Why is it said that Optimistic Rollup better represents the future of Ethereum scalability than ZK Rollup?

Source: Offchain Labs

Compiled by: James, Chain Catcher

Will ZK Rollups be the future of general-purpose smart contract systems? We seem to have heard too much discussion on this topic. However, based on our practical experience from running hundreds of DApps, serving hundreds of thousands of users, and processing millions of transactions on an open, secure, and EVM-compatible Layer 2, ZK Rollups will not become the general-purpose smart contract system. This article will explain the reasons in detail.

We built Arbitrum as an Optimistic Rollup (OR) scaling solution because we believe that Optimistic Rollup is the best way to meet users' real needs for security, trustlessness, and EVM-compatible L2. We chose Optimistic Rollup over ZK Rollups because Optimistic Rollup systems have inherent scalability and cost advantages; to this day, if we were to make the choice again, the answer would still be Optimistic Rollup. Want to know why? Please keep reading.

Content Overview:

1. People want a trustless blockchain that provides security, guaranteed progress, visibility, and fast finality—they want the transaction costs on this blockchain to be lower and compatible with existing tools.

2. While providing the above services and functionalities, we have delved into the specifics of how to use Optimistic Rollup compared to ZK Rollup.

3. Optimistic Rollup can provide the desired functionalities at a lower cost because the off-chain cost of constructing ZK Rollup proofs is very high.

4. Due to the high cost of ZK proofs, fully participating in ZK protocols may require specialized hardware and/or large-scale parallelism, making the network more centralized.

5. The so-called "advantages" of ZK Rollup can either be supported by Optimistic Rollup or require sacrificing important security or usability features.

6. In summary, Optimistic Rollup has an operational cost advantage because executing code is "much cheaper" than computing complex cryptographic proofs.

Let’s Start from the Beginning

First, we must talk about Ethereum. Ethereum users create transactions to deploy smart contracts or interact with them, and you can consider Ethereum transactions in several different ways. On one hand, you can view them as opaque data blocks, but if you look at the data content, you will find that a transaction is certainly much more than that; what we call a transaction is actually a request for a smart contract to do something, such as recording some information, moving some assets, etc.

When a transaction is published on the Ethereum blockchain, two important things happen------

The first thing: Once a transaction is included in the blockchain, Ethereum reaches consensus based on the ordered set of transactions.

The second thing: Ethereum executes these transactions and computes the resulting state updates.

Rollups: What Do Optimistic Rollup and ZK Rollup Have in Common?

If every Ethereum node were to execute every transaction, the costs would inevitably be very high, and Rollups are actually a class of scaling solutions that can significantly reduce network load, with the actual execution of transactions not being completed on the Ethereum blockchain but rather moved to Layer 2 ("L2").

But wait -- Rollups should be secured by Ethereum, right? Indeed, the security of these scaling solutions relies on Ethereum, which means that even if transactions occur on Layer 2, we still need Ethereum to somehow guarantee the correctness of transaction execution. So how can Ethereum approve the state of Rollups?

The answer is: proofs. Rollups use specialized proofs to demonstrate their correctness to Ethereum, allowing Ethereum to verify their correctness even without executing the transactions.

Rollups: What Are the Differences Between Optimistic Rollup and ZK Rollup?

These "proofs" seem magical: they allow Ethereum to verify the state of Rollups without actually executing the transactions. You may wonder what these proofs look like and how they are implemented in practice—this is where the various styles of Rollups differ.

ZK Rollups use validity proofs, which rely on a party publishing a succinct cryptographic proof that can confirm that the party knows the validity of the blockchain ending in a specific state. In other words, the "party providing the proof" needs to execute blockchain transactions to know how to construct the proof, and then construct the "proof" through a series of complex cryptographic operations. These "proofs" will be checked by contracts on Layer 1. ZK Rollups' "proofs" are relatively succinct, and verifying transactions is also relatively inexpensive, so it can be done directly through Ethereum transactions.

