共识存储：Aptos区块链上共识如何横向扩展

Quorum Store：如何在 Aptos 区块链上实现共识水平扩展

作者 Brian Cho 和 Alexander Spiegelman

简要说明

• Aptos Labs 推出了 Quorum Store，这是第一个部署的 Narwhal 实现。
• Quorum Store 通过消除领导者瓶颈显著改善了共识吞吐量。
• Quorum Store 将数据传播与元数据排序解耦，允许验证者并行异步传播数据。
• Quorum Store 的压力测试表明，在仅共识测试和端到端处理中的 TPS 分别提高了 12 倍和 3 倍。

Aptos Labs 很高兴宣布 Quorum Store，这是第一个部署的 Narwhal 实现。Quorum Store 通过消除领导者瓶颈显著改善了共识吞吐量。Quorum Store 不再依赖单一领导者广播大量数据作为共识协议的一部分，而是将数据传播与元数据排序解耦，允许验证者异步并行传播数据。

区块链共识中的瓶颈

目前大多数已部署的区块链实现了基于领导者的共识。在这些协议中，领导者推动进展，并负责传播用户交易作为共识提案的一部分。因此，领导者的资源不断被过度利用，而其余验证者大多处于闲置状态。这意味着整个系统的吞吐量受到领导者广播数据能力的制约。请注意，轮换领导者并不能解决这个问题，因为这只是将瓶颈从一个领导者转移到下一个。

图 1：基于领导者的共识与无 Quorum Store 的资源利用率比较图。

Narwhal：将数据传播与共识解耦

正如在 Narwhal 中首次观察到的，数据传播可以并且应该与共识逻辑解耦。Narwhal 背后的关键思想是，验证者可以持续并行地向彼此流传一批批交易。然后，当领导者在共识中提出区块时，他们指定要包含在区块中的（之前共享的）批次集合。这减少了在每个区块提案中需要共享的数据量，因为领导者不需要列出并发送每个区块中的交易，而只是需要指定批次标识符（元数据）。

假设一个验证者每秒可以广播 T 笔交易。那么，任何基于领导者的共识的吞吐量都受到 T 的限制。然而，使用 Quorum Store，n 个验证者每秒可以广播 nT 笔交易，从而相应地提高共识吞吐量的上限。

与之前一样，共识逻辑负责提供交易的总排序。然而，使用 Quorum Store，领导者只需在其提案中包含元数据。这些元数据在共识中被排序，并在执行之前映射到相应的交易批次。结果是，高负载下的共识延迟和吞吐量显著改善。此外，共识协议的消息复杂度对整体性能的重要性大大降低。因此，在低延迟和低通信成本之间的权衡中，Jolteon 被用来将 Hotstuff 延迟提高 33%。

通过可用性证明确保活性

将数据传播与元数据排序解耦的微妙之处在于确保所有验证者拥有执行所需的交易。例如，如果一个恶意的验证者将数据发送给某些验证者而不是其他人，并且与该数据对应的元数据通过共识进行排序，那么所有诚实的验证者都必须能够检索该数据。

为此，Quorum Store 提供了 可用性证明，确保证明背后的数据将在系统中保持可用，直至其中指定的到期时间。

架构概述

以下是高层验证者流水线架构的概述，涵盖以下四个组件：

1. Mempool 负责保存潜在用户交易的集合
2. Quorum Store 的核心功能是从 Mempool 拉取交易批次，广播它们，并形成其可用性证明
3. 共识从 Quorum Store 拉取证明，对其进行排序，然后推送到执行
4. 执行使用 Quorum Store 将证明映射到交易批次并执行它们

图 2：验证者流水线架构

上线就绪

该实现已在去中心化网络环境中进行了测试，覆盖 100 个验证者，分布在 30 多个不同国家，并对网络进行了压力测试，以确认低延迟、高吞吐量和健康的Gas市场费用。在我们的仅共识测试（无执行）和端到端处理中的 TPS 分别取得了 12 倍和 3 倍的改进。请查看 我们可重复的性能基准测试，了解如何验证这些端到端结果的详细信息。

有趣的是，即使 Quorum Store 增加了往返时间，但在高负载下端到端延迟却有所改善。因为消除领导者瓶颈在这种情况下显著减少了共识延迟。

