没有Massa的并行执行区块链系统调研
编者按：我认为在并行区块链领域进行横向比较时，没有massa的加入，整个调研的结果将是有失水准的，不过我们还是可以看看其他区块链都是有哪些特点。
目录
2. 并行执行模型一览
Aptos：采用乐观并行化的高性能 Layer 1
Sui：采用悲观并行化的高性能 Layer 1
Sei：与 Solidity 和 EVM 兼容的乐观并行化
Crystality 和 PREDA：并行接力执行架构
3. 五大代表性合约的实验数据
4. 由实验结果得到的启发
4.1 对比乐观与悲观并行方法
Aptos 执行中的时间分析
Sui 执行中的时间分析
Aptos和Sui的局限性
4. 2 Crystality 和 PREDA 的性能表现
PREDA和Crystality 的局限性
5. 结论
无论是在传统的数据库领域还是在区块链技术中，并行执行模型的设计都较为复杂。 这是因为，在设计过程中，需要综合考虑多个维度，而每个维度的选择都会对系统的整体性能和可扩展性产生深远影响。本文将深入探讨当前最具代表性的几种区块链执行层并行架构，并详细呈现我们针对这些架构在性能和可扩展性方面所做的实验结果。
从一个维度来说，区块链领域一直处在对链的高性能和高可扩展性的持续追求中。即使在多链系统和Layer 2系统出现后，每个智能合约的执行能力仍受限于单一虚拟机VM的能力。随着并行虚拟机（Parallel VM）的出现，这一局限得到了突破。并行虚拟机允许单个智能合约的交易在多个EVM/VM上同时执行，从而利用更多的CPU核心来提高性能。
我们认为，在众多支持并行VM的高性能区块链系统中，Sei（V2）、Aptos、Sui、Crystality和PREDA最具代表性，每个系统都具备设计上的独特优势。
在本文开篇，我们展示了第一组实验结果。下图展示了在128核的机器上，执行相同的ERC20智能合约时，Sei、Aptos、Sui、Crystality和PREDA的每秒交易数（TPS）的绝对值。从这组实验结果来看，PREDA模型在五个并行执行系统的TPS和可扩展性比较中占据了显著优势。
其他实验数据和分析，我们将在后文详细展开。
https://lh7-rt.googleusercontent.com/docsz/AD_4nXf4FKiDhF-b8Z58VZWYMyzpXoijVROZmpcdHiEtgEjcQBlmGNPW-jbn_BYvA0GprfxyGxeEkXEw-tWtv5ZEwFZr9Xl8hd6UyA6f1lsQoLXHgrRPM7MOluIrKnqkzYHiXd9Pcy87swtifHVHnDTueCXNU4I?key=jTfkx_omQRc7yL1uKcft3w
以下，我们将详细说明我们实验中的具体方法和操作：
我们首先比较了五个系统的TPS值，即吞吐量。在不同链上进行的TPS对比实验中所用的交易量相同。
考虑到不同系统中采用的不同编程语言和底层虚拟机不同，单一的吞吐量比较不能完全说明系统的优劣，我们还进行了相对加速结果即Speedup Ratio的比较，即同样数量的交易在多个VM相对于在一个VM上执行的加速效果。在Sui、Aptos、Crystality和PREDA中，每个线程都分配了一个专用CPU core。
所有详细的实验数据，包括绝对TPS值和加速比，请参阅完整的实验报告。
下表中展示了实验中所用的数据来源、实施过程和评估方法。
| 硬件配置 | 在一台高性能多核机器上进行实验，该机器配备了两颗AMD EPYC 7742 CPU（64核，2.25GHz - 3.4GHz最大加速）和2TB内存，运行Linux Ubuntu 20.04。 |
|---|---|
| 软件配置 | ● 上述评估集中在以太坊上的ERC代币转移实验。本文接下来的评估涉及各种智能合约，包括ETH转账、投票、空投、CryptoKitties和MillionPixel，这些合约最初都在以太坊上部署和执行。 |
| ● 对于Sei，使用标准的Solidity合约。对于Sui和Aptos，分别使用Sui Move和Aptos Move语言实现等效合约。 | |
| ● 对于PREDA和Crystality的评估，分别使用PREDA语言和在Solidity基础上的扩展语言实现等效合约，其中Crystality合约通过其源代码到源代码转译器转换为标准的Solidity合约。 | |
| 实验设置 | 这些五个系统的最新开源代码均从其GitHub库中获取。具体如下: |
| ● Sei (V2): main branch, commit ID 867a…71a3 | |
| ● Aptos: main branch, commit ID a182...7b0b | |
| ● Sui: testnet branch, commit ID 4dbc...c9a0 | |
| ● Crystality: testnet branch, commit ID a8cf...6a98 | |
| ● PREDA: main branch, commit ID 13e9...1806 | |
| 数据来源 | 在Sei中，每个轻量级的Goroutine由其Go运行时管理。使用随机生成的交易对ERC20、投票、空投、CryptoKitties和MillionPixel合约进行评估。具体而言，每个系统生成10,000个地址和100,000笔交易。 |
| 对于TokenTransfer，重放了历史ETH交易。历史数据集包括2024年1月的ETH转账交易，准备了100,000笔连续交易的批次。结果显示了第一个批次的情况，包括2024年1月1日凌晨12:00至04:48（UTC）的区块高度18,908,895至18,910,315之间的100,000笔交易。经过适当格式转换后，该数据集在所有五个系统上分别重放。 | |
| 说明 | |
| 在评估中，采用了相似的系统设置进行并行执行，排除了共识开销，但包括了其他元素，如交易签名验证。所有五个系统均配置在其单节点基准测试框架中，并尽可能优化性能。 |
2. 并行执行模型一览
Aptos 和 Sui两个项目，都衍生于 Meta（ 曾名Facebook）宣告失败的区块链项目 Diem。两个项目均由前 Meta 工程师创立——Aptos 由 Avery Ching 创立，Sui 由 Sam Blackshear 创立。二者随后沿循的技术路线却不尽相同，Aptos 严格遵循为 Diem 开发的原始 Move 编程语言，但 Sui 对 Move 进行了大量修改。
接下来，我们将探讨 Aptos 和 Sui 的并行化模型的差异，分析它们采取的不同方法如何影响性能，并重点介绍它们各自的优势。
Aptos：采用乐观并行化的高性能 Layer 1
Aptos 是一个 Layer 1，通过乐观并行化机制实现智能合约的并行执行，从而提升高性能。具体来说在乐观并行化中，交易被初步假设为无状态冲突并以并行方式执行。执行后，系统会检查冲突，并通过回滚和串行执行方式或通过不同的调度，重新执行冲突交易来解决冲突。这种推测执行方法假设大多数交易不会发生冲突，从而最大化并行执行的优势，同时提供了处理冲突的备用机制。
乐观并行化的优势：(1) 不需要修改程序：无需对现有代码进行更改即可轻松实现。(2) 在冲突只占低到中等百分比的场景下的效率：通过允许许多交易并发进行，并在出现冲突时再处理冲突，最大化吞吐量，在许多现实场景中，冲突相对较少。
Aptos 使用 MOVE 编程语言进行智能合约开发，并在系统实现中使用 Aptos MOVE 虚拟机。
Sui：采用悲观并行化的高性能 Layer 1
Sui 采用了一种悲观并行化策略。在悲观并行化中，系统在执行前会预先检查交易是否可能发生资源争用。程序员需要指定每笔交易需要访问的资源（即状态）。系统对每个接收到的交易进行预检查，以检测潜在冲突。只有不涉及与当前执行中的交易发生资源争用的交易，才会被送至执行引擎进行并行执行。
悲观并行化的优势：(1) 避免回滚：通过在执行前识别并避免冲突，此方法最小化了回滚和重新执行的需求，从而实现更可预测的性能。(2) 在高冲突场景中的效率：在高争用环境中非常有效，确保只有不冲突的交易并行执行，减少冲突解决所带来的开销。
Sui 也使用 MOVE 编程语言，但具有自己的 Sui MOVE 扩展，并在系统实现中使用 Sui MOVE 虚拟机。
Sei：与 Solidity 和 EVM 兼容的乐观并行化
Sei最初推出公链时，其定位是基于 Cosmos SDK 构建的交易型应用链，现在已升级为首个并行化 EVM 链。在并行执行这一层面，Sei 采用了一种类似于 Aptos 模型的方法，我们称之为乐观并行化。
Sei (V2) 所采用的乐观并行，其与众不同之处在于使用 Solidity 编程语言和标准以太坊虚拟机（EVM），确保 EVM 和 Solidity 兼容性。
Crystality 和 PREDA：并行接力执行架构
Crystality 和 PREDA 都支持并行接力执行分布式架构（Parallel Relay-Execution Distributed Architecture）。PREDA 是为多 EVM 区块链架构里的并行化通用智能合约而专门设计。二者的关系是，Crystality 是一种用于并行 EVM/GPU 的编程语言，其基础是 PREDA 模型。从系统的角度来说，PREDA首次在区块链领域，使合约功能的完全并行化成为可能，因此能最大化一组交易的并发性。这确保了所有 EVM 实例的高效利用，从而达到一定硬件配置条件下的最佳性能和可扩展性。
与 Solidity 和 Move 的顺序执行，和Shared Everything的架构设计不同，PREDA 模型首次采用了Shared Nothing架构，以打破并行执行中的状态依赖，并确保不同的 EVM 实例永远不会访问同一片合约状态，从而几乎完全避免了写冲突。
在 PREDA 中，合约函数被分解为多个有序步骤，每个步骤依赖于状态中一个可并行化且无冲突的部分。用户发起的交易首先会被发送到一个持有用户地址状态的 EVM 上。在交易执行过程中，执行流可以通过发出接力交易从一个持有当前管理所需合约状态的 EVM 切换到另一个 EVM的方式，实现数据不动，而执行流根据数据依赖关系在 EVM 之间移动。
3. 五大代表性合约的实验数据
在我们的评估中，我们测试了五个广泛使用的智能合约——ETH TokenTransfer、Voting、Airdrop、CryptoKitties 和 MillionPixel，以及 MyToken (ERC20)。这些合约在包括 Sei、Aptos、Sui、Crystality 和 PREDA 在内的各种区块链系统上执行。我们进行了详细的实验，以比较不同并行执行系统的性能，重点关注每秒交易量 (TPS) 和加速比，这些指标衡量了在多个虚拟机上与各系统单个虚拟机上执行时相对的性能提升。
所有详细的实验数据，包括绝对TPS值和加速比，请参阅完整的实验报告。
- ETH TokenTransfer 合约：该实验使用了与标准 ERC20 智能合约相同的实际历史 ETH 交易。
- Voting 合约：Voting 合约是PREDA 模型如何简化并行投票算法的绝好例子。它利用 Crystality 和 PREDA 的数据拆分、接力和执行机制，在绝对 TPS 和加速比上均优于乐观（Aptos）和悲观（Sui）并行化方法。原本在 Solidity 中的顺序算法现在允许跨虚拟机并行投票，并将结果从临时数组中聚合。
- AirDrop：此合约从一个地址向多个地址触发多次代币或 NFT 转移。它具有一对多的状态更改模式。在这种情况下，Sei、Aptos 或 Sui 中的两个交易不能并行执行。只有通过并行粒度更高的PREDA 模型，能使这些交易能够以流水线模式并行处理。
- CryptoKitties：这个合约是以太坊上的一款流行游戏合约，涉及根据父母猫的基因繁殖子代猫。与前述合约不同，这个合约在处理用户发起的交易时需要访问多个地址状态，包括“父猫”、“母猫”和“新生猫”。该合约在从父母基因中计算新生猫的基因时还涉及比前述合约更复杂的计算。
- MillionPixel：在以太坊上的这个游戏合约中，用户们要抢先在地图上标记坐标。这个智能合约用于展示 PREDA 模型的灵活性。除了按地址划分合约状态外，程序员还可以定制分区键，例如在这种情况下从地址类型切换为 uint32 类型。
为了方便读者理解上述大量数据，以下重点关注分析两个特别有代表性的合约。
ETH Token转账合约：在回放 ETH 历史交易数据时，五个系统的绝对吞吐量和可扩展性比率均较 ERC20 实验有所下降。这是因为历史交易中重复的地址导致了状态争用（读写冲突或写写冲突），从而阻碍了这些交易在并行 EVM 中的并发执行。
Voting 合约：Sei 合约几乎只能按顺序执行，在运行多个 EVM 时没有速度提升。如果算法没有转变为并行算法，其他系统也会出现类似的结果。对于 Aptos 和 Sui 的并行实现，必须为“proposal”变量的临时结果在不同地址初始化多个资源。此外，并行实现还必须基于投票者的地址提供手动调度，将投票者的交易引导至不同的虚拟机，并访问临时结果以进行并行执行。
4. 由实验结果得到的启发
从实验结果中我们得到了以下启示：
4.1 对比乐观与悲观并行方法
Aptos 和 Sui 在不同的特定场景中各有其最佳表现。在 ERC20转账案例中，Aptos 表现优于 Sui，这是因为 ERC20 转账的每笔交易中使用随机生成的地址，导致冲突非常少。相反，在 ETH 测试案例中，由于回放 ETH 历史交易带来的大量冲突，Sui 的表现优于 Aptos。
Aptos 执行中的时间分析
下表展示了在运行这2个合约时 Aptos 的性能分析数据（使用相同的智能合约，但交易数据分别采用的随机生成或历史交易数据）。由于性能分析十分耗时，测试所用的并行虚拟机数量最多限制在64 个。
https://lh7-rt.googleusercontent.com/docsz/AD_4nXdkUptyscd6XOp0-szk3Z3BndQuseMQNI0_HfvlBNqXzmqzNbb54btaH_S-Ipl8Qj-ZVT7pJAnCHkxvNXeoloPyS6xSr_0zd2kKL8gSER51FkmSgTG26LrVuvTIhuilgsbK80lJmz7px2Jr4EATSZvCZNg?key=jTfkx_omQRc7yL1uKcft3w
https://lh7-rt.googleusercontent.com/docsz/AD_4nXe_TWmxf13j09QzG5YQ7-0ZxZcdhwnAkYIH2_Kaa7Ol_hz4mGLcG7Cm9d9i1Zpp_X9MwwIaITT2EWXLAqSBEO6FvUVS1r2g4DN_Xtc4LzRo9LZBi7n3zhNGAj6yJ-VRBFvZprAyK6CYirt4o9KrfMUsUwi9?key=jTfkx_omQRc7yL1uKcft3w
Aptos 交易执行包括执行和验证两个步骤，测试数据显示其中大量的交易执行状态被标记为 "SUSPEND"（挂起），且这些交易执行耗时很长。”SUSPEND”意味着交易执行暂停，直到其状态依赖关系得到解决才可以恢复执行。对于64个虚拟机上的随机交易，执行和验证的总次数分别为102,219次和139,426次。而对于历史交易，这些数字增加到186,948次和667,148次，交易挂起次数从66次增加到46,913次。因此，当交易执行中发生大量状态冲突时，回滚成为乐观并行化的沉重负担。
Sui 执行中的时间分析
以下图表展示了 Sui 在 ETH Token转账合约测试和Voting合约测试中的耗时明细。在 Sui 的并行执行引擎中，有三个主要步骤：(1) 排队时间：交易被事务管理器选中之前的等待时间；(2) 任务管理时间：交易被放入 Sui 的 Executing Txns 哈希图或 Pending Txns 哈希图，到它被 Sui 的 Execution Driver 接收之间的时间；(3) 函数执行时间：由 Execution Driver 中的工作线程执行合约函数的时间。
https://lh7-rt.googleusercontent.com/docsz/AD_4nXcC-nZ-4yN9_M3H4AUZT_Bt-K2j9aGpEcwq8CV5YRtzY8CBXId03rfD0-Y7YN2RRavZutUGUrOGsi0NkLoxLycAfF65ey5stysXdEHWDdKlHA-t4Jic6hwPWiziYPOvvXyoHaDNPS2-_shh9WnYA2hfy7kz?key=jTfkx_omQRc7yL1uKcft3w
任务管理时间涉Locking和等待两个部分。对比这两个图表可以看出，Voting测试中的任务管理时间占整个执行时间的比例明显比ETH Token转账测试大得多。这是因为在Voting测试中，访问共享对象需要通过Locking和等待来避免冲突，使得任务管理时间比函数执行时间和排队时间多了2到4个数量级。相比之下，在ETH Token转账测试中，由于只使用了Owned Objects，绕过了并发控制，任务管理时间要少得多。
Aptos和Sui的局限性
总结来说，Aptos采用乐观并行化，即使在存在冲突的情况下也允许并行交易执行。这种基于乐观并发控制（OCC）的方法对以读取为主的工作负载非常有效，这在写入请求稀少的数据库和大数据系统中较为常见。然而，在区块链系统中，由于链上执行涉及的gas费用，这种方法可能会产生巨大的Gas开销。实际上，用户通常将只读请求（例如历史交易或区块查询）发送到像Etherscan这样的链下数据库，而写入请求则用于链上执行。在这种情况下，像Aptos这样的OCC系统将频繁遇到交易”Suspend”（中止）和挂起，从而降低并行虚拟机的整体性能。
相比之下，Sui采用悲观并行化，严格验证交易之间的状态依赖性，并通过Locking机制防止执行过程中的冲突。这种基于悲观并发控制（PCC）的方法更适合计算密集型工作负载，在这种情况下，PCC相关的开销甚至小到忽略不计。但**在逻辑简单的操作中，PCC相关的开销很容易成为性能瓶颈。**在现实世界里，许多在区块链系统上执行的交易，如ERC20 Token转账、Move Token转账或NFT转账，都涉及相对简单的操作。具体来说，ERC20代币转账通常涉及从一个地址减去一定金额并将其加到另一个地址。类似地，Move Token转账或NFT转账涉及将一个资源或对象从一个地址移动到另一个地址。即使要考虑所有权验证等额外检查， 这些操作也非常快速。此时，PCC的相关开销就会成为并行系统性能的限制因素。
为了解决这些挑战，PREDA 提出了一个几乎完全避免PCC开销和OCC重新执行需求的系统。该方法通过高效地拆分链上状态实现几乎无冲突的并行执行。
4. 2 Crystality 和 PREDA 的性能表现
在所有合约测试中，Crystality 和 PREDA 的性能数据都显著优于 Sei、Aptos 和 Sui，其中 PREDA 表现尤为突出，因为它以原生二进制模式而非 WASM 进行执行。这种高性能得益于几乎无冲突的并行执行。PREDA从设计之初就考虑了以下2个关键环节：
-
定义不同的合约状态范围，系统将依据这个范围进行状态拆分和维护。
-
要实现交易的执行流从一个虚拟机到另一个虚拟机的切换。
PREDA 的核心在于引入了可编程作用域（Programmable Contract Scopes），将合约状态拆分为不重叠、可并行的细粒度片段；并引入了异步函数接力（Asynchronous Functional Relay），用于描述不同 EVM 之间的执行流切换。
我们来进一步解释这些概念的含义，在 PREDA 中，一个合约函数被分解为多个有序步骤，每个步骤依赖于单一的、可并行的状态片段，且不产生冲突。
举个例子：通常情况下，Token转账涉及两个步骤：一是提取步骤**，**即访问Sender的状态并提取指定数量的Token的，二是存入步骤，即访问Recipient的状态并存入相应数量的Token。像 Sei、Aptos 和 Sui 等实现的最新并行机制，试图同步执行每个交易中的所有步骤。如果两个交易之间的访问状态是共享的或被更新的，比如当Sender或Recipient相同时，这两个交易将无法并行执行。
然而，PREDA 采用了一种可拆分且异步的机制，其中交易的各个步骤根据其数据访问依赖性进行分解，使每个步骤能够独立于其他步骤异步执行。对相同状态的访问严格按照原始交易块中确定的顺序进行序列化，并由共识算法保证，即由区块创建者排序。
例如，Token转账交易 Txn 0（将代币从地址状态 A 转移到状态 B）和 Txn 1（从状态 A 转移到状态 C）可以按照顺序两次访问 A（分别用于 Txn 0 和 Txn 1），然后并行访问 B 和 C**。**
Aptos，Sei和PREDA中并行执行的架构比较
Aptos，Sei和PREDA中并行执行的架构比较
PREDA和Crystality 的局限性
尽管 PREDA和Crystality能为区块链系统赋能， 提供显著的性能优势，但它们的局限性也体现在如下方面。
- 并行 EVM 之间工作负载不均衡
Crystality 的数据拆分和执行流重定向机制可能会导致并行 EVM 在运行时出现负载不均衡的问题。我们在用 MyToken 合约重放历史 ETH Token转账交易时观察到了这一问题。
为了评估负载分布情况，我们统计了每个 EVM 上执行的交易数量，包括原始交易和接力交易，然后计算了这些数量的极差和标准差。结果显示，在 64 个 EVM 上执行的交易数量极差与 2 个 EVM 上的范围相当，这意味着在某些EVM地址存在热点问题（即历史交易集中发生在一部分地址上）。对 ETH 数据集的进一步调查发现，每一个热点地址涉及高达 4000 多笔交易。这里必须指出的是，据我们了解，Aptos 和 Sui 在这种情况下，也无法做并行化执行。
我们的测试数据表明，随着 EVM 数量的增加，标准差有所降低，这意味着增加更多的 EVM 有助于缓解负载不平衡问题。
为了解决区块链上的热点问题，一个可行的解决方案是使用多个地址而不是单个地址来发送或接收代币。如果负载不均衡是由于几个非热点地址映射到同一虚拟机造成的，那么分片（Sharding）区块链中的现有方法，例如数据迁移，可能会有所帮助。
- 程序重写
PREDA和Crystality的另一个显著的局限性是，开发者需要使用 directives重写智能合约。如果有一种工具可以自动将 Solidity、Move 或 Rust 编写的现有智能合约翻译为等效的 Crystality 智能合约，将大大优化开发者的体验。从前人经验看来，也并不难实现，已经有一些研究探索了不同语言之间的翻译，例如从 Solidity 到 Move 和从 Python 到 Solidity。
自然语言处理的技术进步，大大增强了自动代码生成的潜力。这些进展结合基于规则和模式的编译器翻译技术（如用于大数据的 SQL 到 MapReduce 翻译和用于深度学习的计算图到矩阵计算的翻译）完全可以为开发自动化的智能合约翻译工具， 提供助力。
5. 结论
Sei、Aptos、Sui 与 Crystality/PREDA 之间的性能对比突显了区块链并行化领域的不断演变。Aptos（与 Sei）和 Sui 分别展示了乐观并行化和悲观并行化机制的潜力，各自在不同场景下展现了优势。然而，Crystality 和 PREDA 显著的性能提升表明，更先进的并行化模型可能是解锁更高层级的可扩展性和效率的关键。
为了总结我们对区块链领域三种主要并行化方法的探索和观察，我们整理汇总了一张表格。如果您想从这篇文章中获得一份Takeaway，那就是本表格中的内容。
| 乐观并行执行 | 悲观并行执行 | 异步并行接力执行 | |
|---|---|---|---|
| 执行模型 | 先执行，再验证 | 先验证，再执行 | 状态拆分，并以无重叠状态依赖异步执行 |
| 冲突处理 | 在执行后检测冲突，并回滚冲突交易 | 通过在执行前锁定资源来防止冲突 | 几乎无需回滚 |
| 无静态分析 | |||
| 通过将交易分解为独立的、异步的步骤，几乎避免了所有冲突。 | |||
| 吞吐量 | 若冲突少则高 | 由于锁定和减少的并行度，较低 | 高，具备线性扩展性 |
| （随着异步步骤和独立状态的增加可线性扩展）和高并发性。 | |||
| 并发能力 | 高并发性，但有可能产生回滚成本 | 由于锁定，限制了并发性 | 设计上具有高并发性，几乎无需回滚 |
| 资源利用率 | 良好，但由于回滚开销可能受到影响 | 由于等待锁定，较差 | 出色，资源利用率非常高 |
| 部署难度 | 中等，需要冲突检测和回滚机制 | 简单，但可能在高争用管理中表现欠佳 | 高，需要拆分状态并理解异步编程 |
| 回滚开销 | 在高冲突场景中较高 | 无，冲突在执行前已预防 | 几乎无，冲突大多通过状态拆分避免了 |
| 示例 | Aptos, SEI v2, Monad | Sui, Solana, SEI v1, Zilliqa-CoSplit | Crystality (PREDA Model) |
| 优点 | 在低冲突环境中具有高吞吐量；减少争用和等待时间 | 确保数据完整性；易于理解和实现 | 高并发性和可扩展性；几乎无需回滚或复杂的冲突解决 |
| 局限性 | 在高冲突环境中回滚成本高；冲突检测和解决的复杂性较高 | 并行度和吞吐量较低；高争用和等待时间 | 并行VM间的工作负载失衡；开发者需要重新设计编程语言，有学习成本 |
