深入探讨「并行EVM」：关乎以太坊EVM生态的存续之战

原文作者：Haotian

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

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

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

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

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

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

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

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

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

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

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

具体到并行 EVM layer 1 链项目本身，要做哪些技术创新和框架优化来实现“并行 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 也在情理之中。

原文链接