From dbbf77ea0d049b267a00a0ce6a3866a88055f751 Mon Sep 17 00:00:00 2001 From: Daniel Helm Date: Tue, 31 Oct 2023 16:22:11 -0500 Subject: [PATCH 01/21] add TabsContent, needs styling --- src/components/Tabs/TabsContent.tsx | 103 +++++++++++++++++++++ src/components/Tabs/index.ts | 2 + src/content/docs/en/article-components.mdx | 54 +++++++++++ 3 files changed, 159 insertions(+) create mode 100644 src/components/Tabs/TabsContent.tsx diff --git a/src/components/Tabs/TabsContent.tsx b/src/components/Tabs/TabsContent.tsx new file mode 100644 index 000000000..f076839ee --- /dev/null +++ b/src/components/Tabs/TabsContent.tsx @@ -0,0 +1,103 @@ +/** @jsxImportSource preact */ +import type { ComponentChild } from "preact" +import { useRef } from "preact/hooks" +import { useTabState } from "./useTabState" +import styles from "./Tabs.module.css" +import { clsx } from "~/lib" +const tabSlotKey = "tab." as const +const panelSlotKey = "panel." as const + +type TabSlot = `${typeof tabSlotKey}${string}` +type PanelSlot = `${typeof panelSlotKey}${string}` + +function isTabSlotEntry(entry: [string, ComponentChild]): entry is [TabSlot, ComponentChild] { + const [key] = entry + return key.startsWith(tabSlotKey) +} + +function isPanelSlotEntry(entry: [string, ComponentChild]): entry is [PanelSlot, ComponentChild] { + const [key] = entry + return key.startsWith(panelSlotKey) +} + +function getBaseKeyFromTab(slot: TabSlot) { + return slot.replace(new RegExp(`^${tabSlotKey}`), "") +} + +function getBaseKeyFromPanel(slot: PanelSlot) { + return slot.replace(new RegExp(`^${panelSlotKey}`), "") +} + +type Props = { + [key: TabSlot | PanelSlot]: ComponentChild + sharedStore?: string +} + +export function TabsContent({ sharedStore, ...slots }: Props) { + const tabs = Object.entries(slots).filter(isTabSlotEntry) + const panels = Object.entries(slots).filter(isPanelSlotEntry) + + /** Used to focus next and previous tab on arrow key press */ + const tabButtonRefs = useRef>({}) + + const firstPanelKey = panels[0] ? getBaseKeyFromPanel(panels[0][0]) : "" + const [curr, setCurrStore] = useTabState(firstPanelKey, sharedStore) + + function moveFocus(event: KeyboardEvent) { + if (event.key === "ArrowLeft") { + const currIdx = tabs.findIndex(([key]) => getBaseKeyFromTab(key) === curr) + if (currIdx > 0) { + const [prevTabKey] = tabs[currIdx - 1] + setCurrStore(getBaseKeyFromTab(prevTabKey)) + tabButtonRefs.current[prevTabKey]?.focus() + } + } + if (event.key === "ArrowRight") { + const currIdx = tabs.findIndex(([key]) => getBaseKeyFromTab(key) === curr) + if (currIdx < tabs.length - 1) { + const [nextTabKey] = tabs[currIdx + 1] + setCurrStore(getBaseKeyFromTab(nextTabKey)) + tabButtonRefs.current[nextTabKey]?.focus() + } + } + } + + return ( +
+
+ {tabs.map(([key, content]) => ( + + ))} +
+ {panels.map(([key, content]) => ( + + ))} +
+ ) +} \ No newline at end of file diff --git a/src/components/Tabs/index.ts b/src/components/Tabs/index.ts index 08cf2bf26..ffe2d6fc7 100644 --- a/src/components/Tabs/index.ts +++ b/src/components/Tabs/index.ts @@ -1 +1,3 @@ export { Tabs } from "./Tabs" + +export { TabsContent } from "./TabsContent" diff --git a/src/content/docs/en/article-components.mdx b/src/content/docs/en/article-components.mdx index 96b4a2f63..aedeb15fa 100644 --- a/src/content/docs/en/article-components.mdx +++ b/src/content/docs/en/article-components.mdx @@ -13,6 +13,7 @@ import priceAggr from "../../../assets/images/contract-devs/price-aggr.png" import ToggleElement from "../../../components/ToggleElement.astro" import Aside from "../../../components/Aside.astro" import MarkmapView from "../../../components/MarkmapView/index.astro" +import { Tabs, TabsContent } from "../../../components/Tabs" This is body text right under the article title. It typically is just paragraph text that's pretty straightforward. Then there's **bold text**, and _italic text_, and **_bold-italic text_**, and `inline-code` and **`bold inline code`** and even _`italic inline code`_ and **_`bold italic inline code`_**. And of course don't forget [links](#), and [**bold links**](#), and [_italic links_](#), and [**_bold-italic links_**](#). @@ -162,3 +163,56 @@ stateDiagram ExecutionState --> ConstraintBuilder step_context --> ConstraintBuilder ``` + +### Tabs + + + npm + yarn + ```console npm install @chainlink/hardhat-chainlink ``` + ```console yarn add @chainlink/hardhat-chainlink ``` + + +### Tabs + + +Subscription +Direct funding + + +For Chainlink VRF v2 to fulfill your requests, you must maintain a sufficient amount of LINK in your subscription balance. Gas cost calculation includes the following variables: + +- **Gas price:** The current gas price, which fluctuates depending on network conditions. + +- **Callback gas:** The amount of gas used for the callback request that returns your requested random values. + +- **Verification gas:** The amount of gas used to verify randomness on-chain. + +The gas price depends on current network conditions. The callback gas depends on your callback function, and the number of random values in your request. The cost of each request is final only after the transaction is complete, but you define the limits you are willing to spend for the request with the following variables: + +- **Gas lane:** The maximum gas price you are willing to pay for a request in wei. Define this limit by specifying the appropriate `keyHash` in your request. The limits of each gas lane are important for handling gas price spikes when Chainlink VRF bumps the gas price to fulfill your request quickly. + +- **Callback gas limit:** Specifies the maximum amount of gas you are willing to spend on the callback request. Define this limit by specifying the `callbackGasLimit` value in your request. + + + + +For Chainlink VRF v2 to fulfill your requests, you must have a sufficient amount of LINK in your consuming contract. Gas cost calculation includes the following variables: + +- **Gas price:** The current gas price, which fluctuates depending on network conditions. + +- **Callback gas:** The amount of gas used for the callback request that returns your requested random values. The callback gas depends on your callback function and the number of random values in your request. Set the **callback gas limit** to specify the maximum amount of gas you are willing to spend on the callback request. + +- **Verification gas:** The amount of gas used to verify randomness on-chain. + +- **Wrapper overhead gas:** The amount of gas used by the VRF Wrapper contract. See the [Request and Receive Data](/vrf/v2/direct-funding#request-and-receive-data) section for details about the VRF v2 Wrapper contract design. + +Because the consuming contract directly pays the LINK for the request, the cost is calculated during the request and not during the callback when the randomness is fulfilled. Test your callback function to learn how to correctly estimate the callback gas limit. + +- If the gas limit is underestimated, the callback fails and the consuming contract is still charged for the work done to generate the requested random values. +- If the gas limit is overestimated, the callback function will be executed but your contract is not refunded for the excess gas amount that you paid. + +Make sure that your consuming contracts are funded with enough LINK tokens to cover the transaction costs. If the consuming contract doesn't have enough LINK tokens, your request will revert. + + + From eac51fbd6e0e41fb87b2c5e28265b63601b1572f Mon Sep 17 00:00:00 2001 From: dembelekaro <157847339+dembelekaro@users.noreply.github.com> Date: Thu, 1 Feb 2024 11:23:41 +0000 Subject: [PATCH 02/21] Corrected sentence structures overview.md --- src/content/docs/en/getting-started/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/en/getting-started/overview.md b/src/content/docs/en/getting-started/overview.md index acddb22f3..9af2eb9bc 100644 --- a/src/content/docs/en/getting-started/overview.md +++ b/src/content/docs/en/getting-started/overview.md @@ -10,7 +10,7 @@ whatsnext: { "User Guide": "/user-guide/", "Building on Scroll": "/developers/" #### Welcome to the Scroll docs! -Scroll is a security-focused scaling solution for Ethereum, using innovations in scaling design and zero knowledge proofs to build a new layer on Ethereum. The Scroll network is more accessible, more responsive, and can support more users at once than Ethereum alone, and if you've ever used or developed an application on Ethereum, you'll be right at home on Scroll. +Scroll is a security-focused scaling solution for Ethereum, using innovations in scaling design and zero knowledge proofs to build a new layer on Ethereum. The Scroll network is more accessible, more responsive and can support more users at once than Ethereum alone. If you've ever used or developed an application on Ethereum, you'll be right at home on Scroll. Want to try out the Scroll Sepolia testnet with free assets before using Scroll? Check out our [User Guide](/user-guide/). @@ -20,7 +20,7 @@ Scroll is building the technology to scale Ethereum. While Ethereum is the leading blockchain network for powering decentralized applications, its popularity also brings higher costs, creating a barrier to adoption for the next wave of users and developers. -Leveraging cutting-edge research in zero knowledge proofs (”zk”), Scroll is building a Layer 2 rollup network on Ethereum. The team, in open-source collaboration with others in the Ethereum community, has created a “zkEVM” that allows for all activity on the network, which behaves just like Ethereum, to be secured by smart contracts _on_ Ethereum. The network publishes all of the transactions to Ethereum, and the zkEVM creates and publishes cryptographic "proofs" that the Scroll network is following the rules of Ethereum. +Leveraging cutting-edge research in zero knowledge (”zk”) proofs , Scroll is building a Layer 2 rollup network on Ethereum. The team, in open-source collaboration with others in the Ethereum community, has created a “zkEVM” that allows for all activity on the network, which behaves just like Ethereum, to be secured by smart contracts _on_ Ethereum. The network publishes all of the transactions to Ethereum, and the zkEVM creates and publishes cryptographic "proofs" that the Scroll network is following the rules of Ethereum. Ultimately, Ethereum smart contracts verify that every transaction on Scroll is valid for these proofs, lending the network incredible security, decentralization, and censorship resistance. This level of security and scalability for Ethereum is only possible with recent breakthroughs in zero knowledge cryptography, blockchain protocol design, and hardware acceleration. From 392d15f3a560bc99443b7529e14d127760536bf1 Mon Sep 17 00:00:00 2001 From: pafaecks <134436264+pafaecks@users.noreply.github.com> Date: Wed, 21 Feb 2024 23:17:58 +0100 Subject: [PATCH 03/21] Update execution-node.mdx --- src/content/docs/en/technology/sequencer/execution-node.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/technology/sequencer/execution-node.mdx b/src/content/docs/en/technology/sequencer/execution-node.mdx index b51fd0476..4eaca9336 100644 --- a/src/content/docs/en/technology/sequencer/execution-node.mdx +++ b/src/content/docs/en/technology/sequencer/execution-node.mdx @@ -72,7 +72,7 @@ Scroll adds a few validation rules in addition to Ethereum's block validation ru The Scroll execution node inherits most of Ethereum's behaviours. However, we needed to make some breaking changes to `l2geth` to enable more efficient proving. This section provides a non-exhaustive list of the modifications, along with their rationale. -- **State and storage tree**: Ethereum uses the MPT (Merkle-Partricia Trie) as its state and contract storage data structure. This trie's structure and the fact that it uses Keccak hash would make it prohibitively expensive for ZK circuits. `l2geth` instead uses [zkTrie](/technology/sequencer/zktrie): a binary Merkle trie with Poseidon hash for its state and contract storage. +- **State and storage tree**: Ethereum uses the MPT (Merkle-Patricia Trie) as its state and contract storage data structure. This trie's structure and the fact that it uses Keccak hash would make it prohibitively expensive for ZK circuits. `l2geth` instead uses [zkTrie](/technology/sequencer/zktrie): a binary Merkle trie with Poseidon hash for its state and contract storage. - **StateAccount**: The modification of state account is described in the [Accounts and State](/technology/chain/accounts). - **EVM**: The modifications are described in the [EVM Differences from Ethereum](/technology/chain/differences) - **Transaction fees** 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 04/21] 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 05/21] 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 06/21] 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 07/21] 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 08/21] 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 09/21] 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 10/21] 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 11/21] 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 12/21] 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 From 930802fa3f4b1a4cf4c894cb6c0497d0dfeb04cd Mon Sep 17 00:00:00 2001 From: markscroller <161376758+markscroller@users.noreply.github.com> Date: Mon, 26 Feb 2024 22:59:04 +0300 Subject: [PATCH 13/21] typo fix "th" --- .../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 23345a609acb3a39b77c5642b29d6720538070cc Mon Sep 17 00:00:00 2001 From: markscroller <161376758+markscroller@users.noreply.github.com> Date: Mon, 26 Feb 2024 23:00:16 +0300 Subject: [PATCH 14/21] typo fix "messagner" --- .../l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx index b46d30062..ca8d12ea3 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx @@ -33,7 +33,7 @@ All Gateway contracts will form the message and send it to the `L1ScrollMessenge address of the `L1ScrollMessenger`. -When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessagner` contract for execution on L2. +When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessenger` contract for execution on L2. ## Withdraw ETH and ERC20 tokens from L2 From f15e0fcbe49ec346da904ae5022f26eae79211da Mon Sep 17 00:00:00 2001 From: Cuong Duong Date: Tue, 5 Mar 2024 14:13:19 +0700 Subject: [PATCH 15/21] Update erc1155-token-bridge.mdx Update the description of param _tokenIds --- .../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..73e4f11f9 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 @@ -52,7 +52,7 @@ interface IScrollERC1155 { /// @notice Batch mint some token to recipient's account. /// @dev Gateway Utilities, only gateway contract can call /// @param _to The address of recipient. - /// @param _tokenIds The token id to mint. + /// @param _tokenIds The list of token ids to mint. /// @param _amounts The list of corresponding amount of token to mint. /// @param _data The data passed to recipient function batchMint( From 5e67db0e8fe09c3d98e3217cb8c621d8465ac96d Mon Sep 17 00:00:00 2001 From: Cuong Duong Date: Tue, 5 Mar 2024 15:03:28 +0700 Subject: [PATCH 16/21] Update eth-and-erc20-token-bridge.mdx Update exactly the description of burn token (not mint) --- .../l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx index b46d30062..e9b0ab44b 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx @@ -76,7 +76,7 @@ interface IScrollStandardERC20 { /// @param _amount The amount of token to mint. function mint(address _to, uint256 _amount) external; - /// @notice Mint some token from account. + /// @notice Burn some token from account. /// @dev Gateway Utilities, only gateway contract can call /// @param _from The address of account to burn token. /// @param _amount The amount of token to mint. From 13e81b185aa264a5e2b3b5f28f94281a3e597cfc Mon Sep 17 00:00:00 2001 From: Maxime Servais <43566493+Maxservais@users.noreply.github.com> Date: Thu, 7 Mar 2024 18:28:59 +0100 Subject: [PATCH 17/21] Update faucet.mdx Adding Ethereum Sepolia faucet that's well funded and resistant to bots --- src/content/docs/en/user-guide/faucet.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/src/content/docs/en/user-guide/faucet.mdx b/src/content/docs/en/user-guide/faucet.mdx index c889c7581..abb02d090 100644 --- a/src/content/docs/en/user-guide/faucet.mdx +++ b/src/content/docs/en/user-guide/faucet.mdx @@ -21,6 +21,7 @@ Here are a few Sepolia faucet apps: - [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip) - [https://faucet.chainstack.com](https://faucet.chainstack.com) - [https://infura.io/faucet/sepolia](https://infura.io/faucet/sepolia) +- [https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) Once you receive ETH on Sepolia, you should see it in your wallet on the _Sepolia Network_. It may take a few seconds for them to appear, but you can check the status by looking for a transaction to your address on a [Sepolia Block Explorer](https://sepolia.etherscan.io/). From e27e4b24e1b31f5f62ac36efd28d9da9bf72e38a Mon Sep 17 00:00:00 2001 From: Shawn | Automata <131737202+Shawn-ata@users.noreply.github.com> Date: Mon, 11 Mar 2024 11:22:23 +0800 Subject: [PATCH 18/21] Update faucet_add_sepolia_eth_scroll_support_by_automata Added faucet support for Sepolia and Scroll Sepolia, backed by Automata Network Proof of Machinehood --- src/content/docs/en/user-guide/faucet.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/content/docs/en/user-guide/faucet.mdx b/src/content/docs/en/user-guide/faucet.mdx index c889c7581..e616641e4 100644 --- a/src/content/docs/en/user-guide/faucet.mdx +++ b/src/content/docs/en/user-guide/faucet.mdx @@ -21,6 +21,7 @@ Here are a few Sepolia faucet apps: - [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip) - [https://faucet.chainstack.com](https://faucet.chainstack.com) - [https://infura.io/faucet/sepolia](https://infura.io/faucet/sepolia) +- [https://www.sepoliafaucet.io/](https://www.sepoliafaucet.io/) Once you receive ETH on Sepolia, you should see it in your wallet on the _Sepolia Network_. It may take a few seconds for them to appear, but you can check the status by looking for a transaction to your address on a [Sepolia Block Explorer](https://sepolia.etherscan.io/). @@ -37,3 +38,4 @@ If you don't want to interact with the bridge, some faucets directly distribute - [https://faucet.quicknode.com/scroll/sepolia](https://faucet.quicknode.com/scroll/sepolia) - [https://bwarelabs.com/faucets/scroll-testnet](https://bwarelabs.com/faucets/scroll-testnet) - [https://scroll.faucetme.pro](https://scroll.faucetme.pro) +- [https://www.l2faucet.com/scroll](https://www.l2faucet.com/scroll) From 3f507b5dc60cf3a32d922c08448c33656bd79aa8 Mon Sep 17 00:00:00 2001 From: "Floyd.Lin" Date: Wed, 17 Apr 2024 19:15:29 +0800 Subject: [PATCH 19/21] Update withdraw-gateways.mdx (#231) fix the typo of mistyped L2 and L1 --- 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 2a664034f..2c220f3f7 100644 --- a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx +++ b/src/content/docs/en/technology/bridge/withdraw-gateways.mdx @@ -59,7 +59,7 @@ The withdrawal of ETH token works as follows. The withdraw of ERC20 tokens works as follows. -1. To withdraw ERC20 tokens from L1 to L2, users can use `L2GatewayRouter.withdrawERC20` and `L2GatewayRouter.withdrawERC20AndCall` showed below. +1. To withdraw ERC20 tokens from L2 to L1, users can use `L2GatewayRouter.withdrawERC20` and `L2GatewayRouter.withdrawERC20AndCall` showed below. ```solidity function withdrawERC20(address _token, uint256 _amount, uint256 _gasLimit) external payable; From 95bb6517db83b711f807ed53a721710f5d818e02 Mon Sep 17 00:00:00 2001 From: Daniel Helm Date: Wed, 17 Apr 2024 14:17:31 -0500 Subject: [PATCH 20/21] various typos, minor issues --- src/content/docs/en/developers/index.mdx | 2 +- src/content/docs/en/learn/intro-to-rollups.md | 6 ++--- .../docs/en/learn/the-scalability-problem.md | 2 +- .../additional-zk-learning-resources.md | 2 +- .../introduction-to-zero-knowledge.mdx | 6 ++--- .../bridge/cross-domain-messaging.mdx | 4 ++-- .../en/technology/bridge/deposit-gateways.mdx | 6 ++--- .../technology/bridge/withdraw-gateways.mdx | 10 ++++----- .../docs/en/technology/chain/accounts.mdx | 4 ++-- .../docs/en/technology/chain/blocks.mdx | 2 +- .../docs/en/technology/chain/rollup.mdx | 8 +++---- .../docs/en/technology/chain/transactions.mdx | 12 +++++----- src/content/docs/en/technology/index.mdx | 6 ++--- .../technology/overview/scroll-upgrades.mdx | 2 +- .../technology/sequencer/execution-node.mdx | 10 ++++----- .../en/technology/sequencer/rollup-node.mdx | 2 +- .../docs/en/technology/sequencer/zktrie.mdx | 22 +++++++++---------- .../en/technology/zkevm/intro-to-zkevm.md | 2 +- .../en/technology/zkevm/zkevm-overview.mdx | 2 +- .../technology/sequencer/execution-node.mdx | 2 +- .../technology/sequencer/execution-node.mdx | 2 +- 21 files changed, 57 insertions(+), 57 deletions(-) diff --git a/src/content/docs/en/developers/index.mdx b/src/content/docs/en/developers/index.mdx index d0a6e32d0..8a1135227 100644 --- a/src/content/docs/en/developers/index.mdx +++ b/src/content/docs/en/developers/index.mdx @@ -80,7 +80,7 @@ ensuring that all code executed on the Scroll Layer 2 behaves just as if it were

We know the challenges of building in the open and getting user engagement! Scroll has a blossoming community of users and builders, and with a Discord community of over 500,000 members eager to try out applications on our - testnet or mainnet, we’re excited to connect builders with users that can provide real-world feedback. + testnet or mainnet, we’re excited to connect builders with users who can provide real-world feedback.

diff --git a/src/content/docs/en/learn/intro-to-rollups.md b/src/content/docs/en/learn/intro-to-rollups.md index f70ebdc1d..990445c84 100644 --- a/src/content/docs/en/learn/intro-to-rollups.md +++ b/src/content/docs/en/learn/intro-to-rollups.md @@ -10,7 +10,7 @@ whatsnext: { "Scroll Rollup Process": "/en/technology/chain/rollup" } ## What’s a rollup? -Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem, and are viewed as a [central part](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) of the Ethereum roadmap. +Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem and are viewed as a [central part](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) of the Ethereum roadmap. A rollup processes batches of transactions off-chain (i.e. not on layer 1), and then posts the resulting data on-chain (i.e. on layer 1). @@ -22,13 +22,13 @@ In order for a rollup to be secure, it must prove that its off-chain computation An optimistic rollup is a rollup that uses fraud proofs to assert the validity of its computation. -Fraud proofs are a mechanism that allow users to challenge and prove the invalidity of any computation performed on the L2. If a fraud proof is successfully submitted, the L2 can be rolled back to a previous state and the invalid computation can be corrected. Fraud proofs depend on at least one honest party checking that the L2 transactions have been correctly executed. +Fraud proofs are a mechanism that allows users to challenge and prove the invalidity of any computation performed on the L2. If a fraud proof is successfully submitted, the L2 can be rolled back to a previous state and the invalid computation can be corrected. Fraud proofs depend on at least one honest party checking that the L2 transactions have been correctly executed. ## What’s a ZK rollup? A ZK rollup is a rollup that uses validity proofs to assert the validity of its computation. -When a ZK rollup executes a batch of transactions and posts the resulting state to L1, it also posts a validity proof. This mathematical proof proves that the resulting state is indeed the state which results from correctly executing the batch of transactions. +When a ZK rollup executes a batch of transactions and posts the resulting state to L1, it also posts a validity proof. This mathematical proof proves that the resulting state is indeed the state that results from correctly executing the batch of transactions. Today, there are multiple types of ZK rollups, broadly defined as either zkVMs (zk Virtual Machines) or zkEVMs (zk Ethereum Virtual Machines). diff --git a/src/content/docs/en/learn/the-scalability-problem.md b/src/content/docs/en/learn/the-scalability-problem.md index 06b5e7b36..c5055fd6c 100644 --- a/src/content/docs/en/learn/the-scalability-problem.md +++ b/src/content/docs/en/learn/the-scalability-problem.md @@ -24,4 +24,4 @@ There are primarily two types of scaling solutions: layer 1 scaling solutions an **Layer 1** (or **L1**) scaling solutions attempt to scale the network by making modifications to the Ethereum blockchain directly. The term “layer 1” here refers to the main Ethereum blockchain. In general, it is very difficult to design layer 1 scaling solutions that increase throughput and at the same time preserve high levels of security and decentralization. Thus, recent scaling efforts have shifted away from layer 1 solutions and towards layer 2 solutions. -**Layer 2** (or **L2**) scaling solutions are networks that live **on top** of Ethereum layer 1 - they are essentially separate blockchains which are “anchored” to the underlying Ethereum blockchain in some way. These layer 2 networks can generally process transactions at a higher rate than the underlying layer 1 network, as they are not subject to the same limitations. The “anchoring” mechanism, the specifics of which differ across various layer 2s, enables the layer 2 network to inherit the strong security and decentralization properties of Ethereum layer 1. +**Layer 2** (or **L2**) scaling solutions are networks that live **on top** of Ethereum layer 1 - they are essentially separate blockchains that are “anchored” to the underlying Ethereum blockchain in some way. These layer 2 networks can generally process transactions at a higher rate than the underlying layer 1 network, as they are not subject to the same limitations. The “anchoring” mechanism, the specifics of which differ across various layer 2s, enables the layer 2 network to inherit the strong security and decentralization properties of Ethereum layer 1. diff --git a/src/content/docs/en/learn/zero-knowledge/additional-zk-learning-resources.md b/src/content/docs/en/learn/zero-knowledge/additional-zk-learning-resources.md index 4dd9e9679..01ae590ba 100644 --- a/src/content/docs/en/learn/zero-knowledge/additional-zk-learning-resources.md +++ b/src/content/docs/en/learn/zero-knowledge/additional-zk-learning-resources.md @@ -16,7 +16,7 @@ Looking to dive deeper into ZK? Here are some of our favorite resources. - [Zero Knowledge Proofs MOOC](https://youtube.com/playlist?list=PLS01nW3Rtgor_yJmQsGBZAg5XM4TSGpPs) - A MOOC that covers zero knowledge proofs from first principles, all the way to modern industry topics. - [The 9th BIU Winter School on Cryptography - Zero Knowledge](https://youtube.com/playlist?list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K) - - These lectures lay the theoretical foundations for zero knowledge - they are targeted towards academics and audiences with mathematical maturity. + - These lectures lay the theoretical foundations for zero knowledge - they are targeted toward academics and audiences with mathematical maturity. - [ZK Symposium](https://www.youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY) - A mix of applied and theoretical presentations from some of the top researchers and product builders in the zero knowledge space. diff --git a/src/content/docs/en/learn/zero-knowledge/introduction-to-zero-knowledge.mdx b/src/content/docs/en/learn/zero-knowledge/introduction-to-zero-knowledge.mdx index aee22511b..77c6817bf 100644 --- a/src/content/docs/en/learn/zero-knowledge/introduction-to-zero-knowledge.mdx +++ b/src/content/docs/en/learn/zero-knowledge/introduction-to-zero-knowledge.mdx @@ -38,9 +38,9 @@ The above properties of ZKPs are extremely useful in the context of verifiabilit In practice, ZKPs can be quite complex to implement into a system, but at a high level, you’ll want to understand that zero knowledge proofs have a few components: a circuit, a proof, and a verifier. -The circuit is a program that takes in input data, and asserts that the input data is valid according to some “constraints” that the input data must satisfy. The input data can be public (known to everyone), private (know to only the prover), or mixed (some inputs are public and some are private). +The circuit is a program that takes in input data and asserts that the input data is valid according to some “constraints” that the input data must satisfy. The input data can be public (known to everyone), private (known to only the prover), or mixed (some inputs are public and some are private). -A proof can be generated, claiming that an input satisfies the circuit. The proof reveals no information about the private inputs, and is quite small in size. +A proof can be generated, claiming that an input satisfies the circuit. The proof reveals no information about the private inputs and is quite small in size. The verifier can check (1) that the proof is valid, (2) that the proof matches the constraints laid out by the circuit (and isn’t just a phony proof), and (3) that the public inputs used to generate the proof match those being used by the verifier. Note that this check performed by the verifier is generally a cheap computation. @@ -62,7 +62,7 @@ The proof, along with the puzzle, could be passed to Bob, who could then use a * ## Zero Knowledge Proofs and Blockchains -One of the primary motivations for recent advances in ZKPs is its application to blockchains. Two of the key challenges that decentralized blockchains face are privacy and scalability - all the data is public, and every node in the network has to re-run every computation on the network. ZKPs can help solve both these challenges. +One of the primary motivations for recent advances in ZKPs is its application to blockchains. Two of the key challenges that decentralized blockchains face are privacy and scalability - all the data is public, and every node in the network has to re-run every computation on the network. ZKPs can help solve both of these challenges. While there are several projects utilizing the zero knowledge property of ZKPs to build privacy-preserving applications, we at Scroll use only the succinctness property of ZKPs to scale Ethereum. diff --git a/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx b/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx index feae12c0f..359484f8a 100644 --- a/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx +++ b/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx @@ -60,7 +60,7 @@ Both functions construct an L1-initiated transaction with a new transaction type - `appendCrossDomainMessage` can be only called by `L1ScrollMessenger` and it uses the [aliased address](#address-alias) of `msg.sender`, which will be the address of `L1ScrollMessenger`, as the transaction sender. - `appendEnforcedTransaction` can be only called by `EnforcedTxGateway` and it uses `sender` from the function parameter as the transaction sender. This allows users to enforce a withdrawal or transfer of ETH from their L2 accounts directly through the L1 bridge. -After the transaction is successfully executed on L1, the watcher in the Scroll sequencer that monitors the `L1MessageQueue` contract collects the new `QueueTransaction` events from L1 blocks. The sequencer then constructs a new `L1MessageTx` transaction per event and appends them to its local L1 transaction queue. When constructing a new L2 block, the sequencer includes the transactions from both its L1 transaction queue and its L2 mempool. Note that the L1 message transactions must be included sequentially based on the L1 message queue order in the `L1MessageQueue` contract. `L1MessageTx` transactions always come first in the L2 blocks followed by L2 transactions. Currently, we limit the number of `L1MessageTx` transactions in a L2 block to `NumL1MessagesPerBlock` (currently set to 10). +After the transaction is successfully executed on L1, the watcher in the Scroll sequencer that monitors the `L1MessageQueue` contract collects the new `QueueTransaction` events from L1 blocks. The sequencer then constructs a new `L1MessageTx` transaction per event and appends them to its local L1 transaction queue. When constructing a new L2 block, the sequencer includes the transactions from both its L1 transaction queue and its L2 mempool. Note that the L1 message transactions must be included sequentially based on the L1 message queue order in the `L1MessageQueue` contract. `L1MessageTx` transactions always come first in the L2 blocks followed by L2 transactions. Currently, we limit the number of `L1MessageTx` transactions in an L2 block to `NumL1MessagesPerBlock` (currently set to 10). Next, we will expand more on the specific process of sending arbitrary messages via `L1ScrollMessenger` and sending enforced transactions via `EnforcedTxGateway`. @@ -162,7 +162,7 @@ Similar to arbitrary message relaying, `sendTransaction` deducts the message rel ### Retrying Failed Messages -If a `L1MessageTx` transaction fails on L2 due to insufficient gas, users can replay the message with a higher gas limit. `L1ScrollMessenger` provides the method `replayMessage` that allows users to send the same information as the previous failed message with a higher gas limit. This message will become a new `L1MessageTx` transaction on L2. Note that we won't refund the gas fee for the previous failed transaction as it is already processed on L2. +If an `L1MessageTx` transaction fails on L2 due to insufficient gas, users can replay the message with a higher gas limit. `L1ScrollMessenger` provides the method `replayMessage` that allows users to send the same information as the previous failed message with a higher gas limit. This message will become a new `L1MessageTx` transaction on L2. Note that we won't refund the gas fee for the previous failed transaction as it is already processed on L2.
replayMessage function signature
diff --git a/src/content/docs/en/technology/bridge/deposit-gateways.mdx b/src/content/docs/en/technology/bridge/deposit-gateways.mdx index 7cec7b18f..72adf4c3f 100644 --- a/src/content/docs/en/technology/bridge/deposit-gateways.mdx +++ b/src/content/docs/en/technology/bridge/deposit-gateways.mdx @@ -80,7 +80,7 @@ The deposit of ERC20 tokens works as follows. ) public payable; ``` -2. Based on the mapping from ERC20 tokens to gateway, the `L1GatewayRouter` calls to the corresponding gateway: `L1StandardERC20Gateway`, `L1CustomERC20Gateway`, or `L1WETHGateway`. The remaining of steps will be described separately. +2. Based on the mapping from ERC20 tokens to gateway, the `L1GatewayRouter` calls to the corresponding gateway: `L1StandardERC20Gateway`, `L1CustomERC20Gateway`, or `L1WETHGateway`. The remaining steps will be described separately. ### Standard ERC20 Tokens @@ -96,10 +96,10 @@ Standard ERC20 tokens are tokens that do not require any custom logic. For such ### Custom ERC20 Tokens -In comparison to standard ERC20 tokens, the L2 contract of custom ERC20 tokens are deployed by the token owner. The remaining steps for custom ERC20 token deposit are: +In comparison to standard ERC20 tokens, the L2 contract of custom ERC20 tokens is deployed by the token owner. The remaining steps for custom ERC20 token deposit are: 3. The `L1CustomERC20Gateway` contract locks the ERC20 tokens on L1 by transferring them from the sender to itself. -4. `L1CustomERC20Gateway` requires a L2 ERC20 token address present in the `tokenMapping`. It retrieves the corresponding ERC20 token address, encodes the token deposit message, and forwards it to `L1ScrollMessenger`. +4. `L1CustomERC20Gateway` requires an L2 ERC20 token address present in the `tokenMapping`. It retrieves the corresponding ERC20 token address, encodes the token deposit message, and forwards it to `L1ScrollMessenger`. 5. The corresponding L2 transaction calls the `L2ScrollMessenger.relayMessage` function to finalize the deposit on L2. In the case of custom ERC20 token deposits, the transaction calls `L2CustomERC20Gateway.finalizeDepositERC20`. 6. `L2CustomERC20Gateway` calls the mint function on the corresponding L2 ERC20 token contract. It is required that the L2 ERC20 token contract grants mint permissions to the `L2CustomERC20Gateway` contract. 7. If the user calls `depositERC20AndCall` on L1, the `L2CustomERC20Gateway` will call the target L2 contract with additional data. diff --git a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx b/src/content/docs/en/technology/bridge/withdraw-gateways.mdx index 2a664034f..01552f631 100644 --- a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx +++ b/src/content/docs/en/technology/bridge/withdraw-gateways.mdx @@ -27,7 +27,7 @@ This document describes how users and developers can utilize gateways to withdra -The figure depicts the withdrawal workflow from L2 to L1. Users call the gateways to initialize the token withdrawal. The withdrawal is encoded into a message sent to the `L2ScrollMessenger`, which is then appended to the `L2MessageQueue`. `L2MessageQueue` maintains a Withdraw Trie and updates the root every time a new message appended. The Withdraw Trie root is finalized on the L1 rollup contract along with the L2 state root. After the new Withdraw Trie root is finalized on the L1, users or third parties can then construct a valid Merkle Inclusion Proof to the Withdraw Trie root and send a _withdraw execution_ transaction to finalize the withdrawal on L1. You can find more details about the L2-to-L1 message relay workflow in the [Cross-Domain Messaging](/technology/bridge/cross-domain-messaging#sending-messages-from-l2-to-l1). +The figure depicts the withdrawal workflow from L2 to L1. Users call the gateways to initialize the token withdrawal. The withdrawal is encoded into a message sent to the `L2ScrollMessenger`, which is then appended to the `L2MessageQueue`. `L2MessageQueue` maintains a Withdraw Trie and updates the root every time a new message is appended. The Withdraw Trie root is finalized on the L1 rollup contract along with the L2 state root. After the new Withdraw Trie root is finalized on the L1, users or third parties can then construct a valid Merkle Inclusion Proof to the Withdraw Trie root and send a _withdraw execution_ transaction to finalize the withdrawal on L1. You can find more details about the L2-to-L1 message relay workflow in the [Cross-Domain Messaging](/technology/bridge/cross-domain-messaging#sending-messages-from-l2-to-l1). The subsequent sections describe the details of how different tokens are withdrawn. @@ -57,7 +57,7 @@ The withdrawal of ETH token works as follows. ## Withdrawing ERC20 Tokens -The withdraw of ERC20 tokens works as follows. +The withdrawal of ERC20 tokens works as follows. 1. To withdraw ERC20 tokens from L1 to L2, users can use `L2GatewayRouter.withdrawERC20` and `L2GatewayRouter.withdrawERC20AndCall` showed below. @@ -75,15 +75,15 @@ The withdraw of ERC20 tokens works as follows. ) public payable; ``` -2. Based on the mapping from ERC20 tokens to gateway, the `L2GatewayRouter` calls to the corresponding gateway, `L2StandardERC20Gateway`, `L2CustomERC20Gateway`, or `L2WETHGateway`. The remaining of steps will be described separately. +2. Based on the mapping from ERC20 tokens to gateway, the `L2GatewayRouter` calls to the corresponding gateway, `L2StandardERC20Gateway`, `L2CustomERC20Gateway`, or `L2WETHGateway`. The remaining steps will be described separately. ### Standard and Custom ERC20 Tokens 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. - - 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`. +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 an 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/accounts.mdx b/src/content/docs/en/technology/chain/accounts.mdx index 9c4fa515b..812ad8470 100644 --- a/src/content/docs/en/technology/chain/accounts.mdx +++ b/src/content/docs/en/technology/chain/accounts.mdx @@ -9,7 +9,7 @@ whatsnext: { "Transactions": "/en/technology/chain/transactions/" } ## Accounts -Same as Ethereum, Scroll has two account types: Externally-owned account (EOA) and contract account that holds the smart contract and additional storages. +Same as Ethereum, Scroll has two account types: Externally-owned account (EOA) and contract account that holds the smart contract and additional storage. Scroll stores additional information of the contract bytecode in the account to facilitate the zkEVM circuit to prove the state transition more efficiently. @@ -26,4 +26,4 @@ The account in Scroll contains the following fields: The state of a blockchain is a collection of account data. The _state trie_ encodes account data and their corresponding addresses to a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) data structure. The root of tree, or the state of the blockchain, is a cryptographic digest of all the account data contained in the tree. -Ethereum uses a data structure called [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for both the state trie and the storage trie that stores the key-value entries stored in a smart contract. In Scroll, we replace the Patricia Merkle Trie by a more zk-friendly data structure, called zkTrie, for both state trie and storage trie. At a high level, the zkTrie data structure is a sparse binary Merkle tree with the [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), a zk-friendly hash function. The [zkTrie](/technology/sequencer/zktrie) document describes more details about this data structure. +Ethereum uses a data structure called [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for both the state trie and the storage trie that stores the key-value entries stored in a smart contract. In Scroll, we replace the Patricia Merkle Trie with a more zk-friendly data structure, called zkTrie, for both state trie and storage trie. At a high level, the zkTrie data structure is a sparse binary Merkle tree with the [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), a zk-friendly hash function. The [zkTrie](/technology/sequencer/zktrie) document describes more details about this data structure. diff --git a/src/content/docs/en/technology/chain/blocks.mdx b/src/content/docs/en/technology/chain/blocks.mdx index e68ded27f..40779fc16 100644 --- a/src/content/docs/en/technology/chain/blocks.mdx +++ b/src/content/docs/en/technology/chain/blocks.mdx @@ -36,4 +36,4 @@ The block header in Scroll mirrors the structure of Ethereum's. However, certain Block time refers to the interval between two consecutive blocks. In Scroll, the block time is set at 3s. A reduced block time elevates the user experience and augments the Scroll chain's scalability. -The 3 second block time is maintained on a best effort basis, it is not guaranteed or enforced by the protocol. +The 3-second block time is maintained on a best-effort basis, it is not guaranteed or enforced by the protocol. diff --git a/src/content/docs/en/technology/chain/rollup.mdx b/src/content/docs/en/technology/chain/rollup.mdx index 614076693..97792a15d 100644 --- a/src/content/docs/en/technology/chain/rollup.mdx +++ b/src/content/docs/en/technology/chain/rollup.mdx @@ -26,8 +26,8 @@ The figure illustrates the rollup workflow. The L2 sequencer contains three modu The rollup node contains three modules: -- **Relayer** submits the commit transactions and finalize transactions to the rollup contract for data availability and finality. -- **Chunk Proposer** and **Batch Proposer** proposes new chunks and new batches following the constraints described in the [Transaction Batching](/technology/chain/transactions#transaction-batching). +- **Relayer** submits the commit transactions and finalizes transactions to the rollup contract for data availability and finality. +- **Chunk Proposer** and **Batch Proposer** propose new chunks and new batches following the constraints described in the [Transaction Batching](/technology/chain/transactions#transaction-batching). The rollup process can be broken down into three phases: transaction execution, batching and data commitment, and proof generation and finalization. @@ -53,7 +53,7 @@ The rollup process can be broken down into three phases: transaction execution, ## Commit Transaction -The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 message. The parent batch header designates the previous batch that this batch links to. The parent batch must be committed before; otherwise the transaction will be reverted. See the `commitBatch` function signature below. +The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 messages. The parent batch header designates the previous batch that this batch links to. The parent batch must be committed before; otherwise, the transaction will be reverted. See the `commitBatch` function signature below. ```solidity function commitBatch( @@ -70,7 +70,7 @@ After the `commitBatch` function verifies the parent batch is committed before, mapping(uint256 => bytes32) public committedBatches; ``` -The encoding of batch header and chunk data are described in the [Codec](#codec) section. Most fields in the batch header are straight-forward to derive from the chunk data. One important field to note is `dataHash` that will become part of the public input to verify the validity proof. Assuming that a batch contains `n` chunks, its `dataHash` is computed as follows +The encoding of batch header and chunk data are described in the [Codec](#codec) section. Most fields in the batch header are straightforward to derive from the chunk data. One important field to note is `dataHash` which will become part of the public input to verify the validity proof. Assuming that a batch contains `n` chunks, its `dataHash` is computed as follows ``` batch.dataHash := keccak(chunk[0].dataHash || ... || chunk[n-1].dataHash) diff --git a/src/content/docs/en/technology/chain/transactions.mdx b/src/content/docs/en/technology/chain/transactions.mdx index b6d8b42d5..9fa5f17db 100644 --- a/src/content/docs/en/technology/chain/transactions.mdx +++ b/src/content/docs/en/technology/chain/transactions.mdx @@ -20,11 +20,11 @@ Currently, Scroll supports three types of transactions. - Legacy Transaction (refer to [EIP-155](https://eips.ethereum.org/EIPS/eip-155)) - `L1MessageTx` Typed Transaction (Type: `0x7E`): This is a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction introduced in Scroll as described below. This transaction type is for transactions initiated on L1. -Note that [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) and [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) transaction type are not supported in Scroll currently. Scroll will bring back these two transaction types in the future. +Note that [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) and [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) transaction types are not supported in Scroll currently. Scroll will bring back these two transaction types in the future. ### 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 transaction `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. @@ -43,15 +43,15 @@ The RLP encoding of `L1MessageTx` transactions follows the [EIP-2718](https://ei Two noticeable behaviors of the `L1MessageTx` transactions: -- The `QueueIndex` in the transaction is the queue index in the L1 message queue, different from the `Nonce` of the `Sender` account. But the sender's `Nonce` will still increases by 1 after the transaction. +- The `QueueIndex` in the transaction is the queue index in the L1 message queue, different from the `Nonce` of the `Sender` account. But the sender's `Nonce` will still increase by 1 after the transaction. - This type of transactions doesn't pay [L2 fee](/developers/transaction-fees-on-scroll#l2-fee) or [L1 fee](/developers/transaction-fees-on-scroll#l1-fee). The L2 fee is already paid when users submit transactions on L1. The L1 Fee isn't charged because the data of `L1MessageTx` transactions is already available in the L1 bridge contract. ## Transaction Life Cycle The transaction life cycle in the Scroll contains the following three phases: -1. **Confirmed**: Users submits a transaction to either the L1 bridge contract or L2 sequencer. The transaction becomes `Confirmed` after it gets executed and included in a L2 block. -2. **Committed**: The transactions are included in a batch and a _commit transaction_ that contains the data of this batch is submitted to L1. After the commit transaction is finalized in the L1 blocks, the transactions in this batch becomes `Committed`. +1. **Confirmed**: Users submits a transaction to either the L1 bridge contract or L2 sequencer. The transaction becomes `Confirmed` after it gets executed and included in an L2 block. +2. **Committed**: The transactions are included in a batch and a _commit transaction_ that contains the data of this batch is submitted to L1. After the commit transaction is finalized in the L1 blocks, the transactions in this batch become `Committed`. 3. **Finalized**: The validity proof of this batch is generated and verified on the L1. After the _finalize transaction_ is finalized on L1, the status of the transaction is `Finalized` and becomes a canonical part of the Scroll L2 chain. ### Submit Transactions @@ -74,7 +74,7 @@ The rollup node collects new L2 blocks and packs them into chunks and batches (s ### Finalize Transactions -After the validity proof is generated, the rollup node sends a _Finalize Transaction_ including the validity proof and the new state root after this batch for onchain verification. Once the Finalize Transaction succeeds and confirmed in a L1 block, the status of the L2 transactions in this batch becomes `Finalized`. The new state root can be used by third parties trustlessly. +After the validity proof is generated, the rollup node sends a _Finalize Transaction_ including the validity proof and the new state root after this batch for onchain verification. Once the Finalize Transaction succeeds and is confirmed in an L1 block, the status of the L2 transactions in this batch becomes `Finalized`. The new state root can be used by third parties trustlessly. ## Transaction Batching diff --git a/src/content/docs/en/technology/index.mdx b/src/content/docs/en/technology/index.mdx index d06d37482..3476b2ce3 100644 --- a/src/content/docs/en/technology/index.mdx +++ b/src/content/docs/en/technology/index.mdx @@ -15,9 +15,9 @@ 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. -- **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. +- **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 Ethereum. +- **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 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/technology/overview/scroll-upgrades.mdx b/src/content/docs/en/technology/overview/scroll-upgrades.mdx index 857701567..b07df0068 100644 --- a/src/content/docs/en/technology/overview/scroll-upgrades.mdx +++ b/src/content/docs/en/technology/overview/scroll-upgrades.mdx @@ -110,7 +110,7 @@ To reduce bridging costs, we implemented several gas optimizations on our bridge - In `ScrollChain`, change `messageQueue` and `verifier` to `immutable`. - In `L1ScrollMessenger`, change `counterpart`, `rollup`, and `messageQueue` to `immutable`. - In all token gateways, change `counterpart`, `router`, and `messenger` to `immutable`. -- Merge `L1MessageQueue` and `L2GasPriceOracle` into a single contract `L1MessageQueueWithGasPriceOracle` (deployed on the same address as the previous `L1MessageQueue`). In this contract we also change `messenger` and `scrollChain` to `immutable`, and simplify `calculateIntrinsicGasFee`. +- Merge `L1MessageQueue` and `L2GasPriceOracle` into a single contract `L1MessageQueueWithGasPriceOracle` (deployed on the same address as the previous `L1MessageQueue`). In this contract, we also change `messenger` and `scrollChain` to `immutable`, and simplify `calculateIntrinsicGasFee`. **Changes to L2 contracts:** diff --git a/src/content/docs/en/technology/sequencer/execution-node.mdx b/src/content/docs/en/technology/sequencer/execution-node.mdx index fe84ffcdc..b467cc440 100644 --- a/src/content/docs/en/technology/sequencer/execution-node.mdx +++ b/src/content/docs/en/technology/sequencer/execution-node.mdx @@ -9,7 +9,7 @@ whatsnext: { "Rollup Node": "/en/technology/sequencer/rollup-node/" } import Aside from "../../../../../components/Aside.astro" -The execution node is one of the core components in the Scroll protocol: it is responsible for maintaining the L2 blockchain. The execution node also ensures that the user and developer experience on Scroll closely resemble those on Ethereum. It achieves this by maintaining EVM and RPC behaviour that is directly inherited from Ethereum, with very few modifications. +The execution node is one of the core components in the Scroll protocol: it is responsible for maintaining the L2 blockchain. The execution node also ensures that the user and developer experience on Scroll closely resembles that on Ethereum. It achieves this by maintaining EVM and RPC behavior that is directly inherited from Ethereum, with very few modifications. The primary functions of Scroll's execution node are: - Collect transactions from L2 and L1. @@ -24,7 +24,7 @@ The secondary functions of Scroll's execution node are: The execution node, being a fork of [go-ethereum](https://github.com/ethereum/go-ethereum), inherits most of its functionality from Ethereum. This includes transaction and block data structures, EVM execution, RPC and p2p protocols. As these were not reimplemented but were directly inherited from `go-ethereum`, we can have a very high certainty of Scroll's compatibility with Ethereum. -The following sections will introduce the main components of the execution node, the additional validation rules, and summary of modification details. +The following sections will introduce the main components of the execution node, the additional validation rules, and a summary of modification details. ## `l2geth` Components @@ -45,7 +45,7 @@ During block creation, if the next transaction would lead to proof overflow, the Skipping L2 transactions means simply discarding them. In this case, the user needs to submit another transaction with the same nonce that does not lead to proof overflow in order to proceed. -Skipping L1 messages is a more explicit process. Both the `ScrollChain` contract on L1 and the zkEVM verifies that each L1 transaction in `L1MessageQueue` was either included and executed, or skipped. While the batch encoding does not contain L1 transactions, it does include a *skip bitmap* that indicates to `ScrollChain` which L1 messages were skipped. If an L1 deposit message is skipped, the user can get their tokens refunded on L1. +Skipping L1 messages is a more explicit process. Both the `ScrollChain` contract on L1 and the zkEVM verify that each L1 transaction in `L1MessageQueue` was either included and executed, or skipped. While the batch encoding does not contain L1 transactions, it does include a *skip bitmap* that indicates to `ScrollChain` which L1 messages were skipped. If an L1 deposit message is skipped, the user can get their tokens refunded on L1.