可并行处理交易的公链案例

在审视区块链技术的发展时，我们可以发现专注于并行执行的新 L1 的强劲趋势。 这个想法并不新鲜，目前在 Solana 的 Sealevel 执行环境中使用。 然而，上一次 DeFi 和 NFT 活动令人印象深刻的牛市表明，迫切需要改进。 采用并行执行理念的一些著名项目是 Aptos、Sui、Linera 和 Fuel。

本文讨论了这些项目之间的异同以及它们面临的挑战。

当下存在的问题

智能合约平台可以创建广泛的去中心化应用程序。 为了执行这些应用程序，需要一个共享的计算引擎。 网络中的每个节点都运行这个计算引擎并执行应用程序以及用户与应用程序的交互。 当节点从执行中获得相同的结果时，它们会达成共识并推进链。

以太坊虚拟机是最主要的智能合约 (SC) 执行引擎，有大约 20 种不同的实现。 自 EVM 发明以来，它已经建立了开发人员采用的临界质量。 除了以太坊和以太坊的 L2s，Polygon、BNB Smart Chain、Avalanche C-chain 等其他几条链都采用了 EVM 作为执行引擎，并专注于改变共识机制以提高网络吞吐量。

EVM 的一个主要限制特性是交易的顺序执行。 EVM 本质上一次执行一个交易，将所有其他交易置于暂停状态，直到交易执行完成，并更新区块链状态。 即使两个交易是独立的，例如，从 Alice 到 Bob 的付款和另一个从 Carol 到 Dave 的付款，EVM 也无法并行执行这些交易。 虽然这种执行模型允许有趣的用例，例如闪电贷款，但它既不高效，也不可扩展。

交易的这种顺序执行是网络吞吐量的主要瓶颈之一。首先，它会导致一个区块中交易的执行时间更长，从而限制了区块时间。此外，它限制了可以添加到区块中的交易数量，以允许节点执行交易并确认区块。以太坊的平均吞吐量约为 17 tx/sec。这种低吞吐量意味着在高活动期间，例如 NFT 铸造事件，网络矿工/验证者无法处理所有交易，并且随之而来的是费用竞标战，以确保优先执行将交易费用推高。以太坊的平均费用在某些时候超过了 0.2 ETH（约 800 美元），让许多用户望而却步。顺序执行的第二个问题是网络节点的低效率。顺序指令执行不会从多个处理器内核中受益，这会导致硬件利用率低和效率低下。这会阻碍可扩展性并导致不必要的能源消耗。

解决方案 --- 并行执行

EVM 结构的基本限制为专注于并行执行 (PE) 的 L1 新领域奠定了基础。 并行性允许在多个处理器内核之间划分交易处理，从而提高硬件利用率，从而实现更好的可扩展性。 在高吞吐量链中，增加硬件资源与可以执行的交易数量直接相关。 在高链活动期间，验证者节点可以委托更多核心来处理额外的交易负载。 计算资源的动态扩展允许网络在高需求时期实现更高的吞吐量，从而显着改善用户体验。

这种方法的另一个优点是改进了交易确认延迟。 节点资源的动态扩展使得确认所有可能的网络负载的低延迟交易成为可能。 交易不需要等待数十或数百个区块，也不会产生过多的费用来优先确认。 改进的确认时间提高了交易的最终确定性，并为低延迟区块链打开了大门。 保证执行交易的低延迟实现了以前不可能的几个用例。

改变链式执行模式允许PE并不是一个新想法，已经有多个项目进行了探索。 一种方法是将 EVM 使用的会计模型从 Accounts 模型替换为 Unspent Transaction Output (UTXO) 模型。 UTXO 执行模型用于比特币，它允许并行处理交易，这使其成为支付的理想选择。 由于 UXTO 的功能有限，因此需要进行扩展以实现智能合约所需的复杂交互。 例如，Cardano 为此使用了扩展的 UTXO 模型，而 Findora 使用了混合 UTXO 模型，该模型实现了两种会计模型并允许用户在两种模型之间更改资产类型。