扩展共识

Quorum Store 的一个重大好处是它允许水平扩展。数据传播本质上是可并行化的，这意味着它可以随着更多硬件的增加而线性扩展。要扩展共识，我们只需要添加更多机器来运行 Quorum Store。目前，每个验证者运行一台机器。相反，每个验证者可以运行几台机器，一台运行共识以排序证明，其他机器以并行方式运行 Quorum Store。请查看 Narwhal 的图 7，查看在机器数量达到 600k TPS 的线性扩展实验。

协议与实现

现在强调一下协议和一些考虑的实际因素。为提高可读性，一些优化和实现细节被省略。简而言之，为了形成可用性证明，所有验证者并行重复以下操作：

1. 从 mempool 中拉取交易。
2. 根据其Gas价格将交易整理成批次，然后选择每个批次的到期时间。
3. 将交易批次广播到所有其他验证者。
4. 持久化接收到的批次，签名其摘要，并发送回签名。
5. 收集签名的法定人数来形成可用性证明。

图 3：可用性证明协议

签名

当验证者签署一个批次时，它承诺在指定的到期时间之前持久化该批次，并回复其他验证者关于缺失批次的请求。

证明保证

一个批次的可用性证明是法定人数的加权 2f+1 签名。有效证明保证至少加权 f+1 的诚实验证者提供了签名。这意味着至少加权 f+1 的诚实验证者将持久化该批次直至到期。因此，证明保证非过期批次将在系统中可用，任何缺失数据的验证者都可以从其他诚实验证者获取。

获取数据

在经过共识排序后，证明被推送到执行。在此时，执行请求 Quorum Store 将证明映射到其相应的交易。在常见的情况下，Quorum Store 将在本地存储交易，因为诚实的批次创建者会将其广播给所有人。然而，在最坏的情况下，Quorum Store 将需要从远程验证者处获取交易。可用性证明保证了足够的远程验证者存储数据，但如果执行不当，可能会增加延迟。为此，我们实施了一个优化，即一旦首次看到包含证明的共识区块，就预先获取远程数据。这样，当区块被排序时，Quorum Store 已经在本地存储了交易。

负载均衡

Quorum Store 完美地实现了负载均衡。由于所有验证者并行广播批次并聚合同步证明，因此资源利用率在验证者之间是均等的，从而以网络速度进行数据传播。请注意，由于所有验证者都必须获得所有批次以执行，因此上述“天真的”获取机制是最优的。其他加密工具如纠删码用于传播和获取/重建数据，只会增加复杂性，并未在负载均衡方面带来好处。

反压

多亏了 Quorum Store，现今共识是我们流水线架构中性能最优的组件。为了防止其淹没系统中的其他组件，每个验证者根据积压情况调整其本地批次创建速率，类似经典拥塞控制系统如 TCP。此外，共识还对不同验证者创建的批次施加公平性，以确保验证者获得公平的区块空间份额。

内存缓存

从持久存储（例如硬盘）读取批次可能代价昂贵。我们实现了一个并发内存缓存，允许执行并行地从 Quorum Store 读取数据。缓存包含一部分 Quorum Store 在存储中持久化的批次。

配额

为防止 DDoS 攻击，对内存缓存和存储都强制执行一个配额。在签署和持久化来自验证者 v 的批次之前，验证者检查 v 的内存和存储余额。如果两者余额都正常，批次就会持久化到存储并存储在缓存中。否则，可能会持久化或被忽略，具体取决于存储余额。

垃圾回收

为了确保诚实验证者不会超过其配额，我们对过期批次进行垃圾回收。为了保证活性，我们需要对每个有序批次 b，诚实的验证者能够 (1) 获取 b 的交易并执行它，或者 (2) 同步到包含它们的状态。为此，过期批次会根据已提交区块中的时间戳进行清理。当验证者获得表明大多数验证者执行了该区块的法定书证时，就会提交一个区块。这些法定书证用于状态同步，以说服验证者该状态有效。因此，如果某个验证者无法获取一个批次，因为所有诚实验证者都已进行过期批次的垃圾回收，便可以确保有足够的诚实验证者执行了该批次，并且拥有对应状态同步的法定书证。

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