• 元宇宙：本站分享元宇宙相关资讯，资讯仅代表作者观点与平台立场无关,仅供参考.

并行执行Blockchain系统调研

  • 2024年9月02日 12:32

撰文：PREDA；编译：ChainFeedsResearch本文的内容和目的

无论是在传统的数据库领域还是在Blockchain技术中，并行执行模型的设计都较为复杂。这是因为，在设计过程中，需要综合考虑多个维度，而每个维度的选择都会对系统的整体性能和可扩展性产生深远影响。本文将深入探讨当前最具代表性的几种Blockchain执行层并行架构，并详细呈现我们针对这些架构在性能和可扩展性方面所做的实验结果。

从一个维度来说，Blockchain领域一直处在对链的高性能和高可扩展性的持续追求中。即使在多链系统和Layer2系统出现后，每个智能合约的执行能力仍受限于单一虚拟机VM的能力。随着并行虚拟机（ParallelVM）的出现，这一局限得到了突破。并行虚拟机允许单个智能合约的交易在多个EVM/VM上同时执行，从而利用更多的CPU核心来提高性能。

我们认为，在众多支持并行VM的高性能Blockchain系统中，Sei（V2）、Aptos、Sui、Crystality和 PREDA 最具代表性，每个系统都具备设计上的独特优势。

在本文开篇，我们展示了第一组实验结果。下图展示了在128核的机器上，执行相同的ERC20智能合约时，Sei、Aptos、Sui、Crystality和PREDA的每秒交易数（TPS）的绝对值。从这组实验结果来看，PREDA模型在五个并行执行系统的TPS和可扩展性比较中占据了显著优势。

其他实验数据和分析，我们将在后文详细展开。

84O9TPXXDzkQlTk7SgklQPm0d3BwRDSTpF7zocfr.jpeg并行执行模型一览

Aptos和Sui两个项目，都衍生于Meta（曾名Facebook）宣告失败的Blockchain项目Diem。两个项目均由前Meta工程师创立——Aptos由AveryChing创立，Sui由SamBlackshear创立。二者随后沿循的技术路线却不尽相同，Aptos严格遵循为Diem开发的原始Move编程语言，但Sui对Move进行了大量修改。

接下来，我们将探讨Aptos和Sui的并行化模型的差异，分析它们采取的不同方法如何影响性能，并重点介绍它们各自的优势。Aptos：采用乐观并行化的高性能Layer1

Aptos是一个Layer1，通过乐观并行化机制实现智能合约的并行执行，从而提升高性能。具体来说在乐观并行化中，交易被初步假设为无状态冲突并以并行方式执行。执行后，系统会检查冲突，并通过回滚和串行执行方式或通过不同的调度，重新执行冲突交易来解决冲突。这种推测执行方法假设大多数交易不会发生冲突，从而最大化并行执行的优势，同时提供了处理冲突的备用机制。

乐观并行化的优势：(1)不需要修改程序：无需对现有代码进行更改即可轻松实现。(2)在冲突只占低到中等百分比的场景下的效率：通过允许许多交易并发进行，并在出现冲突时再处理冲突，最大化吞吐量，在许多现实场景中，冲突相对较少。

Aptos使用MOVE编程语言进行智能合约开发，并在系统实现中使用AptosMOVE虚拟机。Sui：采用悲观并行化的高性能Layer1

Sui采用了一种悲观并行化策略。在悲观并行化中，系统在执行前会预先检查交易是否可能发生资源争用。程序员需要指定每笔交易需要访问的资源（即状态）。系统对每个接收到的交易进行预检查，以检测潜在冲突。只有不涉及与当前执行中的交易发生资源争用的交易，才会被送至执行引擎进行并行执行。

悲观并行化的优势：(1)避免回滚：通过在执行前识别并避免冲突，此方法最小化了回滚和重新执行的需求，从而实现更可预测的性能。(2)在高冲突场景中的效率：在高争用环境中非常有效，确保只有不冲突的交易并行执行，减少冲突解决所带来的开销。

Sui也使用MOVE编程语言，但具有自己的SuiMOVE扩展，并在系统实现中使用SuiMOVE虚拟机。Sei：与Solidity和EVM兼容的乐观并行化

Sei最初推出公链时，其定位是基于CosmosSDK构建的交易型应用链，现在已升级为首个并行化EVM链。在并行执行这一层面，Sei采用了一种类似于Aptos模型的方法，我们称之为乐观并行化。