PE 的另一种方法不会改变账户模型，而是专注于改进链状态的架构和修改方式。 这种方法的一个例子是 Solana 的 Sealevel 框架。 本文重点介绍后一种方法。

链是如何执行并行逻辑的？

并行执行通过识别独立交易并同时执行它们来工作。 如果一个交易的执行会影响另一个交易的执行，则两个交易是相关的。 例如，同一个池中的 AMM 交易是相互依赖的，必须按顺序执行。

虽然并行处理的概念很简单，但魔鬼在细节中。 主要挑战是有效识别“独立”交易。 独立交易的分类需要了解每笔交易如何改变区块链内存或链状态。 与同一智能合约（例如 AMM 池）交互的交易可以同时更改合约状态，因此不能同时执行。 以当前应用程序之间的可组合性程度，识别依赖关系是一项具有挑战性的任务。 想象一下将 Uni 交换为 USDC 的 AMM 交易，AMM 路由器发现执行它的最有效路线是 Uni -> ETH -> DAI -> AAVE -> USDC。 在该交易完全执行并且所有涉及的池的状态被更新之前，该交易中涉及的所有池不能处理任何其他交易。

识别独立交易

在本节中，比较了不同并行执行引擎使用的方法。 讨论的重点是控制状态（内存）访问的方法。 区块链状态可以被认为是 RAM 内存。 每个链帐户或智能合约都拥有一系列可以修改的内存位置。 依赖交易是那些试图更改同一块中相同内存位置的交易。 不同的链利用不同的内存架构和不同的机制来识别依赖交易。

该类别中的几条链建立在 Facebook 已终止的区块链项目 Diem 开发的技术之上。 Diem 团队创建了智能合约语言 Move 来专门改进 SC 执行。 Aptos、Sui 和 Linera 是属于该组的三个备受瞩目的项目。 除了这个小组，Fuel 是另一个著名的专注于 PE 的项目，它使用自己的 SC 语言。

Aptos

Aptos 以 Diem 的 Move 语言和 MoveVM 为基础，创建了一个实现并行执行的高吞吐量链。 Aptos 的方法是在对用户/开发人员透明的同时检测依赖关系，即不需要交易明确声明它们使用的状态的哪一部分（内存位置）。 Aptos 使用软件交易内存 (STM) 的修改版，称为 Block-STM。在 Block-STM 中，交易在块内是预先排序的，并在执行期间在处理器线程之间划分以进行乐观执行。在乐观执行中，假设没有依赖关系执行交易。被交易修改的内存位置被记录下来。执行后，验证所有交易结果。在验证期间，如果发现一个交易访问了由先前交易修改的内存位置，则该交易无效。刷新交易的结果，然后重新执行交易。重复该过程，直到块中的所有交易都被执行。当使用多个处理器内核时，Block-STM 会加快执行速度。加速取决于事务之间的相互依赖程度。 Aptos 团队的结果表明，使用 32 个内核可将高相互依赖性提高 8 倍，将低相互依赖性提高 16 倍。如果一个块中的所有交易都是依赖的，与顺序执行相比，Block-STM 会导致性能上的轻微损失。 Aptos 声称这种方法可以实现 160,000 TPS 的吞吐量。

Sui

另一种 PE 方法是要求交易明确声明它们修改的链状态部分。 Solana 和 Sui 目前正在使用这种方法。 Solana 调用内存单元帐户，交易必须说明它修改了哪些帐户。 Sui 使用了类似的方法。

