Aptos 状态同步的演进：通往每秒超过10万笔交易、延迟不足一秒的道路…

Aptos 状态同步的演变：

达到每秒超过 100,000 笔交易的路径，延迟低于一秒

作者 Joshua Lind

摘要：Aptos 区块链利用多种新颖技术确保高吞吐量、低延迟、已验证的状态同步。在 Aptos，节点今天可以以低于一秒的延迟验证和同步超过 10,000 笔交易（TPS），而且我们已经在朝着 100,000+ TPS 的目标前进。

概述

状态同步（或状态 sync）是区块链设计中一个重要但常常被忽视的方面。在本文中，我们讨论了 Aptos 状态同步的演变，并呈现了最新状态同步协议设计背后的几个关键见解。我们进一步探讨了如何最近将状态同步的吞吐量提高了 10 倍，延迟减少了 3 倍，并继续为更快速、更高效的区块链同步铺平道路。

什么是状态同步？

如今大多数区块链都是层次化结构，网络的核心有一组活跃的验证者。验证者通过执行交易、产生区块并达成共识来扩展区块链。网络中其余的节点（例如，完整节点和客户端）则复制由验证者生成的区块链数据（例如，区块和交易）。状态同步是允许非验证者节点分发、验证和持久化这些区块链数据的协议，并确保生态系统中的所有节点保持同步。请参见下面的图表了解 Aptos 的工作方式。

Aptos 生态系统（概述）

为什么状态同步很重要？

在评估区块链时，状态同步很少被提及：它通常是白皮书中专注于更有趣主题的脚注。然而，状态同步对区块链的性能、安全性和用户体验有着显著影响。请考虑以下几点：

1. 最终确认时间和用户体验： 当新交易由验证者执行时，状态同步负责将数据传播给节点和客户端。如果状态同步较慢或不可靠，节点将感受到交易处理的延迟，从而人为地拉长最终确认时间。这对用户体验有巨大影响，例如去中心化应用（dApps）、去中心化交易所（DEXs）和支付处理的速度都将变得更慢。
2. 与共识的关系： 崩溃或落后的验证者依赖状态同步将其赶上（即同步最新的区块链状态）。如果状态同步无法按共识执行的速度处理交易，崩溃的验证者将无法恢复。而且，新验证者将永远无法开始参与共识（因为他们永远无法跟上！），完整节点将无法同步到最新状态（它们将继续落后！）。
3. 去中心化的影响： 拥有快速、高效和可扩展的状态同步协议允许：（i）验证者集的快速轮换，使验证者可以更自由地进出共识；（ii）网络中可供选择的潜在验证者更多；（iii）更多的完整节点能够迅速上线，而不必等待很长时间；（iv）更低的资源要求，增加异构性。所有这些因素都提高了网络的去中心化，并帮助扩大区块链的规模和地理覆盖。
4. 数据正确性： 状态同步负责在同步过程中验证所有区块链数据的正确性。这防止了恶意节点和对手在网络中修改、审查或伪造交易数据并将其呈现为有效。如果状态同步未能成功进行（或错误地进行），完整节点和客户端可能会被欺骗，从而接受无效数据，这将对网络造成灾难性后果。

理解状态同步

为了更好地理解状态同步，我们首先介绍一个通用的区块链执行模型。虽然该模型专门针对 Aptos 区块链，但可以推广到其他区块链。

我们将 Aptos 区块链建模为一个简单的版本数据库，其中每个版本 V 都有一个唯一的区块链状态 Sⱽ，包含所有链上账户和资源。一个事务 T 可以由 Aptos 虚拟机（VM）在状态 Sⱽ 上执行，以生成表示对状态 Sⱽ 的所有状态修改的状态增量 Dᵀᵥ，如果 T 被提交。当 Dᵀᵥ 被应用到 Sⱽ 时（即，我们认为 T 已提交），会产生一个新版本 V+1 和新的区块链状态 Sⱽ⁺¹。我们将第一状态称为基元状态 S⁰。下面的图表展示了事务执行和状态增量应用。

事务执行和状态增量应用（模型）

目标是什么？

有了通用模型，我们现在可以定义状态同步的几个基本目标**：

