IOSG OFR14th Keynote: Stage 2 Rollups: How do we get there? Proof, proof, proof!

Everyone, great honor to be here, and thanks for the invite from Jocy and also IOSG. And yeah, since we are at the Devcon, right? So I like to share a little bit more on all the sort of latest progress in the rollup space. And also for the past few weeks or almost one or two months, there have been a bunch of these Zuvillages happening in Chiang Mai, and a lot of developers, especially core developers discussing how we really push or at least move forward for all the existing rollups from for example stage zero to stage two. And it’s also something I suggest Gohan mentioned, right?

So for Ethereum, especially for the near future, since we already have this roller-centric future, what kind of new stuff we can do to make all the rollups more decentralized and with much better safety? Before we go into for example what are the different stages for rollup typically we want to know, okay, what’s the existing structure or architecture for the rollup system, right? It hasn’t really evolved too much for the past few years since the first time this rollup was basically mentioned in the Ethereum ecosystem. So when we talk about rollup, typically when we say right now it’s a dominant scaling solution, we always want to know what kind of problems the rollup wants to solve. So it’s quite straightforward.

Basically, the roll app is a way for Ethereum or the L1s to offload these on-chain executions to off-chain, typically using this sequencer basically a very beefy machine to precise and also order and also execute the transactions. After that, they will generate proofs. For optimistic rollup is typically called fraud-proof. For zk rollup is typically like a sort of validity proof and is posted to Ethereum. So the L1 or Ethereum can do the verification. So in this case, right, as you can see, most of the transactions will be executed off-chain, but we have the proof to show that these transactions are executed correctly and the L1 can do the verification of the proofs. So in this case, as you can see, right, even not any of the execution happening on Ethereum, it can still derive security from Ethereum.

So that’s why since 2014, 2015 when Vitalik mentioned Ethereum and also how we addressed these scaling issues over a decade, right? Also like as I mentioned in my tweets, basically I feel like Vitalik really fulfilled his commitment like a decade ago. Basically, right now we have a much more scalable Ethereum ecosystem to precise as many transactions as we want. And however we know, right? For rollup, there are multiple tabs. Sometimes we Say it’s optimistic rollup, ZK rollup or base rollup and also restaked rollup. But what kind of. There are also some other ways to basically measure how decentralized and safe these rollups are. And from either this Ethereum forum or typically we check out this L2Beat right they have these different stages to categorize the different rollups. Right now for most of the rollup typically they are all in stage zero.

Stage zero is like this kind of training wheel phase and the requirement or this kind of criteria is very basic. Basically , the project is called rollup. After that, you can have some machine post this transaction body or this can compress some of the data to the L1. And at the same time as I mentioned, it would be great. You can have some nodes and full nodes can download the data of other transactions from the L1, and then they can re-execute and restore the interstate for the rollup. And beyond that, since it’s a rollup right, it would be great. We can have some ways for users to deposit and withdraw their funds for stage zero. It doesn’t require fraud proof ZK proof or validity proof. So in that case you can see almost any chains that are using OP Stack, Arbitrum Orbit.

We basically say that okay, we launch like a rollup. We don’t really argue that is the fraud proof is enabled or not. It’s basically even for OP, right? It’s just for the past few weeks the enabled is fault proof. But right now as you can see, most of the rollups we can see in the market, probably hundreds of the rollups, most of them at this stage zero training whale phase and beyond that since almost day one Abitrum has this fraud-proof and last few weeks OP enabled is fault proof, right? They just give a new name fault proof, fraud proof, they are almost the same. And if you want to go to state one right then you must have at least one proof system enabled in your rollup.

