Fraud Proof Window

The Fraud Proof Window is a fixed, pre-defined time delay (typically 7 days) between a state root being proposed on L1 and its finalization. This period allows any honest verifier to download the rollup's data, re-execute transactions, and submit a fraud proof if they detect an invalid state transition. The length of this window is a security parameter that directly trades off between withdrawal latency and the cost of potential attacks.

Security is enforced economically. A sequencer or proposer must post a substantial bond when submitting a state root. If a fraud proof is successfully submitted within the window, the malicious proposer's bond is slashed (partially burned and part awarded to the challenger). This makes submitting fraudulent batches financially irrational, as the cost of the slashed bond outweighs any potential gain from the fraud.

For the fraud proof window to be effective, the transaction data for the disputed batch must be available on the base layer (L1). This is known as Data Availability (DA). If data is withheld, verifiers cannot reconstruct the state to check for fraud, breaking the security model. Solutions like Ethereum calldata or dedicated Data Availability Committees (DACs) are used to ensure this data is published.

A key challenge is the Verifier's Dilemma: since submitting a fraud proof requires computational work and gas fees, rational participants may assume someone else will do it. If everyone assumes this, no one verifies. The system relies on the existence of at least one altruistic or specially incentivized verifier (e.g., a protocol with watchtower services) to monitor the chain and submit proofs when necessary.

Optimistic Rollups with a fraud proof window use an optimistic ("innocent until proven guilty") security model. This contrasts with ZK-Rollups, which use validity proofs (cryptographic proofs of correct execution) for every batch. The trade-off is that fraud proofs have a long finality delay but are generally less computationally intensive to generate, while validity proofs provide instant finality but require complex, specialized proving systems.

User withdrawals of assets from the rollup to the base layer are directly impacted. When a user initiates a withdrawal, they must wait for the entire fraud proof window to elapse without a successful challenge before funds are released on L1. This creates a significant latency (e.g., 7 days) for withdrawals, which is a primary UX drawback of the optimistic approach. Liquidity providers often offer faster withdrawal services by bridging this trust gap for a fee.

A fraud proof window is a mandatory delay period (typically 7 days) during which newly published state roots on an optimistic rollup are considered pending and can be challenged. This mechanism enables trust-minimized scaling by assuming transactions are valid by default, only running expensive computation to verify correctness if a challenge is submitted. It is the fundamental security model that allows optimistic rollups to inherit Ethereum's security without executing every transaction on L1.

The window length creates a direct trade-off between security guarantees and withdrawal finality. A longer window (e.g., 7 days) provides more time for honest validators to detect and submit fraud proofs, increasing security. However, it forces users to wait the full duration for their funds to be finalized on L1, creating poor user experience for withdrawals. This is the primary UX drawback of the optimistic model.

The system's security relies on the honest majority assumption and economic incentives. It assumes at least one honest, vigilant node (a verifier) is monitoring the chain and will submit a fraud proof if needed. To disincentivize false claims, challengers must post a bond that is slashed if their challenge is invalid. The required bond size and the value secured must be balanced to prevent both malicious challenges and profitable attacks.

Fraud proofs are only possible if the underlying transaction data is available on the base layer (L1). This is enforced via data availability solutions like calldata or blobs. If data is withheld (a data availability attack), verifiers cannot reconstruct the state to create a proof, making challenges impossible. Therefore, the fraud proof window's security is contingent on guaranteed data availability.

To protect users if the sequencer becomes malicious or censors transactions, optimistic rollups implement escape hatches (or force exit mechanisms). These allow a user to submit a request directly to an L1 contract. After the fraud proof window elapses without a challenge to this request, the user can withdraw their funds, providing censorship resistance even without an active verifier.

Contrasts with ZK-rollups, which use validity proofs (e.g., SNARKs, STARKs). Key differences:

• No Challenge Period: ZK-rollups provide immediate finality upon proof verification on L1.
• Different Trust Model: Security relies on cryptographic proofs, not economic games and honest verifiers.
• Computational Overhead: ZK-rollups incur constant proving cost, while optimistic rollups only pay for computation in the event of a challenge.

A state root is a cryptographic commitment (a Merkle root) that represents the entire state of the rollup chain (account balances, contract code, storage) at a given point. The sequencer periodically posts these to L1.

• Fraud proofs are executed to verify the correctness of a proposed state root.
• An invalid state root is the trigger for initiating a challenge within the fraud proof window.

The sequencer is the node responsible for ordering transactions, executing them, and generating new state roots in an optimistic rollup. It acts as a prover whose work is presumed valid.

• It posts transaction batches and state commitments to the L1.
• Its outputs are subject to verification via fraud proofs during the challenge window.
• Can be centralized (single operator) or decentralized (validator set).

A verifier is any participant (typically a full node) in the optimistic rollup network that monitors the sequencer's published state roots. Their role is to:

• Independently re-execute transactions from published batch data.
• Detect discrepancies between their computed state root and the one posted on-chain.
• If a fault is found, they construct and submit a fraud proof within the challenge window.

The dispute resolution game is the interactive protocol executed when a fraud proof is submitted. It is a multi-round, bisection-based challenge that efficiently pinpoints a single step of execution where the sequencer and verifier disagree.

• Minimizes the on-chain computation needed to resolve a fraud claim.
• Used by systems like Arbitrum Nitro to make fraud proofs efficiently verifiable on L1.