1. 高吞吐量： 状态同步应该最大化每个节点每秒能同步的交易数量。即，最大化每个由验证者提交的 T 从 Sⱽ 到 Sⱽ⁺¹ 前的状态转移率。如果吞吐量低，就会增加同步时间，并成为网络的瓶颈。
2. 低延迟： 状态同步应该最小化最新的节点同步验证者提交的新交易所需的时间。即，最小化处于 Sⱽ 的节点同步到 Sⱽ⁺¹ 每次验证者新提交的 T 所需的时间。这会影响客户端感知的整体最终确认时间。
3. 快速引导时间： 状态同步应最小化新（或崩溃）节点同步到区块链的最新状态所需的时间。即，最小化同步到 Sⱽ（即 V 是验证者达成一致的最高数据库版本）所需的时间，而不考虑节点的当前版本 P 和状态 Sᴾ。这允许节点更快地执行有用的工作（例如，响应余额查询或验证交易）。
4. 抵抗故障和恶意行为者： 状态同步应抵抗故障（例如，机器和网络故障）并容忍网络中的恶意行为者，包括其他节点。这意味着必须克服各种攻击，例如伪造的交易数据、修改或重放的网络消息，以及 eclipse 攻击。
5. 容忍资源限制和异构性： 状态同步应能容忍资源限制（例如，CPU、内存和存储）并接受异构性。考虑到去中心化网络的特性，节点将使用不同类型的硬件，并优化不同的目标。状态同步应考虑到这一点。

所需的构建模块

接下来，我们介绍构建状态同步协议所需的一组基础构建模块。为简洁起见，我们在下面提供每个构建模块的总结，并将技术细节推迟到未来的工作中（这些都可以是单独的博客文章！）：

1. 持久存储： 为了在机器崩溃和故障期间持久存储数据（并向其他节点分发数据！），我们要求每个节点访问可靠的持久存储。在 Aptos，我们目前使用 RocksDB，但正积极探索其他选择。
2. 可验证的区块链数据： 为防止恶意行为者修改区块链数据，我们要求数据经过身份验证并且是可验证的。具体来说，我们需要能够证明： (i) 每个由验证者执行和提交的事务 T；(ii) 每个由验证者执行和提交的事务 T 的顺序；和 (iii) 提交每个事务 T 后的区块链状态 Sⱽ。在 Aptos，我们通过以下方式实现： (i) 构建 merkle 树 来证明已提交的交易和结果区块链状态；和 (ii) 让验证者签署这些树的 merkle 根以进行身份验证。
3. 信任根： 考虑到 Aptos 支持动态验证者集（即在每个纪元中更改验证者），节点需要能够从 Aptos 区块链的经过验证历史中识别当前的验证者集。我们通过以下方式实现： (i) 由 Aptos 验证的 genesis blob，识别第一个验证者集和初始区块链状态 S⁰；和 (ii) 近期 可信的节点（例如，当前验证者集和区块链状态 Sⱽ 的哈希值）。合在一起，genesis blob 和节点形成一个信任根，使节点能够同步真实的 Aptos 区块链，并防止攻击（例如，长线攻击）。

达到 1k TPS：一种简单的方法

利用上面提出的模型和构建模块，我们现在可以展示一种简单的状态同步协议。该协议是 Aptos 原协议（即，state sync v1）的简化版本。

该协议的工作流程如下：（i）Alice（同步节点）识别出最高的本地持久化区块链版本 V 和状态 Sⱽ。如果不存在，Alice 使用创世状态，即 S⁰；（ii）Alice 随机选择一个节点 Bob，请求验证者已提交的任何新的顺序交易；（iii）如果 Alice 收到来自 Bob 的响应，Alice 将验证新交易 (T⁰ 到 Tᴺ) 并执行它们以生成状态增量（D⁰ᵥ 到 Dᵀᵥ ₊ₙ）；（iv）Alice 随后将新的状态增量和新交易应用于存储，将区块链的本地状态从 Sⱽ 更新为 Sⱽ⁺¹⁺ᴺ。Alice 无限重复这循环。该协议的伪代码如下：

状态同步 v1（伪代码）

我们在 Aptos 实现了该协议，并在 devnet 上进行了基准测试和分析。我们注意到的一些关键观察包括：

