Optimistic Rollups: the present and future of Ethereum scaling
We’re hearing a lot of talk about how ZK rollups are supposedly the future of general smart contract systems. We disagree — and this post explains why. It draws 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’ realistic needs for a secure, trustless, EVM-compatible L2. We chose optimistic over ZK because of the inherent scalability and cost advantages of optimistic systems; we would still make the same choice today. To learn why, read on.
Wait! How long is this post?
Yes, this post is long and it gets technical in places. What people want from their chains is simple, but talking about the tech needed to provide those advantages requires us to go into some details. We wanted the technical community to understand our points.
If you don’t want to read the whole thing (and we don’t blame you!), here’s a quick synopsis.
- People want a chain that trustlessly offers safety, guaranteed progress, visibility, and quick finality — and they want it at low cost and compatible with existing tooling.
- We dug into the details of how to provide those properties using an optimistic rollup compared to a ZK rollup.
- Optimistic can provide the properties that users want, at lower cost, because of the very high off-chain costs of constructing ZK proofs.
- Because ZK proofs are so expensive, full participation in a ZK protocol probably requires special-purpose hardware and/or massive parallelism, making the network effectively more centralized.
- The claimed advantages of ZK either are available to optimistic systems too, or require sacrificing important security or usability features.
- Optimistic rollup wins big on the cost of operation, because executing code is much cheaper than computing complex cryptographic proofs about it.
Let’s start from the beginning
Let’s begin with Ethereum. An Ethereum user creates a transaction to deploy or interact with a smart contract. You can think of an Ethereum transaction in a few different ways. On the one hand, you can view it as just an opaque blob of data. But if you look at its contents, a transaction is of course much more than that; it’s a request, asking a smart contract to do something: record some information, move some assets, etc.
When a transaction is posted on Ethereum, two important things happen. First, it gets included and Ethereum reaches consensus on the set of ordered transactions. Second, Ethereum executes those transactions and computes the resulting state update.
Rollups: what we all have in common
It’s expensive to have every Ethereum node execute every transaction, and Rollups are a class of scaling solutions that lighten this load significantly. The actual execution of transactions is not done on Ethereum and instead moved to Layer 2 (“L2”) land.
But wait a second — rollups are supposed to be secured by Ethereum. That means that we need Ethereum to somehow vouch for the correctness of the transaction execution even though it’s happening in L2 land. So how can Ethereum give its stamp of approval to the rollup state?
In a word, the answer is: proofs. Rollups prove their correctness to Ethereum using specialized proofs that allow Ethereum to verify correctness even without executing the transactions.
Rollups: where optimistic and ZK differ
These proofs seem pretty magical: allowing Ethereum to verify the rollup state without actually doing the execution. You’re probably wondering what these proofs look like and how they’re implemented in practice. And this is where the various flavors of rollups differentiate themselves.
ZK Rollups use validity proofs. ZK relies on some party posting a succinct cryptographic proof, which establishes that that party knows a valid chain ending with a particular state. This requires the proving party to execute the chain, in order to know how to construct the proof, and then to construct the proof by doing a series of complex cryptographic operations. The proof is checked by an on-chain L1 contract. ZK proofs are succinct and verification is cheap enough to be done by an Ethereum transaction.
Optimistic Rollups use a different type of proofs: fraud proofs. As their name implies, Optimistic Rollups are optimistic in the sense that when they post the updated state to Ethereum they do this without posting any proof at all. Anyone can post a rollup block containing a claim about what is the correct outcome of executing some transactions. Other nodes execute the same transactions, and can post a challenge if they disagree with the first node’s claim. An efficient dispute protocol resolves any disagreements, guaranteeing that the party who is correct will win the challenge. The parties have strong incentives to post only correct claims, and to challenge incorrect claims, so in the common case all nodes simply execute all of the transactions and the proof code never needs to be invoked. This entire process is managed by an L1 contract.
Alright, so which type of rollup is better? In the rest of this post, we’ll compare ZK and Optimistic Rollups over several dimensions, and explain why we believe that the future is Optimistic, and Optimistic Rollups like Arbitrum are inherently more scalable.
Optimistic vs ZK: Cost
Perhaps the most crucial difference between optimistic and ZK is cost.
Optimistic requires nodes to simply execute contracts. For example, if a contract does an add operation, the nodes do that add operation.
ZK, on the other hand, needs to produce a complex cryptographic proof that requires hundreds or thousands of expensive elliptic curve operations to include that add operation in a proof. ZK incurs that cost for every instruction in every contract. The need to produce a complex cryptographic proof over every instruction, instead of just executing the instructions, is an inherent cost disadvantage for ZK — and a large one.
ZK advocates sometimes argue that only one party needs to create the proof, whereas optimistic requires that the system have many nodes. But if you’re running a large-scale chain, it will have many nodes regardless of which proof system you’re using. Real chains need many nodes to service non-mutating calls, search event logs, display transaction data to users, provide users the data needed for withdrawing funds back to L1, and so on. An optimistic chain’s safety relies on these nodes doing what they already need to do — executing transactions and tracking the correct state of the chain.
With ZK, on the other hand, constructing expensive elliptic-curve based proofs is a very large added cost. To have any hope of ZK proving at scale, you’ll need special-purpose hardware devices or massive parallelism — or both. That is very expensive.
Verdict: Optimistic system have an inherent and large cost advantage.
Optimistic vs ZK: EVM Compatibility
An important consideration for us when building Arbitrum was compatibility with the EVM. Arbitrum is fully EVM compatible; it has the same RPC interface and accepts the same bytecode as the EVM. What this means in practice is that any code written for Ethereum works out of the box on Arbitrum.
We have been running open, EVM-compatible chains (including testnets) for more than a year, and we have learned how challenging it can be to be truly compatible. The first 95% of compatibility isn’t too difficult, but that’s not good enough in practice and doing better requires both a ton of hard work and a product architecture that doesn’t get in the way.
ZK systems run the gamut when it comes to compatibility. Some disregard it as legacy tooling and encourage people to learn their custom languages.
Some ZK systems aren’t trying to be compatible. And that’s fine for developers and users who don’t care about compatibility.
We’re not arguing that in a clean-slate world, EVM is objectively the best thing ever. We’re arguing that there are so many practical advantages that come with the EVM considering the amount of developers, code, and developer tooling that already work with the EVM. Consider a project that’s deployed on Ethereum that wants to expand to a rollup. Having to rewrite their code in a new language, commission new security audits, and maintain multiple codebases is cumbersome and error-prone. But even for new projects that haven’t written any code yet, EVM compatibility is a big win as it allows these projects to tap into the code, tooling, and talent pool that exist around the EVM.
Some ZK projects are working towards an EVM compatible version, but despite vague claims, we are not aware of any code released to date that allows one to run EVM contracts on a ZK rollup. The preliminary systems that exist have significant incompatibilities. For example, one ZK system that claims EVM compatibility fails to implement the ADDMOD, SMOD, MULMOD, EXP, SELFDESTRUCT and CREATE2 opcodes; is considering removing support for XOR, AND, and OR; doesn’t support the standard transaction format; doesn’t support any precompiles; and will likely limit the number of contract calls in a transaction. And there seem to be fundamental incompatibilities with the ZK model that guarantee that even in the best case, ZK EVM compatibility will come with pages of fine print, and not support the full compatibility made possible by Optimistic Rollups.
It’s worth clarifying that there are several examples of application-specific ZK systems that exist today (e.g. Zcash, ZKSync 1.0, Loopring). And indeed some of these systems work well. The core difference is that these were fine-tuned and specially optimized for particular applications that are well-suited for ZK implementation. What doesn’t exist today is a generic compiler that allows one to go from EVM to ZK circuits in a compatible way. And while there are some teams that claim to be working on it, there is no public code available or benchmarks for what the costs of proving would be for user-defined ZK-EVM contracts. Based on our knowledge and all publicly available data, we believe that they would be prohibitively expensive.
Verdict: Only Optimistic supports full EVM compatibility and at minimal cost.
Optimistic vs ZK: Trustless Visibility and Compression
One of our key properties when designing Arbitrum was trustless visibility. Put simply, trustless visibility means that anyone can see or derive, without help from a centralized party, the contents of the chain. Importantly, this means not only that everyone gets to see occasional state snapshots — it means that everyone can see the full history of the chain–how it got to its current state. A practical chain lets anyone run a node that can support non-mutating calls, search event history, and see every transaction — without needing to rely on a centralized data provider. Trustless visibility is what makes that possible.
To put it bluntly, some of the ZK systems out there cut corners on visibility, and try to talk around the fact that they’re not providing full blockchain functionality. When you hear talk about “compression”, listen carefully. Are they saying that they are encoding the contents of the chain more efficiently (which Arbitrum does, and will do even better in our Nitro release)? Or are they saying that parts of the chain history are never made available at all, unless a centralized data provider is willing to share them with you later?
Recall that a ZK proof proves only that the prover knows a valid chain. The proof does not tell you what that chain is, and even if you have enough data to verify the proof, you may not have sufficient data to reconstruct the chain’s history.
As an example, suppose that Alice submits a transaction paying Bob 1 ETH, and Bob submits a transaction paying Charlie 1 ETH, in quick succession. Later you verify a proof that Alice has 1 ETH less than before, Bob’s balance hasn’t 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. Maybe Alice burned an ETH and Charlie was paid by someone else. Maybe Diana was the intermediary, not Bob. Bob looks to the blockchain for evidence, but with some ZK-rollups that don’t provide chain visibility, he can’t tell the difference.
Many smart contract applications require more than knowing an occasional checkpoint. They require knowing the chain — knowing what happened and how the final state was reached. ZK Rollups sometimes tout better “compression” than Optimistic Rollups, but hiding the chain’s data so that only the prover knows it isn’t compression; it’s deleting important data. If a ZK provider says they “don’t need” to post the chain history, what they’re really saying is that they’re not guaranteeing chain visibility. Giving up on a chain visibility guarantee was not a compromise we were willing to make.
Verdict: Optimistic systems provide trustless visibility at minimal cost.
Optimistic vs ZK: Trustless, timely finality
A critical requirement when considering a rollup is whether it offers trustless, timely finality. In simple terms, this means that after you submit a transaction, the result of that transaction should be known, promptly and with certainty, to you and everyone else, and nobody should be able to change or undo it.
The best way to achieve timely finality, in our view, is to separate sequencing of transactions from their execution. Sequencing produces a finalized sequence of proposed transactions, and execution tries to execute the transactions in that sequence. If execution of transactions is deterministic, as it is on Arbitrum, then finalizing the sequencing of transactions is sufficient to finalize the results, because the results are a deterministic function of the sequence of transactions. If everyone knows the sequence of transactions, then everyone can easily determine the results.
Finalizing a sequence requires the sequence to be posted to the L1 chain, with enough information included to allow anyone to execute the transactions themselves, in order to know the results trustlessly. The ideal rollup is one that posts sequenced transaction data to the L1 chain as frequently as possible.
In optimistic systems, there is minimal overhead to post to the L1 chain, and indeed Arbitrum typically posts sequenced transaction data to the L1 chain every minute or so, providing users fast finality and guaranteeing that nobody can undo their transactions. A new optimistic result assertion is made every hour or so, but since the sequence has already been finalized and execution is deterministic, this doesn’t slow down finality.
In principle, ZK systems could operate in a similar way; i.e., separating the ordering of transactions — which could be posted to the L1 frequently — with their verification, which would take place later, with the occasional validity proofs. A ZK-rollup that operated in this way, however, requires posting to the L1 chain essentially the same data that an optimistic system would post; none of the (so-called) “compression” techniques discussed above would be available. For those “compression” techniques to work, the validity of a sequence of L2 transactions must be proven in real time, in the same L1 transaction, every time a batch of L2 transactions is posted.
Thus, a ZK-rollup that seeks to employ the touted “compression” techniques is left with two options:
1) Post sequenced transactions along with proofs of execution every minute or so: this preserves fast finality, but requires that a ZK-Proof be generated off-chain and verified on the L1 chain every minute. The cost of posting ZK proofs on-chain is estimated to be between 500,000 and 5 million gas, depending on the implementation.
2) Post sequenced transactions along with proofs hourly: This keeps the ZK proof checking cost reasonable, but it lengthens the finality time to an hour. During the hour between when a user submits their transaction to the ZK Operator and its posted on-chain, the user has no guarantees that their transaction will even be included, and is simply trusting the Operator’s word.
If we were building a ZK system, we would find these two options unacceptable — the first is too expensive and the second doesn’t provide timely finality. So we would end up using the same type of sequencer and posting essentially the same data online in a ZK version of Arbitrum as in our optimistic version.
If you hear someone touting that ZK can compress hours of data into a single point, be wary. If they’re only posting a single point of data at the end of a long time period, then this means they were not offering finality during that period.
Verdict: Practical considerations force optimistic and ZK systems to handle timely finality in the same way.
Optimistic vs ZK: Trustless Liveness
Trustless liveness means that anyone can force the system to make progress. (The trustless safety property ensures that that progress will be correct.)
Optimistic rollup allows any node to claim a correct execution. Making that claim requires only that the node execute the chain’s transactions, then deposit a stake which can be refunded after the claim is confirmed by the protocol.
On a ZK system, progress requires that any node can create and post one of the ZK proofs needed to progress the chain’s state. This must be possible using hardware and software that is readily available to anyone. So it must not require building or buying exotic, special purpose hardware, nor doing massively parallel computation. There must be a path for constructing a suitable ZK proof on ordinary equipment. A ZK provider who does not offer this, or who has not released code for producing proofs for their system, does not provide trustless progress and the system has no liveness guarantees. Their system is centralized because only parties with special equipment can force progress. (It is not clear whether leading ZK rollup providers will make proving feasible for ordinary users.)
Verdict: trustless progress is easier to provide in an optimistic system.
ZK vs. Optimistic: Bridging
The one area where ZK rollups do have an advantage is when it comes to bridging to Ethereum. Optimistic systems incur an expected weeklong delay to transfer funds from the rollup to L1, whereas ZK rollups allow bridging as soon as a ZK proof has been posted to the L1. In practice, this isn’t such a large difference because optimistic rollup users can take advantage of fast bridging services that will swap L2 funds for L1 funds with low latency. So the advantage of ZK is mostly that its users can avoid paying the small fees charged by the bridging services (which compete with each other on price). And this isn’t theoretical: there are many live fast bridging services today that offer instant withdrawals from Arbitrum.
It’s important to stress that ZK Rollups’ bridging advantage is quite narrow: it’s only for bridging from L2 back to Ethereum. Once upon a time (circa 2019) many believed that Rollups would offer a slow rollout with one or two live dapps. In this world, Rollup users would constantly find themselves bridging back and forth between L1 and L2. But that’s not the world we’re in. Arbitrum has a thriving ecosystem with hundreds of dApps spanning every corner of Defi, and many users are bridging to Arbitrum and staying there long term. Moreover, to the extent that users are hopping across multiple chains, they’re not just going to Ethereum. They’re going to other L1s and sidechains as well, and for this sort of direct bridging, ZK Rollups have no advantage over Optimistic Rollups.
Verdict: ZK systems have a slight advantage in bridging to L1, but it’s mostly mitigated in practice due to fast bridges and multichain usage patterns.
The Bottom Line
Comparing optimistic versus ZK systems, we think optimistic systems are the clear winner. Optimistic is much cheaper, enjoys full compatibility with EVM and existing tooling, and the only real disadvantage in practice is that L1 bridging is slower in the absence of fast bridging services. The other supposed advantages of ZK require sacrificing chain visibility or finality time, which we don’t think is a tradeoff users want.
None of this is likely to change. ZK proving of EVM-compatible contract execution will remain much more expensive than optimistic execution, and the requirements to achieve guaranteed progress, chain visibility, and decentralization will remain as well. Although we’re always open to switching Arbitrum over to ZK-based execution if things change, we don’t think they will.
We’ll conclude with a note of caution. There’s a tendency out there for people to compare what Arbitrum provides today against what ZK systems say they will provide in the future. But this comparison makes little sense. If we compare the systems as they exist today, Optimistic rollups like Arbitrum are the only ones that support open deployment of general smart contracts. Or, if we are comparing future systems, then we should compare the future of Arbitrum with a future ZK system. We are constantly improving Arbitrum — our upcoming Nitro release, for example, includes lower cost and better-optimized lossless compression for on-chain data. We’re working tirelessly to improve Arbitrum and reduce costs to the theoretical limit. And as we’ve shown in this post, we believe that when considering both the systems as they exist today as well as their respective theoretical limits, Optimistic Rollups are the clear winner.
