并行执行的区块链

在区块链技术的发展中，我们可以识别出新 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 铸造活动，网络的矿工/验证者无法处理所有交易，因而导致费用竞标战以确保优先执行，从而推高了交易费用。在某些时候，以太坊的平均费用超过了 0.2 ETH（约 800 美元），使很多用户无法承受。顺序执行的第二个问题是网络节点效率低下。顺序指令执行并未受益于多个处理器内核，导致硬件利用率低下和低效率。这阻碍了可扩展性，并造成不必要的能源消耗。

并行执行能否解救？

EVM 结构中的根本限制为新一代关注并行执行（PE）的 L1 链的出现奠定了基础。并行性允许将事务处理分配到多个处理器核心，提高硬件利用率，从而实现更好的可扩展性。在高吞吐量链中，增加硬件资源直接与可执行的交易数量相关。在高链活动期间，验证节点可以启动更多内核来处理额外的交易负载。计算资源的动态扩展使网络在需求高峰期实现吞吐量增加，显著改善用户体验。

这种方法的另一优点是改进交易确认延迟。节点资源的动态扩展使得在所有可能的网络负载下，都可以以低延迟确认交易。交易无需等待数十或数百个区块，也不需要支付过高的费用来优先确认。改进的确认时间提高了交易最终性，并为低延迟链条打开了大门。保证交易执行的低延迟使得一些之前不可能的用例成为可能。

改变链的执行模型以允许 PE 并不是一个新想法，已经有几个项目对此进行了探索。一种方法是将 EVM 使用的记账模型从账户模型更改为未花费交易输出（UTXO）模型。UTXO 执行模型在比特币中使用，它允许并行处理交易，使其非常适合支付。由于 UTXOs 的功能有限，需要进行扩展以支持智能合约所需的复杂交互。例如，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 的知名项目，它使用自己的智能合约语言。

Aptos

Aptos 基于 Diem 的 Move 语言和 MoveVM 创建了一个高吞吐量链，实现并行执行。Aptos 的方法是在对用户/开发者透明的情况下检测依赖关系，即无需交易明确声明使用状态的哪一部分（内存位置）。Aptos 使用了一种叫做 Block-STM 的软件事务内存（STM）修改版。在 Block-STM 中，交易在区块内按顺序预排序，并在执行过程中划分到处理器线程以进行乐观执行。在乐观执行中，假设没有依赖关系执行交易。被交易修改的内存位置得到记录。执行后，所有交易结果进行验证。在验证期间，如果发现某笔交易访问了前面交易修改的内存位置，则该笔交易将被作废。该交易的结果将被清除，交易随后被重新执行。该过程将持续重复，直到区块内的所有交易执行完成。当使用多个处理器核心时，Block-STM 会加快执行速度。加速取决于交易之间的相互依赖程度。Aptos 团队的结果显示，使用 32 个核心的高相互依赖交易改善了 8 倍，低相互依赖交易改善了 16 倍。如果区块中的所有交易都是相互依赖的，则与顺序执行相比，Block-STM 将导致性能的轻微惩罚。Aptos 声称该方法可实现 160,000 TPS 的吞吐量。

Sui

另一种 PE 方法要求交易明确声明他们修改的链状态部分。Solana 和 Sui 目前都采用这种方法。Solana 将内存单元称为 accounts，一笔交易必须表明它修改了哪些账户。Sui 使用类似的方法。

Sui 也基于 Diem 的技术，使用 MoveVM。然而，Sui 使用了一个 不同版本 的 Move 语言。Sui Move 的实现旨在从核心 Diem 的 Move 修改存储模型和资产权限。这与使用核心 Diem Move 的 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 与其他链进行互动，例如以太坊或 Celestia 来进行共识和数据可用性。这篇 文章 对模块化区块链概念提供了很好的回顾。

Fuel 使用 UTXO 创建严格的访问列表，即控制对同一块状态的访问。这一模型建立在称为 标准交易排序 的概念上。在该方案中，区块内的交易排序显著简化了依赖关系的检测。为实现这一架构，Fuel 构建了一个新的虚拟机 FuelVM 和一种新的语言 Sway。FuelVM 是对 EVM 的兼容且简化的实现，这对于引导开发者进入 Fuel 生态系统非常有效。此外，由于 Fuel 关注模块化区块链堆栈，Fuel SC 执行可以在以太坊主网进行结算。这一方法与以太坊在合并之后作为聚合中心的结算和数据可用性层的愿景是一致的。在这种架构中，Fuel 可以实现高吞吐量的执行，这些执行会批量处理并在以太坊上进行结算。

作为概念证明，Fuel 团队创建了一个称为 SwaySwap 的类似 Uniswap 的 AMM，并在测试网上运行，以展示 FuelVM 在与 EVM 相比时的性能改进。

