Rollup Architecture Deep Dive: Optimistic Rollups vs. ZK-Rollups

Optimistic Rollups: Fault Proofs, Challenge Windows & Interactive Bisection Games

Optimistic Rollups (such as Arbitrum One, OP Mainnet, and Base) operate on an "optimistic assumption": the Layer-1 bridge assumes all state roots submitted by sequencers are valid by default without verifying execution on-chain.

To prevent malicious sequencers from stealing user funds or publishing forged state roots, Optimistic Rollups enforce a 7-day Dispute Challenge Window and an on-chain Fraud Proof / Fault Proof system.

The Dispute Protocol operates as follows:

1. State Assertion: The proposer posts a bond (e.g., 50 ETH) and submits a state claim asserting that after executing batch $B$, the L2 state transitions from $S_{\text{pre}}$ to $S_{\text{post}}$.
2. Challenge Initiation: If a verifier node (challenger) detects an invalid state root, the challenger posts a matching bond and initiates a dispute on the Layer-1 dispute contract.
3. Interactive Bisection Game: Rather than re-executing an entire complex block on Layer-1 (which would exceed the L1 block gas limit), modern optimistic rollups (Arbitrum Nitro and Optimism Cannon) conduct an interactive binary search over the disputed execution trace:
4. In round 1, the proposer asserts the midpoint state at step $N\mathrm{/}2$. The challenger declares whether the error occurred before or after $N\mathrm{/}2$.
5. The trace interval is halved ($N\mathrm{/}4,N\mathrm{/}8,\dots$) in successive back-and-forth interactive on-chain turns until the dispute is narrowed down to a single instruction step (a single EVM opcode or MIPS/WAVM CPU cycle).
6. One-Step Prover Execution: The L1 smart contract executes that single isolated instruction step inside an on-chain interpreter (OneStepProver). If the proposer was dishonest, the proposer's bond is slashed, the fraudulent state root is rolled back, and the honest challenger is rewarded.

The primary operational tradeoff of optimistic rollups is the 7-day withdrawal delay required to allow verifiers sufficient time to detect and challenge invalid assertions on L1. Fast liquidity bridge protocols (such as Across and Hop) circumvent this delay for retail users by using market makers who front liquidity instantly in exchange for a small fee.

Zero-Knowledge Rollups: Validity Proofs, zkEVM Architectures & Instant Finality

Zero-Knowledge Rollups (ZK-Rollups, such as Starknet, zkSync Era, Linea, Polygon zkEVM, and Scroll) eliminate the 7-day dispute window entirely by replacing optimistic game-theoretic assumptions with mathematically irrefutable cryptographic Validity Proofs (typically SNARKs or STARKs).

In a ZK-Rollup, the off-chain operator (Prover) executes a batch of $N$ transactions, generates a succinct cryptographic proof $\pi$, and submits $\pi$ along with the new state root to the on-chain Verifier Contract on Ethereum.

The L1 verifier contract executes a succinct algebraic verification algorithm (taking constant time $O(1)$ or logarithmic time $O(\log N)$ in gas, regardless of whether the batch contained 10 or 100,000 transactions). If $\text{Verify}(\text{vk},\text{publicInputs},\pi )==\text{true}$, the state root is updated immediately with absolute mathematical finality.

The core challenge of ZK-Rollups has historically been the construction of the zkEVM (Zero-Knowledge Ethereum Virtual Machine). Traditional EVM design incorporates cryptographic hash functions (Keccak-256), 256-bit word sizes, and dynamic memory models that are extremely expensive to represent in algebraic polynomial circuits.

zkEVMs are categorized by Vitalik Buterin into distinct compatibility types:

• Type-1 (Fully Ethereum-equivalent): Exact consensus and state equivalence with Ethereum (e.g., Taiko, Privacy & Scaling Explorations). Generates proofs for native Ethereum blocks directly, but requires massive proving compute times.
• Type-2 (Fully EVM-equivalent): Exact bytecode equivalence with EVM applications. Compatible with all existing Solidity tools, but modifies state tree structures for easier algebraic polynomial translation (e.g., Scroll, Polygon zkEVM, Linea).
• Type-3 (Almost EVM-equivalent): EVM-compatible but removes complex precompiles and modifies stack operations to optimize prover latency.
• Type-4 (High-Level Language equivalent): Compiles high-level smart contract code (Solidity, Vyper) into custom ZK-friendly Intermediate Representations (IR) and execution bytecodes (e.g., zkSync Era via LLVM, Starknet via Cairo). Provides hyper-fast proving throughput but requires custom compiler toolchains.

## Sequencer Economics, Decentralization & Shared Sequencer Networks

The Sequencer is the primary operational engine of a rollup. It performs continuous transaction ingestion, immediate soft-finality confirmation (sub-second user feedback), and batch assembly.

However, almost all major production rollups operate with Centralized Sequencers run by their foundation teams. While a centralized sequencer cannot steal user funds (because it cannot forge valid state transitions without violating proof rules), it introduces two critical systemic risks:

