Scroll三层架构深度解析：结算层、排序层与证明层如何协同工作-育师

Scroll三层架构深度解析：结算层、排序层与证明层如何协同工作

【免费下载链接】scroll-documentationThis is the frontend for the Scroll documentation项目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentation

很多刚接触 Scroll 的朋友都会问：Scroll 三层架构到底是怎么运作的？为什么它既能兼容以太坊，又能实现高性能与低费用？作为基于 zkEVM 技术的以太坊 Layer 2 网络，Scroll 将系统拆分为结算层、排序层与证明层三大模块，各司其职又紧密配合。本文用最通俗的语言，带新手一步步看懂这三层各自承担什么职责，以及它们是如何协同完成一笔交易从发起到最终确认的全过程。

一图看懂：Scroll 三层架构总览

先看官方文档中的这张架构图，它直观展示了三大分层的关系：

从上到下依次是：结算层（基于以太坊的 Bridge Contract 与 Rollup Contract）、排序层（Execution Node 执行节点与 Rollup Node 汇总节点）、证明层（Coordinator 协调器与 Provers 证明者）。数据从结算层流入排序层，执行跟踪再进入证明层，最终证明结果回流结算层完成闭环。😉

结算层：锚定以太坊，负责最终安全

结算层（Settlement Layer）是 Scroll 的"信任根基"，它直接构建在以太坊主网上，主要包含两类核心合约：

Bridge Contract（桥接合约）：管理 L1 与 L2 之间的跨链资产和消息。用户在主网存入 ETH 或 ERC-20 代币时，消息会写入L1MessageQueue合约，等待 L2 侧取走。
Rollup Contract（汇总合约）：负责接收排序层提交的批次数据（Commit），并在验证有效性证明后完成最终确认（Finalize），同时记录最新的状态根和提款根。

结算层还有一个重要特点：数据可用性。排序层必须把批次交易数据提交到主网，任何人都能据此重建 L2 状态，从而保证用户资金安全不依赖单一运营方。

排序层：交易打包与数据提交的执行者

排序层（Sequencing Layer）相当于 Scroll 的"工厂车间"，由两个核心组件构成：

1. 执行节点（Execution Node）

执行节点基于 go-ethereum 分叉而来，负责收集交易、校验并打包区块、维护 L2 链状态。它还负责处理来自 L1 的存款消息，将其构造成一种特殊交易类型L1MessageTx，与其他 L2 交易一起进入区块。相关实现可参考 execution-node.mdx。

2. 汇总节点（Rollup Node）

汇总节点负责把 L2 区块分层打包：

Chunk（数据块）：一段连续的区块集合，是 zkEVM 生成证明的基本单位。
Batch（批次）：多个 chunk 的集合，是提交到 L1 的数据单位，附带聚合证明。

这种多级打包策略是为了在保证 zkEVM 电路容量不溢出的前提下，摊薄链上提交与验证成本。具体打包约束见 rollup-node.mdx。下图展示了交易从打包到提交的完整流程：

证明层：zkEVM 如何生成有效性证明

证明层（Proving Layer）是 Scroll 与乐观 Rollup 最本质的区别所在。它由**协调器（Coordinator）和证明者（Provers）**组成：

协调器从数据库轮询到新的 chunk 后，会向执行节点拉取该 chunk 内所有区块的执行轨迹（Execution Trace）。
协调器将"chunk 证明任务"随机分配给一台zkEVM 证明者，生成 chunk 证明。
当新 batch 产生时，协调器收集其中所有 chunk 证明，把"batch 证明任务"分发给聚合证明者（Aggregator Prover），生成聚合证明。

下图展示了 zkEVM 如何基于 EVM 执行过程生成零知识证明：

为了让证明更高效，Scroll 还把状态树替换为使用 Poseidon 哈希的 zkTrie（一种稀疏二叉 Merkle Patricia 树），大幅降低电路证明开销，细节见 zktrie.mdx。

三层协同：一笔交易的完整生命周期

现在把三层串起来，看看一笔交易从发起到最终确认要经历哪些阶段（此流程详见 transactions.mdx）：

阶段	状态	参与层级	发生的事
1. 提交执行	Confirmed	排序层	用户在 L1 桥或 L2 提交交易，执行节点打包出块
2. 数据提交	Committed	排序层 → 结算层	Rollup 节点打包 batch，提交 Commit 交易到 L1，数据上链
3. 证明生成	—	证明层	协调器派发任务，zkEVM 证明者生成 chunk 证明，聚合器合成 batch 证明
4. 最终确认	Finalized	证明层 → 结算层	提交 Finalize 交易，L1 合约验证聚合证明，更新状态根

跨链资金如何流动？

充值（L1 → L2）：用户在主网调用网关合约，消息进入L1MessageQueue，排序层同步后打包进 L2 区块，流程如图：
提款（L2 → L1）：用户发送提款消息进入 L2 的 Withdraw Trie，待批次在 L1 最终确认后，任何人都可凭 Merkle 包含证明在 L1 上执行提款，无需信任第三方：

跨链消息的完整机制（含消息重放、地址别名等）可参阅 cross-domain-messaging.mdx，而 Rollup 提交/最终确认的合约细节在 rollup.mdx。