Sui 还通过使用 MoveVM 以 Diem 的技术为基础。 但是，Sui 使用不同版本的 Move 语言。 实施 Sui Move 是为了从核心 Diem 的举动中更改存储模型和资产权限。 这代表了与使用核心 Diem's Move 的 Aptos 的主要区别。 Sui Move 定义了一种状态存储模型，可以更轻松地识别独立交易。 在 Sui 中，状态存储被定义为对象。 对象通常代表资产并且可以共享，这意味着多个用户可以修改对象。 每个对象在 Sui 执行环境中都有一个唯一的 ID，并具有指向所有者地址的内部指针。 通过使用这些概念，很容易通过检查交易是否使用相同的对象来识别依赖关系。

通过将工作转移给开发人员来声明依赖项，执行引擎的实现变得更加容易，这意味着它理论上可以具有更好的性能和可扩展性。 然而，这伴随着开发人员体验欠佳的成本。

Sui 尚未启动，该项目刚刚启动了他们的测试网。 Sui 的创始人声称，并行执行的实现以及使用 Narwhal & Tusk 共识机制可以导致吞吐量超过 100,000 tx/sec。 如果这个吞吐量是真的，那么它可能比 Solana 当前的约 2400 tx/秒的吞吐量有很大的提升，并且将超过 Visa 和 Mastercard 的吞吐量。

Linera

Linera 是并行处理包的最新成员，最近宣布了由 a16z 牵头的第一轮融资。 关于项目实施的细节并不多。 然而，根据他们的资金公告帖子，我们知道它是基于 Facebook 开发的 FastPay 协议。 Fastpay 基于一种称为拜占庭一致广播的技术。 该技术专注于加速独立支付，例如发生在销售点网络中的支付。 它允许一组验证者确保支付的完整性，只要其中三分之二以上是诚实的。 Fastpay 是实时总结算 (RTGS) 系统的一种变体，用于银行和金融机构之间的网络。

在 FastPay 的基础上，Linera 计划通过并行执行支付交易来构建一个专注于快速结算和低延迟的区块链。 值得注意的是，Sui 还使用拜占庭一致广播方法进行简单支付。 对于其他交易，Sui 自己的共识机制 Narwhal 和 Tusk 用于高效处理 DeFi 交易等更复杂和依赖的交易。

Fuel

Fuel 专注于成为模块化区块链堆栈中的执行层。 也就是说，Fuel 没有实现共识，也没有将区块链的数据存储在 Fuel 链上。 对于功能性区块链，Fuel 与其他链交互以达成共识和数据可用性，例如 Ethereum 或 Celestia。 本文对模块化区块链概念进行了很好的回顾。

Fuel 使用 UTXO 创建严格的访问列表，即控制对同一状态的访问的列表。 该模型建立在规范交易排序的概念之上。 在该方案中，块中的交易排序导致检测交易之间的依赖关系的显着简化。 为了实现这种架构，Fuel 构建了一个名为 FuelVM 的新虚拟机和一种名为 Sway 的新语言。 FuelVM 是对 EVM 的兼容且简化的实现，可以有效地将开发人员引入 Fuel 生态系统。 此外，由于 Fuel 专注于模块化区块链堆栈，Fuel SC 的执行可以在以太坊主网上进行。 这种方法与合并后以太坊的愿景一致，即作为以汇总为中心的结算和数据可用性层。 在这种架构中，Fuel 可以实现在以太坊上批量和结算的高吞吐量执行。

作为概念验证，Fuel 团队创建了一个名为 SwaySwap 的 Uniswap 风格的 AMM，它在测试网上运行，以展示 FuelVM 与 EVM 相比的改进性能。

并行执行 的挑战

并行执行方法似乎合乎逻辑且简单明了。 然而，有一些挑战需要讨论。 首先是估计可以使用这种并行执行加速的交易的实际百分比。 第二个挑战是网络的去中心化，即如果验证者可以轻松扩展计算能力以提高吞吐量，那么经常使用商品硬件的全节点如何跟上来确保链的正确性？

可并行交易的百分比