1. 吞吐量受网络延迟限制： 该协议实现的最大吞吐量为 ~1.2k TPS。然而，由于 Alice 顺序请求数据并且必须等待节点的响应，因此吞吐量受网络延迟显著影响。鉴于我们在 devnet 中观察到的平均网络往返时延（RTT）为 150ms，这不是一个最佳方案。
2. CPU 主要被执行占用： 当 Alice 接收到要同步的新交易集时，我们发现 55% 的 CPU 时间用于执行这些交易，而 40% 的时间用于验证数据、将状态增量应用于存储，并持久化新交易。其余的 5% 用于消息处理、序列化和其他任务。
3. 延迟较高： 在网络达到最大负载时，Alice 接收新交易的平均延迟为 ~900 ms，这主要是因为 Alice 在请求数据时随机选择节点，并没有考虑网络拓扑：靠近验证者的节点会更快地接收到新交易。
4. 引导速度较慢： 上述协议要求 Alice 从创世状态开始重放和同步所有交易。如果 Alice 距离最新状态较远，她必须等待很长时间才能执行有用操作（这可能需要几个小时甚至几天！）。
5. 性能容易受到操控： 该协议的性能受到恶意节点的严重影响。如上文所述，故意慢速（或无响应）的节点将迫使 Alice 在等待数据时花费长时间，而无所事事。因此，显著增加了同步时间。
6. 资源使用高： 该协议对所有资源类型的成本较高：（i）CPU 使用高，因为 Alice 必须重新执行所有交易；（ii）存储使用高，因为 Alice 必须持久化从创世以来的所有交易和区块链状态；（iii）网络使用高，因为 Alice 必须通过网络接收自创世以来的所有交易。这自动增加了高成本和资源需求，降低了异构性。
7. 资源浪费： 当 Alice 同步新数据时，网络中的其他节点也在从她那里进行同步。随着请求数据的节点数量增加，存储和 CPU 需要处理这些请求的附加读取负载增加。然而，Alice 处理这些请求时执行的许多计算是无用的，因为节点通常会请求相同的数据。

达到 10k TPS：一种优化的方法

针对上述简单协议，我们可以进行多项修改以帮助解决其局限性。首先，我们扩展协议以支持另外 2 种同步模式：

1. 状态增量同步： 鉴于验证者已执行交易并通过 merkle 证明认可生成的区块链状态，节点可以依赖验证者生成的状态增量来跳过交易执行。这可以避免： (i) 执行的高成本，使 CPU 时间缩短约 55%； (ii) 不需要使用 Aptos VM，从而大大简化状态增量同步的实现。结果，节点现在可以通过下载每个交易 T 和状态增量 Dᵀᵥ 并将其应用于存储来生成新的状态 Sⱽ⁺¹。我们注意到这会增加网络使用（约 2.5x）。
2. 区块链快照同步： 鉴于验证者认可每个区块链状态 Sⱽ，我们可以通过允许节点直接下载最新的区块链状态来进一步缩短引导时间（而不是必须通过交易或者状态增量生成）。这显著减少了引导时间，并且与以太坊的 snap-sync 方法相似。其权衡是节点不会存储任何 Sⱽ 之前的交易或区块链状态。

接下来，我们实现了一系列通用优化和其他功能，以改进性能和可扩展性：

1. 数据预取： 为了防止网络延迟影响吞吐量，我们可以执行数据预取。在处理数据之前，节点可以从其他节点预取交易数据（例如，交易和状态增量），以摊销网络延迟。
2. 管道执行与存储： 为进一步增加同步吞吐量，我们可以将交易执行与存储持久化分离并使用管道化：这是处理器设计中常用的 优化方法。这允许在将交易 T² 执行的同时，将交易 T¹ 和状态增量 Dᵀ¹ᵥ 同时持久化到存储中。
3. 节点监控与信誉： 为提高可观察性和更好地容忍恶意节点，我们可以实施节点监控服务来：（i）监控节点的恶意行为（例如，传输无效数据）；（ii）识别关于每个节点的元数据，例如节点拥有的所有交易数据的摘要及其与验证者集的感知距离；（iii）维护每个节点的本地得分。这些信息可以用于优化请求新区块链数据时的节点选择。
4. 数据缓存： 为减少存储的读取负载并防止状态同步在越来越多的节点同步时进行冗余计算，我们可以实现一个数据缓存，在内存中存储常请求的数据项及响应。
5. 存储修剪： 为了防止存储随时间持续增长（例如，在更多交易提交时），我们还可以实施动态修剪器，从存储中移除不必要的交易和区块链数据，例如，几天、几周或几个月之前的数据，具体取决于节点配置。

