为什么“并行EVM”关乎以太坊EVM生态的存续之战？

作者：Haotian，独立研究员 来源：X，@tmel0211

最近，Paradigm下重注领投了Monad一轮2.25亿美元的巨额融资，引发市场对“并行EVM”的强烈关注。那么，“并行EVM”到底解决了什么问题？发展并行EVM的瓶颈和关键是什么？ 在我看来，“并行EVM”是EVM链迎击高性能layer1链的最后一博，事关以太坊EVM生态的存续之战。Why？接下来，来谈谈我的理解：

由于以太坊EVM虚拟机只能“串行”交易，这使得EVM- Compatible layer1链以及EVM兼容的layer2链，也都受到了相应的性能制约，因为大家本质上都基于同一套框架处理状态和交易Finality。

然而，像Solana、Sui、Aptos等主打高性能的layer1先天就具有可并行的优势。在此背景下，EVM基因的链要想正面Battle高性能layer1公链的冲击，就势必得补足“并行”能力先天不足的问题。如何做呢？涉及技术原理和细节，我将以并行EVM新锐链 @Artela_Network 为例展开说明：

1）以Monad、Artela、SEI等为代表的强化型EVM layer1链，它们会在高度兼容EVM的基础上大幅提升TPS并能赋予交易在拟EVM环境下的并行能力，这类独立并行EVM layer1链，有独立的共识机制和技术特性，但依然会以兼容并拓展EVM生态为目标，相当于，以“换血统”的方式重构EVM链，又服务于EVM生态；

2） 以Eclipse、MegaETH等为代表的扩容型layer2 EVM兼容链，它们利用layer2链独立的共识和交易“预处理”能力，可以在大批量交易被Batch到主网前，对交易状态进行筛选和处理，并可同时选择其他任意链的执行层来最终确定交易状态。等同于把EVM抽象成一个可插拔的执行模块，可根据需要选择最佳“执行层”，进而实现了并行能力；但，这类方案可服务于EVM，但又超出EVM框架范畴；

3）以Polygon、BSC等为代表的等效型 Alt-layer1链，它们一定程度上实现了EVM的并行处理能力，但只是进行了算法层的优化，并没有进行深层次的共识层和存储层的优化，因此这类并行能力更多可视为一个特定的Feature，而并没有彻底解决EVM的并行问题。

4）以Aptos、Sui、Fuel等为代表的差异型Non-EVM并行链，它们某种程度上并非实现的并非EVM链，而是在其先天具有高并发执行能力接触上，然后通过某种中间件或编码解析方式，实现了和EVM环境的兼容。我们看身为以太坊layer2的Starknet就是如此，由于Starknet具备Cario语言和账户抽象使其也具备并行能力，但其兼容EVM却需要一个特殊的管道。这些Non-EVM链的并行能力接轨EVM链基本都存在这个问题。

以上四个方案，各有侧重点，比如：有并行能力的layer2侧重模块化组合“执行层”链的灵活性；而EVM- Compatible链则突出了特定功能的定制特性；至于其他非EVM链的EVM兼容特性更多所图抽以太坊的流动性；真正目标彻底巩固EVM生态，并从底层改变并行能力的只剩一个强化型EVM layer1赛道了。

那么，做强化型并行EVM layer1公链的关键是什么？如何才能重构EVM链，又能服务于EVM生态？有两个关键点：

1、访问state I/O磁盘读取和输出信息的能力，由于数据的读取和写入要消耗时间，只是简单进行交易排序和调度，并不能根本上提高并行处理能力，还需要引入缓存、数据切片甚至分布式存储技术等等，从根本状态存储和读取流程上平衡读取速度和状态冲突的可能性；

2）拥有高效的网络通信，数据同步，算法优化、虚拟机强化、以及将计算和IO任务分离等共识机制层的各类组件优化等等，需要牵一发而动全身从底层组件架构、协作流程等方方面面综合优化和提升，最终促成响应速度快、计算消耗可控、准确率高的并行交易的能力；

具体到并行EVM layer1链项目本身，要做哪些技术创新和框架优化来实现“并行EVM”呢？

为了从底层架构层彻底实现资源协调和优化的“并行EVM”能力，Artela引入了弹性计算（Elastic Computing）和弹性区块空间（Elastic Block Space），如何理解呢？弹性计算，网络可根据需求和负载动态地分配和调整计算资源；弹性区块空间，可根据网络中交易数量和数据大小进行动态调整区块大小；整个弹性设计工作原理，恰如商场自动感应人流量进行工作的扶梯一样，很Make Sense；

前文说了，State I/O磁盘读取性能对并行EVM很关键，Polygon、BSC等EVM-Compatible链通过算法实现的“并行”能力，也能实现2-4倍的效率提升，但其只是算法层的优化，其共识层、存储层并没有进行深层优化，真正的深层优化会是怎样呢？

针对此，Artela借鉴了数据库技术方案，在状态读取和写入方面都做了提升，其中写入状态方面才去了写入前日志（WAL）技术，当状态改变要写入时先把改变记录写入日志并提交到内存，就可以认为完成了“写入”操作，这样做其实实现了操作异步化，避免了在状态改变时写入时立即进行磁盘写入操作，故而降低了对磁盘的I/O操作。状态读取方面，本质上也是异步化操作，通过预加载策略来提升读取效率，根据合约历史执行记录来预测下一次特定的合约调用会用到哪些状态，并预先加载到内存中，进而提升了磁盘I/O请求效率。

总之，这是一种通过内存空间换执行时间的一种算法，以此从根本上提升EVM虚拟机的并行处理能力，算是从根本上优化了状态冲突问题。

除此之外，Artela通过引入Aspect模块化编程能力，以更好管理复杂性并提高开发效率：通过引入WASM编码解析以增强编程的灵活性；同时，它还具有底层API访问权限，实现了执行层的安全隔离。这使得开发者可以在Artela的环境下高效地开发，调试和部署智能合约，以此激活开发者群体的定制扩展能力。特别是，开发者也会被激励在智能合约代码层就往可并行的方向进行代码优化，毕竟要减少状态冲突概率，每一个智能合约的调用逻辑和算法都尤为关键。

大家不难看出，“并行EVM”这一概念本质上就是在优化交易状态的执行过程， @monad_xyz 号称可达到每秒10,000笔交易，其技术内核也无非在专用数据库、开发者友好度、延迟执行共识、超标量流水线技术等等方面来达成大规模交易的并行处理，这和Artela的弹性计算和I/O异步性操作本质逻辑并无太大差异。

但我其实更想表达的是，这类高性能并行EVM链其实是融入web2产品和技术力之后的结果，确实采用了web2成熟应用市场上，时不时流量高负载下的“技术处理”精髓。

如果放眼一个Mass Adoption的遥远未来，“并行EVM”的确是EVM生态下一步面向web2更广泛市场的基础infra，能受资本市场如此Bullish也在情理之中。