Aptos Shardines 打破极限，实现 100 万 TPS！

By Manu Dhundi, Sital Kedia, Igor Kabiljo, Zhoujun Ma, Jan Olkowski

内容概要：

我们很兴奋地推出 Shardines，它是区块链执行引擎的又一次进化，旨在实现横向扩展并达到每秒 100 万笔以上交易（TPS）。这一成果是区块链行业的重要里程碑，证明了我们的架构有能力满足 Web3 应用程序不断增长的需求，并支持全球范围内的创新。

区块链执行引擎能够独立于共识机制和存储进行扩展。这使得验证者运营商可以优化资源，提升系统灵活性。

Shardines 采用了前沿的动态分区器，将跨分片网络通信和等待时间减到最少，能够无缝适应不断变化的工作负载。

一种创新的 “微批处理与流水线” 策略通过分摊成本，进一步减轻网络延迟的影响，确保高性能。

Aptos 始终致力于提供开源且可验证的性能结果，以促进 Web3 的透明度。我们已开源了 Shardines 完全可重现的基准测试，供区块链爱好者验证结果。

长期以来，可扩展性一直是区块链面临的关键挑战。随着Web3的普及以及用例的不断拓展，传统区块链常常在吞吐量（以每秒交易数衡量）上遭遇瓶颈，进而导致高延迟和高昂的燃气费。像以太坊这样的第一代区块链，通过采用单线程执行模型开创了Web3的先河，但这将吞吐量限制在了仅每秒15笔交易，事实证明这是一个重大瓶颈。为应对以太坊的可扩展性挑战，像Aptos和Solana这样的下一代区块链采用了并行执行模型。在Aptos上，我们有Block – STM，这是一种高效的、多线程的、基于内存的并行执行引擎，它利用软件事务内存技术结合乐观并发控制。Block – STM为并行交易执行设定了行业标准，促使其他几条链也采用了类似方法。 如今，我们很高兴推出Shardines，这是旨在实现横向可扩展性的区块链执行引擎的又一次进化。借助Shardines，我们能够实现近乎线性的吞吐量扩展，在我们由30台机器组成的集群上，吞吐量超过每秒100万笔交易。这一里程碑并非终点，而是向前迈出的关键一步，展示了一种准备好支持全球规模应用以及满足Web3不断演变需求的区块链架构。

区块链的扩展 一个典型的区块链架构由三个主要部分组成：共识、执行和存储。 共识层接收传入的交易，并负责确保网络内所有节点就交易的特定顺序达成一致。 执行层获取当前状态以及经共识达成一致的传入交易，负责处理智能合约并执行交易。 存储层负责持久化与区块链相关的所有数据，包括账本状态以及任何相关的智能合约数据。它将当前状态提供给执行层，并根据执行结果更新状态。 为实现横向扩展性，我们的设想是对这些组件进行独立的分片和扩展。也就是说，共识层可通过增加数据分发服务分片的数量来扩展，这与执行和存储分片的数量无关。同样，如果执行成为瓶颈，可以通过增加更多CPU核心来扩展，而无需增加存储容量和数据分发服务容量。此外，这些分片服务被设计为逻辑服务，与物理机器布局解耦。这种解耦使验证节点运营商能够灵活选择机器类型，在优化资源利用的同时增强系统弹性。

### 共识 我们基于Narwhal的仲裁存储（Quorum Store）的实现，展示了如何通过增加节点来提升带宽，从而实现共识的扩展。仲裁存储将数据分发与元数据排序解耦，这使得数据分发能够进行横向扩展。上述架构展示了多个数据分发分片，它们负责将交易数据分发给其他验证者，并获取存储证书证明。共识协调器负责对元数据进行排序——由于元数据比交易数据小几个数量级，这使得共识能够扩展以支持非常高的吞吐量，而不会成为瓶颈。

### 存储 Aptos采用水母默克尔树（Jellyfish Merkle Tree，JMT）设计来存储区块链状态。JMT是一种空间和计算效率高的稀疏默克尔树，针对基于日志结构合并树（Log – Structured Merge – tree，LSM – tree）的键值存储（如RocksDB）进行了优化。概括来说，对存储进行分片意味着对用于状态存储的JMT进行分片。我们已经实现了JMT数据结构的分片，并且最近在主网的单个节点内将分片部署到生产环境中。由于JMT的设计确保了键值对的均匀分布，这种分片技术保证了负载在不同分片之间均匀分配。

