Fault-proof dispute games: Exclusive, Best Practices

Dispute games keep optimistic systems honest. A sequencer proposes a state update, and anyone can challenge it within a window. If the update is wrong, a fraud proof shows the exact fault, the bad actor is slashed, and the correct state wins.

Three knobs shape these games: bonds that pay for honesty, fraud proofs that pinpoint errors, and timeouts that throttle the tempo. Get them right and you gain strong safety with low cost. Get them wrong and you either stall or leak value.

Why bonds exist

Bonds are posted by proposers and sometimes challengers. They create a real cost for lying and a real reward for catching a lie. Without them, spam and griefing swamp the protocol.

A clean design ties bond size to the maximum damage a single faulty proposal could impose before being reverted. Too low, and attackers treat cheating as a cheap option. Too high, and honest participation dries up.

Anatomy of a fraud proof

A fraud proof is a verifiable transcript that reduces a global dispute to a local mistake. Instead of replaying a million steps on-chain, the protocol narrows the disagreement to one transition that both parties must compute on-chain under identical rules.

Two common styles exist. Interactive (bisecting) proofs split the trace until only one step remains. Single-step proofs jump straight to a challenged step by referencing a commitment to the full trace. Both end with an on-chain execution of the disputed transition.

Timeouts and liveness

Timeouts keep disputes moving. Each round has a response clock; miss it and you lose by default. These clocks must beat worst-case network delays and leave some margin for reorgs or congestion.

Finality windows hinge on timeouts. A shorter window gives quick confirmations but risks honest parties timing out under stress. A longer window improves safety but delays withdrawals and cross-chain actions.

A minimal dispute protocol

The core flow can be expressed as a short sequence of actions. Each step seeks to reduce ambiguity while keeping costs down for the honest side.

1. Propose: A sequencer posts a state root with a proposer bond and a commitment to the execution trace (e.g., Merkleized).
2. Challenge: Any verifier posts a challenger bond and identifies a mismatch (root vs. local compute) within the dispute window.
3. Narrow: The parties interactively bisect the trace or jump to a referenced step using inclusion proofs.
4. Resolve: The protocol executes the single disputed step on-chain with canonical inputs. The losing side is slashed.
5. Finalize: If no valid challenge lands before the final timeout, the proposed root is accepted and bonds are returned.

This skeleton appears across optimistic rollups, light-client bridges, and some cross-chain messaging systems. The variations lie in how traces are committed, how many rounds exist, and who can respond in each round.

Parametrization trade-offs

Choosing numbers for bonds and timeouts is not cosmetic. It meaningfully shifts incentives, costs, and the user experience. The table below summarizes typical levers and what they buy you.

Parameter tuning should be empirical. Measure actual client execution times, mempool delays, and block propagation; then set timeouts and bonds from data, not hunches.

Attacks and mitigations

Real systems attract creativity. Expect opportunists to test edge cases and operational gaps. The following patterns recur across deployments.

• Griefing by timeout: An attacker spams challenges hoping the honest party misses a response. Mitigate with responder pools, longer round timeouts during congestion, and rate limits per challenger.
• DoS via cheap challenges: Low challenger bonds and low per-round costs invite floods. Raise economic floors and require stake-weighted initiation after repeated failures.
• State commitment mismatch: Ambiguous trace commitments let attackers wedge inconsistent interpretations. Standardize hashing, serialization, and VM versions on-chain.
• Clock skew exploitation: Attackers exploit block timing jitter. Base deadlines on block numbers plus margin instead of wall-clock timestamps.
• Cross-domain race conditions: Bridges finalize on chain A while a challenge brews on chain B. Gate finality on the slowest, most conservative domain.

Well-instrumented monitoring helps. Track challenge frequency, outcomes, median response times, and slash rates. Sudden deviations often signal probing or configuration drift.

Tiny scenarios

A sequencer posts Root R with a 5 ETH bond. A verifier computes locally and finds a mismatch at step 742. They lodge a challenge with a 1 ETH bond and a Merkle proof for the subtrace. After two rounds of bisection, both agree on a disputed step. The on-chain VM executes it; the proposer loses, gets slashed, and the verifier earns a portion of the 5 ETH.

In another case, the challenge is valid but gas prices spike. The challenger’s relayer times out. A backup responder picks up the baton from a shared key-safe, submits the response under a gas price cap, and clears the round. The protocol avoids a wrongful loss because operational redundancy matched the timeout budget.

How fraud proofs stay practical

Gas is the enemy of on-chain re-execution. Systems keep costs manageable with commitments and minimal on-chain work. Interactive games compress a million steps to O(log n) rounds plus one step of execution.

Proof integrity rests on reproducibility. Lock down bytecode, compilers, and configuration in the commitment scheme. If two honest clients can diverge due to nondeterminism, attackers will exploit that seam.

Guidance for builders

Design choices stick. A few habits reduce both attack surface and operational pain while keeping the game fair to honest participants.

1. Quantify worst-case harm per proposal, and set proposer bonds to exceed it by a clear margin.
2. Benchmark end-to-end: client execution, witness generation, merklization, and on-chain step costs; base round timeouts on p99 plus slack.
3. Enable multiple responders (not just the original party) with clear authorization so honest challenges don’t fail due to a single point of failure.
4. Publish a deterministic spec: hashing, encoding, VM version, and precompile semantics, with test vectors that clients must pass.
5. Rotate parameters as conditions change. On major gas regime or bandwidth shifts, adjust bonds and windows via governance with a grace period.

The goal is simple: make cheating unprofitable and honest participation routine. When incentives, proofs, and clocks align, dispute games fade into the background, yet they quietly carry the security load.