并行执行方法的挑战

并行执行方法似乎合乎逻辑且直截了当。然而，仍然存在一些需要讨论的挑战。首先是评估可以使用这种并行执行加速的实际交易百分比。第二个挑战是网络的去中心化，即如果验证者能够轻松扩展计算能力以提升吞吐量，那么使用普通硬件的全节点如何能够跟上以确保链的正确性？

可并行化交易的百分比

很难准确估计在任何链上能够以并行方式执行的交易百分比。此外，根据网络活动的类型，此百分比在不同区块之间可能会显著变化。例如，一场 NFT 铸造事件可能会导致活动激增，相关交易的百分比很高。也就是说，我们可以使用一些假设来粗略估算可并行化交易的平均百分比。例如，我们可以假设大多数 ETH 和 ERC20 转账都是独立转账，即来自不同地址和接收不同地址。因此，我们可以假设约 25% 的简单 ETH 和 ERC20 转账是相关的，即存入到 SC 和交换热钱包到冷钱包之间的转账。另一方面，所有同一池中的 AMM 交易都是相关的。考虑到大多数 AMM 通常由少量池主导，且 AMM 交易高度合成并与多个池交互，我们可以安全地假设至少 50% 的 AMM 交易是相关的。

通过对以太坊的交易类别进行一些分析，我们发现，在约 1.2M 的以太坊每日交易中，20-30% 是 ETH 转账，10-20% 是稳定币转账，10-15% 是 DEX 转账，4-6% 是 NFT 交易，8-10% 是 ERC20 批准，12-15% 是其他 ERC20 转账。利用这些数字和假设，我们可以估算 PE 可以加速大约 70-80% 的 SC 平台交易。这意味着执行过程中的最长路径，即相关交易的顺序执行可以占所有交易的 20-30%。换句话说，如果使用相同的 gas 限制，通过 PE 可以实现 3x-5x 的吞吐量提升。一些 实验 在构建并行执行 EVM 时显示出类似的估计，表明3-5倍的吞吐量提升是可持续实现的。在实践中，高吞吐量链使用远高于以太坊的每个区块 gas 限制和更短的区块时间，从而实现至少 100 倍的吞吐量提升。吞吐量的提升要求验证者节点具有强大的能力来处理这些区块。这一要求导致第二个批评，即网络中心化。

网络中心化

对并行处理的另一常见批评是，它会显著推动网络向集中的方向发展。在高吞吐量的网络中，网络可以处理每秒数万笔交易。验证者节点受到费用和网络奖励的激励，处理这些交易并投资于 Dedicated 服务器或可扩展的云架构来处理这些交易。对于使用链的公司或个人而言，他们需要运行完整节点来与链进行交互，但情况并非如此。这些实体无力负担复杂的服务器以处理如此巨大的交易负担。这将迫使区链用户依赖专业的 RPC 节点供应商，例如 Infura，这导致了更大程度的中心化。

如果没有使用普通硬件操作全节点的选项，高吞吐量链可能会变成一个封闭系统，在这个系统中，小团体对网络拥有绝对控制权。在这种情况下，这些实体可以协调以审查交易、实体甚至应用程序，例如 Tornado Cash，这可能使这些链变成与 Web 2 没有区别的许可系统。

目前，运行 Sui 测试网 的全节点要求低于 Aptos 测试网节点 的要求。然而，我们预计当主网推出且应用开始涌现时，这些要求将显著变化。去中心化的倡导者已提出 解决方案 来应对这些预期的问题。这些解决方案包括使用轻节点通过 zk 有效性证明或欺诈证明来验证区块的正确性。Fuel 团队在这方面 非常活跃，这与以太坊社区对去中心化重要性的理念相符。Aptos 和 Sui 团队未明确优先实施这些方法或替代方案以促进去中心化。Linera 团队在他们的介绍帖子中简要讨论了这些担忧，但协议实施尚未确认这一承诺。

结论

并行执行引擎是提高智能合约平台吞吐量的有前景的解决方案。结合共识机制上的创新，交易的并行执行可以导致吞吐量接近或超过 100,000 TPS 的链。这种与 Visa 和 Mastercard 相抗衡的性能可以实现多个当前具有挑战性的用例，例如完全链上游戏和去中心化微支付。这些令人印象深刻的吞吐量提升并非没有挑战，如何确保去中心化是关键。在联盟，我们期待支持致力于解决这些问题的创始人，并扶持那些受益于这些进步的创新应用程序的创始人。

感谢 Aries 团队 的创始人和 Robert Chen 对本文的评论和反馈！

如需对本文提供反馈，请通过 Twitter 直接私信我或在下方留下评论！

• 原文链接： medium.com/alliancedao/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～