### 执行 执行本质上受限于CPU，由于可用核心数量有限，通过提升单台机器性能来提高每秒交易数（TPS）存在严格限制。因此，跨多台机器进行扩展成为唯一可行的解决方案。 大多数现有的区块链分片解决方案，包括二层扩展（L2 rollups），都将执行和存储在单台机器上紧密耦合。虽然这种方法看似具有很强的可扩展性，但由于没有单一的共享状态，会导致用户体验欠佳以及碎片化问题。我们扩展执行的方法是将其与存储解耦，使两者能够独立扩展。实际上，我们认为在任何实际的分片区块链系统中，都不可能实现执行与数据100% 的共置。获取与执行不共置的数据总会产生成本。为解决这一问题，我们采用了动态分区器和一种新颖的 “微批处理与流水线” 策略（稍后将详细讨论这两者），以分摊远程存储读取成本，确保高效运行。

#### 分片执行中的冲突处理 区块链执行扩展的主要挑战之一是处理跨交易的读写冲突。当一个区块中的一笔交易（例如T2）读取的状态被该区块中的另一笔交易（例如T1）修改时，就会发生读写冲突。

在共享状态上存在冲突的交易对性能构成重大挑战，因为它们无法并行执行。为保持一致性，对共享状态的访问必须进行序列化处理，这实际上形成了一个瓶颈，减缓了执行速度。当这些冲突交易分布在不同的分片（节点）上时，问题会变得更加突出。在这种情况下，需要进行跨分片通信，以协调对共享状态的序列化访问，这给扩展执行增加了延迟和复杂性。

一种简单处理冲突的方法是创建仅包含无冲突交易的区块。然而，如果没有足够的无冲突交易来填满区块空间，这种方法就不切实际。更关键的是，对于那些支付较高燃气费以让自己的交易上链的用户来说，这是不公平的。例如，在热门的NFT铸造期间，许多高费用的冲突交易可能要求立即上链。 冲突交易是像Aptos这样被广泛采用的区块链所固有的一部分。认识到这一点，我们在设计系统时将冲突视为首要关注点。在单节点执行器上，Block – STM能高效管理冲突，而对于横向分片执行，我们通过下面描述的超图分区方法来尽量减少跨分片冲突。

### 交易分区 当分配到不同分片（节点）的两笔交易之间存在读写冲突时，就需要额外的网络跳转，即更新后的值要通过网络传输，这使得后续交易在开始执行前需要等待。分区的主要目标是尽量减少这种跨分片通信以及相关的等待时间。 减少跨分片通信最直接的方法是对交易进行分区，使每个资源在最少数量的机器上被使用，然后对交易重新排序，以消除在两个节点之间来回发送资源的需求，并减少等待时间。为了实现这一点，我们将冲突建模为一个超图，其中节点是交易，每个资源是一条超边，连接所有访问或写入该资源的交易。在下面的示例中，我们将超图绘制为一个二分图，一侧是交易，另一侧是资源。

在这样的图中，我们希望最小化一个称为扇出（fanout）的指标，它表示一条超边跨越的分片数量（在我们的例子中，即一个资源所需的分片数量）。扇出（f）= 1的资源无需跨分片进行协调，而其他资源则需要。并且随着某个资源扇出的增加，为该资源进行协调的分片数量也会增加。为实现这一目标，我们选用并实施了 “社交哈希分区器”（Social Hash Partitioner）中的策略，因为它具有完全可扩展性，同时能保持较高质量。它通过将扇出泛化为 “概率扇出” 来平滑目标函数，使得简单的局部搜索算法就能找到高质量的解决方案。最后，我们使用一种单遍启发式算法来确定交易顺序，以最小化分片之间的来回通信以及相应的等待时间，从而生成用于执行的优化顺序和分片。

通过这种方法生成的分片是动态的，也就是说，从不同分片中访问资源的情况会随着区块的变化而变化。这使得系统在不断变化的工作负载下仍能保持高吞吐量。

### “沙丁鱼”（Shardines）的设计

如上图所示，交易执行在多个节点间进行扩展，每个节点都作为一个 “执行器分片” 运行。每个分片运行一个 Block – STM 实例，以高效执行分配给它的交易。执行器分片的数量是可配置的，可根据预期工作负载进行设置。一个执行器分片接收待执行的交易，并向远程存储服务发出请求，以获取执行交易所需的数据。对于那些数据依赖于其他分片交易的交易（即跨分片依赖或冲突），分片之间会交换跨分片消息以获取更新后的数据。执行完成后，执行器分片将结果返回给协调器。