准确估计可以在任何链中并行执行的链交易的百分比是一项挑战。此外，根据网络活动的类型，该百分比可能会在块之间发生显着变化。例如，NFT 铸币事件可能会导致大量相关交易的活动爆发。也就是说，我们可以使用一些假设来粗略估计可并行交易的平均百分比。例如，我们可以假设大多数 ETH 和 ERC20 转账是独立的转账，即来自不同地址和接收到不同地址。因此我们可以假设约 25% 的简单 ETH 和 ERC20 转账是依赖的，即向 SC 存款以及将交易所热钱包聚合到冷钱包。另一方面，同一个池中的所有 AMM 交易都是依赖的。鉴于大多数 AMM 通常由少数矿池主导，并且 AMM 交易具有高度可组合性并与多个矿池交互，我们可以安全地假设至少 50% 的 AMM 交易是依赖的。

通过对以太坊的交易类别进行一些分析，我们可以发现，在大约 120 万以太坊的每日交易中，20-30% 是 ETH 转账，10-20% 是稳定币转账，10-15% 是 DEX 转账，4- 6% 是 NFT 交易，8-10% 是 ERC20 批准，12-15% 是其他 ERC20 转账。使用这些数字和假设，我们可以估计 PE 可以加速 SC 平台中大约 70-80% 的交易。这意味着最长的执行路径，即依赖交易的顺序执行可以占所有交易的 20-30%。换句话说，如果使用相同的gas限制，PE 的吞吐量可能会提高 3 到 5 倍。一些关于构建并行执行 EVM 的实验显示了类似的估计，其中可以持续实现 3-5 倍的吞吐量提高。在实践中，高吞吐量链使用更高的每个块的gas限制和更短的块时间来实现至少 100 倍于以太坊的吞吐量提升。增加的吞吐量需要强大的验证节点来处理这些块。这一要求导致了第二个批评，即网络中心化。

网络中心化

对并行处理的另一个常见批评是它极大地推动了网络向集中化方向发展。 在高吞吐量网络中，网络每秒可以处理数万笔交易。 验证者节点受到费用和网络奖励的激励来处理这些交易，并投资于专用服务器或可扩展的云架构来处理这些交易。 对于使用链并需要运行完整节点与链交互的公司或个人，情况并非如此。 这些实体负担不起复杂的服务器来处理如此庞大的事务负载。 这将促使链用户依赖专门的 RPC 节点提供商，例如 Infura，从而导致更多的中心化。

如果没有使用消费级硬件来操作完整节点的选项，高吞吐量链可以变成一个封闭系统，其中一小部分实体对网络拥有绝对权力。 在这种情况下，这些实体可以协调审查交易、实体甚至应用程序，例如 Tornado Cash，它可以将这些链变成与 Web 2 没有区别的许可系统。

目前，在 Sui 测试网运行全节点的要求低于 Aptos 测试网节点。 但是，我们预计当主网启动和应用程序开始出现在链上时，这些要求会发生显着变化。 权力下放倡导者一直在提出解决这些预期问题的解决方案。 解决方案包括使用轻节点，通过使用 zk 有效性证明或欺诈证明来验证块的正确性。 Fuel 团队在这方面很活跃，并与以太坊社区关于去中心化重要性的精神保持一致。 Aptos 和 Sui 团队并不清楚优先实施这些方法或替代方法以促进去中心化。 Linera 团队在他们的介绍文章中简要讨论了这些问题，但协议实施尚未确认这一承诺。

总结

并行执行引擎是提高智能合约平台吞吐量的有前途的解决方案。 结合共识机制的创新，交易的并行执行可以使链的吞吐量接近或超过 100k TPS。 与 Visa 和 Mastercard 相媲美的这种性能可以实现当今具有挑战性的几个用例，例如完全链上游戏和去中心化小额支付。 这些令人印象深刻的吞吐量改进并非没有如何确保去中心化的挑战。 在 Alliance，我们期待支持致力于解决这些问题的创始人，并支持创始人构建从这些进步中受益的创新应用程序。

原文

译者：GG@comingchat