原文标题：The Case for Parallel Processing Chains

原文作者：Mohamed Fouda - Alliance DAO

原文编译：Assembly Partners Labs

并行执行正成为新公链的强劲趋势。目前 Solana 的 Sealevel 执行环境就是并行的，然而这轮牛市期间，由于一些 DeFi 和 NFT 项目过于火爆，Solana 曾多次宕机，这提示我们区块链并行执行技术还需要升级。新一代公链中采用并行执行的知名项目有 Aptos、Sui、Linera 和 Fuel。本文编译自 Alliance DAO 通过原理和案例详细解释了并行执行的前景和难点。

问题

为了执行 dAPP 合约，网络中的每个节点都运行同一个计算引擎，运行合约以及用户与合约的交互。节点运行合约后得到相同结果，节点之间则达成共识并写到链上。

以太坊虚拟机是目前最主要的智能合约执行引擎，拥有大约 20 种不同的实现方式。自 EVM 发明以来，已经吸引了大量开发者。除了以太坊和以太坊的 L2s，Polygon、BNB Smart Chain、Avalanche C-chain 等其他几条链都采用了 EVM 作为执行引擎，并通过改变共识机制提高网络吞吐量。

EVM 的一个主要限制是交易的顺序执行（Sequential execution）。EVM 将事务按线性排序，一次执行一个事务，完成所有事务后，打包成一个区块更新到区块链状态。即使两个交易是独立的，EVM 也不能并行执行。例如，Alice-Bob 之间的交易和 Carol-Dave 之间的交易互不影响，EVM 仍将两个交易按顺序处理。顺序执行有一些有趣的用例，如闪电贷，但它既不高效，也没有可扩展性。

顺序执行是网络吞吐量的主要瓶颈之一，他带来两个问题：

• 首先，它导致一个区块的交易执行时间更长，从而限制了出块时间，同时它还限制了区块中的交易数量。以太坊的平均吞吐量约为 17 tx/sec。这种低吞吐量意味着在高活动期间，例如热门 NFT 铸造期间，矿工/验证者无法处理所有交易，用户只能竞相提高 Gas 费，以确保优先执行。以太坊的平均 Gas 费在某些时候超过了 0.2 ETH（约 800 美元），超高交易费让许多用户望而却步。

• 顺序执行的第二个问题是网络节点的低效率。顺序执行不能通过增加处理器内核提高效率，导致硬件利用率低、效率低下，不仅限制网络可扩展性还导致不必要的能源消耗。

并行执行能提高可扩展性吗？

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

这种方法的另一个优点是改进了交易确认延迟。由于节点硬件资源可动态扩展，从而网络能实现低延迟确认所有网络负载。交易不需要等待数十或数百个区块，也不会因为需要优先确认产生过多的费用。确认时间的缩短提高了交易的最终确定性，使得低延迟区块链成为可能，一些以前不可能实现的用例也能得以实现。

并行执行并不是一个新想法，已经有多个项目对此进行了探索。一种方法是将 EVM 的账户模型改为 UTXO 模型（未被花费的交易输出）。UTXO 模型是无状态的，因此更容易并发处理，比特币就是采用的这种模型，这使其成为支付的理想选择。由于 UXTO 的功能有限，无法实现复杂逻辑，可编程性差，因此需要进行扩展。例如，Cardano 使用了扩展的 UTXO 模型，而 Findora 使用了混合 UTXO 模型，该模型实现了两种记账模型并允许用户在两种模型之间更改资产类型。

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

并行执行如何工作？

并行执行需要先识别独立事务，然后同时执行它们。如果一个事务的执行会影响另一个事务的执行，则两个事务是相关的，譬如同一个 AMM 池中的事务就是相互依赖的，则必须按顺序执行。

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

识别独立交易的方案

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

Aptos

Aptos 建立在 Move 语言和 MoveVM 之上，它创建了一个并行执行的高吞吐量公链。Aptos 在识别独立交易时对用户/开发人员均透明，即不需要事务明确声明它们使用状态的哪一部分（内存位置）。Aptos 使用软件事务内存 (STM) 的修改版，称为 Block-STM。在 Block-STM 中，事务在区块内是预先排序的，并在处理器线程之间划分，以便进行乐观执行（optimistic execution）。

乐观执行的过程：

• 假设交易之间没有依赖关系。事务所修改的内存位置被记录下来。

• 执行后，验证所有交易结果。如果发现一个事务访问了由前序事务修改的内存位置，则该事务无效。

• 剔除无效事务后，重新执行事务。

• 重复该过程，直到块中的所有事务都被执行。

当使用多个处理器内核时，Block-STM 会加快执行速度。加速程度取决于事务之间的相互依赖程度。Aptos 的试验结果表明，使用 32 个内核可以将高度相互依赖事务集的执行速度提高 8 倍，将低相互依赖事务集处理速度提高 16 倍。如果一个块中的所有事务都是相互依赖的，与顺序执行相比，Block-STM 会导致性能上的轻微损失。Aptos 声称这种方法可以实现 160,000 TPS 的吞吐量。

Sui

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

