Partnered With:

Why Optimistic Rollup 2 is the future of Layer2?

Read this article in 15 Minutes

Optimistic mechanistic development remains the main story in the Rollup universe.

原文标题：《 Foresight Ventures: 第二代 Optimistic Rollup 》

原文作者：msfew，Foresight Ventures

0. Why do we need to look at Optimistic Rollup?

a) OP or ZK?

Even though Vitalik decided that zkEVM Rollup was the future a few years ago and several zkEVM (Scroll, zkSync, Hermez, Consensys) have sprung up, Optimistic Rollup is still the absolute main force of current Rollup ecosystem, with 80% Layer2 market share and half of the top ten Layer2 solutions.

Will Optimistic Rollup be completely eliminated by the existence of the endgame expansion scheme of zkEVM Rollup?

Optimistic Rollup and zkEVM Rollup are not incompatible, but complementary solutions in the long run (even in a permanent time). Optimistic is still the simplest and easiest solution for App-rollup to develop and deploy.

b) OP and ZK are immature

Optimistic Rollup's development schedule is about two years ahead of zkEVM Rollup. However, our Optimistic Rollup benchmark Arbitrum and modernism did not fully open the official version of Fraud Proof on the main network.

According to Vitalik, the Ethereum Foundation PSE's zkEVM circuit has 34,469 lines of code. This huge amount of code requires lengthy development and continuous testing to polish. We won't be able to fully rely on the security provided by ZK systems for several years.

c) OP + ZK

As early as half a year ago, Kelvin who was carrying Optimism began to frequently discuss the feasibility of combining realism with zkVM on Twitter.

He says Bedrock of Optimism isn't just Optimistic Rollup's client, it's the Rollup client. In order to fully ensure the overall safety of Rollup, the client (perhaps related to Arbitrum's recent acquisition?) And Validity Proof and Fraud Proof are the real future of Rollup.

Vitalik improved Kelvin's scheme and believed that a reliable Rollup could be achieved through the 2 + 1 combination of (OP + ZK) + Governance.

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

a) If there is no fraud challenge during the period, release ZKP and Finalize block completely. b) If there is a challenge, Governance will be introduced to determine the final result through the model of 2 of 3.

After the stability and maturation of zkEVM:

a) If ZKP is normally released during the specified period, it shall be subject to it. b) If ZKP is not normally released during the period (Prover failure or bug), Optimistic mechanism is introduced until ZK mechanism recovers.

Both schemes require the existence of Optimistic mechanisms to ensure liveness and safety of the entire Rollup system.

So the development of Optimistic mechanics remains an important part of the Rollup universe map.

1. Optimistic Rollup of the second generation

The term Optimistic Rollup of the second generation is derived from the title of Arbitrum Nitro's white paper. Optimism Rollup Optimism Rollup, which was released slightly earlier with Nitro, is also the second generation of Optimism Bedrock.

The overall difference between the two is not so much (if you read Arbitrum and modernism blogs, you may even think it is the same), which is essentially a new major release. The difference between the second generation and the first generation is no more than the following optimization:

Developer experience: Greater EVM equivalence and compatibility, L1 interoperability... User experience: Higher throughput, lower gas...

However, there are still differences in design details. We can see Arbitrum and modernism in the construction of the next generation Optimistic Rollup.

2. Optimistic Rollup design selection comparison of the second generation

Developers at Arbitrum and Optimist respectively compared and contrasted the architectures of the two, and here we will only discuss the points that are relevant to users or app developers:

a) Block time

There are two main options for block time design: fixed time or variable time. Think of it as the difference between PoS and PoW Ethereum.

Modernism: A fixed time (2 seconds).

Fixed time guarantees stability for contracts that use blocks (block.number) as timestamps, such as Sushiswap's Masterchef contract. Perhaps these contracts aren't time-stamped because miners have control over the timestamp (kind of Selfish mining or MEV?). .

