想象一下：你在一个繁忙的厨房里，厨师们必须等一个人切完蔬菜后，另一个才能开始烤土豆。这听起来既慢又低效，对吧？这就像计算和区块链中的同步执行：一个任务必须完成后，下一个才能开始。现在，再想象一个协调良好的厨房，每个厨师同时在不同的菜肴部分上工作，准备食材、烹饪和装盘。这就是异步执行——任务可以并发运行，创造更高效、更快速的工作流程。

在区块链发展过程中，同步可组合性成为热议话题，因为它似乎能解决以太坊网络中分散的 Layer 2 系统的整合问题。这种方式解决了用户体验（UX）和开发者体验（DevEx）的问题，比如 Layer 2 之间的简单转账可能会花费 1 美元，并且延迟长达 7 天。Vitalik 参与这些讨论，指出并非所有问题都必须依赖普遍的同步性。我们认为，事务执行的有效性并不一定要同步，且同步基础设施的构建和维护会带来不小的成本。同步与异步不是非此即彼的选择，它们可以共存，且未来可能更多地向异步执行转型。

1. 异步可分解（Asynchronous Decomposable）

在区块链技术的扩展性能挑战中，智能合约的并行执行受到了广泛关注。尽管多链和 Layer-2 系统的出现使得性能有所提升，智能合约的执行仍然受限于单个虚拟机（EVM）的能力。而并行虚拟机提供了一个有前景的解决方案，可以并行处理智能合约的多个交易，充分利用更多 CPU 核心，从而显著提高性能。

并行中继执行分布式架构（PREDA） 是一种面向分布式多 EVM 区块链系统的高级编程模型，旨在实现智能合约的内在并行化。PREDA 提供了一种新的架构，通过异步执行和可分解性，使得合约功能能够完全并行化，从而极大地提高交易并发性。这种方法确保所有 EVM 实例的资源都能够高效利用，实现最佳性能与可扩展性。

在深入探讨具体细节之前，让我们先澄清本文中几个关键术语的含义：
Tx1 = 交易 1
Tx2 = 交易 2

我们假设：

• Tx1 的执行需要更改状态 A 、状态 B 、状态 C
• Tx2 的执行需要更改状态 A 、状态 D 、状态 E

目前最先进的 EVM 并行化方法，如 Sei、Aptos 和 Sui 所实现的那样，尝试同步执行每笔交易的所有步骤。想象一下，放大到单笔交易的场景中，在这些系统里，交易在一个区块高度内执行完成，无论所涉及的数据依赖（即访问不同的合约状态部分）如何分散。因此，如果两笔交易之间访问的合约状态步骤存在共享或更新，它们将被识别为读写冲突或写写冲突，无法并行执行，从而阻碍系统的整体吞吐量和可扩展性。当链上活动突然飙升时，这种情况会显著恶化。

PREDA 采用了一种不同于上述系统的新颖方法。它引入了一种实现异步可分解性的智能合约执行模型，根据数据访问依赖将交易的各个步骤分解，从而允许这些步骤异步执行。PREDA 的执行模型实现了更高的效率，并在理论上具备无限的可扩展性。我们将进一步探讨 PREDA 如何实现这一点，并展示实验结果以支持这一论点。

2. 性能评估

通过吞吐量和可扩展性评估 Sei (V2)、Aptos、Sui 和 PREDA，回放历史 ETH 代币转账交易。需要注意的是，我们的评估采用了真实世界的历史 ETH 代币转账交易，而非在随机地址对之间创建一组转账交易。随机交易会产生明显高于实际情况的实验结果，因为真实交易涉及彼此相关的地址，从而引入了大量的数据依赖性。

实验设置如下：

图1的比较强调了采用 PREDA 编程模型以实现显著吞吐量提升的必要性。在以太坊网络上的真实历史转账交易中，PREDA 的 TPS 比 Aptos 高出 3.3 倍至 28.2 倍。

由于这些系统采用不同的编程语言（包括 Go、Rust 和 C++）及不同的虚拟机实现，我们通过相对于单个 EVM 基线的相对加速比来评估不同系统的可扩展性，以排除不同系统实现所带来的影响。

图1. 在 Sei、Aptos、Sui 和 PREDA 上执行的等效代币转账智能合约的绝对吞吐量（TPS）

图2. Aptos、Sui、Sei 和 PREDA 相对于各自基线的相对加速比

3. 编程模型

为了帮助熟悉并行 EVM 的读者理解 PREDA，目前的并行 EVM 区块链系统中存在两种典型的并行化机制¹：

Optimistic并行化（例如 Aptos、Sei (V2) 和 Monad）：忽略交易之间的状态依赖，同时执行并验证交易，在发生冲突时回滚交易并重新执行。

悲观并行化（例如 Solana (Sealevel)、Sui 和 Sei (V1)）：在执行之前对每笔交易的状态依赖进行预检查，分析其状态依赖，仅并行执行没有冲突的交易。

两种方法均采用共享一切架构（Shared-everything Architecture），在并发控制中将交易视为一个整体；所有步骤（如访问不同的合约状态）不可分解，必须同步执行。而 PREDA 模型提出了共享无架构（Shared-nothing Architecture），通过消除状态依赖，确保不同的 EVM 实例永远不会访问同一部分合约状态，从而完全避免写入冲突。

