EVM并行化优化:提升以太坊交易处理效率

EVM作为以太坊的核心执行引擎,其定位是"智能合约执行环境"。为确保智能合约在不同节点上都能得到一致的结果,EVM提供了跨平台的虚拟机环境,类似于Java虚拟机JVM。

智能合约在部署时会被编译为EVM字节码存储到链上。EVM执行合约时按顺序读取这些字节码,每条指令都有相应的Gas成本。EVM会跟踪指令执行过程中的Gas消耗,消耗量取决于操作复杂度。

传统EVM采用串行方式处理交易,所有交易在单一队列中按确定顺序执行。这种设计简单易维护,但随着用户规模扩大和Rollup技术的应用,串行执行的性能瓶颈日益凸显。

在Rollup架构中,Sequencer作为Layer2的关键组件承担所有运算任务。如果其他外部模块效率足够高,Sequencer本身的串行执行将成为最大瓶颈。有团队通过极致优化使Sequencer每秒最多可执行2000多笔ERC-20转账,但对于更复杂的交易,TPS仍会大幅下降。因此,交易处理并行化成为未来发展趋势。

除EVM外,go-ethereum中与交易执行相关的另一核心组件是stateDB,用于管理账户状态和数据存储。以太坊使用Merkle Patricia Trie树状结构作为数据库索引,EVM每次交易执行都会变更stateDB中的数据,最终反映在全局状态树中。

stateDB负责维护所有以太坊账户状态,包括账户余额、智能合约代码等。交易执行过程中,stateDB会对相应账户数据进行读写,执行结束后将新状态提交到底层数据库中持久化。

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

在串行执行模式下,一个区块内的交易会按顺序逐笔处理。每笔交易使用独立的EVM实例,但所有交易共用同一个stateDB。EVM在执行过程中需要不断与stateDB交互,读取相关数据并写回变更结果。

区块内所有交易执行完毕后,stateDB中的数据会被提交到全局状态树,生成新的状态根。这种串行模式的主要瓶颈是交易必须排队执行,无法充分利用硬件资源,特别是面对复杂的智能合约交易时效率较低。

为提高交易处理效率,一些项目开始尝试EVM的多线程并行优化。这类似于银行开设多个柜台同时服务客户,可以几倍提升处理速度,但需要解决可能出现的状态冲突问题。

某ZKRollup项目对EVM的并行优化思路是为每个线程分配一个临时状态数据库(pending-stateDB)。具体实现包括:

1. 多线程并行执行交易,互不干扰。

2. 每个线程有独立的pending-stateDB,交易执行时先将状态变化记录在此。

3. 所有交易执行完毕后,将pending-stateDB中的变更同步到全局stateDB。

该方案对读写操作进行了优化:

• 读操作时先检查pending-stateDB的ReadSet,如有所需数据直接读取,否则从全局stateDB读取历史状态。

• 写操作不直接写入全局stateDB,而是先记录到pending-stateDB的WriteSet中。

为处理状态冲突,引入了冲突检测机制:

• 监测不同交易的ReadSet和WriteSet,发现多个交易读写相同状态项时视为冲突。

• 冲突交易会被标记为需要重新执行。

所有交易执行后,多个pending-stateDB的变更记录会合并到全局stateDB,成功后提交到全局状态树并生成新状态根。

研究显示,在低冲突工作负载中,并行EVM的TPS相比传统串行执行提升了3-5倍。在高冲突工作负载中,理论上最高可达60倍提升。

这种多线程并行优化方案,通过临时状态库和并行执行,显著提高了EVM的交易处理能力。优化读写操作和引入冲突检测机制,使得在保证状态一致性的同时实现交易大规模并行化,解决了串行执行的性能瓶颈,为以太坊Rollup的未来发展奠定了基础。