Closed 0xJepsen closed 1 year ago
Hey! So this may be a bit long, but it'll be good to document some details about the game for future reference here.
The two contracts that we'll need to deploy are the DisputeGameFactory
and the FaultDisputeGame
.
The DisputeGameFactory
is responsible for keeping track of implementation contracts for different GameType
s, creating clone proxies of games with the create
function, and bookkeeping of the games keyed by a unique identifier. When a faulty output proposal is submitted to the output oracle, the role of the off-chain challenge agent is first to create a new game via the factory to begin a dispute on the output proposal they deem faulty.
The FaultDisputeGame
was outlined in my CMDX presentation earlier this year - that is the best place to go to get a long-winded explanation of its mechanics. To sum it up, it allows for n
players to bisect over an execution trace generated by the op-program
to find the left-most, deepest divergence point among the participants' claims. At the very bottom level of the bisection in the leaf nodes, players must resort to executing a single instruction step of the MIPS program on-chain in order to prove their trace as truthy. Many paths can be taken through this bisection due to the game allowing for anyone to play, but only one path is correct. This also introduces the mechanic that rational players with the same traces effectively act as the same entity.
A few smaller details that may help:
Claim
s always disagree with their parents.Claim
s are effectively promises that commit to a value, true|false
, that is revealed in the resolution process. At the time of creating a Claim
, it has no objective concept of truthiness, only relative truthiness.Claim
s that are dangling and have never been countered after clocks have ran out implicitly resolve to true
.When fault proofs go live onchain, players will be incentivized to run off-chain challenge agents to challenge any faulty claims that present themselves via the bonds attached to the claims they counter. There are three types of situations that the challenger needs to respond to:
As for agents we can implement in Arbiter, I think there are several strategies that may be interesting:
In general, the primary goals are:
A lot of this is abbreviated, so please feel free to ask questions! Thanks for the interest in working with us on this - I think Arbiter will be very powerful in chaos testing / profiling this thing 😄
Nice this is based. I have a lot of questions on this but im going to watch the CMDX presentation first to see if i can get some answered there. I think something we will have to think about is plugging the nodes into the agents. Makes me curious to dive deeper into how the op nodes work
I think something we will have to think about is plugging the nodes into the agents. Makes me curious to dive deeper into how the op nodes work
One thing that we can do to simplify this on Arbiter's end is use a mock onchain VM - rather than bisecting over a MIPS trace, which requires Cannon + a devnet on the agents' ends, we can just as easily bisect over something like the alphabet or natural numbers.
On the other hand, doing it with the real deal would be sweet! We've got a devnet script in the monorepo that will spin everything up, so it would really just be a matter of starting it + having cannon on-hand.
Currently we're in the middle of implementation, but we should be at the stage where we can dispute the alphabet or natural numbers sooner than full Cannon integration 😄
Note to self: Fork and make a directory for simulations here https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock
Would be curious to think about what agents would need to be designed for this scope. I'm personally jazzed on this.