From 95bb6517db83b711f807ed53a721710f5d818e02 Mon Sep 17 00:00:00 2001 From: Daniel Helm Date: Wed, 17 Apr 2024 14:17:31 -0500 Subject: [PATCH] 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.