How do rollups work? Optimistic vs ZK rollups explained

A rollup executes transactions off Ethereum but publishes enough data to Ethereum that anyone can rebuild its state, and it has Ethereum judge whether each new state is correct. The two families differ only in how Ethereum judges. Optimistic rollups (Arbitrum, OP Stack chains such as OP Mainnet and Base) assume a posted state is valid unless someone proves it wrong during a challenge window. ZK rollups (Starknet, zkSync Era, Scroll, Linea) post a cryptographic validity proof that L1 verifies before accepting the state.

The parts every rollup has

1. Sequencer. Orders user transactions and produces L2 blocks quickly. On most rollups today this is a single operator.
2. Data publication. Batches of transactions (or state diffs) are posted to Ethereum. Since the Dencun upgrade (EIP-4844) most rollups use blobs, which are cheaper than calldata and are pruned by consensus nodes after about 18 days. That is long enough for anyone to download and verify them.
3. State commitment. A contract on L1 records claimed L2 state roots.
4. Bridge contract. Holds deposited assets on L1 and releases them against a state root that L1 has accepted.
5. Proof system. The piece that convinces L1 a state root is correct. This is where the two families split.

Posting the data to L1 is what makes it a rollup. If the data lives somewhere else (a committee or a separate DA layer), the design is usually called a validium or optimium, and it adds that data provider as a trust assumption.

Optimistic rollups: fault proofs

A proposer posts a state root and puts up a bond. Nobody proves anything unless there's a dispute. During the challenge window (about a week on Arbitrum One and OP Mainnet), any honest party that re-executes the batches and gets a different result can challenge.

Disputes are settled by interactive bisection. The two sides keep splitting their disagreement in half, first over blocks, then over the steps of execution, until they disagree about a single instruction. L1 then executes just that one step on-chain and decides who is right. The loser forfeits their bond.

• Arbitrum compiles its state transition function to WebAssembly (WAVM) and proves single WAVM steps on L1. Its current dispute protocol, BoLD, lets anyone take part in validation and is designed to bound how long a dispute can drag on.
• OP Stack runs its fault proof program on Cannon, a MIPS emulator whose single steps can be checked on L1, inside a dispute game contract.

The security assumption is one honest verifier: as long as at least one party watches and challenges within the window, a bad state root can't finalize. The cost is the withdrawal delay. Moving funds from L2 to L1 through the canonical bridge waits out the full window. Third-party "fast withdrawal" bridges pay you sooner by fronting liquidity and taking on the risk themselves.

ZK rollups: validity proofs

A prover generates a SNARK or STARK showing that applying the batch to the old state root produces the new one. The L1 verifier contract checks the proof, which costs roughly the same however many transactions it covers. Once it's verified, the state is final as far as L1 is concerned. No challenge window is needed.

The trade-offs:

• Proving is expensive. Generating proofs for general EVM execution takes serious compute, so proofs are batched and withdrawals wait until the batch is proven. That is usually much faster than a week, but not instant.
• EVM equivalence varies. Some zkEVMs aim to match Ethereum at the bytecode level. Others compile Solidity to a different VM, where some opcodes, precompiles or gas costs behave differently. Starknet uses its own language, Cairo.
• Circuit bugs are a real risk. A soundness bug in a prover or verifier could accept an invalid state. For that reason, many deployments keep upgrade keys or extra safeguards around the verifier.

Side by side

	Optimistic	ZK
Correctness	Assumed; disputes via fault proofs	Proven for every batch
Trust assumption	At least one honest, live challenger	Soundness of the proof system and its implementation
L2→L1 withdrawal (canonical bridge)	Challenge window, about a week	After proof is verified on L1
Operator cost	Low; proofs only on dispute	High; proof for every batch
EVM compatibility	Very high	Varies by zkEVM

What to watch as a developer

Sequencer trust is separate from proof trust. A centralized sequencer can censor or reorder, but it cannot forge state. Both families offer a path to force a transaction through L1 if the sequencer ignores you, though it is slow. Arbitrum uses a delayed inbox; OP Stack uses L1 deposit transactions.

block.number differs across rollups. On Arbitrum it returns an approximate L1 block number. Use the ArbSys precompile for the L2 block number:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface ArbSys {
    function arbBlockNumber() external view returns (uint256);
}

contract Timing {
    ArbSys constant ARB_SYS = ArbSys(0x0000000000000000000000000000000000000064);

    function blocks() external view returns (uint256 l1Estimate, uint256 l2Block) {
        l1Estimate = block.number;          // on Arbitrum: approximate L1 block number
        l2Block = ARB_SYS.arbBlockNumber(); // the Arbitrum block number
    }
}

On OP Stack chains, block.number is the L2 block number. Prefer block.timestamp for time-based logic that has to be portable.

L1→L2 senders are aliased. When an L1 contract sends a message to L2 on Arbitrum or OP Stack, msg.sender on L2 is the L1 address plus 0x1111000000000000000000000000000000001111. This stops an L1 contract from impersonating an L2 contract at the same address. If you authorize an L1 contract, compare against the aliased address:

library AddressAlias {
    uint160 internal constant OFFSET = uint160(0x1111000000000000000000000000000000001111);

    function applyL1ToL2Alias(address l1Address) internal pure returns (address) {
        unchecked { return address(uint160(l1Address) + OFFSET); }
    }
}

"Confirmed" means different things. A sequencer receipt is a soft promise. The batch landing in a finalized L1 block fixes ordering. For withdrawals, the state root also has to pass the challenge window or be proven.

Summary

1. Rollups execute off-chain, publish data to L1, and prove state to an L1 contract.
2. Optimistic rollups use bonded claims, a challenge window and bisection down to one instruction. Security needs one honest watcher, and withdrawals wait about a week.
3. ZK rollups verify a validity proof for every batch. There's no challenge window, but proving costs more and EVM equivalence varies.
4. Check your rollup's block.number semantics, alias L1 senders, and don't treat sequencer receipts as final for high-value actions.