Skip to content

N
nebula
Commit a8958868 authored by inphi's avatar inphi
Browse files
Options

couple fixes

parent 5e2124de
Hide whitespace changes
Inline Side-by-side
Showing with 81 additions and 27 deletions
specs/fault-dispute-game.md
View file @ a8958868
...@@ -62,7 +62,7 @@ We refer to this state as the **ABSOLUTE\_PRESTATE**. ...@@ -62,7 +62,7 @@ We refer to this state as the **ABSOLUTE\_PRESTATE**.
### Claims ### Claims
Claims assert an execution trace. This is represented as `ClaimHash`, a `bytes32` commitment to Claims assert an execution trace. This is represented as `ClaimHash`, a `bytes32` commitment to
the last VM state in the trace. A FDG is initialized with a root claim, which commits to the entire the last VM state in a trace. A FDG is initialized with a root claim, which commits to the entire
execution trace. As we'll see later, there can be multiple claims, committing to different states in the FDG. execution trace. As we'll see later, there can be multiple claims, committing to different states in the FDG.
### DAG ### DAG
...@@ -97,6 +97,7 @@ Positions higher up the game tree also cover the deepest, right-most positions r ...@@ -97,6 +97,7 @@ Positions higher up the game tree also cover the deepest, right-most positions r
We refer to this coverage as the **trace index** of a Position. We refer to this coverage as the **trace index** of a Position.
> This means claims commit to an execution trace that terminates at the same index as their Position's trace index. > This means claims commit to an execution trace that terminates at the same index as their Position's trace index.
> That is, for a given trace index $n$, its ClaimHash corresponds to the $S_n$ th state in the trace.
Note that there can be multiple positions covering the same _trace index_. Note that there can be multiple positions covering the same _trace index_.
......
specs/honest-challenger-fdg.md
View file @ a8958868
...@@ -15,55 +15,89 @@ ...@@ -15,55 +15,89 @@
<!-- END doctoc generated TOC please keep comment here to allow auto update --> <!-- END doctoc generated TOC please keep comment here to allow auto update -->
The honest challenger is an agent interacting in the [Fault Dispute Game](./fault-dispute-game.md) (FDG) supporting honest claims and dispute false claims. An honest challenger strives to ensure a correct game resolution. The honest challenger is also _rational_ as its behavior is the only one that results in a positive outcome. The honest challenger is an agent interacting in the [Fault Dispute Game](./fault-dispute-game.md)
This document specifies the behavior of an honest challenger. (FDG) that supports honest claims and disputes false claims.
An honest challenger strives to ensure a correct, truthful, game resolution.
The honest challenger is also _rational_ as any deviation from its behavior will result in
negative outcomes.
This document specifies the expected behavior of an honest challenger.
## Overview ## Overview
The Honest Challenger has two responsibilities: The Honest Challenger has two primary duties:
1. Challenge invalid outputs by creating FDGs that aim to delete them.
2. Challenge the root claims in FDGs that aim to delete valid outputs.
It monitors the `L2OutputOracle` to detect invalid proposals and the `DisputeGameFactory` to locate in-progress FDGs. 1. Challenge invalid outputs by either creating new FDGs or supporting existing ones that
aim to delete such outputs.
2. Contest root claims in FDGs that seek to remove valid outputs.
The Honest Challenger relies on a trusted rollup node that is synced to the canonical state and a trace provider (ex: [Cannon](./cannon-fault-proof-vm.md)) in order to determine the validity of proposed outputs and claims made to Fault Dispute Games. The trace provider must be configured with the [ABSOLUTE_PRESTATE](./fault-dispute-game.md#execution-trace) of the chosen FDG to generate the traces needed to make truthful claims. The honest challenger monitors the `L2OutputOracle` to identify invalid proposals and scans
the `DisputeGameFactory` contract to find on-going FDGs.
For verifying the legitimacy of proposed outputs and FDG claims, it relies on a synced,
trusted rollup node as well as a trace provider (ex: [Cannon](./cannon-fault-proof-vm.md)).
The trace provider must be configured with the [ABSOLUTE_PRESTATE](./fault-dispute-game.md#execution-trace)
of the FDG being interacted with to generate the traces needed to make truthful claims.
## L2OutputOracle Responses ## L2OutputOracle Responses
When a new output is proposed to the `L2OutputOracle`, the honest challenger has a binary decision to make: When a new output is proposed to the `L2OutputOracle`, the honest challenger has a binary decision to make:
1. If the trusted node agrees with the output, take no action. A `FaultDisputeGame` is designed to prove that a proposed output root is incorrect and to delete it. Therefore, an honest challenger will not create a dispute game that challenges an output root that its trusted node agrees with. 1. If the trusted node agrees with the output, take no action. A `FaultDisputeGame` is
2. If the trusted node disagrees, create a new `FaultDisputeGame` via the `DisputeGameFactory`. In contrast to the above, an honest challenger aims to delete any output roots that its trusted node disagrees with in order to claim the bond attached to it. The honest challenger assumes that their rollup node is synced to the canonical state and that the fault proof program is correct, so it is willing to put its money on the line to counter any faults. designed to prove that a proposed output root is incorrect and consequently, to delete it.
Therefore, an honest challenger will not create a dispute game that challenges an output
root that its trusted node agrees with.
2. If the trusted node disagrees, create a new `FaultDisputeGame` via the `DisputeGameFactory`.
In contrast to the above, an honest challenger aims to delete any output roots that its trusted
node disagrees with in order to claim the bond attached to it.
The honest challenger assumes that their rollup node is synced to the canonical state and that
the fault proof program is correct, so it is willing to put its money on the line to counter
any faults.
## FDG Responses ## FDG Responses
### Root Claims ### Root Claims
When a `FaultDisputeGame` is created, the honest challenger has two possible correct responses to its root claim: When a `FaultDisputeGame` is created, the honest challenger has two possible correct responses
to its root claim:
1. [**Attack**](./fault-dispute-game.md#attack) if they disagree with the root claim. When an honest challenger disagrees with a root claim of a game, it is akin to them agreeing with the output proposal that the game is attempting to delete. The root claim commits to the entire execution trace, so the first move by a defender of the output root is to attack with the [ClaimHash](./fault-dispute-game.md#claims) at the midpoint instruction within their execution trace. 1. [**Attack**](./fault-dispute-game.md#attack) if they disagree with the root claim.
2. **Do Nothing** if they agree with the root claim. If an honest challenger agrees with a root claim of a game, it means that they disagree with the output root it is trying to delete. They do nothing because if the root claim is left un-countered, the game will delete the output root they disagree with. When an honest challenger disagrees with a root claim of a game,
it is akin to them agreeing with the output proposal that the game is attempting to delete.
The root claim commits to the entire execution trace, so the first move by a defender of the
output root is to attack with the [ClaimHash](./fault-dispute-game.md#claims) at the midpoint
instruction within their execution trace.
2. **Do Nothing** if they agree with the root claim. If an honest challenger agrees with a
root claim of a game, it means that they disagree with the output root it is trying to delete.
They do nothing because if the root claim is left un-countered, the game will delete the output
root they disagree with.
### Counter Claims ### Counter Claims
When a new claim is made in a dispute game with a [game tree](./fault-dispute-game.md#game-tree) depth in the range of `[1, MAX_DEPTH]`, the honest challenger processes it and performs a response. If multiple claims are observed since the last sync, the honest challenger responds to them in chronological order. When a new claim is made in a dispute game with a [game tree](./fault-dispute-game.md#game-tree)
depth in the range of `[1, MAX_DEPTH]`, the honest challenger processes it and performs
a response. If multiple claims are observed since the last sync,
the honest challenger responds to them in chronological order.
The challenger first needs to determine which [_team_](./fault-dispute-game.md#team-dynamics) To determine the appropriate response, the challenger first needs to know which
it belongs to. This determines the set of claims it should respond to in the FDG. [_team_](./fault-dispute-game.md#team-dynamics) it belongs to.
This determines the set of claims it should respond to in the FDG.
If the agent determines itself to be a Defender, aiming to delete an output root, If the agent determines itself to be a Defender, aiming to delete an output root,
then it must dispute claims positioned at odd depths in the game tree. then it must dispute claims positioned at odd depths in the game tree.
Otherwise, the challenger dispute claims positioned at even depths in the game tree. Otherwise, it disputes claims positioned at even depths in the game tree.
This means an honest challenger will only respond to claims made by the opposing team. This means an honest challenger will only respond to claims made by the opposing team.
The next step is to determine if the claim, now at a depth it disagrees with, disputes another claim it _agrees with_. An honest challenger agrees with a claim iff every other claim along its path to the root claim commits to a valid `ClaimHash`. Thus, an honest challenger will avoid supporting invalid claims on the same team. The next step is to determine if the claim, now determined to be on the opposing team,
disputes another claim it _agrees with_.
An honest challenger agrees with a claim iff every other claim along its path to the root
claim commits to a valid `ClaimHash`.
Thus, an honest challenger avoids supporting invalid claims on the same team.
The last step is to determine whether the claim has a valid commitment (i.e. `ClaimHash`). The last step is to determine whether the claim has a valid commitment (i.e. `ClaimHash`).
If the `ClaimHash` matches ours at the same trace index, then we disagree with the claim's stance If the `ClaimHash` matches ours at the same trace index, then we disagree with the claim's
by moving to [defend](./fault-dispute-game.md#defend). stance by moving to [defend](./fault-dispute-game.md#defend).
Otherwise, the claim is [attacked](./fault-dispute-game.md#attack). Otherwise, the claim is [attacked](./fault-dispute-game.md#attack).
The following pseudocode illustrates the response logic.
The following pseudocode illustrates the response logic at a high level.
```python ```python
class Team(Enum): class Team(Enum):
DEFENDER = 0 DEFENDER = 0
...@@ -87,23 +121,42 @@ def agree_with(claim: Claim, chal_trace: List[ClaimHash, MAX_TRACE]): ...@@ -87,23 +121,42 @@ def agree_with(claim: Claim, chal_trace: List[ClaimHash, MAX_TRACE]):
def respond(claim: Claim, chal: Team, chal_trace: List[ClaimHash, MAX_TRACE]): def respond(claim: Claim, chal: Team, chal_trace: List[ClaimHash, MAX_TRACE]):
if depth(claim.position) % 2 != chal.value: if depth(claim.position) % 2 != chal.value:
if claim.parent is None or agree_with(claim.parent, chal_trace): if claim.parent is None or agree_with(claim.parent, chal_trace):
if chal_trace[claim.trace_index] == claim.claim_hash: if chal_trace[trace_index(claim.position)] == claim.claim_hash:
defend() defend()
else: else:
attack() attack()
else: pass # no response else: pass # no response
``` ```
The honest challenger SHOULD respond to claims as soon as possible to avoid the clock of its counter-claim from expiring. In attack or defense, the honest challenger MUST submit a `ClaimHash` corresponding to the state
identified by the trace index of their response position.
The honest challenger SHOULD respond to claims as soon as possible to avoid the clock of its
counter-claim from expiring.
### Steps ### Steps
At the max depth of the game, claims represent commitments to the state of the fault proof VM at a single instruction step interval. Because the game can no longer bisect further, when the honest challenger has a valid move against these claims (valid defined by the response in [Counter Claims](#counter-claims)), the only option for an honest challenger is to execute a VM step on-chain to disprove the claim at `MAX_GAME_DEPTH`. If the VM step proves this claim correct, the claim will be left uncountered. At the max depth of the game, claims represent commitments to the state of the fault proof VM
at a single instruction step interval.
Because the game can no longer bisect further, when the honest challenger has a valid move
against these claims (valid defined by the response in [Counter Claims](#counter-claims)),
the only option for an honest challenger is to execute a VM step on-chain to disprove the claim
at `MAX_GAME_DEPTH`.
If the VM step proves this claim correct, the claim will be left uncountered.
The same rules for determining whether a move is an attack, defense, or noop from the above section apply to claims at the bottom level of the tree. Instead of calling `attack` or `defend`, the challenger issues a [step](./fault-dispute-game.md#step). An honest challenger will issue an attack step if it disagrees with the claim, otherwise a defense step is issued. The same rules for determining whether a move is an attack, defense, or noop from the above
section apply to claims at the bottom level of the tree.
Instead of calling `attack` or `defend`, the challenger issues a [step](./fault-dispute-game.md#step).
An honest challenger will issue an attack step if it disagrees with the claim,
otherwise a defense step is issued.
## Resolution ## Resolution
When one side of a `FaultDisputeGame`'s chess clock runs out, the honest challenger’s responsibility is to resolve the game. This action entails the challenger calling the `resolve` function on the `FaultDisputeGame` contract. When one side of a `FaultDisputeGame`'s chess clock runs out, the honest challenger’s responsibility
is to resolve the game.
This action entails the challenger calling the `resolve` function on the `FaultDisputeGame` contract.
The `FaultDisputeGame` does not put a time cap on resolution - because of the liveness assumption on honest challengers and the bonds attached to the claims they’ve countered, challengers should resolve the game promptly in order to make their funds liquid again and capture their reward(s). The `FaultDisputeGame` does not put a time cap on resolution - because of the liveness assumption
on honest challengers and the bonds attached to the claims they’ve countered,
challengers should resolve the game promptly in order to make their funds
liquid again and capture their reward(s).
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment