Fraud Proof

A fraud proof is a succinct cryptographic argument that demonstrates a state transition posted by a sequencer or proposer is invalid. It typically involves:

• State Merkle Proofs: Providing the minimal data (e.g., account balances, storage slots) needed to recompute a transaction.
• Fault Locator: Pinpointing the specific opcode or step in the transaction execution where the proposer's claim diverges from the correct EVM execution.
• Verification Game: In some designs (like Arbitrum), a multi-round interactive challenge refines the dispute to a single step, which is then verified on-chain cheaply.

In optimistic rollups like Arbitrum One and Optimism, fraud proofs are the primary security guarantee. The system operates on an "innocent until proven guilty" model:

• Challenge Period: After a state root is posted to L1, a 7-day window (typical) allows any honest party to submit a fraud proof.
• Economic Security: Challengers and the sequencer must post bonds; the loser's bond is slashed.
• Data Availability: Fraud proofs require the underlying transaction data to be published on the base layer (L1), ensuring verifiers have the information needed to construct a proof.

Fraud proof designs differ in how the dispute is resolved:

• Interactive Fraud Proofs (e.g., Arbitrum's multi-round challenge protocol): Use a bisection game to reduce a complex dispute to a single, easily verifiable step over several rounds. This minimizes on-chain verification cost.
• Non-Interactive Fraud Proofs (e.g., early Optimism): The challenger submits a single, complete proof of the faulty execution. This proof must re-execute the entire disputed transaction on-chain, which can be gas-intensive for large transactions.

These are the two dominant cryptographic verification paradigms for Layer 2s:

• Fraud Proofs (Optimistic): Assume correctness and only act to prove fraud. Cheaper for complex computation but introduces a challenge delay for finality.
• Validity Proofs (ZK-Rollups): Use zero-knowledge proofs (like zk-SNARKs) to cryptographically prove the correctness of every batch. Provides instant cryptographic finality but requires specialized, computationally intensive proving. The choice defines the trust model and performance characteristics of the scaling solution.

A fraud proof is only possible if the data needed to reconstruct the disputed state is available. This creates a critical dependency:

• On-Chain Data: Rollups that post full transaction data to Ethereum calldata or blobs guarantee data availability, enabling permissionless fraud proofs.
• Data Availability Committees (DACs): Some systems use a trusted committee to hold data off-chain, which introduces an additional trust assumption, as fraud proofs are impossible if the committee withholds data. This is why Ethereum's EIP-4844 (proto-danksharding) is crucial, as it provides cheap, abundant data availability for rollups.

A fraud proof is a compact, verifiable argument that demonstrates a specific transaction or state transition is invalid. It operates on the principle of optimistic execution, where state updates are assumed valid unless proven otherwise. The proof typically contains:

• The specific faulty transaction or state root.
• The minimal witness data (e.g., Merkle proofs) needed to recompute the step.
• A trace showing the correct execution versus the claimed, faulty outcome.

Fraud proofs rely on several critical security assumptions:

• Honest Minority Assumption: At least one honest, vigilant node (a watcher) must be online to detect and submit a challenge.
• Data Availability: The underlying data (e.g., transaction batches) must be published and accessible on the base layer (L1) for anyone to verify the fraud proof's claims.
• Challenge Period: A fixed time window (e.g., 7 days) during which fraud proofs can be submitted. Funds are locked during this period.

There are two primary technical approaches to constructing fraud proofs:

• Interactive Fraud Proofs (Dispute Games): Use a multi-round, interactive challenge-response protocol (like a bisection game) to pinpoint the exact step of disagreement, minimizing on-chain verification costs. Used by Arbitrum.
• Non-Interactive (ZK-fault) Proofs: A single, succinct proof that can be verified on-chain without multiple rounds, though historically more complex to implement. Optimism originally used interactive proofs but has migrated to a multi-proof system.

The system is secured by economic penalties and rewards:

• Staking & Slashing: Sequencers or proposers post a bond (stake) that is slashed if a fraud proof against them is successful.
• Watcher Rewards: The entity submitting a successful fraud proof is often rewarded from the slashed bond, creating an incentive for network surveillance.
• Cost of Attack: An attacker must risk their entire bond for a chance to steal funds, making attacks economically irrational if the bond is sufficiently high.

While powerful, fraud proof systems have inherent limitations:

• Liveness vs. Safety Trade-off: The challenge period introduces a withdrawal delay (liveness issue) to ensure safety.
• Data Availability Problem: If transaction data is withheld, fraud proofs cannot be constructed, leading to potential theft. This is addressed by data availability committees or blob transactions.
• Censorship Resistance: A malicious sequencer could attempt to censor the publication of fraud proof transactions, though base layer inclusion provides a strong counter.

Fraud proofs are fundamentally different from validity proofs (e.g., ZK-SNARKs/STARKs):

• Proving Model: Fraud proofs are disproval-based (optimistic), while validity proofs are attestation-based (cryptographically proven correctness).
• Finality: Validity proofs offer near-instant finality; fraud proofs have a delayed finality due to the challenge window.
• Computational Overhead: Fraud proofs shift verification cost to the challenger only in case of fraud, whereas validity proofs require constant, expensive proof generation.