Airbender Prime：关注最慢的区块

分析 | 2026年10月17日

ZKsync在10月13日公布的测试称，一张GPU证明7,200个区块，每个均低于12秒。

值得追问的工程问题，是如何使用更快证明器带来的时间余量。Open Market Notes 分析三种选择：缩短等待、吸收突发任务，或要求更多实现达成一致。下文计算是原创的假设示例，并非 Airbender Prime 的实测数据，也不是对已公布测试的独立复现。

先决定计时在哪里结束

以太坊路线图描述了12秒的出块节奏，并区分证明生成与验证。

在我们提出的服务测试中，完整任务可用时开始计时，所需结果被接受时停止。排队、证明、传输和验证分别记录。证明阶段缩短，可以给其他环节留下时间，但不能据此确定它们实际需要多久。单凭出块间隔，也无法确定服务接受结果的截止时间；这一条件必须明确写出。

一个慢任务可能拖延后面的任务

设想五个相互独立的任务，分别在第0、12、24、36和48秒到达。一个工作单元按到达顺序处理，中途不抢占。处理时长依次为8、8、20、8和8秒。每个任务的截止时间均为到达后12秒。忽略传输、验证、启动及其他全部开销；恰好在截止时刻完成算作按时。

完成时刻依次为第8、20、44、52和60秒，对应截止时刻为第12、24、36、48和60秒。第三、第四个任务超时，尽管平均处理时长只有10.4秒。第四个任务只需八秒工作，却承接了第三个任务造成的等待。第五个任务刚好按时完成，没有为任何被省略的开销留下余量。

这个例子并不估计真实系统的超时率。它只分离两个概念：处理任务本身花费的时间，以及任务到达后经过的时间。调整任务顺序、允许抢占或增加工作单元，都会形成不同的实验。这些选择应当可见，而不应藏在平均值里。

备用容量与必须达成的一致并不相同

以太坊基金会的研究主张，zkVM及其执行的状态转换实现都应保持多样性。

现在设想两条明确属于假设的接受规则。第一条接受两个工作单元中最早产生的有效结果；第二条要求两个指定的独立实现都提交有效且一致的结果。假设候选区块相同，结果分别在第八和第十三秒可用，且没有其他开销。第一条规则在第八秒接受结果；第二条最早也要等到第十三秒。这只是服务策略示例，不是在描述当前以太坊共识。

因此，在两种设计中，额外工作单元承担的职责不同。第一种可以用它补上迟到的结果；第二种则把它的结果纳入必要条件。机器更多，本身并不能说明哪些结果必须一致。任何速度比较都应明示接受规则，包括缺少必需结果时，任务是否仍未完成。

测试突发任务，也披露未完成的工作

我们建议按明确规定的到达时间表，重放固定的区块序列，并纳入突发任务。保留排队历史，而不是在每个区块开始前重置工作单元。说明可用硬件、调度规则、截止时间和接受条件。在启用预期的冗余或实现多样性要求后，运行同一序列。

分别报告截止前被接受的结果、迟到结果和未完成任务，并展示突发任务后队列需要多久才能恢复。不要仅因为任务没有完成时间就把它删去：排除这些工作，可能让一个吃力的服务显得更快。运营结果应与安全评估分开。

设计选择在于如何使用省下的时间。更短的等待、应付难处理序列的储备，以及额外一个必须获得的结果，是对同一份余量的不同用途。下一次有价值的演示，应把这种分配写清楚，并展示选定的截止时间能否经受由此形成的队列。