ethereum-optimism · cpengilly · Jun 10, 2024 · Jun 10, 2024 · Jun 10, 2024 · Jun 10, 2024
@@ -96,5 +96,5 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang
 
 ## Next Steps
 
-*   See the [Fault Proofs Overview](/stack/protocol/fault-proofs/overview) to learn more about the three main components of the Fault Proof System.
+*   See the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer) to learn more about the three main components of the Fault Proof System.
 *   You can also read more about [Cannon FPVM](/stack/protocol/fault-proofs/cannon) and [Mips.sol](/stack/protocol/fault-proofs/mips), the onchain smart contract implementation of Cannon.
@@ -26,6 +26,32 @@ This multisig is a [2-of-2 nested multisig](https://etherscan.io/address/0x5a0Aa
 This multisig can be used to upgrade core OP Mainnet smart contracts **without upgrade delays** to allow for quick responses to potential security concerns.
 All upgrades to the OP Mainnet system must be approved by both component multisigs and either can veto an upgrade.
 
+## Fault Proofs
+
+<Callout>
+  It is important to understand that **fault proofs are not a silver bullet** and that **fault proofs do not meaningfully improve the security of a system if the system still has a multisig or security council that can instantly upgrade the system**.
+  OP Mainnet is following a multi-client and multi-proof approach designed to eventually remove the need for instant upgrades entirely.
+</Callout>
+
+Fault proofs are a mechanism that allow users to prove if a transaction output published to the [`L2OutputOracle`](https://github.com/ethereum-optimism/optimism/blob/5877ee24cc9aaef5848c1372e0e196707fb336a0/packages/contracts-bedrock/src/L1/L2OutputOracle.sol) contract is invalid.
+The behavior and security model of the `L2OutputOracle` is determined by three roles:
+
+1.  The `PROPOSER` is a permissioned role that is given the authority to publish output roots.
+2.  The `GUARDIAN` is a permissioned role that is given the authority to remove output roots published by the `PROPOSER`.
+3.  The `SystemOwner` is the address that controls the `ProxyAdmin` contract, which in turn controls the proxy in front of the `L2OutputOracle` contract.
+
+The cumulative effect of these roles on the security model is therefore:
+
+1.  A liveness failure can occur if the `PROPOSER` fails to publish new proposals AND the `SystemOwner` does not change the `PROPOSER`.
+2.  A safety failure can occur if the `PROPOSER` publishes an invalid output root AND the `GUARDIAN` fails to remove the invalid output AND the `SystemOwner` does not change the `GUARDIAN`.
+3.  The `SystemOwner` can trigger the system-wide pause action to halt activity in the `OptimismPortal` to give itself time to carry out one of the above actions.
+
+In summary, the `PROPOSER` and `GUARDIAN` roles essentially exist for convenience and short-term safety and liveness while the security of the system ultimately lies with the `SystemOwner`.
+
+<Callout type="info">
+  See the [FP Mainnet Security Model](/stack/protocol/fault-proofs/fp-security) for a detailed walk-thru of significant changes to Fault Proof Mainnet for the OP Stack.
+</Callout>
+
 ## Bugs and Unknowns
 
 Please also keep in mind that just like any other system, **the Optimism codebase may contain unknown bugs** that could lead to the loss of some or all of the ETH or tokens held within the system.
@@ -35,17 +61,6 @@ It's important to understand that using OP Mainnet inherently exposes you to the
 
 ## Work in Progress
 
-### Fault Proofs
-
-Fault proofs are a mechanism that allow users to prove if a transaction output published to the [`L2OutputOracle`](https://github.com/ethereum-optimism/optimism/blob/5877ee24cc9aaef5848c1372e0e196707fb336a0/packages/contracts-bedrock/src/L1/L2OutputOracle.sol) contract is invalid.
-Fault proofs are an important part of future of OP Mainnet security and begin to reduce the need for a multisig.
-An alpha version of the first fault proof mechanism is [currently in testing](https://blog.oplabs.co/building-a-fault-proof-system/).
-
-<Callout>
-It is important to understand that **fault proofs are not a silver bullet** and that **fault proofs do not meaningfully improve the security of a system if the system still has a multisig or security council that can instantly upgrade the system**.
-OP Mainnet is following a multi-client and multi-proof approach designed to eventually remove the need for instant upgrades entirely.
-</Callout>
-
 ### Sequencer Decentralization
 
 The Optimism Foundation currently operates the sole sequencer on OP Mainnet.

@@ -1,5 +1,7 @@
 {
-    "overview": "Overview",
+    "explainer": "Fault Proofs Explainer",
+    "fp-components": "FP System Components",
     "cannon": "FPVM: Cannon",
-    "mips": "MIPS.sol"
+    "mips": "MIPS.sol",
+    "fp-security": "FP Mainnet Security"
 }
@@ -0,0 +1,91 @@
+---
+title: Fault Proofs Explainer
+lang: en-US
+description: Learn about permissionless fault proofs.
+---
+
+import { Callout } from 'nextra/components'
+import Image from 'next/image'
+
+# Fault Proofs Explainer
+
+The Fault Proofs protocol upgrade reduces the trust assumptions for users by enabling permissionless output proposals and a permissionless fault proof system and preserves the ability for the guardian to override if necessary to maintain security. 
+The fault proofs upgrade moves closer to technical decentralization by:
+
+*   allowing anyone to post the L2 root, known as permissionless fault proofs
+*   enabling users to withdraw tokens from L2 to L1 without the need to involve any trusted third party
+*   enhancing the security of bridged ETH and ERC-20 tokens with an improved trust model
+*   allowing anyone to challenge invalid proposals through participating in an associated dispute game
+*   building a modular design of the fault proof system, allowing for easy integration of additional proving mechanisms.
+
+## Permissionless Fault Proofs
+
+Pernissionless Fault Proofs serve as a security mechanism for OP Stack Chains, enabling validators to propose or dispute claims about an OP Stack Chain's state on Ethereum.
+These claims about an OP Stack Chain's state allow anyone to verify and ensure the validity and security of transactions and withdrawals on the OP Stack Chain. 
+
+See the permission fault proofs diagram below for more details:
+<br />
+<Image src="/img/op-stack/protocol/fp-permissionless.png" alt="Permissionless Fault Proofs flow" width={700} height={600} />
+
+In [Optimistic Rollups (OP Stack Chains)](/stack/protocol/rollup/overview), there is a \~1 week challenge period where anyone can challenge the output root if they see that the root is not an accurate representation of the rollup's state.
+With permissionless fault proofs, anyone can spin up their own validator node that can either propose a state (output root) or dispute a state root (output proposal) submitted by a proposer. 
+
+The validator node can:
+
+*   Post claims about an OP Stack chain's state to Ethereum (i.e, propose output roots)
+*   Challenge invalid claims (output roots) made by other validators
+
+## Modular Design and Multi-layer Security
+
+Fault Proof for OP Stack Chains is [modular in design](/stack/protocol/fault-proofs/fp-components#system-design--modularity) and lays the groundwork for achieving Multiproof Nirvana. This allows the OP Stack to support multiple proof systems in a future state along with [Cannon](/stack/protocol/fault-proofs/cannon) (the default fault proof virtual machine), which is crucial for achieving greater decentralization and scalable security.
+
+Additionally, the following [security safeguards](/stack/protocol/fault-proofs/fp-security) have been built around the game, as follows:
+
+*   An off chain monitoring system has been set up to monitor all proposed roots and ensure they align with the correct state.
+*   After a root is finalized through a game, an additional delay has been added before withdrawals can occur. During this period, the `GUARDIAN` role can reject the root. This will allow the monitoring to stop invalid withdrawals.
+*   A contract called `DelayedWETH` has been set up to hold the bonds and only allow payouts after a delay, so that bonds can be redirected towards the rightful recipient in the event that a game is abused.
+*   If there is a disagreement over the result of the fault proofs, the security council can intervene and reject the outcome of the dispute game.
+
+## Considerations
+
+OP Stack developers must keep the following considerations in mind for fault proofs:
+
+*   As a part of the `OptimismPortal` being upgraded (the contract that handles withdrawals), all previously proved withdrawals will no longer work. This means that any previously proven withdrawal that has not yet been finalized will need to be reproved, including an additional wait before being able to finalize.
+*   There may be cases where the proposer becomes malicious and chooses to either not submit a state root (to censor transactions) or submit a false/malicious state root (to steal funds from the OP Stack Chain).
+    This could result in funds being stolen from the OP Stack Chain or transactions being censored. However, with permissionless fault proofs, anyone can spin up their own validator node and challenge the state root (output root) or post their own state root (output proposal).
+
+## Next Steps
+
+*   Ready to get started? Review the [FP Components](fp-components) to learn how the different components work together to enhance decentralization in the Optimism ecosystem.
+*   See the [Fault Proof Mainnet Security](/stack/protocol/fault-proofs/fp-security) to understand changes to `OptimismPortal` and `DisputeGame` contracts.
+*   For more info about how the the FP system works under the hood, [check out the specs](https://specs.optimism.io/fault-proof/index.html).
+
+## FAQs
+
+### How many steps/transactions are required to settle a dispute (worst-case scenario)?
+
+The maximum depth of a game is 73, but there can be any number of claims and counter-claims within a dispute game.
+Due to the permissionless structure where many different actors can participate in the same game, a single claim may be countered by any number of different counter-claims, effectively combining multiple disputes into a single game.
+
+### Are there any dependencies to consider when proposing a new state root (in the event of sequencer and proposer failure)?
+
+Users are able to complete the full withdrawal cycle without depending on any privileged action.
+The caveat is that the Guardian role has the ability to override the system by either blacklisting games or reverting to a permissioned system.
+So the trust assumption is reduced to requiring only that the guardian role does not act to intervene but there is still a trust assumption, inline with the stage 1 requirements.
+
+### Since the roles of proposer and challenger will be open to everyone, is there a guide available outlining the best practices for running them?
+
+It's not expected that normal users run `op-proposer` to regularly propose output roots.
+Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan or using the [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of op-challenger.
+OP-challenger docs are forthcoming.
+
+### How large are the bonds expected to be needed to sustain and win a dispute?
+
+The bonds are sized based on the anticipated cost to post a counter claim as well as to deter spamming invalid claims.
+As an example, on OP Sepolia, the game [`0xcf8f181497DAD07277781517A76cb131C54A1BEE`](https://sepolia.etherscan.io/address/0xcf8f181497DAD07277781517A76cb131C54A1BEE) shows the escalating bond sizes. The list-claims subcommand of op-challenger can also provide a good view of the claims in the game:
+
+```
+./op-challenger/bin/op-challenger list-claims --l1-eth-rpc <SEPOLIA_L1> --game-address 0xcf8f181497DAD07277781517A76cb131C54A1BEE
+```
+
+See the [specs](https://specs.optimism.io/experimental/fault-proof/stage-one/bond-incentives.html) for more details.
@@ -1,13 +1,15 @@
 ---
-title: Fault Proofs Overview
+title: FP System Components
 lang: en-US
-description: Learn about the fault proof system, its components, and how they will work together to enhance decentralization in the Optimism ecosystem.
+description: Learn about fault proof system components and how they work together to enhance decentralization in the Optimism ecosystem.
 ---
 
 import Image from 'next/image'
 import { Callout } from 'nextra/components'
 
-# Fault Proof Overview
+# FP System Components
+
+This page explains the fault proof system components and how they work together to enhance decentralization in the Optimism ecosystem.
 
 The Fault Proof System is comprised of three main components: a Fault Proof Program (FPP), a Fault Proof Virtual Machine (FPVM), and a dispute game protocol.
 The system is designed to eventually enable secure bridging without central fallback.
@@ -33,7 +35,7 @@ The OP Stack's unique, modular design allows the decoupling of the FPP and FPVM,
 
 ## Fault Proof Program
 
-The default for this system component is `op-program`, which implements a fault proof program that runs through the rollup state-transition to verify an L2 output from L1 inputs. This verifiable output can then resolve a disputed output on L1. 
+The default for this system component is `op-program`, which implements a fault proof program that runs through the rollup state-transition to verify an L2 output from L1 inputs. This verifiable output can then resolve a disputed output on L1.
 The FPP is a combination of `op-node` and `op-geth`, so it has both the consensus and execution "parts" of the protocol in a single process. This means Engine API calls that would normally be made over HTTP are instead made as direct method calls to the op-geth code.
 
 The FPP is designed so that it can be run in a deterministic way such that two invocations with the same input data will result in not only the same output, but the same program execution trace. This allows it to be run in an onchain VM as part of the dispute resolution process.
@@ -75,5 +77,6 @@ The first full implementation of the VM generic in the bisection game includes a
 
 ## Next Steps
 
-*   See [Mips.sol](mips) to learn more about the onchain smart contract implementation of Cannon.
-*   See [Cannon FPVM Specification](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/specs/cannon-fault-proof-vm.md) for more detail.
+*   See [Cannon FPVM](cannon) for more detail on Cannon and its default operation as part of Optimism's Fault Proof Virtual Machine.
+*   See [FP Mainnet Security](fp-security) for a detailed walk-thru of significant changes to Fault Proof Mainnet.
+*   See the [specs](https://specs.optimism.io/fault-proof/index.html) for detailed information about the entire FP program, FP virtual machine, and dispute game.
@@ -0,0 +1,60 @@
+---
+title: Fault Proofs Mainnet Security
+lang: en-US
+description: Learn about changes to the security model for the Fault Proofs Mainnet System.
+---
+
+import { Callout } from 'nextra/components'
+
+# Fault Proofs Mainnet Security
+
+<Callout type="warning">
+  Some contracts for the Fault Proof Mainnet system are still being updated.
+  Current versions of the Dispute Game contracts can be found within the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/src/dispute).
+  All content below is subject to change as these contracts are finalized.
+</Callout>
+
+This page details changes to the security model for the Fault Proofs Mainnet System. The most significant change introduced by Fault Proof Mainnet is the modification of the `OptimismPortal` to reference a new contract, the `DisputeGameFactory`, instead of the `L2OutputOracle`.
+*   The `DisputeGameFactory` contract generates `DisputeGame` contract instances that each act as a host to a proposed output root for a given block.
+*   Unlike the `L2OutputOracle`, the `DisputeGame` contract is no longer an entirely trusted contract but instead offers users the ability to play a "fault dispute game" in which the correctness of the proposal is determined programmatically.
+
+## Security Model
+
+Fault Proof Mainnet is a large contract upgrade that introduces a number of novel components.
+Our approach to FPM security has therefore been to limit the blast radius of any potential bugs to specific contracts and fallback mechanisms that can be easily audited.
+
+### Handling Invalid Proposals
+
+All of the security mechanisms we put in place generally revolve around the possibility that a `DisputeGame` contract may incorrectly finalize and invalid proposal.
+There are two major potential impacts of such an invalid proposal:
+
+1.  An invalid proposal would allow users to prove and execute withdrawal transactions against invalid states, potentially allowing for the withdrawal of ETH or ERC-20 tokens that those users should not be able to withdraw.
+2.  An invalid proposal would cause honest challengers to lose the bonds they submitted in order to play a role within the `DisputeGame`. Bonds can become quite large, so this can have a significant impact on the effected challengers.
+
+### Understanding `OptimismPortal` and `DisputeGame` Contracts
+
+We address these problems by encapsulating security concerns into two contracts:
+
+1.  The `OptimismPortal` includes various security mechanisms, some old and some new, that allow the `GUARDIAN` and `SystemOwner` roles to collaborate to prevent invalid proposals from impacting withdrawals.
+2.  The `DisputeGame` contracts store bonds within a `DelayedWETH` contract that is managed by the `SystemOwner`. Withdrawals from the `DelayedWETH` contract are delayed which gives the `SystemOwner` the ability to manually recover from situations in which bonds would be incorrectly distributed. This delay will most likely be set to a period of 7 days to give the `SystemOwner` sufficient time to respond to potential security concerns.
+
+We specifically include the following capabilities within the `OptimismPortal`:
+
+*   The `SystemOwner` can trigger the global pause mechanism found in the original system.
+*   The `SystemOwner` can replace the `GUARDIAN` address.
+*   The `GUARDIAN` can "blacklist" specific `DisputeGame` contracts that resolve incorrectly.
+*   The `GUARDIAN` can change the respected type of `DisputeGame` contract in the case that an entire class of `DisputeGame` contracts is found to have critical bugs. A `PermissionedDisputeGame` is provided by default that allows the same `PROPOSER` and `CHALLENGER` roles found in the original system to participate. If required, the `GUARDIAN` can choose to revert to this `PermissionedDisputeGame`.
+
+And these capabilities within the `DelayedWETH` contract:
+
+*   The `SystemOwner` can trigger the global pause mechanism to halt WETH withdrawals.
+*   The `SystemOwner` can hold funds from any specific `DisputeGame` contract.
+*   The `SystemOwner` can remove funds from the `DelayedWETH` contract if the issue extends to so many `DisputeGame` contracts that holding funds from specific contracts is not viable.
+
+As with the original system, the cumulative effect of these security capabilities is that the `GUARDIAN` role provides fast response capabilities while the `SystemOwner` can always step in to resolve all classes of bugs that could result in a loss of funds.
+The most significant change in security model with the introduction of Fault Proof Mainnet is that `SystemOwner` can take a more passive role as most potential safety failures can be handled automatically the Fault Proof system instead of needing to be handled by a permissioned role like the `GUARDIAN`.
+
+## Next Steps
+
+*   See the [FP Components](fp-components) for an overview of FP system components and how they work together to enhance decentralization in the Optimism ecosystem.
+*   See the [specs](https://specs.optimism.io/fault-proof/index.html) for detailed information about the entire FP program, FP virtual machine, and dispute game.