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, refcell, and Adrian Sutton for contributing to the design and implementation of the mechanisms 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
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:
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](<https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/dispute/interfaces/IDisputeGame.sol>). This interface defines the minimum functionality, such as storing a [Root Claim](<https://vexil.notion.site/Dispute-Games-8386677b52554a269cd95b8334f0ebfb>), arbitrary extra data for more extensive implementations, an [IBondManager](<https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/dispute/interfaces/IBondManager.sol>) to bond each [Claim](<https://vexil.notion.site/Dispute-Games-8386677b52554a269cd95b8334f0ebfb>), 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](<https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/dispute/DisputeGameFactory.sol>), 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, RISC-V, 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](<https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/L1/L2OutputOracle.sol>) 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.