Sei(V2)所采用的乐观并行，其与众不同之处在于使用Solidity编程语言和标准Ethereum虚拟机（EVM），确保EVM和Solidity兼容性。Crystality和PREDA：并行接力执行架构

Crystality和PREDA都支持并行接力执行分布式架构（ParallelRelay-ExecutionDistributedArchitecture）。PREDA是为多EVMBlockchain架构里的并行化通用智能合约而专门设计。二者的关系是，Crystality是一种用于并行EVM/GPU的编程语言，其基础是PREDA模型。从系统的角度来说，PREDA首次在Blockchain领域，使合约功能的完全并行化成为可能，因此能最大化一组交易的并发性。这确保了所有EVM实例的高效利用，从而达到一定硬件配置条件下的最佳性能和可扩展性。

与Solidity和Move的顺序执行，和SharedEverything的架构设计不同，PREDA模型首次采用了SharedNothing架构，以打破并行执行中的状态依赖，并确保不同的EVM实例永远不会访问同一片合约状态，从而几乎完全避免了写冲突。

在PREDA中，合约函数被分解为多个有序步骤，每个步骤依赖于状态中一个可并行化且无冲突的部分。用户发起的交易首先会被发送到一个持有用户地址状态的EVM上。在交易执行过程中，执行流可以通过发出接力交易从一个持有当前管理所需合约状态的EVM切换到另一个EVM的方式，实现数据不动，而执行流根据数据依赖关系在EVM之间移动。五大代表性合约的实验数据

在我们的评估中，我们测试了五个广泛使用的智能合约——ETHTokenTransfer、Voting、Airdrop、CryptoKitties和MillionPixel，以及MyToken(ERC20)。这些合约在包括Sei、Aptos、Sui、Crystality和PREDA在内的各种Blockchain系统上执行。我们进行了详细的实验，以比较不同并行执行系统的性能，重点关注每秒交易量(TPS)和加速比，这些指标衡量了在多个虚拟机上与各系统单个虚拟机上执行时相对的性能提升。

所有详细的实验数据，包括绝对TPS值和加速比，请参阅完整的实验报告。

ETHTokenTransfer合约：该实验使用了与标准ERC20智能合约相同的实际历史ETH交易。

Voting合约：Voting合约是PREDA模型如何简化并行投票算法的绝好例子。它利用Crystality和PREDA的数据拆分、接力和执行机制，在绝对TPS和加速比上均优于乐观（Aptos）和悲观（Sui）并行化方法。原本在Solidity中的顺序算法现在允许跨虚拟机并行投票，并将结果从临时数组中聚合。

AirDrop：此合约从一个地址向多个地址触发多次Tokens或NFT转移。它具有一对多的状态更改模式。在这种情况下，Sei、Aptos或Sui中的两个交易不能并行执行。只有通过并行粒度更高的PREDA模型，能使这些交易能够以流水线模式并行处理。

CryptoKitties：这个合约是Ethereum上的一款流行游戏合约，涉及根据父母猫的基因繁殖子代猫。与前述合约不同，这个合约在处理用户发起的交易时需要访问多个地址状态，包括「父猫」、「母猫」和「新生猫」。该合约在从父母基因中计算新生猫的基因时还涉及比前述合约更复杂的计算。

MillionPixel：在Ethereum上的这个游戏合约中，用户们要抢先在地图上标记坐标。这个智能合约用于展示PREDA模型的灵活性。除了按地址划分合约状态外，程序员还可以定制分区键，例如在这种情况下从地址类型切换为uint32类型。

P6YUHmdO7h3ivnJc5sG8sZQZmE5T3r7YUSbcmJm6.jpeg

Aptos交易执行包括执行和验证两个步骤，测试数据显示其中大量的交易执行状态被标记为「SUSPEND」（挂起），且这些交易执行耗时很长。「SUSPEND」意味着交易执行暂停，直到其状态依赖关系得到解决才可以恢复执行。对于64个虚拟机上的随机交易，执行和验证的总次数分别为102,219次和139,426次。而对于历史交易，这些数字增加到186,948次和667,148次，交易挂起次数从66次增加到46,913次。因此，当交易执行中发生大量状态冲突时，回滚成为乐观并行化的沉重负担。

Sui执行中的时间分析

以下图表展示了Sui在ETHToken转账合约测试和Voting合约测试中的耗时明细。在Sui的并行执行引擎中，有三个主要步骤：(1)排队时间：交易被事务管理器选中之前的等待时间；(2)任务管理时间：交易被放入Sui的ExecutingTxns哈希图或PendingTxns哈希图，到它被Sui的ExecutionDriver接收之间的时间；(3)函数执行时间：由ExecutionDriver中的工作线程执行合约函数的时间。

