Update scroll-documentation

src/content/docs/en/developers/l1-and-l2-bridging.mdx

@@ -26,12 +26,12 @@ In addition to token transfers, the Scroll Messenger contract enables cross-chai
 
 <ClickToZoom src={L1GatewayWHITE} />
 
-There are many entry points from the user to the Scroll bridge. This will depend on what you want to do and how you want to do it. If you want to send ETH or ERC20 tokens, you should use the `GatewayRouter` . If you want to send NFTs, you should use the `L1ERC721Gateway` or `L1ERC1155Gateway`. If you want to send arbitrary data, you should use the `L1ScrollMessenger`. All Gateway transfers use the Scroll Messenger to send assets cross-chain, whose job is to append the transactions to the Message Queue for L2 inclusion.
+There are many entry points from the user to the Scroll bridge. This will depend on what you want to do and how you want to do it. If you want to send ETH or ERC20 tokens, you should use the `GatewayRouter`. If you want to send NFTs, you should use the `L1ERC721Gateway` or `L1ERC1155Gateway`. If you want to send arbitrary data, you should use the `L1ScrollMessenger`. All Gateway transfers use the Scroll Messenger to send assets cross-chain, whose job is to append the transactions to the Message Queue for L2 inclusion.
 
 ## L2 Gateway architecture
 
 <ClickToZoom src={withdrawWHITE} />
 
-Regarding possible permissionlessly callable entry points, the L2 Gateway Architecture is very similar to L1. The difference is that when sending a message from L2, calling the `appendMessage` function will store the message in an append-only binary merkle tree (aka withdraw tree) in the `L2MessageQueue`. When a new message is sent to the `L2MessageQueue`, the relayer will detect it and store it in the database. When the block is finalized, it will generate a proof of the new merkle path and pass it to the L1geth node to execute on `L1ScrollMessenger` . All finalized withdraw roots will be stored in the rollup contract so we can verify the proof against them. In the next Scroll versions, the Relayer won't be needed since all users will be able to finalize the transaction on L1.
+Regarding possible permissionlessly callable entry points, the L2 Gateway Architecture is very similar to L1. The difference is that when sending a message from L2, calling the `appendMessage` function will store the message in an append-only binary merkle tree (aka withdraw tree) in the `L2MessageQueue`. When a new message is sent to the `L2MessageQueue`, the relayer will detect it and store it in the database. When the block is finalized, it will generate a proof of the new merkle path and pass it to the L1geth node to execute on `L1ScrollMessenger`. All finalized withdraw roots will be stored in the rollup contract so we can verify the proof against them. In the next Scroll versions, the Relayer won't be needed since all users will be able to finalize the transaction on L1.
 
-In the upcoming sections, we will explore the technical aspects of the bridge, including the smart contract API required to utilize its capabilities. Detailed guides with code examples are provided in the Developer Guides section to assist developers and users in understanding and implementing these functionalities.
+In the upcoming sections, we will explore the technical aspects of the bridge, including the smart contract API required to utilize its capabilities. Detailed guides with code examples are provided in the Developer Guides section to assist developers and users in understanding and implementing these functionalities.

src/content/docs/en/developers/verifying-smart-contracts.mdx

@@ -76,7 +76,7 @@ npx hardhat verify --network scrollSepolia 0xD9880690bd717189cC3Fbe7B9020F27fae7
 ```
 
 <Aside type="danger" title="Warning">
-  You may receive an error stating `etherscan.apiKey.trim is not a function` . If so, you need to update
+  You may receive an error stating `etherscan.apiKey.trim is not a function`. If so, you need to update
   `@nomiclabs/hardhat-etherscan` to be able to support custom chains. Try running `npm update
   @nomiclabs/hardhat-etherscan`
 </Aside>
@@ -98,4 +98,4 @@ forge verify-contract <contract address> <contract name> \
 ```
 <Aside type="caution" title="Caution">
   Do not specify the chain ID.
-</Aside>
+</Aside>

src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md

@@ -51,7 +51,7 @@ There are established methods of conducting trusted setup ceremonies with weak t
 
 - Given a commitment $c = [P(\tau)]_1$, an evaluation $P(a) = b$, and a proof $\pi = [Q(\tau)]_1$
 - Verify that $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$
-  - Some algebra shows that this is equivalent to checking that that the quotient polynomial is correctly formed at $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$
+  - Some algebra shows that this is equivalent to checking that the quotient polynomial is correctly formed at $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$
     $$
     \begin{align*}
     & e(\pi, [\tau - a]_2) = e(c - [b]_1, h) \\ \iff

src/content/docs/en/technology/bridge/withdraw-gateways.mdx

@@ -82,7 +82,7 @@ The withdraw of ERC20 tokens works as follows.
 The withdrawal of standard and custom ERC20 tokens works in the same way as follows.
 
 3. The `L2StandardERC20Gateway` or `L2CustomERC20Gateway` contract burns the withdrawn ERC20 token, encodes the withdrawal into a message, and sends it to `L2ScrollMessenger`.
