原文来源：Aptos Labs

自计算技术诞生以来，工程师与研究人员不断探索如何将计算资源推向性能极限，力求在最大化效率的同时最小化计算任务的延迟。高性能与低延迟这两大支柱始终塑造着计算机科学的发展，影响着从 CPU、FPGA 到数据库系统，以及近期的人工智能基础设施和区块链系统等广泛领域。在追求高性能时，流水线技术成为不可或缺的手段。自 1964 年 IBM System/360 引入流水线技术以来 [1]，它一直是高性能系统设计的核心，推动了该领域的关键讨论与创新。

流水线技术不仅应用于硬件，在数据库领域也有广泛应用。例如，Jim Gray 在其著作《高性能数据库系统》中引入了流水线并行方法 [2]。该方法将复杂的数据库查询分解为多个阶段并同时运行，从而提高效率和性能。流水线技术在人工智能领域同样至关重要，特别是在广泛使用的深度学习框架 TensorFlow 中。它利用数据流水线并行处理数据预处理和加载，确保训练与推理的数据流畅通，使 AI 工作流程更快、更高效 [3]。

区块链也不例外。其核心功能类似于数据库，处理交易并更新状态，但增加了拜占庭容错共识的挑战。提升区块链吞吐量（每秒交易数）和降低延迟（至最终确认的时间）的关键在于优化不同阶段——排序、执行、提交和同步交易——在高负载下的交互。这一挑战在高吞吐量场景下尤为关键，因为传统设计难以维持低延迟。

为了探讨这些理念，我们不妨回顾一个熟悉的类比：汽车工厂。理解装配线如何革新制造业，有助于我们领会区块链流水线的演进——以及为何像 Zaptos[8] 这样的下一代设计将区块链性能推向新高度。

从汽车工厂到区块链

想象你是一家汽车工厂的老板，有两个主要目标：

· 最大化吞吐量：每天组装尽可能多的汽车。

· 最小化延迟：缩短每辆汽车的建造时间。

现在，设想三种类型的工厂：

简单工厂

在简单工厂中，一组多能工人按部就班地组装一辆汽车。一名工人组装引擎，下一名工人安装车轮，以此类推——一次只生产一辆车。

问题在于？部分工人常常处于等待状态，整体生产效率低下，因为没有人同时在同一辆车的不同部分上工作。

福特工厂

引入福特装配线 [4]！在这里，每名工人专注于单一任务。汽车沿着传送带移动，每辆车经过时，一名专职工人添加自己的部件。

结果如何？多辆汽车同时处于不同组装阶段，所有工人都在忙碌。吞吐量大幅提升——但每辆车仍需依次经过每名工人，意味着每辆车的延迟时间不变。

魔法工厂

想象一个魔法工厂，所有的工人可以同时在一辆车上工作！不再需要将汽车从一个工位移到下一个工位，汽车的每个部分都同时被建造。

结果呢？汽车以创纪录的速度组装完成，每一步骤都在同步进行。这是解决吞吐量和延迟问题的理想场景。

好了，汽车工厂的讨论到此为止——区块链呢？事实证明，设计高性能区块链与优化装配线并无太大不同。

区块链如汽车工厂

在区块链中，处理一个区块类似于组装一辆汽车。类比如下：

· 工人 = 验证者资源

· 汽车 = 一个区块

· 组装任务 = 共识、执行和提交等阶段

就像简单工厂一次只处理一辆车，区块链如果一次只处理一个区块，会导致资源利用不足。相反，现代区块链设计力求像福特装配线一样——同时处理多个区块的不同阶段。这就是流水线技术的用武之地。

区块链流水线的演进

传统架构：顺序区块链

想象一个按顺序处理区块的区块链。验证者需要：

1. 接收区块提议。

2. 执行区块以更新区块链状态。

3. 继续对该状态进行共识。

4. 将状态持久化到数据库。

5. 开始下一个区块的共识。

问题在哪里？

· 执行和提交处于共识过程的关键路径中。

· 每个共识实例需等待前一个完成才能开始。

