干货| 深入理解OVM

为什么需要 OVM？

我们团队的很多成员都参与了第一代支持智能合约的通用 Plasma 网络（plapps）的架构设计。 然而，部署 plapps 需要一套全新的开发工具（包括功能有限的“谓词”合约）。 我们很快意识到，人们对以太坊 Layer 2 的期望远不止于此——以太坊 L2 不仅意味着扩展以太坊的应用，更意味着扩展以太坊本身。

上述原因促使我们开发了 Optimistic Rollup——第一个可以将以太坊智能合约的全部功能带入扩展层的 L2 架构。 Unipig.exchange 展示了这个前所未有的新特性：这是 Uniswap 首次部署在 L2 上； 但是，如果我们想让 Uniswap 应用 rollup，我们仍然需要编写具体的 L2 智能合约。 为了打造更好的开发体验，我们还有很长的路要走。

什么是 OVM？

OVM 是用于 L2 系统的全功能、完全 EVM 兼容的执行环境。 我们可以通过OVM在rollup链上进行以太坊主链上的所有操作——编写Solidity智能合约，通过Web3 API与区块链进行交互。

有了 OVM，将 dApps 移植到 L2 不再是架构层面的大工程，只剩下简化的部署操作。 当然，dApp 的构建仍然需要考虑紧耦合和可组合性，但只要你需要，随时可以使用 OVM 将新的智能合约部署到链上。 换句话说，在L2创造货币乐高（money lego，泛指DeFi产品）还是很方便的。

那么，OVM 是如何做到的呢？ 为什么OVM这么难实现？ 让我们找出答案！

问题描述：EVM中的EVM

所有 optimistic L2 解决方案都是围绕执行结果及其差异构建的：从 plasma 到 rollup，关键在于“乐观执行” - 乐观执行意味着：任何人（或组））都可以声明“嘿，Layer 1，执行结果这些交易是X，不需要进行验证！”； 如果结果不是 X，（我们假设）会有​​其他团体愿意支付主链的执行成本来证明结果 X 是错误的。

理想情况下，我们不需要在主链上执行交易，这就是为什么乐观执行可以大大提高链的吞吐量。 但是考虑到安全性，一旦出现错误（比如上图中的tx2），我们还需要一个事务回溯机制！

Unipig的自定义代码基本上就是Unipig编码形式的execute_L2_tx()，你也可以叫它execute_uniswap_tx()！

一般来说，我们需要的是Unipig编码来实现execute_EVM_tx()——一个允许我们在L1交易中嵌套执行任意以太坊L2交易的函数（实现防欺诈功能）。 但理想很丰满深入理解以太坊，现实很骨感。 以太坊交易的嵌套执行是非常困难的，更何况有些L2交易根本不适合L1！

为什么很难在 EVM 中构建 EVM

在我们深入解释我们想出的独特解决方案之前，让我们问一下 - 为什么这是一个问题？ EVM 不是执行 EVM 交易的完美环境吗？ 是EVM！

天真的想法：将智能合约从 L2 重新部署到 L1

EVM 的核心定义了一组计算机指令，并定义了每条指令在一次交易中应该执行什么。 智能合约就像是一个庞大而丑陋的指令集合——作为一个简单的例子，下图是部署前对 Solidity 的 SafeMath.sol 库的部分编译：

如果我们要在L1上执行L2交易，直观的做法是获取L2使用的代码（智能合约），放到L1中； 简而言之，就是直接在L1上部署相应的L2智能合约！

然而，这是不可能做到的，因为：不同的链，不同的结果

这种方法在某些情况下可能会奏效。 例如深入理解以太坊，一个逻辑非常简单的智能合约——SafeMath库，它只进行加减等数学运算； 如果我们把L2的SafeMath合约部署到L1上，在L1上也能正确执行！ 毕竟加法就是加法，减法就是减法，不管执行的是哪条链。

但对于其他智能合约，事情就变得复杂了。 举个简单的例子，下面的智能合约执行后会返回“当前以太坊（区块）时间戳+42”：

