Optimistic Rollups Explainer
Last updated
Last updated
The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of how Optimistic Rollups work at a high level. Then we'll explain why Optimism is built as an Optimistic Rollup and why we believe it's the best option for a system that addresses all of our design goals.
The concept behind Optimistic Rollups (ORs) is to enhance scalability while leveraging the security of a parent blockchain, such as Ethereum. This overview will explain the workings of Optimistic Rollups, particularly focusing on Optimism and comparing it with Arbitrum, another leading OR implementation. Optimistic Rollups are leading the L2 race, with 90% dominance vs ZK Rollups in terms of TVL.
The beauty of optimistic proving is that the proving cost can always be zero for honest parties. In the common case, no proof is necessary because only true claims are posted, so there is never a challenge. If there is a challenge, there is some cost to resolving it — but every dishonest party will lose the challenge, and therefore they will forfeit a stake, which can be used to pay the cost of the challenge.
Optimistic protocols rely on having multiple parties executing the chain, so that they can check up on any posted claims about the results of execution. In other words, the chain needs to have nodes. But any chain with non-trivial usage will have plenty of ordinary nodes, run by users or infrastructure providers, in order to support the chain’s activity. Those nodes will all naturally serve as watchtowers for the optimistic protocol.
By contrast, ZK requires a cryptographic proof to be generated for every posted claim, and that proof must be verified on Layer 1. Over time, ZK researchers have reduced the cost of generating these proofs, but they can never be reduced to zero.
In fact, ZK proofs are quite expensive by comparison with optimistic execution. If a smart contract does (say) a bitwise AND operation, every validator of an optimistic system just does a bitwise AND. A ZK prover needs to do the bitwise AND, then do a large number of expensive cryptographic operations to ZK-prove the result of the bitwise AND instruction. If Alice and Bob go to the food market, Alice buys a grape, and Bob buys a grape and a watermelon, then Alice’s cost will always be lower than Bob’s.
In both optimistic and ZK rollups, ordinary nodes need to execute every transaction in order to know the chain’s history as it evolves. So that part is no different.
Bottom line: optimistic has lower cost.
In software engineering, and especially in security engineering, simpler is better. Complexity increases security risk, and makes everything slower and more difficult.
There’s no question that optimistic proving is simpler than ZK proving. Optimistic proving can be explained to, and understood by, almost any developer, whereas ZK proving relies on complex mathematics as well as deep and subtle cryptography theorems that are understood by very few people. Even professors who teach cryptography have to work hard to understand ZK proof systems.
Proving is a necessity for any L2 chain. But proving is not the only thing that users and developers want. They want new features — and those are easier and faster to build on optimistic systems.
A good example is Arbitrum Stylus, which allows developers to write smart contracts in common languages like Rust and C++, and run those programs in a WASM virtual machine, on the same chain as EVM contracts, with full composability. A feature like Stylus is challenging to build, requiring integration of two virtual machines into a single seamless system.
One reason features like this can be built in optimistic systems is that optimistic implementations can use standard programming languages and tools, which makes it easier to evolve software. By contrast, ZK requires different programming tools, either to build ZK circuits (or constraint sets) manually or to use some intermediate compiler to reduce everything to circuits. Custom tools and programming approaches will always be slower and more cumbersome to use, which translates into slower progress in evolving the whole system.
The simplicity of optimistic systems translates into more flexibility and faster evolution and improvement.
People often ask about the finality time for optimistic vs ZK rollups. The answer is that they are the same.
A transaction has finality when the result of the transaction is fully determined and all participants in the protocol know the result. Rollup chains, whether optimistic or ZK, operate in two phases: first, a sequencer publishes and records a sequence of transactions that have arrived at the chain; then second, an execution and settlement layer computes and proves the result of executing the transactions in the sequence, one by one in order. Finality occurs when a transaction has a finalized position in the transaction sequence — at that point the transaction’s result is fully determined by the finalized transaction sequence, and everyone knows that result.
Because finality is determined by the sequencer’s output being posted to Ethereum (which is the same process in optimistic as in ZK), rather than the prover (which only operates later), optimistic and ZK systems have exactly the same finality behavior. Any finality time that one can achieve, the other can achieve equally.
The one place where ZK has an inherent advantage is in the latency of cross-chain communication, that is, how long it takes for a contract on one chain to send a message trustlessly to a contract on another chain.
Cross-chain transfers of fungible assets (ETH or tokens) typically happen via fast bridging services whose operation doesn’t depend on optimistic vs ZK proving, so ordinary users won’t see any difference in cross-chain asset transfer time.
For other types of cross-chain messages, ZK can be faster, because the ZK chain can checkpoint its state to a parent chain (i.e., to Ethereum for an L2) more quickly than an optimistic chain can. This means that trustless cross-chain messaging, for use cases other than asset transfer, will be faster if the sending chain uses ZK proving.
At this point, it’s not clear how important that difference will turn out to be. Today the vast majority of cross-chain activity is asset transfer, where there isn’t much difference in user experience.
