Reforge Research雄文：唯有并行EVM拯救以太坊

本文来自: Reforge Research

编译: Odaily星球日报 Wenser

编者按：近期并行 EVM 的讨论引起业界高度关注，Reforge Research 与多名 EVM L1 生态网络、AMM 行业以及跨链协议等资深业内人士进行了深入交流，以了解不同生态系统对这一话题的不同观点，Odaily 星球日报对本文予以编译，供参考学习。

介绍

在今天的计算机系统中，想要让事务更快且更有效率地得到处理通常意味着并行处理，而非顺序处理。这种现象，顾名思义被称为并行化，正是由现代计算机的多核处理器架构催生出来的。传统意义上分步骤处理的任务现在往往同时得到处理，从而最大限度地发挥处理器的性能。同样，在区块链网络中，这种同时执行多个操作的原则也适用于交易层面，尽管并非利用多个处理器进行操作，而是利用网络中众多节点的集体验证能力。一些早期示例包括：

2015 年，Nano（XNO）采用区块格结构，使得每个账户都拥有自己的区块链以实现并行处理以及去除对网络范围内交易确认的需要。

2018 年，区块链网络的 Blockbeats-STM（软件交易存储器）并行执行引擎论文正式发表，Polkdot 通过多链架构实现并行化，EOS 推出了他们的多线程处理引擎。

2020 年，Avalanche 为其共识层（而非序列化的 EVM c 链）引入了并行处理机制，Solana 在 Sealevel 中加入了类似创新。

对于 EVM 来说，自成立以来，交易和智能合约的执行都是顺序化处理的。这种单线程执行设计限制了整个系统的吞吐量和可扩展性，这一缺陷在网络需求过载时尤其明显。随着网络节点面临日益加重的工作负载，区块链网络不可避免地变慢，且用户也将面对更高的成本，为了在拥挤的网络环境中交易得到优先处理，他们不得不给出更高的竞价。

从 Vitalik 于 2017 年提出的 EIP 提案以来，以太坊社区一直在探索将并行处理作为一种解决方案。最初的目的是通过传统的分片区块链或分片化实现并行化。然而，L2 Rollup 的快速开发和应用能够提供更简单、更直接的可扩展性优势，因而将以太坊的发展重点从分片转移到了现在所谓的 danksharding。借助 danksharding，分片主要用作数据可用层，而非并行执行交易。然而，由于 danksharding 尚未完全实现，人们的注意力已经转向了几个具有 EVM 兼容性的关键替代性并行化 L1 网络（尤其是 Monad、Neon EVM 和 Sei）。

鉴于软件系统工程的传统发展态势和其他网络可扩展性的成功，EVM 的并行推进是不可避免的。我们以坚定的信念期待这一转变，而未来的走向虽然并不明确，但却充满希望。这将对全球最大的智能合约开发者生态系统（目前拥有超过 800 亿美元 TVL）产生巨大影响。当 gas 费经过优化状态访问情况而减少到仅仅一美分的几分之一时，情况会变得如何？对于应用层开发者来说，可供设计的空间如何广阔？以下是我们对后并行 EVM 世界发展可能性的看法。

并行化是一种手段，而非目的

扩展区块链是一个多维问题，而并行执行为更多关键基础设施的开发铺平了道路，比如区块链状态存储。

在并行 EVM 上运转的项目面临的主要挑战不仅是使计算能够同时进行，而且要确保在并行化环境中对优化状态访问和修改。问题的关键在于两个主要问题：

以太坊客户端和以太坊本身使用不同的存储数据结构（B 树/LSM 树与默克尔树），导致将一个数据结构嵌入另一个数据结构时性能不佳。

在并行执行中，对于交易读取和更新而言的异步输入/输出（简称异步 I/O ）的能力至关重要；操作进程因互相等待对方反应而卡顿，浪费所有速率收益。

与检索或设置存储值的成本相比，添加大量额外的 SHA-3 哈希或计算等附加计算任务是次要的。为了减少交易处理时间和 gas 费用，数据库本身的基础设施必须加以改进。这不仅仅是采用传统的数据库架构作为原始键值存储的替代方案（如 SQL 数据库）的问题。与使用基本键值存储相比，使用关系模型实现 EVM 状态会增加不必要的复杂性和开销，从而导致‘加载’和‘存储’操作的成本更高。EVM 状态不需要像排序、范围扫描或操作性语义等功能，因为它只执行点读取和点写入操作，并且写入操作分别发生在每个区块末尾。反过来说，对于这些改进的需求应该集中在解决诸如可扩展性、低延迟读写、高效的并发控制、状态修剪和归档，以及与 EVM 的无缝集成等主要考虑因素上。例如，Monad 正在从零开始构建一个被称为 MonadDB 的自定义状态数据库。它将利用最新的内核支持进行异步操作，同时在磁盘上和内存中本地实现默克尔树数据结构。