# 让以太坊成为标准：EVM 等同性介绍

By [EthereumCN](https://paragraph.com/@ethereumcn-2) · 2021-11-04

---

来源 | [Optimism PBC Blog](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306)

![](https://storage.googleapis.com/papyrus_images/742562b835c526fa2f6340cfec8c76692931bfefc3ae1d968afd8edfe464c53b.gif)

上个月，我们宣布了 [Optimistic Ethereum 历史上最重大的升级](https://medium.com/ethereum-optimism/the-future-of-optimistic-ethereum-7f22d987331) —— OVM 2.0。最近，我们将 Optimistic Kovan 迁移了，使其真正能够一键部署以及提高了其稳定性。并且，将在未来的三周内上线主网，

但是本文并不是关于一键部署或者渐进式改善。

本文主要介绍了 **EVM Equivalence (完全与以太坊虚拟机规范相一致)** 将如何成为 L2 领域的下一个通用标准。

Optimistic 争议协议的简史
==================

首先，一起来回顾一下 rollup 的发展历史。

Rollup 的开端
----------

Optimistic L2 解决方案都与争议有关。如果你认为以太坊是一个全能的、去中心化的法庭，那么 L2 扩容的核心观点便是：“不要去法庭兑现支票 —— 如果支票被退回再去。”

实际上，可扩展性的研究在过去六年可以归结为一件事：什么样的“拒付支票”可以被强制执行。首先，只有一组预先商定的参与可以在彼此之间进行交易 (状态通道)。接着就是，任何人都可以交易，但也有可能被审查 (plasma)。终于，我们把审查问题也解决了 (rollups)。

![](https://storage.googleapis.com/papyrus_images/86a9558a6d63e7a41e8d5e614b568f3d72c3427f4194a00ea2a7977717742a43.png)

在 rollup 之前，我们已经[知道](https://l4.ventures/papers/statechannels.pdf)[如何](https://medium.com/plasma-group/plapps-and-predicates-understanding-the-generalized-plasma-architecture-fc171b25741)在所有这些模型上运行智能合约 —— 只是没有任何意义。毕竟谁想要在几个朋友之间运行 Uniswap 或者要被审查一周呢？而 rollup 能够承诺给我们提供真实的、类似于以太坊交互体验的 L2。

兼容时代
----

当然，仅仅“承诺”提供一个真实的、类似于以太坊交互体验的 L2，并不代表能够真正创建实现。在构建首个 L2 AMM Unipig 时，我们必须使用与 rollup 争议合约兼容的自定义代码重新创建 Uniswap —— **而不是利用 EVM 本身来构建**。

由于 Uniswap 的设计相对简单，上述的构建方式是可行的。然而连 Solidity 这么基础的东西都不能再用了，实在不是一个好兆头。对于非开发者来说，Uniswap 是目前最简单的 DeFi 智能合约之一，如果连 Uniswap 也要大改一番才能方便地实现兼容 rollup，这真不是一个好现象。

到目前为止，以太坊的发展速度之快，早已超过了逃逸速度 (escape velocity)。呈指数级增长的以太坊生态系统根本无法围绕非 EVM 接口进行重新架构。因此，L2 除了要提供“原始”规模之外，它还要确保 L1 的法院系统与 EVM 的差异最小化。这迫使 rollup 同时在以下两个方面开创先河：

*   构建可扩展的、产品级别的 rollup 基础设施。
    
*   [解决长期](https://github.com/ethereum/EIPs/issues/726#:~:text=Currently%20any%20of%20these%20applications%20would%20require%20essentially%20creating%20a%20full%20ethereum%20client%20inside%20EVM%20code%2C%20which%20would%20add%20an%20unacceptably%20high%20amount%20of%20overhead.)以来就让人难以接受的的 EVM-in-EVM (在 EVM 里构建 EVM) 问题。
    

以太坊的图灵完备性 ( [Turing-completeness](https://en.wikipedia.org/wiki/Turing_completeness)) 意味着它确实可以解决这些问题，但在我们的研究过程中，我们发现，如果想要在合理的时间范围内将以太坊迁移到 L2 上，我们需要牺牲一些东西，做出妥协。

这种妥协也就是我们后来所称的 EVM 兼容性 (**EVM “Compatibility**”)。

EVM 兼容性的论点很简单：只要以太坊的应用程序可以合理地移植到 rollup 上运行 —— 不管这是如何在幕后完成的 —— 我们就可以追上以太坊的逃逸速度。

![](https://storage.googleapis.com/papyrus_images/2f78989bef1d23bc7bf56c41f41373f60ebe2c85fbe059f1d0b2ed2476612a57.png)

_“这算是兼容性吗？”_

乘风破浪
----

起初，这种妥协取得了一些成功。在 2020 年，由于许多用户从以太坊转移到了其他 L1 竞争链上 (这些链打着“费用低廉”的幌子而罔顾安全性和价值)，我们竞相推出了 OVM。在今年 1 月份，Optimism 上线主网，10 个月过去了，我们已经处理了数百万笔交易，为用户节省了数亿美元的交易费。

但是以太坊网络效应产生的逃逸速度有多种形式，并从以太坊 L1 的交易活动飙升这个现象可以看出，其他 L1 链和 L2 所缺乏的是：以太坊 L1 所拥有的**基础设施**。过去六年来，遍布世界的以太坊社区成员合力将以太坊从一个简化的原型变成一个更加完善的系统：

*   成千上万的开发工具已深度集成到 EVM 中。
    
*   价值数十亿美元的公司的出现，只为了给以太坊的节点软件提供服务以及完善其运行。
    
*   以太坊本身的交易处理速度[越来越快](https://etherscan.io/chart/gaslimit)了。
    

以太坊网络效应的浪潮只会越来越大。由于一切都是开源的，人们可能会期望这些巨大的胜利同样也能在 L2 上发生。

**然而并没有达到大家的预期。**

EVM 兼容性 (EVM **compatibility**) 与 EVM 等同性 (EVM **equivalence**) 是有区别的，仅仅满足于兼容性意味着你被迫修改 (甚至需要完全重新实现) 以太坊的基础设施也依赖的低级代码。如果 L2 想要从以太坊基础设施网络效应所带来的浪潮中获得一些好处，它们必须要具有 EVM 等同性。

在 Optimistic Ethereum 上线并运行发展之后，我们发现越来越多以太坊工具难以部署在 Optimistic Ethereum 系统上，这是由于我们老旧的 EVM 兼容性设计理念造成的。

我们知道我们能做得更好。为了真正让大众用上 OE，我们需要的不仅仅是与 EVM 合约**兼容**；相反，我们要做到从根本上实现与 EVM 本身**等同**。

EVM 等同性能够帮助填补以太坊 L1 的基础设施网络效应和以太坊 L2 的执行环境之间的缺口。

EVM 等同性：借助以太坊的 EVM 应用浪潮
=======================

![](https://storage.googleapis.com/papyrus_images/e84064eb232eb43c99b24f012b4e5e32019000c90e533971118e7cd8d79423e6.png)

…什么是 EVM 等同性？
-------------

简而言之：EVM 等同性也就是与[以太坊黄皮书](https://ethereum.github.io/yellowpaper/paper.pdf)的规范 (该协议的正式定义) 完全相符。根据定义，L1 以太坊软件必须符合该规范。

深入到最本质来说，这意味着现有的以太坊堆栈也将要与 L2 系统集成。每一个调试器、每一个工具链以及**每个节点实现**都要和 L2 集成。我们相信，任何提供任何 EVM 开发体验的 L2 都必须满足这一标准 —— 一丁点达不到标准都不可接受。

…为什么需要 EVM 等同性？
---------------

从最开始，我们就在以太坊最具有鲁棒性和最普遍的实现 “Geth” 上构建了我们的软件 —— 这是我们实现产品级的以太坊 L2 的唯一可行途径。OVM v1 引入了一种容器化系统 (containerization system)，它基于 Geth 的 EVM 构建，有助于避免在 L1 上繁琐地重新实现整个 EVM。

这种组合在早期取得了一些胜利，但由于 EVM 并不原生地支持容器化，所以这不是免费的。即使对于我们以 Geth 为中心的团队，这些变化也开始累积起来。随着 Optimistic Ethereum 的发展，EVM 等同性的力量不容忽视：

*   像 Solidity、Vyper 和 Hardhat 等项目无私地致力于开发 OVM 版本的开发工具，但我们这样做冒着将这些已经资源受限的团队分散的风险。这给我们上了一课，团队需要投入相当的人力来维护非 EVM 等同的代码库。
    
*   随着每一行代码的改变，采用像 Erigon 这样的实验性实现变得更加困难。也就是说，我们总是需要花人力来负责集成未来的客户端实现。
    
*   与现有的超级优化版本相比，重新实现部分 EVM 带来了一些 gas 开销。这告诉我们，最小化 gas 成本需要 EVM 等同性的设计方案。
    

是时候寻求更优的解决方法了，尽管这需要单调乏味的工作。

…如何实现 EVM 等同性？
--------------

幸好，比起在 EVM 中繁琐地重新实现 EVM，我们找到了更好的办法。这就是你要做的。

**将区块产生和执行分离**

在实践中，我们确实需要对 L2 化的以太坊进行一些更改：尤其是如何产生区块。在 L1 上，节点通过 PoW 共识机制来确定区块；在 L2 上，通过将批量交易的 batches 发送到“父链” (L1 以太坊) 上来应用这些交易。如果某个 L2 使用它自己的 PoW，那么它将变成一个 L1！所以，从这个层面来说，这种“等同性”毫无意义。

区块链模块化的一个核心模式就是将共识与执行分离 —— 也就是说，确定和执行下一个区块的过程不同。我们可以借用这个模式在 L2 中使用。基本上，我们只需定义一个函数：接收 L1 区块，对其中的 rollup 交易进行处理，然后产生 L2 区块 —— **与 L1 区块的格式完全相同**。这之后，L2 的执行便可以定义为等同于 L1。

![](https://storage.googleapis.com/papyrus_images/8210c03396ae9198dda40ef13a87d48a31a9c7fe7876631b554675ef48b47d57.png)

**ETH2 Merge API**

那么，现有 L1 客户端实现中的共识/执行模块化的现状如何？好吧：**它即将要在所有以太坊实现中标准化。**

[https://twitter.com/benjaminion\_xyz/status/1446516207159582743?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1446516207159582743%7Ctwgr%5E%7Ctwcon%5Es1\_&ref\_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fbenjaminion\_xyz%2Fstatus%2F1446516207159582743image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07](https://twitter.com/benjaminion_xyz/status/1446516207159582743?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1446516207159582743%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fbenjaminion_xyz%2Fstatus%2F1446516207159582743image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07)

事实证明， [ETH2 合并](https://www.notion.so/5d3201318929487eb080734f9af0170d) 需要的东西与具有 EVM 等同性的 rollup 需要同一种抽象：信标链之于 PoW 链的“父链”角色与 L1 之于 rollup 的角色完全相同。这将使得在 L2 中使用 L1 客户端变得非常简单。

![https://miro.medium.com/max/700/1\*15vPK46LbqmQe6LNFEcj4A.png](https://storage.googleapis.com/papyrus_images/f86b98d332aebb82791d492ac3485f53e05d46eddfda5f5f66619fc643f0ee1d.png)

https://miro.medium.com/max/700/1\\\*15vPK46LbqmQe6LNFEcj4A.png

**执行标准**

好了，我们已经介绍了为什么 EVM 等同性能够让我们实现一个强大的、模块化概念以及完成一个及其简单的客户端实现。但我们如何在链上执行这种操作呢？首先，这种模块化的强大之处在于其灵活性 —— 只要某个解决方案等同于 EVM，我们就能够用它。这意味着不管是对欺诈证明的改进，还是 EVM 等同的零知识证明 (如果可行的话)，都可以轻松地嵌入现有的链下堆栈中。

然而，在短期内，我们目前需要一些可行的方案 —— 我们找到了。有一个方案是这样的，在 Solidity 中实现一个完美的 EVM 等同实现，但是 EVM 十分复杂， 含有许多 VM 指令，因此这是一项十分浩大的任务。此外，未来对 EVM 的更新也必须在 Solidity 中重新实现。

我们的解决方案是：不是在 Solidity 中实现 EVM，而是实现一个具有[更小、更简单指令集](https://en.wikipedia.org/wiki/Reduced_instruction_set_computer)的 VM，并在欺诈证明期间**在该 VM 中运行 EVM**。为此，我们必须简单地编译一个现有的 EVM 编译器，例如 [geth](https://github.com/ethereum/go-ethereum/blob/633e7ef4781453111c4b29e14a65c5335bb9ecac/core/state_processor.go#L59)，以便在更简单的 VM 中运行。

**太长不读**：我们允许 Geth 本身在一个争议友好的环境中运行。由于 Geth 具有 EVM 等同性，它的环境也如此。这样的话，我们就不用在链上重新实现 EVM，并针对 EVM 未来的升级对系统进行未来验证。

我们正在与[我们最喜欢的编译器专家](https://twitter.com/jinglejamOP/status/1310718738417811459?s=20) George Hotz 合作，共同构建首个 [EVM-等同证明系统](https://github.com/geohot/cannon)。进展令人兴奋 —— 自伦敦硬分叉以来，系统已经 [可以运行所有 L1 块](https://github.com/geohot/cannon/commit/00f026451ea5a98ea90278cb201bcfb85131851c)。通过欺诈证明运行 L1 区块是一个有趣的、反直觉的想法 —— 但这正式 EVM 等同性所需要的！

哇 —— 关于这种方案还有很多令人兴奋的事情要说，但我们必须把剩下的内容留给以后的帖子！

展望以太坊的未来
========

> 如果以太坊要实现其以 rollup 为中心的愿景，那么 rollup 必须以以太坊为中心。

这便是 EVM 等同性所提供的。

欺诈证明永垂不朽
--------

这种以 Geth 为中心的模块化设计不仅是供我们使用的优雅实现 —— 这朝着**大众化欺诈证明基础设施**的目标迈出了一大步。目前，想要安全地设计并推出一款 rollup，需要深入了解 L2 的争议博弈设计，以及它们如何与节点软件协同运作。这极大地限制了大家的创新空间 —— 想象一下，如果每个 web 开发者还必须成为 IP 网络、系统管理和微芯片制造方面的专家，这多让人崩溃啊。

未来的 rollup 将非常简单，以至于不需要 L2 专家来部署。这意味着，L2 将不再在“如何”或“是否”提供安全性上竞争，而是在它们提供的安全性内容方面竞争。竞争的内容包括：

*   性能、稳定性和正常运行时间
    
*   网络效应、生态系统专门化和社区
    
*   抗 MEV 性以及定序工具
    

总而言之，这意味着具有 EVM 等同性的各个 rollup 会就其去中心化的程度竞争。这是整个生态系统民主化的巨大胜利，这也是使得整个行业更加反脆弱和抗审查的重要一步。

这也意味着我们的团队终于可以专注于我们的核心能力 —— 这也是最重要的部分 —— 构建世界上最快、最可靠、最安全的 L2 Geth。

以太坊兼容性的束缚已经解除。

让以太坊成为标准
--------

EVM 等同性的的威力归根到底就是它帮我们实现了标准化。

在一个多链的世界中，“一份代码走天下”变得尤其关键。一次性编写好代码，就可以在任意链上部署，这听起来不是很吸引吗？

拥有许多“兼容”的链，每条链都略有不同，这会导致碎片化：从需要单个 EVM 专家团队处理单个代码库，到需要为每条链的每个代码库组建 EVM 专家团队。

Vitalik 将 EVM 比作 Javascript [(甚至在他第一次公开 EVM 的时候就提出了这个概念)](https://youtu.be/l9dpjN3Mwps?t=840)，这个类比在这种情况下得到了很好的体现。在互联网的早期，浏览器之间的不兼容性 (说得就是你，IE 浏览器) 困扰着 web 开发，并导致开发者和生态系统分裂。

Web3 是关于协调和开源标准的，而等同性让 EVM 有望成为标准 —— 以避免重复过去的错误。

即使这个标准不断发展，我们的 L2 也可以毫不费力地协同发展。L1 和 L2 携手向前发展，锁死。

这种好处是双向的 —— 几乎所有的以太坊 EIP 都可以在 L2 上应用，并且 rollup 将成为一个令人兴奋的全新创新实时测试环境。想象一个位于激励测试网和主网之间的 rollup，在自然环境下验证新的交易类型、预编译和 [EOF](https://eips.ethereum.org/EIPS/eip-3540)s，在它们广播至 L1 之前测试不可预见的结果。

DeFi 最大的其中一个障碍就是，随心所欲地测试，没有东西可以替代 DeFi 的实时环境。你无法在一个测试网上“重新创建” DeFi，所以当你想测试更改时，总是需要“在产品中测试”。

EVM 等同性允许我们在实时环境中测试 EIP，并对以太坊整体环境进行更安全、长期的改进，而无需进行“硬分叉”。

以太坊是我们永远的重心
-----------

我们[最近启动](https://medium.com/ethereum-optimism/retropgf-experiment-1-1-million-dollars-for-public-goods-f7e455cbdca)了关于追溯性公共物品募资机制的首个实验。100 万美元的协议收入将很快分配给有利于以太坊生态发展的公共物品！有些人问我们，为什么这些钱会分配给整个以太坊系统，而不是仅仅分配给 Optimistic Ethereum 生态系统。

希望通过本文理解了 EVM 等同性后，大家能明白为什么：我们源自相同的生态系统。

Layer2 长期以来都承诺推动以太坊成为一个多链的系统，充满活力的城市深入探索这个新网络空间的边界。虽然我们可以预期这些链是多样化且丰富的，但 EVM 等同性为这些链和以太坊之间带来了新的连接 —— 不仅仅是作为结算层，而是成为其组成的最深层次部分。

一直以来我们的重心都是以太坊，而且永远都是 🚀

![](https://storage.googleapis.com/papyrus_images/999a52d426a03f5ecbd73b9c9e56f14963701f48c112ab5afaeb88a6d3716330.png)

复活节彩蛋在底部! 😉

我们要真诚地感谢那些帮助我们实现这一目标以及传播我们项目的社区成员: Ansgar Dietrichs、David Hoffman、George Hotz、Georgios Konstantopoulos、lightclients、Magmo 团队、protolambda、ricmoo 等等等等。谢谢你们！！

声明：ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系[ethereumcn@gmail.com](mailto:ethereumcn@gmail.com)进行授权。

---

*Originally published on [EthereumCN](https://paragraph.com/@ethereumcn-2/evm)*
