Merge pull request #7172 from ethereum-optimism/aj/fpa-docs

specs: Remove attestation game specs

docs/fault-proof-alpha/README.md

@@ -9,7 +9,11 @@ finalized and may change without notice.
 
 ### Contents
 
- * Overview
+ * Specifications
+   * [Generic Fault Proof System](../../specs/fault-proof.md)
+   * [Generic Dispute Game Interface](../../specs/dispute-game-interface.md)
+   * [Fault Dispute Game](../../specs/fault-dispute-game.md)
+   * [Cannon VM](../../specs/cannon-fault-proof-vm.md)
  * [Deployment Details](./deployments.md)
  * [Manual Usage](./manual.md)
    * [Creating Traces with Cannon](./cannon.md)

op-challenger/README.md

@@ -3,7 +3,7 @@
 The `op-challenger` is a modular **op-stack** challenge agent
 written in golang for dispute games including, but not limited to, attestation games, fault
 games, and validity games. To learn more about dispute games, visit the
-[dispute game specs](../specs/dispute-game.md).
+[fault proof specs](../specs/fault-proof.md).
 
 ## Quickstart
 

specs/README.md

@@ -29,8 +29,9 @@ that maintains 1:1 compatibility with Ethereum.
 Specifications of new features in active development.
 
 - [Fault Proof](./fault-proof.md)
-- [Dispute Game](./dispute-game.md)
 - [Dispute Game Interface](./dispute-game-interface.md)
+- [Fault Dispute Game](./fault-dispute-game.md)
+- [Cannon VM](./cannon-fault-proof-vm.md)
 
 ## Design Goals
 

specs/bond-manager.md

@@ -20,14 +20,14 @@ be attached to an output proposal. In this case, the bond will be paid in ether.
 
 By requiring a bond to be posted with an output proposal, spam and invalid outputs
 are disincentivized. Explicitly, if invalid outputs are proposed, challenge agents
-can delete the invalid output via a [dispute-game](./dispute-game.md) and seize the
+can delete the invalid output via a [dispute-game](./dispute-game-interface.md) and seize the
 proposer's bond. So, posting invalid outputs is directly disincentivized in this way
 since the proposer would lose their bond if the challenge agents seize it.
 
 Concretely, outputs will be permissionlessly proposed to the `L2OutputOracle` contract.
 When submitting an output proposal, the ether value is sent as the bond. This bond is
 then held by a bond manager contract. The bond manager contract is responsible for
