EVM的串行执行瓶颈与并行化优化探索

众所周知，EVM是以太坊的核心执行引擎和智能合约运行环境，是以太坊最关键的组件之一。在由众多节点构成的公链网络中，为了确保智能合约在不同节点上都能得到一致的执行结果，虚拟机技术起到了至关重要的作用。

EVM能够在各种操作系统和设备上以统一的方式执行智能合约，这种跨平台兼容性保证了每个节点运行合约后都能获得一致的结果。这与Java虚拟机JVM的工作原理类似。

通常情况下，智能合约会先被编译为EVM字节码，然后存储到区块链上。EVM执行合约时，会按顺序读取这些字节码，每条指令都对应特定的Gas成本。EVM会追踪每条指令执行过程中的Gas消耗，具体消耗量取决于操作的复杂程度。

作为以太坊的核心执行引擎，EVM采用串行方式处理交易，所有交易在单一队列中排队并按确定顺序依次执行。选择串行而非并行的原因是为了严格满足区块链的一致性要求，确保一批交易在所有节点中都按相同顺序处理。

2014-2015年间，以太坊创始团队出于时间紧迫，选择了设计简单且易于维护的串行执行方式。然而，随着区块链技术的发展和用户群体的扩大，对TPS和吞吐量的要求不断提高。特别是在Rollup技术成熟落地后，EVM串行执行带来的性能瓶颈在以太坊二层网络中变得更加明显。

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

某团队通过对DA层和数据读写模块进行极致优化，使Sequencer每秒最多可执行约2000多笔ERC-20转账。这个数字看似很高，但对于更复杂的交易，TPS数值必然会大幅下降。因此，交易处理的并行化将是未来的必然趋势。

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

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

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

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

串行执行的具体过程

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

相比之下，合约交易涉及智能合约的调用与执行。EVM在处理合约交易时，需要逐条解释和执行智能合约中的字节码指令，合约逻辑越复杂，涉及的指令越多，消耗的资源也就越多。

例如，ERC-20转账的处理时间约为EOA转账的2倍，而更复杂的智能合约，如某DEX上的交易操作，耗时可能是EOA转账的十几倍。这是因为DeFi协议在交易时需要处理流动性池、价格计算、代币交换等复杂逻辑，需要进行大量计算。

在串行执行模式下，EVM与stateDB这两个组件协作处理交易的过程如下：

以太坊设计中，一个区块内的交易会按先后顺序逐笔处理，每笔交易都有一个独立实例用于执行具体操作。虽然每笔交易使用不同的EVM实例，但所有交易共用同一个状态数据库stateDB。

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

当一个区块中所有交易都执行完毕后，stateDB中的数据会被提交到全局状态树，并生成新的状态根。状态根是每个区块中的重要参数，记录了区块执行后新的全局状态的"压缩结果"。

显然，EVM的串行执行模式存在明显瓶颈：交易必须按顺序排队执行，如果出现耗时很长的智能合约交易，其他交易只能等待，无法充分利用硬件资源，效率受到较大限制。

EVM的多线程并行优化方案

如果用生活中的例子来类比，串行执行就像只有一个柜台的银行，而并行EVM则类似于有多个柜台的银行。并行模式下可以开启多个线程同时处理多笔交易，效率可以得到几倍提升，但需要解决状态冲突问题。

如果多笔交易都声明要修改某个账户的数据，同时处理时就会产生冲突。例如，某NFT只能铸造1个，而交易1和交易2都声明要铸造该NFT，如果两个请求都得到满足，显然会出错。实际操作中的状态冲突往往更加频繁，因此并行化处理必须有应对状态冲突的措施。

某项目对EVM的并行优化原理

某ZKRollup项目对EVM的并行优化思路是为每个线程分配一笔交易，并在每个线程中提供一个临时的状态数据库，称为pending-stateDB。具体细节如下：

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

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

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

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

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

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

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

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

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

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

多线程并行优化对性能的提升是显著的，特别是在处理复杂智能合约交易时。研究显示，在低冲突工作负载中，基准测试的TPS相比传统串行执行提升了3-5倍左右。在高冲突工作负载中，理论上如果将所有优化手段都应用，甚至可以达到60倍的提升。

总结

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

未来还可以进一步探索如何优化存储效率以提升性能，高冲突情况下的优化方案，以及如何利用GPU进行优化等内容。