Dispute Resolution Protocol

A mandatory time window during which a state assertion (e.g., a new rollup batch) can be challenged. This is the core security delay in optimistic rollups. During this period, any network participant (a verifier) can submit a fraud proof to contest invalid state transitions. The length of this period (typically 7 days) is a trade-off between security guarantees and finality latency.

Cryptographic proofs that demonstrate a specific state transition is invalid. They allow a single honest verifier to prove fraud to the underlying layer-1 blockchain (e.g., Ethereum), which then slashes the bond of the malicious party. Key types include:

• Non-interactive fraud proofs: A single proof submitted to the L1.
• Interactive fraud proofs: A multi-round challenge game (like a bisection protocol) that pinpoints the exact step of faulty computation.

In contrast to fraud proofs, validity proofs (e.g., ZK-SNARKs, ZK-STARKs) cryptographically prove the correctness of a state transition before it is accepted. Protocols using validity proofs (like ZK-rollups) do not require a challenge period, enabling near-instant finality. The dispute resolution is inherent in the mathematical proof; if a proof is invalid, the L1 contract will reject the state update.

Economic security mechanism where participants must lock capital (a bond) to perform certain roles, such as proposing state updates (sequencers or proposers). If a participant acts maliciously and is successfully challenged, their bond is slashed (partially or fully confiscated). This aligns economic incentives with honest behavior and compensates verifiers.

An interactive dispute resolution game used to efficiently pinpoint a single step of disagreement in a long computation. The protocol recursively splits (bisects) the disputed computation into smaller and smaller intervals until the fault is isolated to a single, easily verifiable step. This minimizes the on-chain verification cost for complex fraud proofs. It's a key component of systems like Optimism's Cannon and Arbitrum Nitro.

Specialized nodes or services that automatically monitor the chain for invalid state transitions and submit fraud proofs on behalf of users. They solve the verifier's dilemma—the lack of individual user incentive to run a full node and constantly check for fraud. Watchtowers can be run by individuals, DAOs, or professional services, decentralizing the security monitoring role.

The challenge period is a mandatory time window during which any participant can submit a fraud proof to contest a proposed state. Key considerations include:

• Duration: A longer period increases security but delays finality. Typical durations range from 7 days to 2 weeks.
• Economic Viability: Attackers must bond value for the duration, making long-range attacks capital-intensive.
• Liveness Assumption: The protocol relies on at least one honest, watchful node to be online and submit a challenge.

These are the economic incentives that secure the protocol.

• Challenge Bond: A challenger must lock (bond) funds to initiate a dispute. This prevents spam and frivolous claims.
• Slashing: If a challenge is proven correct, the malicious proposer's bond is slashed (partially burned, partially awarded to the challenger).
• Collusion Risk: A large, coordinated entity could post a bond, intentionally lose, and profit if the slashed funds flow to accomplices, requiring careful reward distribution design.

The Verifier's Dilemma is a game-theoretic problem where rational participants have little incentive to perform the costly work of verifying state correctness, assuming "someone else will do it." This can lead to:

• Liveness Failure: If no one verifies, an invalid state may become finalized.
• Mitigations: Protocols use watchtower services, delegated staking pools, or require verifiers for specific shards/rollups to specialize and capture MEV, making verification profitable.

For fraud-proof systems (like optimistic rollups), a Data Availability (DA) attack occurs when a sequencer/proposer publishes a state root but withholds the underlying transaction data, making it impossible for verifiers to construct a fraud proof.

• Impact: Invalid state cannot be challenged, breaking safety.
• Solutions: Data Availability Committees (DACs), Data Availability Sampling (DAS) as used in danksharding, or posting data to a high-security layer like Ethereum calldata.

A delay attack or griefing attack is a denial-of-service vector where a malicious actor continuously initiates spurious disputes to delay the finalization of correct results, without necessarily risking their full bond.

• Mechanism: An attacker can challenge a valid block, forcing a full verification game, then withdraw at the last step, only losing a small portion of their bond.
• Consequence: Creates uncertainty and increases latency for honest users.
• Mitigation: Designing dispute games with escalating costs or penalties for premature withdrawal.

The correctness of the entire system depends on the flawless implementation of the fraud proof verification game (e.g., interactive fraud proofs). Bugs here are catastrophic.

• Single-Instruction Vulnerabilities: A bug in a single opcode's proof logic can allow invalid state to be accepted.
• Formal Verification: Critical protocols often use formal verification (e.g., with tools like K-framework) to mathematically prove the correctness of the fraud proof circuit or virtual machine.
• Example: The initial Optimism rollout delayed fraud proofs to ensure rigorous auditing.