1. Censorship & Priority Extraction: The sequencer can arbitrarily reorder, delay, or censor user transactions, or monopolize MEV extraction across the rollup.
2. Liveness Failures: If the single sequencer server crashes or experiences a network outage, the entire rollup halts processing new transactions.

To mitigate censorship, all production rollups maintain an on-chain "Escape Hatch" (Force Inclusion Queue) on Layer-1. If a user is censored on L2, they can deposit their transaction directly into the L1 Inbox contract. If the sequencer fails to include the forced transaction within a predefined timeout window (e.g., 24 hours), the rollup enters emergency mode, allowing any permissionless user to propose state roots or withdraw assets.

To permanently solve sequencer centralization, the industry is transitioning to Decentralized and Shared Sequencer Networks (such as Espresso, Astria, and Radius). A shared sequencer network runs a dedicated Byzantine Fault Tolerant (BFT) consensus protocol among hundreds of independent nodes, providing atomic cross-rollup composability, shared mempools, and fair sequencing auctions across multiple rollups simultaneously.

Calldata vs. EIP-4844 Blobs: The Economics of Rollup Posting Costs

Before the Ethereum Dencun upgrade (March 2024), rollups published all compressed transaction data directly into Ethereum Mainnet calldata. Because calldata competes directly with standard DeFi transactions for base-layer execution gas, rollup posting costs were volatile and expensive, accounting for over $85\mathrm{\%}$ to $95\mathrm{\%}$ of total rollup user transaction fees.

EIP-4844 (Proto-Danksharding) fundamentally revolutionized rollup economics by introducing Blob-Carrying Transactions.

Blobs are temporary data payloads (128 KB per blob, up to 6 blobs per L1 block) attached to Ethereum blocks that possess distinct economic characteristics:

• Ephemeral Storage: Blob data is not stored in permanent EVM state; it is pruned from Ethereum consensus nodes after approximately 18 to 40 days. This duration is sufficient for optimistic fraud proof challenge windows and ZK validity proof verifications while preventing permanent disk bloat for L1 validators.
• Independent Fee Market: Blobs use an independent EIP-1559 dynamic pricing curve (Blob Gas) decoupled from standard execution gas.

When rollups migrated from calldata to EIP-4844 blobs, L2 transaction fees plummeted by $90\mathrm{\%}$ to $99\mathrm{\%}$, reducing simple token transfer and swap fees from $0.50-$2.00 down to sub-penny levels ($0.001-$0.02), making high-frequency on-chain applications economically viable.

Volitions, Validiums & Hybrid Data Availability Architectures

While posting transaction data to Ethereum blobs provides the highest tier of decentralized data availability, high-throughput consumer applications (such as on-chain gaming, social protocols, and micro-payment networks) require even lower fee structures than L1 blobs can provide.

To cater to varying security requirements, modern rollup frameworks support Hybrid Data Availability Architectures:

1. Validiums: ZK-Rollups that execute off-chain validity proofs on Ethereum but store transaction data off-chain on dedicated Data Availability Committees (DACs) or specialized DA layers (like Celestia or EigenDA). If the DA layer withholds data, funds cannot be stolen (due to ZK validity proofs), but state freeze can occur.
2. Optimiums: Optimistic rollups that publish data to external DA layers instead of Ethereum.
3. Volitions (e.g., Starknet Volition): Flexible protocols that allow users or smart contract functions to choose the data storage mode per transaction: high-value financial transactions post data directly to Ethereum blobs for maximum security, while micro-transactions use cheap off-chain validium storage.

This spectrum allows developers to calibrate the precise tradeoff between settlement cost and security tier dynamically within a unified smart contract ecosystem.

Frequently asked questions

Why do Optimistic Rollups have a 7-day withdrawal delay?

The 7-day challenge window gives honest verifiers sufficient time to detect an invalid state root published by a sequencer, download the transaction data, and submit an on-chain fraud proof to slash the malicious sequencer.

Can a centralized sequencer steal user funds on a rollup?

No. On an optimistic rollup, submitting a fraudulent state root that steals funds will be challenged and slashed during the 7-day dispute period. On a ZK-rollup, a fraudulent state root cannot generate a valid mathematical ZK proof.

What is the main advantage of ZK-Rollups over Optimistic Rollups?

ZK-Rollups provide near-instant finality and immediate withdrawals to Layer-1 (minutes instead of 7 days) because state transitions are proven valid using cryptographic mathematics rather than challenge windows.

Related reading

• ZK validity proof mathematics and circuit verification — Explore the cryptographic proving systems that power zero-knowledge rollups.
• L2 data availability posting and blob gas — Understand where rollups publish compressed execution data for settlement.

## Sources

• Arbitrum documentation: fraud proofs and the challenge protocol — Arbitrum
• Optimism documentation: fault proofs and the Superchain — Optimism
• zkSync documentation: validity proofs and the prover — zkSync

No contributor to this article holds a professional cryptography or security credential. Every technical claim above is sourced to primary protocol documentation rather than to personal authority — follow the sources and verify anything you intend to act on.

Not financial advice. Crypto assets are volatile and can lose value. This article describes how protocols work, not what you should buy.