.png)
1
以太坊二层 Reddio 的并行 EVM 实现思路概述。
撰文：雾月，极客 web3
众所周知，EVM 的定位是以太坊的「执行引擎」和「智能合约执行环境」，可以说是以太坊最重要的核心组件之一。公链是一个包含成千上万节点的开放性网络，不同节点的硬件参数相差甚大，若想让智能合约在多个节点上都跑出相同结果，满足「一致性」，要设法在不同设备上都搭建出相同的环境，而虚拟机可以实现这个效果。
以太坊的虚拟机 EVM 能在不同操作系统（如 Windows、Linux、macOS）和设备上以相同的方式来运行智能合约，这种跨平台兼容性确保每个节点运行合约后，都能得到一致的结果。最典型的例子就是 Java 虚拟机 JVM。
我们平时在区块浏览器里看到的智能合约，都是先被编译为 EVM 字节码，然后才存储到链上的。EVM 在执行合约时，直接按顺序读取这些字节码，字节码对应的每条指令（opCode）都有相应的 Gas 成本。EVM 会跟踪每条指令在执行过程中的 Gas 消耗，消耗量则取决于操作的复杂度。
此外，作为以太坊的核心执行引擎，EVM 采用串行执行的方式处理交易，所有交易在单一队列里排队并按照确定顺序先后执行。之所以不用并行化的方式，是因为区块链要严格满足一致性，一批交易在所有节点中都要按相同次序来处理，如果将交易处理并行化，难以精确的预判交易次序，除非引入对应的调度算法，但这会比较复杂。
2014~15 年的以太坊创始团队出于时间紧迫，选用了串行执行的方式。因为它设计简单且易于维护。然而随着区块链技术的迭代和用户群体越来越大，区块链对 TPS 和吞吐量的要求越来越高，在 Rollup 技术出现并成熟落地后，EVM 串行执行带来的性能瓶颈在以太坊二层身上已经暴露无疑。
Sequencer 作为 Layer2 的关键组件，以单个服务器的形式承接所有运算任务，如果与 Sequencer 配合的外部模块的效率都足够高，则最终的瓶颈将取决于 Sequencer 本身的效率，此时串行执行将成为巨大的阻碍。
opBNB 团队曾通过对 DA 层和数据读写模块进行极致优化，Sequencer 每秒最多可执行约 2000 多笔 ERC-20 转账。这个数字看起来很高，但如果要处理的交易比 ERC-20 转账复杂很多，TPS 数值必然会大打折扣。所以说，交易处理的并行化将是未来的必然趋势。
下面我们将从更具体的细节入手，为大家详细解释传统 EVM 的局限性，以及并行 EVM 的优势。
在代码模块层面，除 EVM 外，go-ethereum 中与交易执行相关的另一核心组件是 stateDB，用于管理以太坊中的账户状态和数据存储。以太坊采用名为 Merkle Patricia Trie 的树状结构来充当数据库索引（目录），EVM 每一次交易执行都会变更 stateDB 中存放的某些数据，这些变更最终会反映在 Merkle Patricia Trie（后面简称全局状态树）中。
具体来说，stateDB 负责维护所有以太坊账户的状态，包括 EOA 账户和合约账户，其存储的数据包括账户余额、智能合约代码等。在交易执行过程中，stateDB 会对相应账户的数据进行读写。而在交易执行结束后，stateDB 需要将新的状态提交到底层数据库（如 LevelDB）中，进行持久化处理。
总的来说，EVM 负责解释和执行智能合约指令，根据计算结果变更区块链上的状态，而 stateDB 则充当全局状态存储，管理所有账户和合约的状态变化。两者协作构建了以太坊的交易执行环境。
以太坊的交易类型分两种，即 EOA 转账和合约交易。EOA 转账是最简单的交易类型，即普通账户之间的 ETH 转账。这种交易不涉及合约调用，处理速度非常快。由于操作简单，EOA 转账收取的 gas 费极低。
与简单的 EOA 转账不同，合约交易会涉及到智能合约的调用与执行。EVM 在处理合约交易时，要逐条解释和执行智能合约中的字节码指令，合约的逻辑越复杂，涉及的指令越多，消耗的资源越多。
举例来说，ERC-20 转账的处理时间大约是 EOA 转账的 2 倍，而对于更复杂的智能合约，如 Uniswap 上的交易操作，耗时更长，甚至可以比 EOA 转账慢十几倍。这是因为 DeFi 协议需要在交易时处理流动性池、价格计算、代币 swap 等复杂逻辑，需要进行非常复杂的计算。
那么在串行执行模式下， EVM 与 stateDB 这两个组件是如何协作处理交易的呢？
在以太坊的设计中，一个区块内的交易会按先后次序被一笔笔处理，每笔交易（tx）都会有一个独立实例，用于执行该交易的具体操作。尽管每笔交易会使用不同的 EVM 实例，但所有交易要共用同一个状态数据库，也就是 stateDB。
在交易执行过程中，EVM 需要不断与 stateDB 交互，从 stateDB 中读取相关的数据，并将变更后的数据写回 stateDB。
我们从代码角度大致看下 EVM 和 stateDB 是如何协作执行交易的：
1. processBlock()函数会调用Process() 函数处理一个区块中包含的交易；
2. Process() 函数中定义了一个 for 循环，可以看到交易是被一笔一笔执行的；
3. 在所有交易处理完毕后，processBlock() 函数调用 writeBlockWithState() 函数，再调用 statedb.Commit() 函数，提交状态变更结果。
当一个区块中所有交易都被执行完毕后，stateDB 中的数据会被 Commit 到前面提到的全局状态树（Merkle Patricia Trie），并生成新的状态根（stateRoot）。状态根是每个区块中的重要参数，它记录了区块执行后新的全局状态的「压缩结果」。
我们不难理解，EVM 的串行执行模式瓶颈很明显：交易必须按顺序排队执行，如果出现耗时很久的智能合约交易，在其处理完毕前，其他交易只能等待，这显然无法充分利用 CPU 等硬件资源，效率会受到较大限制。
如果用生活中的例子来对比串行执行与并行执行，前者类比为只有一个柜台的银行，并行 EVM 则类比为有多个柜台的银行。在并行模式下，可以开启多个线程同时处理多笔交易，效率可以得到几倍速的提升，但棘手的地方在于状态冲突问题。
如果多笔交易都声明要改写某个账户的数据，当它们被同时处理时，就会产生冲突，比如某 NFT 仅能铸造 1 个，而交易 1 和交易 2 都声明要铸造该 NFT，如果他们的请求都得到满足，显然会出现错误，应对这类情况需要进行协调处理。实际操作中的状态冲突往往比我们提到的更频发，所以如果要将交易处理并行化，就必须要有应对状态冲突的措施。
我们可以看一下 ZKRollup 项目 Reddio 对 EVM 的并行优化思路。Reddio 的思路是为每个线程都分配一笔交易，并在每个线程中提供一个临时的状态数据库，称为 pending-stateDB。具体细节如下：
1. 多线程并行执行交易：Reddio 设置多个线程同时处理不同的交易，线程之间互不干扰。这可以几倍速提升交易处理速度。
2. 为每个线程分配临时状态数据库：Reddio 为每个线程都分配一个独立的临时状态数据库（pending-stateDB）。各个线程在执行交易时，不会直接修改全局的 stateDB，而是将状态变化结果暂时记录在 pending-stateDB 中。
3. 同步状态变更：在一个区块内的所有交易都执行完毕后，EVM 会将每个 pending-stateDB 中记录的状态变更结果依次同步到全局 stateDB 中。如果不同交易在执行过程中没有发生状态冲突，就可以将 pending-stateDB 中的记录顺利合并到全局 stateDB 中。
Reddio 对读写操作的处理方式进行了优化，以确保交易能够正确访问状态数据并避免冲突。
并行执行的关键问题在于状态冲突，当多笔交易尝试读写相同账户的状态时，该问题尤为显著。为此 Reddio 引入了冲突检测机制：
在所有交易都执行完成后，多个 pending-stateDB 中的变更记录会被合并到全局 stateDB 中。如果合并成功，EVM 会将最终状态提交到全局状态树中，并生成新的状态根。
多线程并行优化对性能的提升是显而易见的，特别是应对复杂智能合约交易时。
根据并行 EVM 的研究显示，在低冲突工作负载（交易池中较少矛盾的或者占用相同资源的交易）中，基准测试的 TPS 相比传统的串行执行，提升了 3~5 倍左右。在高冲突工作负载中，理论上如果将所有优化手段都用上甚至可以达到 60 倍。
Reddio 的 EVM 多线程并行优化方案，通过为每个交易分配临时状态库，并在不同线程中并行执行交易，显著提高了 EVM 的交易处理能力。通过优化读写操作和引入冲突检测机制，EVM 系公链能够在保证状态一致性的前提下，实现交易的大规模并行化，解决了传统串行执行模式带来的性能瓶颈。这为以太坊 Rollup 未来的发展奠定了重要基础。
后续我们会进一步深入分析 Reddio 的实现细节，如如何进一步从优化存储效率提升效率，冲突高发时的优化方案，以及如何借助 GPU 做优化等等内容。
.png)