Sui 通过使用 MoveVM 构建在 Diem 技术基础之上。但 Sui 使用了不同版本的 Move 语言。实施 Sui Move 是为了从 Diem 版 move 中更改存储模型和资产权限。这是 Sui 与 Aptos 的主要区别（Aptos 使用 Diem 版 Move）。

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 基于拜占庭一致性广播的技术，专注于加速独立支付，例如发生在销售网点中的支付。只要 2/3 以上节点是诚实的，它就允许验证者确保支付的完整性。Fastpay 是实时总结算 (RTGS) 系统的一种变体，RTGS 系统被用于银行和金融机构之间的网络。

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

Fuel

Fuel 专注于成为模块化区块链中的执行层。也就是说，Fuel 没有共识层，也没有将区块链的数据存储在 Fuel 链上。Fuel 通过与其他链（如 Ethereum 或Celestia）交互以获得共识和数据可用性。

Fuel 使用 UTXO 来创建严格的访问列表，一个控制对同一状态访问的列表。该模型建立在规范交易排序的概念之上。它通过区块中的事务排序显著简化了检测依赖关系的难度。

为了实现这种架构，Fuel 构建了一个名为 FuelVM 的新虚拟机和一种名为 Sway 的新语言。FuelVM 兼容 EVM，是 EVM 的简化实现，可以有效地将 EVM 开发人员引入 Fuel 生态系统。此外，由于 Fuel 专注于模块化区块链堆栈，Fuel 合约的执行可以在以太坊主网上进行。这种模式与合并后以太坊的愿景一致，即 Fuel 可以成为以 Rollup 为中心的结算层和数据可用性层。在这种架构中，Fuel 可以实现在以太坊上进行高吞吐量执行。

为了验证这一概念，Fuel 团队创建了类似 Uniswap 风格的 AMM——SwaySwap，并在测试网上运行，以展示 FuelVM 相比 EVM 的性能改进。

并行执行方法的挑战

并行执行方法似乎合乎逻辑且简单明了。但还是有些问题需要讨论。首先是估计通过并行执行可以加速的事务占比。然后是网络的去中心化，如果验证者可以轻松扩展计算能力以提高吞吐量，那么使用商品硬件（便宜、广泛使用）的全节点如何跟上以确保链的正确性？

可并行交易的百分比

准确估计可并行执行的交易的比例是一项挑战。根据交易类型，该比例在不同区块之间有显著变化。譬如，NFT 铸币事件可能会导致相关交易量爆增。我们可以使用一些假设来粗略估计可并行事务的平均百分比。例如，我们可以假设大多数 ETH 和 ERC20 转账是独立转账，即来自不同地址和接收到不同地址。假设大约 25% 的 ETH 和 ERC20 转账是依赖的，譬如存入合约、交易所热钱包到冷钱包。鉴于大多数 AMM 通常由少量池子主导，且 AMM 交易具有高度可组合性、且常与多个池子交互，我们可以合理地假设至少 50% 的 AMM 交易是依赖的。

通过分析以太坊的交易类别，我们发现，以太坊每日交易数量大约 120 万：

• 20-30% 是 ETH 转账

• 10-20% 是稳定币转账

• 10-15% 是 DEX 转账

• 4- 6% 是 NFT 交易

• 8-10% 是 ERC20 批准

• 12-15% 是其他 ERC20 转账

通过以上数据和假设，我们可以估计并行执行可以加速智能合约平台中大约 70-80% 的交易。这意味着必须顺序执行的事务占 20-30%。换句话说，如果 Gas limit 相同，并行执行的吞吐量可能会提高 3 到 5 倍。一些构建并行执行 EVM 的试验显示了类似的数据结果——吞吐量能持续稳定的提高 3-5 倍。

在实践中，高吞吐量链使用更高的区块 Gas limit 和更短的出块时间，将吞吐量提升了至少 100 倍。当然，要实现这样的吞吐量提升，需要强大的验证节点。这就导致了上述第二个问题，即网络中心化。

网络中心化

对并行执行的另一个常见批评是它使得网络向中心化方向发展。在高吞吐量网络中，网络每秒可以处理数万笔交易。验证者节点通过费用和网络奖励获得收入，并投资于专用服务器或可扩展的云架构从而处理这些交易。对于需要运行完整节点，并且进行链上交互的公司或个人，他们负担不起复杂服务器的开销。这促使用户依赖专门的 RPC 节点提供商，例如 Infura，从而导致更多的中心化。

如果不能使用消费级硬件来操作完整节点，高吞吐量链可能会变成一个封闭系统，一小部分节点对网络拥有绝对权力，这些节点可以配合审查交易、实体甚至 dApp，例如 Tornado Cash，这将使区块链变成与 Web 2 没有区别的许可系统。

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

结语

在提高智能合约平台吞吐量方面，并行执行引擎是非常有前景解决方案。结合共识机制的创新，并行执行可以使链的吞吐量接近或超过 100k TPS。这种与 Visa 和 Mastercard 相媲美的性能可以实现如今难以实现的用例，例如完全的链上游戏和去中心化小额支付。尽管这些吞吐量改进令人印象深刻，但仍然面临确保去中心化的挑战。

本文编译自 Alliance DAO:

关于 Assembly Partners Insights

Assembly Partners Insights 栏目将不定期分享关于 Infrastructure, DeFi, Web3 的研究和思考，若您对我们的研究有任何想法，欢迎与我们在推特上交流！