From 32b53615d36b72389d34ce2761c8aa5a2f2ff8fd Mon Sep 17 00:00:00 2001 From: moonman <155266991+moooonman@users.noreply.github.com> Date: Thu, 27 Feb 2025 13:50:31 +0100 Subject: [PATCH 1/6] Update adding-derivation-attributes.mdx --- .../chain-operators/tutorials/adding-derivation-attributes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/operators/chain-operators/tutorials/adding-derivation-attributes.mdx b/pages/operators/chain-operators/tutorials/adding-derivation-attributes.mdx index 1bb3c9864..f0a8c0e97 100644 --- a/pages/operators/chain-operators/tutorials/adding-derivation-attributes.mdx +++ b/pages/operators/chain-operators/tutorials/adding-derivation-attributes.mdx @@ -43,7 +43,7 @@ contract L1Burn { uint256 public total; /** - * @notice Mapping of blocks numbers to total burn. + * @notice Mapping of block numbers to total burn. */ mapping (uint64 => uint256) public reports; From 0afacb04018b704c4ea0168dd11280287332beda Mon Sep 17 00:00:00 2001 From: moonman <155266991+moooonman@users.noreply.github.com> Date: Thu, 27 Feb 2025 13:50:52 +0100 Subject: [PATCH 2/6] Update architecture.mdx --- pages/operators/chain-operators/architecture.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/operators/chain-operators/architecture.mdx b/pages/operators/chain-operators/architecture.mdx index 5bc5b42ef..041d05014 100644 --- a/pages/operators/chain-operators/architecture.mdx +++ b/pages/operators/chain-operators/architecture.mdx @@ -123,7 +123,7 @@ Bootnodes facilitate peer discovery for network nodes. They help initialize peer ### Archive RPC Nodes -We recommend setting up some archive nodes for internal RPC usage, primary used by the challenger, proposer and security monitoring tools like [monitorism](/operators/chain-operators/tools/chain-monitoring#monitorism). +We recommend setting up some archive nodes for internal RPC usage, primarily used by the challenger, proposer and security monitoring tools like [monitorism](/operators/chain-operators/tools/chain-monitoring#monitorism). ```yaml GETH_GCMODE: "archive" From 65ac14b74380279f529f8480de983915c53257e3 Mon Sep 17 00:00:00 2001 From: moonman <155266991+moooonman@users.noreply.github.com> Date: Thu, 27 Feb 2025 13:51:34 +0100 Subject: [PATCH 3/6] Update blobs.mdx --- pages/operators/node-operators/management/blobs.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/operators/node-operators/management/blobs.mdx b/pages/operators/node-operators/management/blobs.mdx index 8511e3a2a..4bb60fec9 100644 --- a/pages/operators/node-operators/management/blobs.mdx +++ b/pages/operators/node-operators/management/blobs.mdx @@ -71,9 +71,9 @@ These will need to be set on `op-node` and `op-geth` for the sequencer and all o ## Configure a blob archiver -There is a configurable `beacon-archiver` that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will "prune" or remove them. If your node is already in sync with the head of the chain, you won't need to use a `beacon-archiver`. +There is a configurable `beacon-archiver` that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will "prune" or remove them. If your node is already in sync with the head of the chain, you won't need to use a `beacon-archiver`. -* If you're spinning up a new node, if you load it from a snapshot that's within 18 days (the amount of time until blobs are pruned) you will not need to use a `beacon-archiver` at all as long as your node does not fall offline for more than 18 days. +* If you're spinning up a new node, if you load it from a snapshot that's within 18 days (the amount of time until blobs are pruned) you will not need to use a `beacon-archiver` at all as long as your node does not fall offline for more than 18 days. * If you're running a new node that is syncing more than 18 days (the amount of time until blobs are pruned) after Ecotone launch, then you will need to configure a `beacon-archiver` on the `op-node`. ```shell From 164461236fb6f5e46dbe9ac05162fd0a0dcc9f6f Mon Sep 17 00:00:00 2001 From: moonman <155266991+moooonman@users.noreply.github.com> Date: Thu, 27 Feb 2025 13:52:38 +0100 Subject: [PATCH 4/6] Update troubleshooting.mdx --- pages/operators/node-operators/management/troubleshooting.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/operators/node-operators/management/troubleshooting.mdx b/pages/operators/node-operators/management/troubleshooting.mdx index 02f5bddcf..f53007bcd 100644 --- a/pages/operators/node-operators/management/troubleshooting.mdx +++ b/pages/operators/node-operators/management/troubleshooting.mdx @@ -87,7 +87,7 @@ it is restarted. It is always best to shut down Geth gracefully, i.e. using a shutdown command such as `ctrl-c`, `docker stop -t 300 ` or -`systemctl stop` (although please note that `systemctl sto`p has a default timeout +`systemctl stop` (although please note that `systemctl stop` has a default timeout of 90s - if Geth takes longer than this to gracefully shut down it will quit forcefully. Update the `TimeoutSecs` variable in `systemd.service` to override this value to something larger, at least 300s). From ace80a8f8f3c09a2c5ba6806056ab7657e471cb8 Mon Sep 17 00:00:00 2001 From: moonman <155266991+moooonman@users.noreply.github.com> Date: Thu, 27 Feb 2025 13:53:03 +0100 Subject: [PATCH 5/6] Update explainer.mdx --- pages/stack/fault-proofs/explainer.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/fault-proofs/explainer.mdx b/pages/stack/fault-proofs/explainer.mdx index 3afad066f..73a648af1 100644 --- a/pages/stack/fault-proofs/explainer.mdx +++ b/pages/stack/fault-proofs/explainer.mdx @@ -85,7 +85,7 @@ Assuming OP Mainnet parameters, where proposals will be posted hourly, that's 0. 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. +However, the capital requirements for operating a FP chain in itself are 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. From b4bfc9589b97f34cc029e8521b8f298c8ccff8c5 Mon Sep 17 00:00:00 2001 From: moonman <155266991+moooonman@users.noreply.github.com> Date: Thu, 27 Feb 2025 13:53:42 +0100 Subject: [PATCH 6/6] Update mips.mdx --- pages/stack/fault-proofs/mips.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/fault-proofs/mips.mdx b/pages/stack/fault-proofs/mips.mdx index 995ae979e..b84a2b493 100644 --- a/pages/stack/fault-proofs/mips.mdx +++ b/pages/stack/fault-proofs/mips.mdx @@ -19,7 +19,7 @@ The Dispute Game itself is modular, allowing for any FPVM to be used in a disput The `FaultDisputeGame.sol` interacts with `MIPS.sol` and then `MIPS.sol` calls into `PreimageOracle.sol`. `MIPS.sol` is only called at the max depth of the game when someone needs to call `step`. `FaultDisputeGame.sol` is the deployed instance of a Fault Dispute Game for an active dispute, and `PreimageOracle.sol` stores Pre-images. -* Pre-images contain data from both L1 and L2, which includes information such as block headers, transactions, receipts, world state nodes, and more. Pre-images are used as the inputs to the derivation process used to calculate the true L2 state, and subsequently the true L2 state is used to resolve a dispute game. +* Pre-images contain data from both L1 and L2, which includes information such as block headers, transactions, receipts, world state nodes, and more. Pre-images are used as the inputs to the derivation process used to calculate the true L2 state, and subsequently the true L2 state is used to resolve a dispute game. * A Fault Dispute Game, at a high-level, will effectively determine what L2 state is currently agreed-upon, and move through L2 state until the first disagreed-upon state is found. How the Pre-images are determined and populated into the `PreimageOracle.sol` contract is out-of-scope for this reference document on the `MIPS.sol` contract, as that contract only consumes Pre-images that have already been populated by the off-chain Cannon implementation. The `MIPS.sol` contract is called by a running instance of a dispute game (i.e. by a `FaultDisputeGame.sol` contract), and is only called once a dispute game reaches a leaf node in the state transition tree that is currently being disputed.