Zaptos：将区块链延迟降低到绝对最低限度

由 Zhuolun Xiang 和 Alexander Spiegelman

TL;DR：Zaptos 是一种新型的并行、流水线区块链架构，旨在在保持高吞吐量的同时，尽可能减少端到端延迟。在一个具有100个验证者的地理分布式网络中，Zaptos 实现了低于一秒的端到端区块链延迟，吞吐量为每秒 20,000 笔交易（TPS）。

欲了解更多详细信息，请查看 Zaptos 论文。

端到端区块链延迟是指从提交交易的那一刻到收到确认其已被记入的点，这已成为一个关键的关注话题。在高吞吐量下的端到端区块链延迟对于尾部敏感的区块链应用的广泛采用尤其重要，包括支付、 DeFi 和游戏。

大多数学术界和 Web3 产业的研究与创新主要集中在增强拜占庭容错（BFT）共识机制的性能上，例如近期的研究 Shoal、Shoal++ 和 Mysticeti。然而，交易生命周期包括除了共识之外的更多阶段：客户端、全节点和验证者之间的通信、区块执行、最终执行状态的认证、将结果持久化到存储中，以及将结果返回给客户端的通信。实际上，现代共识系统通常在低负载下需要大约 300–400 毫秒的时间来排序一笔交易。然而，即使是 最快的区块链，其端到端延迟也在一秒左右，并且随着负载的增加而大幅上升。

为了解决减少端到端区块链延迟的挑战，我们将研究重心放在了 架构改进 上。今天我们介绍 Zaptos，这是一种旨在尽可能减少端到端延迟的并行流水线架构，同时保持高吞吐量。

Zaptos 在共识延迟普遍情况下影影位置中，影影了区块执行、状态认证和存储阶段。这意味着在区块被排序时，区块已经被执行，其最终状态已被认证并持久化。特别是，在这种情况下，Zaptos 的端到端延迟等于

客户端-验证者通信延迟 + 共识延迟

由于客户端-验证者通信延迟是不可避免的，当共识延迟达到最优时，Zaptos 实现了最佳的端到端区块链延迟。

现有区块链架构

现有的区块链流水线架构可以根据其流水线阶段之间的交互分为三大类：耦合共识执行、执行后共识以及共识后执行。在后两类中，共识和执行被解耦为单独的阶段。

图 1. 耦合共识执行流水线架构的示意图。

在耦合共识执行架构中，共识阶段与区块的执行紧密结合，此阶段在共识期间决定新的区块链状态。例如，在基于领导者的协议中，验证者在领导者提出后执行区块，并在共识协议中对生成的新区块链状态进行投票。共识阶段的输出包括最终状态。使用该架构的典型链包括比特币、以太坊 PoS、Solana、Algorand、Cosmos、Redbelly、NEAR、XRP 和 Stellar。

图 2. 执行后共识流水线架构的示意图。

执行后共识架构首先在 HyperLedger 中提出。验证者首先在本地执行交易列表，产生执行输出。然后将这些输出提交给共识过程，以一致其排序并因此产生新的区块链状态。

图 3. 共识后执行流水线架构的示意图。当与流水线共识协议结合时，该架构有效地成为 Aptos 的流水线架构。

在共识后执行架构中，验证者最初对扩展区块链的新区块达成共识。之后按照顺序执行该区块，产生更新后的区块链状态。为了生成公开可验证的新区块链状态证明，并避免因非确定性执行引发的安全性违反，在存储之前引入了一个认证阶段。使用该架构的典型链包括 Aptos 和 Sui，而 Avalanche 目前正在实施它。

Aptos 区块链的流水线架构

Aptos 是自 2021 年以来第一个采用 流水线架构 的区块链，允许不同区块的不同阶段并行执行。此设计通过最大限度地利用资源来提高区块链性能。

架构

图 4. Aptos 流水线架构示意图。图中显示了客户端 C_i、全节点 F_i 和验证者 V_i。每个框代表区块链中一笔交易区块在从左到右的传递过程中需要经过的阶段。该流水线包含四个阶段，包括共识（包含传播和排序）、执行、认证和提交。

我们通过追踪交易（txn）的生命周期描述当前的 Aptos 架构。客户端可以将 txn 提交给它所连接的全节点（以防止 DDoS 攻击）。全节点收到 txn 后，将其转发给它所连接的验证者。

• 共识阶段： 验证者首先运行共识协议来达成包括 txn 的区块。此过程通常包括两个子阶段：传播阶段，在该阶段验证者分发负载批次，以及排序阶段，在该阶段验证者一致区块中包含这些负载批次的元数据的排序。该阶段需要大量网络带宽。
• 执行阶段： 当存在一个已排序的未执行区块且其上一个区块已执行时，验证者执行该区块。该阶段需要大量 CPU 资源。
• 认证阶段： 执行后，验证者签名执行状态的加密摘要并广播签名。当收到对同一状态的法定签名的时，验证者聚合这些签名以认证该状态。该阶段只使用少量计算或带宽资源，但是需要一轮时间来从法定验证者那里获取签名。
• 提交阶段： 如果新的认证区块是接下来要提交的最高高度的区块，验证者则更新已提交的最高高度和区块链状态，并将两者存储到存储中。该阶段需要大量存储 IO 资源。当提交完成后，验证者将新提交的区块发送给全节点。

