Optimistic Rollups: The Present and Future of Ethereum Scaling

Original author: offchain labs

We hear a lot of talk these days about how ZK Rollup is considered to be the future of general-purpose smart contract systems. And we disagree — and this article explains why. It builds on the practical lessons we have learned from running an open, secure, EVM-compatible L2 chain with hundreds of dapps, hundreds of thousands of users, and millions of transactions.

We built Arbitrum as an Optimistic Rollup (OR) because we believe that OR is the best way to meet users' real-world needs for a secure, unconditionally trustworthy, EVM-compatible L2. We chose Optimistic Rollup over ZK because of the inherent scalability and cost advantages of the system; we would still make the same choice today. If you want to know why, read on.

Michael Johnson - originally posted to Flickr as apples and oranges - they don't compare, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=4289506)

etc! How long is this post?

Yes, this post is long and somewhat technical in places. What people want from on-chain is simple, but talking about the technology needed to deliver these advantages requires us to delve into some details. We hope the technical community understands our point of view.

If you don't want to read the whole article, here's a brief outline.

1. People want a chain that can be trusted unconditionally to provide security, guaranteed progress, visibility and fast properties - and they want low cost and compatibility with existing tools.

2. Compared with ZK Rollup, we delved into the details of how to use Optimistic Rollup to provide these properties.

3. Since the off-chain cost of ZK is very high, Optimistic can provide the attributes users want at a lower cost.

4. Since ZK proofs are very expensive, full participation in the ZK protocol may require special-purpose hardware and/or massive parallelism, making the network effectively more centralized.

5. The advantages claimed by ZK either apply to the Optimistic Rollup system, or require sacrificing important security or usability features.

6. Optimistic Rollup wins in terms of operating costs, because executing code is much cheaper than computing complex cryptographic proofs.

start from scratch

Let's start with Ethereum first. An Ethereum user creates a transaction to deploy or interact with a smart contract. You can look at Ethereum transactions in a few different ways. On the one hand, it can be thought of as opaque data. But if you look at its content, a transaction is of course much more than that; it's a request for a smart contract to do something: record some information, move some asset, etc.

When a transaction is posted on Ethereum, two important things happen. First, it is included that Ethereum achieves consensus on a set of ordered transactions. Second, Ethereum executes these transactions and computes the resulting state updates.

Rollup: What Optimistic and ZK have in common

Having every Ethereum node execute every transaction is expensive, and Rollups are a class of scaling solutions that can significantly offload this load. The actual execution of the transaction is not done on Ethereum, but is moved to the Layer 2 (“L2”) area.

But wait - Rollup should be guaranteed by Ethereum. This means we need Ethereum to somehow guarantee the correctness of transaction execution, even if it happens on L2. So, how did Ethereum get its stamp of approval to rollup status?

In short, the answer is: proof. Rollup uses a proprietary proof to prove its correctness to Ethereum, which can be verified even without executing the transaction.

Rollup: the difference between Optimistic and ZK

These proofs seem pretty magical: allowing Ethereum to verify the Rollup state without actually executing it. You might be wondering what these proofs look like and how they are implemented in practice. This is where the various Rollups are different.

ZK Rollup uses proof of validity. ZK relies on a party issuing a succinct cryptographic proof that the party knows of a valid chain that ends in a particular state. This requires the verifier to execute the chain so that it knows how to build the verification, and then builds the verification by performing a series of complex cryptographic operations. The proof is checked by the L1 contract on-chain. ZK proofs are succinct, and verification costs are cheap enough to be done with Ethereum transactions.

Optimistic Rollup uses a different type of proof: a fraud proof. As the name suggests, Optimistic Rollups are optimistic, and when they publish an updated state to Ethereum, they don't have to publish any proofs at all. Anyone can publish a Rollup block that contains claims about the correct outcome of executing certain transactions. Other nodes perform the same transaction and can issue a challenge if they disagree with the first node's claim. An effective dispute protocol can resolve any disagreements, guaranteeing that the correct party will win the challenge. All parties have a strong incentive to only issue correct claims and not challenge false ones, so in the usual case all nodes simply execute all transactions and never need to call the proof code. The whole process is managed by the L1 contract.

