fix(repo): fix typos (#14165)

packages/protocol/docs/L2EIP1559.md

@@ -32,4 +32,4 @@ It turns out the initial value of gasExcess doesn't really matter for the above
 
 ## Adjust the slope
 
-To adjust the slope of the curve to satisfy $R == basefee(2T)/basefee(T)$, we simply need to chose $M$ and $b_0$. $b_0$ is simply to decide -- if we believe the cost of a L2 transaction is $1/n$ of the same L1 transaction, we simply use the current L1 base fee divided by $n$. Then we can simply tune $M$ to make sure $R == basefee(2T)/basefee(T)$ holds. This is very simply manually a try-and-adjust approach as shown in `Lib1559Math.t.sol`. The TaikoL1 contract will check if $R == basefee(2T)/basefee(T)$ holds but will not calculate $M$ for us.
+To adjust the slope of the curve to satisfy $R == basefee(2T)/basefee(T)$, we simply need to choose $M$ and $b_0$. $b_0$ is simply to decide -- if we believe the cost of a L2 transaction is $1/n$ of the same L1 transaction, we simply use the current L1 base fee divided by $n$. Then we can simply tune $M$ to make sure $R == basefee(2T)/basefee(T)$ holds. This is very simply manually a try-and-adjust approach as shown in `Lib1559Math.t.sol`. The TaikoL1 contract will check if $R == basefee(2T)/basefee(T)$ holds but will not calculate $M$ for us.

packages/protocol/docs/how_taiko_proves_blocks.md

@@ -63,7 +63,7 @@ Note that the anchor transaction emits an `Anchored` event that may help ZKP to
 ZKP shall also check the signature of the anchor transaction:
 
 - The signer must be _`TaikoL2.GOLDEN_TOUCH_ADDRESS`_.
-- The signature must use `1` as the `k` value if the calculated `r` is not `0`, other wise, `k` must be `2`. See [TaikoL2Signer.sol](https://github.com/taikoxyz/taiko-mono/blob/main/packages/protocol/contracts/L2/TaikoL2Signer.sol) and Taiko [whitepaper](https://taikoxyz.github.io/taiko-mono/taiko-whitepaper.pdf).
+- The signature must use `1` as the `k` value if the calculated `r` is not `0`, otherwise, `k` must be `2`. See [TaikoL2Signer.sol](https://github.com/taikoxyz/taiko-mono/blob/main/packages/protocol/contracts/L2/TaikoL2Signer.sol) and Taiko [whitepaper](https://taikoxyz.github.io/taiko-mono/taiko-whitepaper.pdf).
 
 ### Block Metadata
 

packages/website/pages/docs/concepts/proposing.mdx

@@ -61,7 +61,7 @@ The transaction list intrinsic validity function checks that the transaction lis
 A transaction list is valid if and only if:
 
 1. The transaction list is well-formed RLP, with no additional trailing bytes (rule #1 in Ethereum yellow paper).
-2. The transaction list is no larger than than $K_{TxListMaxBytes}$.
+2. The transaction list is no larger than $K_{TxListMaxBytes}$.
 3. The sum of all transactions' gas limit is no larger than the protocol constant $K_{BlockMaxGasLimit}$.
 4. The total number of transactions is no larger than the protocol constant $K_{BlockMaxTxs}$.
 

packages/website/pages/docs/concepts/proving.mdx

@@ -13,7 +13,7 @@ There are three states that a block can be in on Taiko:
 
 We already know what a proposed block is (must pass at least the block-level intrinsic validity tests to be accepted by the TaikoL1 contract). Next, a proposed block can be valid or invalid, depending on whether it passes the transaction list intrinsic validity test. A block is invalid if it fails the transaction list intrinsic validity test, and this block is not created on Taiko.
 
-Now, a block can be proved, but also further "verified". What's the difference? A block is proved if it has a valid proof which proves a state transition from one state (parent block) to another (current block). However, blocks are proven in parallel by the decentralized provers. So while a block can prove a parent block transitions to the current block, we don't know if the parent block itself has been proven. As you can see, for a block to be "verified", it needs to prove the valid state transition to the current block, but the parent also need to be verified. We assume that the genesis block (which has no parent), is verified. So all the children blocks from genesis to the current block need to have proofs of their state transition for the current block to be "verified".
+Now, a block can be proved, but also further "verified". What's the difference? A block is proved if it has a valid proof which proves a state transition from one state (parent block) to another (current block). However, blocks are proven in parallel by the decentralized provers. So while a block can prove a parent block transitions to the current block, we don't know if the parent block itself has been proven. As you can see, for a block to be "verified", it needs to prove the valid state transition to the current block, but the parent also needs to be verified. We assume that the genesis block (which has no parent), is verified. So all the children blocks from genesis to the current block need to have proofs of their state transition for the current block to be "verified".
 
 For the visual learners here is a visualization of the three stages (proposed -> proved -> verified)
 
@@ -68,4 +68,4 @@ We have a `realProofSkipSize` set [here](https://github.com/taikoxyz/taiko-mono/
 
 ### Your role as a prover
 
-We are describing this dynamic so you can be informed when you run a prover. It's very possible that without the correct strategy, you will not be profitable as a prover. You are naturally competing in an open space where others could have more efficient hardware and generate a proof in a short amount of time that you cannot compete against.
+We are describing this dynamic so you can be informed when you run a prover. It's very possible that without the correct strategy, you will not be profitable as a prover. You are naturally competing in an open space where others could have more efficient hardware and generate a proof in a short amount of time that you cannot compete against.

packages/website/pages/docs/concepts/taiko-nodes.mdx

@@ -19,7 +19,7 @@ The [taiko-geth](https://github.com/taikoxyz/taiko-geth) software is a fork of [
 
 Like Ethereum mainnet execution engines, `taiko-geth` listens to new L2 transactions broadcasted in the L2 network, executes them in the EVM, and holds the latest state and database of all current L2 data.
 
-You can see all the changes made in the the `taiko-geth` fork at [geth.taiko.xyz](https://geth.taiko.xyz)!
+You can see all the changes made in the `taiko-geth` fork at [geth.taiko.xyz](https://geth.taiko.xyz)!
 
 ## taiko-client
 

packages/website/pages/docs/guides/build-on-taiko/setup-your-wallet.mdx

@@ -4,7 +4,7 @@ import { Steps } from "nextra-theme-docs";
 
 ## Overview
 
-This guide help you connect your wallet to Taiko (Alpha-3 testnet). There are two networks to configure your wallet with: Ethereum (Sepolia testnet) and Taiko (Alpha-3 testnet).
+This guide helps you connect your wallet to Taiko (Alpha-3 testnet). There are two networks to configure your wallet with: Ethereum (Sepolia testnet) and Taiko (Alpha-3 testnet).
 
 ## Prerequisites
 

packages/website/pages/docs/guides/run-a-node/run-a-taiko-node.mdx

@@ -258,7 +258,7 @@ Your RPC provider has a limit on the number of requests. You can try using a dif
 The block that you want to prove has already been verified, you can ignore this.
 
 #### `error: L1_ALREADY_PROVEN`
-This block has been proven by someone else, but its not verified yet, you can ignore it.
+This block has been proven by someone else, but it's not verified yet, you can ignore it.
 
 #### `Fatal: Failed to register the Ethereum service: database contains incompatible genesis`
 Try to remove the node with `docker compose down -v` and then try again.