PREDA 的核心是引入可编程合约范围（Programmable Contract Scopes），将合约状态分解为非重叠、可并行的小块，以及异步功能中继（Asynchronous Functional Relay），用来描述跨不同 EVM 的执行流程切换。

为进一步解释这些概念，在 PREDA 中，合约函数被分解为多个有序步骤，每个步骤依赖于一个没有冲突的、可并行的状态片段。用户发起的交易首先被定向到一个确定性持有该用户地址状态的 EVM，例如通过用户地址到 EVM 的映射方法。在交易执行过程中，执行流程可以通过发起中继交易，从一个持有所需合约状态的 EVM 切换到另一个 EVM。这样，PREDA 通过根据数据依赖将执行流程在 EVM 之间移动，同时保持数据不动。

在每个 EVM 中，用户发起的交易和中继交易按顺序执行，而不同 EVM 上的交易则因不存在数据依赖而可以并行执行。这种机制避免了基于Optimistic并行化方法中因冲突导致的重执行，也避免了基于悲观并行化方法中的运行时状态依赖分析及锁定/解锁所带来的开销。因此，PREDA 为区块链系统提供了一种并行且共享无的架构，不同于 Solidity 和 Move 中顺序且共享一切的架构，这种架构可能会引发显著的并发控制开销。

4. 语言

我们将 PREDA 编程模型实现为一种类似于 C/C++ 和 Javascript 的 Algo 风格语言。以下展示了 Solidity 和 PREDA 语言中简化的代币转账函数。

图(a)所示的 Solidity 代码包含一个表示地址余额的合约状态（balances）以及一个 transfer 函数，用于将指定数量的代币从交易发起者（msg.sender）转给接收者（payee）。

图(b)展示的 PREDA 实现中，关键字 @address 定义了可编程合约范围，其中属于合约变量（balance）的状态按照地址分区，由不同的 EVM 分散管理。关键字 relay 标识了一个异步功能中继。

在 PREDA 的实现中有三个部分：

1. 在第(1)部分，@address 关键字定义用户的余额，提供了细粒度的、可分离的状态描述。地址范围变量 balance 对于每个用户地址都有一个唯一的实例。不同用户地址的实例由不同的 EVM 管理，彼此不重叠。
2. 第(2)部分中，transfer 函数定义在相同的地址范围内，当用户初始化转账交易时，通过提供付款人的地址作为目标范围来调用该函数。
3. 第(3)部分中，为了在成功完成提款后继续进行对收款人的存款，使用收款人的地址作为目标范围发起一个 relay，将资金添加到收款人的余额中，并由托管该收款人地址余额实例的 EVM 执行。

上图展示了 PREDA 并行 EVM 系统中代币转账交易的执行流程。Bob 发起一笔调用 transfer 函数的交易，该交易将被引导至托管 Bob 余额的 EVM，在那里完成提款操作。之后，发起一笔中继交易并将其引导至托管 Alice 余额的 EVM，完成存款操作。并行化通过以下两种方式实现：

1. 用户发起交易之间的并行化：由于按地址划分的状态不重叠，用户发起的交易可以无冲突地并行执行。例如，在代币转账合约中，针对每个地址更新付款人状态的不同用户发起交易，可以在不同的 EVM 间并行化。
2. 中继交易的并行化：在 Bob 向 Alice 和 Carol 转账的场景中，针对 Alice 的存款中继交易（从 Bob 到 Alice 的转账）可以与针对 Bob 的提款用户发起交易（在 Bob 到 Carol 的转账中）和对 Carol 的存款交易并行执行。只有通过 PREDA 模型的可分解性，智能合约中的固有并行化才能被底层区块链系统利用，使用户发起交易和中继交易以流水线方式处理，从而促进并行执行。

展望未来

PREDA 标志着区块链性能，尤其是可扩展性方面的重要进步。通过实现异步可分解性，它能够高效处理交易，避免传统同步并行化模型的瓶颈。此方法根据数据依赖将交易分解为微交易，允许并发状态变更，彻底避免写入冲突。

PREDA 的通用性不仅限于通过 @address 按地址划分合约状态。它还支持使用 @type 等关键字自定义划分类型，其中类型可以是任意 Solidity 基本类型，如 @uint。此外，PREDA 支持使用 @global 声明未划分的合约状态，确保每个 EVM 为此类状态维护一致的值。这种状态划分的灵活性增强了模型在各种智能合约中的适应性和有效性。

我们的实验表明，PREDA 在吞吐量和可扩展性方面显著优于其他并行化方法。PREDA 团队将在后续文章中深入探讨我们的研究成果，提供针对不同类型智能合约的更全面比较及对 PREDA 编程模型和语言的详细分析。请持续关注这些深入探索。

声明：

1. 本文转载自【medium】，著作权归属原作者【PREDA Parallel VMs】，如对转载有异议，请联系 Gate Learn 团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由 Gate Learn 团队翻译， 除非另有说明，否则不得复制、传播或抄袭经翻译文章。