Dispute Game

A dispute game is an interactive protocol where a challenger and a defender (prover) engage in a series of moves to pinpoint a single point of disagreement. The process starts with a broad claim (e.g., "this state root is correct") and iteratively bisects the execution trace until the disagreement is isolated to a single instruction or state transition. This mechanism efficiently proves fraud without requiring a full re-execution on-chain.

The core mechanism for narrowing a dispute. The protocol forces participants to repeatedly split a disputed execution interval into smaller segments.

• Step 1: Challenger claims the output for a large block of transactions is invalid.
• Step 2: Defender must provide the intermediate state hash at the midpoint.
• Step 3: Challenger identifies which half contains the error. This process repeats until the dispute is isolated to a single step, which can be verified on-chain with minimal gas cost.

The final, on-chain verification that resolves the dispute game. After bisection isolates the disagreement to a single state transition (e.g., one opcode execution), a one-step proof is submitted. This proof is a small, self-contained cryptographic argument that can be verified by the L1 smart contract. It conclusively demonstrates whether the specific instruction was executed correctly, settling the entire dispute based on the outcome of this minimal computation.

Dispute games use cryptoeconomic security to ensure honest participation. Both the challenger and defender must post a security bond to participate. The bond of the losing party is slashed, with a portion awarded to the winner. This system:

• Deters frivolous challenges that waste network resources.
• Incentivizes honest validation by rewarding correct challenges.
• Ensures it is economically irrational to defend an invalid state transition.

Anyone with the required bond can act as a challenger, creating a decentralized security model. This is a key improvement over centralized multi-sig committees. The system's security relies on the existence of at least one honest and watchful participant (the honest minority assumption). This permissionless design eliminates trust in a specific set of actors and aligns with blockchain's decentralized ethos.

Dispute games introduce a challenge period (e.g., 7 days) during which state assertions can be disputed before being considered final. This delay is a security-latency tradeoff:

• Longer periods increase security by giving challengers more time to detect and submit fraud proofs.
• Shorter periods improve user experience by reducing withdrawal times. The period must be long enough to allow for the full multi-round bisection protocol to complete, even under potential network congestion.

Entities that provide the services and tooling necessary to participate in or monitor dispute games.

• Watchtowers / Challengers: Services like Uptime run nodes to monitor rollup state and submit challenges if fraud is detected, acting as the active players in the game.
• Provers (for ZK-backed games): Services like RISC Zero or Succinct Labs can provide the final ZK proof to irrevocably settle a dispute game that has been bisected to a single step.
• Staking Providers: Decentralized Sequencer projects or restaking platforms (e.g., EigenLayer) can provide the bonded capital required for actors (asserters, challengers) to participate in the economic game.

A malicious actor attempts to waste challenger resources by forcing them to perform computationally expensive execution steps. The attacker posts an invalid claim and strategically disagrees at each step of the bisection protocol, forcing the honest party to provide intermediate Merkle proofs and execute code for the entire disputed segment. This is a denial-of-service (DoS) vector against honest validators, designed to increase their operational costs.

• Mitigation: Implementing bonding requirements and slashing for provably wrong moves, alongside step duration limits to bound the attack window.

Also known as a censorship attack, this occurs when a malicious sequencer or a coalition of nodes prevents a valid fault proof from being published on the underlying Layer 1 (L1) within the challenge period. If the only honest party capable of submitting the proof is censored, an invalid state root may finalize.

• Key Risk: Centralization of proof submission roles.
• Mitigation: Permissionless participation in the dispute game, distributed watchtowers, and cryptographic proof aggregation to make censorship more difficult.

Exploiting the strict time constraints of the interactive game. An attacker may delay their responses until the last possible moment in each round, aiming to cause an honest challenger to timeout and lose by default. This tests the liveness assumptions of the protocol and the reliability of the L1 network for timely transaction inclusion.

• Components at risk: Challenge period duration, round timers, and L1 block time variability.
• Mitigation: Conservative timing parameters and allowing honest parties to respond to the final move of a round without penalty.

This defines the fundamental security model. A one-shot game (e.g., based on a Validity Proof) has a single round where a proof is verified; failure is binary. A multi-round interactive game (like a bisection game) breaks the dispute into steps, reducing the cost of verification but introducing more complex attack surfaces.

• Trade-off: One-shot games have simpler security but higher initial proof generation cost. Multi-round games are more complex but enable cheaper fraud proofs.
• Vulnerability: Complexity in multi-round games can lead to implementation bugs in the state transition logic.

The security of dispute games relies on cryptoeconomic incentives. Participants must post bonds that are slashed for incorrect claims. An attack arises if the cost of attacking (bond loss) is lower than the profit from stealing funds from the rollup's bridge.

• Critical Parameters: Bond sizes, challenge reward, and the value at risk in the rollup's bridge contract.
• Attack Vector: Bribe attacks, where an attacker profits from a successful invalid state transition and uses part of the profit to bribe potential challengers not to dispute.

The verification game (VGM) or dispute contract on L1 is a complex piece of code that must perfectly mirror the rollup's execution semantics. Bugs in this contract are catastrophic, as they could allow invalid states to be verified as valid, or vice-versa.

• Examples: Incorrect Merkle proof verification, wrong opcode emulation in the on-chain VM, or errors in the bisection logic.
• Mitigation: Extensive formal verification, audits, and bug bounty programs focused on the dispute contract. Simplicity in design is a key security feature.