Lesson 4 — Fraud proofs vs validity (ZK) proofs

Question

A rollup's state root on L1 is asserted by the sequencer. How does L1 know it's correct? Two answers: optimistic + fraud proofs (assume correct, allow challenges) or ZK validity proofs (verify a cryptographic proof on every commit). Both are deployed in production. The trade-off is concrete.

Principle (minimum model)

• Fraud proofs (optimistic). The sequencer commits a state root; anyone can submit a fraud proof during a challenge window (7 days on OP). If a fraud proof is valid, the state root is rolled back. After the window, the state root is final.
• ZK validity proofs. The sequencer commits a state root and a ZK proof. L1 verifies the proof; if valid, the state root is immediately final (no challenge window).
• Fraud-proof cost: 7-day finality. Withdrawals from optimistic rollups must wait 7 days for finality (challenge window). This is the main user-facing cost.
• ZK-proof cost: prover hardware + complexity. Generating ZK proofs for L2 blocks takes specialised hardware (typically GPU clusters) and proving time. zkEVM prover technology is the rate-limiting step.
• Production landscape (2026). OP Mainnet (permissionless fault proofs since June 2024) / Arbitrum One (BoLD since February 2025) = fraud proofs. ZKsync Era / Linea / Scroll = ZK proofs. Both production at scale; ZK is the longer-term direction as prover tech improves.
• Hybrid: optimistic-zk. Run optimistic by default; if no challenge, finalize. If challenged, generate a ZK proof for the disputed range. Best of both worlds (for some use cases).
• Withdrawal asymmetry. Optimistic = 7 days (the challenge window). ZK = proving time plus any delay the chain adds on purpose (ZKsync Era: a governance-set security time lock, 24 hours since October 2026). For payment rails, ZK is the right answer; for general-purpose computation, optimistic is currently cheaper.
• Why both will coexist. Fraud proofs are simpler to deploy; ZK gets cheaper every year as prover tech improves. Different rollups make different trade-offs.

Worked example + steps

Fraud proofs vs validity (ZK) proofs

You withdraw from OP Mainnet. You wait seven days. You withdraw from ZKsync Era. You wait at least a day: a security time lock set by governance — raised from 3 to 24 hours on 2026-10-07 (ZIP-17 update; see also ZKsync docs) — plus the time for your batch to be committed, proven and executed. Both are EVM rollups posting to Ethereum. The gap isn't because Optimism's team is slower — it's because OP Mainnet uses fraud proofs, whose 7-day challenge window is the price of not proving anything up front, while ZKsync uses validity proofs, so its delay is proving time plus a time lock that governance chose and can change.

A rollup's L1 contracts trust the sequencer's state root claims for a fixed period (the challenge window). After the window closes, the state root is final. The two paradigms for what happens during the window are fraud proofs (challenge-based — "trust unless proven wrong") and validity / ZK proofs (cryptographic — "always require a proof of correctness"). Optimistic or ZK: pick one. Everything else follows.

1. The state root commitment problem

A sequencer submits a state root to L1 every ~1 hour. The L1 contract must decide: is this state root correct?

Options:

1. Trust it always — pure trust, no proofs (validium / sidechain)
2. Trust it, but let challengers prove it wrong — fraud proofs (optimistic)
3. Require a proof of correctness — validity proofs (ZK)

Each makes different trade-offs.

2. Fraud proofs — the optimistic model

Sequence:

1. Sequencer posts state root S on L1
2. Challenge window opens (7 days for OP Stack)
3. During window, anyone can submit a fraud proof showing S is incorrect
4. If valid fraud proof submitted, S is rejected, the chain reorgs
5. After 7 days, S is final

The fraud proof itself is a proof of incorrect execution: "the sequencer claimed tx T results in state S, but actually it results in state S'." The L1 contract re-runs the disputed step in a verifier game.

sequenceDiagram
    participant Seq as Sequencer
    participant L1 as L1 Output Oracle
    participant Challenger
    participant Verifier as Fraud Proof Verifier

    Seq->>L1: Submit state root S (claim)
    Note over L1: 7-day challenge window opens
    Challenger->>Challenger: Detect S is wrong
    Challenger->>Verifier: Submit fraud proof
    Verifier->>Verifier: Re-execute disputed step
    Verifier->>L1: S is invalid
    L1->>L1: Reject state root, reorg chain

The trade-off: anyone can challenge, but you have to wait 7 days before finality.

3. Validity (ZK) proofs — the cryptographic model

Sequence:

