fp updates

pages/builders/notices/fp-changes.mdx

@@ -1,19 +1,19 @@
 ---
-title: Preparing for Fault Proofs Changes
+title: Preparing for Fault Proofs Breaking Changes
 lang: en-US
 description: Learn how to prepare for Fault Proofs changes.
 ---
 
 import { Steps, Callout } from 'nextra/components'
 
-# Preparing for Fault Proofs Changes
+# Preparing for Fault Proofs Breaking Changes
 
 OP Labs has submitted a [proposal to governance](https://gov.optimism.io/t/upgrade-proposal-fault-proofs/8161) to upgrade OP Mainnet to support Fault Proofs. If this proposal passes, fault proofs would launch on OP Mainnet approximately June 2024. This document details changes that apply to users, bridges, and centralized exchanges, as well as any custom solutions that use withdrawals. This page outlines changes for OP Mainnet and OP Sepolia only. Details for other OP Chains are forthcoming.
 
 If you experience difficulty at any stage of this process, please reach out to [OP Labs Developer Support](https://github.com/ethereum-optimism/developers/discussions).
 
 <Callout type="error">
- **IMPORTANT NOTICE FOR BRIDGES AND USERS**
+ **Important Notice for Bridges and Users**
 
 **ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete.
 
@@ -22,7 +22,7 @@ If you experience difficulty at any stage of this process, please reach out to [
 </Callout>
 
 <Callout type="warning">
-  **IMPORTANT NOTICE FOR BRIDGES AND USERS**
+  **Important Notice for Bridges and Users**
 
   Maximum withdrawal delay times are increasing with the Fault Proofs upgrade.
   *   Withdrawals will generally take 7 days to finalize (unchanged from before Fault Proofs).
@@ -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.

pages/chain/security/faq.mdx

@@ -26,6 +26,24 @@ 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 provide limited improvements to 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>
+
+Users can withdraw ETH and tokens from OP Mainnet to Ethereum by submitting a withdrawal proof that shows the withdrawal was actually included inside of OP Mainnet.
+Withdrawals are proven against proposals about the state of OP Mainnet that are published through the [`DisputeGameFactory`](https://github.com/ethereum-optimism/optimism/blob/363c5d7f4fb14180a0e2a28cc948fe2146f03dce/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol) contract.
+
+Proposals can be submitted to the `DisputeGameFactory` contract by any user and submissions do not require any special permissions.
+Each submitted proposal creates a [`FaultDisputeGame`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol) contract that allows any other user to challenge the validity of a proposal by participating in a "fault proof" process.
+A more detailed explanation of the fault proof game can be found in the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer).
+
+Although the fault proof game is permissionless, the Optimism Security Council acting as the [Guardian](/chain/security/privileged-roles#guardian) role provides a backstop in case of a failure in the fault proof game.
+Each proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches.
+The Guardian can also choose to shift the system to use a `PermissionedDisputeGame` in which only specific `PROPOSER` and `CHALLENGER` roles can submit and challenge proposals.
+
 ## 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 +53,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.
@@ -55,8 +62,8 @@ Although users can always bypass the Sequencer by sending transactions directly
 
 ### Does OP Mainnet have fault proofs?
 
-**No**, OP Mainnet does not currently have fault proofs.
-**Fault proofs do not meaningfully improve the security of a system if that system can be upgraded within the 7 day challenge window ("fast upgrade keys")**.
+**Yes**, OP Mainnet has fault proofs.
+It is important to note that **fault proofs are not a silver bullet** and that **fault proofs provide limited improvements to the security of a system if the system still has a multisig or security council that can instantly upgrade the system**.
 A system with fast upgrade keys, such as OP Mainnet, is fully dependent on the upgrade keys for security.
 OP Mainnet's goal is to be the first system that deploys fault proofs that can secure the system by themselves, without fast upgrade keys.
 

pages/stack/protocol/fault-proofs/_meta.json

@@ -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"
 }

pages/stack/protocol/fault-proofs/explainer.mdx

@@ -0,0 +1,103 @@
+---
+title: Fault Proofs Explainer
+lang: en-US
+description: Learn about the OP Stack's fault proof system.
+---
+
+import { Callout } from 'nextra/components'
+import Image from 'next/image'
+
+# Fault Proofs Explainer
+
+Fault Proofs are an important part of an Optimistic Rollup system like the OP Stack.
+Users withdraw ETH and tokens from OP Stack chains like OP Mainnet by submitting a withdrawal proof that shows the withdrawal was actually included in the OP Stack chain.
+Fault Proofs allow users to permissionlessly submit and challenge the proposals about the state of an OP Stack chain that are used to prove withdrawals.
+
+On June 10, 2024, Fault Proofs were officially added to the OP Stack and were activated on OP Mainnet.
+This Fault Proofs upgrade moves the OP Stack closer to technical decentralization by:
+*   allowing anyone to make proposals about the state of the L2
+*   allowing anyone to challenge proposals made by other users
+*   allowing users to send messages from L2 to L1 without the need for a trusted third party
+*   allowing users to trigger withdrawals from L2 to L1 without the need for a trusted third party
+*   introducing a modular fault proof design that can easily integrate additional proving mechanisms
+
+Although the fault proof game is permissionless, the Optimism Security Council acting as the Guardian role provides a backstop in case of a failure in the fault proof game.
+Each proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches.
+The Guardian can also choose to shift the system to use a PermissionedDisputeGame, in which only specific `PROPOSER` and `CHALLENGER` roles can submit and challenge proposals.
+
+## Permissionless Proposals
+
+"Proposals" or "State Proposals" are claims about the state of an OP Stack chain that are submitted to Ethereum through the `DisputeGameFactory` contract.
+Proposals can be used for many things but are most commonly used by end-users to prove that they created a withdrawal on an OP Stack chain.
+With the Fault Proofs upgrade to the OP Stack, proposals become permissionless and can be submitted by anyone.
+
+See the permissionless 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} />
+
+## Permissionless Challenges
+
+Because anyone can submit a proposal, it's important that invalid proposals can be challenged.
+In [Optimistic Rollups like OP Stack Chains](/stack/protocol/rollup/overview) there is a \~1 week challenge period during which users can challenge a proposal if they believe it to be incorrect.
+With the Fault Proofs upgrade to the OP Stack, challenges become permissionless and can be submitted by anyone.
+Any user can run a node for the OP Stack chain in question and use the `op-challenger` tool to participate in the dispute process.
+
+## Modular Design and Multi-layer Security
+
+The OP Stack Fault Proof system is [modular in design](/stack/protocol/fault-proofs/fp-components#system-design--modularity) and lays the groundwork for achieving a "multi-proof" system. This allows the OP Stack to support multiple proof systems alongside the initial [Cannon](/stack/protocol/fault-proofs/cannon) proof system.
+With multiple proof systems in place, the OP Stack can be more resilient to potential attacks and bugs in any one proof system.
+
+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. See [`op-dispute-mon`](https://github.com/ethereum-optimism/optimism/blob/develop/op-dispute-mon/README.md?plain=1) for more details.
+*   After a root is finalized through a game, an additional delay called the "airgap window" has been added before withdrawals can occur. During this period, the `GUARDIAN` role can reject the root.
+*   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 correct recipient in the case that a game resolves incorrectly.
+
+## 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 `FaultDisputeGame` contracts.
+*   For more info about how 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 can complete the full withdrawal cycle without depending on any privileged action.
+The Guardian role can override the system by pausing withdrawals, blacklisting games, or reverting to a permissioned system.
+As a result, the trust assumption is reduced to requiring only that the Guardian role does not act to intervene, inline with the stage 1 requirements.
+### Since the roles of proposer and challenger will be open to everyone, are guides 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`.
+Documentation for `op-challenger` is forthcoming.
+
+### How much ETH should a chain operator put aside to operate the fault proof system?
+
+The nominal operating cost of running FPs (i.e., assuming no invalid proposals or malicious actors) will depend on the initial bond set for the `FaultDisputeGame` and the frequency of posting proposals.
+Assuming OP Mainnet parameters, where proposals will be posted hourly, that's 0.08 ETH per hour.
+Assuming a 7 day dispute window, you'll need roughly 14 ETH (including gas costs) to make proposals.
+If chains are using the similar FP deploy configs as OP Mainnet, it's recommended to stick to a 0.08 ETH initial bond.
+
+However, the capital requirements for operating a FP chain in itself is much larger than 14 ETH.
+An operator that secures their chain using FPs must be willing to stake a lot of ETH to secure the chain.
+One may decide the capital requirements aren't worth it, and use only a Permissioned FP system.
+The capital requirements will be improved in the later stages of Fault Proofs to make it more feasible for smaller chains.
+
+### 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.

pages/stack/protocol/fault-proofs/overview.mdx → pages/stack/protocol/fault-proofs/fp-components.mdx

@@ -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.
+*   For more detail on Cannon and its default operation as part of Optimism's Fault Proof Virtual Machine, see [Cannon FPVM](cannon).
+*   For a detailed walk-thru of significant changes to Fault Proof Mainnet, see [FP Mainnet Security](fp-security).
+*   For detailed information about the entire FP program, FP virtual machine, and dispute game, see the [specs](https://specs.optimism.io/fault-proof/index.html).