L2 – 深入理解OVM

在Layer2, Optimistic Rollup通过OVM执行智能合约,并使用“检察”的方式确定Layer2世界状态在Layer1的正确性。Optimistic Rollup的难点也在OVM,需要在EVM的基础上模拟OVM的执行,并判断状态的正确性。目前,Optimistic Rollup的挑战期为7天。也就是说,只有7天前的状态是“确定”的,不会回滚。

Optimistic Rollup是Layer2潜在的一种方案。周末有点时间,在网络上翻了翻。网络上的文章,Optimistic Rollup深入技术的文章不多,介绍OVM底层技术细节的文章则更少。感兴趣看了看Optimism实现的OVM功能相关的智能合约,对Optimistic Rollup的理解很有帮助。总结一下,感兴趣的小伙伴可以看看。 ## 1. Optimistic Rollup vs. zk Rollup 网络上对比这两种Rollup的方案文章不多。主要的一篇文章是: https://medium.com/matter-labs/optimistic-vs-zk-rollup-deep-dive-ea141e71e075 国内也有对应的翻译文章: [Optimistic Rollup vs. ZK Rollup 对比](https://learnblockchain.cn/article/738) 具体的性能和安全性对比,感兴趣的小伙伴可以直接看这篇文章。个人觉得,因为方案都不够成熟,目前方案能够达到的TPS都只是理论值。没必要太多的讨论。主要说说两种Rollup的技术实现的区别: ![](https://img.learnblockchain.cn/2020/11/05/16045408123631.jpg) 两种方案都是Rollup,Layer2的所有Transaction的信息都会作为CallData“存储”在Layer1,并且Layer2的状态也及时同步到Layer1。两者的区别在于,Layer2的状态在Layer1的正确性保证。Optimistic Rollup采用的是“检察”的方式,任何一个节点发现Layer2的状态的错误,提交相关的证明。如果错误的状态被验证,在Layer1的Layer2的状态需要回滚,提交错误状态的节点被惩罚。zk Rollup采用的方式直接了当,在向Layer1提交Layer2状态的同时,提交相关状态改变的证明。这些证明都是在Layer2生成。也就是说,zk Rollup在向Layer1提交Layer2状态的同时,同时提交了Layer2状态转换的计算证明。这个计算证明是通过零知识证明的算法产生。简单的说,如果转换的状态复杂,生成零知识证明的时间越长。 目前,zk Rollup只是支持简单的账户系统以及世界状态,并不能支持智能合约等复杂的世界状态。Optimistic Rollup虽然能支持智能合约,事实上,因为Layer1的计算能力比较弱,智能合约的支持也比较有限。Optimistic Rollup支持的智能合约的执行环境,类似EVM,称为 OVM(Optimistic Virtual Machine)。 ## 2 OVM OVM - Optimistic Virtual Machine。OVM是Layer2交易的执行环境。因为提交到Layer1的状态需要检验正确性,Layer1需要“重放”Layer2的交易,也就是说,Layer1在有些情况下需要执行OVM交易的执行。Optimistic Rollup最复杂的地方也在于此,用EVM模拟OVM,并执行Layer2的交易。 ![](https://img.learnblockchain.cn/2020/11/05/16045408463837.jpg) Optimism实现了EVM模拟OVM的逻辑,相关的项目的Github地址: https://github.com/ethereum-optimism/contracts-v2 本文中使用的代码的最后一个提交信息如下: ``` commit ca1fede6c8cb9e4eacd8205c1d53284d0c8debdc Author: Mark Tyneway Date: Fri Oct 30 12:14:50 2020 -0700 deploy: use layer 2 chainid (#42) ``` 核心代码在contracts-v2/contracts/optimistic-ethereum/OVM目录中。除了OVM目录,iOVM目录是接口定义,libraries目录是各种库的实现,包括编解码,二叉树等等。 ### 2.1 OVM/chain Layer1的智能合约中用两条链维护交易信息和状态信息,分别是CanonicalTransactionChain和StateCommitmentChain。 ![](https://img.learnblockchain.cn/2020/11/05/16045408978919.jpg) Layer2的所有的交易信息,一个个Batch的通过CallData提交到Layer1。每个Batch中的交易的Hash信息组织成Merkle树。简单的说,CanonicalTransactionChain存储的是一个个Batch交易的Merkle树根。这些树根用来判断某个具体的交易是否在链中。 ![](https://img.learnblockchain.cn/2020/11/05/16045409109677.jpg) Layer2的世界状态,通过一个个交易的状态改变来表示。每个交易后的状态也是通过一个个Batch提交到Layer1。每个Batch中的状态,也再次组织成Merkle树。这些树根用来判断某个状态是否在链中。 具体两条链的存储信息,可以查看源代码:OVM_CanonicalTransactionChain.sol和OVM_StateCommitmentChain.sol。 ### 2.2 OVM/execute execute是OVM在EVM执行的核心逻辑,包括**ExecuteManager**,**StateManager**以及**SafetyChecker**。对应的源代码分别是:OVM_ExecutionManager.sol,OVM_SafetyChecker.sol和OVM_StateManager.sol。 ExecuteManager是整个智能合约执行环境以及指令集的处理。OVM其实和EVM逻辑上采用同样的指令集,但是在OVM的环境下,特别在Layer1的EVM执行OVM时,需要将这些指令集“转义”。之所以叫OVM的原因,可能很大程度为了区分EVM,表述方便。蛮多指令需要转义,把OVM在Layer1的实现想象成虚拟机。这些指令包括:TIMESTAMP,CALL,STATICCALL,DELEGATECALL,GASLIMIT,SLOAD,SSTORE等等。一个交易的执行从ExecuteManager的run函数开始: ``` function run( Lib_OVMCodec.Transaction memory _transaction, address _ovmStateManager ) ``` run函数提供了执行的交易,以及执行交易前的状态。 StateManager实现了智能合约以及账户的存储状态管理。ExecuteManager在执行一个交易时会通过StateManager更新状态。 SafetyChecker检查OVM的指令合约中的指令集是否正常,有没有超过目前可以执行的范围。安全性检查通过OVM_SafetyChecker.sol的isBytecodeSafe函数实现。 ``` function isBytecodeSafe( bytes memory _bytecode ) override external pure returns (bool) { ``` ### 2.3 OVM/verification verification是OVM调用的业务逻辑。在Layer1,只是在验证的时候才需要通过OVM执行判断某个交易执行是否正确。verification逻辑中包括了BondManager(抵押管理),StateTransitioner(状态转换管理)和FraudVerifier(错误状态验证逻辑)。FraudVerifier逻辑是最核心的逻辑。整个验证过程的逻辑调用关系如下: ![](https://img.learnblockchain.cn/2020/11/05/16045409678756.jpg) 通过调用initializeFraudVerification函数,开始让Layer1开始验证某个交易执行后的状态是否正确。StateTransitioner准备交易之前的世界状态以及交易执行的中间状态存储。在世界状态准备就绪后(proveContractState/proveStorageSlot),通过调用ExecutionManager的run函数执行交易并更新状态。更新后的状态通过StateTransitioner的completeTransition函数生成世界状态。生成的世界状态和提交的世界状态进行对比,如果不一致,之前提交世界状态的节点通过BondManager进行惩罚。 仔细的分析一下FraudVerifier的initializeFraudVerification和finalizeFraudVerification函数。先从initializeFraudVerification函数开始: ``` function initializeFraudVerification( bytes32 _preStateRoot, Lib_OVMCodec.ChainBatchHeader memory _preStateRootBatchHeader, Lib_OVMCodec.ChainInclusionProof memory _preStateRootProof, Lib_OVMCodec.Transaction memory _transaction, Lib_OVMCodec.TransactionChainElement memory _txChainElement, Lib_OVMCodec.ChainBatchHeader memory _transactionBatchHeader, Lib_OVMCodec.ChainInclusionProof memory _transactionProof ) ``` _preStateRoot是之前的世界状态的Merkle树根。通过_preStateRootBatchHeader和_preStateRootProof可以验证某个状态是在StateCommitmentChain上。 ``` require( ovmStateCommitmentChain.verifyStateCommitment( _preStateRoot, _preStateRootBatchHeader, _preStateRootProof ), "Invalid pre-state root inclusion proof." ); ``` _transction信息是需要验证的交易信息。通过_txChainElement,_transactionBatchHeader以及_transactionProof可以验证某个交易是否在CanonicalTransactionChain上。 ``` require( ovmCanonicalTransactionChain.verifyTransaction( _transaction, _txChainElement, _transactionBatchHeader, _transactionProof ), "Invalid transaction inclusion proof." ); ``` 在确定了交易以及状态都合法后,创建StateTransitioner准备执行交易。 ``` transitioners[_preStateRoot] = iOVM_StateTransitionerFactory( resolve("OVM_StateTransitionerFactory") ).create( address(libAddressManager), _preStateRootProof.index, _preStateRoot, Lib_OVMCodec.hashTransaction(_transaction) ); ``` 执行交易的逻辑,直接忽略,感兴趣的小伙伴可以看OVM_StateTransitioner.sol的applyTransaction函数。交易执行完,通过finalizeFraudVerification函数检查执行后的世界状态的结果。 ``` function finalizeFraudVerification( bytes32 _preStateRoot, Lib_OVMCodec.ChainBatchHeader memory _preStateRootBatchHeader, Lib_OVMCodec.ChainInclusionProof memory _preStateRootProof, bytes32 _postStateRoot, Lib_OVMCodec.ChainBatchHeader memory _postStateRootBatchHeader, Lib_OVMCodec.ChainInclusionProof memory _postStateRootProof ) ``` 先检查提供的两个世界状态是否在StateCommitmentChain上存在: ``` require( ovmStateCommitmentChain.verifyStateCommitment( _preStateRoot, _preStateRootBatchHeader, _preStateRootProof ), "Invalid pre-state root inclusion proof." ); require( ovmStateCommitmentChain.verifyStateCommitment( _postStateRoot, _postStateRootBatchHeader, _postStateRootProof ), "Invalid post-state root inclusion proof." ); ``` 并且,保证两个状态是连续的: ``` require( _postStateRootProof.index == _preStateRootProof.index + 1, "Invalid post-state root index." ); ``` 查看OVM执行的世界状态是否和提交的状态一致: ``` require( _postStateRoot != transitioner.getPostStateRoot(), "State transition has not been proven fraudulent." ); ``` 如果不一致,需要回滚世界状态: ``` ovmStateCommitmentChain.deleteStateBatch( _postStateRootBatchHeader ); ``` 并且对提交世界状态的节点进行惩罚: ``` ovmBondManager.finalize( _preStateRoot, _postStateRootBatchHeader.batchIndex, publisher, timestamp ); ``` 简单的看,OVM在EVM的模拟,涉及到两个重要的点:1/之前世界状态的表示 2/当前交易的执行。整个逻辑涉及到多次Layer1的交易,除此之外,还需要足够的时间保证链上数据能够同步并检查。目前,世界状态的挑战过程必须在相应交易后的7天内完成: ``` /// The dispute period uint256 public constant disputePeriodSeconds = 7 days; ``` ## 总结: Optimistic Rollup是Layer2潜在的一种方案。和zk Rollup一样,所有Transaction的信息都会作为CallData“存储”在Layer1。在Layer2, Optimistic Rollup通过OVM执行智能合约,并使用“检察”的方式确定Layer2世界状态在Layer1的正确性。Optimistic Rollup的难点也在OVM,需要在EVM的基础上模拟OVM的执行,并判断状态的正确性。目前,Optimistic Rollup的挑战期为7天。也就是说,只有7天前的状态是“确定”的,不会回滚。 ![](https://img.learnblockchain.cn/2020/08/13/15973018578548.jpg!/scale/20)

