为什么需要OVM？
我们团队中的许多成员都曾参与过致力于支持智能合约的第一代通用plasma网络的架构设计。然而，部署plapps需要借助一整套新的开发工具。我们很快意识到，人们对于以太坊Layer2的期待远不止此——以太坊L2不只意味着扩展以太坊的应用，还要扩展以太坊本身。
以上原因促使我们开发了OptimisticRollup——首个能将以太坊智能合约的全部功能引入扩展层的L2架构。Unipig
}
把这个合约重新部署到L1上之后，还能返回相同的值吗？
-不同的链，不同的结果-
明显不行！即使是在同一条L1上，如果将智能合约重部署在不同的两个区块，返回值也不一样——因为重部署的合约会获取L1的时间戳，而正确执行?execute_l2_tx?则应该返回L2的时间戳。
如果你深入思考，你会发现这个问题几乎会发生在所有智能合约上。比如对于某个ERC20智能合约来说，你将合约重部署在L1上之后，你要怎么设置L2上的余额呢？诸如此类，不可胜数。
解决之道：OVM
过去曾出现过两种解决“EVM中的EVM”问题的办法：要么是对EVM进行分叉，要么是硬着头皮用Solidity重新实现整个EVM；OVM是一种全新的方法，对于当前的以太坊1.0有着更好的性能和灵活性，而且不需要分叉！
容器化：执行管理器
OVM能够解决问题的最重要原因是，它引入了一个全新的智能合约——作为OVM智能合约的虚拟容器。执行管理器会虚拟化所有可能导致L1、L2出现不同结果的执行，包括：
智能合约存储内容
交易内容——如区块高度、时间戳、tx.origin?的帐户的地址），等等。
跨合约信息的路由
基本上，对于可能导致L1、L2出现不同结果的EVM功能，执行管理器都提供了保证其结果一致的函数。
举例来说，我们构造一个容器来解决上述提到的时间戳不一致的问题：
现在我们重部署上面的合约，这回我们使用虚拟容器：
如此一来，我们就能够在验证fraudproof的时候，设置L1容器中的“虚拟区块高度”，来保证正确的返回值！
-新的TimeShifter函数，使用TimestampManager作为容器。-
这就是"EVM中的EVM"——OVM的核心概念：虚拟化所有可能在不同链上返回不同结果的EVM组件。具体点来说，约有15条以太坊指令需要被虚拟化，你可以从以下入口查看真正的执行管理器长啥样。
安全性：容器纯度检查
当然我们还需要稍微修改上面的合约，才能真正调用timestamp容器而不是拿到错误的?block.timestamp。
虽然我们解决了结果差异性的问题，但这只作用于该智能合约而已。因此，为了保障L2的安全性，我们需要确保L2上的所有合约都使用了timestamp容器，没有错误使用?block.timestamp?的漏网之智能合约。
OVM提供了“容器纯度检查”的服务——检查目标智能合约“是否只通过执行管理器来调用虚拟化指令”，而不允许像是?block.timestamp?这样的操作！不论有没有其他智能合约调用了目标合约，只要合约未通过检查，就无法部署到OVM。这样就能保证L2的安全性。
开发体验：转译器
要让智能合约只通过执行管理器来调用某些指令，还有一个问题就是开发体验——如果开发者需要遍历整份智能合约，然后把所有?block.timestamp?替换为?getOvmTimestamp()，这种费力不讨好的活肯定没人愿意做。
为了解决这个问题，我们搭了一个转译器——输入普通EVM字节码，然后转译器会输出使用上述容器的OVM字节码。对于使用转译器的开发者来说，完全不需要和OVM直接打交道?——只需要在Waffle、Truffle等你喜欢的测试套件中加入我们的?solc-transpiler?包。
展望
我们认为OVM的出现代表着以太坊L2的飞跃，因为它不同于变着招?使用?以太坊，它就是以太坊本身的进步。只要加上几行代码，就能够实现快速且低成本的Solidity智能合约迁移，这也是当前关于以太坊扩展方面最令我们兴奋的topic。如果你想要自行体验一把，可以关注我们最近的OVM测试——在标准的以太坊工具中，实时运行部分的Synthetix复杂交易合约。
原文链接:
https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52
作者:?EthereumOptimism
翻译&校对:?IANLIU?&阿剑
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。