Translated by LC

Summary

• The role of rollups is to improve L1 scalability while not significantly affecting cost or trust requirements.
• The sophisticated structure of ZK rollup makes it more scalable compared to Optimistic rollup, but there is almost no difference between the two as to costs, and both are unlikely to have impactful problems in terms of trust.
• Though less scalable than ZKR, EVM compatibility and equivalence are significantly easier for optimistic rollups to implement.
• All things considered, OR is likely to grow in the mid-to short-term even if the ZK technology continues to develop.

Introduction

With recent updates to zkEVM development such as Polygon, Scroll, and zkSync, and the possibility of fractal scaling through Starkware's recursive proof, ZK rollups have been garnering most of the attention despite being relatively infant in functionality. During ETHSeoul 2022, Ethereum co-founder Vitalik Buterin projected that ZK rollup would eventually beat Optimistic rollup because the basics of ZK rollup technology would allow it to replace Optimistic rollup entirely. In this article, we dive into the Optimistic rollup's principles, possibilities, and limitations. 

*The article was written assuming readers have a basic understanding of the structure and operation of OR and ZKR. For complimentary reading about the basics of rollups and L2, we recommend “Etherium Layer 2 Solution” and Corbit Research’s “Layer 2 Ecosystem, a Key to Solving the Blockchain Scalability Problem.” 

The Role and Benefits of Rollups

Before diving into rollups' benefits, let’s look at rollups' development intentions. Of the three elements of the blockchain trilemma – security, decentralization, and scalability – scalability on the Ethereum network have been a point of contention. Ethereum’s block times average is at a current level of 12.5 sec with 13 TPS (1M gas per second), indicating a low level of performance compared to other L1 blockchains.

To tackle this issue, Ethereum adopted a different approach called the modular blockchain, in which key functions are segregated into separate layers, enabling L2 to focus on scalability. In other words, rollups are simply methods to increase the scalability of L1. How well rollups perform transaction executions decides their competitiveness.

The two major deciding factors of scalability are:

• Throughput: Speed of transactions per second
• Latency: The time one has to wait until the transaction is finalized

The scalability of blockchain networks is measured based on throughput and latency. One thing to keep in mind is that network maintenance costs should not increase exponentially, and network reliability should not be compromised in the process of improving scalability. Ideally, the cost should increase as linearly as possible with increasing scalability. That is to say that the key to increased scalability is increasing network throughput and lowering latency without sacrificing trust and cost.

Performance: Optimistic Rollup vs Zero Knowledge Rollup

By going through their development history, we came to the conclusion that scalability is the decisive factor that determines the competitiveness of rollups. With that in mind, let’s turn our focus to the scalability of optimistic and zero-knowledge rollups while comparing and evaluating the long-term growth potential of the two. Furthermore, we will compare OR and ZKR in terms of security, one of the components of the blockchain trilemma, and cost, which is an essential element of blockchain mass adoption.

1) Scalability

A. Throughput

Optimistic Rollup (OR): In OR, every data is recorded on the Ethereum network to allow the challenger or verifier to verify the data and challenge the results. In addition, since the maximum number of transactions that OR can support per second, and the transaction cost is proportional to the amount of data that Ethereum can process, the amount of OR's throughput depends on how much it can compress transactions without missing data. As a result, OR projects continue to attempt to compress data in various ways. To facilitate a better understanding of OR, the table below compares the required data capacity when a simple ETH transfer is compressed in a rollup and when it is not. Currently, the gas cost per simple transfer in an OR is about 4k gas per transfer, which translates into 100 TPS. With BLS signature aggregation, which allows many messages created in public keys to be aggregated into a single signature, this number can go up to 500 TPS.

Zero-Knowledge Rollup (ZKR): As previously mentioned, OR has to record every data on the Ethereum network since it uses fraud proofs to detect invalid batches. On the other hand, ZKR uses validity proofs where state transitions occur strictly across valid states, meaning that except for the core data required for state update, any other type of data can be stored off-chain. Simply put, ZKR presents a few benefits over OR in terms of throughput. The realistic throughput cap of the currently released ZKR projects is over 2,000 TPS.