The first iteration of Modernism featured a variable time + 1 tx/block design, which resulted in some issues with Stargate's reward delivery due to timing issues.

With the older 1tx/block design, Modernism attributed the overhead of the storage chain to block headers, as well as the high cost of frequent updates to the state root.

Arbitrum: Variable time.

The variable time design is mainly to reduce the tx confirmation delay. Currently, you can create up to 4 blocks per second, and skip if there is no tx, so it is a variable time.

For the timing contract with block.number, Arbitrum block.number will directly return the Ethereum block number, so there will be no stability and adaptation problems. In addition, Arbitrum provides the corresponding precompilation to provide L2 block numbers.

b) Positioning of Geth

Geth is Ethereum's execution client and accounts for about 80% of the total number of nodes.

Modernism: as an indie engine.

Treat Geth as a standalone execution engine rather than a library. The benefit is full reuse of the previous infrastructure while seamlessly switching to other executing clients.

Arbitrum: serves as the library.

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

c) Delay of L1-L2 message inclusion

Modernism: ~2 minutes

Bedrock's latency is a few L1 blocks, with a worst-case scenario of ten minutes.

Bedrock's architecture is more like an L1, and in extreme cases can respond to L1's reorg by reorg itself.

tx that is not included by L2 for more than 10 minutes is judged to be invalid.

Arbitrum: 10 minutes.

Nitro delays processing for ten minutes, if more than ten minutes, you can force tx to be included via L1 call.

Nitro's goal is to make L2 never need reorg for the sake of user experience.

Both are trade-offs in terms of user experience.

d) L1-L2 message retry mechanism

The message retry mechanism is mainly to solve the problem that L1 confirms and L2 fails in the process of L1-L2 cross-chain.

Realism: Implementation of a contract.

Developers can refer to the implementation of L1 Modernism Portal or define their own retry mechanism within the contract.

Arbitrum: implemented in the node.

The retry mechanism is implemented in the ArbOS node.

e) L2 cost algorithm

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

Optimism: reuse of EIP - 1559.

The upside is seamless access to wallets and other infrastructure.

The calculation of L2 gas with Optimism basically minimizes the cost of L2 execution gas (99% calldata cost).

Arbitrum: Use a custom system.

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

f) L1 cost algorithm

Optimism:

The transfer of L1 gas levels to L2 is almost instantaneous. At present, Sequencer's income is largely derived from the multiplier of L1 gas costs. After EIP-4844, their income will come from MEV.

In the future, this data will be transmitted through L1-L2 messaging to ensure security (to be part of the protocol and to be challenged).

Arbitrum:

The L1 fee algorithm for Arbitrum collects fees through the average value of L1 gas, and obtains feedback from the actual paid fees through its own control system, so as to ensure the stability of L1 gas collection and expenditure.

As part of the overall strategy, batch is released when gas prices are low, in order to avoid over-charging by Sequencer.

In addition, there are a lot of architectural and technical differences discussed, but the content is too domain-specific and irrelevant to users and app developers, so you can watch for yourself.

3. Rollup's future is still Optimistic

zkEVM Rollup and the ZK ecology as a whole have become so popular recently (Devcon Bogota is basically ZK + MEV + others) that most Ethereum researchers have more or less ignored Optimistic Rollup's development, And these interesting design details in the second generation.

Optimistic, as the lead team in Rollup, is conducting experimental pioneering and pioneering innovations on L2 UX and DX. What they do lays the foundation for zkEVM Rollup.

In the next two to three years, or even longer, until zkEVM Rollup is fully available, Rollup's dominant position will continue to be held by Optimistic, Meanwhile, 80% of the new Rollup (App-rollup) will adopt more mature and available Optimistic mechanism.

Even after the maturation of zkEVM Rollup in the long term, there is some P's and P's in order to achieve the overall liveness and safety of Rollup, Optimistic evaluation is still an important cornerstone in the whole system.

Rollup's future remains optimistic.