什么是 EVM 等效性？
简单说： EVM 等效性完全符合 以太坊黄皮书，后者是对该协议的正式定义。根据定义，L1 以太坊软件必须符合这一规范。这意味着—从最根本上讲，现有的以太坊堆栈现在也将与 L2 系统集成——每个 debugger 。每个工具链。每个节点实现。我们相信，任何提供 EVM 体验的 L2 都必须满足这一标准——任何不足都是不可接受的。
为什么 EVM 等效性是个好方案？
从第 0 天起，我们就在 Geth （以太坊最强大和最受欢迎的部署）上构建了我们的软件——这是通往生产就绪的以太坊 L2 解决方案的唯一可行途径。 OVM v1 引入了一个容器化系统，位于 Geth 的 EVM 之上，有助于避免在 L1 上繁琐地重新实现整个 EVM。
这一组合在早期取得一定程度的成功，但由于 EVM 本身不支持容器化，所以它不是免费的。即使对于我们专注于 Geth 的团队，这些变化也开始累积。随着 Optimistic 以太坊的发展壮大， 等效性具备令人难以置信的力量：
Solidity、Vyper 和 Hardhat 等项目无私地致力于开发其 OVM 版本的开发工具，但我们制造出的风险是：让这些本身资源已经很有限的团队进一步分散资源。这教会我们，各家团队总是需要投入人力来维护非等效的代码库。
随着每一行代码的改变，采用像 Erigon 这样的实验性部署变得更加困难。 这教会我们，我们将始终需要致力于整合未来的客户部署。
与现有的超优化版本相比，重新实现部分 EVM 会制造出 gas 开销。这教会我们，要实现 gas 成本最小化，需要 EVM 等效设计理念。
是时候寻求更好的解决方法了，即使解决方案可能有一些乏味。
如何实现 EVM 等效性？
值得庆幸的是，我们找到了更好的方法，不用在 EVM 中繁琐地重新部署 EVM。以下步骤就是你要做的。
实现区块生产和执行的分离
在实践中，我们确实必须对嘉盛外汇jiashengib.com以太坊的 L2 进行一些更改：特别是如何生成区块。在 L1 上，节点使用工作量证明（PoW）共识机制来确定区块；在 L2 上，通过发送分批交易到「父链」（L1 以太坊）实现批量交易。如果 L2 使用自己的 PoW 共识，它将是 L1！ 所以「等效性」在这个层面上基本上是荒谬的。
区块链模块化的一个核心特征是将共识与执行分离——也就是说，确定和执行下一个区块分别通过不同的过程完成。我们可以借用这个模式，在 L2 中加以使用。简单说，我们只是定义了一个函数，它接收 L1 区块，处理它们以进行 rollup 交易，并以与 L1 区块完全相同的格式输出 L2 区块。因此，L2 执行可以定义为等效于 L1。
以太坊 2.0 合并 API
现有 L1 客户端部署中的共识 / 执行模块化的状态如何？ 它将在所有以太坊部署方案中实现标准化。
事实证明，以太坊 2.0 合并 需要与 EVM 等效 Rollup 完全相同的抽象：信标链等同于 L1 为 Rollup 所做的完全相同的「父链」角色。这将使在 L2 中使用 L1 客户端变得非常简单。
好的，我们已经介绍了为什么等效性为强大的模块化抽象和极其简单的客户端部署打开了大门。但我们如何在链上实际执行这一操作？
首先，这种模块化的强大之处在于灵活——只要解决方案与 EVM 等效，我们就可以使用它。而当它们变得可行时，这意味着对防欺诈证明的改进，甚至是等效于 EVM 的零知识证明，都可以轻松地插入现有的链下堆栈中。
不过从短期来看，我们目前需要一些可行的方法——我们已经找到了这一点。 一种解决方案是在 Solidity 中实现完美的 EVM 等效部署，但 EVM 是一个复杂的野兽，具有许多 VM 指令，因此这是一项艰巨的任务。此外，未来对 EVM 的更新也必须在 Solidity 中重新部署。
我们的解决方案是：不是在 Solidity 中部署 EVM，而是 部署 一个具有更小、更简单指令集的 VM，并在防欺诈证明期间在这一 VM 中运行 EVM。为此，我们必须简单地编译一个现有的 EVM 编译器，例如 geth，以便在更简单的 VM 中运行。
简单总结一下：我们允许 Geth 本身在一个有争议的环境中运行。由于 Geth 与 EVM 等效，因此这一环境也是如此。我们因此能够绕过在链上重新部署 EVM 的难度，同时摆脱应对 EVM 未来升级的繁重工作，使这一解决方案不会很快过时。
