From 81f7373f6b4c315bcf6f16f10b0e5d2f94b44a25 Mon Sep 17 00:00:00 2001 From: David <165518730+Red-Pandaz@users.noreply.github.com> Date: Fri, 17 Jan 2025 14:00:40 -0600 Subject: [PATCH 1/4] Update FAQ question on fault proofs --- pages/stack/security/faq.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/security/faq.mdx b/pages/stack/security/faq.mdx index 267de6258..2dd866b5a 100644 --- a/pages/stack/security/faq.mdx +++ b/pages/stack/security/faq.mdx @@ -32,7 +32,7 @@ As with anything, modify the OP Stack at your own risk. There is no guarantee th ### Can I use fault proofs? -**Not yet.** The OP Stack does not currently have a Fault Proof System. **Note that 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")**. A system with fast upgrade keys is fully dependent on the upgrade keys for security. +**Yes!** On June 10, 2024, Fault Proofs were officially added to the OP Stack and were activated on OP Mainnet. Please refer to the [documentation on fault proofs](/stack/fault-proofs/explainer) for more information. Fault proofs are a key milestone and top priority for the OP Stack. In the meantime, the OP Stack can be shipped with several other excellent security options for systems that want to improve security before fault proofs are available in production. From f686aa913a7f01dff3365b919cf966259e846bcc Mon Sep 17 00:00:00 2001 From: David <165518730+Red-Pandaz@users.noreply.github.com> Date: Fri, 17 Jan 2025 14:23:21 -0600 Subject: [PATCH 2/4] Rewrite desciptions of fault proof contracts --- pages/stack/smart-contracts.mdx | 43 ++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index 201bbd7d0..347e68e2c 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -360,44 +360,47 @@ references to all other contract addresses for the chain. #### DisputeGameFactory -The `DisputeGameFactory` contract generates `FaultDisputeGame` contract -instances. +The `DisputeGameFactory` contract deploys `FaultDisputeGame` instances to resolve +disputes about the state of the OP Stack chain at specific block numbers. It serves +as the primary mechanism for creating and managing dispute games. #### FaultDisputeGame -The `FaultDisputeGame` contract is deployed by the `DisputeGameFactory`. Each -deployed instance of the contract acts as a host to a proposal about the state -of the OP Stack chain at a given block number. +The `FaultDisputeGame` contract is deployed by the `DisputeGameFactory` to +facilitate disputes about the OP Stack chain state. Participants can propose +or challenge states, and the contract hosts the logic to resolve these disputes. #### PermissionedDisputeGame -The `Guardian` can also choose to revert to a `PermissionedDisputeGame` -contract that only allows specific roles to submit and challenge proposals. +The `PermissionedDisputeGame` is an alternative to `FaultDisputeGame` that restricts +participation to specific roles, such as designated proposers or challengers. It is +enabled by the `Guardian` when stricter access controls are needed. #### AnchorStateRegistry -The `AnchorStateRegistry` is a contract that stores the latest "anchor" state -for each available `FaultDisputeGame` type. The anchor state is the latest -state that has been proposed on L1 and was not challenged within the challenge -period. By using stored anchor states, new `FaultDisputeGame` instances can -be initialized with a more recent starting state which reduces the amount of -required offchain computation. +The `AnchorStateRegistry` stores the latest unchallenged "anchor" state for each +`FaultDisputeGame` type. These anchor states allow new games to start from a recent +trusted state, reducing offchain computation requirements. #### DelayedWETH -The `DelayedWETH` contract 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. +The `DelayedWETH` contract manages bonds posted during disputes, ensuring participants +are financially committed. Payouts are delayed to allow for verification and correction +of errors, ensuring bonds go to the correct recipient. #### MIPS -The `MIPS` smart contract is an onchain implementation of a virtual machine -(VM) that encompasses the 32-bit, Big-Endian, MIPS III Instruction Set -Architecture (ISA). +The `MIPS` contract provides an onchain implementation of a 32-bit, Big-Endian MIPS III +virtual machine (VM). It executes fault proofs for disputes using a standardized instruction set. #### PreimageOracle -The `PreimageOracle` contract is used for storing permissioned pre-images. +The `PreimageOracle` contract maps hashes to their corresponding pre-images, enabling permissioned +and secure retrieval of data. It is integral to fault proof disputes, where hash-based claims +(e.g., state transitions or computational steps) must be validated by retrieving the original data. +By ensuring accurate and efficient verification of these claims, the `PreimageOracle` helps maintain +the integrity of the dispute resolution process. + #### DEPRECATED - L2OutputOracle From 10f690ec557b927cafdeb46c699f0458578a1773 Mon Sep 17 00:00:00 2001 From: David <165518730+Red-Pandaz@users.noreply.github.com> Date: Sat, 18 Jan 2025 17:40:41 -0600 Subject: [PATCH 3/4] Expand definition of anchor state --- pages/stack/smart-contracts.mdx | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index 347e68e2c..9c631dcd1 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -378,9 +378,10 @@ enabled by the `Guardian` when stricter access controls are needed. #### AnchorStateRegistry -The `AnchorStateRegistry` stores the latest unchallenged "anchor" state for each -`FaultDisputeGame` type. These anchor states allow new games to start from a recent -trusted state, reducing offchain computation requirements. +The `AnchorStateRegistry` stores the latest "anchor" state for each `FaultDisputeGame` type. +An anchor state is the most recent state proposed on L1 that was not challenged within +the challenge period. By storing anchor states, new `FaultDisputeGame` instances can start +from a trusted, recent state, reducing offchain computation requirements. #### DelayedWETH From adfb0d3e0ce24d6f2149c2667d83e7779f33f17b Mon Sep 17 00:00:00 2001 From: David <165518730+Red-Pandaz@users.noreply.github.com> Date: Sun, 19 Jan 2025 11:52:16 -0600 Subject: [PATCH 4/4] Revise fault proof contract descriptions --- pages/stack/smart-contracts.mdx | 57 +++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 24 deletions(-) diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index 9c631dcd1..9c5807c05 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -127,7 +127,7 @@ the ability for the guardian to override if necessary to maintain security. As a result, withdrawals no longer depend on the privileged proposer role posting an output root, allowing the entire withdrawal process to be completed without any privileged actions. The trust assumption is reduced to requiring -only that the guardian role does not act to intervene. +only that the Guardian role does not act to intervene. Combined with the Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes 23 proposals, this satisfies the criteria to have OP Chains @@ -360,47 +360,56 @@ references to all other contract addresses for the chain. #### DisputeGameFactory -The `DisputeGameFactory` contract deploys `FaultDisputeGame` instances to resolve -disputes about the state of the OP Stack chain at specific block numbers. It serves -as the primary mechanism for creating and managing dispute games. +The `DisputeGameFactory` deploys instances of `FaultDisputeGame` and `PermissionedDisputeGame` +to resolve disputes about the OP Stack chain state at specific block numbers. +It serves as the entry point for creating and managing dispute games. +The factory uses the `AnchorStateRegistry` for initialization, +and integrates the `DelayedWETH` contract to manage participant bonds. #### FaultDisputeGame -The `FaultDisputeGame` contract is deployed by the `DisputeGameFactory` to -facilitate disputes about the OP Stack chain state. Participants can propose -or challenge states, and the contract hosts the logic to resolve these disputes. +The `FaultDisputeGame` resolves disputes about the OP Stack chain state by +allowing participants to propose or challenge states. +It is deployed by the `DisputeGameFactory` and includes logic to finalize disputes. +The contract uses the `AnchorStateRegistry` to start from trusted states, +`MIPS` to execute fault proofs, the `PreimageOracle` to validate hash-based claims, +and the `DelayedWETH` contract to handle bonds. #### PermissionedDisputeGame -The `PermissionedDisputeGame` is an alternative to `FaultDisputeGame` that restricts -participation to specific roles, such as designated proposers or challengers. It is -enabled by the `Guardian` when stricter access controls are needed. +The `PermissionedDisputeGame` is also deployed by the `DisputeGameFactory`, +and inherits logic and dependencies from `FaultDisputeGame` while adding role-based restrictions. +It restricts participation to specific roles, such as designated proposers or challengers. +It is used when stricter access controls are required, as enforced by the Guardian. #### AnchorStateRegistry -The `AnchorStateRegistry` stores the latest "anchor" state for each `FaultDisputeGame` type. -An anchor state is the most recent state proposed on L1 that was not challenged within -the challenge period. By storing anchor states, new `FaultDisputeGame` instances can start -from a trusted, recent state, reducing offchain computation requirements. +The `AnchorStateRegistry` stores the latest "anchor" state for each dispute game type. +An anchor state is the most recent state proposed on L1 that was not challenged within the challenge period. +These states allow new dispute games to start from a trusted, recent state, reducing offchain computation requirements. #### DelayedWETH -The `DelayedWETH` contract manages bonds posted during disputes, ensuring participants -are financially committed. Payouts are delayed to allow for verification and correction -of errors, ensuring bonds go to the correct recipient. +The `DelayedWETH` contract manages bonds posted by participants during disputes. +It delays payouts to allow time for verification, ensuring that funds are distributed correctly. +This mechanism ensures participants are financially committed and disputes are finalized securely. #### MIPS -The `MIPS` contract provides an onchain implementation of a 32-bit, Big-Endian MIPS III -virtual machine (VM). It executes fault proofs for disputes using a standardized instruction set. +The `MIPS` contract provides an on-chain implementation of a 32-bit, Big-Endian MIPS III virtual machine, +designed to execute fault proofs for disputes by processing a standardized instruction set. +This enables instances of `FaultDisputeGame` and `PermissionedDisputeGame` to resolve disputes + over state transitions accurately and consistently. + The process starts from the trusted anchor state provided by the `AnchorStateRegistry`, + ensuring that the dispute is based on a reliable foundation. + The `PreimageOracle` is then used to retrieve pre-images of hash-based claims, + validating the data used in the computation and ensuring its integrity. #### PreimageOracle -The `PreimageOracle` contract maps hashes to their corresponding pre-images, enabling permissioned -and secure retrieval of data. It is integral to fault proof disputes, where hash-based claims -(e.g., state transitions or computational steps) must be validated by retrieving the original data. -By ensuring accurate and efficient verification of these claims, the `PreimageOracle` helps maintain -the integrity of the dispute resolution process. +The `PreimageOracle` maps hashes to their corresponding pre-images for secure and permissioned data retrieval. +It validates hash-based claims used in disputes, such as state transitions or computational steps. +This ensures the integrity of fault proofs in `FaultDisputeGame` and `PermissionedDisputeGame` instances. #### DEPRECATED - L2OutputOracle