-4. The L1 withdrawal execution transaction calls `L1ScrollMessenger.relayMessageWithProof` function to finalize the withdrawals on L1. In the case of standard or custome ERC20 token withdrawal, the transaction calls `finalizeWithdrawERC20` function on the `L1StandardERC20Gateway` or `L1CustomERC20Gateway` contract respectively.
+4. The L1 withdrawal execution transaction calls `L1ScrollMessenger.relayMessageWithProof` function to finalize the withdrawals on L1. In the case of standard or custom ERC20 token withdrawal, the transaction calls `finalizeWithdrawERC20` function on the `L1StandardERC20Gateway` or `L1CustomERC20Gateway` contract respectively.
    - In the `L1StandardERC20Gateway` contract, if this is the first withdrawal transaction of a ERC20 token, `finalizeWithdrawERC20` function will update the mapping from L1 token address to its L2 token address in the `tokenMapping`.
 5. The L1 ERC20 token gateway releases the locked ERC20 tokens by transferring them from itself to the recipient address on L1.
 6. If the user calls `withdrawERC20AndCall` on L2, the gateways will call the target L1 contract with additional data.

src/content/docs/en/technology/chain/blocks.mdx

@@ -27,7 +27,7 @@ The block header in Scroll mirrors the structure of Ethereum's. However, certain
 | `gasLimit`          | The maximum gas allowed in the block.                              |
 | `gasUsed`           | The gas used in the block.                                         |
 | `timestamp`         | The block time.                                                    |
-| `extraData`         | Signature by the block's signer, followd by arbitrary additional data. |
+| `extraData`         | Signature by the block's signer, followed by arbitrary additional data. |
 | `mixHash`           | Always 0.                                                          |
 | `nonce`             | Always 0.                                                          |
 | `baseFee`           | Currently empty in Scroll because we haven't enabled the EIP-1559. |

src/content/docs/en/technology/chain/transactions.mdx

@@ -24,7 +24,7 @@ Note that [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) and [EIP-1559](htt
 
 ### L1 Message Transaction
 
-We introduce a new type of transactions `L1MessageTx` for L1 initiated transactions. This type of transaction is initiated on the L1 bridge contract. Every time a new message is appended to the `L1MessageQueue` contract on L1, the L2 sequeuncer will create a corresponding `L1MessageTx` transaction to be included in the L2 blocks. Because the signature was already implicitly verified when users submitted the transaction on L1, `L1MessageTx` transactions don't have signature.
+We introduce a new type of transactions `L1MessageTx` for L1 initiated transactions. This type of transaction is initiated on the L1 bridge contract. Every time a new message is appended to the `L1MessageQueue` contract on L1, the L2 sequencer will create a corresponding `L1MessageTx` transaction to be included in the L2 blocks. Because the signature was already implicitly verified when users submitted the transaction on L1, `L1MessageTx` transactions don't have signature.
 
 The `L1MessageTx` transaction type is `0x7E` and its payload is defined as follows.
 

src/content/docs/en/technology/index.mdx

@@ -16,7 +16,7 @@ import Architecture from "./_images/arch.png"
 As illustrated in the figure above, Scroll chain consists of three layers:
 
 - **Settlement Layer**: provides data availability and ordering for the canonical Scroll chain, verifies  validity proofs, and allows users and dapps to send messages and assets between Ethereum and Scroll. We use Ethereum as the Settlement Layer and deploy the bridge and rollup contract onto the Ethereum.
-- **Sequencing Layer**: contains a *Execution Node* that executes the transactions submitted to the Scroll sequencer and the transactions submitted to the L1 bridge contract and produces L2 blocks, and a *Rollup Node* that batches transactions, posts transaction data and block information to Ethereum for data availability, and submits validity proofs to Ethereum for finality.
+- **Sequencing Layer**: contains an *Execution Node* that executes the transactions submitted to the Scroll sequencer and the transactions submitted to the L1 bridge contract and produces L2 blocks, and a *Rollup Node* that batches transactions, posts transaction data and block information to Ethereum for data availability, and submits validity proofs to Ethereum for finality.
 - **Proving Layer**: consists of a pool of provers that are responsible for generating the zkEVM validity proofs that verify the correctness of L2 transactions, and a coordinator that dispatches the proving tasks to provers and relays the proofs to the Rollup Node to finalize on the Ethereum.
 
 This section of the documentation provides comprehensive information on the Scroll protocol specification, bridging protocol, sequencer, and zkEVM circuit.

src/content/docs/en/user-guide/common-errors.mdx

@@ -32,7 +32,7 @@ If no error or console logs appear, this is likely due to a nonce issue, please
 
 ## Block Explorer shows "Internal server error"
 
-Use an incognito window, or open your browser developer console and remove the `_explorer_key` cookie (or all cookies). [See this guide for how to remove cookies.](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/).
+Use an incognito window, or open your browser developer console and remove the `_explorer_key` cookie (or all cookies). [See this guide for how to remove cookies](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/).
 
 ## Sending max amount of Ether in MetaMask results in a "Failed" error