Although Vitalik has identified zkEVM Rollup as the future for several years, and various zkEVMs (Scroll, zkSync, Hermez, Consensys) have sprung up, Optimistic Rollup is still the dominant stack in the Rollup ecosystem, with 80% of the Layer2 market share and half of the top 10 Layer2 solutions.

Will the existence of zkEVM Rollup as the ultimate scaling solution make Optimistic Rollup completely obsolete?

• Optimistic Rollup and zkEVM Rollup are not incompatible, but will be complementary solutions in the long run (even permanently).

• For App-rollup, the Optimistic mechanism is still the simplest and easiest solution to develop and deploy.

According to Vitalik, the zkEVM circuit of the Ethereum Foundation PSE has 34,469 lines of code. That’s a lot of code to polish in a very long period of development and continuous testing. We won’t be able to fully rely on the security offered by the ZK system for several years.

Six months ago, Optimism’s Kelvin started tweeting a lot about the feasibility of combining Optimism with zkVM.

He says Optimism’s Bedrock will not be just an Optimistic Rollup client, but a Rollup client. In order to fully guarantee the overall security of Rollup, the client (perhaps related to Arbitrum’s recent acquisition?) and the diversity of proofs (Validity Proof and Fraud Proof) are the real roadmap for Rollup.

Vitalik has refined Kelvin’s solution, suggesting that a 2 + 1 combination of (OP + ZK) + Governance could be used to achieve a reliable Rollup.

Until zkEVM is fully stable and mature, the workflow is as follows:

1. publish the block

2. wait 24 hours

3. a) If there are no fraud challenges during this period, release the ZKP and fully finalize the block. b) If there are challenges, Governance is introduced to adjudicate the final result through the 2 of 3 model.

After zkEVM is stable and mature:

1. release the block

2. Publish ZKP periodically.

3. a) If the ZKP is released properly during the specified period, it will prevail. b) If the ZKP is not released properly during the period (Prover failure or bug), the Optimistic mechanism is introduced first, until the ZK mechanism is restored.

Both options require the existence of the Optimistic mechanism to ensure the liveness and safety of the entire Rollup system.

Therefore, the development of the Optimistic mechanism is still the vital part of the Rollup universe.

The term “Second-Generation Optimistic Rollup” comes from the title of Arbitrum Nitro’s white paper. The Optimism Bedrock, which was released slightly earlier than Nitro, is also considered a Second-Generation Optimistic Rollup.

The overall difference between the two is not really that big (if you read Arbitrum and Optimism blogs, you might even think they are the same), they are essentially a new major release with themselves. The differences between the second generation and the first generation are just the following optimizations:

• Developer experience: stronger EVM equivalence and compatibility, L1 interoperability…

• User experience: higher throughput, lower gas…

But there are still trade-offs in design details, and we can see in these differences the refinement of Arbitrum and Optimism in building the next generation of Optimistic Rollup.

The developers of Arbitrum and Optimism have compared and contrasted their architectures, and here we will discuss only those points that are relevant to users or dApp developers:

There are two main options for block time design: fixed time or variable time. This can be interpreted as the difference between PoS and PoW Ethereum.

• Optimism: fixed time (2 seconds).

Fixed time ensures the stability of contracts that use block.number to measure the time, such as Sushiswap’s Masterchef contract. These contracts do not use timestamps probably because the miner has control over the timestamp (sort of selfish mining or MEV?).

The first generation of Optimism used a variable time + 1 tx/block design, so there were some problems with Stargate rewards due to its contracts’ time calculation algo.

For the old 1 tx/block design, Optimism considered the overhead of the storage of the blockchain too high due to the block header and the need for frequent updates to the state root too costly.

• Arbitrum: Variable time.

Variable time is designed to reduce the delay of tx confirmation. Currently, up to 4 blocks can be created per second, and skipped if there is no tx, so it is variable time.

For contracts that are timed with block.number, Arbitrum returns the block.number directly from the Ethereum L1 block, so there are no stability or adaptation issues. In addition, Arbitrum also provides a pre-compile to provide L2 block numbers.