So typically for optimistic rollup is fraud-proof and for ZK rollup, it’s validity proof. The difference for Optimistic rollup this fraud-proof typically engages with this bisection mechanism. If something is wrong, the challenger can challenge this verifier or this sequencer, and then to see who is wrong the other party will be slashed of their stakes. But for validity proof, it’s a sort of generated by zk that prover and the proof can be directly verified on Ethereum. Beyond that typical they also have some not-that-technical requirements as I mentioned in the slides. So Basically we need to have a security concile right now most of these, basically all the rollups they are contracts on Ethereum managed by multisale Wallet. So if you agree we can have multiple these sorts of parties and send the signature for some necessary upgrades and also bugs.

And they also want to have some delays on these decisions. For example, if something is wrong, we don’t want things to happen immediately. It will be great. We can have a seven-day delay when we want to do the next upgrade via this Security Council. Then beyond that, we want better decentralization and also safety. Then there’s also the highest state so far is state 2. Basically for rollup you need multiple proof systems. One proof system like fraud-proof or zk proof. And that’s not enough probably we need some TEE some extra proof systems to make you have some redundancy. At the same time, I have some diversity about your proof system. So in that case, if one proof system somehow is broken, for example, there are some critical bugs on the ZK prover.

But at least we can have probably some fraud-proof or TEE to make sure we still have the ways to make sure the proof that was submitted to the L1 is correct. Beyond that of course we want to limit the Security Council’s power, right? We don’t want the Security Council to really sort of upgrade or patch the bugs at any time. Then the power is too big. And the same time we also want to add these extra delays. No longer seven days, but it would be great. Like we have 30 days. As I mentioned, if you look at L2Beat even it is not that comprehensive. On L2Beat probably we only have less than 100. But based on our experience we have definitely over a few hundreds of roll ups since we already launched a bunch of them.

In that case, almost all of them are in either stage one or stage zero. Very few of them stage two. Typically they have limited functionalities. For the major ones like Arbitrum and OP, they are in stage one. But for most of these OP stacks, even superchain, they are still in stage zero. If you look closely at this Optimism and also Arbitrum, we can see that typically if they want to go to stage two, of course they need to have a multiprover. So far they don’t have. Beyond that is the other parts are not the technical ones I just mentioned. You need to extend the delay when you want to upgrade the contract.

Then we will see how we really make all the rollups into stage Two, even for optimism and also Arbitrum, one thing as I just mentioned, one way is that we can have these multiprovers systems. One is basically the ZK proof or fraud proof. And the other thing is, as I just mentioned, we can also engage with the TEE prover to generate the proof. After that the Security Council can see, okay, all the proofs are the same. If not same, probably we can pick two out of three, we get the majority votes and then to make decision. Okay, what kind of proof we posted to the L1. On top of that, as I just mentioned, the other proof system, they are not just a standalone.

There’s a bunch of ways we can combine them together to make a better one. One example is basically for optimistic rollup we have the fraud proof and for ZK rollup we have validity proof. But is it possible we make it together. And so in that case we can leverage the ZK proofs like these kinds of mathematics. At the same time we can also reduce the cost of this ZK proof generation. So that’s a part I want to mention about this ZK fraud proof approach. So the idea behind this ZK fraud proof, as I mentioned, right, if it’s a ZK rollup, we need to regularly submit this ZK proof to the L1 to the verification. Typically the approval cost is super high. It’s over like $10,000 per month.

And also if you have a lot of transaction, the proof of verification on Ethereum also very costly. And beyond that, if we just do this optimistic fraud proof, right? So in that case, like there’s a bisection, like sort of a mechanism typical engage with a bunch of these option challengers and it’s very lengthy and sometimes like, you know, right, it takes a long time. The good thing, like if we can combine them together, we can leverage the ZK proof. At the same time we can also make it optimistic. So in that case we don’t need to Regularly, almost every 20 blocks we generate a ZK proof so we can save the cost. And one idea behind this approach is that, okay, let’s optimize this optimistic rollup. Right now we have this bisection protocol. So we still have the challenger and also sequencer.

