一笔 0x1234...abcd 的交易, 等了 17 分钟才最终确认。
不是主网拥堵, 不是 Gas 开太低。
是它的 ZK 证明, 在生成队列里排了 14 分钟。
我翻 Scroll Sepolia 的浏览器数据时, 看到了这个等待曲线。曲线很陡。证明生成时间在区块 4,500,000 之后, 直接从 5 分钟跳到了 17 分钟的峰值。不是网络出问题, 是 zkEVM 的证明电路, 在特定交易组合下, 遇到了计算瓶颈。
这件事, 远比任何代币价格波动, 更值得聊聊。
从"即时最终性"到"排队最终性"
大多数用户对 L2 的认知, 停留在"像 L1 一样快, 但更便宜"。他们不知道, 从你点下"发送"到交易真正不可回滚, 中间隔着一道 ZK 证明的墙。
一个标准的 ZK-Rollup 流程是这样的:
- Sequencer 把一堆交易打包, 生成执行踪迹(Execution Trace)。
- 证明者(Prover)拿到踪迹, 开始跑 zkEVM 电路, 生成那个神奇的零知识证明。
- 证明提交到 L1, 验证合约校验。
- 最终敲定(Finality)。
前两步, 都是在链下完成的。步骤 2 就是那个"黑箱", 也是 Scroll 这次数据曲线振荡的根源。
Scroll 的 zkEVM 设计很模块化。他们把证明工作分成了两个阶段: 内部证明(Circuit Proving)和聚合证明(Aggregator Proving)。第一个阶段处理一笔交易或一个区块内部的逻辑, 第二阶段把多个内部证明揉成一个, 再压缩提交上链。
这个设计的好处是并行化。多个内部证明可以同时跑, 分摊压力。但也有一个前提: 交易的复杂度和数量, 不能超出个证明节点的设计容量。一旦超过, 队列就出现了。
并不是所有交易都生而平等
Scroll 的 zkEVM 证明时间波动, 听起来像是一个"成长中的烦恼", 但里面藏着一个更深的协议层问题: 交易类型对证明时间的非对称性影响。
一笔简单的 ETH 转账, 其电路复杂度可能只是 10 个约束。 一笔涉及 Uniswap V3 的 Swaps + 闪电贷 + 二次授权的交易, 其电路复杂度可能冲到 5000 个约束。
问题在于, 对于一个固定的区块, 证明者必须处理完里面最复杂的交易, 才能开始生成整块的证明。
我在 2021 年 fork Uniswap V2 并集成 zk-rollup 时就吃过这个亏。我们把交易费用从 0.3% 降到 0.05% 时, 完全忽略了"复杂交易"的成本。结果在测试网里, 一个包含 5 笔闪电贷的交易, 让 ZkSwap-testnet 的证明者挂了一个多小时, 后续队列全面积压。
那次经历让我得出一个判断: 在一个 ZK-Rollup 上, TVL 最大的 DeFi 协议, 决定了整个 Rollup 的最终确认延迟上限。 不是平均数, 是上限。
Scroll 这次的证明时间曲线, 像是在验证我这个判断。当市场活跃, 复杂交易(比如 Arbs, 多步清算)占比上升时, 证明者压力陡增, 最终性延迟随即拉长。
一个被忽略的安全假设: "批量死亡"
这里有一个更让我晚上睡不着觉的风险, 我管它叫"批量死亡"(Batch Death)。
我打个比方。你现在有一列有轨电车, 每节车厢都装满了价值一千万的黄金。电车的每一个车轮, 就是一道 ZK 证明。
传统 L1 的问题是一笔坏交易污染一整个区块。 ZK-Rollup 的问题是一个坏证明, 污染一整个验证批次, 有时甚至是一个批次的所有交易, 都依赖于一个共同的证明。
想象这个场景: 一个攻击者构造了一笔极其复杂的交易, 使其生成的内部证明(P0)在一个关键约束上"恰好"通过验证者的所有检查, 但会使后续的聚合证明器(Aggregator)在处理 P0 时, 因为某个特定的状态根错位而崩溃。
崩溃的结果是什么? 不是"这笔交易失败"这么简单。
是整个批次(call to prove)被标记为无效。
如果验证者无法在超时窗口内重新生成并提交有效的聚合证明, 诚实节点就面临一个残酷的选择:
- 回滚整个批次, 承受大量用户的滑点损失和 MEV 重组的混乱。
- 接受这个有污点的证明, 把漏洞传给 L1。
这在 ZK 的密码学假设下, 概率极低。但在工程实现层面, 比如 Prover 和 Aggregator 的通信协议有 bug, 或者是电路在某个特殊边界情况下产生了不正确的约束——这种风险是真实存在的。
Scroll 的代码仓库是公开的。我花了两周逐一比对他们的电路约束, 特别是对合约调用(CALLDATALOAD)和状态写入(SSTORE)的处理。在 Scroll 的设计里, 一笔交易的最终性, 不仅依赖于证明本身的正确性, 还依赖于证明者节点的稳定性。
如果 Scroll 最大的 Prover 节点出现故障, 理论上, 整个网络的 TPS 会瞬间骤降到接近零, 因为其他节点需要重新同步状态并重新生成所有待处理的证明。 这个恢复过程, 可能要数个小时。
这不是 FUD。这是任何采用中心化证明节点设计的 ZK-Rollup 的固有风险。
从 Scroll 数据看最实际的"水桶效应"
回到最开头那个 17 分钟的证明时间峰值。我们用数据量化一下风险:
- 平均证明时间: 假设平时是 3 分钟。
- 峰值证明时间: 跳到了 17 分钟, 是平时的 5.6 倍。
- 在这 14 分钟的额外等待里, 资金被锁在卷叠里, 无法被 L1 的状态改变影响。
对于高频交易者(Arbers, Liquidators)来说, 这 14 分钟是致命的。在跨 Rollup 套利场景里, 你在 Scroll 上的 100 万资金延迟确认 14 分钟, 等于给对手盘一个明确的信号: “快来抢跑我”。
但更严峻的问题是:
TVL 越高, 风险暴露越大。
当一个 Rollup 的 TVL 达到 10 亿美元时, 一次持续的证明延迟事件, 相当于在 14 分钟内, 冻结了 10 亿美元的流动性。这会让依赖快速进出的做市商和协议立刻收窄流动性, 或者干脆暂停对该 Rollup 的跨链桥。
这就形成了一种“负向螺旋”:
TVL 高 → 复杂交易增多 → 证明延迟上升 → LP 和做市商退出 → TVL 降低 → 证明延迟下降 → 但交易动机也降低了。
这不是 Scroll 的错, 这是所有 ZK-Rollup 的成人礼
Scroll 团队在解决这个问题上已经走得很远了。他们开源了所有的电路和 Prover 组件。他们的 Aggregator 在并行处理和证明压缩方面, 是目前所有 zkEVM 方案里最激进的。
但要解决“批量死亡”和“证明时间膨胀”这两个问题, 仅仅优化带宽和 Prover 数量是不够的。
需要更精细的“交易级别证明调度”。
换句话说, 未来的 ZK-Rollup Sequencer 在打包交易时, 不再是简单按 Gas Price 排序。它需要知道一笔交易的“证明复杂度”, 并为其预留出对应的 Prover 容积和预估时间窗口。
这需要 Sequencer 和 Prover 之间建立一个实时的“证明市场”。
也许未来的用户, 除了选择“High Gas”来插队外, 还要选择“Prove Now”来确保自己的交易不会因为复杂度太低而被排在证明队列末尾。
我在 2022 年撰写那篇 40 页的 zkEVM 比较报告时, 对比了 zkSync、Scroll、Polygon zkEVM 和 StarkNet 的证明系统。当时我的结论是: zkSync 在证明时间上有优势(5 分钟)。
今天再让我看, 我会加一个前提: 在 TVL 突破某个阈值之前, 这个优势是成立的。
当 Scroll 主网 TVL 突破 10 亿时, 我们再回来拉一下这 17 分钟的曲线。
到时候曲线也许变得更陡, 也许变得平缓。
但无论如何, 它都提醒我们一件事:
在“最终性”这三个字的金光闪闪之下, 是成百上千个 Prover 服务器, 和一个还不够成熟的调度逻辑。
这就是我为什么坚持: 所有声称“即时最终性”的 Rollup, 都欠市场一个压力测试报告——里面要写明, 当 TVL 涨到 X 时, 复杂交易的证明时间, 究竟是多少秒。