Ok, so which type of Rollup is better? In the following, we will compare ZK and Optimistic Rollup in several dimensions, and explain why we think the future is Optimistic, while Optimistic Rollup like Arbitrum is inherently more scalable.

Optimistic Rollup vs. ZK: Costs

Perhaps the most important difference between Optimistic Rollup and ZK is cost.

Optimistic Rollup requires nodes to simply execute contracts. For example, if a contract performs an add operation, the node will perform that add operation.

ZK, on ​​the other hand, needs to generate a complex cryptographic proof that requires hundreds or thousands of expensive elliptic curve operations to include the addition operation in the proof. ZK bears this fee for every instruction in every contract. The need to generate complex cryptographic proofs for every instruction, not just the execution, is an inherent cost disadvantage to ZK — and a big one at that.

ZK advocates sometimes argue that only one party is required to create a proof, whereas Optimistic Rollup requires the system to have many nodes. However, if you are running a large chain, it will have many nodes no matter which verification system you use. A real chain would require many nodes to serve the non-mutating call event log, display transaction data to users, provide users with the data they need to withdraw funds to L1, etc. The security of an Optimistic Rollup chain relies on these nodes doing what they already need to do — execute transactions and track the correct state of the chain.

On the other hand, ZK building expensive elliptic curves proves to be a very large additional cost. You need special-purpose hardware or massive parallelism — or both — to be able to do large-scale proofs with ZK, but that’s expensive.

Conclusion: The Optimistic Rollup system has an inherent and huge cost advantage.

Optimistic Rollup and ZK: EVM Compatibility

An important consideration for us when building Arbitrum was compatibility with the EVM. Arbitrum is fully compatible with EVM; it has the same RPC interface and accepts the same bytecode as EVM. In practice, this means that any code written for Ethereum can be run on Arbitrum out of the box.

We’ve been running an open, EVM-compatible chain (including testnet) for over a year now, and we’ve learned how challenging it can be to be truly compliant. Compatibility in the first 95% is not hard, but it's not good enough in practice, and doing better requires both a lot of effort and a product architecture that doesn't get in the way.

The ZK system operates on a wide range in terms of compatibility. Some see it as a legacy tool and encourage people to learn their custom language.

But some ZK systems make no attempt to be compatible. Of course it's fine for developers and users who don't care about compatibility.

We're not arguing that the EVM is objectively the best ever. What we think is that the EVM has a lot of practical advantages given the number of developers, code, and developer tools that already work with it. Consider a project deployed on Ethereum that, if it wishes to scale to Rollup, must rewrite the code in a new language, commission a new security audit, and maintain multiple code bases, which is cumbersome and error-prone. But even for new projects that haven't written any code yet, EVM compatibility is a great advantage because it allows those projects to take advantage of the code, tooling, and talent pool that exists around the EVM.

A few ZK projects are working on EVM-compatible versions, but despite their vague claims, we are not aware of any code released so far that would allow people to run EVM contracts while ZK Rollup. Existing preliminary systems have serious incompatibilities. For example, a ZK system that claims EVM compatibility fails to implement the ADDMOD, SMOD, MULMOD, EXP, SELFDESTRUCT, and CREATE2 opcodes; removing support for XOR, AND, and OR is being considered; does not support standard transaction formats; does not support any precompilation ; and possibly limit the number of contract calls in a transaction. There seems to be a fundamental incompatibility with the ZK model, which guarantees that even in the best case, ZK EVM compatibility will come with detailed printed pages, without enabling the full compatibility that Optimistic Rollups achieve.

It is worth clarifying that several examples of application-specific ZK systems exist today (e.g. Zcash, ZKSync 1.0, Loop). In fact, some of these systems work quite well. The core difference is that these are just fine-tuned and specifically optimized for specific applications that are well suited for ZK implementations. What doesn't exist today is a general-purpose compiler that allows one to implement the transition from EVM to ZK in a compatible way. While there are some teams claiming to be working on it, there is no public code or benchmarks of proof-of-cost for user-defined ZK-EVM contracts available. Based on our knowledge and all publicly available data, we believe their cost is prohibitively high.

Conclusion: Only Optimistic supports full EVM compatibility with the lowest cost.

Optimistic Rollup and ZK: Visibility and Compressibility with Unconditional Trust