为展示我们分片设计的能力，我们在一个名为 “执行协调器” 的单节点应用程序中，将系统的其他部分（如共识（区块生成）、分区、读写集生成、存储、聚合以及基准测试）进行了抽象。一旦区块生成器生成交易区块，协调器就会对区块内的交易进行分区，并将分区后的交易分派到各自的执行器分片进行执行。分片完成执行后，协调器收集结果，包括更新后的状态和元数据，以用于后续处理，如聚合和最终确定。最后，它会用输出结果更新存储服务，确保一致性和持久性。

在这个设计中，存储服务并未跨多个节点进行分片，而是由协调器承载远程存储服务。在每秒 100 万笔交易（TPS）的情况下，单节点上的存储服务会成为瓶颈。我们计划在未来解决存储瓶颈问题。

提取交易依赖关系

预测交易的读写集对于我们的分区方法至关重要。它们是在运行时通过静态分析生成的，更具体地说，是在字节码验证时生成。就我们的实验范围而言，我们只考虑了那些通过查找交易的发送方和接收方参数就能轻松推断出读写集的交易。我们正在构建一个用于在运行时提取交易依赖关系的静态分析框架，该框架将适用于所有类型的交易。

流水线操作

为解决由网络延迟导致的性能瓶颈，我们在整个执行流程中采用了一种新颖的微批处理和流水线操作方法。其思路是将一个区块中的交易分割成微批次，并使它们在各个执行阶段形成流水线。这些执行阶段如下：

1. 从协调器向一个分片发送一批微交易。
2. 预取微批次中交易的数据和依赖项。
3. Block – STM 在分片上执行交易。
4. 根据需要将执行结果发送到包含相关依赖交易的分片。
5. 将微批次的结果发送回协调器。

如何在执行器分片之间交换跨分片消息？

可以使用哪些方法来预测交易的读写集？

如何解决单节点上存储服务成为瓶颈的问题？

执行过程包含五个阶段，每批交易总共需要进行 5 次网络跳转。微批处理缓解了因序列化和反序列化大数据块而导致的延迟，以及传输大数据包带来的网络延迟。此外，将流水线操作与微批处理相结合，通过使单个微批次的网络延迟与执行任务重叠，确保了资源的高效利用。因此，在单跳延迟低于 1 毫秒的标准数据中心环境中，多个批次的总网络延迟能有效地最小化到每个区块约 5 毫秒（5 次网络跳转）（而非每批 5 次网络跳转）。即使数据和执行不在同一位置，这种策略也能实现高效处理，维持高吞吐量。

结果聚合

向分片进行扩展执行时，一个有趣的挑战是结果聚合的需求。像燃气代币的总供应量等一些资源，会被所有交易修改。如果将这些资源纳入冲突图，那么每笔交易都会产生冲突，这就迫使跨分片顺序执行。为解决这一问题，每笔交易在其所在的分片执行过程中计算其对总供应量的增量，最后汇总这些增量，以在输出中更新总供应量。这个聚合过程也采用流水线操作，对整体执行时间造成的额外开销可忽略不计。

虽然聚合器看似完全是串行操作，但流水线架构确保了聚合过程不会带来明显的额外开销。

结果

实验设置

“沙丁鱼”（Shardines）架构展示了在无冲突交易模式下，将区块链执行吞吐量提升至每秒 100 万笔交易（TPS）以上的能力。为实现这一目标，我们对非执行组件（如区块生成和存储）进行了抽象，并在一个名为执行协调器的单节点应用程序中实施基准测试。通过扩展协调器，我们确保执行的横向扩展受这些抽象组件的影响降至最低。分片执行时间指的是将交易分发到执行器分片、执行交易、收集结果，以及执行可能需要的任何额外处理所需的时间。

实验设置包含以下规格：

• 执行器分片节点：谷歌云平台（GCP）上的 T2d – 60，带宽 32 Gbps，60 个 vCPU（物理核心），基于 AMD Milan 处理器，运行频率 2.45 GHz，240 GB 内存。
• 协调器节点：一台 NUMA 机器，360 个 vCPU（使用单个 NUMA 节点上的 180 个 vCPU），带宽 100 Gbps，AMD Genoa 处理器，708 GB 内存，以及 2 TB 固态硬盘（SSD）持久磁盘。