dYdX and Immutable X, both of which are powered by StarkEx, could mislead users that ZKR’s throughput is 9,000 to 10,000 TPS, but these numbers can only be achieved by application-specific ZKRs, and the current smart contract ZKRs has yet to achieve this speed.

Lastly, the level of EVM compatibility is what decides the TPS that can be implemented. ZKR reduces the time it takes to generate proof of validity as EVM compatibility decreases. Most ZKRs, such as ZKSync and StarkNet, use the Type 4 method, which has the lowest EVM compatibility but the fastest generation speed of validation proofs. As the OR projects such as Arbitrum and Optimism are built with EVM compatibility in mind, TPS cannot be the measure of the rollups’ competitiveness. In the later sections, we will investigate the development environment, such as EVM.

B. Latency and Finality

Latency may be an unfamiliar concept, but it is also a very important element in scalability. A transaction becomes irreversible only when it is added to the block through the consensus process of nodes, and speeding up this process is also an important measure of the performance of the blockchain.

OR: OR is finality or hard confirmation because there is a Dispute Time Delay (DTD) or a Challenge Period in which the sequencer executes a state transition that can be challenged is limited to 7-14 days. Arbitrum creates L2 transaction batches about every 5 minutes and sends them to L1 for soft confirmation, leaving a record on Ethereum. However, the changed state root value is canceled if the fraud proof passes within the challenge period. Soft confirmation differs for each OR, because latency (batch size) and cost are inversely proportional. The faster the batch is created, the shorter the delay time, but the frequency of sending to L1 increases that much, and the cost of state commitment increases. Therefore, it is important to properly balance safety and cost for each OR. However, in theory, L2 can create and transmit a batch for every block, and it is expected that the delay time will be reduced as the OR technology is improved in the future.

ZKR: ZKRs have the largest fixed costs of the two rollups due to the validity proof, meaning that batches cannot be generated as often. If batches cannot be sent frequently, you cannot send transactions to L1 as often causing latencies. As a result, ZKR’s soft confirmation is slower than OR (batches are sent to L1 every 3 to 5 minutes). Hard confirmation, however, ZKR is faster than OR since there is a 7-day challenge period. Although it varies depending on the size, ZK-SNARK incur lower costs due to their smaller size, consuming approximately 500k – 1M gas in the EVM. ZK-STARK incur higher costs than SNARKs because of their larger proof size, consuming anywhere from 1M – 5M gas. Therefore, if the demand for block space of ZKR is high (if the actual TPS is high), batches can be generated quickly. However, it will be a while for the ZKR ecosystem to grow and fully develop. At present, the finality of zksync takes about 30 minutes while StarkNet takes about 6 hours.

2) Reliability and Security

All rollups leverage trust and security from L1 by storing transactions in Ethereum to secure DA (Data Availability). However, the mechanism is slightly different depending on the rollup type, and some argue that OR is structurally weaker than ZKR in terms of stability. Before commenting on this, let's first look at the incentive structure of OR and safety measures that are in place to minimize fraud proof that hinders the scalability of OR.

Incentives in OR can be categorized into three main components and the stability is largely dependent on how the following components are set. 

• Fidelity bond: The amount which must be posted on Ethereum by the sequencer (generates transaction batches and L2 blocks). Sequencers' bond is slashed and distributed to verifiers as incentives if fraud is proven. The forfeited bond is slashed and distributed to verifiers/challengers as incentives. Consider it as an insurance measure to prevent sequencers from publishing a fraudulent state update
• Dispute Time Delay (DTD) or Challenge Period:  A period during which a verifier may challenge the output of the rollup. Once the DTD is over, the L2 transaction is considered finalized (disallows roll backs) and safe to be recorded in L1. Choosing a long dispute period over a short one provides better security but at the cost of hindering user experience due to L2 → L1 withdrawal delay. Although there is no right answer as to how long the challenge period should be, the Arbitrum team proposed a model to calculate the optimal challenge period and the calculation suggests a 7-day window is the optimal dispute period (refer to the image below).

