什么是并行执行 以 Aptos、Sui、Linera 和 Fuel 为例给你讲透

来源：老雅痞

本文旨在通过 Aptos、Sui、Linera 和 Fuel 来阐明并行执行技术的原理，以及这些项目之间的异同和面临的挑战。

当观察区块链技术的发展时，我们可以看到一个强大的趋势，即新的 L1 侧重于并行执行。这一想法并不新鲜，比如目前在 Solana 的 Sealevel 执行环境中就使用了并行执行。然而，上一轮牛市中，DeFi 和 NFT 令人印象深刻的表现表明了对改进的迫切需求。目前采用并行执行理念的一些知名项目有 Aptos、Sui、Linera 和 Fuel。

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

问题所在

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

以太坊虚拟机是最主要的智能合约 (SC) 执行引擎，有大约 20 种不同的实现方式。自从 EVM 发明以来，它已经被开发人员广泛采用。除了以太坊和以太坊的 L2 外，Polygon、BNB Smart Chain 和 Avalanche c Chain 等其他几个链都采用了 EVM 作为执行引擎，并致力于改变共识机制以提高网络吞吐量。

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

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

并行执行可以解决这个问题？

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

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

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

PE 的另一种方法并不改变账户模型，而是专注于改进链状态的架构。这种方法的一个例子是 Solana 的 Sealevel‌框架，本文主要讨论后一种方法。

并行执行是如何运作的

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

虽然并行处理的概念很简单，但问题在于细节。其主要的挑战是有效地识别“独立”的交易。分类独立交易需要理解每个交易如何更改区块链内存或链状态。与同一个智能合约交互的交易可以同时改变合约状态，因此不能同时执行。在目前应用程序之间的可组合程度下，识别依赖关系是一项具有挑战性的任务。

识别独立交易

本节中将比较不同的并行执行引擎所使用的方法。讨论的重点是控制状态 ( 内存 ) 访问的方法。区块链状态可以被看作是 RAM 存储器。每个链上账户或智能合约都拥有一系列可修改的存储位置。相互依赖的交易是那些试图改变同一区块中相同内存位置的交易。不同的链使用不同的内存架构和不同的机制来识别依赖交易。

这个类别中的几条链都建立在 Facebook 已经砍掉的区块链项目 Diem 所开发的技术之上。Diem 团队创建了智能合约语言 Move，以专门改善 SC 的执行。Aptos、Sui 和 Linera 是属于这一类别的三个备受瞩目的项目。除了它们之外，Fuel 是另一个专注于 PE 的知名项目，它使用自己的 SC 语言。

Aptos

Aptos 构建在 Diem 的 Move 语言和 MoveVM 之上，创建了实现并行执行的高吞吐量链。Aptos 的方法是检测依赖关系，同时对用户 / 开发者透明，也就是说不要求交易明确声明它们使用的是哪一部分状态 ( 内存位置 )。Aptos 使用了软件交易内存 (STM) 的一种称为 Block-STM 的修改。在 Block-STM 中，交易在区块中被预先排序，并在执行期间在处理器线程之间进行划分，以便 optimistic execution。在执行中，交易的执行被假定没有依赖关系。被交易修改的内存位置会被记录下来。执行之后将验证所有交易结果。在验证期间，如果发现一个交易访问了被前一个交易修改过的内存位置，该交易就会被宣布无效。交易结果将被刷新，然后重新执行交易。这个过程重复进行，直到区块中的所有交易都被执行。当使用多个处理器核心时，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 Move 的 Aptos 的主要区别。（此前我们分析过 Sui 和 Aptos 的区别，感兴趣的朋友请前往 Allrecord 重构查看）Sui Move 定义了一个状态存储模型，使识别独立交易更加容易。在 Sui 中，状态存储被定义为对象。对象通常代表资产，并且可以被共享，这意味着多个用户都可以修改一个对象。每个对象在 Sui 执行环境中都有一个惟一的 ID，并具有指向所有者地址的内部指针。通过使用这些概念，很容易通过检查交易是否使用相同的对象来识别依赖关系。

通过将声明依赖关系的工作转移给开发者，执行引擎的实施变得更加容易，这意味着理论上它可以拥有更好的性能和可扩展性。然而，这样做的代价是开发人员体验不够理想。