全节点在接收到来自验证者的提交区块时，确保状态已被认证，并将区块添加到其流水线。全节点的流水线与验证者类似，但没有认证阶段或共识。客户端可以查询 txn 是否在区块链上已提交。全节点在接收到客户端有关 txn 的查询后，将根据最新的区块链状态响应 txn 是否已在某个位置提交。如果客户端在超时内收到响应，则会验证该证明是否对 txn 有效，并分别返回成功或失败。如果客户端失败或超时，可以重新提交交易。

流水线

图 5. Zaptos 流水线架构中连续区块流水线的示意图。

如图所示，流水线设计通过充分利用验证者和全节点的不同资源，实现了高区块链吞吐量。在 Aptos 中，验证者可以流水线不同连续区块的不同阶段（例如，区块 B_1、B_2、B_3），并且验证者可以并行执行提交阶段（IO 密集型）B_1、B_2的认证阶段、B_3 的执行阶段（CPU 密集型），以及后续区块的共识阶段（网络密集型）。在实际中，各阶段的持续时间可能会有所不同，但只要并行阶段利用不同资源，流水线就能通过最大化资源利用率来改善吞吐量，相较于非流水线设计。

Zaptos

Zaptos 通过三关键优化显著减少了 Aptos 流水线架构的端到端延迟，同时保持最大程度利用资源以实现高吞吐量的特性。

图 6. Zaptos 示意图。

• 乐观执行： 此优化通过乐观地运行执行阶段改善了验证者和全节点的流水线延迟。当任何验证者在共识中收到区块提案时，验证者立即将该区块添加到流水线，而不是等待其排序。然后，验证者可以在父区块执行完成后进行推测性执行。验证者还将提案发送给订阅验证者的全节点。同样，全节点也执行乐观执行，以验证从验证者接收到的状态证明。
• 乐观提交： 第二个优化通过允许区块在执行阶段完成后立即乐观地提交到存储来减少验证者和全节点的提交阶段延迟，但在状态认证之前。验证者在认证状态的过程中，仅需要最小更新以完成提交阶段。在未最终被共识排序的乐观提交区块情况下，乐观提交的状态将因数据一致性被从存储中回滚。
• 将状态认证依附于共识： 最后一个优化进一步通过允许验证者提前开始已执行区块的认证阶段来改善验证者的流水线延迟，而不是 等待区块排序。这使得验证者可以与最后一轮共识并行运行认证阶段，有效减少共识情况下流水线延迟一轮。

通过这些关键优化，Zaptos显著降低流水线延迟，同时最大限度地利用资源以实现高吞吐量。

图 7. Zaptos 中连续区块流水线的示意图。左侧图示例了流水线，在其中验证者还可以流水线不同连续区块的不同阶段。右侧图示例了连续区块的各阶段之间的依赖关系，例如，区块 B_2 的执行与提交阶段也分别依赖于其父区块 B_1 的执行和提交阶段。

评估

我们使用地理分布实验评估 Zaptos 的端到端性能，以 Aptos 作为高性能基线。更多评估细节请查看 论文。

我们使用 Google Cloud 模拟全球去中心化网络的部署。我们的测试平台由100个验证者和30个全节点组成，覆盖10个全球地区，机器规范类似于 Aptos 所使用的商品级规范。

吞吐量-延迟

图 8. Zaptos 和基准 (Aptos Blockchain) 的典型性能。

上图展示了 Zaptos 和 Aptos 的 吞吐量-延迟 图。正如所示，两种系统的延迟随系统负载增长逐渐增加，并在达到最大容量时急剧上升。与基准相比，Zaptos 在低负载下显著减少延迟 160 毫秒，在高负载下超过 500 毫秒。

值得注意的是，Zaptos 在 20k TPS 的生产级实现下，达到了低于一秒的端到端区块链延迟，并在现实的类似主网环境中进行了测试。这是当前区块链系统中罕见的突破性组合，释放了对区块链在速度和可扩展性上同时满足现实应用需求的潜力。

延迟分析

图 9. Aptos Blockchain 的典型延迟分析。

图 10. Zaptos 的典型延迟分析。

延迟分析图显示了验证者和全节点每个流水线阶段的持续时间。为进一步分析系统性能，我们提供了通过 吞吐量-延迟 图的数据点的详细延迟分析：

• Zaptos 的端到端区块链延迟大约等于共识延迟，最多到 10k TPS。在此范围内，验证者和全节点的乐观执行、认证和乐观提交阶段在共识阶段内实际上是“影影位置”的。这验证了 Zaptos 设计朝着实现最佳区块链延迟迈出了一步。
• 随着 TPS 增加，非共识阶段不再完全影影位置于共识阶段。这主要是由于需要等待或获取更大区块而增加的执行准备以及乐观执行阶段持续时间的延长。尽管在最大吞吐量下，阶段存在部分重叠，但 Zaptos 通过影影位置大多数阶段的方法显著降低了延迟。例如，在 20k TPS 时，Aptos 的总延迟为 1.32 秒（共识延迟：0.68 秒；其他阶段：0.64 秒），而 Zaptos 则将其降低至 0.78 秒（共识延迟：0.67 秒；其他阶段：0.11 秒）。
• 在高负载下，共识传播延迟仍然是端到端区块链延迟的瓶颈。进一步提高传播延迟是未来研究的一个有趣挑战。

结论

Zaptos 是一种新颖的区块链流水线架构，通过有效的流水线设计实现低延迟和高吞吐量，以最大限度地利用资源。欲了解更多详细信息，请查看 Zaptos 论文。

• 原文链接： medium.com/aptoslabs/zap...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～