If something wrong, challenger, start this sort of bisection protocol and then they will challenge each other until they figure out this instruction is not correct. Then they figure out who is correct, who is wrong. We can replace the last step with the ZK proof. In that case you can see it’s super cheap because you only need to generate ZK proof for the last instruction. But the drawback, as you can see, we still need to engage with this bisection protocol. It’s very lengthy and takes hours or days. The second option, forget about this bisection protocol. Let’s directly use ZK proof, generate the proof for this kind of challenge or the proof for the past few blocks and transactions and post to the L1.

So in that case, as you can see, it’s relatively expensive because you need generate ZK proof for bunch of blocks and also transactions. But however, we don’t need to go through this very lengthy bisection mechanism and protocol. And in that case, right, we can quickly decide who is correct and who is wrong. As I just mentioned, right, there’s a pros and cons for both the solutions, but in the end I would say it’s definitely another approach like we can engage to help and provide an extra proof system for the existing roll app and to move them into this kind of C2.

And based on our experience and also learnings, right, most of the rollups so far in the space either using OP Stack or Arbitrum Orbit because people want the high performance sort of rollup at the same time with minimum cost it just takes probably less than $3,000 every month. And at the same time people want this ZK proof in some affordable way. We all know that for ZK proof generation it takes from a few minutes, 20 minutes to a few hours. It depends on how beefy is your machine or the proofer is. Basically that’s a part we can relearn from the past experience. Beyond that, so far none of these existing system for different pool systems having these staking, slashing mechanism.

So that means sometimes it’s just a POA network and it’s well listed and only a few selected sort of nodes can do this challenging and also proof generation, of course, as I mentioned, right beyond this ZK proof, fraud proof, optimistic ZK proof, we can also use some TEE to do this proof generation. The workflow as you can see, right, is quite similar to the ZK proof. Just like replacing the ZK proofer with TEE prover, beyond that you need some extra verification and for the remote attestation, that’s it. It’s like this machine is much cheaper than this ZK prover. And the drawback is that, okay, we all know that there are a bunch of side channels against the TEE solutions like the SGX. And also I did a bunch of research a decade ago on attacking these systems.

By the way, as I mentioned for stage 2 we just need multiple proof systems. If one proof system is under attack or has bugs so at least we can have some backup and have some redundancy. But as I mentioned actually in the new slides today I will just make the announcement. So we are having sort of this new system called Vital. With Vital we can directly push all the existing rollups and also new rollups into the Stake tool. So the good thing about this vital system is basically we don’t need to change the existing roller stacks like OP Stack, and Arbitrum Orbit, but we will directly provide some extra proof systems.

As I mentioned to you, right, either it’s a ZK validity proof system or an optimistic ZK proof system, all these kinds of TEE proof systems. So one thing I previously mentioned earlier, we are providing these restake rollout systems and one of the key features today I want to announce is that the vital is to provide this extra verification layer with multiple proof systems embedded. In that case, when you ask us to help you launch a rollup, we will also launch this vital AVS to help you directly equip your rollup with a multiprovers system. So in that case as I mentioned at the beginning we want all the rollups into state two and now with the system we provide we can directly go into this state two without much hassle and we will also share more details in the rollout days.

So just feel free to join us. Beyond that if you really have a lot of these interest in building the stage two rollups and if you want to do a lot of research in this area providing different proof systems for the existing rollups, just feel free to reach out to us and it would be great like we can work together on different sort of these aspects. And beyond that, as I mentioned, right, we are already at the tipping point and we already have all different rollup stacks and rollups. I believe we can easily to basically scale the existing applications in crypto to the Internet scale level. But at the same time, we also want to have more applications and we also want to have more safety for the existing rollups.

So that’s a part I believe for the next few months, the next few years either for the Ethereum foundation or for us to push the limit for the space to provide a much scalable roll up. At the same time, we also take decentralization and safety into consideration. Yeah, that’s all about my talk, and yeah. Thanks for your time.