硬核 – 深化了解 Optimistic Rollup 履行环境 OVM

硬核 | 深化了解 Optimistic Rollup 履行环境 OVM

Optimistic Rollup 的难点在于 OVM,需求在 EVM 的基础上模仿 OVM 的履行,并判别状况的正确性。…以太坊,Layer 2,EVM,OVM,Optimistic Rollup,ZK Rollup,Rollup 以太坊 Layer 2 EVM OVM Optimistic Rollup ZK Rollup Rollup星主意 图标 Logo星主意区块链作者,团队,专栏,大众号,头条· ·阅览约 5 分钟

Optimistic Rollup 的难点在于 OVM,需求在 EVM 的基础上模仿 OVM 的履行,并判别状况的正确性。

原文标题:《L2 – 深化了解 OVM》
撰文:Star Li

Optimistic Rollup 是 Layer 2 潜在的一种计划。周末有点时刻,在网络上翻了翻。网络上的文章,Optimistic Rollup 深化技能的文章不多,介绍 OVM 底层技能细节的文章则更少。感兴趣看了看 Optimism 完结的 OVM 功用相关的智能合约,对 Optimistic Rollup 的了解很有协助。总结一下,感兴趣的小伙伴可以看看。

Optimistic Rollup vs. ZK Rollup

网络上比照这两种 Rollup 的计划文章不多。

首要的一篇文章:

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

对应的翻译文章:

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

详细的功能和安全性比照,感兴趣的小伙伴可以直接看这篇文章。个人觉得,由于计划都不行老练,现在计划可以到达的 TPS 都仅仅理论值。没必要太多的评论。首要说说两种 Rollup 的技能完结的差异:

硬核 | 深化了解 Optimistic Rollup 履行环境 OVM

两种计划都是 Rollup,Layer 2 的一切 Transaction 的信息都会作为 CallData「存储」在 Layer 1,而且 Layer 2 的状况也及时同步到 Layer 1。两者的差异在于,Layer 2 的状况在 Layer 1 的正确性确保。Optimistic Rollup 选用的是「查看」的方法,任何一个节点发现 Layer 2 的状况的过错,提交相关的证明。假如过错的状况被验证,在 Layer 1 的 Layer 2 的状况需求回滚,提交过错状况的节点被赏罚。ZK Rollup 选用的方法直接了当,在向 Layer 1 提交 Layer 2 状况的一起,提交相关状况改动的证明。这些证明都是在 Layer 2 生成。也就是说,ZK Rollup 在向 Layer 1 提交 Layer 2 状况的一起,一起提交了 Layer 2 状况转化的核算证明。这个核算证明是经过零常识证明的算法发生。简略的说,假如转化的状况杂乱,生成零常识证明的时刻越长。

现在,ZK Rollup 仅仅支撑简略的账户体系以及国际状况,并不能支撑智能合约等杂乱的国际状况。Optimistic Rollup 虽然能支撑智能合约,事实上,由于 Layer 1 的核算才能比较弱,智能合约的支撑也比较有限。Optimistic Rollup 支撑的智能合约的履行环境,相似 EVM,称为 OVM (Optimistic Virtual Machine)。

OVM

OVM – Optimistic Virtual Machine。OVM 是 Layer 2 买卖的履行环境。由于提交到 Layer 1 的状况需求查验正确性,Layer 1 需求「重放」Layer 2 的买卖,也就是说,Layer 1 在有些情况下需求履行 OVM 买卖的履行。Optimistic Rollup 最杂乱的当地也在于此,用 EVM 模仿 OVM,并履行 Layer 2 的买卖。

硬核 | 深化了解 Optimistic Rollup 履行环境 OVM

Optimism 完结了 EVM 模仿 OVM 的逻辑,相关的项目的 Github 地址。

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

    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 目录是各种库的完结,包含编解码,二叉树等等。

OVM/chain

Layer 1 的智能合约顶用两条链保护买卖信息和状况信息,分别是 CanonicalTransactionChain 和 StateCommitmentChain。

硬核 | 深化了解 Optimistic Rollup 履行环境 OVM

Layer 2 的一切的买卖信息,一个个 Batch 的经过 CallData 提交到 Layer 1。每个 Batch 中的买卖的 Hash 信息组织成 Merkle 树。简略的说,CanonicalTransactionChain 存储的是一个个 Batch 买卖的 Merkle 树根。这些树根用来判别某个详细的买卖是否在链中。

硬核 | 深化了解 Optimistic Rollup 履行环境 OVM

Layer 2 的国际状况,经过一个个买卖的状况改动来表明。每个买卖后的状况也是经过一个个 Batch 提交到 Layer 1。每个 Batch 中的状况,也再次组织成 Merkle 树。这些树根用来判别某个状况是否在链中。

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

OVM/execute

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

ExecuteManager 是整个智能合约履行环境以及指令集的处理。OVM 其实和 EVM 逻辑上选用相同的指令集,但是在 OVM 的环境下,特别在 Layer 1 的 EVM 履行 OVM 时,需求将这些指令集「转义」。之所以叫 OVM 的原因,或许很大程度为了区别 EVM,表述便利。蛮多指令需求转义,把 OVM 在 Layer 1 的完结幻想成虚拟机。这些指令包含: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)           {

OVM/verification

verification 是 OVM 调用的事务逻辑。在 Layer 1,仅仅在验证的时分才需求经过 OVM 履行判别某个买卖履行是否正确。verification 逻辑中包含了 BondManager (典当办理),StateTransitioner (状况转化办理)和 FraudVerifier (过错状况验证逻辑)。FraudVerifier 逻辑是最中心的逻辑。整个验证进程的逻辑调用联系如下:

硬核 | 深化了解 Optimistic Rollup 履行环境 OVM

经过调用 initializeFraudVerification 函数,开端让 Layer 1 开端验证某个买卖履行后的状况是否正确。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/ 当时买卖的履行。整个逻辑涉及到屡次 Layer 1 的买卖,除此之外,还需求满足的时刻确保链上数据可以同步并查看。现在,国际状况的应战进程必须在相应买卖后的 7 天内完结:

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

总结

Optimistic Rollup 是 Layer 2 潜在的一种计划。和 ZK Rollup 相同,一切 Transaction 的信息都会作为 CallData「存储」在 Layer 1。在 Layer 2, Optimistic Rollup 经过 OVM 履行智能合约,并运用「查看」的方法确认 Layer 2 国际状况在 Layer 1 的正确性。Optimistic Rollup 的难点也在 OVM,需求在 EVM 的基础上模仿 OVM 的履行,并判别状况的正确性。现在,Optimistic Rollup 的应战期为 7 天。也就是说,只要 7 天前的状况是「确认」的,不会回滚。

免责声明:作为区块链信息渠道,本站所发布文章仅代表作者个人观点,与链闻 ChainNews 态度无关。文章内的信息、定见等均仅供参考,并非作为或被视为实践出资主张。

[标签:作者]