任务管理时间涉Locking和等待两个部分。对比这两个图表可以看出，Voting测试中的任务管理时间占整个执行时间的比例明显比ETHToken转账测试大得多。这是因为在Voting测试中，访问共享对象需要通过Locking和等待来避免冲突，使得任务管理时间比函数执行时间和排队时间多了2到4个数量级。相比之下，在ETHToken转账测试中，由于只使用了OwnedObjects，绕过了并发控制，任务管理时间要少得多。

Aptos和Sui的局限性

总结来说，Aptos采用乐观并行化，即使在存在冲突的情况下也允许并行交易执行。这种基于乐观并发控制（OCC）的方法对以读取为主的工作负载非常有效，这在写入请求稀少的数据库和大数据系统中较为常见。然而，在Blockchain系统中，由于链上执行涉及的gas费用，这种方法可能会产生巨大的Gas开销。实际上，用户通常将只读请求（例如历史交易或区块查询）发送到像Etherscan这样的链下数据库，而写入请求则用于链上执行。在这种情况下，像Aptos这样的OCC系统将频繁遇到交易「Suspend」（中止）和挂起，从而降低并行虚拟机的整体性能。

相比之下，Sui采用悲观并行化，严格验证交易之间的状态依赖性，并通过Locking机制防止执行过程中的冲突。这种基于悲观并发控制（PCC）的方法更适合计算密集型工作负载，在这种情况下，PCC相关的开销甚至小到忽略不计。但在逻辑简单的操作中，PCC相关的开销很容易成为性能瓶颈。在现实世界里，许多在Blockchain系统上执行的交易，如ERC20Token转账、MoveToken转账或NFT转账，都涉及相对简单的操作。具体来说，ERC20Tokens转账通常涉及从一个地址减去一定金额并将其加到另一个地址。类似地，MoveToken转账或NFT转账涉及将一个资源或对象从一个地址移动到另一个地址。即使要考虑所有权验证等额外检查，这些操作也非常快速。此时，PCC的相关开销就会成为并行系统性能的限制因素。

为了解决这些挑战，PREDA提出了一个几乎完全避免PCC开销和OCC重新执行需求的系统。该方法通过高效地拆分链上状态实现几乎无冲突的并行执行。

Crystality和PREDA的性能表现

在所有合约测试中，Crystality和PREDA的性能数据都显著优于Sei、Aptos和Sui，其中PREDA表现尤为突出，因为它以原生二进制模式而非WASM进行执行。这种高性能得益于几乎无冲突的并行执行。PREDA从设计之初就考虑了以下2个关键环节：

定义不同的合约状态范围，系统将依据这个范围进行状态拆分和维护。

要实现交易的执行流从一个虚拟机到另一个虚拟机的切换。

PREDA的核心在于引入了可编程作用域（ProgrammableContractScopes），将合约状态拆分为不重叠、可并行的细粒度片段；并引入了异步函数接力（AsynchronousFunctionalRelay），用于描述不同EVM之间的执行流切换。

我们来进一步解释这些概念的含义，在PREDA中，一个合约函数被分解为多个有序步骤，每个步骤依赖于单一的、可并行的状态片段，且不产生冲突。

举个例子：通常情况下，Token转账涉及两个步骤：一是提取步骤，即访问Sender的状态并提取指定数量的Token的，二是存入步骤，即访问Recipient的状态并存入相应数量的Token。像Sei、Aptos和Sui等实现的最新并行机制，试图同步执行每个交易中的所有步骤。如果两个交易之间的访问状态是共享的或被更新的，比如当Sender或Recipient相同时，这两个交易将无法并行执行。

然而，PREDA采用了一种可拆分且异步的机制，其中交易的各个步骤根据其数据访问依赖性进行分解，使每个步骤能够独立于其他步骤异步执行。对相同状态的访问严格按照原始交易块中确定的顺序进行序列化，并由共识算法保证，即由区块创建者排序。

例如，Token转账交易Txn0（将Tokens从地址状态A转移到状态B）和Txn1（从状态A转移到状态C）可以按照顺序两次访问A（分别用于Txn0和Txn1），然后并行访问B和C。

9OivJEc236LUJLYi5nlDgf3athD94z4xpcmjIy3a.jpeg

元宇宙最新

元宇宙热门

Copyright © 2021.Company 元宇宙YITB.COM All rights reserved.元宇宙YITB.COM