Optimistic Rollups use a different type of proof: fraud proofs. As the name suggests, Optimistic Rollups are "positive and optimistic" because when they publish the updated state to the Ethereum blockchain, they do not publish any "proofs" at all. Anyone can publish a Rollup block containing a claim about the correct result of executing a transaction, and when other nodes execute the same transaction, they can challenge the claim if they disagree with the first node's assertion. A valid dispute protocol can resolve any disagreements, ensuring that the correct party will win the challenge. Parties have a strong incentive to only publish correct claims rather than challenge incorrect ones, so in common cases, all nodes will "simply" execute all transactions and never need to call proof code—the entire process is managed by Layer 1 contracts.

So, which type of Rollup is better? In the remainder of this article, we will compare ZK Rollup and Optimistic Rollup across several dimensions and explain why we believe the future belongs to Optimistic Rollup, and fundamentally, scalability like Arbitrum's Optimistic Rollup is clearly better.

Optimistic Rollup vs. ZK Rollup: Cost

One of the most important differences between Optimistic Rollup and ZK Rollup may be cost.

Optimistic Rollup requires nodes to simply execute contracts; for example, if the contract executes an addition operation, the node performs that addition.

In contrast, ZK Rollup requires generating complex cryptographic proofs, necessitating hundreds or thousands of elliptic curve operations to include the addition operation in the proof, resulting in high costs. More importantly, ZK Rollup incurs costs for every instruction in each contract, as complex cryptographic proofs need to be generated for each instruction, not just for executing instructions, which brings an inherent cost disadvantage to ZK Rollup—and it is a significant disadvantage.

Supporters of ZK Rollup sometimes argue that the solution only requires one party to create a "proof," while Optimistic Rollup requires many nodes in the system. However, if you are running a large-scale blockchain, regardless of which proof system you use, there will be many nodes. A real blockchain needs many nodes to serve various activities, such as non-mutative calls, searching event logs, displaying transaction data to users, and providing users with the data needed to withdraw funds back to Layer 1, etc. The security of an Optimistic Rollup blockchain relies on these nodes doing what they already need to do—executing transactions and tracking the correct state of the blockchain.

On the other hand, using ZK Rollup leads to expensive, elliptic curve-based proofs, which incurs significant additional costs. To hope to scale ZK Rollup, either specialized hardware is needed, or support for large-scale parallelism—or both, which are very expensive.

Conclusion: Optimistic Rollup systems have a significant inherent cost advantage.

Optimistic Rollup vs. ZK Rollup: EVM Compatibility

An important consideration when building Arbitrum was compatibility with the Ethereum Virtual Machine (EVM). Arbitrum is fully compatible with EVM, has the same RPC interface, and accepts the same bytecode as EVM, meaning any code written for Ethereum can be "plug-and-play" on Arbitrum.

Optimistic Rollup has been running open, EVM-compatible blockchains (including testnets) for over a year, and we have learned that true compatibility with Ethereum is very challenging. Achieving 95% compatibility in the initial stages is not too difficult, but in practice, it is not good enough; only through significant effort and building an architecture that does not hinder the product can compatibility perform better.

In terms of compatibility, ZK Rollup systems have a wide range of operations. However, some believe ZK Rollup is an "old-fashioned" tool because they still encourage people to learn their custom languages. Additionally, some ZK Rollup systems do not attempt to be compatible with Ethereum, which is fine for developers and users who do not care about Ethereum compatibility.

Objectively speaking, EVM is arguably the best on-chain tool ever. We believe that considering the number of developers, code, and developer tools that have already been used with EVM, EVM itself has a significant practical advantage. Consider a project deployed on Ethereum; if that project wants to scale to Rollup, developers must rewrite their code in a new language, commission new security audits, and maintain multiple codebases, which is not only cumbersome but also prone to errors. But even for new projects that have not yet written any code, EVM compatibility is very important because being compatible with EVM means these projects can fully leverage the code, tools, and talent pool that exist around EVM.