这种设置就像前福特时代的工厂：工人（资源）在一次只专注于一个区块（汽车）时常常处于空闲状态。不幸的是，许多现有区块链仍属于这一类别，导致吞吐量低、延迟高。

Aptos：并行化性能

Diem 引入了一种流水线架构，将执行和提交从共识阶段解耦，同时共识阶段本身也采用了流水线设计。

· 异步执行与提交 [5]：验证者首先对一个区块达成一致，然后根据父区块的状态执行该区块。在由验证者法定人数签名认证后，状态被持久化到存储中。

· 流水线共识（Jolteon[6]）：新的共识实例可以在前一个完成之前开始，类似于移动的装配线。

这通过允许不同区块同时处于不同阶段来提升吞吐量，并将区块时间显著缩短至仅需 2 次消息延迟。然而，Jolteon 基于领导者的设计可能造成瓶颈，因为领导者在交易分发时会超载。

Aptos 通过 Quorum Store[7] 进一步优化了流水线，这是一种将数据分发与共识解耦的机制。Quorum Store 不再依赖单一领导者在共识协议中广播大数据块，而是将数据分发与元数据排序分离，允许验证者异步并行分发数据。这种设计利用了所有验证者的总带宽，有效消除了共识中的领导者瓶颈。

图示：Quorum Store 如何平衡基于领导者共识协议的资源利用率。

至此，Aptos 区块链打造了区块链的“福特工厂”。正如福特的装配线革新了汽车生产——不同汽车的不同阶段同时进行——Aptos 同时处理不同区块的不同阶段。每个验证者的资源都被充分利用，确保流程中没有部分处于等待状态。这种巧妙的编排带来了高吞吐量系统，使 Aptos 成为高效且可扩展地处理区块链交易的强力平台。

图示：Aptos 区块链中连续区块的流水线处理。验证者可以对连续区块的不同阶段进行流水线处理，以最大化资源利用率并提高吞吐量。

虽然吞吐量至关重要，但端到端延迟——从交易提交到最终确认的时间——同样重要。对于支付、去中心化金融（DeFi）和游戏等应用，每毫秒都很关键。许多用户在高流量事件中体验过延迟，因为每笔交易必须依次通过一系列阶段：客户端-全节点-验证者通信、共识、执行、状态认证、提交和全节点同步。在高负载下，执行和全节点同步等阶段会带来更多延迟。

图示：Aptos 区块链的流水线架构。图中显示客户端 Ci、全节点 Fi 和验证者 Vi。每个框表示区块链中交易区块从左到右需要经历的一个阶段。流水线包括五个阶段：共识（包括分发和排序）、执行、认证、提交和全节点同步。

这就像福特工厂：尽管装配线最大化了整体吞吐量，但每辆车仍需依次通过每个工人，因此完成时间较长。为了真正将区块链性能推向极限，我们需要打造一个“魔法工厂”——让这些阶段并行运行。

Zaptos：迈向最优区块链延迟

Zaptos[8] 通过三种关键优化进一步降低延迟，同时不牺牲吞吐量。

· 乐观执行：通过在收到区块提议后立即开始执行来减少流水线延迟。验证者立即将区块添加到流水线，并在父区块完成后推测性地执行。全节点从验证者接收提议后，也执行乐观执行以验证状态证明。

· 乐观提交：在区块执行后立即将状态写入存储——甚至在状态认证之前。当验证者最终认证状态时，仅需最小的更新即可完成提交。如果一个区块最终未被排序，其乐观提交的状态会被回滚以保持一致性。

· 快速认证：验证者通过在最终共识轮次并行发送认证消息，提前开始认证已执行区块的状态，而无需等待共识完成。这一优化在常见情况下有效减少了一个轮次的流水线延迟。

图示：Zaptos 的并行流水线架构。除共识外的其他阶段实际上被隐藏在共识阶段内，从而降低端到端延迟。

通过这些优化，Zaptos 有效地将其他流水线阶段的延迟隐藏在共识阶段内。因此，如果区块链采用最优延迟的共识协议，整体区块链延迟也能达到最优！