• Fraud Proof: An indication that the sequencer has pulished an invalid state transition. If a fraud is suspected, any party can publish a fraud proof to challenge the sequencer. Fraud proof is categorized into i) single-round interactive proving and ii) multi-round interactive proving depending on the number of communication.
  • Single-round interactive proving: Single-round interactive proving schemes replay disputed transactions on L1 to detect invalid rollup blocks. The rollup protocol emulates the re-execution of the disputed transaction on L1 using a verifier contract, with the computed state root determining who wins the challenge. If the challenger's claim about the rollup’s correct state is correct, the operator is penalized by having their bond slashed. Though this method is fairly simple, it increases the data rollups that must be published on-chain and incurs significant gas costs. For these reasons, ORs are switching to multi-round interactive proving.
  • Multi-round interactive proving: Unlike single-round, multi-round interactive proving involves a back-and-forth protocol between the sequencer and challenger overseen by an L1 verifier contract, which ultimately decides the lying party. When challenged, the sequencer is required to divide the disputed rollup block into two equal halves. The dividing process (called a “bisection protocol”) continues until the winner is decided. This method is considered efficient as it does not replay the entire transaction and minimizes the data to be stored on-chain.

OR’s incentive model assumes at least one honest node among n number of nodes will keep the system intact. On the other hand, ZKRs validate every transaction from the start, indicating that its structure alone offers security advantages over ORs. Contrary to the beliefs of the many, I believe the crypto community is overly concerned with OR’s security vulnerabilities. 

Arguments Over OR’s Stability

A. Verifier’s Dilemma

Ed Felten suggests OR can suffer from the Verifier’s Dilemma as described below:

• If the system’s incentives work as intended, nobody will cheat.
• If nobody cheats, then there’s no point in running a verifier because you make no money from operating it.
• Since nobody runs a verifier, there’s eventually an opportunity for a sequencer to cheat.
• The sequencer cheats, the system no longer functions as intended.

Felten’s verifier’s dilemma sounds plausible. In fact, adding more verifiers doesn’t help to prevent cheating, it would make things worse. As you add more verifiers, they would need to worry more about having to split the incentive multiple ways, reducing the expected payout for an individual verifier.

However, Paradigm’s research partner Georgios Konstantopoulos points out that the verifier’s dilemma is not to be concerned because in practice, the parties involved with OR (i.e., onboarded projects and rollup token holders) are likely to run validator nodes for the betterment of their service offerings and to increase the token value, regardless of the monetary incentives. For instance, in large dApps that run on Arbitrum, such as GMX, Stargate, and Synapse, users will run validator nodes to keep the system running rather than to gain monetary incentives. If you are a large Optimism token holder, you would also participate as a verifier so that your token value would not be reduced. OR system will sustain as long as there is a single honest verifier, and these non-monetary incentives will keep the OR system safe. The fact that OR has never been hacked also proves that the system is secure.

B. Centralized Sequencer

Given that the technology is still at an infant stage, almost every OR, including Optimism and Arbitrum, is centralized for security reasons. A centralized sequencer involves two worst-case scenarios: i) when the sole sequencer shuts down and ii) when the centralized sequencer attempts to publish an invalid state transition. As for the first scenario, the L2 mainnet will shut down, but since the entire rollup data has been stored on Ethereum, a different sequencer can download the L2 data to reproduce the L2 state and continue block production. Though the mainnet operation may be suspended temporarily, all data that had been confirmed before going offline are preserved. As for the remaining scenario, it is highly unlikely for the sequencer to publish a fraudulent state update because service providers would not want their system to fail. Even if the sequencer acts maliciously, validators/challengers will always be on standby as described in the validators’ dilemma. According to the planned roadmap releases by Optimism and Arbitrum, both plan to decentralize their sequencers over time. Arbitrum is currently working with a team at Cornell Tech to develop decentralized fair sequencing algorithm while Optimism is developing a sequencer rotation mechanism.

3) Rollup Fee

Rollup transaction fees follow the below process and fee structure:

1. The sequencer receives and orders transactions. L2 users will soon be able to get soft confirmations through the sequencer’s feedback.

2. A deterministic state transition function processes each transaction and updates the L2 state, creating an L2 block. These blocks can be generated faster than L1 blocks. Users are charged L2 gas when applying state transitions. 

3. Every so often a batch of transactions is compressed and sent to L1. Currently stored as calldata, but eventually Rollups will use data blobs. L1 gas is paid later when batch transactions are processed.