-both the [dispute-games](./dispute-game.md) and the `L2OutputOracle` (further detailed
+both the [dispute-games](./dispute-game-interface.md) and the `L2OutputOracle` (further detailed
 in [proposals](./proposals.md)).
 
 The bond manager will need to handle bond logic for a variety of different
@@ -136,7 +136,7 @@ instead tied to the address of the output proposer.
 ## Bond Manager Implementation
 
 Initially, the bond manager will only be used by the `L2OutputOracle` contract
-for output proposals in the attestation [dispute game](./dispute-game.md). Since
+for output proposals in the attestation [dispute game](./dispute-game-interface.md). Since
 the attestation dispute game has a permissioned set of attestors, there are no
 intermediate steps in the game that would require bonds.
 

specs/challenger.md

-# Challenger Specification
-
-<!-- START doctoc generated TOC please keep comment here to allow auto update -->
-<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
-**Table of Contents**
-
-- [Description](#description)
-- [Terminology](#terminology)
-- [Event and Response Lifecycle](#event-and-response-lifecycle)
-  - [`GameType.FAULT`](#gametypefault)
-  - [`GameType.ATTESTATION`](#gametypeattestation)
-  - [`GameType.VALIDITY`](#gametypevalidity)
-
-<!-- END doctoc generated TOC please keep comment here to allow auto update -->
-
-## Description
-
-The Challenger is an off-chain agent that listens for faulty claims made about the state of
-the L2 on the data availability layer. It is responsible for challenging these incorrect claims
-and ensuring the correctness of all finalized claims on the settlement layer.
-
-The Challenger agent is intended to be ran as a permissionless service by participants of the network
-alongside a [rollup-node](./rollup-node.md). Challenger agents will be rewarded in the form of the
-bond attached to the claims they disprove.
-
-## Terminology
-
-- **data availability layer** - In the context of this document, the data availability layer is the
-  generic term for the location where claims about the state of the layer two are made. In the context
-  of Optimism, this is Ethereum Mainnet.
-- **settlement layer** - In the context of this document, the settlement layer is the location of the
-  bridge as well as where funds deposited to the rollup reside. In the context of Optimism, this is
-  Ethereum Mainnet.
-- **L2** - In the context of this document, the layer two of the Optimistic Rollup. In the context
-  of Optimism, this is the Optimism Mainnet.
-- **rollup-node** - In the context of this document, the rollup node describes the
-  [rollup-node specification](./rollup-node.md). In the context of Optimism, this is the implementation
-  of the [rollup-node specification](./rollup-node.md), the `op-node`.
-
-## Event and Response Lifecycle
-
-The Challenger agent is expected to be able to listen for and respond to several different events
-on the data availability layer. These events and responses are parameterized depending on the type
-of dispute game being played, and the Challenger listens to different events and responds uniquely
-to each of the different game types. For specification of dispute game types, see the
-[Dispute Game Interfaces specification](./dispute-game-interface.md) and
-[Dispute Game specification](./dispute-game.md).
-
-### `GameType.FAULT`
-
-> **Warning**
-> The `FAULT` game type is not yet implemented. In the first iteration of Optimism's decentralization effort,
-> challengers will respond to `ATTESTATION` games only.
-
-**Events and Responses**
-*TODO*
-
-### `GameType.ATTESTATION`
-
-**Events and Responses**
-
-- [`L2OutputOracle.OutputProposed`](../packages/contracts-bedrock/src/L1/L2OutputOracle.sol#L57-70)
-  The `L2OutputOracle` contract emits this event when a new output is proposed on the data availability
-  layer. Each time an output is proposed, the Challenger should check to see if the output is equal
-  the output given by the `optimism_outputAtBlock` endpoint of their `rollup-node`.
-  - If it is, the Challenger should do nothing to challenge this output proposal.
-  - If it is not, the Challenger should respond by creating a new `DisputeGame` with the
-    `DisputeGameType.ATTESTATION` `gameType`, the correct output root as the `rootClaim`, and the abi-encoded
-    `l2BlockNumber` of the correct output root as the `extraData`.
-  ![Attestation `OutputProposed` Diagram](./assets/challenger_attestation_output_proposed.png)
-- `DisputeGameFactory.DisputeGameCreated` A new dispute game has been created and is ready to be reviewed. The
-  Challenger agent should listen for this event and check if the `rootClaim` of the `AttestationDisputeGame`
-  created by the `DisputeGameFactory` is equal to the output root of their `rollup-node` at the game's `l2BlockNumber`.
-  - If it is, the Challenger should sign the [EIP-712 typeHash](./dispute-game.md) of the struct containing the
-    `AttestationDisputeGame`'s `rootClaim` and `l2BlockNumber`. The Challenger should then submit the abi-encoded
-    signature to the `AttestationDisputeGame`'s `challenge` function.
-  - If it is not, the Challenger should do nothing in support of this dispute game.
-  ![Attestation `DisputeGameCreated` Diagram](./assets/challenger_attestation_dispute_game_created.png)
-
-A full diagram and lifecycle of the Challenger's role in the `ATTESTATION` game type can be found below:
-
-![Attestation Diagram](./assets/challenger_attestation.png)
-
-### `GameType.VALIDITY`
-
-**TODO**
-
-> **Warning**
-> The `VALIDITY` game type is not yet implemented. In the first iteration of Optimism's decentralization effort,
-> challengers will respond to `ATTESTATION` games only. A validity proof based dispute game is a possibility,
-> but fault proof based dispute games will be the primary focus of the team in the near future.
-
-**Events and Responses**
-*TODO*

specs/dispute-game.md

-# Dispute Game
-
-<!-- START doctoc generated TOC please keep comment here to allow auto update -->
-<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
-**Table of Contents**
-
-- [Attestation Dispute Game](#attestation-dispute-game)
-  - [Smart Contract Implementation](#smart-contract-implementation)
-    - [Attestation Structure](#attestation-structure)
-  - [Why EIP-712](#why-eip-712)
-
-<!-- END doctoc generated TOC please keep comment here to allow auto update -->
-
-## Attestation Dispute Game
-
-The output attestation based dispute game shifts the current permissioned output proposal process
-to a permissionless, social-consensus based architecture that can progressively decentralize over
-time by increasing the size of the signer set. In this "game," output proposals can be submitted
-permissionlessly. To prevent "invalid output proposals," a social quorum can revert an output proposal
-when an invalid one is discovered. The set of signers is maintained in the `SystemConfig` contract,
-and these signers will issue [EIP-712](https://eips.ethereum.org/EIPS/eip-712) signatures
-over canonical output roots and the `l2BlockNumber`s they commit to as attestations. To learn more,
-see the [DisputeGame Interface Spec](./dispute-game-interface.md).
-
-In the above language, an "invalid output proposal" is defined as an output proposal that represents
-a non-canonical state of the L2 chain.
-
-### Smart Contract Implementation
-
-The `AttestationDisputeGame` should implement the `IDisputeGame` interface and also be able to call
-out to the `L2OutputOracle`. It is expected that the `L2OutputOracle` will grant permissions to
-`AttestationDisputeGame` contracts to call its `deleteL2Outputs` function at the *specific* `l2BlockNumber`
-that is embedded in the `AttestationDisputeGame`'s `extraData`.
-
-The `AttestationDisputeGame` should be configured with a quorum ratio at deploy time. It should also
-maintain a set of attestor accounts, which is fetched by the `SystemConfig` contract and snapshotted
-at deploy time. This snapshot is necessary to have a fixed upper bound on resolution cost, which in
-turn gives a fix cost for the necessary bond attached to output proposals.
-
-The ability to add and remove attestor accounts should be enabled by a single immutable
-account that controls the `SystemConfig`. It should be impossible to remove accounts such that quorum
-is not able to be reached. It is ok to allow accounts to be added or removed in the middle of an
-open challenge, as it will not affect the `signerSet` that exists within open challenges.
-
-A challenge is created when an alternative output root for a given `l2BlockNumber` is presented to the
-`DisputeGameFactory` contract. Multiple challenges should be able to run in parallel.
-
-For simplicity, the `AttestationDisputeGame` does not need to track what output proposals are
-committed to as part of the attestations. It only needs to check that the attested output root
-is different than the proposed output root. If this is not checked, then it will be possible
-to remove output proposals that are in agreement with the attestations and create a griefing vector.
-
-#### Attestation Structure
-
-The EIP-712 [typeHash](https://eips.ethereum.org/EIPS/eip-712#rationale-for-typehash) should be
-defined as the following:
-
-```solidity
-TYPE_HASH = keccak256("Dispute(bytes32 outputRoot,uint256 l2BlockNumber)");
-```
-
-The components for the `typeHash` are as follows:
-
-- `outputRoot` - The **correct** output root that commits to the given `l2BlockNumber`. This should be a
-  positive attestation where the `rootClaim` of the `AttestationDisputeGame` is the **correct** output root
-  for the given `l2BlockNumber`.
-- `l2BlockNumber` - The L2 block number that the `outputRoot` commits to. The `outputRoot` should commit
-  to the entirety of the L2 state from genesis up to and including this `l2BlockNumber`.
-
-### Why EIP-712
-
-It is important to use EIP-712 to decouple the originator of the transaction and the attestor. This
-will allow a decentralized network of attestors that serve attestations to bots that are responsible
-for ensuring that all output proposals submitted to the network will not allow for malicious withdrawals
-from the bridge.
-
-It is important to have replay protection to ensure that attestations cannot be used more than once.

specs/fault-proof.md

@@ -412,5 +412,5 @@ The allocated response time is limited by the dispute-game window,
 and any additional time necessary based on L1 fee changes when bonds are insufficient.
 
 > Note: the timed, bonded, bisection dispute game is in development.
-> Also see [dispute-game specs](./dispute-game.md) for general dispute game system specifications,
+> Also see [fault dispute-game specs](./fault-dispute-game.md) for fault dispute game system specifications,
 > And [dispute-game-interface specs](./dispute-game-interface.md) for dispute game interface specifications.