Optimizing Parallel EVM from Reddio

以太坊二层 Reddio 的并行 EVM 实现思路概述。

撰文:雾月,极客 web3

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

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

从 Reddio 看并行 EVM 的优化之路

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

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

从 Reddio 看并行 EVM 的优化之路

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

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

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

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

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

在代码模块层面,除 EVM 外,go-ethereum 中与交易执行相关的另一核心组件是 stateDXiaobai NavigationB,用于管理以太坊中的账户状态和数据存储。以太坊采用名为 Merkle Patricia Trie 的树状结构来充当数据库索引(目录),EVM 每一次交易执行都会变更 stateDB 中存放的某些数据,这些变更最终会反映在 Merkle Patricia Trie(后面简称全局状态树)中。

从 Reddio 看并行 EVM 的优化之路

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

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

串行执行的具体过程

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

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

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

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

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

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

从 Reddio 看并行 EVM 的优化之路

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

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

从 Reddio 看并行 EVM 的优化之路

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

从 Reddio 看并行 EVM 的优化之路

3. 在所有交易处理完毕后,processBlock() 函数调用 writeBlockWithState() 函数,再调用 statedb.Commit() 函数,提交状态变更结果。

从 Reddio 看并行 EVM 的优化之路

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

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

EVM 的多线程并行优化方案

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

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

Reddio 对 EVM 的并行优化原理

我们可以看一下 ZKRollup 项目 Reddio 对 EVM 的并行优化思路。Reddio 的思路是为每个线程都分配一笔交易,并在每个线程中提供一个临时的状态数据库,称为 pending-stateDB。具体细节如下:

从 Reddio 看并行 EVM 的优化之路

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

2. 为每个线程分配临时状态数据库:Reddio 为每个线程都分配一个独立的临时状态数据库(pending-stateDB)。各个线程在执行交易时,不会直接修改全局的 stateDB,而是将状态变化结果暂时记录在 pending-stateDB 中。

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

Reddio 对读写操作的处理方式进行了优化,以确保交易能够正确访问状态数据并避免冲突。

  • 读操作:当一个交易需要读取状态时,EVM 会首先检查 Pending-state 的 ReadSet。如果 ReadSet 显示存在所需数据,EVM 就直接从 pending-stateDB 中读数据。如果 ReadSet 中没有找到对应的 key-value(键值对),就从上一个区块对应的全局 stateDB 中读取历史状态数据。

从 Reddio 看并行 EVM 的优化之路

  • 写操作:所有写操作(即对状态的修改)都不会直接写入全局 stateDB,而是先记录到 Pending-state 的 WriteSet 中。待交易执行完成后,通过冲突检测再尝试将状态变更结果合并到全局 stateDB 中。

从 Reddio 看并行 EVM 的优化之路

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

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

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

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

从 Reddio 看并行 EVM 的优化之路

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

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

Summarize

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

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

The article comes from the Internet:Optimizing Parallel EVM from Reddio

相关推荐: Intent asset—Web3资产大规模应用的入口

Intent 资产借助 dappOS 执行网络,将普通或意图资产转化为预期结果,复杂结算由服务商完成。 作者: Mike @Foresight Ventures 闲置资产的革命 2013年,阿里的余额宝横空出世,将资产管理带入了一个全新的时代。在此之前,普通用…

share to
© 版权声明

相关文章