核心|深入了解最佳汇总执行环境OVM

**上卷的难点是OVM，它需要在EVM的基础上模拟OVM的实现，并判断状态的正确性。

标题：L2-深入了解OVM a632:star Li

**汇总是第2层的一个潜在解决方案。周末的时候，我上网。互联网上的文章很少，关于**汇总的深层技术的文章也很少，关于OVM细节的文章也很少。有兴趣研究由Optimi实现的与OVM函数相关的智能契约，有助于理解优化汇总。综上所述，感兴趣的合作伙伴可以看到。

乐观汇总vs.ZK汇总

在网络上很少有文章比较这两种汇总方案。

主要文章：

https://medium.com/matter-labs/optimistic-vs-zk-rollup-deep-pe-ea141e71e075

对应翻译文章：

https://www.chainnews.com/articles/932935429481.htm

对于具体的性能和安全性比较，感兴趣的合作伙伴可以直接阅读本文。个人认为，由于方案还不够成熟，目前方案所能实现的TPS只是理论上的价值。没有必要太多的讨论。主要内容是讨论这两种汇总技术的区别

两个方案都是汇总的。Layer2的所有事务信息作为calldata存储在第一层，Layer2的状态会及时同步到第一层。两者之间的区别在于，第1层的状态保证是正确的。优化汇总采用“检察”方法。任何节点发现Layer2状态错误并提交相关证明。如果验证了错误状态，则需要回滚第1层中第2层的状态，并惩罚提交错误状态的节点。ZK rollup采用直接方式将第2层状态提交给第1层，并提交相关状态变化的证明。这些证书在Layer2生成。也就是说，ZK rollup将第2层状态提交给第1层，同时提交第2层状态转换的计算证明。该证明由零知识证明算法生成。简而言之，如果变换的状态很复杂，生成零知识证明的时间越长。

目前，ZK-rollup只支持简单的账户系统和世界状态，不能支持智能合约等复杂的世界状态。虽然**汇总可以支持智能合约，但事实上，第1层算力较弱，对智能合约的支持有限。与EVM类似，**上卷支持的智能合约实现环境称为OVM（optimal virtual machine）。

卵母细胞

OVM-乐观虚拟机。OVM是Layer2事务的执行环境。由于提交给第1层的状态需要验证正确性，所以第1层需要重放第2层的事务，即在某些情况下，第1层需要执行OVM事务。优化汇总最复杂的部分是它用EVM模拟OVM并执行第2层事务。

Optimi实现了OVM逻辑的EVM模拟，以及相关项目的GitHub地址。

本文中使用的代码的**一次提交如下：

核心代码位于contracts-v2/contracts/optimal ETHereum/OVM目录中。除了OVM目录外，iovm目录是接口定义，libraries目录是各种库的实现，包括codec、二进制树等。

OVM/链

在第1层智能合约中，使用两条链来维护事务信息和状态信息，即规范事务链和状态承诺链。

Layer2的所有事务信息通过calldata逐个提交到第一层。每个批中事务的哈希信息被组织成一个Merkle树。简而言之，规范事务链存储批处理事务的Merkle树根。这些根用于确定特定事务是否在链中。

Layer2的世界状态由每个事务的状态变化来表示。每个事务处理后的状态也通过批处理提交到第一层。每一批中的状态也被重新组织成Merkle树。这些树根用于确定状态是否在链中。

关于这两条链的存储信息，可以查看源代码：OVM_ucanonicalTransactionChain.SOL还有奥文状态承诺链.SOL。

OVM/执行

Execute是EVM中OVM的核心逻辑，包括executemanager、statemanager和safetychecker。对应的源代码是：OVMu执行管理器.SOL，奥维姆安全检查器.SOL还有奥文状态管理器.SOL。

Executemanager是整个智能合约执行环境和指令集的处理。实际上，OVM和EVM在逻辑上使用相同的指令集，但是在OVM环境中，特别是当第一层的EVM执行OVM时，这些指令集需要被“转义”。之所以称之为OVM，可能是因为它便于区分EVM。许多指令需要转义。把第一层的OVM实现想象成一个虚拟机。这些指令包括：timestamp、call、staticcall、delegatecall、gaslimit、load、sstore等。事务的执行从executemanager的run函数开始

run函数提供执行的事务和执行事务之前的状态。

Statemanager实现智能合约和账户的存储状态管理。执行事务时，Executemanager通过statemanager更新状态。

safetychecker检查OVM的指令契约中的指令集是否正常，是否超出当前可执行范围。安全检查通过安全检查器.SOLIytecodesafe函数实现。

OVM/验证

验证是OVM调用的业务逻辑。在第1层中，只有在验证时才需要执行OVM来判断事务是否正确执行。验证逻辑包括债券管理器（抵押管理）、状态转换器（状态转换管理）和欺诈验证器（错误状态验证逻辑）。欺诈验证逻辑是核心逻辑。整个验证过程的逻辑调用关系如下：

通过调用initializefraudverification函数，层1开始验证执行后事务的状态是否正确。Statetransitioner准备事务之前的世界状态和事务执行的中间状态存储。在世界状态就绪（provecontractstate/provestoragesLoot）之后，事务将被执行，并通过调用executionmanager的run函数更新状态。更新后的状态通过statetransitioner的completeTransition函数生成世界状态。生成的世界状态与提交的世界状态进行比较。如果不一致，将通过bondmanager惩罚之前提交世界状态的节点。

本文详细分析了验证和细分功能。从initializefraudverification函数开始

一种前物质是前世界状态的Merkle树根。通过Prestaterootbatchheader和_U的prestate根证明可以验证一个状态是否在状态承诺链上。

一种交易信息是需要验证的交易信息。通过_xChaineElement、Transactionbatchheader和_uTransaction-proof可以验证事务是否在规范事务链上。

在确认事务和状态合法之后，创建statetransitioner来执行事务。

事务逻辑被直接忽略。感兴趣的合作伙伴可以查看OVM状态传递器.SOL的apptransaction函数。事务执行后，finalizefraudverification函数用于检查执行后世界状态的结果。

首先，检查所提供的两个世界国家是否存在于国家承诺链上：

此外，这两种状态保证是连续的

检查OVM执行的世界状态是否与提交状态一致：

如果不一致，则需要回滚世界状态：

提交世界状态的节点将受到惩罚

简言之，EVM中OVM的模拟涉及到两个重要方面：1/前一世界状态的表示和2/当前事务的执行。整个逻辑涉及多个第1层事务。此外，它还需要足够的时间来确保链上的数据可以同步和检查。目前，《世界状况》的质询程序必须在相应交易完成后7天内完成：

总结

**汇总是第2层的一个潜在解决方案。与ZK rollup一样，所有事务信息都作为calldata“存储”在第1层中。在Layer2，**上卷通过OVM执行智能合约，并使用“检查”方法来确定第一层Layer2世界状态的正确性。**上卷的难点也在于OVM。在EVM的基础上模拟OVM的执行，判断状态的正确性。目前，**汇总的挑战期是7天。换言之，只有7天前的状态是“已确认”，不会回滚。