公链扩容新视角，详解Aptos、Sui、Linera 和 Fuel背后的「并行执行」原理

作者：Mohamed Fouda由DeFi之道编译

当我们审视整个区块链技术发展时，我们可以看到一个非常大的趋势，即新的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/sec。这种低吞吐量意味着在高活动期间，例如 NFT 铸造事件中，节点矿工/验证者无法处理所有交易，并会发生GAS费用的竞标战，来确保交易的优先执行。以太坊的平均费用在某些时候甚至超过了 0.2 ETH，让许多用户望而却步。顺序执行模式的第二个问题是网络节点的低效率。顺序执行的模式难以从多核处理器中受益，这会导致硬件利用率低，这阻碍了可扩展性，并造成不必要的能源浪费。

并行执行

EVM 的上述限制为专注并行执行（PE）的新L1提供了更多的发展契机。并行性允许在多个处理器内核之间划分事务处理，从而提高硬件利用率，从而更好的实现可扩展性。在高吞吐量链中，增加硬件资源与可以执行的事务数量直接相关。在链上的高活动期间，验证者节点可以委托更多核心来处理额外的交易负载。计算资源的动态扩展允许网络在高需求时期实现更高的吞吐量，从而显著改善用户体验。

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

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

PE 的另一种方法不会改变账户模型，而是专注于改进链状态的架构。这种方法的一个例子是 Solana 的Sealevel‌框架，后文将会讲述。

并行执行如何工作？

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

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

识别独立交易

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

这一类中的几个公链大都是建立在Facebook 的前公链 Diem 的技术架构之上。Diem 团队创建了智能合约语言 Move，专门改善SC的执行，Aptos、Sui 和 Linera 都属于这一范围，除此之外，Fuel是另一个专注于PE的知名项目，它使用自己的智能合约语言。

Aptos

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

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

目前，Sui 尚未启动，该项目刚刚启动了他们的测试网。Sui 的创始人声称，并行执行的实现以及使用 Narwhal & Tusk 共识机制可以让吞吐量超过 100,000 tx/sec，如果这个吞吐量是真的，那么它将超过 Solana 当前 2400 tx/sec 的吞吐量，并超过 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 智能合约的执行可以在以太坊主网上进行。这种方法与合并后以太坊的愿景一致，即作为以 Rollup 为中心的结算和数据可用层。在这种架构中，Fuel 可以实现在以太坊上批量和结算的高效执行。

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

并行执行的挑战

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

可并行交易的百分比

准确估计在任何链中可以并行执行的链交易的百分比是一个挑战。此外，根据网络活动的类型，这个百分比在不同区块之间可以有很大的变化。例如，一个 NFT mint 事件可能会导致网络活动的大幅增长，其中依赖事务的比例可能会很高。我们可以使用一些假设来粗略估计可并行事务的平均百分比。例如，我们可以假设大多数 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 可以加速只能合约平台上大约 70-80% 的交易。这意味着最长的执行路径，即依赖事务的顺序执行可能只占所有事务的 20-30%。换句话说，如果使用相同的 GAS 限制，PE 的吞吐量可能会提高 3 到 5 倍，一些实验关于构建并行执行 EVM 的研究也显示了类似的结果。在实践中，高吞吐量的链使用每个区块更高的 GAS 限制和更短的区块时间来实现比以太坊100倍的吞吐量改进，增加的吞吐量需要强大的验证器节点来处理这些区块，这一要求也导致了第二个问题的出现——即网络的集中化。

网络集中化

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

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

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

结论

并行执行引擎有望改善智能合约平台的吞吐量。结合创新的共识机制，事务的并行执行可以催生吞吐量接近10万 TPS 的链，与 Visa 和万事达一决高下或成为可能，此外，一些现在难以实现的应用也能得到进一步的发展，比如：全链上游戏和去中心化的微支付。但这些令人印象深刻的吞吐量改进也对如何确保去中心化的问题提出了新的挑战。非常感谢Aries 团队的创始人和Robert Chen对本文的评论和反馈！