Sui 还没有上线，该项目最近刚刚上线了他们的测试网。Sui 的创始人声称，并行执行的实现以及 Narwhal & Tusk 共识机制的使用可以让吞吐量超过 10 万 tx/ 秒。如果这是真的，比起 Solana 目前约 2400 tx/ 秒的吞吐量，Sui 将有一个巨大的提升，并将超过 Visa 和万事达的吞吐量。

Linera

Linera 是并行处理领域的最新成员，他们最近宣布了由 a16z 领投的第一轮融资。关于项目实施的细节并不多。然而，根据他们的融资公告，我们知道它基于同样在 Facebook 开发的 FastPay 协议。Fastpay 基于一种叫做 Byzantine Consistent Broadcast 的技术。这项技术专注于加速独立支付，比如发生在销售点网络中的支付。它允许一组验证者确保支付的完整性，只要其中三分之二以上是诚实的。Fastpay 是银行和金融机构网络中使用的实时总结算 (RTGS) 系统的变体。

Linera 计划在 FastPay 的基础上建立一个区块链，通过并行执行支付交易，专注于快速结算和低延迟。值得注意的是，Sui 也使用了 Byzantine Consistent Broadcast 方式进行简单支付。对于其他交易，Sui 使用自己的共识机制 Narwhal 和 Tusk 来高效地处理 DeFi 交易等更复杂和具依赖性的交易。

Fuel

Fuel 致力于成为模块化区块链堆栈中的执行层。这意味着 Fuel 不实施共识，也不将区块链的数据存储在 Fuel 链上。对于一个功能性的区块链，Fuel 与其他链 ( 如以太坊或 Celestia) 进行交互，以获得共识和数据可用性。

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

作为一种概念验证，Fuel 团队创建了一个名为 SwaySwap 的 Uniswap 风格的 AMM，目前它正在测试网上运行，以证明与 EVM 相比，FuelVM 的性能有所提高。

并行执行方法的挑战

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

可并行交易的百分比

准确估计可并行执行的链上交易的百分比是一个挑战。此外，根据网络活动的类型，这个百分比在不同区块之间可能会有很大的变化。例如，一个 NFT 铸币活动可能会导致依赖交易剧增。也就是说，我们可以使用一些假设来获得可并行交易平均百分比的粗略估计。例如，我们可以假设大多数 ETH 和 ERC20 传输是独立的。因此，我们可以假设约 25% 的简单 ETH 和 ERC20 转账是相互依赖的。另一方面，同一个池中的所有 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 的一些实验也显示了类似的估计。在实践中，高吞吐量链将通过使用更高的每区块 gas 限制和更短的区块时间来以实现至少比以太坊提高 100 倍的吞吐量。增加的吞吐量需要强大的验证者节点来处理这些区块。这一需求导致了网络集中化的问题。

网络集中化

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

如果不选择使用消费级硬件来运行整个节点，高吞吐量链可能会变成一个封闭的系统，其中一小群实体对网络拥有绝对的权力。在这种情况下，这些实体可以协调审查交易、实体甚至应用程序，从而将这些链转变为与 Web 2 没有区别的许可系统。

目前，在 Sui 测试网上运行全节点的要求低于 Aptos 测试网节点。然而，我们预计当主网启动、应用程序开始出现在链上时，这些需求将发生重大变化。去中心化的倡导者一直在提出解决这些预期问题的方案。其中解决方案包括使用轻型节点，通过 zk 有效性证明或欺诈证明来验证区块的正确性。Fuel 团队在这方面非常积极，并在去中心化的重要性上与以太坊社区的理念达成了一致。Aptos 和 Sui 团队还未清晰表明执行这些方法的优先次序或其他促进去中心化的方法。Linera 团队在他们的介绍文章中简要地讨论了这些问题，但协议的实施尚未证实这一承诺。

结论

并行执行引擎有望改善智能合约平台的吞吐量。通过结合共识机制的创新，交易的并行执行可以使链的吞吐量接近或超过 100k TPS。这样的性能可以与 Visa 和 Mastercard 相媲美，从而可以实现完全的链上游戏和去中心化小额支付等目前具有挑战性的几个用例。这些令人印象深刻的改进面临着如何确保去中心化的挑战。我们期待着致力于解决这些问题的创始人。

信息来源自 Alliance DAO，略有修改

作者：Mohamed Fouda

编译：RR