A rollup is a layer-2 scaling technique that executes transactions on a separate chain, then compresses and posts the results back to a base layer like Ethereum — inheriting the base layer’s security without congesting it. Two distinct designs have emerged as the leading approaches: optimistic rollups and zero-knowledge (ZK) rollups. They answer the same question — “how do we prove off-chain work is honest?” — with fundamentally different strategies.
Why rollups exist
A layer-1 blockchain like Ethereum deliberately limits throughput to keep nodes easy to run and the network decentralized. That constraint means gas and fees spike during busy periods, and transactions queue in the mempool waiting for space.
Rollups sidestep this by doing the heavy computation elsewhere. A rollup operator batches hundreds or thousands of transactions together, executes them off-chain, and submits a compact summary — plus enough data for anyone to reconstruct or verify — back to the main chain. Users get lower fees and faster confirmations; the base layer provides the settlement guarantee.
Both designs share a common structure:
- Transactions are executed on the rollup chain.
- Batched transaction data is posted to the base layer (ensuring public availability).
- A mechanism proves to the base layer that the batch was executed correctly.
The designs diverge at that last step.
Optimistic rollups
Optimistic rollups assume batches are valid by default — they are “optimistic” about operator honesty. No proof of correctness is submitted upfront. Instead, there is a challenge window, typically around one week, during which any observer can inspect the posted data and raise a fraud proof if they detect invalid state transitions.
How fraud proofs work
If a challenger identifies a dishonest batch, they submit a fraud proof to the base-layer contract. The contract re-executes the disputed computation on-chain and, if the challenger is right, rolls back the invalid batch and penalizes the operator. This “trust but verify” model means the system only does expensive on-chain work when something goes wrong.
The withdrawal delay
The challenge window creates a practical cost for users: withdrawing assets from an optimistic rollup back to the base layer takes as long as that window. Liquidity protocols can bridge this gap — a user pays a small fee to a liquidity provider who fronts the funds immediately — but the native exit path is slow.
Examples in the wild
Arbitrum and Optimism are the most widely used optimistic rollups. Both are EVM-compatible, so existing smart contracts and tooling port over with minimal changes.
ZK rollups
ZK rollups generate a cryptographic validity proof for every batch before submitting it to the base layer. “ZK” stands for zero-knowledge, though in practice most rollup proofs use the validity-proving property of zero-knowledge systems rather than the privacy property. (They prove a statement is true without revealing the underlying data, but the main goal here is correctness, not secrecy.)
How validity proofs work
After executing a batch, the rollup produces a succinct proof — often called a ZK-SNARK or ZK-STARK — that mathematically certifies the state transition is correct. The base-layer contract verifies this proof (a relatively cheap operation) before accepting the batch. No challenge period is needed because the proof itself is the guarantee.
Insight: A ZK proof lets you convince a skeptic that you ran a computation correctly without making them re-run it themselves. Verifying the proof is far cheaper than redoing the work, which is what makes it useful for blockchain scaling.
Faster finality, harder engineering
Because validity is proven upfront, withdrawals from ZK rollups can be processed as soon as the proof is verified on-chain — potentially minutes rather than days. The trade-off is computational cost on the rollup side: generating these proofs is intensive, and building a general-purpose ZK proof system for arbitrary smart contract logic (as opposed to simple transfers) is a difficult engineering problem.
Head-to-head comparison
| Property | Optimistic Rollup | ZK Rollup |
|---|---|---|
| Correctness mechanism | Fraud proofs (after the fact) | Validity proofs (upfront) |
| Withdrawal to L1 | Days (challenge window) | Minutes to hours |
| EVM compatibility | High — near-identical to Ethereum | Improving — historically harder |
| Proof generation cost | None upfront | Computationally intensive |
| Security assumption | Honest challenger exists | Cryptographic soundness |
| Maturity | Production-ready, widely used | Rapidly maturing |
Security assumptions
Neither design is unconditionally safe.
Optimistic rollups require that at least one honest, well-resourced party is watching the chain and willing to submit fraud proofs. If no one challenges an invalid batch within the window, the bad state becomes final. Protocols typically run their own watchers and offer financial rewards for successful challenges.
ZK rollups depend on the soundness of the underlying cryptography. A flaw in the proving system could theoretically allow invalid proofs to pass. These systems are complex, and their codebases are relatively young. Auditing and formal verification are ongoing priorities.
Neither approach is as simple as using Ethereum directly, and both require trusting the rollup’s smart contracts — particularly the bridge contracts that lock and unlock assets between layers.
Data availability: the hidden requirement
Both designs require posting transaction data to the base layer so that anyone can independently reconstruct the rollup’s state. This data availability guarantee is what distinguishes rollups from systems that only post proofs or state roots. If the data is not available, users could be locked out even if the proof says everything is fine.
Some newer designs post data to cheaper alternative networks rather than Ethereum itself — a design sometimes called a “validium” for ZK rollups or an “optimium” for optimistic ones. This lowers costs further but weakens the inherited security. It is a deliberate trade-off, not a flaw.
Where things are heading
The distinction between the two families is narrowing. ZK proof technology is advancing quickly, and EVM-equivalent ZK rollups — capable of running unmodified Ethereum contracts — have moved from theoretical to deployed. Optimistic rollups, meanwhile, are exploring shorter challenge windows and more efficient fraud-proof systems.
Cross-chain interoperability and bridges between rollups are also improving, since a thriving rollup ecosystem creates its own fragmentation problem. Users holding assets on one rollup may want to interact with protocols on another, which reintroduces the complexity rollups were meant to reduce.
Key takeaways
- Rollups execute transactions off-chain and post compressed results to a base layer, reducing fees and increasing throughput while preserving base-layer security.
- Optimistic rollups assume validity by default and rely on fraud proofs submitted within a challenge window — making withdrawals slow but keeping the system simpler to build.
- ZK rollups generate a cryptographic validity proof for every batch, enabling near-instant finality but requiring intensive proof generation and complex engineering.
- The core security trade-off: optimistic rollups need an honest watcher; ZK rollups need cryptographic soundness.
- Both designs require posting transaction data to the base layer — without data availability, users cannot reconstruct state or exit safely.
- EVM compatibility has historically favored optimistic rollups, but ZK-EVM technology is closing that gap rapidly.
Next up: Sidechains and Bridges