Scroll Rollup流程全解析从交易打包到有效性证明生成【免费下载链接】scroll-documentationThis is the frontend for the Scroll documentation项目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentationScroll 是首个基于 zkEVM 的以太坊二层L2网络它的Scroll Rollup流程堪称 zk-rollup 技术的教科书级实现。这篇文章将用最通俗的语言带你完整走一遍 Scroll Rollup流程从用户提交交易、执行节点打包区块到交易分批提交上链再到 zkEVM 生成有效性证明并最终确认。全程不需要写代码看完全文你就明白 Layer 2 是如何踩着以太坊的肩膀高效运转的。Scroll 是什么一张图看懂二层网络的三层架构要理解 Rollup 流程先要知道 Scroll 的总体架构。它的核心思路是把计算和状态放到 L2 上执行把数据与安全性交给 L1 以太坊保证。整个系统分为三层结算层Settlement Layer以太坊主网部署着跨链桥合约与 Rollup 合约是最终裁决者。排序层Sequencing Layer由执行节点Execution Node与 Rollup 节点Rollup Node组成负责出块与打包。证明层Proving Layer由协调器Coordinator与两类证明者Prover组成负责生成有效性证明。这三层各司其职、环环相扣共同支撑起完整的 Scroll Rollup流程。Scroll Rollup 流程第一步交易执行与区块生成一切的起点是用户提交交易。在 Scroll 上你有两种提交方式直接提交给 L2 排序器像用普通钱包一样连接 Scroll 的 RPC 端点即可。在 L1 桥合约上发起交易比如存款、强制交易这类消息会进入 L1 的L1MessageQueue消息队列。随后执行节点内的三个模块开始协同工作Sync Service同步服务持续监听 L1 桥合约事件发现新消息就生成对应的L1MessageTx交易放入 L1 队列Mempool交易池收集用户直接提交到 L2 的交易Executor执行器同时从 L1 队列和 L2 交易池拉取交易执行并打包成新的 L2 区块。上图完整展示了 Scroll Rollup流程的各个环节。交易被打进区块后就进入了**已确认Confirmed**状态但这只是漫长旅程的开始。第二步交易打包Batching——Chunk 与 Batch 的分层设计Scroll 最有特色的设计就是它的多层交易打包机制。交易并不是直接一股脑提交到 L1 的而是像套娃一样逐级聚合Block区块一组有序交易打包而成是 L2 的最小账本单元Chunk分块一系列连续区块聚合而成是 zkEVM 电路证明的基本单位Batch批次一系列连续 Chunk 聚合而成是 L1 数据提交与证明验证的基本单位。为什么要搞这么复杂的层级答案是为了省钱。以太坊对交易 payload 有 128KB 的硬性限制而且每次在 L1 上提交数据、验证证明都要消耗 gas。把交易聚合得越大块单位交易摊分的成本就越低同时还能规避 zkEVM 电路的容量上限。打包完成后Rollup 节点中的Relayer会向 L1 的ScrollChain合约提交一笔Commit 交易提交交易把该 Batch 的区块信息与交易数据在 Bernoulli 升级后以 EIP-4844 Blob 形式上链确保数据可用性Data Availability。这笔交易中包含了关键的dataHash它将成为后续证明验证的公共输入之一——相当于给这批数据盖了一个内容指纹。第三步有效性证明生成——zkEVM 如何自证清白数据提交上链后真正的重头戏来了生成有效性证明。Rollup 的信任基础就在于——任何人都可以依据 L1 上公开的数据重新执行而 Scroll 用密码学证明保证了执行结果的唯一正确。这个过程由**协调器Coordinator**调度每产生一个新 Chunk协调器就会从执行节点拉取该 Chunk 内所有区块的执行轨迹Execution Trace把Chunk 证明任务随机派发给某个 zkEVM 证明者每产生一个新 Batch协调器会从数据库收集该 Batch 内所有 Chunk 的证明把Batch 证明任务派发给聚合证明者Aggregator Prover由它把多个 Chunk 证明聚合成一个 Batch 证明。zkEVM 证明的本质是证明执行轨迹是正确的每个操作码都按以太坊黄皮书的规范执行且初始状态经过这些步骤后确实变成了最终状态。这个证明过程把 EVM 的执行拆解为一条条指令级记录再交由 zkEVM 电路验证最终生成一个可在链上快速验证的密码学证明。最终确认Finalize 交易与提款解锁证明生成后Relayer 会把证明与结果提交给 L1 的ScrollChain合约执行Finalize 交易最终确认交易。这笔交易包含该 Batch 的有效性证明执行前的状态根prevStateRoot与执行后的状态根postStateRoot提款根withdrawRoot。合约会将chainId、前后状态根、提款根与 Batch 的dataHash组合成publicInputHash交给 Plonk 验证器验证。验证通过的那一刻新的状态根成为 L2 的官方账本该 Batch 内的提款交易用户可以在 L1 上用 Merkle 证明直接领取资产。也就是说只有走到这一步你的资产跨链才是真正落袋为安的。快速自查我的交易处于哪个阶段理解了整个流程就能轻松判断一笔 Scroll 交易的进展了。三个阶段对比如下状态触发时机含义✅ Confirmed已确认交易被打进 L2 区块交易已被执行但尚未提交到 L1 Committed已提交Commit 交易在 L1 确认交易数据已上链任何人都可自行验证状态 Finalized已最终确认Finalize 交易验证通过有效性证明通过状态根可信任可提款对普通用户而言日常转账看到Confirmed就已足够而当你进行跨链提款时则需要耐心等待到Finalized资产才能真正到达 L1。总结一条完整的 Scroll Rollup 流水线回顾整个 Scroll Rollup流程可以用一句话概括L2 负责执行L1 负责记账zkEVM 负责背书。交易从用户手中出发经过区块、Chunk、Batch 三级打包数据先提交到 L1 保证可用性证明随后生成并验证最终状态被 L1 锁定——整个过程环环相扣兼顾了性能、安全与成本。如果你想深入了解每个环节的技术细节Scroll 官方文档仓库提供了完整的英文技术文档建议按以下路径查阅Rollup 流程总览src/content/docs/en/technology/chain/rollup.mdx交易打包与生命周期src/content/docs/en/technology/chain/transactions.mdxRollup 节点与 Chunk/Batch 约束src/content/docs/en/technology/sequencer/rollup-node.mdx执行节点与电路容量检查src/content/docs/en/technology/sequencer/execution-node.mdxzkEVM 证明原理src/content/docs/en/technology/zkevm/zkevm-overview.mdx看完这篇文章相信你已经对 Scroll 的 Rollup流程有了整体认知。下一次使用 Scroll 跨链时不妨想象一下那笔交易正在流水线上经历打包、提交与证明的完整旅程是不是觉得它更酷了一点【免费下载链接】scroll-documentationThis is the frontend for the Scroll documentation项目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentation创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Scroll Rollup流程全解析：从交易打包到有效性证明生成
Scroll Rollup流程全解析从交易打包到有效性证明生成【免费下载链接】scroll-documentationThis is the frontend for the Scroll documentation项目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentationScroll 是首个基于 zkEVM 的以太坊二层L2网络它的Scroll Rollup流程堪称 zk-rollup 技术的教科书级实现。这篇文章将用最通俗的语言带你完整走一遍 Scroll Rollup流程从用户提交交易、执行节点打包区块到交易分批提交上链再到 zkEVM 生成有效性证明并最终确认。全程不需要写代码看完全文你就明白 Layer 2 是如何踩着以太坊的肩膀高效运转的。Scroll 是什么一张图看懂二层网络的三层架构要理解 Rollup 流程先要知道 Scroll 的总体架构。它的核心思路是把计算和状态放到 L2 上执行把数据与安全性交给 L1 以太坊保证。整个系统分为三层结算层Settlement Layer以太坊主网部署着跨链桥合约与 Rollup 合约是最终裁决者。排序层Sequencing Layer由执行节点Execution Node与 Rollup 节点Rollup Node组成负责出块与打包。证明层Proving Layer由协调器Coordinator与两类证明者Prover组成负责生成有效性证明。这三层各司其职、环环相扣共同支撑起完整的 Scroll Rollup流程。Scroll Rollup 流程第一步交易执行与区块生成一切的起点是用户提交交易。在 Scroll 上你有两种提交方式直接提交给 L2 排序器像用普通钱包一样连接 Scroll 的 RPC 端点即可。在 L1 桥合约上发起交易比如存款、强制交易这类消息会进入 L1 的L1MessageQueue消息队列。随后执行节点内的三个模块开始协同工作Sync Service同步服务持续监听 L1 桥合约事件发现新消息就生成对应的L1MessageTx交易放入 L1 队列Mempool交易池收集用户直接提交到 L2 的交易Executor执行器同时从 L1 队列和 L2 交易池拉取交易执行并打包成新的 L2 区块。上图完整展示了 Scroll Rollup流程的各个环节。交易被打进区块后就进入了**已确认Confirmed**状态但这只是漫长旅程的开始。第二步交易打包Batching——Chunk 与 Batch 的分层设计Scroll 最有特色的设计就是它的多层交易打包机制。交易并不是直接一股脑提交到 L1 的而是像套娃一样逐级聚合Block区块一组有序交易打包而成是 L2 的最小账本单元Chunk分块一系列连续区块聚合而成是 zkEVM 电路证明的基本单位Batch批次一系列连续 Chunk 聚合而成是 L1 数据提交与证明验证的基本单位。为什么要搞这么复杂的层级答案是为了省钱。以太坊对交易 payload 有 128KB 的硬性限制而且每次在 L1 上提交数据、验证证明都要消耗 gas。把交易聚合得越大块单位交易摊分的成本就越低同时还能规避 zkEVM 电路的容量上限。打包完成后Rollup 节点中的Relayer会向 L1 的ScrollChain合约提交一笔Commit 交易提交交易把该 Batch 的区块信息与交易数据在 Bernoulli 升级后以 EIP-4844 Blob 形式上链确保数据可用性Data Availability。这笔交易中包含了关键的dataHash它将成为后续证明验证的公共输入之一——相当于给这批数据盖了一个内容指纹。第三步有效性证明生成——zkEVM 如何自证清白数据提交上链后真正的重头戏来了生成有效性证明。Rollup 的信任基础就在于——任何人都可以依据 L1 上公开的数据重新执行而 Scroll 用密码学证明保证了执行结果的唯一正确。这个过程由**协调器Coordinator**调度每产生一个新 Chunk协调器就会从执行节点拉取该 Chunk 内所有区块的执行轨迹Execution Trace把Chunk 证明任务随机派发给某个 zkEVM 证明者每产生一个新 Batch协调器会从数据库收集该 Batch 内所有 Chunk 的证明把Batch 证明任务派发给聚合证明者Aggregator Prover由它把多个 Chunk 证明聚合成一个 Batch 证明。zkEVM 证明的本质是证明执行轨迹是正确的每个操作码都按以太坊黄皮书的规范执行且初始状态经过这些步骤后确实变成了最终状态。这个证明过程把 EVM 的执行拆解为一条条指令级记录再交由 zkEVM 电路验证最终生成一个可在链上快速验证的密码学证明。最终确认Finalize 交易与提款解锁证明生成后Relayer 会把证明与结果提交给 L1 的ScrollChain合约执行Finalize 交易最终确认交易。这笔交易包含该 Batch 的有效性证明执行前的状态根prevStateRoot与执行后的状态根postStateRoot提款根withdrawRoot。合约会将chainId、前后状态根、提款根与 Batch 的dataHash组合成publicInputHash交给 Plonk 验证器验证。验证通过的那一刻新的状态根成为 L2 的官方账本该 Batch 内的提款交易用户可以在 L1 上用 Merkle 证明直接领取资产。也就是说只有走到这一步你的资产跨链才是真正落袋为安的。快速自查我的交易处于哪个阶段理解了整个流程就能轻松判断一笔 Scroll 交易的进展了。三个阶段对比如下状态触发时机含义✅ Confirmed已确认交易被打进 L2 区块交易已被执行但尚未提交到 L1 Committed已提交Commit 交易在 L1 确认交易数据已上链任何人都可自行验证状态 Finalized已最终确认Finalize 交易验证通过有效性证明通过状态根可信任可提款对普通用户而言日常转账看到Confirmed就已足够而当你进行跨链提款时则需要耐心等待到Finalized资产才能真正到达 L1。总结一条完整的 Scroll Rollup 流水线回顾整个 Scroll Rollup流程可以用一句话概括L2 负责执行L1 负责记账zkEVM 负责背书。交易从用户手中出发经过区块、Chunk、Batch 三级打包数据先提交到 L1 保证可用性证明随后生成并验证最终状态被 L1 锁定——整个过程环环相扣兼顾了性能、安全与成本。如果你想深入了解每个环节的技术细节Scroll 官方文档仓库提供了完整的英文技术文档建议按以下路径查阅Rollup 流程总览src/content/docs/en/technology/chain/rollup.mdx交易打包与生命周期src/content/docs/en/technology/chain/transactions.mdxRollup 节点与 Chunk/Batch 约束src/content/docs/en/technology/sequencer/rollup-node.mdx执行节点与电路容量检查src/content/docs/en/technology/sequencer/execution-node.mdxzkEVM 证明原理src/content/docs/en/technology/zkevm/zkevm-overview.mdx看完这篇文章相信你已经对 Scroll 的 Rollup流程有了整体认知。下一次使用 Scroll 跨链时不妨想象一下那笔交易正在流水线上经历打包、提交与证明的完整旅程是不是觉得它更酷了一点【免费下载链接】scroll-documentationThis is the frontend for the Scroll documentation项目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentation创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考