边出块边执行边落盘：Aptos 共识流水线的四道工序

一笔交易的四道工序

aptos-core 仓库里管线的官方文档开门见山：区块链流水线把区块排序与执行、认证、持久化解耦，让不同区块同时停在不同工序上，各取各的资源红利——共识吃网络、执行吃 CPU、落盘吃磁盘。一笔交易在 Aptos 依次经过四个主要阶段：共识层把交易排进区块；执行层用 Block-STM 执行区块内交易；认证层由验证者对执行结果签名并聚合；提交层把拿到证书的区块写入存储。

错位进行才是重点

真正决定性能的是阶段之间的重叠。官方文档描述的基础流水线里，任意时刻大致有四个区块同时在途：第 i 块正在被排序，i-1 块正在被执行，i-2 块正在被认证，i-3 块正在落盘。换句话说，验证者的网卡、处理器和磁盘不会互相空等——上一条链把区块从出块到落盘串成一条队列，节点资源永远只有一类在满负荷；而流水线把队列横过来摆，同一台机器同一秒内三段工作并行。文档还注明完整设计见配套的 Zaptos 论文，四阶段命名与 arXiv 论文 2501.10612 的架构描述一致。

对普通用户，这种结构的可感知含义在确认时间上：一笔交易不必等前面所有区块走完全部流程才被定死，它所在区块被认证后状态即可信，而更靠前的区块仍在悄悄写盘。系统端到端延迟不再由”单块总工时乘以在途块数”主导，而由最慢的一道工序决定。仓库文档进一步记载了 Zaptos 阶段的三项优化——乐观执行（收到提案就开跑，不等排序完成）、提前认证（与最后一轮共识投票同时广播认证票）、预提交（执行结果先落盘、标记为乐观提交，拿不到排序结果再回滚）：目标是让执行、认证、落盘全部藏进共识延迟的影子里，排序完成时三件事已经完成，端到端延迟约等于共识延迟。文档同时列出例外：需要链上随机数的区块无法乐观执行，必须等随机值就位，Zaptos 的延迟优化对这类区块不生效。

认证阶段容易被忽略

四步里最特殊的是认证。Aptos 的共识只负责定序，执行结果是否有效由验证者对结果签名来证明：多数票聚合起来形成执行承诺，此后节点之间交换区块时会带这份证书。这与”出块即正确”的假设不同——排序与执行被有意拆权，坏结果拿不到证书就进不了提交。对观察链上状态的读者，这意味着区分”区块已排序”和”区块已认证”是有意义的两种状态，正如其他链区分”已打包”与”已最终”。

流水线的工程骨架在文档里也有交代。实现上，每一区块被构造成一棵异步任务的依赖图，依赖分两类：块内依赖，即后一阶段等同一区块的前一阶段（执行要等区块准备完成）；块间依赖，即第 N+1 块的执行要等第 N 块的执行完成。正是第二条约束保证了状态迁移仍按链的顺序推进——并行只发生在工序之间，从不颠倒区块之间的先后。执行阶段还有一个容易被忽略的前置条件：区块里的交易若声明需要链上随机数，执行必须等随机值就位才能开跑。

对读节点的读者还有一处细节：有序区块先进入缓冲管理器登记为 ordered 状态，收齐认证票之后才转为 executed 并推进到提交，节点对外提供”已提交状态”对应的正是这最后一步。

边界与代价

流水线不是免费的：同一时刻多块在途要求验证者同时维护多份执行上下文，失败的交易仍要处理推测执行的开销；Block-STM 的并行红利取决于交易冲突率，冲突密集时段执行这道工序可能反超排序成为瓶颈，届时流水线的节拍会被拉长——这类负载特征官方文档不假装不存在。此外上述参数与实现会随版本演进，文中结构描述对应 aptos-core 仓库 pipeline 文档当前记载的基准设计，具体行为以该仓库与论文的当前版本为准。

本文为协议机制解释，不构成投资建议，也不对任何链的性能结论做背书；公链吞吐表现受网络状况与负载影响，评估技术请以官方文档与可复核论文为准。