Merge pull request #1423 from moooonman/main

fix spelling issues

Author: krofax

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"

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;
 

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

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 <container ID>` 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). 

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.

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.