在 Scroll 上发一笔 Layer2 交易，你会在浏览器里先后看到它处于 Pending、Committed 和 Finalized 三种状态。这背后是官方文档里一套分层的打包结构：交易先被排进区块，连续区块被编成 chunk，连续的 chunk 再被打包成 batch。三层的分工很明确——chunk 是生成零知识证明的基本单位，batch 是提交到以太坊上做数据承诺和验证证明的基本单位。理解这套结构，才能判断一笔交易在哪个时点”数据跑不掉”、又在哪个时点”状态已被证明”。
区块、chunk 与 batch 各管一段
官方文档把打包分成三级：一组有序交易打包成区块；一段连续区块组成一个 chunk；一段连续 chunk 组成一个 batch。分层的目的是省钱——链上数据承诺和证明验证的费用，通过批处理被摊薄到更多 Layer2 交易头上：batch 要提交的数据被压缩合并，batch 的证明则是它内部所有 chunk 证明聚合出来的一个总证明，验证者只需在 L1 验一次。
承担打包工作的是 rollup 节点，它和执行节点分开，内部有三个子模块：Chunk Proposer 收集 L2 区块并提议新的 chunk，Batch Proposer 收集 chunk 并提议新的 batch，Relayer 负责把 batch 数据和证明提交到 L1。三者各自要守几条官方约束：以太坊对 blob 数据和 calldata 的大小设了上限；提交一个 batch 的 gas 成本随块内区块和交易数量增长，必须压在 L1 区块 gas 上限之内；一个 batch 装多少个 chunk 还要照顾聚合证明器的工作效率。
Commit 交易给数据，Finalize 交易给终局
新 batch 一旦成形会触发两件事：rollup 节点把这笔 batch 的交易数据和区块信息通过一笔 Commit 交易发到 L1 的 ScrollChain 合约；同时一个聚合各 chunk 证明的 batch 证明任务被派发给聚合证明器。当 Commit 交易在 L1 区块里落定，这笔 batch 里的交易状态变成 Committed——从这一刻起，任何人和遵循派生规则的节点都可以只根据 L1 上的承诺数据完整重建出这段 L2 状态。
等有效性证明生成好，rollup 节点再发一笔 Finalize 交易，把证明和这个 batch 之后的新状态根交给 L1 合约做链上验证。Finalize 交易在 L1 确认后，batch 里的交易才算 Finalized，成为规范链的一部分，新状态根也就可以被第三方信任最小化地引用。两段时间差取决于证明生成速度和 L1 拥堵程度，官方文档没有承诺固定时长，把某条 Layer2 的”几分钟终局”当成常数并不可靠。
用户与开发者该在哪个台阶上验收
两层提交给了两把不同的尺子：看到 Committed，说明交易数据已经钉在以太坊上、别人删不掉也改不了，此时状态还只建立在”按同一数据本地重放”的默契上；看到 Finalized，说明状态转换已经用零知识证明在 L1 上验证过，这才是可对外引用的结论。跨链桥、金库这类下游逻辑把等待点设在哪一级，直接决定它们信任的是数据可用还是已经证明的正确性——读桥的文档时值得先确认这一点。
边界之外：跳层比较的坑
三层结构还解释了两件容易被混谈的事。其一，“Scroll 把数据发到以太坊”指的是 batch 级别的 Commit 交易，不是每笔交易单独上链：零散看某笔交易的原始字节在以太坊上找不到，是正常现象，它的痕迹被压缩编码进了所属 batch 的承诺数据里。其二，Committed 与 Finalized 各自依赖的对象不同——前者依赖 L1 数据可用性与派生规则的一致性，后者额外要求那份零知识证明正确且验证合约逻辑无误，所以比较两条 Layer2 的安全性时，先对齐它们在哪一层做保证，再下结论。想核对某个具体 batch 的进度，可查 ScrollChain 合约上的批次提交记录与验证合约的最终化记录；浏览器状态页读到的正是这些链上记录的映射。本文只描述协议机制，不构成投资建议，也不对任何上线时间与性能指标做承诺，相关参数与流程以 Scroll 官方文档与链上合约现状为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。