The past month for me has been dispute games, which are pretty fun mechanisms. This post is a dump of my ramblings on what they are, why I think building infrastructure for generic dispute games is important, and how the implementation I’m working on functions.

Shoutout to Karl Floersch, protolambda, Joshua (trianglesphere), Mark Tyneway, Inphi, and refcell for contributing to the design and implementation of the mechanism described below 🙂

Joshua is also giving a talk on this topic at EthCC next week! If you’re interested in a more long form presentation on some of the topics in this post, tune into the livestream.

Disclaimer: I am an employee of OP Labs, and these words are my own. I am not writing this post on behalf of OP Labs or the Optimism Foundation. All material within this post is subject to change and does not serve as a specification for the dispute game that the OP Stack will use to power fault proofs.

Table of Contents

Dispute Games

A Dispute Game is a generic mechanism that enables two or more parties to resolve a dispute over a claim about a piece of information. I did a presentation on them earlier this year, but to boil it down to its essence, generic dispute games have two important properties:

1. Incentive Compatibility: In order to make the game sybil resistant and to encourage honest actors to participate, there must be an explicit penalty for creating faulty claims and an explicit reward for creating truthful claims.
2. Resolution: Each dispute game implementation must have a mechanism for determining whether claims made within them are true or false. This can be anything from a multisig to a fault proof or validity proof, so long as it can deterministically distinguish all claims in the game as true or false at the time of resolution.

There are many ways a dispute game can be implemented while meeting these requirements; For this reason, we can define a loose interface such as in IDisputeGame. This interface defines the minimum functionality, such as storing a Root Claim, arbitrary extra data for more extensive implementations, an IBondManager to bond each Claim, the resolve function, and a few other helper functions for retrieving data about the game.

Because many different types of dispute games can exist and often perform various privileged actions while relying on differing security models, it is also advantageous to have a way to create, bookkeep, and upgrade implementations of different game types. In the Optimism codebase, this idea manifested itself in the DisputeGameFactory, which is a clones-with-immutable-args factory that passes immutable setup data to the minimal game proxies. Having the ability to add different game types and authenticate their actions through the factory opens up some interesting doors, such as creating an aggregate proof system using multiple fault proof based games that are secured with different programs & VMs (MIPS, RISCV, WASM, etc.)

An example of a simple, trusted dispute game would be an Attestation Game that secures output roots on Optimism. We could imagine an implementation of IDisputeGame with an added function for trusted attestors to submit EIP-712 signatures of a type hash committing to an alternative output root and the resolve function’s implementation deleting the faulty output root from the L2OutputOracle once a threshold of signatures has been submitted. A full flow of this game's lifecycle, including interactions with the off chain agents participating in the game, could look like:

Attestation Game Diagram

This is only one of many examples of dispute games that can be built, though, and it has a serious downside of relying on trusted parties within the attester set.

Bisection Game