Optimistic Rollup是Layer2潜在的一种方案。周末有点时间,在网络上翻了翻。网络上的文章,Optimistic Rollup深入技术的文章不多,介绍OVM底层技术细节的文章则更少。感兴趣看了看Optimism实现的OVM功能相关的智能合约,对Optimistic Rollup的理解很有帮助。总结一下,感兴趣的小伙伴可以看看。

1. Optimistic Rollup vs. zk Rollup

网络上对比这两种Rollup的方案文章不多。主要的一篇文章是:

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

国内也有对应的翻译文章:

Optimistic Rollup vs. ZK Rollup 对比

具体的性能和安全性对比,感兴趣的小伙伴可以直接看这篇文章。个人觉得,因为方案都不够成熟,目前方案能够达到的TPS都只是理论值。没必要太多的讨论。主要说说两种Rollup的技术实现的区别:

两种方案都是Rollup,Layer2的所有Transaction的信息都会作为CallData“存储”在Layer1,并且Layer2的状态也及时同步到Layer1。两者的区别在于,Layer2的状态在Layer1的正确性保证。Optimistic Rollup采用的是“检察”的方式,任何一个节点发现Layer2的状态的错误,提交相关的证明。如果错误的状态被验证,在Layer1的Layer2的状态需要回滚,提交错误状态的节点被惩罚。zk Rollup采用的方式直接了当,在向Layer1提交Layer2状态的同时,提交相关状态改变的证明。这些证明都是在Layer2生成。也就是说,zk Rollup在向Layer1提交Layer2状态的同时,同时提交了Layer2状态转换的计算证明。这个计算证明是通过零知识证明的算法产生。简单的说,如果转换的状态复杂,生成零知识证明的时间越长。