One of our key properties when designing Arbitrum is the visibility of unconditional trust. In short, visibility with unconditional trust means anyone can see or access on-chain content without centralization. Importantly, this doesn’t just mean everyone can see a snapshot of the state; it means everyone can see the full history of the chain — how it got to its current state. UtilityChain allows anyone to run a node that can support non-mutating calls, search event history, and view every transaction—without relying on centralized data providers. Untrustworthy visibility makes this possible.

Quite frankly, some ZK systems are a little less visible and trying to make conversations around the fact that they don't provide full blockchain functionality. When you hear talk about "compression" please listen carefully: do they say they are encoding on-chain content more efficiently (Arbitrum has done this and will do it better in our Nitro release) ? Or are they saying that parts of the on-chain history will never be available unless the centralized data provider is willing to share it with you later?

Recall that a ZK proof only proves that the prover knows the valid chain. The proof doesn't tell you what the chain is, and even if you have enough data to verify the proof, you probably don't have enough data to reconstruct the chain's history.

For example, suppose Alice continuously submits transactions of 1 ETH to Bob, and Bob continuously submits transactions of 1 ETH to Charlie. Later, you verify the proof that Alice is 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 pays Charlie directly. Maybe Alice burned an ETH and Charlie was paid by someone else. Maybe Diana is the intermediary, not Bob. Bob looks to the blockchain for proofs, but some ZK Rollup doesn't provide chain visibility and he can't tell the difference.

Many smart contract applications require more than knowing a checkpoint occasionally. They need to understand the chain - know what happened and how to reach the final state. ZK Rollups sometimes boast better "compression" than Optimistic Rollups, but in fact hide the chain's data so that only the prover knows it's not compression - it removes important data. If a ZK provider says they "do not need" to publish on-chain history, what they are really saying is that they cannot guarantee chain visibility. Giving up on-chain visibility guarantees is not a compromise we are willing to make.

Conclusion: The Optimistic Rollup system provides visibility with unconditional trust at minimal cost.

Optimistic Rollup and ZK: unconditional trust, timely ending

A key requirement when considering Rollup is whether it delivers unconditionally trusted, timely end results. In short, this means that after you submit a transaction, you should know the outcome of the transaction to yourself and others quickly and with certainty, and no one should change or reverse it.

We believe that the best way to achieve timely finality is to separate the order of transactions from their execution. Sorting produces a final sequence of proposed transactions, and execution attempts to execute transactions in that sequence. If the execution of transactions is deterministic, as in a quorum, then the order in which transactions are completed is sufficient to finalize the outcome, since the outcome is a deterministic function of the sequence of transactions. If everyone knows the order of transactions, everyone can easily determine the outcome.

Finalizing the sequence requires publishing the sequence to the L1 chain with enough information so that anyone can execute the transaction themselves to know the outcome with unconditional trust. The ideal Rollup is to publish sequential transaction data to the L1 chain as frequently as possible.

In the Optimistic Rollup system, the overhead of publishing to the L1 chain is minimal. In fact, Arbitrum usually publishes serialized transaction data to the L1 chain every 1 minute or so, providing users with fast final results and guaranteeing that no one can undo them transaction. A new Optimistic Rollup result assertion is made every hour or so, but since the sequence is already complete and execution is deterministic, this does not slow down the final result.

In principle, a ZK system could operate in a similar fashion; i.e. separate the order of transactions (which can often be published to L1) from the verification that takes place later, occasionally providing proof of validity. However, ZK Rollup operating in this manner requires posting data on the L1 chain that is basically published with the Optimistic Rollup system; none of the (so-called) "compression" techniques discussed above will be available. In order for these "compression" techniques to work, each time a batch of L2 transactions is published, within the same L1 transaction, the validity of a series of L2 transactions must be verified in real time.

Thus, ZK Rollup seeking to use the touted "compression" technique is left with two options:

1) Publish serial transactions and proof of execution every minute or so: This retains the speed, but requires ZK-Proof to be generated outside the chain every minute and verified on the L1 chain. Depending on the implementation, the cost of issuing a ZK proof on-chain is estimated to be between 500,000 and 5 million gas.

2) Publish sequential transactions and proofs every hour: This makes ZK proof checking cost reasonable, but extends finality time to one hour. Within a few hours of a user submitting a transaction to a ZK operator and being published on-chain, users can't even guarantee that their transaction will be included, but simply trust the operator's message.