Users are charged L2 gas when applying state transitions and executing their transactions. L1 gas is paid later when batch transactions are processed. The sequencer commits to the transaction and collects the L2 fee before it knows the full content of the batch transaction, how compressed it is, or what the base fee for L1 is when it is published. Rollup can pay Ethereum a larger fee to settle many transactions than a single user would pay for an L1 transaction occupying the same block space. L1 and L2 gas prices vary according to their respective congestion conditions. Two costs (gas fees) are associated with publishing transaction batches: fixed cost and variable cost. 

Note:

• The L1 base fee is 21,000 gas, but for rollups, the base fee is amortized over many transactions.
• Calldata cost = Size of transaction batch*16 gas/byte

As mentioned previously, ORs keep track of all the L2 transaction data, including L2 state root and fraud proof. At the same time, ZKRs only store state transitions in Ethereum’s history to reduce cost (for clarity, refer to the Lightning Network). OR should be compared using transaction data recorded on L1 for verification purposes. In other words, ZKR provers generate validity proofs that attest to each batch, which require computing many cryptographic commitments to generate, incurring a high fixed cost. However, this cost is still cheaper than OR as the cost of transactions written on L1 as calldata is too high. Meanwhile, with Optimism's Bedrock being adopted, transaction fees will reduce from 280,000 gas (excluding calldata cost) to 21,000 gas per batch, lowering the fixed cost significantly. At the same time, OR’s variable cost (calldata) will be cut down by a wide margin in the future as there is an ongoing effort by L2 projects to develop data optimization technologies, including data compression, integration, and calldata compression. The cost will further decrease when a new transaction format for “blob-carrying transactions” is introduced after the Surge upgrade. In the end, the cost difference between OR and ZKR is expected to be minimal. Even if there is a difference in cost, it will be between $0.01 and $0.1, indicating that users will focus on the architecture and not choose one over the other based on cost. The cost breakdown of OR and ZKR is shown below.

Other Areas to Consider

1) The Challenge Period is 7 Days, but Faster Withdrawal Service is Available via Market Maker  

In ZKR, the creation time of the validation proof is final, so users can transfer assets from L2 to L1 in a few hours at most. Also, in case of emergency (when the sequencer stops or acts maliciously), there is an escape hatch that supports forced withdrawal. On the other hand, OR users have to wait until the challenge period ends (it takes about 7 to 14 days) to withdraw, offering poor user experience compared to ZKR. For this reason, some argue that OR will not be chosen by users when ZKEVM is released. However, I think this is a rather unconvincing argument. In the OR ecosystem, there are market makers (MMs) that support immediate withdrawal service among validator nodes that monitor L2 state, and users can withdraw faster than ZKR through this service. The concept first appeared in the article “Simple Fast Withdrawals” by ETHresearch. For example:

1. Alice has 1 ETH on the Arbitrum and wishes to quickly withdraw to purchase a NFT.

2. Bob, a validator node on Arbitrum has 0.95 ETH on L1 market maker (MM) smart contract.

3. Alice promises to pay 0.005 ETH as a fee to Bob and makes a withdrawal request.

4. Bob would encounter one of the following situations:

• Bob checks that the withdrawal is valid on his L2 verifier and approves the fast withdrawal. This transfers 4.95 ETH to Alice's L1 address instantly. Bob will be able to claim the 5 ETH after the withdrawal period is over, netting a nice profit.
• Bob’s L2 verifier alerts him that this transaction is not valid. Bob disputes the state transition caused by that transaction, canceling it and earning the sequencer’s bond for allowing the malicious transaction to happen.

Bridges support MM services in general. Users using bridges such as Hop Protocol or Stargate would have experience transferring funds via OR directly to the Ethereum wallet. The additional costs may be a bit of a hassle for users but would not significantly affect user experience as faster withdrawal service is available via MM.

2) OR’s EVM Compatibility Makes It a Better Environment for Developers

It is also worth noting that OR's development environment is better established than ZKR's. Optimism and Arbitrum already provide general-purpose rollup solutions with a high level of EVM compatibility and a well-established development library. Thanks to this rollup-friendly development environment, it is relatively easy for projects to develop or migrate dApps via OR.

