feat: dispute game v2 specification #266
Conversation
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
|
||
| The Dispute Game V2 is a new version of the dispute game protocol that allows for chaining several | ||
| [subcontexts](#isubcontext) together in order to enable multi-proofs. In addition, it features advancements | ||
| in the incentive system, mitigating the effects of the ["proof of whale"][pow] issue in the current design. |
There was a problem hiding this comment.
nit: "current design" won't age well, perhaps "previous design" is better
| With branch claims, the cost of the bond now scales with the _length of the branch_, rather than the | ||
| _depth of the claim_. That is, branch claims made higher up in the tree cost more to make. | ||
|
|
||
| The calculation of the bond is left to the implementor. It _must_ be a pure function of the definition $B(l)$, where |
There was a problem hiding this comment.
We will want to specify the bond function in this document eventually
There was a problem hiding this comment.
Do we want to get that specific when it comes to the implementation details? The requirement for l being the scalar should be enough to hold the required invariant of the design. Further impl details can be up to the implementor of it.
| trace between two blocks. In this `BisectionGame` implementation, the `enterSubcontext` function simply passes the | ||
| arguments to the FPVM contract's `step` function to determine validity at the leaf level. | ||
|
|
||
| #### `ZKVerifier` |
There was a problem hiding this comment.
I really like this overall. It gives us a lot more flexibility and is a big improvement on the proof of whale problem. Working through the details of bonds is going to be critical though as we risk making it very expensive to make proposals or wind up with a proof of computational whale problem if its cheap to make the honest actor execute a lot of full cannon runs.
|
|
||
| #### Bond Calculation | ||
|
|
||
| With branch claims, the cost of the bond now scales with the _length of the branch_, rather than the |
There was a problem hiding this comment.
If I understand correctly, this would mean that the largest bond is paid when first creating the game. That's the single most common operation though since its what op-proposer does so this would very significantly increase the capital requirements for running op-proposer.
| Here, assuming trace extension is active in `[12,16)`, the honest actor may short-circuit this dispute immediately, | ||
| without performing further bisection by entering the verifier subcontext with `11` -> `12`. The dishonest actor, on the |
There was a problem hiding this comment.
I'm not following how this works. Assuming the malicious user is posting the correct values right up until the last trace index, the value at 12 would be valid and the only invalid claim would be 15. So if the honest actor enters the sub context with 11 -> 12 wouldn't it just resolve that 12 is valid and support the dishonest actor?
Admittedly, the invalid value at trace index15 has been provided by the dishonest actor in gindex 3 so the honest actor could post 7 and 14 and be assured that the subcontext 14->15 will resolve in their favour.
|
|
||
| /// @notice Create and enter the subcontext. To be called by the parent context. | ||
| /// @param `_opaqueData` - The opaque data passed to the subcontext. | ||
| /// @param `opaqueData_` - The opaque return data passed back to the |
There was a problem hiding this comment.
nit: Missing end of sentence
| Because of the low-cost to challenge a valid game and require a verification subcontext to be entered, the challenger | ||
| is opened up to DoS attack. However, assuming the cost of proving off-chain outweighs the best-case bond, the system | ||
| is still economically sound. |
There was a problem hiding this comment.
The need for large bonds here to pay for the cost of running the challenger is directly at odds with the need to keep bonds low to avoid needing huge amounts of capital to run op-proposer.
| implemented. The main goal of this change is to create an abstraction for a layered `IDisputeGame` over ordered data, | ||
| with each layer being unaware of others. | ||
|
|
||
| ### `ISubContext` |
There was a problem hiding this comment.
I think this is the part of the dispute game which could use the most extra thinking. The reason I have this feeling is because SubContexts feel too similar to our current nested claim structure. It would be nice to do more exploration to see if it is possible or reasonable create a dispute game which has a single flat tree but that itself executes the multi-proofs.
@protolambda has had interesting ideas around how we can shape the dispute tree to achieve really interesting results & I think that it might be possible to reuse some of those designs to achieve the same goal as SubContext but without introducing recursive games which resemble our recursive claims
There was a problem hiding this comment.
Yes, it would be great to discuss in-tree (same bisection game) sub-contexts that can serve the encapsulation of proving the interop state-transition in a series of smaller programs to prove. And there's a parallel here to ZK proof folding schemes that may be interesting to look at.
There was a problem hiding this comment.
@protolambda has a DB design which seems like it could be used for this. Adding checkpoints at powers of 2 which are easy to compute so that when we bisect the tree it is easy to retrieve all of the information until you get really deep at which point you generate the specific block trace or the specific block ZKP
Overview
Note
Heavy WIP. Needs some fleshing out.
This PR introduces a specification for the Dispute Game V2, featuring: