ethereum-optimism · sbvegan · Oct 30, 2024 · Oct 30, 2024 · Oct 30, 2024
@@ -16,3 +16,4 @@ Granite
 Holocene
 Monitorism
 Kubernetes
+Fault Proof System
@@ -34,7 +34,7 @@ One simple modification to the Settlement Layer is to tweak the parameters of th
 
 ### Custom proofs
 
-Settlement Layer modules use a proof system to verify the correctness of the state of your OP Stack chain as proposed on the third-party chain. In general, these proofs are either Optimistic proofs that require a withdrawal delay or Validity proofs that use a mathematical proof system to assert the validity of the proposal. The current Attestation Proof Optimistic Settlement module could be replaced with a fault proof system.
+Settlement Layer modules use a proof system to verify the correctness of the state of your OP Stack chain as proposed on the third-party chain. In general, these proofs are either Optimistic proofs that require a withdrawal delay or Validity proofs that use a mathematical proof system to assert the validity of the proposal. The current Attestation Proof Optimistic Settlement module could be replaced with a Fault Proof System.
 
 ### Multiple modules
 

@@ -195,7 +195,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring
 
   ### Test and debug challenger (optional)
 
-  This is an optional step to use `op-challenger` subcommands, which allow chain operators to interact with the fault proof system onchain for testing and debugging purposes. For example, it is possible to test and explore the system in the following ways:
+  This is an optional step to use `op-challenger` subcommands, which allow chain operators to interact with the Fault Proof System onchain for testing and debugging purposes. For example, it is possible to test and explore the system in the following ways:
 
   *   create games yourself, and it doesn't matter if the games are valid or invalid.
   *   perform moves in games and then claim and resolve things.

@@ -271,6 +271,6 @@ cast call <YOUR_BURN_CONTRACT_HERE> "total()" | cast --from-wei
 
 ## Conclusion
 
-With just a few tiny changes to the `op-node`, you were just able to implement a change to the OP Stack that allows you to keep track of the L1 ETH burn on L2. With a live Cannon fault proof system, you should not only be able to track the L1 burn on L2, you should be able to *prove* the burn to contracts back on L1. That's crazy!
+With just a few tiny changes to the `op-node`, you were just able to implement a change to the OP Stack that allows you to keep track of the L1 ETH burn on L2. With a live Cannon Fault Proof System, you should not only be able to track the L1 burn on L2, you should be able to *prove* the burn to contracts back on L1. That's crazy!
 
 The OP Stack is an extremely powerful platform that allows you to perform a large amount of computation trustlessly. It's a superpower for smart contracts. Tracking the L1 burn is just one of the many, many wild things you can do with the OP Stack. If you're looking for inspiration or you want to see what others are building on the OP Stack, check out the OP Stack Hacks page. Maybe you'll find a project you want to work on, or maybe you'll get the inspiration you need to build the next killer smart contract.
@@ -148,7 +148,7 @@ In order to address these issues, we can introduce two features:
 
 We can enable these two features first by introducing a permissionless proof system to the Optimism bridge contracts. With the modular proof design introduced in Bedrock, proofs may come in the form of fault proofs or validity proofs (e.g. zero knowledge proofs). However, until validity proofs are productionized, we assume withdrawals will use a fault proof system.
 
-In the envisioned fault proof system, anyone can submit a withdrawal claim, and these withdrawal claims can be submitted at any time. Submitting withdrawal claims can be permissionless when claims come with bonds attached to them, as these bonds act as collateral if the claim is proven to be invalid. If a challenger successfully challenges the claim, the bond is paid out to the challenger for their participation in securing the system, thereby preventing spam even within this permissionless system. Additionally, there is no need to submit them at a regular interval because the fault proof game can efficiently prove the entire history of the chain since genesis.
+In the envisioned Fault Proof System, anyone can submit a withdrawal claim, and these withdrawal claims can be submitted at any time. Submitting withdrawal claims can be permissionless when claims come with bonds attached to them, as these bonds act as collateral if the claim is proven to be invalid. If a challenger successfully challenges the claim, the bond is paid out to the challenger for their participation in securing the system, thereby preventing spam even within this permissionless system. Additionally, there is no need to submit them at a regular interval because the fault proof game can efficiently prove the entire history of the chain since genesis.
 
 The fault proof implementation may initially rely on a trusted set of chain attestors to be the final arbiter of disputes. Challengers must request attestations from a large number of chain attestors and combine these attestations into a single transaction called an attestation proof. The attestation proof is then used to challenge invalid claims.
 
@@ -290,7 +290,7 @@ A generic Plasma protocol is able to scale beyond what is possible on L1 because
 *   If the DA Provider does not send the proof to the user, the user may submit a DA challenge. This forces the DA Provider to post the transaction data onchain. If the DA Provider does not submit the proof onchain, the hash is deleted. This ensures the user can always (after the challenge period) sync the Plasma chain.
     *   DA challenge periods may be extended in case of heavy L1 congestion.
 *   The user may also submit an L1 transaction to withdraw from the Plasma chain in order to switch their DA Provider.
-*   Settlement of Plasma chains use a near identical fault proof system to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Plasma Contract.
+*   Settlement of Plasma chains use a near identical Fault Proof System to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Plasma Contract.
 
 Because of the ability for hashes to reduce arbitrary size data into a constant size commitment, and the ability to parallelize transaction data hashing, it is possible to achieve near-perfect horizontal scalability of data commitments using Plasma DA. This means that it is possible to put massively scalable applications such as games or social media on Plasma chains.
 

@@ -1,7 +1,7 @@
 ---
 title: OP-Challenger explainer
 lang: en-US
-description: Learn about OP-Challenger and how it operates within the OP Stack's fault proof system.
+description: Learn about OP-Challenger and how it operates within the OP Stack's Fault Proof System.
 ---
 
 import { Callout } from 'nextra/components'

@@ -1,7 +1,7 @@
 ---
 title: Fault proofs explainer
 lang: en-US
-description: Learn about the OP Stack's fault proof system.
+description: Learn about the OP Stack's Fault Proof System.
 ---
 
 import { Callout } from 'nextra/components'
@@ -45,7 +45,7 @@ Any user can run a node for the OP Stack chain in question and use the `op-chall
 
 ## Modular design and multi-layer security
 
-The OP Stack Fault Proof system is [modular in design](/stack/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/fault-proofs/cannon) proof system.
+The OP Stack Fault Proof System is [modular in design](/stack/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/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/fault-proofs/fp-security) have been built around the game, as follows:
@@ -78,7 +78,7 @@ It's not expected that normal users run `op-proposer` to regularly propose outpu
 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?
+### 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.

@@ -1,7 +1,7 @@
 ---
 title: FP System components
 lang: en-US
-description: Learn about fault proof system components and how they 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'
@@ -13,7 +13,7 @@ This page explains the fault proof system components and how they work together
 
 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.
-The modular design of the fault proof system lays the foundation for a multi-proof future, inclusive of ZK proofs, and significantly increases the opportunities for ecosystem contributors to build alternative fault proof components to secure the system.
+The modular design of the Fault Proof System lays the foundation for a multi-proof future, inclusive of ZK proofs, and significantly increases the opportunities for ecosystem contributors to build alternative fault proof components to secure the system.
 
 <Callout type="info">
   Visit the [Immunefi bug bounty page](https://immunefi.com/bounty/optimism/) for details on testing and helping to build a robust fault proof system.
@@ -30,7 +30,7 @@ See the video below for a full technical walkthrough of the OP Stack's first fau
 The OP Stack's unique, modular design allows the decoupling of the FPP and FPVM, resulting in the following:
 
 *   development of multiple proof systems, unique dispute games, and a variety of FPVMs in the future.
-*   custom-built fault proof systems comprised of any combination of these isolated components—including validity proofs, attestation proofs, or ZKVM.
+*   custom-built Fault Proof Systems comprised of any combination of these isolated components—including validity proofs, attestation proofs, or ZKVM.
 *   dispute games in the dispute protocol backed by multiple security mechanisms.
 
 ## Fault proof program

@@ -55,7 +55,7 @@ The `FaultDisputeGame` contracts store bonds within a `DelayedWETH` contract tha
 ### Cumulative security impact
 
 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 invalid proposals will generally be rejected by the Fault Proof system while the `Guardian` can act as a backstop only in case of a failure in the fault proof game.
+The most significant change in security model with the introduction of Fault Proof Mainnet is that `SystemOwner` can take a more passive role as invalid proposals will generally be rejected by the Fault Proof System while the `Guardian` can act as a backstop only in case of a failure in the fault proof game.
 
 ## Next steps
 

@@ -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.
+**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.
 
 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.
 

@@ -37,7 +37,7 @@ Contract releases have a component name of `op-contracts` and therefore are tagg
 
 The release fixes security vulnerabilities found in Fault Proof contracts. They were made in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk.
 
-The upgrade was coupled with the [Granite network upgrade](/builders/node-operators/network-upgrades#granite) to improve the stability and performance of the fault proof system. In addition, the capabilities of the Guardian and DeputyGuardian have been extended to set the anchor state for the fault proof system in order to prevent referencing invalid anchor states.
+The upgrade was coupled with the [Granite network upgrade](/builders/node-operators/network-upgrades#granite) to improve the stability and performance of the Fault Proof System. In addition, the capabilities of the Guardian and DeputyGuardian have been extended to set the anchor state for the Fault Proof System in order to prevent referencing invalid anchor states.
 
 *   [Official - Fault Proof Fixes Release](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.6.0)
 *   [Governance Post](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733)