Geth is the execution client of Ethereum, which accounts for about 80% of the total number of nodes.

• Optimism: As a standalone engine.

Geth is treated as a standalone execution engine, not a library. The advantage is that it can fully reuse the previous infrastructure, while seamlessly switching to other execution clients.

• Arbitrum: As a library.

Since Arbitrum has more L2-specific features, such as gas pricing for L1 and L2, and retryable tickets, Geth is handled as a library. Arbitrum uses hooks for invocation.

• Optimism: ~2 minutes.

Bedrock’s latency is the length of several L1 blocks, with a worst-case latency of ten minutes.

Bedrock’s architecture is more like an L1, which in extreme cases can cope with L1 reorg by reorging itself.

A tx that is not contained by L2 for more than 10 minutes is simply invalidated.

• Arbitrum: 10 minutes.

Nitro delays processing for 10 minutes, and if it exceeds 10 minutes, it can force tx inclusion via an L1 call.

The goal of Nitro is to make L2 never need to reorg for user experience.

Both are tradeoffs for user experience in different ways.

The message retry mechanism is designed to solve the problem of “L1 confirmed, L2 failed” in L1-L2 messaging.

• Optimism: Implemented in the contract.

Developers can refer to the L1 Optimism Portal implementation, or define their own retry mechanism in the contract.

• Arbitrum: Implemented in the node.

The retry mechanism is implemented in the ArbOS node.

The gas calculation for L2 is basically L2 execution gas + L1 calldata cost.

• Optimism: Reuse EIP-1559.

The benefit is that the wallet and other infrastructure can be seamlessly connected.

Optimism’s calculation of L2 gas essentially minimizes the cost of L2 execution gas (99% of it is calldata cost).

• Arbitrum: Use a custom system.

Due to the variable block time design mentioned earlier, gas pricing is more complex, so EIP-1559 is not used.

• Optimism:

The transmission of L1 gas levels to L2 is almost instantaneous. Currently sequencer’s revenue is basically entirely from the multiplier of L1 gas costs. After EIP-4844, their revenue will come from MEV.

In the future, this data will be transmitted via L1-L2 messaging, thus ensuring security (being part of the protocol and subject to fraud challenge).

• Arbitrum:

Arbitrum’s L1 fee algorithm collects fees by averaging the L1 gas, and uses its own control system to obtain feedback from the actual fees paid, thus ensuring stable L1 gas collection and spending.

The overall strategy also includes, in order to avoid sequencer overcharging, releasing batches when gas prices are low.

In addition, the differences in architecture and technical details are also discussed, but the content is too domain-specific and not relevant to users and application developers, so you can read it on your own.

The zkEVM Rollup and the entire ZK ecosystem has been really hot lately (Devcon Bogota is basically ZK + MEV + others), so much so that most Ethereum researchers have more or less overlooked the development of Optimistic Rollup and these interesting design details in the second generation.

Optimistic, the leading force in Rollup, is experimenting with pioneering and groundbreaking innovations on L2 UX and DX. What they are doing could lay the groundwork for the zkEVM Rollup.

Until the zkEVM Rollup is fully available in the next two to three years, or even longer, the dominance of the Rollup will remain with Optimistic, and 80% of the new Rollups (App-rollups) will use the more mature and available Optimistic mechanism.

Even after the long-term zkEVM rollup has matured, Optimistic will remain the cornerstone of the system for the overall liveness and safety of the rollup.

The future of rollup is (still) optimistic.

0:

https://hackmd.io/@vbuterin/zk_slides_20221010#/1

https://hackmd.io/@vbuterin/zk_slides_20221010#/7

1:

Arbitrum Nitro: one small step for L2, one giant leap for Ethereum.

Arbitrum Nitro: one small step for L2, one giant leap for Ethereum. The time has come Arbinauts. Arbitrum One has now been fully migrated to the Nitro stack! Ahhhhh! Yes, it's true, Arbitrum One is ...

https://medium.com

https://dev.optimism.io/introducing-optimism-bedrock/

2:

