docs: typos (#17335)

Co-authored-by: Matthias Seitz <matthias.seitz@outlook.de>

crates/engine/tree/docs/root.md

@@ -10,7 +10,7 @@ root of the new state.
 4. Compares the root with the one received in the block header.
 5. Considers the block valid.
 
-This document describes the lifecycle of a payload with the focus on state root calculation,
+This document describes the lifecycle of a payload with a focus on state root calculation,
 from the moment the payload is received, to the moment we have a new state root.
 
 We will look at the following components:
@@ -26,7 +26,7 @@ We will look at the following components:
 It all starts with the `engine_newPayload` request coming from the [Consensus Client](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients).
 
 We extract the block from the payload, and eventually pass it to the `EngineApiTreeHandler::insert_block_inner`
-method which executes the block and calculates the state root. 
+method that executes the block and calculates the state root. 
 https://github.com/paradigmxyz/reth/blob/2ba54bf1c1f38c7173838f37027315a09287c20a/crates/engine/tree/src/tree/mod.rs#L2359-L2362
 
 Let's walk through the steps involved in the process.
@@ -166,7 +166,7 @@ and send `StateRootMessage::ProofCalculated` to the [State Root Task](#state-roo
 
 ### Exhausting the pending queue
 
-To exhaust the pending queue from the step 2 of the `spawn_or_queue` described above,
+To exhaust the pending queue from step 2 of the `spawn_or_queue` described above,
 the [State Root Task](#state-root-task) calls into another method `on_calculation_complete` every time
 a proof is calculated.
 https://github.com/paradigmxyz/reth/blob/2ba54bf1c1f38c7173838f37027315a09287c20a/crates/engine/tree/src/tree/root.rs#L379-L387
@@ -230,11 +230,11 @@ https://github.com/paradigmxyz/reth/blob/2ba54bf1c1f38c7173838f37027315a09287c20
 https://github.com/paradigmxyz/reth/blob/2ba54bf1c1f38c7173838f37027315a09287c20a/crates/engine/tree/src/tree/root.rs#L1093
 3. Update accounts trie
 https://github.com/paradigmxyz/reth/blob/2ba54bf1c1f38c7173838f37027315a09287c20a/crates/engine/tree/src/tree/root.rs#L1133
-4. Calculate keccak hashes of the nodes below the certain level
+4. Calculate keccak hashes of the nodes below a certain level
 https://github.com/paradigmxyz/reth/blob/2ba54bf1c1f38c7173838f37027315a09287c20a/crates/engine/tree/src/tree/root.rs#L1139
 
 As you can see, we do not calculate the state root hash of the accounts trie
-(the one that will be the result of the whole task), but instead calculate only the certain hashes.
+(the one that will be the result of the whole task), but instead calculate only certain hashes.
 
 This is an optimization that comes from the fact that we will likely update the top 2-3 levels of the trie
 in every transaction, so doing that work every time would be wasteful.

docs/design/headers-downloader.md

@@ -6,6 +6,6 @@
 * First, we implemented the reverse linear download. It received the current chain tip and local head as arguments and requested blocks in batches starting from the tip, and retried on request failure. See [`reth#58`](https://github.com/paradigmxyz/reth/pull/58) and [`reth#119`](https://github.com/paradigmxyz/reth/pull/119).
 * The first complete implementation of the headers stage was introduced in [`reth#126`](https://github.com/paradigmxyz/reth/pull/126). The stage looked up the local head & queried the consensus for the chain tip and queried the downloader passing them as arguments. After the download finished, the stage would proceed to insert headers in the ascending order by appending the entries to the corresponding tables.
 * The original downloader was refactored in [`reth#249`](https://github.com/paradigmxyz/reth/pull/249) to return a `Future` which would resolve when either the download is completed or the error occurred during polling. This future kept a pointer to a current request at any time, allowing to retry the request in case of failure. The insert logic of the headers stage remained unchanged.
-    * NOTE: Up to this point the headers stage awaited full range of blocks (from local head to tip) to be downloaded before proceeding to insert.
-* [`reth#296`](https://github.com/paradigmxyz/reth/pull/296) introduced the `Stream` implementation of the download as well as the commit threshold for the headers stage. The `Stream` implementation yields headers as soon as they are received and validated. It dispatches the request for the next header batch until the head is reached. The headers stage now has a configurable commit threshold which allows configuring the insert batch size. With this change, the headers stage no longer waits for the download to be complete, but rather collects the headers from the stream up to the commit threshold parameter. After collecting, the stage proceeds to insert the batch. The process is repeated until the stream is drained. At this point, we populated all tables except for HeadersTD since it has to be computed in a linear ascending order. The stage starts walking the populated headers table and computes & inserts new total difficulty values.
-* This header implementation is unique because it is implemented as a Stream, it yields headers as soon as they become available (contrary to waiting for download to complete) and it keeps only one header in buffer (required to form the next header request) .
+    * NOTE: Up to this point the headers stage awaited the full range of blocks (from local head to tip) to be downloaded before proceeding to insert.
+* [`reth#296`](https://github.com/paradigmxyz/reth/pull/296) introduced the `Stream` implementation of the download as well as the commit threshold for the headers stage. The `Stream` implementation yields headers as soon as they are received and validated. It dispatches the request for the next header batch until the head is reached. The headers stage now has a configurable commit threshold which allows configuring the insert batch size. With this change, the headers stage no longer waits for the download to be complete, but rather collects the headers from the stream up to the commit threshold parameter. After collecting, the stage proceeds to insert the batch. The process is repeated until the stream is drained. At this point, we populated all tables except for HeadersTD since it has to be computed in a linear ascending order. The stage starts walking through the populated headers table and computes & inserts new total difficulty values.
+* This header implementation is unique because it is implemented as a Stream, it yields headers as soon as they become available (contrary to waiting for download to complete), and it keeps only one header in buffer (required to form the next header request) .

docs/vocs/docs/pages/cli/cli.mdx

@@ -2,7 +2,7 @@ import Summary from './SUMMARY.mdx';
 
 # CLI Reference
 
-The Reth node is operated via the CLI by running the `reth node` command. To stop it, press `ctrl-c`. You may need to wait a bit as Reth tears down existing p2p connections or other cleanup tasks.
+The Reth node is operated via the CLI by running the `reth node` command. To stop it, press `ctrl-c`. You may need to wait a bit as Reth tears down existing p2p connections or performs other cleanup tasks.
 
 However, Reth has more commands:
 

docs/vocs/docs/pages/index.mdx

@@ -150,7 +150,7 @@ Leading infra companies use Reth for MEV applications, staking, RPC services and
 
 ## Built with Reth SDK
 
-Production chains and networks powered by Reth's modular architecture. These nodes are built using existing components without forking, saving several engineering hours while improving maintainability.
+Production chains and networks are powered by Reth's modular architecture. These nodes are built using existing components without forking, saving several engineering hours while improving maintainability.
 
 <div className="mb-12">
     <SdkShowcase />