我们实现了这些修改，并产生了新的状态同步协议（即，state sync v2）。我们在 devnet 上对其进行了基准测试并获得了以下观察结果：

1. 吞吐量增加了 5 倍至 10 倍： 在执行交易时（没有 并行执行），该协议现在实现的最大吞吐量为 ~4.5k TPS，其主要原因是管道化和数据预取（即，该协议现在能够充分利用 CPU）。在同步状态增量时，协议的吞吐量超出了 10K TPS，这进一步得益于避免交易执行。在这两种情况下，吞吐量不再受网络延迟影响。
2. 延迟减少了 3 倍： 在网络达到最大负载时，我们现在观察到 Alice 接收到新交易的平均延迟为 ~300 ms，这是由于数据预取和更高效的节点选择：更有响应且靠近验证者的节点更频繁地被联系。
3. 引导速度显著加快： 使用区块链快照同步的节点能够更快地启动。此外，引导时间不再受区块链长度（即，交易数量）的影响，而是受要同步的链上资源数量的影响。目前在 devnet 中，节点能够在数分钟内快速引导***。
4. 资源需求减少： 随着多种同步模式和存储修剪的实施，资源需求已降低。此外，节点在选择同步策略时现在支持异构性。例如：（i）资源有限的节点可以跳过交易执行；（ii）存储有限的节点可以配置修剪器以采取激进策略；（iii）希望快速更新的节点可以实施区块链快照同步。
5. 资源使用更高效： 在处理来自节点的同步请求时，我们看到存储的读取负载大幅降低，CPU 使用更少的冗余。这得益于新的数据缓存在内存中存储常请求的数据项及响应。我们还观察到，随着在 devnet 中同步节点的数量增加，数据缓存的效率更高，例如，在 20 个同步节点时，我们看到每个请求的缓存命中率为 70%-80%。而在 60 个节点时，缓存命中率为 93%-98%。这额外使用了 ~150 MB 的 RAM 来维持缓存。

100k TPS 及以后？

虽然我们已经将吞吐量提高了 10 倍，延迟减少了 3 倍，但我们意识到仍有更多工作要做。特别是如果我们想匹配 Block-STM，并使 Aptos 成为所有人的第一层！

那么，我们将如何达到这一目标？好吧，我们已经开始了下一个状态同步目标：100k+ TPS！虽然我们计划将细节留到未来的博客文章中，但我们确实想向非常渴望的读者提供一些提示：

1. 交易批量处理： 目前，Aptos 将每笔交易视为可验证的，即用于验证和确认数据的 merkle 证明在交易粒度上操作。这使得验证和存储成本非常高。避免这种情况的一种方法是采用交易批量处理，即对批次（或区块！）交易进行证明。
2. 网络压缩： 网络带宽往往成为点对点网络的瓶颈，而 Aptos 也不例外。目前，状态同步预取器在 devnet中能够获取约 ~45K TPS 的吞吐量，然后便饱和了带宽。如果我们想扩展，这就是个问题。幸运的是，我们已经意识到节点使用低效的序列化格式分发数据，并通过使用现成的压缩技术，我们可以将传输的数据量减少超过 10x。
3. 更快的存储写入： 目前，状态同步的吞吐量受到持久化区块链数据到存储所需时间的制约。我们正在积极寻找可以消除这一瓶颈的不同优化和改进，包括：（i）更高效的数据结构；（ii）更优的存储配置；和（iii）替代存储引擎。
4. 并行数据处理： 到目前为止，我们要求状态同步按照顺序处理数据（例如，顺序处理逐渐增加的版本中的交易）。但是，有多种现有方法可以允许我们避免这一要求，并利用并行数据处理显著提高吞吐量，例如，区块链分片！

下次见！

如果你像我们一样，对设计算法、将其付诸实践并对 Web3 的未来产生实际影响充满热情，请联系—我们在 Aptos 正在扩招。 正在招聘

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