contract TimeShifter { function getShiftedTime() returns(uint) {返回块。 时间戳 + 42； }}

（在错误挑战中）将这个合约重新部署到L1后，它还能返回相同的值吗？

明显不是！ （当前区块“之后的区块”的重新部署肯定会返回不同的结果。）即使在同一个 L1 上，如果在两个不同的区块中重新部署智能合约，返回值也会不同——因为部署的合约将得到L1的时间戳，正确执行execute_l2_tx应该返回L2的时间戳。

如果你深入思考，你会发现几乎所有的智能合约都会出现这个问题。 比如一个ERC 20的智能合约，你在L1上重新部署合约后，你如何设置L2上的余额？ 等等，数不胜数。

解决方案：OVM

过去，解决“EVM in EVM”问题有两种方法：要么分叉EVM，要么硬着头皮用Solidity重新实现整个EVM； OVM 是一种全新的方式，因为目前的以太坊 1.0 具有更好的性能和灵活性，并且不需要分叉！

容器化：执行经理

OVM之所以能够解决问题，最重要的原因在于它引入了一种全新的智能合约（Execution Manager，执行管理器）——作为OVM智能合约的虚拟容器。 执行管理器虚拟化所有可能导致 L1 和 L2 不同结果的执行，包括：

基本上，对于可能在 L1 和 L2 中导致不同结果的 EVM 功能，执行管理器提供了保证相同结果的功能。

比如我们构造一个容器来解决上面提到的时间戳不一致的问题：

contract TimestampManager { uint storage ovmTimestamp; 函数 setOvmTimestamp(number: uint) {ovmTimestamp = number; } 函数 getOvmTimestamp() public returns(uint) {return ovmTimestamp; }}

现在我们重新部署上面的合约，这次使用虚拟容器：

contract OvmTimeShifter { function getShiftedTime() returns(uint) {return timestampManager.getOvmTimestamp() + 42;}}

这样我们在验证欺诈证明的时候就可以在L1容器中设置“虚拟区块高度”来保证正确的返回值！

这就是“EVM in EVM”——OVM的核心理念：虚拟化所有可能在不同链上返回不同结果的EVM组件。 具体来说，大约有 15 条以太坊指令需要虚拟化。 您可以从以下条目中看到真正的执行管理器是什么样子的。

安全：容器纯度检查

当然，我们还是需要稍微修改一下上面的合约，让它真正调用时间戳容器，而不是得到错误的block.timestamp。

虽然我们解决了结果不一致的问题，但它只适用于这个智能合约。 因此，为了保证L2的安全，我们需要保证L2上的所有合约都使用timestamp容器，不存在误用block.timestamp的智能合约。

OVM 提供“容器纯度检查”服务——检查目标智能合约“仅通过执行管理器调用虚拟化指令”，不允许像 block.timestamp 这样的操作！ 不管是否有其他智能合约调用目标合约，只要（目标）合约检查失败，就不能部署到OVM。 这确保了 L2 的安全性。

开发经历：翻译

要让智能合约只通过执行管理器调用某些指令，另一个问题是开发经验——如果开发者需要遍历整个智能合约，然后替换所有块。 肯定没有人愿意做奉承的工作。

为了解决这个问题，我们构建了一个转译器——输入纯 EVM 字节码，转译器将使用上述容器输出 OVM 字节码。 对于使用转译器的开发人员，无需直接与 OVM 打交道——只需将我们的 solc-transpiler 包添加到您喜欢的测试套件（如 Waffle 和 Truffle）中即可。

外表

我们认为，OVM 的出现代表了以太坊 L2 的飞跃，因为它不同于以不同的方式使用以太坊，它是以太坊本身的进步。 只需几行代码，就可以实现快速低成本的Solidity智能合约迁移，这是目前我们以太坊扩容最激动人心的话题。 如果你想自己尝试，可以按照我们最近的 OVM 测试——在标准以太坊工具（例如 Graph 和 Burner 钱包）中实时运行 Synthetix 复杂交易合约的一部分（参见此处）。

（结束）

原文链接：

作者：Ethereum Optimism 翻译校对：IAN LIU & A Jian