Review

Co-authored-by: Maurelian <maurelian@protonmail.ch>
Co-authored-by: Adrian Sutton <adrian@oplabs.co>

docs/fault-proof-alpha/immunifi.md → docs/fault-proof-alpha/immunefi.md

@@ -14,14 +14,14 @@ The alpha system is not prepared for mainnet, and as such, there are a number of
 
 ### Reviewer Notes
 1. **Any bug report without a PoC in the form of a test in `op-e2e` will not be considered a valid bug report.**
-    1. *todo*: Provide Adrian's example op-e2e test
+    1. A guide on creating an e2e test with an invalid output proposal to dispute can be found [here][invalid-proposal-doc].
 1. Exploits against the alpha system that take advantage of the aforementioned issues will not be considered valid bug reports.
 1. The [AlphabetVM][alphabet-vm] is not equivalent to the MIPS thread context in behavior. Bug reports submitted against the [AlphabetVM][alphabet-vm] will not be considered valid bug reports, this mock VM is used solely for testing.
 
 ### Plans for the next iteration
 Going past alpha, we have a number of plans for improving the system and fixing some of the aforementioned issues in preparation for full integration with the current system. These include:
-1. Including an extra layer of bisection over output roots, enabling the off-chain challenge agents to only need to run [Cannon][cannon] over a single block rather than a string of blocks. This will heavily reduce the hardware cost of running the off
-   chain challenge agent, which mitigates the DoS vector mentioned above.
+1. Including an extra layer of bisection over output roots prior to beginning execution trace bisection, enabling the off-chain challenge agents to only need to run [Cannon][cannon] over a single block rather than a string of blocks. This will heavily reduce the hardware cost of running the off
+   chain challenge agent and provide an upper bound on what Cannon will have to execute, allowing for sparse proposals.
 1. Adding bonds to the system to preserve incentive compatibility. In the alpha, defenses of the honest L2 state are not incentivized, which also means that attacks on the honest L2 state are not disincentivized. Adding bonds to each claim
    made in the dispute game will preserve the incentives of the system as well as make it more costly to attack.
 1. Improving the [Dispute Game][dispute-game]'s resolution algorithm to reduce the number of interactions that the off-chain challenge agents need to have with the on-chain dispute game. This will reduce the cost of running the off-chain challenge
@@ -41,20 +41,22 @@ As mentioned above in the "[Plans for the next iteration](#plans-for-the-next-it
 as well as the [`op-challenger`][op-challenger] in order to support the features that will bring the system to a production ready state. During this time, it is unlikely that [Cannon][cannon], the [Cannon contracts][cannon-contracts],
 or the [`op-program`][op-program] will change significantly, and as such, we recommend focusing efforts primarily on these components.
 
-There are several key invariants that must be maintained in order for the system to be considered secure:
+There are several key invariants that must be maintained in order for the system to be considered secure. A bounty report must demonstrate a bug which breaks one of these invariants.
 1. **Cannon**
-    1. [Cannon][cannon]'s `mipsevm` must be functionally equivalent to the [MIPS thread context][cannon-contracts] implemented in Solidity. Any disparities in behavior is considered a bug.
+    1. [Cannon][cannon]'s `mipsevm` must be functionally equivalent to the [MIPS thread context][cannon-contracts] implemented in Solidity. Any disparities that result in different `op-program` execution are a bug.
         1. Both [Cannon][cannon] and the on-chain [MIPS thread context][cannon-contracts] must produce the same output given an identical setup state and input data.
     1. Both [Cannon][cannon] and the on-chain [MIPS thread context][cannon-contracts] must produce a deterministic output given an identical setup state and input data.
-    1. Both [Cannon][cannon] and the on-chain [MIPS thread context][cannon-contracts] must never panic on a valid state transition.
+    1. Both [Cannon][cannon] and the on-chain [MIPS thread context][cannon-contracts] must never panic on a state transition with honest input data / setup state.
+        1. Note: There are a number of instructions from MIPS that Cannon does not support. Specifically, this invariant covers panic conditions within the realm of supported instructions and valid honest input data / setup state where cannon otherwise should have completed execution and produced a valid/invalid opinion about the state transition.
     1. The `PreimageOracle` contract's local data storage must not be able to be corrupted by an external party.
 1. **op-program**
     1. The [`op-program`][op-program] must produce a deterministic output given an identical setup state and input data.
 1. **Dispute Game Contracts**
     1. Assuming the presence of an `honest challenger` (defined by the behavior of the [`op-challenger`][op-challenger]) participating within the game, the `FaultDisputeGame` utilizing the `MIPS` VM **must always** resolve favorably towards the honest L2 state.
-        1. *Note*: The only exception to this invariant in the alpha dispute game (with a `MIPS` VM) is the aforementioned DoS vector. This is not considered a valid bug report, however any other violation of this invariant is.
+        1. *Note (1)*: The presence of an honest challenger implies that the honest challenger has exhausted all moves it would have made - any game where the honest challenger was unable to exhaust its move set can resolve unfavorably to their desired outcome. The aforementioned DoS vector is one such reason the honest challenger may not perform all its moves.
 1. **op-challenger**
     1. The honest `op-challenger` must never make a claim that does not support the honest outcome of the dispute game (i.e., the outcome which favors the honest L2 state being considered canonical).
+        1. *Note:* Because of the rules in the current solving / resolution mechanism, the challenger will counter all claims that have a different view of the root claim's validity. While this is an inefficiency, it is not considered a violation of this invariant, as this behavior is necessary to ensure that all invalid claims have been countered.
 
 Any bug reports in the form of a PoC `op-e2e` test that demonstrates a violation of any of the above invariants will be considered valid bug reports and elligible for a reward.
 
@@ -68,7 +70,7 @@ Any bug reports in the form of a PoC `op-e2e` test that demonstrates a violation
 * [`op-challenger`][op-challenger]
 
 ### Bounty Rewards
-*todo* - I don't define these.
+All valid bug reports for Fault Proof Alpha qualify as a low-severity report. See [immunefi][immunefi]
 
 <!-- LINKS -->
 [cannon]: https://github.com/ethereum-optimism/optimism/tree/develop/cannon
@@ -78,5 +80,7 @@ Any bug reports in the form of a PoC `op-e2e` test that demonstrates a violation
 [cannon-contracts]: https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/src/cannon
 [op-program]: https://github.com/ethereum-optimism/optimism/tree/develop/op-program
 [op-challenger]: https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger
-[alphabet-vm]: https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/test/FaultDisputeGame.t.sol#L977-L1005
+[alphabet-vm]: https://github.com/ethereum-optimism/optimism/blob/c1cbacef0097c28f999e3655200e6bd0d4dba9f2/packages/contracts-bedrock/test/FaultDisputeGame.t.sol#L977-L1005
 [fault-proof-specs]: https://github.com/ethereum-optimism/optimism/blob/develop/specs/fault-proof.md
+[immunefi]: https://immunefi.com/bounty/optimism/
+[invalid-proposal-doc]: https://github.com/ethereum-optimism/optimism/blob/develop/docs/fault-proof-alpha/invalid-proposals.md