原文标题：《The Case for Parallel Processing Chains》
原文作者：Mohamed Fouda
原文编译：深潮 TechFlow
当我们重新审视区块链技术的演变时，可以看到一个强劲的趋势正在显现，即新的 L1 注重并行执行。
这并不是什么新鲜技术，目前 Solana 就在 Sealevel 的执行环境中使用。
然而，在过去的牛市中，DeFi 和 NFT 令人印象深刻的表现也让人们意识到，技术迫切需要改进。
在下轮市场中，一些采用并行执行理念的著名项目即将出现，这些项目的名单是 Aptos、Sui、Linera 和 Fuel。
本文将会讨论这些项目的异同，以及它们所面临的挑战。
问题
智能合约平台可以创建广泛的去中心化应用程序。为了执行这些应用，需要一个共享的计算引擎。网络中的每个节点都运行这个计算引擎，以及执行应用程序和用户与应用程序的互动。当节点从执行中得到相同的结果时，他们就会达成共识，并推动链的运转。
以太坊虚拟机是最主要的智能合约（SC）执行引擎，有大约 20 种不同的实现方式。
自 EVM 发明以来，它已经建立了开发人员采用的临界质量。
除了以太坊和以太坊的 L2，其他几个链包括 Polygon、BNB 智能链和 Avalanche C 链都采用 EVM 作为执行引擎，并专注于改变共识机制以提高网络吞吐量。
EVM 的一个主要限制性特征是交易的顺序执行。EVM 基本上是一次执行一个交易，将所有其他交易搁置，直到交易执行完毕，区块链状态被更新。即使两个交易是独立的，例如，从 Alice 到 Bob 的付款和从 Carol 到 Dave 的另一个付款，EVM 不能并行执行这些交易。虽然这种执行模式允许有趣的用例，如闪电借贷，但它既没有效率，也没有可扩展性。
这种顺序执行交易是网络吞吐量的主要瓶颈之一：
首先，它导致区块中的交易执行时间更长，限制了区块时间；
此外，它限制了可以添加到区块中的交易数量，以使节点能够执行交易并确认区块。
以太坊的平均吞吐量约为 17 tx/秒。这种低吞吐量意味着在高活动期间，例如 NFT Mint，网络矿工/验证者不能处理所有的交易，随之而来的是费用竞标战，以确保优先执行，推动交易费用上升。以太坊的平均费用在某些时候超过了 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 使用的是 Software Transactional Memory （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 Move 的 Aptos 的重大区别。
Sui Move 定义了一个状态存储模型，允许更容易识别独立交易。
在 Sui 中，状态存储被定义为 Objects。Objects 通常代表资产，并且可以共享，这意味着多个用户可以修改该对象。每个 Objects 在 Sui 执行环境中都有一个唯一的 ID，并有指向所有者地址的内部指针。通过使用这些概念，很容易通过检查交易是否使用相同的 Objects 来识别关联。
通过将声明关联关系的工作转移给开发者，使执行引擎的实施变得更容易，这意味着理论上它可以有更好的性能和可扩展性。然而，这是以不太理想的开发者体验为代价的。
Sui 还没有启动，最近刚刚推出了测试网。
Sui 的创始人声称，并行执行的实施以及使用 Narwhal 和 Tusk 共识机制导致吞吐量超过 100,000 tx/秒。这个吞吐量，如果是真的，那么它可能比 Solana 当前的约 2400 tx/秒的吞吐量有很大的提升，并且将超过 Visa 和 Mastercard 的吞吐量。
Linera
Linera 是并行处理领域的最新成员，最近宣布了他们的第一轮融资，由 a16z 领投。关于项目实施的细节不多。然而，根据他们的融资公告帖子，我们知道它是基于同样在 Facebook 开发的 FastPay 协议。
Fastpay 是基于一种叫做 Byzantine Consistent Broadcast 的技术，这项技术专注于加速独立的支付，例如发生在销售点网络中的支付。它允许一组验证者确保付款的完整性，只要超过三分之二的验证者是诚实的。快速支付是实时毛额结算（RTGS）系统的一个变种，用于银行和金融机构之间的网络。
在 FastPay 的基础上，Linera 正计划建立一个区块链，通过并行执行支付交易，专注于快速结算和低延迟。值得注意的是，Sui 也使用 Byzantine Consistent Broadcast 的方式进行简单的支付。对于其他交易，Sui 自己的共识机制 Narwhal 和 Tusk 被用于高效处理 DeFi 交易等更复杂的和有关系性的交易。
Fuel
Fuel 专注于成为模块化区块链中的执行层，这意味着 Fuel 不实施共识或将区块链的数据存储在 Fuel 链上。对于功能性区块链，Fuel 与其他链交互以达成共识和数据可用性，例如 Ethereum 或 Celestia。
Fuel 使用 UTXO 来创建严格的访问列表，即用一个列表来控制对同一片状态的访问。这个模型建立在规范交易排序的概念之上。在这个方案中，区块中的交易排序导致了检测交易之间的关联关系的显著简化。为了实现这个架构，Fuel 公司建立了一个新的虚拟机，称为 FuelVM 和一种新的语言，称为 Sway。
FuelVM 是对 EVM 的一种兼容和简化的表现，可以有效地让开发者加入到 Fuel 的生态系统中。
此外，由于 Fuel 专注于模块化区块链，Fuel SC 的执行可以在以太坊主网上解决。这种方法与合并后以太坊的愿景一致，即作为以 Rollup 为中心的结算和数据可用性层。在这种架构中，Fuel 可以实现在以太坊上批量和结算的高吞吐量执行。
为了验证该概念，Fuel 团队已经创建了一个名为 SwaySwap 的 AMM，类似于 Uniswap，并在测试网上运行。目的是证明 FuelVM 与 EVM 相比性能更高。
并行执行方法的挑战
并行执行的方法似乎是合乎逻辑和直接的，然而，目前我们仍然面临着几个挑战。首先是估计使用这种并行执行方式可以加速的交易的实际比例。第二个挑战是网络的去中心化，也就是说，如果验证者可以很容易地扩展计算能力以提高吞吐量，那么完整节点如何跟上以确保链的正确性？
可并行交易的百分比
准确估计在任何链上可并行执行的链上交易的百分比是具有挑战性的。此外，根据网络活动的类型，这个百分比在区块之间会有很大的变化。
例如，一个 NFT Mint 可能会导致一个具有高百分比的关联性交易的爆发。也就是说，我们可以使用一些假设来获得可并行交易的平均百分比的粗略估计。
例如，我们可以假设大多数 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 团队在他们的介绍帖子中简要地讨论了这些问题，但协议实施尚未确认这一承诺。
总结
并行执行引擎是提高智能合约平台吞吐量的有前途的解决方案。
结合共识机制的创新，交易的并行执行可以使链的吞吐量接近或超过 10 万 TPS，这样的性能可以与 Visa 和 Mastercard 相媲美，可以实现当今最具挑战性的几个用例，例如完全的链上游戏和去中心化小额支付。
这些令人印象深刻的吞吐量改进并不是没有挑战，即关于如何确保去中心化，我们期待致力于解决这些问题的创始人。
