From 71848f2139a83b60e0a822c2a9ca6cc794f88bf7 Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:02:11 +0200 Subject: [PATCH 1/9] Update common-errors.mdx --- src/content/docs/en/user-guide/common-errors.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 From 8888204e2ac1824c34576f9cb2686e3ec7ac7d8a Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:05:12 +0200 Subject: [PATCH 2/9] Update verifying-smart-contracts.mdx --- src/content/docs/en/developers/verifying-smart-contracts.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/en/developers/verifying-smart-contracts.mdx b/src/content/docs/en/developers/verifying-smart-contracts.mdx index be119ed8c..a9322d6af 100644 --- a/src/content/docs/en/developers/verifying-smart-contracts.mdx +++ b/src/content/docs/en/developers/verifying-smart-contracts.mdx @@ -78,7 +78,7 @@ npx hardhat verify --network scrollSepolia 0xD9880690bd717189cC3Fbe7B9020F27fae7 ``` @@ -127,4 +127,4 @@ forge verify-contract \ \ No newline at end of file + From 4df922ac334db9bba883d92a8460c981be7a04b6 Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:07:38 +0200 Subject: [PATCH 3/9] Update l1-and-l2-bridging.mdx --- src/content/docs/en/developers/l1-and-l2-bridging.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 b30000ef4..9971f29ce 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. From bd521d7ada33366da44b458ed3df3381ad1cafaa Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:11:12 +0200 Subject: [PATCH 4/9] Update erc1155-token-bridge.mdx --- .../en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx index 082ab18fd..274334aea 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx @@ -158,5 +158,5 @@ Update the mapping that connects an ERC1155 token contract from L2 to L1. | Parameter | Description | | --------- | ------------------------------------------------- | -| \_l1Token | The address of th ERC1155 token in L1. | +| \_l1Token | The address of the ERC1155 token in L1. | | \_l2Token | The address of corresponding ERC1155 token in L2. | From 76537cf4d2ab5a43dce2bfd07c1ca469719a3e07 Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:13:00 +0200 Subject: [PATCH 5/9] Update index.mdx --- src/content/docs/en/technology/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/technology/index.mdx b/src/content/docs/en/technology/index.mdx index 927303aa8..ae9168a7b 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. From f06ca9e9b1b2f907ea1945ac4d384df023074041 Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:14:35 +0200 Subject: [PATCH 6/9] Update transactions.mdx --- src/content/docs/en/technology/chain/transactions.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/technology/chain/transactions.mdx b/src/content/docs/en/technology/chain/transactions.mdx index d22a3402a..6a10f078c 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. From 0420f2cc223b0e7f836a73e3596ad4672183f4aa Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:15:50 +0200 Subject: [PATCH 7/9] Update blocks.mdx --- src/content/docs/en/technology/chain/blocks.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/technology/chain/blocks.mdx b/src/content/docs/en/technology/chain/blocks.mdx index eb6f716d6..90ac5c4a0 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. | From 028a8f98e609031708ed488d345e57bdd1497b16 Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:17:47 +0200 Subject: [PATCH 8/9] Update withdraw-gateways.mdx --- src/content/docs/en/technology/bridge/withdraw-gateways.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx b/src/content/docs/en/technology/bridge/withdraw-gateways.mdx index 5b0053981..5bd0a1862 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. From f4621edf61bb804da99e95aa59f7cc418bea01a0 Mon Sep 17 00:00:00 2001 From: mcisb <83702309+KyryloKilin@users.noreply.github.com> Date: Sat, 24 Feb 2024 16:19:13 +0200 Subject: [PATCH 9/9] Update kzg-commitment-scheme.md --- .../docs/en/learn/zero-knowledge/kzg-commitment-scheme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 1ff01ca4b..41f5ca162 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