1. Sequencer produces L2 blocks
2. Sequencer (or a separate prover) generates a ZK proof that the L2 execution is correct
3. Proof is submitted to L1 along with the new state root
4. L1 contract verifies the proof (a few hundred thousand gas; SP1's docs give ~270k gas for a Groth16 proof)
5. If proof verifies, state root is immediately final

No challenge period. No waiting.

sequenceDiagram
    participant Seq as Sequencer
    participant Prover
    participant L1 as L1 Verifier
    participant User

    Seq->>Seq: Build L2 blocks
    Seq->>Prover: Send execution trace
    Prover->>Prover: Generate ZK proof (~minutes/hours)
    Prover->>L1: Submit proof + new state root
    L1->>L1: Verify proof (~ms on-chain)
    L1->>L1: State root finalized immediately
    User->>L1: Can withdraw without waiting

The trade-off: proving is expensive (compute, time, gas), but there is no challenge window to wait out (a chain may still add its own delay, as ZKsync Era does).

4. The cost comparison

For high-frequency batches (sub-hour), ZK is more expensive per batch. For low-frequency, optimistic is cheaper but slower to finalize.

Optimistic wins for:

• Lower L1 cost
• Mature tooling
• General EVM compatibility

ZK wins for:

• No challenge window (no 7-day wait)
• Better for cross-chain interop (other chains can trust proofs)
• Better for compliance (auditable proofs)

5. Reading fraud proof code — OP Stack Cannon

OP Stack's fraud proof system is called Cannon. The non-obvious move: instead of re-running the entire L2 on L1 (impossible — way too expensive), Cannon re-runs a single disputed MIPS instruction in a constrained MIPS VM running on L1.

The flow:

1. Challenger asserts "step X is wrong"
2. Bisection game: both parties narrow down to a single MIPS instruction
3. L1 contract executes that single instruction
4. Wins whoever proves the instruction's correct/incorrect result

ethereum-optimism/optimism/cannon is the codebase.

The bisection-to-one-instruction pattern is what makes fraud proofs feasible at all — without it, you'd be asking L1 to re-execute potentially years of L2 history.

6. Reading ZK proof code — SP1 + Reth

succinctlabs/sp1 is a zkVM that can prove EVM execution via revm. The flow:

1. Reth executes the L2 block (normal execution)
2. SP1's "guest program" wraps revm execution
3. SP1 generates a proof that revm produced the claimed state changes
4. Proof submitted on-chain

For Reth-based ZK rollups: the same revm code runs in execution and in proving. This is why Rust EVM stack matters for ZK rollups.

7. The future — RISC Zero, SP1, and ZK rollups on Reth

The 2025-2026 trend: zkVM proving (SP1, RISC Zero and others) keeps getting cheaper and faster, and Succinct now ships OP Succinct, a ZK proving engine for OP Stack chains. As costs fall, ZK rollups become competitive for general payments.

A payments rollup going ZK would likely use one of these proving systems. Tempo and Hyperliquid are L1s with BFT finality, so they have no rollup withdrawal proof to choose.

8. A single-sequencer rollup's decentralization path

For an OP Stack chain that starts with one sequencer and no proofs, the path is:

1. Start: centralized sequencer, no fraud/validity proofs (trust the operator)
2. Phase 2: permissionless fault proofs (OP Stack's Cannon-based fault proofs; anyone can challenge)
3. Phase 3: ZK proofs (faster withdrawals)
4. Phase 4: decentralized sequencer set + ZK proofs

Tempo, by comparison, is an L1: its validators run Simplex BFT consensus (via Commonware) and finalize blocks themselves (tempoxyz/tempo), so this rollup path doesn't apply to it.

Each step adds trust-minimization at the cost of complexity and operational overhead.

9. Practice

1. Read Optimism's fraud proof spec
2. Read SP1's EVM proving guide
3. Calculate: at $5 per ZK proof for 1 batch and $1 fraud proof verification, when does ZK become cheaper than optimistic for a high-throughput chain?
4. Identify: when would a chain not want ZK proofs even if cheap?

10. Reading list

• Vitalik's fraud proof intro
• Cannon (OP Stack fraud proofs)
• SP1 (ZK proving)

Final check: in one sentence, why does the choice between fraud proofs and validity proofs determine everything else about a rollup's UX? If your answer doesn't reference "withdrawal delay" or "trust window," re-read §2-§4.

Summary (3 lines)

• Two state-root verification models: fraud proofs (optimistic, 7-day challenge window) and ZK validity proofs (immediate finality, expensive prover).
• OP / Arbitrum = fraud proofs (production). ZKsync Era / Linea / Scroll = ZK proofs (production). Both at scale; ZK is the longer-term direction.
• Withdrawal asymmetry: optimistic 7 days (challenge window) vs ZK proving time plus any chain-set delay (ZKsync Era: ≥24 h time lock since October 2026). For payment rails ZK wins; for general computation optimistic is currently cheaper. Hybrid optimistic-zk is emerging. Next lesson: build a minimal sequencer.