目前,zk Rollup只是支持简单的账户系统以及世界状态,并不能支持智能合约等复杂的世界状态。Optimistic Rollup虽然能支持智能合约,事实上,因为Layer1的计算能力比较弱,智能合约的支持也比较有限。Optimistic Rollup支持的智能合约的执行环境,类似EVM,称为 OVM(Optimistic Virtual Machine)。

2 OVM

OVM - Optimistic Virtual Machine。OVM是Layer2交易的执行环境。因为提交到Layer1的状态需要检验正确性,Layer1需要“重放”Layer2的交易,也就是说,Layer1在有些情况下需要执行OVM交易的执行。Optimistic Rollup最复杂的地方也在于此,用EVM模拟OVM,并执行Layer2的交易。

Optimism实现了EVM模拟OVM的逻辑,相关的项目的Github地址:

https://github.com/ethereum-optimism/contracts-v2

本文中使用的代码的最后一个提交信息如下:

commit ca1fede6c8cb9e4eacd8205c1d53284d0c8debdc
Author: Mark Tyneway 
Date:   Fri Oct 30 12:14:50 2020 -0700

 deploy: use layer 2 chainid (#42)

核心代码在contracts-v2/contracts/optimistic-ethereum/OVM目录中。除了OVM目录,iOVM目录是接口定义,libraries目录是各种库的实现,包括编解码,二叉树等等。

2.1 OVM/chain

Layer1的智能合约中用两条链维护交易信息和状态信息,分别是CanonicalTransactionChain和StateCommitmentChain。

Layer2的所有的交易信息,一个个Batch的通过CallData提交到Layer1。每个Batch中的交易的Hash信息组织成Merkle树。简单的说,CanonicalTransactionChain存储的是一个个Batch交易的Merkle树根。这些树根用来判断某个具体的交易是否在链中。

Layer2的世界状态,通过一个个交易的状态改变来表示。每个交易后的状态也是通过一个个Batch提交到Layer1。每个Batch中的状态,也再次组织成Merkle树。这些树根用来判断某个状态是否在链中。

具体两条链的存储信息,可以查看源代码:OVM_CanonicalTransactionChain.sol和OVM_StateCommitmentChain.sol。

2.2 OVM/execute

execute是OVM在EVM执行的核心逻辑,包括ExecuteManagerStateManager以及SafetyChecker。对应的源代码分别是:OVM_ExecutionManager.sol,OVM_SafetyChecker.sol和OVM_StateManager.sol。

ExecuteManager是整个智能合约执行环境以及指令集的处理。OVM其实和EVM逻辑上采用同样的指令集,但是在OVM的环境下,特别在Layer1的EVM执行OVM时,需要将这些指令集“转义”。之所以叫OVM的原因,可能很大程度为了区分EVM,表述方便。蛮多指令需要转义,把OVM在Layer1的实现想象成虚拟机。这些指令包括:TIMESTAMP,CALL,STATICCALL,DELEGATECALL,GASLIMIT,SLOAD,SSTORE等等。一个交易的执行从ExecuteManager的run函数开始:

 function run(
 Lib_OVMCodec.Transaction memory _transaction,
 address _ovmStateManager
 )

run函数提供了执行的交易,以及执行交易前的状态。

StateManager实现了智能合约以及账户的存储状态管理。ExecuteManager在执行一个交易时会通过StateManager更新状态。

SafetyChecker检查OVM的指令合约中的指令集是否正常,有没有超过目前可以执行的范围。安全性检查通过OVM_SafetyChecker.sol的isBytecodeSafe函数实现。

 function isBytecodeSafe(
 bytes memory _bytecode
 )
 override
 external
 pure
 returns (bool)
 {

2.3 OVM/verification

verification是OVM调用的业务逻辑。在Layer1,只是在验证的时候才需要通过OVM执行判断某个交易执行是否正确。verification逻辑中包括了BondManager(抵押管理),StateTransitioner(状态转换管理)和FraudVerifier(错误状态验证逻辑)。FraudVerifier逻辑是最核心的逻辑。整个验证过程的逻辑调用关系如下:

通过调用initializeFraudVerification函数,开始让Layer1开始验证某个交易执行后的状态是否正确。StateTransitioner准备交易之前的世界状态以及交易执行的中间状态存储。在世界状态准备就绪后(proveContractState/proveStorageSlot),通过调用ExecutionManager的run函数执行交易并更新状态。更新后的状态通过StateTransitioner的completeTransition函数生成世界状态。生成的世界状态和提交的世界状态进行对比,如果不一致,之前提交世界状态的节点通过BondManager进行惩罚。

仔细的分析一下FraudVerifier的initializeFraudVerification和finalizeFraudVerification函数。先从initializeFraudVerification函数开始:

 function initializeFraudVerification(
 bytes32 _preStateRoot,
 Lib_OVMCodec.ChainBatchHeader memory _preStateRootBatchHeader,
 Lib_OVMCodec.ChainInclusionProof memory _preStateRootProof,
 Lib_OVMCodec.Transaction memory _transaction,
 Lib_OVMCodec.TransactionChainElement memory _txChainElement,
 Lib_OVMCodec.ChainBatchHeader memory _transactionBatchHeader,
 Lib_OVMCodec.ChainInclusionProof memory _transactionProof
 )

_preStateRoot是之前的世界状态的Merkle树根。通过_preStateRootBatchHeader和_preStateRootProof可以验证某个状态是在StateCommitmentChain上。

 require(
 ovmStateCommitmentChain.verifyStateCommitment(
 _preStateRoot,
 _preStateRootBatchHeader,
 _preStateRootProof
 ),
 "Invalid pre-state root inclusion proof."
 );

_transction信息是需要验证的交易信息。通过_txChainElement,_transactionBatchHeader以及_transactionProof可以验证某个交易是否在CanonicalTransactionChain上。

 require(
 ovmCanonicalTransactionChain.verifyTransaction(
 _transaction,
 _txChainElement,
 _transactionBatchHeader,
 _transactionProof
 ),
 "Invalid transaction inclusion proof."
 );

在确定了交易以及状态都合法后,创建StateTransitioner准备执行交易。

 transitioners[_preStateRoot] = iOVM_StateTransitionerFactory(
 resolve("OVM_StateTransitionerFactory")
 ).create(
 address(libAddressManager),
 _preStateRootProof.index,
 _preStateRoot,
 Lib_OVMCodec.hashTransaction(_transaction)
 );

执行交易的逻辑,直接忽略,感兴趣的小伙伴可以看OVM_StateTransitioner.sol的applyTransaction函数。交易执行完,通过finalizeFraudVerification函数检查执行后的世界状态的结果。

 function finalizeFraudVerification(
 bytes32 _preStateRoot,
 Lib_OVMCodec.ChainBatchHeader memory _preStateRootBatchHeader,
 Lib_OVMCodec.ChainInclusionProof memory _preStateRootProof,
 bytes32 _postStateRoot,
 Lib_OVMCodec.ChainBatchHeader memory _postStateRootBatchHeader,
 Lib_OVMCodec.ChainInclusionProof memory _postStateRootProof
 )

先检查提供的两个世界状态是否在StateCommitmentChain上存在:

 require(
 ovmStateCommitmentChain.verifyStateCommitment(
 _preStateRoot,
 _preStateRootBatchHeader,
 _preStateRootProof
 ),
 "Invalid pre-state root inclusion proof."
 );

 require(
 ovmStateCommitmentChain.verifyStateCommitment(
 _postStateRoot,
 _postStateRootBatchHeader,
 _postStateRootProof
 ),
 "Invalid post-state root inclusion proof."
 );

并且,保证两个状态是连续的:

 require(
 _postStateRootProof.index == _preStateRootProof.index + 1,
 "Invalid post-state root index."
 );

查看OVM执行的世界状态是否和提交的状态一致:

 require(
 _postStateRoot != transitioner.getPostStateRoot(),
 "State transition has not been proven fraudulent."
 );

如果不一致,需要回滚世界状态:

 ovmStateCommitmentChain.deleteStateBatch(
 _postStateRootBatchHeader
 );

并且对提交世界状态的节点进行惩罚:

 ovmBondManager.finalize(
 _preStateRoot,
 _postStateRootBatchHeader.batchIndex,
 publisher,
 timestamp
 );

简单的看,OVM在EVM的模拟,涉及到两个重要的点:1/之前世界状态的表示 2/当前交易的执行。整个逻辑涉及到多次Layer1的交易,除此之外,还需要足够的时间保证链上数据能够同步并检查。目前,世界状态的挑战过程必须在相应交易后的7天内完成:

 /// The dispute period
 uint256 public constant disputePeriodSeconds = 7 days;

总结:

Optimistic Rollup是Layer2潜在的一种方案。和zk Rollup一样,所有Transaction的信息都会作为CallData“存储”在Layer1。在Layer2, Optimistic Rollup通过OVM执行智能合约,并使用“检察”的方式确定Layer2世界状态在Layer1的正确性。Optimistic Rollup的难点也在OVM,需要在EVM的基础上模拟OVM的执行,并判断状态的正确性。目前,Optimistic Rollup的挑战期为7天。也就是说,只有7天前的状态是“确定”的,不会回滚。

区块链技术网。

  • 发表于 2020-11-05 09:56
  • 阅读 ( 1183 )
  • 学分 ( 37 )
  • 分类:Rollup

评论