以Reddio为例,阐述并行EVM的最佳化之路
  • 14
以Reddio为例,阐述并行EVM的最佳化之路 极客 Web3 20241029 1000 我们将从更具体的细节入手,为大家详细解释传统EVM的局限性,以及并行EVM的优势。

作者:雾月,极客web3

众所周知,EVM的定位是以太坊的“执行引擎”和“智能合约执行环境”,可以说是以太坊最重要的核心组件之一。公链是一个包含成千上万节点的开放性网络,不同节点的硬体参数相差甚大,若想让智能合约在多个节点上都跑出相同结果,满足“一致性”,要设法在不同设备上都搭建出相同的环境,而虚拟机器可以达到这个效果。

以太坊的虚拟机器EVM能在不同作业系统如Windows、Linux、macOS和装置上以相同的方式来运行智慧合约,这种跨平台相容性确保每个节点运行合约后,都能得到一致的结果。最典型的例子就是Java虚拟机器JVM。

我们平常在区块浏览器里看到的智能合约,都是先被编译成EVM字节码,然后才储存到链上的。 EVM在执行合约时,直接依序读取这些字节码,字节码对应的每条指令opCode都有对应的Gas成本。 EVM会追踪每个指令在执行过程中的Gas消耗,消耗量则取决于操作的复杂度。

此外,作为以太坊的核心执行引擎,EVM采用串行执行的方式处理交易,所有交易在单一队列中排队并按照确定顺序先后执行。之所以不用并行化的方式,是因为区块链要严格满足一致性,一批交易在所有节点中都要按相同次序来处理,如果将交易处理并行化,难以精确的预判交易次序,除非引入对应的调度演算法,但这会比较复杂。

201415年的以太坊创始团队出于时间紧迫,选用了串列执行的方式。因为它设计简单且易于维护。然而随着区块链技术的迭代和用户群体越来越大,区块链对TPS和吞吐量的要求越来越高,在Rollup技术出现并成熟落地后,EVM串行执行带来的效能瓶颈在以太坊二层身上已经暴露无疑。

Sequencer作为Layer2的关键组件,以单一伺服器的形式承接所有运算任务,如果与Sequencer配合的外部模组的效率都足够高,则最终的瓶颈将取决于Sequencer本身的效率,此时串行执行将成为巨大的阻碍。

opBNB团队曾透过对DA层和资料读写模组进行极致优化,Sequencer每秒最多可执行约2000多笔ERC20转帐。这个数字看起来很高,但如果要处理的交易比ERC20转帐复杂很多,TPS数值必然会大打折扣。所以说,交易处理的平行化将是未来的必然趋势。

以下我们将从更具体的细节入手,为大家详细解释传统EVM的局限性,以及并行EVM的优势。

以太坊交易执行的两大核心组件

在程式码模组层面,除EVM外,goethereum中与交易执行相关的另一个核心元件是stateDB,用于管理以太坊中的帐户状态和资料储存。以太坊采用名为Merkle Patricia Trie的树状结构来充当资料库索引目录,EVM每一次交易执行都会变更stateDB中存放的某些数据,这些变更最终会反映在Merkle Patricia Trie后面简称全域状态树中。

具体来说,stateDB负责维护所有以太坊帐户的状态,包括EOA帐户和合约帐户,其储存的资料包括帐户余额、智慧合约代码等。在交易执行过程中,stateDB会对对应帐户的资料进行读写。而在交易执行结束后,stateDB需要将新的状态提交到底层资料库如LevelDB中,进行持久化处理。

总的来说,EVM负责解释和执行智能合约指令,根据计算结果变更区块链上的状态,而stateDB则充当全局状态存储,管理所有帐户和合约的状态变化。两者协作建构了以太坊的交易执行环境。

串行执行的具体过程

以太坊的交易类型分两种,即EOA转帐和合约交易。 EOA转帐是最简单的交易类型,即普通帐户之间的ETH转帐。这种交易不涉及合约调用,处理速度非常快。由于操作简单,EOA转帐收取的gas费极低。

与简单的EOA转帐不同,合约交易会涉及智慧合约的呼叫与执行。 EVM在处理合约交易时,要逐条解释和执行智能合约中的字节码指令,合约的逻辑越复杂,涉及的指令越多,消耗的资源越多。

举例来说,ERC20转帐的处理时间大约是EOA转帐的2倍,而对于更复杂的智慧合约,如Uniswap上的交易操作,耗时更长,甚至可以比EOA转帐慢十几倍。这是因为DeFi协议需要在交易时处理流动性池、价格计算、代币swap等复杂逻辑,需要进行非常复杂的计算。

那么在串列执行模式下, EVM与stateDB这两个元件是如何协同处理交易的呢?

在以太坊的设计中,一个区块内的交易会按先后次序被一笔处理,每笔交易tx都会有一个独立实例,用于执行该交易的具体操作。尽管每笔交易会使用不同的EVM实例,但所有交易要共用同一个状态资料库,也就是stateDB。

在交易执行过程中,EVM需要不断与stateDB交互,从stateDB中读取相关的数据,并将变更后的资料写回stateDB。

我们从程式码角度大致看下EVM和stateDB是如何协作执行交易的:

1 processBlock()函数会呼叫Process()函数处理一个区块中包含的交易;

