“并行式”公链详解

作者：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，在事务完全执行并更新所有涉及的池状态之前，该事务涉及的所有池不能处理任何其他事务。

识别独立交易