Although Vitalik has identified zkEVM Rollup as the future for several years, and various zkEVMs (Scroll, zkSync, Hermez, Consensys) have sprung up, Optimistic Rollup is still the dominant stack in the Rollup ecosystem, with 80% of the Layer2 market share and half of the top 10 Layer2 solutions.

Will the existence of zkEVM Rollup as the ultimate scaling solution make Optimistic Rollup completely obsolete?

• Optimistic Rollup and zkEVM Rollup are not incompatible, but will be complementary solutions in the long run (even permanently).

• For App-rollup, the Optimistic mechanism is still the simplest and easiest solution to develop and deploy.

According to Vitalik, the zkEVM circuit of the Ethereum Foundation PSE has 34,469 lines of code. That’s a lot of code to polish in a very long period of development and continuous testing. We won’t be able to fully rely on the security offered by the ZK system for several years.

Six months ago, Optimism’s Kelvin started tweeting a lot about the feasibility of combining Optimism with zkVM.

He says Optimism’s Bedrock will not be just an Optimistic Rollup client, but a Rollup client. In order to fully guarantee the overall security of Rollup, the client (perhaps related to Arbitrum’s recent acquisition?) and the diversity of proofs (Validity Proof and Fraud Proof) are the real roadmap for Rollup.

Vitalik has refined Kelvin’s solution, suggesting that a 2 + 1 combination of (OP + ZK) + Governance could be used to achieve a reliable Rollup.

Until zkEVM is fully stable and mature, the workflow is as follows:

1. publish the block

2. wait 24 hours

3. a) If there are no fraud challenges during this period, release the ZKP and fully finalize the block. b) If there are challenges, Governance is introduced to adjudicate the final result through the 2 of 3 model.

After zkEVM is stable and mature:

1. release the block

2. Publish ZKP periodically.

3. a) If the ZKP is released properly during the specified period, it will prevail. b) If the ZKP is not released properly during the period (Prover failure or bug), the Optimistic mechanism is introduced first, until the ZK mechanism is restored.

Both options require the existence of the Optimistic mechanism to ensure the liveness and safety of the entire Rollup system.

Therefore, the development of the Optimistic mechanism is still the vital part of the Rollup universe.

The term “Second-Generation Optimistic Rollup” comes from the title of Arbitrum Nitro’s white paper. The Optimism Bedrock, which was released slightly earlier than Nitro, is also considered a Second-Generation Optimistic Rollup.

The overall difference between the two is not really that big (if you read Arbitrum and Optimism blogs, you might even think they are the same), they are essentially a new major release with themselves. The differences between the second generation and the first generation are just the following optimizations:

• Developer experience: stronger EVM equivalence and compatibility, L1 interoperability…

• User experience: higher throughput, lower gas…

But there are still trade-offs in design details, and we can see in these differences the refinement of Arbitrum and Optimism in building the next generation of Optimistic Rollup.

The developers of Arbitrum and Optimism have compared and contrasted their architectures, and here we will discuss only those points that are relevant to users or dApp developers:

There are two main options for block time design: fixed time or variable time. This can be interpreted as the difference between PoS and PoW Ethereum.

• Optimism: fixed time (2 seconds).

Fixed time ensures the stability of contracts that use block.number to measure the time, such as Sushiswap’s Masterchef contract. These contracts do not use timestamps probably because the miner has control over the timestamp (sort of selfish mining or MEV?).

The first generation of Optimism used a variable time + 1 tx/block design, so there were some problems with Stargate rewards due to its contracts’ time calculation algo.

For the old 1 tx/block design, Optimism considered the overhead of the storage of the blockchain too high due to the block header and the need for frequent updates to the state root too costly.

• Arbitrum: Variable time.

Variable time is designed to reduce the delay of tx confirmation. Currently, up to 4 blocks can be created per second, and skipped if there is no tx, so it is variable time.

For contracts that are timed with block.number, Arbitrum returns the block.number directly from the Ethereum L1 block, so there are no stability or adaptation issues. In addition, Arbitrum also provides a pre-compile to provide L2 block numbers.