On the other hand, the general-purpose ZK solution is still under development as the ZK technology is very complex and in the early stages of research. The fact that EVM itself was initially developed without having ZK technology in mind also contributes to development challenges. For this reason, only the application-specific ZK rollups have been publicly released, and most ZKVMs that can deploy smart contracts are scheduled to be launched at the end of this year at the earliest. Of course, StarkNet has already released an alpha version, but being relatively infant in functionality, it is yet to be fully trusted. There have been many "ZK-EVM" projects such as Polygon, ZKSync, and Scroll making announcements recently. Most of the ZKRs currently being developed are the Type 4 (high-level-language equivalent), which is one of the four types of ZK-EVMs introduced by Vitalik Buterin. A Type 4 system works by taking smart contract source code written in a high-level language and compiling that to some language explicitly designed to be ZK-SNARK-friendly, but it has the lowest EVM compatibility. It is expected that it will take another 2 to 3 years for the Type 2 ZKEVM to be released. Of course, EVM compatibility is not the only measure for determining the competitiveness of the development environment, but it is true that there are overwhelmingly many Ethereum developers in the Web3 ecosystem. From this point of view, ZKR will be able to attract more developers only when it offers a development environment similar to EVM. 

Interestingly, Starkware launched its own VM for the Cairo language rather than focusing on EVM compatibility. Of course, Starkware is also preparing “Warp,” a service that converts the written Solidity code to Cairo code with the EVM developer ecosystem in mind. However, they saw it more important in the long run to break away from EVM and establish a development environment optimized for ZKR. "After all, all DApps will be on-boarding on L2 in five years, so will EVM still be important?" they argue.

3) OR’s First-Mover Advantage

Contrary to the steadily growing OR that launched its mainnet a year ago, ZKR has not yet publicly released a solution to implement smart contracts. It is thus not surprising that the OR ecosystem is larger by a wide margin. According to L2Beat, the total TVL of L2 is about $5B as of Aug 29, 2022. Out of the total TVL, Arbitrum and Optimism account for $2.51B and $1.58B, respectively, translating into 49% and 31% of the L2 market share, respectively. However, when adding up the TVL of all application specific ZKRs, the total comes to less than $1B. Looking at Unique Active Wallets (UAW), Arbitrum and Optimism reached 1.1M and 1.4M, respectively, and the daily transaction count has also been steadily rising, both exceeding 100,000 in recent days. Also, Arbitrum and Optimism have already onboarded more than 80 and 50 DApps, respectively.

On the other hand, ZKR will not release Type 4 ZKEVM until the end of this year or next year and will have to wait two to three years for a highly EVM-compatible Type2 ZKEVM to be released. On top of that, it will take additional time for developers to launch services, gain users' trust and expand the services. In the meantime, OR will continue to attract users and bring scale to those dApps that cannot yet be built on ZK Rollup today while making the system more mature. OR’s first-mover advantage will be a challenge for ZKR to catch up. With an ecosystem in place, OR has more options going forward. OR has in fact, spoke about a strategy to possibly switching to ZKR in the future.

Conclusion: Optimistic Rollup will Remain a Viable Candidate Even After ZK Rollup Is Fully Developed

The rollup’s competitiveness comes from its role in improving the scalability of L1 without sacrificing the trust and cost of the network. With that in mind, we compared OR and ZKR while examining these factors. We see that scalability will give the ZKR a clear advantage in the coming days, while the cost will not differ significantly between the two rollups. In terms of trust, OR, which assumes that at least one of the n nodes will behave honestly, may not be structurally advantageous to ZKR, of which proofs can be guaranteed with mathematical proof per batch. Still, the structure of OR is unlikely to be problematic as it relies heavily on game theory. This is evidenced by the fact that Arbitrum or Optimism have been running the mainnet for about a year and have never been hacked. In addition, we checked the possibility of OR by looking at three other factors that could affect the competitiveness of rollups. We concluded that the FUD surrounding OR was somewhat excessive and that it could build sufficient competitiveness with EVM compatibility and also by having the fast-mover advantage. In that sense, OR is likely to grow, at least in the mid-to short-term, even if ZK technology continues to develop. Furthermore, as Optimism is concerned, there is a way first to grow the ecosystem to build network effects and then slowly switch to ZKR, so there is no reason to be pessimistic about OR due to ZKEVM, which has yet to be released.