ETH

在确定了生意业务以及状态都正当后，建设 StateTransitioner 筹备执行生意业务。

Optimistic Rollup 是 Layer 2 潜在的一种方案。周末有点时间，在网络上翻了翻。网络上的文章，，Optimistic Rollup ovmBondManager.finalize( _preStateRoot, _postStateRootBatchHeader.batchIndex, publisher, timestamp );

ERC721

verification 是 OVM 挪用的业务逻辑。在 Layer 1，只是在验证的时候才需要通过 OVM 执行判定某个生意业务执行是否正确。verification 逻辑中包罗了 BondManager （抵押打点），StateTransitioner （状态转换打点）和 FraudVerifier （错误状态验证逻辑）。FraudVerifier 逻辑是最焦点的逻辑。整个验证进程的逻辑挪用干系如下：

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 )

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

function isBytecodeSafe( bytes memory_bytecode ) override external pure returns (bool) {

来历链接：mp.weixin.qq.com

网络上比拟这两种 Rollup 的方案文章不多。

run 函数提供了执行的生意业务，以及执行生意业务前的状态。

通过挪用 initializeFraudVerification 函数，开始让 Layer 1 开始验证某个生意业务执行后的状态是否正确。StateTransitioner 筹备生意业务之前的世界状态以及生意业务执行的中间状态存储。活着界状态筹备停当后（proveContractState/proveStorageSlot），通过挪用 ExecutionManager 的 run 函数执行生意业务并更新状态。更新后的状态通过 StateTransitioner 的 completeTransition 函数生成世界状态。生成的世界状态和提交的世界状态举办比拟，假如纷歧致，之前提交世界状态的节点通过 BondManager 举办处罚。

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

commit ca1fede6c8cb9e4eacd8205c1d53284d0c8debdc Author: Mark Tyneway Date: Fri Oct 30 12:14:50 2020 -0700 deploy: use layer 2 chainid (#42)

Layer 2 的世界状态，通过一个个生意业务的状态改变来暗示。每个生意业务后的状态也是通过一个个 Batch 提交到 Layer 1。每个 Batch 中的状态，也再次组织成 Merkle 树。这些树根用来判定某个状态是否在链中。

function run( Lib_OVMCodec.Transaction memory_transaction, address_ovmStateManager )

StateManager 实现了智能合约以及账户的存储状态打点。ExecuteManager 在执行一个生意业务时会通过 StateManager 更新状态。

焦点代码在 contracts-v2/contracts/optimistic-ethereum/OVM 目次中。除了 OVM 目次，iOVM 目次是接口界说，libraries 目次是各类库的实现，包罗编解码，二叉树等等。

而且对提交世界状态的节点举办处罚：

ERC20

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

execute 是 OVM 在 EVM 执行的焦点逻辑，包罗 ExecuteManager，StateManager 以及 SafetyChecker。对应的源代码别离是：OVM_ExecutionManager.sol，OVM_SafetyChecker.sol 和 OVM_StateManager.sol。

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 )

两种方案都是 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）。

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

Ethereum

执行生意业务的逻辑，直接忽略，感乐趣的小同伴可以看 OVM_StateTransitioner.sol 的 applyTransaction 函数。生意业务执行完，通过 finalizeFraudVerification 函数查抄执行后的世界状态的功效。

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

对应的翻译文章：

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

假如纷歧致，需要回滚世界状态：

原文标题：《L2 - require( ovmCanonicalTransactionChain.verifyTransaction( _transaction, _txChainElement, _transactionBatchHeader, _transactionProof ), "Invalid transaction inclusion proof." );