by Ming Guo, ZKM Chief Scientist
On the blockchain timeline, Ethereum has been around for ages, in the process evolving into the most widely used network — by a mile. Still, many challenges remain. By enabling decentralized application-building, Ethereum has fueled floods of user interest in popular dApps, only to see its network get bogged down due to painfully limited throughput. Remember CryptoKitties and DeFi Summer¹?
We call CryptoKitties-like situations the “Ethereum Scaling Struggle”. Those moments really squeezed Ethereum — roaring gas fees, long transaction completion wait time and whatnot. But Ethereum is a survivor. Evolutionary pressure like these also fueled its growth in terms of innovation.
The thing about evolution is that nature (or in this case, science) always finds a way. For Ethereum, the Scaling solution now lies in Ethereum Rollups. But before we get to Rollups², let’s examine some of the predecessors of Rollups.
Blockchain consensus is like a giant smooth mirror. You might think you can easily scale it up to build a bigger smooth mirror by just gluing many smaller mirrors together. But no. It’s a very hard thing to do. If you don’t do it right you will be looking into that bigger, stitched-up mirror with each piece of the “shard” reflecting a separate image of you, instead of a single image, like a smooth mirror would do. We can’t just stitch together blockchains with separate consensus to form a bigger (decentralized) blockchain. The mirror analogy is what we call Sharding³, which Ethereum strives to build in future upgrades.⁴
Since Sharding is difficult and deals with shattered consensus, it is a long-term solution for scaling Ethereum (or any blockchain that adopts this approach). What if we can scale Ethereum without even touching its precious consensus? It turns out that “not touching” consensus makes the solution much easier, and a better short-term solution.⁵
Aside from Sharding, the following are other attempts to scale Ethereum:
People tried to glue mirrors together nonetheless, just like we “glue” blockchains together all the time. The smaller chains glued to a main chain are called side chains⁶ (or child chains, with subtle differences sometimes). Side chains often siphon off consensus from the main chain and thus weaken the main chain. So people figured out ways to prohibit side chains to siphon off consensus from the main chain. One such approach is to defer side-chain finality (finalizing transactions) to the main chain by implementing special hash time locks⁷ on the side chains to form state channels. State channel works by making sure that time locks guarantee state finality resolution only on the main chain. On the Bitcoin blockchain this kind of state channel is called the Lightning Network.
Ethereum state channel is more general in the sense that it uses multisig smart contracts⁸ to defer finality (final states) resolution on the main chain. But because it is general, more states have to be stored off chain, creating potential breach points for security. Therefore Ethereum state channel adopts fraud proof⁹ to mitigate the risk, just like in Optimistic Rollups.
Ethereum also has a child chain design called Plasma.¹⁰ Plasma has trees of child chains all having roots on the Ethereum main chain; they act like sort of “checkpoints”. Plasma chain also utilizes fraud proof to mitigate security risks (resolving disputes).
The problem with Ethereum Plasma is that it is too complicated, and as a side chain it has a separate consensus mechanism, thus making it not as secure as the main chain. Ethereum founder Vitalik Buterin invented a new kind of side chain scheme called Shadow Chain¹¹ and it later became what today we call Rollup.¹²
Rollups scale Ethereum by offloading computation and state storage off chain, posting some data onto the Ethereum main chain to prove state transition finality and integrity — consensus. The data Rollups (L2 — Layer 2) posted to Ethereum main chain (L1 — Layer1) are proof that transactions done off-chain are valid. Rollups can scale Ethereum because they effectively increase Ethereum throughput by reducing transaction data size and decreasing transaction time, thus saving gas.
There are two major flavors of Ethereum L2 Rollups, depending on their proof method, or rather, proof philosophy — something like good cop vs. bad cop.
An Optimistic Rollup¹³ is like a good cop, trusting people to be honest and trustworthy until proven otherwise. For this to work, the Optimistic good cop’s main tool is time; not a time lock (as in state channels) but a time window, a challenge time period to be precise. Batched transactions are processed and state changes posted to L1 as is, with instant confirmation. Yet their finality is withheld for a challenge period — usually 7 days. During the challenge period anyone can assume the role of the good cop to expose fraudulent transactions by posting fraud proofs to L1. What happens if someone gets caught? Fraudulent transactions (the whole batch) will be rolled back and an economic sanction will be placed on the fraudster (called slashing).
A ZK Rollup¹⁴ is like a bad cop. Nobody is trusted up front and every batch of transactions must carry a one-time special pass called a validity proof to be posted onto L1. Validity proofs are generated by advanced cryptographic instruments called zero-knowledge proofs/arguments (hence ZK Rollup). These are specifically constructed algebraic circuits (mathematical formulas). The validity proofs are backed by (supposedly) unbreakable mathematics. Therefore all transactions with validity proofs come with instant finality (and confirmation). There is no challenge window and slashing because invalid (fraudulent) transactions will never get posted to L1 in the first place.
As I mentioned earlier, decentralized consensus is an unforgiving beast. It took Ethereum many iterations to find a scaling solution like Rollups. The best thing about Rollups is that they sideline the complexities of decentralized consensus. Rollups settle on the Ethereum L1 and that makes every L2 Rollup transaction as secure as any transaction on the Ethereum L1 main chain. However, the power of Rollups comes at a price. And the future of Rollups dwells on reducing or mitigating that price. Of course we don’t mean “price” literally, but rather design tradeoffs from a user-centric perspective.
Rollups offload computation from L1 to L2 and post proofs to L1. This is the way Rollups maintain both L1 level consensus and L2 level scalability. Of course for getting this nice feature there is a price to pay.
For Optimistic Rollup, the major trade-off price paid is delayed finality in exchange for security (7-day fraud challenge window). There are other minor trade-offs as well, such as favoring withdrawal users over depository users. Most withdrawal users want instant finality but depository users, less so — the bigger the depository funds, the stronger the incentive for them to want a longer fraud challenge window, as that is the way traditional banks do inter-bank settlement. Nevertheless, most transactions are of the withdrawal type, therefore Optimistic Rollup made the trade-off to pick a 7-day fraud challenge window for marginally OK security (this choice has a lingering security ramification in the unlikely yet plausible situation that Ethereum L1 main chain is under attack, we’ll discuss it later).
For ZK Rollups, there seems to be no downside at a first glance. A mathematically sound and tight validity proof for every transaction, with instant finality for all use cases — a true panacea to cure all Ethereum woes. Yet by common wisdom things this good usually have some downsides behind the scenes. One major downside is the zkEVM. ZK secured EVM is notoriously hard to implement and implement correctly. That’s why ZK Rollups roll out much slower than Optimistic Rollups. The early ZK Rollup services only support a limited type of transactions. Another downside is that unlike Optimistic Rollup with its straightforward security argument similar to traditional banking settlement, to some users ZK Rollup is a black box and as such, although it is indeed the future there are holdouts who favor Optimistic Rollup over ZK Rollup when large amount of funds are at stake.
The ramifications of these trade-off prices paid by both Rollups would inevitably call for a better design of a new generation of Rollups.
The Ethereum Rollup space is fragmented. Many in the Ethereum developer community think that ZK Rollups will win out long-term over Optimistic Rollups.¹⁵ That said, from a user-centric perspective the many diagonally opposite characteristics of the two flavors of Rollups can make user choice difficult, depending on specific wants and needs.
Many characteristics of both Rollups are diagonally opposite, e.g. Optimistic Rollup transactions are cheaper than ZK Rollups (for now) but suffer from having to wait 7 days to get finality. For a more comprehensive comparison of the two Rollups, please check out Ethereum co-founder Vitalik Buterin’s article on the topic.¹⁶
To better understand both Optimistic and ZK Rollups from a user-centric perspective we aggregated many of their characteristics in Table 1 below.
Please notice that certain use cases conflict with each other, making it almost impossible to design with all-around satisfaction within a certain Rollup framework; for example, the class of depository users that crave extra security and thus want to have a much longer fraud challenge window (** 15–30 days), are in direct conflict with most Optimistic Rollup users who prefer a 7-day fraud challenge window (they want an even shorter window but Optimistic Rollup can only go no less than 7 days).
Earlier we mentioned that both Optimistic and ZK Rollups made some trade-offs. Trade-offs have ramifications meaning that someday there will be a price to pay for them. As it turns out each Rollup has a dark cloud hanging over its head. We can’t just ignore these dark clouds because they either degrade Ethereum security (a serious allegation) or have practical downside that makes their operation and maintenance unattainable.
Please check out the following table:
Table 2 describes for each Rollup a worrisome scenario. For Optimistic Rollups, the 7-day fraud challenge window is generally thought to be a compromise between usability and security. But it can leave all parties disappointed. Users who want rapid withdrawals feel frustrated to have to wait a week or more to withdraw back to Layer 1. In addition, this 7-day parameter, immensely important for Optimistic Rollups, will be much more difficult to design around once the TVL of Rollups becomes much bigger in the near future and thus also becomes much more vulnerable to attacks.
For ZK Rollups the biggest problem is that EVM (Ethereum Virtual Machine) is not stable in the sense that its design changes quite frequently, making it difficult to build zkEVM for it.
Therefore the answer to the question “Which Rollup Is Better?” is this: both Rollups, even though well implemented, have merits and challenges of their own, and we can’t say one is better than the other. And from a user-centric perspective, neither one covers the broadest use case spectrum.
Users (or application developers) shouldn’t have to care which Rollup they have to choose — they should have a seamless experience as when transacting on Ethereum L1, but with a much higher throughput.
Each Rollup has its own strengths and weaknesses — so can we combine Optimistic Rollup and ZK Rollup to cover a broader spectrum of use cases to give users and developers a smoother user experience? We call this the usability challenge for Rollups.
And we have a solution. It’s called Hybrid Rollup.¹⁷
Conceptually, Hybrid Rollup combines the two Rollups, Optimistic Rollup and ZK Rollup, into one cohesive Rollup protocol. Hybrid Rollup should address the shortcomings of the two Rollups, and cover a broader range of use cases.
Table 3 lists the design goals of Hybrid Rollup. It should address problems raised in Table 2 of the two Rollups: 1. Provide for conflicting needs of near-instant withdrawals and a much longer fraud challenge window of 15–30 days based on alternate user needs and wants; 2. Solve the EVM stability problem.
Hybrid Rollup is a chimera because we put a ZK Rollup inside an Optimistic Rollup body. The design goal is to cover as many use cases as possible. When we think of next-generation Rollups, we need to consider use cases of large user classes as well as smaller user classes of different design criteria (properties as Vitalik calls them¹⁸), as in Table 1.
Fig 1 demonstrates the chimera design of Hybrid Rollup. From this process diagram we can see that the beginning phase of a Hybrid Rollup looks like an Optimistic Rollup. Most withdrawal transactions can be processed using ZK validity proofs to bypass the usual Optimistic 7-day fraud challenge phase (Fig 1 — “If smart contract is happy”). Those that failed the validity check still go to an Optimistic fraud challenge phase. But with Hybrid Rollups we could make the fraud challenge window much longer (since those who would want to bypass the fraud proof window, be it 7 days or longer, can bypass it with validity proof, a choice they didn’t have previously with standard Optimistic Rollup) — say 15–30 days.
This longer fraud challenge window has many benefits. In pure Optimistic Rollup the conflicting needs to have both a shorter fraud challenge window for most withdrawal transactions and an actually preferred longer fraud challenge window for big fund transactions (including depository transactions) are hard to reconcile. Now with Hybrid Rollup, we can handle all those previously conflicting use cases harmoniously.
Another scenario is that situations exist where a longer fraud challenge window is the last resort to provide security. Imagine when the Ethereum L1 main chain is attacked (say hijacked by some malicious POS nodes that somehow accumulate a vast amount of ETH) and the whole network (L1 & L2) is flooded with fraudulent transactions. In such dire situations, on the Hybrid Rollup network all transactions will automatically be filtered toward the longer 15 or 30-day challenge window. That way, even if someone might hold the Ethereum network hostage for 7 days, it is much more difficult to continue to hold it for up to 30 days. This is the situation where Hybrid Rollup as a last resort saves Ethereum L1.
Fig 1 shows a user-centric view of Hybrid Rollup. In the next section I’ll show you how we incorporate this design vision into the Ethereum Rollup tech stack.
In this section I’ll show you the machinery of the Hybrid Rollup chimera. I’ll lay bare all the plumbing that makes it work. To fully grasp how we put a ZK Rollup inside an Optimistic Rollup, I’ll show you the plumbings of all three Rollups (Optimistic, ZK and Hybrid Rollup).
Fig 2, 3, 4 show the Ethereum tech stack view of the three kinds of Rollup: Optimistic, ZK and Hybrid Rollup. It is how each Rollup works as a software process. We can see how Optimistic Rollup and ZK Rollup processes are merged into a Hybrid Rollup process that is functional.
Next I’ll show you the function architecture that powers the Hybrid Rollup process. To make an efficient machine we have to be innovative to create capable components, such as our own ZK Rollup component called zkMIPS. See the diagram below.
Fig 5 is a function diagram of Hybrid Rollup. As stated in previous sections, both Optimistic Rollup and ZK Rollup accumulated a lot of evolutionary baggage that made them cumbersome. In order to build Hybrid Rollup we need efficient components, especially ZK Rollup machinery. In Table 3 we mentioned a MIPS based ZK circuit machinery called zkMIPS, which is beyond the scope of this article. For those interested, please refer to this whitepaper.¹⁹
Ethereum’s future is L1 for consensus and L2 Rollups for scaling. And Rollup’s future is Hybrid Rollup. As hot as ZK Rollup technology has become, its dominance will be wrapped in the form of Hybrid Rollup.
Evolution is a neverending process, as well as a neverending story. There is no epilogue for this drama we call the Ethereum Scaling Struggle. Stay tuned for the next chapter of this grand story.
Endnotes
¹ The Inside Story of the CryptoKitties Congestion Crisis; A Look Back at 2020, the Year of DeFi
³Ethereum Sharding, Ethereum sharding: A beginner’s guide to blockchain sharding
⁵ Ethereum Sharding: Comparison with Other Scaling Solutions
⁷Hash Time Locked Contracts (HTLCs) Explained
¹¹ Scalability, Part 1: Building on Top#Off-chain oracles
¹²The Dawn of Hybrid Layer 2 Protocols
¹⁵ A rollup-centric ethereum roadmap
¹⁶ An Incomplete Guide to Rollups
¹⁷An earlier mention of Hybrid Rollup can be found here: The hybrid ZK/Optimistic Rollup of the future
¹⁸An Incomplete Guide to Rollups
—
Have you read the ZKM whitepaper yet? Check it out at https://ethresear.ch/t/zkmips-a-zero-knowledge-zk-vm-based-on-mips-architecture/16156
Want to discuss this article and other ZK-related topics with our core ZKM team? Join our Discord channel: discord.gg/Bck7hdGcns
Want to discuss this and other ZK-related topics with our core ZKM team? Join our Discord channel: discord.gg/Bck7hdGcns
by Ming Guo, ZKM Chief Scientist
On the blockchain timeline, Ethereum has been around for ages, in the process evolving into the most widely used network — by a mile. Still, many challenges remain. By enabling decentralized application-building, Ethereum has fueled floods of user interest in popular dApps, only to see its network get bogged down due to painfully limited throughput. Remember CryptoKitties and DeFi Summer¹?
We call CryptoKitties-like situations the “Ethereum Scaling Struggle”. Those moments really squeezed Ethereum — roaring gas fees, long transaction completion wait time and whatnot. But Ethereum is a survivor. Evolutionary pressure like these also fueled its growth in terms of innovation.
The thing about evolution is that nature (or in this case, science) always finds a way. For Ethereum, the Scaling solution now lies in Ethereum Rollups. But before we get to Rollups², let’s examine some of the predecessors of Rollups.
Blockchain consensus is like a giant smooth mirror. You might think you can easily scale it up to build a bigger smooth mirror by just gluing many smaller mirrors together. But no. It’s a very hard thing to do. If you don’t do it right you will be looking into that bigger, stitched-up mirror with each piece of the “shard” reflecting a separate image of you, instead of a single image, like a smooth mirror would do. We can’t just stitch together blockchains with separate consensus to form a bigger (decentralized) blockchain. The mirror analogy is what we call Sharding³, which Ethereum strives to build in future upgrades.⁴
Since Sharding is difficult and deals with shattered consensus, it is a long-term solution for scaling Ethereum (or any blockchain that adopts this approach). What if we can scale Ethereum without even touching its precious consensus? It turns out that “not touching” consensus makes the solution much easier, and a better short-term solution.⁵
Aside from Sharding, the following are other attempts to scale Ethereum:
People tried to glue mirrors together nonetheless, just like we “glue” blockchains together all the time. The smaller chains glued to a main chain are called side chains⁶ (or child chains, with subtle differences sometimes). Side chains often siphon off consensus from the main chain and thus weaken the main chain. So people figured out ways to prohibit side chains to siphon off consensus from the main chain. One such approach is to defer side-chain finality (finalizing transactions) to the main chain by implementing special hash time locks⁷ on the side chains to form state channels. State channel works by making sure that time locks guarantee state finality resolution only on the main chain. On the Bitcoin blockchain this kind of state channel is called the Lightning Network.
Ethereum state channel is more general in the sense that it uses multisig smart contracts⁸ to defer finality (final states) resolution on the main chain. But because it is general, more states have to be stored off chain, creating potential breach points for security. Therefore Ethereum state channel adopts fraud proof⁹ to mitigate the risk, just like in Optimistic Rollups.
Ethereum also has a child chain design called Plasma.¹⁰ Plasma has trees of child chains all having roots on the Ethereum main chain; they act like sort of “checkpoints”. Plasma chain also utilizes fraud proof to mitigate security risks (resolving disputes).
The problem with Ethereum Plasma is that it is too complicated, and as a side chain it has a separate consensus mechanism, thus making it not as secure as the main chain. Ethereum founder Vitalik Buterin invented a new kind of side chain scheme called Shadow Chain¹¹ and it later became what today we call Rollup.¹²
Rollups scale Ethereum by offloading computation and state storage off chain, posting some data onto the Ethereum main chain to prove state transition finality and integrity — consensus. The data Rollups (L2 — Layer 2) posted to Ethereum main chain (L1 — Layer1) are proof that transactions done off-chain are valid. Rollups can scale Ethereum because they effectively increase Ethereum throughput by reducing transaction data size and decreasing transaction time, thus saving gas.
There are two major flavors of Ethereum L2 Rollups, depending on their proof method, or rather, proof philosophy — something like good cop vs. bad cop.
An Optimistic Rollup¹³ is like a good cop, trusting people to be honest and trustworthy until proven otherwise. For this to work, the Optimistic good cop’s main tool is time; not a time lock (as in state channels) but a time window, a challenge time period to be precise. Batched transactions are processed and state changes posted to L1 as is, with instant confirmation. Yet their finality is withheld for a challenge period — usually 7 days. During the challenge period anyone can assume the role of the good cop to expose fraudulent transactions by posting fraud proofs to L1. What happens if someone gets caught? Fraudulent transactions (the whole batch) will be rolled back and an economic sanction will be placed on the fraudster (called slashing).
A ZK Rollup¹⁴ is like a bad cop. Nobody is trusted up front and every batch of transactions must carry a one-time special pass called a validity proof to be posted onto L1. Validity proofs are generated by advanced cryptographic instruments called zero-knowledge proofs/arguments (hence ZK Rollup). These are specifically constructed algebraic circuits (mathematical formulas). The validity proofs are backed by (supposedly) unbreakable mathematics. Therefore all transactions with validity proofs come with instant finality (and confirmation). There is no challenge window and slashing because invalid (fraudulent) transactions will never get posted to L1 in the first place.
As I mentioned earlier, decentralized consensus is an unforgiving beast. It took Ethereum many iterations to find a scaling solution like Rollups. The best thing about Rollups is that they sideline the complexities of decentralized consensus. Rollups settle on the Ethereum L1 and that makes every L2 Rollup transaction as secure as any transaction on the Ethereum L1 main chain. However, the power of Rollups comes at a price. And the future of Rollups dwells on reducing or mitigating that price. Of course we don’t mean “price” literally, but rather design tradeoffs from a user-centric perspective.
Rollups offload computation from L1 to L2 and post proofs to L1. This is the way Rollups maintain both L1 level consensus and L2 level scalability. Of course for getting this nice feature there is a price to pay.
For Optimistic Rollup, the major trade-off price paid is delayed finality in exchange for security (7-day fraud challenge window). There are other minor trade-offs as well, such as favoring withdrawal users over depository users. Most withdrawal users want instant finality but depository users, less so — the bigger the depository funds, the stronger the incentive for them to want a longer fraud challenge window, as that is the way traditional banks do inter-bank settlement. Nevertheless, most transactions are of the withdrawal type, therefore Optimistic Rollup made the trade-off to pick a 7-day fraud challenge window for marginally OK security (this choice has a lingering security ramification in the unlikely yet plausible situation that Ethereum L1 main chain is under attack, we’ll discuss it later).
For ZK Rollups, there seems to be no downside at a first glance. A mathematically sound and tight validity proof for every transaction, with instant finality for all use cases — a true panacea to cure all Ethereum woes. Yet by common wisdom things this good usually have some downsides behind the scenes. One major downside is the zkEVM. ZK secured EVM is notoriously hard to implement and implement correctly. That’s why ZK Rollups roll out much slower than Optimistic Rollups. The early ZK Rollup services only support a limited type of transactions. Another downside is that unlike Optimistic Rollup with its straightforward security argument similar to traditional banking settlement, to some users ZK Rollup is a black box and as such, although it is indeed the future there are holdouts who favor Optimistic Rollup over ZK Rollup when large amount of funds are at stake.
The ramifications of these trade-off prices paid by both Rollups would inevitably call for a better design of a new generation of Rollups.
The Ethereum Rollup space is fragmented. Many in the Ethereum developer community think that ZK Rollups will win out long-term over Optimistic Rollups.¹⁵ That said, from a user-centric perspective the many diagonally opposite characteristics of the two flavors of Rollups can make user choice difficult, depending on specific wants and needs.
Many characteristics of both Rollups are diagonally opposite, e.g. Optimistic Rollup transactions are cheaper than ZK Rollups (for now) but suffer from having to wait 7 days to get finality. For a more comprehensive comparison of the two Rollups, please check out Ethereum co-founder Vitalik Buterin’s article on the topic.¹⁶
To better understand both Optimistic and ZK Rollups from a user-centric perspective we aggregated many of their characteristics in Table 1 below.
Please notice that certain use cases conflict with each other, making it almost impossible to design with all-around satisfaction within a certain Rollup framework; for example, the class of depository users that crave extra security and thus want to have a much longer fraud challenge window (** 15–30 days), are in direct conflict with most Optimistic Rollup users who prefer a 7-day fraud challenge window (they want an even shorter window but Optimistic Rollup can only go no less than 7 days).
Earlier we mentioned that both Optimistic and ZK Rollups made some trade-offs. Trade-offs have ramifications meaning that someday there will be a price to pay for them. As it turns out each Rollup has a dark cloud hanging over its head. We can’t just ignore these dark clouds because they either degrade Ethereum security (a serious allegation) or have practical downside that makes their operation and maintenance unattainable.
Please check out the following table:
Table 2 describes for each Rollup a worrisome scenario. For Optimistic Rollups, the 7-day fraud challenge window is generally thought to be a compromise between usability and security. But it can leave all parties disappointed. Users who want rapid withdrawals feel frustrated to have to wait a week or more to withdraw back to Layer 1. In addition, this 7-day parameter, immensely important for Optimistic Rollups, will be much more difficult to design around once the TVL of Rollups becomes much bigger in the near future and thus also becomes much more vulnerable to attacks.
For ZK Rollups the biggest problem is that EVM (Ethereum Virtual Machine) is not stable in the sense that its design changes quite frequently, making it difficult to build zkEVM for it.
Therefore the answer to the question “Which Rollup Is Better?” is this: both Rollups, even though well implemented, have merits and challenges of their own, and we can’t say one is better than the other. And from a user-centric perspective, neither one covers the broadest use case spectrum.
Users (or application developers) shouldn’t have to care which Rollup they have to choose — they should have a seamless experience as when transacting on Ethereum L1, but with a much higher throughput.
Each Rollup has its own strengths and weaknesses — so can we combine Optimistic Rollup and ZK Rollup to cover a broader spectrum of use cases to give users and developers a smoother user experience? We call this the usability challenge for Rollups.
And we have a solution. It’s called Hybrid Rollup.¹⁷
Conceptually, Hybrid Rollup combines the two Rollups, Optimistic Rollup and ZK Rollup, into one cohesive Rollup protocol. Hybrid Rollup should address the shortcomings of the two Rollups, and cover a broader range of use cases.
Table 3 lists the design goals of Hybrid Rollup. It should address problems raised in Table 2 of the two Rollups: 1. Provide for conflicting needs of near-instant withdrawals and a much longer fraud challenge window of 15–30 days based on alternate user needs and wants; 2. Solve the EVM stability problem.
Hybrid Rollup is a chimera because we put a ZK Rollup inside an Optimistic Rollup body. The design goal is to cover as many use cases as possible. When we think of next-generation Rollups, we need to consider use cases of large user classes as well as smaller user classes of different design criteria (properties as Vitalik calls them¹⁸), as in Table 1.
Fig 1 demonstrates the chimera design of Hybrid Rollup. From this process diagram we can see that the beginning phase of a Hybrid Rollup looks like an Optimistic Rollup. Most withdrawal transactions can be processed using ZK validity proofs to bypass the usual Optimistic 7-day fraud challenge phase (Fig 1 — “If smart contract is happy”). Those that failed the validity check still go to an Optimistic fraud challenge phase. But with Hybrid Rollups we could make the fraud challenge window much longer (since those who would want to bypass the fraud proof window, be it 7 days or longer, can bypass it with validity proof, a choice they didn’t have previously with standard Optimistic Rollup) — say 15–30 days.
This longer fraud challenge window has many benefits. In pure Optimistic Rollup the conflicting needs to have both a shorter fraud challenge window for most withdrawal transactions and an actually preferred longer fraud challenge window for big fund transactions (including depository transactions) are hard to reconcile. Now with Hybrid Rollup, we can handle all those previously conflicting use cases harmoniously.
Another scenario is that situations exist where a longer fraud challenge window is the last resort to provide security. Imagine when the Ethereum L1 main chain is attacked (say hijacked by some malicious POS nodes that somehow accumulate a vast amount of ETH) and the whole network (L1 & L2) is flooded with fraudulent transactions. In such dire situations, on the Hybrid Rollup network all transactions will automatically be filtered toward the longer 15 or 30-day challenge window. That way, even if someone might hold the Ethereum network hostage for 7 days, it is much more difficult to continue to hold it for up to 30 days. This is the situation where Hybrid Rollup as a last resort saves Ethereum L1.
Fig 1 shows a user-centric view of Hybrid Rollup. In the next section I’ll show you how we incorporate this design vision into the Ethereum Rollup tech stack.
In this section I’ll show you the machinery of the Hybrid Rollup chimera. I’ll lay bare all the plumbing that makes it work. To fully grasp how we put a ZK Rollup inside an Optimistic Rollup, I’ll show you the plumbings of all three Rollups (Optimistic, ZK and Hybrid Rollup).
Fig 2, 3, 4 show the Ethereum tech stack view of the three kinds of Rollup: Optimistic, ZK and Hybrid Rollup. It is how each Rollup works as a software process. We can see how Optimistic Rollup and ZK Rollup processes are merged into a Hybrid Rollup process that is functional.
Next I’ll show you the function architecture that powers the Hybrid Rollup process. To make an efficient machine we have to be innovative to create capable components, such as our own ZK Rollup component called zkMIPS. See the diagram below.
Fig 5 is a function diagram of Hybrid Rollup. As stated in previous sections, both Optimistic Rollup and ZK Rollup accumulated a lot of evolutionary baggage that made them cumbersome. In order to build Hybrid Rollup we need efficient components, especially ZK Rollup machinery. In Table 3 we mentioned a MIPS based ZK circuit machinery called zkMIPS, which is beyond the scope of this article. For those interested, please refer to this whitepaper.¹⁹
Ethereum’s future is L1 for consensus and L2 Rollups for scaling. And Rollup’s future is Hybrid Rollup. As hot as ZK Rollup technology has become, its dominance will be wrapped in the form of Hybrid Rollup.
Evolution is a neverending process, as well as a neverending story. There is no epilogue for this drama we call the Ethereum Scaling Struggle. Stay tuned for the next chapter of this grand story.
Endnotes
¹ The Inside Story of the CryptoKitties Congestion Crisis; A Look Back at 2020, the Year of DeFi
³Ethereum Sharding, Ethereum sharding: A beginner’s guide to blockchain sharding
⁵ Ethereum Sharding: Comparison with Other Scaling Solutions
⁷Hash Time Locked Contracts (HTLCs) Explained
¹¹ Scalability, Part 1: Building on Top#Off-chain oracles
¹²The Dawn of Hybrid Layer 2 Protocols
¹⁵ A rollup-centric ethereum roadmap
¹⁶ An Incomplete Guide to Rollups
¹⁷An earlier mention of Hybrid Rollup can be found here: The hybrid ZK/Optimistic Rollup of the future
¹⁸An Incomplete Guide to Rollups
—
Have you read the ZKM whitepaper yet? Check it out at https://ethresear.ch/t/zkmips-a-zero-knowledge-zk-vm-based-on-mips-architecture/16156
Want to discuss this article and other ZK-related topics with our core ZKM team? Join our Discord channel: discord.gg/Bck7hdGcns
Want to discuss this and other ZK-related topics with our core ZKM team? Join our Discord channel: discord.gg/Bck7hdGcns