If we were building a ZK system, we would find these two options unacceptable - the first is too expensive, and the second does not provide timely final results. So we end up using the same sequencer as the Optimistic Rollup version and publishing essentially the same data online in the ZK version of Arbitrum.

Be careful if you hear someone brag that ZK can compress hours of data into a single time node. If they only publish a single data point at the end of a long period of time, then that means they provided no termination during that period.

Conclusion: Practical considerations force Optimistic Rollup and ZK systems to handle finalization in the same way in a timely manner.

Optimistic Rollup and ZK: The vitality of unconditional trust

The dynamism of unconditional trust means that anyone can force the system to make progress. (The security property of unconditional trust ensures that this progress is correct.)

Optimized Rollup allows any node to declare correct execution. Making a claim simply requires a node to perform an on-chain transaction and then deposit a stake, which can be refunded once the claim is confirmed by the protocol.

On a ZK system, progress requires that any node can create and issue one of the ZK proofs needed to advance the state of the chain. This must use hardware and software that is readily available to anyone. As such, it must not require special-purpose hardware to be built or purchased, nor can massively parallel computing be performed. There must be a way to build proper ZK proofs on common devices. A ZK provider that does not provide this service, or releases the code to generate proofs for its system, does not provide unconditional trust in progress, nor does the system have liveness guarantees. Their system is centralized because only specially equipped parties can force progress. (It's unclear whether the leading ZK Rollup providers will make the proof viable for ordinary users.)

Conclusion: In an Optimistic Rollup system, it is easier to have progress with unconditional trust.

ZK vs. Optimistic Rollup: Bridging

One area where ZK Rollup does have an advantage is as a bridge to Ethereum. The Optimistic Rollup system anticipates a one-week delay in transferring funds from Rollup to L1, while ZK Rollup allows immediate erection after the ZK proof is issued to L1. In practice, this doesn't make that much of a difference, as Optimistic Rollup users can take advantage of the fast bridging service and swap L2 funds for low-latency L1 funds. Therefore, the advantage of ZK is mainly that its users can avoid paying the small fees charged by bridging services (these services compete with each other on price). This is not just theoretical: today there are many real-time fast bridge services that can provide instant withdrawals from Arbitrum.

Importantly, the bridging advantage of ZK Rollups is rather narrow: it only works for bridging from L2 to Ethereum. Once upon a time (circa 2019), many thought that Rollups would offer a slow rollout of one or two live dapps. In such a world, Rollup users will constantly find themselves switching back and forth between L1 and L2. But that's not the world we live in. Arbitrum has a thriving ecosystem with hundreds of dApps in every corner of Defi, and many users are building bridges with Arbitrum and staying there for a long time. Also, since users hop across multiple chains, they are not just going to Ethereum. They will also use other L1s and sidechains, and for this direct bridge, ZK Rollups have no advantage over Optimistic Rollups.

Summarize

Summarize

Comparing Optimistic Rollup with the ZK system, we think the Optimistic Rollup system is the clear winner. Optimistic is much cheaper, fully compatible with EVM and existing tools, and the only real downside in practice is that L1 bridging is much slower without fast bridging services. Other supposed advantages of ZK require sacrificing chain visibility or fastness, which we don't think is a trade-off that users want.

None of this is likely to change. ZK-proof EVM-compatible contract execution will still be significantly more expensive than Optimistic Rollup execution, and the requirements to achieve guaranteed progress, on-chain visibility, and decentralization will also remain the same. While we would always be open to switching Arbitrum to a ZK-based execution if circumstances change, we don't think they will.

Finally, we cautiously conclude. People tend to compare what Arbitrum offers today with what the ZK system represents to offer in the future. But this comparison is meaningless, because if we compare the systems that exist today, Optimistic Rollup like Arbitrum is the only one that supports open deployment of smart contracts in general. Or, if we compare future systems, then we should compare future Arbitrum and future ZK systems. We are constantly improving Arbitrum — for example, our upcoming Nitro release includes lower costs and better optimized lossless compression of on-chain data. We are working tirelessly to improve Arbitrum and bring the cost down to theoretical limits. As we have shown in this post, we believe that Optimistic Rollup is the clear winner when considering the systems that exist today and their respective theoretical constraints.