diff --git a/src/content/docs/en/developers/l1-and-l2-bridging.mdx b/src/content/docs/en/developers/l1-and-l2-bridging.mdx index 4607b3fa2..abf53308f 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging.mdx +++ b/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 -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 -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. \ No newline at end of file +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. diff --git a/src/content/docs/en/developers/verifying-smart-contracts.mdx b/src/content/docs/en/developers/verifying-smart-contracts.mdx index f12158cc2..bbb02f953 100644 --- a/src/content/docs/en/developers/verifying-smart-contracts.mdx +++ b/src/content/docs/en/developers/verifying-smart-contracts.mdx @@ -76,7 +76,7 @@ npx hardhat verify --network scrollSepolia 0xD9880690bd717189cC3Fbe7B9020F27fae7 ``` @@ -98,4 +98,4 @@ forge verify-contract \ ``` \ No newline at end of file + diff --git a/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md b/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md index db766a01f..6d25e00b7 100644 --- a/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md +++ b/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 diff --git a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx b/src/content/docs/en/technology/bridge/withdraw-gateways.mdx index 2c220f3f7..1c4497acc 100644 --- a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx +++ b/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. diff --git a/src/content/docs/en/technology/chain/blocks.mdx b/src/content/docs/en/technology/chain/blocks.mdx index e68ded27f..77d52a5de 100644 --- a/src/content/docs/en/technology/chain/blocks.mdx +++ b/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. | diff --git a/src/content/docs/en/technology/chain/transactions.mdx b/src/content/docs/en/technology/chain/transactions.mdx index b6d8b42d5..81d0b3d29 100644 --- a/src/content/docs/en/technology/chain/transactions.mdx +++ b/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. diff --git a/src/content/docs/en/technology/index.mdx b/src/content/docs/en/technology/index.mdx index d06d37482..af905bbc0 100644 --- a/src/content/docs/en/technology/index.mdx +++ b/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. diff --git a/src/content/docs/en/user-guide/common-errors.mdx b/src/content/docs/en/user-guide/common-errors.mdx index f1f1b52b8..39f6b65bd 100644 --- a/src/content/docs/en/user-guide/common-errors.mdx +++ b/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