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 a ZK proof for an L2 block takes specialised hardware ($10K+ GPU clusters) and ~10 minutes per block. zkEVM prover technology is the rate-limiting step.
• Production landscape (2026). OP / Arbitrum = fraud proofs (deployed). ZKsync / Linea / Polygon zkEVM = ZK proofs (deployed). 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. ZK = ~10 minutes (proof generation time). 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 Optimism. You wait seven days. You withdraw from zkSync. You wait about an hour. Both are EVM rollups posting to Ethereum. The 170× difference isn't because Optimism's team is slower — it's because Optimism chose fraud proofs and zkSync chose validity proofs, and that single choice forces every downstream UX decision.

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 (cheap — ~100k gas)
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 withdrawals are instant.

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:

• Instant finality (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: ZK proving costs are dropping fast. SP1, RISC Zero, Polyhedra are all hitting ~$1-10 per proof for an Ethereum block. At this cost, ZK rollups become competitive for general payments.

Tempo (if it goes ZK) would likely use one of these proving systems. Hyperliquid is more likely to stay optimistic for now (their MEV-extraction model doesn't benefit from ZK).

8. For Tempo's decentralization path

If Tempo Moderato is centralized today, the decentralization path likely:

1. Today: centralized sequencer, no fraud/validity proofs (trust Paradigm)
2. Phase 2: optimistic fraud proofs added (anyone can challenge)
3. Phase 3: ZK proofs (instant finality)
4. Phase 4: decentralized sequencer set + ZK proofs

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 / Linea / Polygon zkEVM = ZK proofs (production). Both at scale; ZK is the longer-term direction.
• Withdrawal asymmetry: optimistic 7 days vs ZK 10 minutes. For payment rails ZK wins; for general computation optimistic is currently cheaper. Hybrid optimistic-zk is emerging. Next lesson: build a minimal sequencer.