From 37996ae81fb9c2a47250e43c510b0d99b89c4996 Mon Sep 17 00:00:00 2001 From: Turupawn Date: Tue, 6 Jan 2026 20:53:09 -0600 Subject: [PATCH 1/4] upgraded docs from zkEVM to zkVM --- .../docs/en/technology/chain/accounts.mdx | 10 +- .../docs/en/technology/chain/differences.mdx | 2 +- .../docs/en/technology/chain/rollup.mdx | 1 - .../docs/en/technology/chain/transactions.mdx | 6 +- src/content/docs/en/technology/index.mdx | 4 +- .../scroll-upgrades/euclid-upgrade.mdx | 2 +- .../en/technology/prover/proof-generation.mdx | 31 +++ .../technology/sequencer/execution-node.mdx | 38 +--- .../en/technology/sequencer/rollup-node.mdx | 8 +- .../docs/en/technology/sequencer/zktrie.mdx | 204 ------------------ .../en/technology/zkevm/intro-to-zkevm.md | 27 ++- .../en/technology/zkevm/zkevm-overview.mdx | 13 +- 12 files changed, 88 insertions(+), 258 deletions(-) delete mode 100644 src/content/docs/en/technology/sequencer/zktrie.mdx diff --git a/src/content/docs/en/technology/chain/accounts.mdx b/src/content/docs/en/technology/chain/accounts.mdx index 812ad8470..d6437ed69 100644 --- a/src/content/docs/en/technology/chain/accounts.mdx +++ b/src/content/docs/en/technology/chain/accounts.mdx @@ -11,19 +11,15 @@ whatsnext: { "Transactions": "/en/technology/chain/transactions/" } 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. - -The account in Scroll contains the following fields: +The account structure in Scroll follows the standard Ethereum format: - `nonce`: A counter that indicates the number of transactions sent by the sender. - `balance`: The balance of `ETH` token in the account (unit in wei). -- `storageRoot`: The root hash of the storage trie. Since Scroll uses the [zkTrie](/technology/sequencer/zktrie) for the storage trie, the `storageRoot` stores the Poseidon hash digest in a 256-bit integer. +- `storageRoot`: The root hash of the storage trie. - `codeHash`: The Keccak hash digest of the contract bytecode. -- `PoseidonCodeHash` (**new field**): The Poseidon hash digest of the contract bytecode in a 256-bit integer. -- `CodeSize` (**new field**): The size of the contract bytecode in bytes. ## State 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 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. +Scroll uses Ethereum's [Merkle-Patricia Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) (MPT) for both the state trie and the storage trie that stores the key-value entries in smart contracts. This ensures full compatibility with Ethereum's state proof format and tooling. diff --git a/src/content/docs/en/technology/chain/differences.mdx b/src/content/docs/en/technology/chain/differences.mdx index b597aca12..cc93503d4 100644 --- a/src/content/docs/en/technology/chain/differences.mdx +++ b/src/content/docs/en/technology/chain/differences.mdx @@ -28,7 +28,7 @@ import Aside from "../../../../../components/Aside.astro" | `0x09` | `blake2f` | Currently not supported. | | `0x0a` | `point evaluation` | Currently not supported. | -The remaining precompiled contracts have the same behavior as Ethereum. However, their maximum usage within a block is constrained by a limit tied to the zkEVM circuit capacity. +The remaining precompiled contracts have the same behavior as Ethereum. ## EIPs diff --git a/src/content/docs/en/technology/chain/rollup.mdx b/src/content/docs/en/technology/chain/rollup.mdx index e65bb6e35..a6eac5d58 100644 --- a/src/content/docs/en/technology/chain/rollup.mdx +++ b/src/content/docs/en/technology/chain/rollup.mdx @@ -86,7 +86,6 @@ chunk.dataHash := keccak(blockContext[0] || ... || blockContext[k-1] || , where `block.l1TxHashes` are the concatenated transaction hashes of the L1 transactions in this block and `block.l2TxHashes` are the concatenated transaction hashes of the L2 transactions in this block. Note that the transaction hashes of L1 transactions are not uploaded by the rollup node, but instead directly loaded from the `L1MessageQueue` contract given the index range of included L1 messages in this block. The L2 transaction hashes are calculated from the RLP-encoded bytes in the `l2Transactions` field in the [`Chunk`](#Chunk-Codec). -In addition, the `commitBatchWithBlobProof` function contains a bitmap of skipped L1 messages. Unfortunately, this is due to the problem of proof overflow. If the L1 transaction corresponding to an L1 message exceeds the circuit capacity limit, we won't be able to generate a valid proof for this transaction and thus cannot finalize it on L1. Scroll is working actively to eliminate the proof overflow problem through upgrades to our proving system. ## Finalize Transaction diff --git a/src/content/docs/en/technology/chain/transactions.mdx b/src/content/docs/en/technology/chain/transactions.mdx index 9fa5f17db..e4555b64c 100644 --- a/src/content/docs/en/technology/chain/transactions.mdx +++ b/src/content/docs/en/technology/chain/transactions.mdx @@ -83,9 +83,9 @@ After the validity proof is generated, the rollup node sends a _Finalize Transac In Scroll, the transactions are batched in multiple tiers. 1. A group of ordered transactions are packed into a block. -2. A series of contiguous blocks are grouped into a chunk. The chunk is the base unit for proof generation of the zkEVM circuit. +2. A series of contiguous blocks are grouped into a chunk. The chunk is the base unit for proof generation. 3. A series of contiguous chunks are grouped into a batch. The batch is the base unit for data commitment and proof verification on the L1. The proof for a batch, or a _batch proof_, is an aggregated proof of the chunk proofs in this batch. -The goal for this multi-layer batching schema is to reduce the gas cost of onchain data commitment and proof verification. This approach increases the granularity of the rollup units on L1 while takes the fixed circuit capacity into consideration. As a result, batching reduces the data to be stored in the contract and amortizes the proof verification cost to more L2 transactions. +The goal for this multi-layer batching schema is to reduce the gas cost of onchain data commitment and proof verification. As a result, batching reduces the data to be stored in the contract and amortizes the proof verification cost to more L2 transactions. -Once a chunk is created, a corresponding chunk proving task will be generated and sent to a zkEVM prover. Upon the creation of a new batch, two subsequent actions occur: (a) the rollup node commits the transaction data and block information from this batch to the L1 contract, and (b) a batch proving task to aggregate chunk proofs is dispatched to an aggregator prover. The standards for proposing a chunk and a batch are detailed in the [Rollup Node](/technology/sequencer/rollup-node). +Once a chunk is created, a corresponding chunk proving task will be generated and sent to a prover. Upon the creation of a new batch, two subsequent actions occur: (a) the rollup node commits the transaction data and block information from this batch to the L1 contract, and (b) a batch proving task to aggregate chunk proofs is dispatched to an aggregator prover. The standards for proposing a chunk and a batch are detailed in the [Rollup Node](/technology/sequencer/rollup-node). diff --git a/src/content/docs/en/technology/index.mdx b/src/content/docs/en/technology/index.mdx index d43cbd5b2..1adaed24a 100644 --- a/src/content/docs/en/technology/index.mdx +++ b/src/content/docs/en/technology/index.mdx @@ -17,8 +17,8 @@ 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 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. +- **Proving Layer**: consists of a pool of provers running the [OpenVM prover](/en/technology/prover/proof-generation) that generate zero-knowledge proofs verifying 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. +This section of the documentation provides comprehensive information on the Scroll protocol specification, bridging protocol, sequencer, and proving system. *In the remainder of this section, L1 will refer to Ethereum, while L2 will refer to Scroll.* diff --git a/src/content/docs/en/technology/overview/scroll-upgrades/euclid-upgrade.mdx b/src/content/docs/en/technology/overview/scroll-upgrades/euclid-upgrade.mdx index 862607d8c..54a69e9f7 100644 --- a/src/content/docs/en/technology/overview/scroll-upgrades/euclid-upgrade.mdx +++ b/src/content/docs/en/technology/overview/scroll-upgrades/euclid-upgrade.mdx @@ -41,7 +41,7 @@ Scroll has been among the pioneers of ZK technology through our EVM bytecode com The new OpenVM prover offers numerous benefits. Prover code is easier to reason about and to audit. We can better reuse code among different components. We can also reduce proving costs and latency. Finally, the new prover will enable us to prove arbitrarily complex transactions, allowing us to remove the circuit capacity checker module that has been a major bottleneck on sequencer throughput. ##### MPT State Commitment -Scroll currently uses a zk-friendly state commitment data structure called [zktrie](https://docs.scroll.io/en/technology/sequencer/zktrie/). With the new OpenVM prover, it is now practical to prove Ethereum’s state structure: the [Merkle-Patricia Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie), also known as MPT. Scroll is now deprecating the zktrie and adopting MPT. +Prior to this upgrade, Scroll used a custom zk-friendly state commitment data structure called zkTrie. With the new OpenVM prover, it is now practical to prove Ethereum's state structure: the [Merkle-Patricia Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie), also known as MPT. Scroll has deprecated zkTrie and adopted MPT. MPT unlocks better sequencer performance and offers better compatibility for dapps relying on L2 state proofs. diff --git a/src/content/docs/en/technology/prover/proof-generation.mdx b/src/content/docs/en/technology/prover/proof-generation.mdx index 028be2e2a..721ae6886 100644 --- a/src/content/docs/en/technology/prover/proof-generation.mdx +++ b/src/content/docs/en/technology/prover/proof-generation.mdx @@ -4,4 +4,35 @@ date: Last Modified title: "Proof Generation" lang: "en" permalink: "technology/prover/proof-generation" +whatsnext: { "zkEVM Overview": "/en/technology/zkevm/zkevm-overview" } --- + +import Aside from "../../../../../components/Aside.astro" + +## Overview + +Scroll uses the **OpenVM prover** to generate zero-knowledge proofs that validate L2 transaction execution. This system was introduced in the [Euclid upgrade](/en/technology/overview/scroll-upgrades/euclid-upgrade). + + + +## Proof Aggregation + +The prover uses a three-layer hierarchical aggregation: + +1. **Chunk proofs**: Prove execution of individual chunks (collections of blocks) +2. **Batch proofs**: Aggregate multiple chunk proofs +3. **Bundle proofs**: Final aggregation, converted to SNARK for on-chain verification + +This hierarchy reduces L1 verification costs by combining many proofs into one. + +## Proving Infrastructure + +The **Coordinator** dispatches proving tasks to a pool of provers, collects completed proofs, and manages aggregation. Final proofs are relayed to the Rollup Node for submission to L1. + +## Learn More + +- [OpenVM Repository](https://github.com/openvm-org/openvm) +- [Scroll zkVM Prover](https://github.com/scroll-tech/zkvm-prover) +- [Euclid Upgrade](/en/technology/overview/scroll-upgrades/euclid-upgrade) diff --git a/src/content/docs/en/technology/sequencer/execution-node.mdx b/src/content/docs/en/technology/sequencer/execution-node.mdx index b467cc440..9f62506e2 100644 --- a/src/content/docs/en/technology/sequencer/execution-node.mdx +++ b/src/content/docs/en/technology/sequencer/execution-node.mdx @@ -35,45 +35,25 @@ The following sections will introduce the main components of the execution node, - **L1 SyncService**: Sync and store L1 messages in `l2geth` local database. - **API layer**: Standard Ethereum RPC and p2p interfaces. - **Transaction pool**: Mempool for L2 transactions. -- **Circuit capacity checker**: checks if a transaction or a block exceeds the circuit capacity limit. -### Circuit Capacity Checker - -With Scroll's current zkEVM circuits, it is possible to construct transactions and blocks that cannot be proven because they do not fit into the zkEVM circuit. We call this *proof overflow*. To avoid this, we implemented a *circuit capacity checker* module as part of l2geth. The circuit capacity checker is used both during block creation and block validation. - -During block creation, if the next transaction would lead to proof overflow, then we seal the block and leave the transaction for the next block. If a single transaction leads to proof overflow, l2geth discards it. We call this mechanism *skipping*. - -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 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. - -