Fraud Proof

In an optimistic rollup, state transitions are assumed valid but can be challenged during a dispute window (typically 7 days). A fraud proof is the formal challenge submitted by a network participant (verifier) that proves a sequencer posted an invalid state root. This mechanism allows the system to inherit the security of the underlying L1 (like Ethereum) without requiring all nodes to re-execute every transaction.

A sophisticated challenge protocol where the verifier and the sequencer engage in a multi-round bisection game (or dispute game) on-chain. They iteratively narrow down the dispute to a single instruction or state transition, minimizing the computational load and gas cost required for the L1 to adjudicate the fraud. This is the model used by Arbitrum and Optimism (with its Cannon fault proof system).

A single, succinct proof that can be verified on-chain without an interactive game. While similar in concept to a Validity Proof, it is generated only in the case of a suspected fault. This model aims to reduce the complexity and latency of the challenge process. Optimism's upcoming Superchain architecture is migrating to this model with its Cannon proof system.

Fraud proofs are secured by cryptoeconomic incentives. To post a state root, a sequencer must stake a bond. A successful fraud proof results in the slashing of this bond, which is used to reward the verifier who submitted the proof. This creates a strong disincentive for malicious behavior and aligns the system's security with financial penalties.

A core tenet is that anyone can be a verifier and submit a fraud proof. This permissionless watchtower model ensures censorship resistance and decentralization of the security function. Verifiers run a full node of the rollup, monitor state commitments posted to L1, and are economically incentivized to challenge invalid outputs to claim the sequencer's slashed bond.

This highlights the two dominant L2 security models:

• Fraud Proofs (Optimistic): Assume validity, with a challenge period for corrections. Offers lower computational overhead for provers but introduces a withdrawal delay.
• Validity Proofs (ZK-Rollups): Use Zero-Knowledge proofs (like zk-SNARKs/zk-STARKs) to cryptographically prove correctness for every batch. Offers immediate finality and no challenge period, but requires specialized proving hardware. Both aim to scale Ethereum while leveraging its security.

A fraud proof system relies on a challenge period (e.g., 7 days) where any network participant can dispute an invalid state root published by a sequencer. During this window, assets are locked and cannot be withdrawn. This creates a strong economic disincentive for fraud, as honest actors have ample time to detect and submit proof of an invalid transaction.

For a fraud proof to be constructed, the transaction data must be available. If a sequencer posts an invalid state root but withholds the underlying data, verifiers cannot generate the proof to challenge it. This is why solutions like optimistic rollups must post their transaction data to a data availability layer (like Ethereum's calldata or a dedicated DA layer), making it a non-negotiable security assumption.

The security model of fraud proofs relies on the "single honest verifier" assumption. It only requires one honest, economically rational participant with sufficient technical capability to monitor the chain and submit a proof. The system's safety does not depend on a majority of honest actors, which is a key difference from pure consensus-based systems.

• Interactive Fraud Proofs: Involve a multi-round challenge game (e.g., a bisection protocol) between the challenger and the sequencer to pinpoint the exact step of execution where fraud occurred. This minimizes computational load on the verifier.
• Non-Interactive Fraud Proofs (zk-proofs): A validity proof (like a ZK-SNARK) is submitted with every block, proving correctness instantly. This removes the challenge window but requires more complex cryptography.

Real-world implementations face complex risks:

• Liveness Attacks: A malicious actor could spam challenges to delay withdrawals, even if all state roots are valid.
• Prover Censorship: If the only entity capable of generating a fraud proof is censored, fraud could go unchallenged.
• Bridging Vulnerabilities: The smart contract bridge that verifies fraud proofs on the parent chain becomes a critical, high-value attack target.

Fraud proofs are the security backbone of optimistic rollups, while validity proofs (zero-knowledge proofs) secure ZK-rollups. The key trade-off:

• Fraud Proofs: Assume honesty but allow for verification (optimistic). They are computationally cheaper to generate but require a long challenge period for security.
• Validity Proofs: Cryptographically guarantee correctness (pessimistic). They enable instant finality but require significant, specialized computation to generate.

A more general term often used synonymously with fraud proof. Technically, a fault proof system can be designed to detect any fault (including liveness failures), while a classic fraud proof specifically detects invalid state transitions resulting from malicious intent. In practice, the terms are frequently used interchangeably within the context of Optimistic Rollups to describe the mechanism that allows a single honest party to prove an error to the L1 contract.

A multi-round, game-like dispute resolution protocol that splits a complex computation claim into smaller and smaller steps (often using bisection) until a single, easily verifiable instruction is identified. This makes fraud proofs efficient and practical, as the L1 contract only needs to verify a single step of computation, not an entire batch. This is a key innovation that makes Optimistic Rollups like Arbitrum's Nitro feasible.

A mandatory time delay (e.g., 1-7 days) during which funds cannot be withdrawn from an Optimistic Rollup back to Layer 1. This window provides time for anyone to submit a fraud proof if they detect an invalid state root. It represents a trade-off between security and withdrawal latency. A longer period increases security but delays user experience; a shorter period increases risk. Validity-proof-based systems (ZK-Rollups) do not require a challenge period.