空谈无益，数据说话

我们通过地理分布式实验评估了 Zaptos 的端到端性能，以 Aptos 作为高性能基线。更多细节见论文 [8]。

在 Google Cloud 上，我们模拟了一个由 100 个验证者和 30 个全节点组成的全球去中心化网络，分布在 10 个地区，使用与 Aptos 部署类似的商用级机器。

吞吐量-延迟

图示：Zaptos 与 Aptos 区块链的常见性能表现。

上图比较了两种系统的端到端延迟与吞吐量关系。两者在负载增加时延迟逐渐上升，并在最大容量时出现急剧 spikes，但 Zaptos 在达到峰值吞吐量前始终表现出更稳定的延迟，低负载下延迟减少 160 毫秒，高负载下减少超过 500 毫秒。

令人印象深刻的是，Zaptos 在生产级主网环境中以 20k TPS 实现亚秒级延迟——这一突破使得需要速度和可扩展性的现实世界应用成为可能。

延迟分解

图示：Aptos 区块链的延迟分解。

图示：Zaptos 的延迟分解。

延迟分解图详细展示了验证者和全节点在每个流水线阶段的持续时间。关键见解包括：

· 至 10k TPS：Zaptos 的总体延迟几乎等同于其共识延迟，因为乐观执行、认证和乐观提交阶段实际上被“隐藏”在共识阶段内。

· 超过 10k TPS：由于乐观执行和全节点同步时间的增加，非共识阶段变得更显著。尽管如此，Zaptos 通过重叠大多数阶段显著减少了总体延迟。例如，在 20k TPS 时，基线总延迟为 1.32 秒（共识 0.68 秒，其他阶段 0.64 秒），而 Zaptos 为 0.78 秒（共识 0.67 秒，其他阶段 0.11 秒）。

结论

区块链架构的演进类似于制造业的转型——从简单的顺序工作流程到高度并行化的流水线。Aptos 的流水线方法显著提升了吞吐量，而 Zaptos 更进一步，将延迟降低至亚秒级，同时维持高 TPS。正如现代计算架构利用并行性最大化效率，区块链必须不断优化设计以消除不必要的延迟。通过全面优化区块链流水线以实现最低延迟，Zaptos 为需要速度和规模的现实世界区块链应用铺平了道路。

参考文献

[1] Gene M. Amdahl, Gerrit A. Blaauw, and Frederick P. Brooks. 1964. “Architecture of the IBM System/360.” IBM Journal of Research and Development. https://doi.org/10.1147/rd.82.0087

[2] David DeWitt, and Jim Gray. 1992. “Parallel Database Systems: The Future of High Performance Database Systems.” Communications of the ACM. https://doi.org/10.1145/129888.129894

[3] Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin et al. 2016. “TensorFlow: a System for Large-Scale Machine Learning.” In 12th USENIX symposium on operating systems design and implementation (OSDI). https://arxiv.org/abs/1605.08695

[4] The Moving Assembly Line and the Five-Dollar Workday. https://corporate.ford.com/articles/history/moving-assembly-line.html

[5] Zekun Li, and Yu Xia. 2021. DIP-213 – Decoupled Execution. https://github.com/diem/dip/blob/7dc44ee57bb7efe76559f05dcc6851d97e2d3149/dips/dip-213.md

[6] Rati Gelashvili, Lefteris Kokoris-Kogias, Alberto Sonnino, Alexander Spiegelman, and Zhuolun Xiang. 2022. “Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback.” In International conference on financial cryptography and data security (FC). https://arxiv.org/abs/2106.10362

[7] Quorum Store: How Consensus Horizontally Scales on the Aptos Blockchain. https://medium.com/aptoslabs/quorum-store-how-consensus-horizontally-scales-on-the-aptos-blockchain-988866f6d5b0

[8] Zhuolun Xiang, Zekun Li, Balaji Arun, Teng Zhang, and Alexander Spiegelman. 202 2025. “Zaptos: Towards Optimal Blockchain Latency.” arXiv preprint arXiv:2501.10612. https://arxiv.org/abs/2501.10612