Some ZK Rollup projects are working hard to achieve EVM-compatible versions, but the statements are vague, and we do not know whether the code released so far allows EVM contracts to run on ZK Rollup; some systems still lack EVM compatibility. For example, a ZK Rollup system that claims to be EVM compatible ++system++ has poor actual compatibility, as this system------

• Fails to achieve compatibility with ADDMOD, SMOD, MULMOD, EXP, SELFDESTRUCT, and CREATE2 opcodes;
• Is considering dropping support for XOR, AND, and OR;
• Does not support standard transaction formats;
• Does not support any precompiles;
• May limit the number of contract calls in transactions.

It seems that the ZK Rollup model is fundamentally incompatible with EVM, which is clearly a significant gap compared to the complete compatibility achieved by Optimistic Rollups.

It should be clarified that there are still several application-specific ZK Rollup system examples (such as Zcash, ZKSync 1.0, Loopring). In fact, these systems work well, but the core difference is that they are fine-tuned and specifically optimized for certain applications that are very suitable for ZK Rollup implementation. While some teams claim to be researching a universal compiler that allows for a compatible "bridge" from EVM to ZK Rollup, there is no publicly available code or benchmarks to indicate the proof costs of user-defined ZK-EVM contracts; based on existing knowledge and all publicly available data, we believe this cost will be very high.

Conclusion: Only Optimistic Rollups support full EVM compatibility at the lowest cost.

Optimistic Rollup vs. ZK Rollup: Trustless Visibility and Compression

One of the key attributes of Optimistic Rollups when designing transaction arbitrage is trustless visibility. In short, trustless visibility means that anyone can view or access the contents of the blockchain without the help of a centralized organization. More importantly, this does not just mean that everyone can occasionally see state snapshots—it also means that everyone can see the complete history of the chain—how it reached its current state. A practical blockchain allows anyone to run a node, while the node can also support non-mutative calls, search event histories, and view each transaction—without relying on centralized data providers, and trustless visibility makes this possible.

Frankly, some ZK Rollup systems seem to have taken shortcuts in visibility and try to talk about the fact that they do not provide complete blockchain functionality. When you hear discussions about "compression," think carefully—are they saying they are encoding the contents of the chain more efficiently? (Arbitrum does this, and will do it better in our Nitro version) or are they saying that certain parts of the blockchain history are simply unavailable unless a centralized data provider is willing to share them with you later?

Recall that ZK Rollup proofs only prove that the "prover" knows a valid chain, but the "proof" itself does not tell you what that chain is; even if you have enough data to verify the "proof," there may not be enough data to reconstruct the historical data of the blockchain.

For example, suppose Alice submits a transaction to pay Bob 1 ETH, and soon after, Bob submits a transaction to pay Charlie 1 ETH. Next, you need to verify a proof that states: Alice has 1 ETH less than before, Bob's balance has not changed, and Charlie has 1 ETH more than before.

But what happened? Did Alice pay Bob? Did Bob pay Charlie? Maybe Alice paid Charlie directly, or maybe Alice burned one ETH, and the 1 ETH that Charlie received was paid by someone else, perhaps that "someone else" is named Diana, not Bob. If we look for evidence of Bob's payment in the blockchain, it may be impossible to distinguish and find Bob's payment transaction for some ZK Rollups that do not provide blockchain visibility.

What many smart contract applications need is not just to know a few checkpoints, but to understand the entire chain—what happened and how the final state was reached. ZK Rollups sometimes boast better "compression" than Optimistic Rollups, but they hide the data of the blockchain, which means only the "prover" knows the data is not compressed; they may even delete crucial data. If ZK providers say they "do not need" to publish the entire history of the blockchain, what they really mean is that they cannot guarantee the visibility of the blockchain, and giving up the guarantee of blockchain visibility is not a compromise that Optimistic Rollup is willing to make.

