Documentation Improvements Across Multiple Files (#8611)

- Fix various typos in documentation files (e.g., 'and well as' to 'as well as', 'systemcall' to 'syscall', 'brisma' to 'Prisma').
- Clarify and correct technical information in several sections, including MIPS.sol documentation, L2 Output RPC method, memory write descriptions, and more.
- Standardize terminology and fix grammatical errors for enhanced readability and consistency.
- Correct variable naming conventions and file path errors.

These changes collectively enhance the accuracy and readability of the documentation, ensuring it remains clear and accessible for users and developers.

[Files affected: cannon/docs/README.md, indexer/ui/README.md, packages/chain-mon/src/fault-mon/README.md, packages/contracts-bedrock/STYLE_GUIDE.md, packages/fee-estimation/README.md, specs/messengers.md, specs/meta/devnet.md, specs/rollup-node.md]

cannon/docs/README.md

@@ -12,7 +12,7 @@ to reproduce the same instruction onchain as offchain.
 This is an onchain implementation of big-endian 32-bit MIPS instruction execution.
 This covers MIPS III, R3000, as required by the `mips` Go compiler/runtime target.
 
-The systemcall instruction is implemented to simulate a minimal subset of the Linux kernel,
+The syscall instruction is implemented to simulate a minimal subset of the Linux kernel,
 just enough to serve the needs of a basic Go program:
 allocate memory, read/write to certain file-descriptors, and exit.
 
@@ -30,7 +30,7 @@ The difference is that it has access to the full memory, and pre-image oracle.
 And as it executes each step, it can optionally produce the witness data for the step, to repeat it onchain.
 
 The Cannon CLI is used to load a program into an initial state,
-transition it N steps quickly without witness generation, and 1 step while producing a witness.
+transition it to N steps quickly without witness generation, and 1 step while producing a witness.
 
 `mipsevm` is instrumented for proof generation and handles delay-slots by isolating each individual instruction
 and tracking `nextPC` to emulate the delayed `PC` changes after delay-slot execution.
@@ -90,7 +90,7 @@ where the write is over the same memory as was last read.
 The memory access is specifically:
 - instruction (4 byte) read at `PC`
 - load or syscall mem read, always aligned 4 bytes, read at any `addr`
-- store or syscall mem write, always aligned 4 bytes, at ths same `addr`
+- store or syscall mem write, always aligned 4 bytes, at the same `addr`
 
 Writing only once, at the last read leaf, also means that the leaf can be safely updated and the same proof-data
 that was used to verify the read, can be used to reconstruct the new `memRoot` of the memory tree,

packages/chain-mon/src/fault-mon/README.md

@@ -16,7 +16,7 @@ pnpm build
 
 ## Running the service
 
-Copy `.env.example` into a new file named `.env`, then set the environment variables listed there. Additional env setting are listed on `--help`. If running the fault detector against
+Copy `.env.example` into a new file named `.env`, then set the environment variables listed there. Additional env settings are listed on `--help`. If running the fault detector against
 a custom op chain, the `OptimismPortal` contract addresses must also be set associated with the op-chain.
 
 Once your environment variables or flags have been set, run the service via:

packages/contracts-bedrock/STYLE_GUIDE.md

@@ -55,7 +55,7 @@ Immutable variables:
 - should have a hand written getter function
 
 This approach clearly indicates to the developer that the value is immutable, without exposing
-the non-standard casing to the interface. It also ensure that we don’t need to break the ABIs if
+the non-standard casing to the interface. It also ensures that we don’t need to break the ABIs if
 we switch between values being in storage and immutable.
 
 #### Spacers

packages/fee-estimation/README.md

@@ -56,7 +56,7 @@ const fees = await estimateFees({
   */
   functionName: 'burn',
   abi: optimistABI,
-  args: [tokenid],
+  args: [tokenId],
   account: optimistOwnerAddress,
   to: '0x2335022c740d17c2837f9C884Bfe4fFdbf0A95D5',
 })

specs/messengers.md

@@ -19,7 +19,7 @@ the ability to replay cross domain messages and sit directly on top of the lower
 level system contracts responsible for cross domain messaging on L1 and L2.
 
 The `CrossDomainMessenger` is extended to create both an
-`L1CrossDomainMessenger` and well as a `L2CrossDomainMessenger`.
+`L1CrossDomainMessenger` as well as a `L2CrossDomainMessenger`.
 These contracts are then extended with their legacy APIs to provide backwards
 compatibility for applications that integrated before the Bedrock system
 upgrade.

specs/meta/devnet.md

@@ -33,7 +33,7 @@ The devnet comes with a pre-funded account you can use as a faucet:
 - Private key: `ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80`
 
 The faucet account exists on both L1 and L2. To deposit onto L2 from L1, you can use the `deposit` hardhat task.
-Run the following from the `packags/contracts` directory:
+Run the following from the `packages/contracts` directory:
 
 ```bash
 npx hardhat deposit --amount-eth <amount in eth> --to <address>

specs/rollup-node.md

@@ -63,7 +63,7 @@ byte hash corresponding to the [L2 output root](./proposals.md#l2-output-commitm
 
 ### Output Method API
 
-The input and return types here are as defined by the [engine API specs][engine-structures]).
+The input and return types here are as defined by the [engine API specs][engine-structures].
 
 [engine-structures]: https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#structures