Geth is the execution client of Ethereum, which accounts for about 80% of the total number of nodes.

• Optimism: As a standalone engine.

Geth is treated as a standalone execution engine, not a library. The advantage is that it can fully reuse the previous infrastructure, while seamlessly switching to other execution clients.

• Arbitrum: As a library.

Since Arbitrum has more L2-specific features, such as gas pricing for L1 and L2, and retryable tickets, Geth is handled as a library. Arbitrum uses hooks for invocation.

• Optimism: ~2 minutes.

Bedrock’s latency is the length of several L1 blocks, with a worst-case latency of ten minutes.

Bedrock’s architecture is more like an L1, which in extreme cases can cope with L1 reorg by reorging itself.

A tx that is not contained by L2 for more than 10 minutes is simply invalidated.

• Arbitrum: 10 minutes.

Nitro delays processing for 10 minutes, and if it exceeds 10 minutes, it can force tx inclusion via an L1 call.

The goal of Nitro is to make L2 never need to reorg for user experience.

Both are tradeoffs for user experience in different ways.

The message retry mechanism is designed to solve the problem of “L1 confirmed, L2 failed” in L1-L2 messaging.

• Optimism: Implemented in the contract.

Developers can refer to the L1 Optimism Portal implementation, or define their own retry mechanism in the contract.

• Arbitrum: Implemented in the node.

The retry mechanism is implemented in the ArbOS node.

The gas calculation for L2 is basically L2 execution gas + L1 calldata cost.

• Optimism: Reuse EIP-1559.

The benefit is that the wallet and other infrastructure can be seamlessly connected.

Optimism’s calculation of L2 gas essentially minimizes the cost of L2 execution gas (99% of it is calldata cost).

• Arbitrum: Use a custom system.

Due to the variable block time design mentioned earlier, gas pricing is more complex, so EIP-1559 is not used.

• Optimism:

The transmission of L1 gas levels to L2 is almost instantaneous. Currently sequencer’s revenue is basically entirely from the multiplier of L1 gas costs. After EIP-4844, their revenue will come from MEV.

In the future, this data will be transmitted via L1-L2 messaging, thus ensuring security (being part of the protocol and subject to fraud challenge).

• Arbitrum:

Arbitrum’s L1 fee algorithm collects fees by averaging the L1 gas, and uses its own control system to obtain feedback from the actual fees paid, thus ensuring stable L1 gas collection and spending.

The overall strategy also includes, in order to avoid sequencer overcharging, releasing batches when gas prices are low.

In addition, the differences in architecture and technical details are also discussed, but the content is too domain-specific and not relevant to users and application developers, so you can read it on your own.

The zkEVM Rollup and the entire ZK ecosystem has been really hot lately (Devcon Bogota is basically ZK + MEV + others), so much so that most Ethereum researchers have more or less overlooked the development of Optimistic Rollup and these interesting design details in the second generation.

Optimistic, the leading force in Rollup, is experimenting with pioneering and groundbreaking innovations on L2 UX and DX. What they are doing could lay the groundwork for the zkEVM Rollup.

Until the zkEVM Rollup is fully available in the next two to three years, or even longer, the dominance of the Rollup will remain with Optimistic, and 80% of the new Rollups (App-rollups) will use the more mature and available Optimistic mechanism.

Even after the long-term zkEVM rollup has matured, Optimistic will remain the cornerstone of the system for the overall liveness and safety of the rollup.

The future of rollup is (still) optimistic.

0:

https://hackmd.io/@vbuterin/zk_slides_20221010#/1

https://hackmd.io/@vbuterin/zk_slides_20221010#/7

1:

Arbitrum Nitro: one small step for L2, one giant leap for Ethereum.

Arbitrum Nitro: one small step for L2, one giant leap for Ethereum. The time has come Arbinauts. Arbitrum One has now been fully migrated to the Nitro stack! Ahhhhh! Yes, it's true, Arbitrum One is ...

https://medium.com

https://dev.optimism.io/introducing-optimism-bedrock/

2: