Light Client Fraud Proof

A light client fraud proof allows a node with only block headers to challenge invalid state transitions. The process involves:

• A full node (or another light client) detecting an invalid transaction or state root in a block.
• The challenger constructing a fraud proof, which is a compact cryptographic proof (e.g., a Merkle proof) pinpointing the specific invalid execution.
• The light client verifies this proof against the known block header. If valid, the light client rejects the fraudulent block, ensuring it does not accept incorrect state.

Optimistic rollups are the primary ecosystem application of fraud proofs. They operate on a "verify, don't trust" model:

• Transactions are batched and posted to a base chain (like Ethereum) with an assertion about the resulting state root.
• During a challenge period (typically 7 days), any watcher can submit a fraud proof if the assertion is incorrect.
• Successful fraud proofs slash the rollup validator's bond and revert the invalid state update. This design allows for high throughput while inheriting the base layer's security for dispute resolution.

For fraud proofs to be constructible, the underlying block data must be available. This is a fundamental prerequisite.

• If a block producer withholds transaction data, a fraud proof cannot be created to prove invalidity, leading to a data availability problem.
• Solutions like Data Availability Sampling (DAS) used by celestia or Ethereum's danksharding ensure light clients can probabilistically verify data is published without downloading it all.
• Without available data, the system defaults to an optimistic security model, relying solely on the honesty of at least one data-available full node.

Some systems use interactive fraud proofs to handle complex disputes efficiently. Instead of proving the entire faulty execution, the protocol uses a multi-round challenge game (a bisection protocol).

• The challenger and the asserter iteratively narrow down their disagreement to a single, simple instruction step.
• This single step is then verified on-chain, minimizing gas costs.
• This approach is crucial for proving fraud in arbitrary EVM or WASM execution, where a single-step proof is vastly cheaper than proving a full block's execution.

This is the key architectural choice for Layer 2 scaling.

• Fraud Proofs (Optimistic): Assume validity unless proven otherwise. Efficient for complex VMs, but has a delay (challenge period) for finality. Used by Arbitrum and Optimism (pre-Bedrock).
• Validity Proofs (ZK-Rollups): Cryptographically prove correctness for every state transition. Provides instant finality and better privacy, but generating proofs is computationally intensive. Used by zkSync and StarkNet.
• The choice impacts trust assumptions, latency, and the types of applications a rollup can support.

Fraud proofs are a stepping stone towards a stateless client paradigm for base layers like Ethereum.

• In this model, even full nodes would not store the entire state. They would verify blocks using witnesses (proofs of state access).
• Fraud proofs would be essential to punish block producers who create blocks with invalid witnesses.
• This would drastically reduce the hardware requirements for network participation, improving decentralization and sync times, while maintaining full security guarantees through cryptographic verification.

A network participant that downloads, validates, and stores the entire blockchain history. It is the authoritative source of truth against which fraud proofs are constructed and verified. Full nodes:

• Process every transaction and state transition.
• Maintain the complete Merkle Patricia Trie for state data.
• Are the provers in a fraud proof system, generating the cryptographic evidence of invalid state transitions.

A cryptographic commitment (typically a Merkle root) that represents the entire state of the blockchain—all account balances, contract code, and storage—at a given block. It is the critical data point for fraud proofs.

• Published in the block header.
• A light client trusts the state root from its connected full node.
• A fraud proof demonstrates that a proposed state root is inconsistent with the agreed-upon transaction history.

A multi-round, challenge-response protocol used to resolve disputes about state validity without requiring a light client to download full blocks. Key steps include:

• Assertion: A full node posts a claim (e.g., a new state root).
• Challenge: A verifier disputes the claim.
• Bisection: Parties iteratively narrow down the point of disagreement to a single instruction or storage slot.
• One-Step Proof: The dispute is resolved by executing a single step on-chain, proving fraud.

The guarantee that all data necessary to validate a block (e.g., transaction data) is published and accessible to network participants. It is a prerequisite for fraud proofs.

• If data is withheld (data withholding attack), validators cannot reconstruct the block to check for fraud.
• Solutions like Data Availability Sampling (DAS) and Erasure Coding allow light clients to probabilistically verify data is available.

A Layer 2 scaling solution that heavily relies on fraud proofs for security. It operates on the principle of optimistic execution:

• Transactions are batched and posted to Ethereum (Layer 1).
• State updates are assumed valid.
• A challenge period (e.g., 7 days) allows anyone to submit a fraud proof if a state root is incorrect.
• Light clients can use these proofs to verify rollup state securely.

An alternative cryptographic security mechanism to fraud proofs. Instead of detecting invalid state after the fact, a validity proof (e.g., a zk-SNARK or zk-STARK) cryptographically proves a state transition was executed correctly.

• Provides instant finality with no challenge period.
• Requires significant computational resources to generate.
• Light clients for ZK rollups verify a small proof, not the entire computation.