工作负载

我们使用两种不同的工作负载来评估 “沙丁鱼” 的可扩展性：一种模拟无冲突工作负载，另一种模拟有冲突工作负载。这些工作负载展示了该架构如何在大规模情况下高效处理各种交易模式。

无冲突工作负载

为在最小开销的情况下评估我们架构的扩展能力，我们设计了一种工作负载，其中的交易具有以下操作：

• 通过增加序列号、调整余额以及修改燃气代币的总供应量来更新账户状态。
• 发出一个事件。

这些交易仅更新单个账户的状态，因此与来自不同账户的其他交易本质上不会产生冲突。

我们对这一工作负载进行了 50 个区块的测试，每个区块包含 500,000 笔交易。结果显示吞吐量呈线性扩展，使用 30 个分片时，达到了约每秒 103.3 万笔交易（TPS）。在分片层面，大多数配置下每个分片的性能保持在约 40,000 TPS。使用 30 个分片时，每个分片的 TPS 略有下降，约为 35,000 TPS，这反映了因协调增加而引入的额外开销。

这些结果突出了我们的扩展架构在处理高吞吐量工作负载时的效率，随着系统扩展，性能下降极小。

有冲突工作负载

区块链拥有一个充满活力的生态系统，其中包含多个去中心化应用程序（DApp），可满足诸如游戏、金融、社交网络和供应链管理等各种用例需求。在一个区块范围内，用户通常会与一个符合其主要兴趣的 “主要 DApp” 进行交互，而与多个 DApp 的交互则相对较少。这种工作负载模式形成了一个图，其中用户（通过他们的交易）主要聚集在单个 DApp 的资源周围，跨集群的资源访问很少。

为模拟这种工作负载，我们生成了一个包含 50 万笔交易的区块，这些交易分布在 400 个 DApp 中，每个 DApp 管理 5 个资源。交易在各个 DApp 之间的分布遵循正态模式，而每个用户的交易数量呈对数正态分布，平均值为 5。每个用户都有一个主要的 DApp，并且有 99.9% 的概率仅访问该 DApp 内的资源。这意味着大多数与同一个 DApp 交互的用户的交易将会产生冲突 —— 对同一个 DApp 资源进行读写操作。

在 50 个区块的测试中，我们的吞吐量超过了每秒 50 万笔交易（TPS）。虽然扩展到 30 个分片时，吞吐量的增长并非完全呈线性，但仍然十分可观。随着分片数量的增加，每个分片的 TPS 会下降，这是因为分区效果不够理想，导致跨分片依赖交易增多。我们计划进一步优化分区算法，同时探索其他替代方法，以实现最佳分区，从而实现更好的线性扩展。

未分片存储导致的饱和现象

有趣的是，执行吞吐量最终并非受执行层本身的限制，而是受制于存储层的扩展能力。

在我们的实验设置中，执行协调器负责管理所有非执行任务，其中存储是主要部分。目前，运行在单节点协调器上的存储服务读写吞吐量有限。这一限制成为了瓶颈，阻碍了执行层在超过 30 个分片后进行横向扩展。这表明执行的扩展架构仍有进一步发展的空间。未来的改进将着重于对存储层进行扩展，以突破这些限制。

可复现的开源基准测试

Aptos 致力于提供开源且可验证的性能结果，推动区块链领域的透明度。水平分片执行器代码和性能基准测试完全开源，我们鼓励区块链爱好者进行探索、实验，并分享他们的改进建议。

未来工作

借助 “沙丁鱼”（Shardines），我们已经证明了 Aptos 具备实现横向扩展的能力，在区块链性能方面取得了显著的里程碑。我们使用 30 个分片已达到每秒 100 万笔交易（TPS），但这仅仅是个开始。通过进一步提升单节点 Block – STM 的性能以及将分片数量扩展到 30 个以上，Aptos 有望释放出更强大的交易处理能力，重新定义区块链性能的边界。

展望未来，我们将专注于对存储层进行横向扩展，以消除当前的瓶颈，实现更高的吞吐量。同时，作为 BlockSTM V2 的一部分，我们还将优化单线程（AptosVM）以及单节点（BlockSTM）的性能。此外，我们致力于通过一种支持共识、存储和执行层独立扩展的架构，为 Aptos 主网带来端到端的横向扩展能力。

欢迎见证我们所熟知的区块链技术未来的范式转变。