Why I’m Still Optimistic About Optimistic
Arbitrum uses an optimistic rollup protocol. People often ask why we chose optimistic for Arbitrum, and whether we expect Arbitrum to switch to ZK proving. I have written about this before, but that was almost two years ago. Here’s my current personal view. Others may disagree.
I’m a big believer in pragmatism when designing systems. Rather than falling in love with one technical approach and applying it whatever the cost, we should ask which approach best meets the needs of our users and developers. The best approach might change over time, and if so we should be willing to switch.
We chose optimistic proving for Arbitrum as the pragmatic choice, and I believe that optimistic is still a better choice than ZK proving, for meeting the needs of users and developers. Simply put, optimistic is cheaper, simpler, and more flexible than ZK. I’ll expand on each of those claims below.
That said, if something changed and ZK became the better choice, I would argue that Arbitrum should switch. I don’t expect that to happen any time soon.
Optimistic has lower cost
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.
Optimistic is simpler
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.
Optimistic is more flexible
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.
Finality time is the same
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.
Cross-chain communication time
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.
The bottom line
For me, the answer is clear: the advantages of optimistic proving — low cost, simplicity, and flexibility — outweigh the one area where ZK is better (speed of non-asset-transfer cross-chain functionalities).
That’s why I’m happy that Arbitrum is still using optimistic proving.