Conclusion: Optimistic Rollup systems can provide trustless visibility at the lowest cost.

Optimistic Rollup vs. ZK Rollup: Trustless, Timely Finality

When evaluating Rollups, we need to determine a key requirement: does the Rollup need to provide trustless, timely finality? Simply put, this means that after you submit a transaction, you and everyone else should know the result of that transaction promptly and definitively, and no one can change or revoke that transaction.

In our view, the best way to achieve timely finality is to separate the ordering of transactions from their execution. Ordering produces a final proposed transaction sequence, and attempts to execute transactions according to that sequence. If the execution of transactions is deterministic, as it is based on Arbitrum, then determining the order of transactions is sufficient to determine the result, as the result is a deterministic function of the transaction order. If everyone knows the order of transactions, then everyone can easily determine the result.

Completing a sequence requires publishing the sequence to the Layer 1 chain and including enough information to allow anyone to execute the transactions themselves, so they can understand the result without trust. Ideally, the aggregator should publish the ordered transaction data to the Layer 1 chain as frequently as possible.

In Optimistic Rollup systems, the cost of publishing to the Layer 1 chain is minimal; in fact, Arbitrum typically publishes ordered transaction data to the Layer 1 chain every minute or so, providing users with fast finality and ensuring that no one can revoke their transactions. Additionally, Arbitrum generates a new Optimistic Rollup result assertion approximately every hour, but since the sequence has already been finalized and execution is deterministic, it does not slow down the speed of finality at all.

In principle, ZK Rollup systems could also operate in a similar manner; that is, separating the ordering of transactions (which can be frequently published to Layer 1) from later verification and occasional validity proofs. However, like the data published by Optimistic Rollup systems, ZK Rollups operating in this way need to publish essentially the same data to the Layer 1 chain, but the aforementioned (so-called) "compression" techniques do not support this. For "compression" techniques to work, ZK Rollups must prove the validity of a series of Layer 2 transactions in real-time within the same Layer 1 transaction, and they must do this every time a batch of Layer 2 transactions is published.

Therefore, while the so-called "compression" techniques are highly touted by ZK Rollups, when faced with the above situations, they have to make two choices:

1) Publish ordered transactions and execution proofs approximately every minute: this can maintain fast finality but requires generating ZK proofs off-chain every minute and verifying them on the Layer 1 chain. Depending on the implementation, the cost of publishing ZK proofs on-chain is estimated to be between 500,000 and 5 million gas.

2) Publish ordered transactions and proofs every hour: while this approach can make the costs of checking ZK proofs slightly more reasonable, it extends the finality time to an hour. During the time between when users submit transactions to ZK Rollup operators and when they are published on the situation chain, users cannot guarantee whether their transactions will be included and can only trust the ZK Rollup operators.

If you are building a ZK Rollup system, you will find that both of the above options are actually unacceptable—the first is too expensive, and the second cannot provide timely finality. Therefore, if the same type of sequencer will ultimately be used, the ZK Rollup version of Arbitrum will need to publish essentially the same data as our Optimistic Rollup version.

If you hear someone bragging that ZK Rollup can compress hours of data into a single point, do not worry. If they only publish single-point data at the end of a long period, it means they have not provided finality during that time.

Conclusion: For practical reasons, ZK Rollup systems have to handle real-time finality in the same way as Optimistic Rollup.

Optimistic Rollup vs. ZK Rollup: Trustless Liveness

Trustless liveness means that anyone can force the system to make progress. (The trustless security properties can ensure that progress is correct.)

Optimistic Rollup allows any node to declare that a transaction has been executed correctly; making that declaration only requires the node to execute the chain's transactions and then deposit a stake that can be refunded after the protocol confirms the declaration.