以Reddio为例,阐述并行EVM的最佳化之路

ave ai官网入口

2 Process()函数中定义了一个for循环,可以看到交易是被一笔一笔地执行的;

3 在所有交易处理完毕后,processBlock()函数呼叫writeBlockWithState()函数,再呼叫statedbCommit()函数,提交状态变更结果。

当一个区块中所有交易都被执行完毕后,stateDB中的资料会被Commit到前面提到的全域状态树Merkle Patricia Trie,并产生新的状态根stateRoot。状态根是每个区块中的重要参数,它记录了区块执行后新的全域状态的压缩结果。

我们不难理解,EVM的串行执行模式瓶颈很明显:交易必须按顺序排队执行,如果出现耗时很久的智能合约交易,在其处理完毕前,其他交易只能等待,这显然无法充分利用CPU等硬体资源,效率会受到较大限制。

EVM的多执行绪并行最佳化方案

如果用生活中的例子来比较串列执行与并行执行,前者类比为只有一个柜台的银行,并行EVM则类比为有多个柜台的银行。在并行模式下,可以开启多个执行绪同时处理多笔交易,效率可以得到几倍速的提升,但棘手的地方在于状态冲突问题。

如果多笔交易都声明要改写某个帐户的数据,当它们被同时处理时,就会产生冲突,比如某NFT仅能铸造1个,而交易1和交易2都声明要铸造该NFT,如果他们的请求都得到满足,显然会出现错误,应对这类情况需要协调处理。实际操作中的状态冲突往往比我们提到的更频繁,所以如果要将交易处理并行化,就必须要有应对状态冲突的措施。

Reddio对EVM的平行最佳化原理

我们可以来看看ZKRollup专案Reddio对EVM的平行优化思路。 Reddio的想法是为每个执行绪都分配一笔交易,并在每个执行绪中提供一个临时的状态资料库,称为pendingstateDB。具体细节如下:

1 多执行绪并行执行交易:Reddio设定多个执行绪同时处理不同的交易,执行绪之间互不干扰。这可以几倍速提升交易处理速度。

2 为每个执行绪分配临时状态资料库:Reddio为每个执行绪都分配一个独立的临时状态资料库pendingstateDB。各个执行绪执行交易时,不会直接修改全域的stateDB,而是将状态变更结果暂时记录在pendingstateDB中。

3 同步状态变更:在一个区块内的所有交易都执行完毕后,EVM会将每个pendingstateDB中记录的状态变更结果依序同步到全域stateDB中。如果不同交易在执行过程中没有发生状态冲突,就可以将pendingstateDB中的记录顺利合并到全域stateDB中。

Reddio对读写操作的处理方式进行了最佳化,以确保交易能够正确存取状态资料并避免冲突。

读取操作:当交易需要读取状态时,EVM会先检查Pendingstate的ReadSet。如果ReadSet显示存在所需数据,EVM就直接从pendingstateDB读取数据。如果ReadSet中没有找到对应的keyvalue键值对,就从上一个区块对应的全域stateDB中读取历史状态资料。

写入操作:所有写入操作即状态的修改都不会直接写入全域stateDB,而是先记录到Pendingstate 的WriteSet中。待交易执行完成后,透过冲突侦测再尝试将状态变更结果合并到全域stateDB中。

并行执行的关键问题在于状态冲突,当多笔交易尝试读写相同帐户的状态时,此问题尤其显着。为此Reddio引入了冲突侦测机制:

冲突侦测:在交易执行过程中,EVM会监控不同交易的ReadSet和WriteSet。如果发现多个交易尝试读写相同的状态项,则视为发生冲突。

冲突处理:当侦测到冲突时,冲突交易将被标记为需要重新执行。

在所有交易都执行完成后,多个pendingstateDB中的变更记录会被合并到全域stateDB中。如果合并成功,EVM会将最终状态提交到全域状态树中,并产生新的状态根。

多执行绪并行优化对效能的提升是显而易见的,特别是应对复杂智能合约交易时。

根据平行EVM的研究显示,在低冲突工作负载交易池中较少矛盾的或占用相同资源的交易中,基准测试的TPS相比传统的串列执行,提升了35倍左右。在高冲突工作负载中,理论上如果将所有最佳化手段都用上甚至可以达到60倍。

总结

Reddio的EVM多执行绪并行最佳化方案,透过为每个交易分配临时状态库,并在不同执行绪中并行执行交易,显着提高了EVM的交易处理能力。透过优化读写作业和引入冲突侦测机制,EVM系公链能够在保证状态一致性的前提下,实现交易的大规模并行化,解决了传统串列执行模式带来的效能瓶颈。这为以太坊Rollup未来的发展奠定了重要基础。

后续我们会进一步深入分析Reddio的实作细节,如如何进一步从优化储存效率提升效率,冲突高发时的最佳化方案,以及如何借助GPU做最佳化等等内容。

分享至微信

Subscribe to us 作者 :极客 Web3 本文为PANews入驻专栏作者的观点,不代表PANews立场,不承担法律责任。文章及观点也不构成投资意见。 图片来源 : 极客 Web3 如有侵权,请联络作者删除。 深度节点DeFiLayer2智能合约UniswapETH 评论 发布 推荐阅读