In ZK Rollup systems, the process requires any node to create and publish the ZK proof necessary to advance the blockchain state, but not everyone can achieve this with ordinary hardware and software. Therefore, to complete ZK proofs, specialized hardware must be built or purchased, and large-scale parallel computing is required. Even on ordinary devices, a suitable path for building ZK proofs needs to be constructed; ZK providers that do not provide this functionality or have not released code to generate proofs for their systems cannot provide trustless progress, and the system has no guarantees of liveness. In other words, ZK Rollup systems are centralized because only provers with specialized equipment can drive progress. (It is currently unclear whether leading ZK Rollup providers will provide viable proofs for ordinary users.)

Conclusion: It is easier to provide trustless progress in Optimistic Rollup systems.

Optimistic Rollup vs. ZK Rollup: Bridging

Of course, ZK Rollup is not without its advantages; it has a significant edge in one area: Ethereum cross-chain connectivity. When funds are transferred to Layer 1, Optimistic Rollup systems will experience a delay of about a week, while ZK Rollup allows bridging to be established immediately after ZK proofs are published to Layer 1. However, fundamentally, there is not much difference between the two methods, as Optimistic Rollup can also allow users to quickly utilize bridging services to exchange Layer 2 funds for Layer 1 funds with low latency. Thus, the advantage of ZK primarily lies in users being able to avoid paying the small fees charged by cross-chain bridging services (which has some competitive pricing). But in practice, Optimistic Rollup performs quite well, as there are currently many real-time fast cross-chain bridges providing instant withdrawal services from Arbitrum.

It is important to emphasize that the bridging advantage of ZK Rollups is not very significant: because it can only be used to bridge back to Ethereum from Layer 2. Once upon a time (around 2019), many believed that Ethereum scaling solutions would not emerge quickly, perhaps only one or two DApps would be slowly rolled out. However, in practice, Rollup users find themselves needing to switch back and forth between Layer 1 and Layer 2, which ZK Rollup cannot support; in contrast, Arbitrum has a thriving ecosystem with hundreds of DApps spread across every corner of the DeFi space, and many users are connecting to Arbitrum and staying there long-term. Additionally, in providing cross-chain support for users, Arbitrum not only supports Ethereum but also connects with other Layer 1s and sidechains; for this direct bridging, ZK Rollups do not have as much of an advantage as Optimistic Rollups.

Conclusion: ZK Rollup systems have a slight advantage in bridging to Layer 1, but in terms of fast bridging and multi-chain usage patterns, the practical application of ZK Rollup is not as good as expected.

Summary

After a comprehensive comparison of Optimistic Rollup and ZK Rollup systems, we believe that Optimistic Rollup systems are clearly the winners. Optimistic Rollup has lower costs, is fully compatible with EVM and existing tools, and the only real drawback in practice is the slower bridging speed to Layer 1 without fast cross-chain bridging services. Many of the assumed advantages of ZK Rollup require sacrificing blockchain visibility or finality time, which we believe is not what users want.

Moreover, it seems unlikely that ZK Rollup will make changes. ZK proofs for executing EVM-compatible contracts will still be much more expensive than executing Optimistic Rollup, and ZK Rollup will also struggle to meet the requirements for guaranteed progress, blockchain visibility, and decentralization. If the situation changes, we would be willing to switch Arbitrum to ZK Rollup-based transaction execution, but we believe they will not make optimized changes.

Finally, it is worth mentioning that people tend to compare what Arbitrum currently offers with what ZK systems claim they will provide in the future, but this comparison is meaningless because we should compare with existing systems. Scaling solutions like Arbitrum's Optimistic Rollup are the only open deployment systems that support general-purpose smart contracts. Or, if we are to compare future systems, we should compare future Arbitrum with future ZK systems.

We are continually improving Arbitrum; for example, in our upcoming Nitro version, we will provide users with lower transaction costs and better on-chain optimized lossless compressed data. Moreover, we are tirelessly working to improve transaction arbitrage and reduce costs to theoretical limits. As we have analyzed in this article, we believe that when considering the two existing systems and their respective theoretical limitations, Optimistic Rollups are clearly the true winners.