Optimistic Rollups: Chain, Execute & State, Verification
For the specific storage information of the two chains, you can view the source code: OVM_CanonicalTransactionChain.sol and OVM_StateCommitmentChain.sol.
Execute is the core logic executed by OVM in EVM, including ExecuteManager , StateManager and SafetyChecker . The corresponding source codes are: OVM_ExecutionManager.sol, OVM_SafetyChecker.sol and OVM_StateManager.sol.
-
ExecuteManager is the processing of the entire smart contract execution environment and instruction set. OVM actually uses the same instruction set logically as EVM, but in the OVM environment, especially when the EVM of Layer 1 executes OVM, these instruction sets need to be “escaped”. The reason why it is called OVM may be to a large extent to distinguish EVM and make it easy to express. A lot of instructions need to be escaped. Think of the implementation of OVM in Layer 1 as a virtual machine. These instructions include: TIMESTAMP, CALL, STATICCALL, DELEGATECALL, GASLIMIT, SLOAD, SSTORE, etc.
-
StateManager implements smart contract and account storage state management. ExecuteManager updates the state through StateManager when executing a transaction.
-
SafetyChecker checks whether the instruction set in the OVM instruction contract is normal and whether it exceeds the current executable range. The safety check is implemented by the isBytecodeSafe function of OVM_SafetyChecker.sol.
Verification is the business logic called by OVM. In Layer 1, OVM execution is only needed to determine whether a transaction is executed correctly during verification. The verification logic includes BondManager (mortgage management), StateTransitioner (state transition management) and FraudVerifier (error state verification logic). FraudVerifier logic is the core logic.
The logic call relationship of the entire verification process is as follows:
By calling the initializeFraudVerification function, Layer 1 starts to verify whether the status of a certain transaction is correct. StateTransitioner prepares the world state before the transaction and the intermediate state storage of the transaction execution. After the world state is ready (proveContractState/proveStorageSlot), execute the transaction and update the state by calling the run function of ExecutionManager. The updated state generates the world state through the completeTransition function of StateTransitioner. The generated world state is compared with the submitted world state. If it is inconsistent, the node that previously submitted the world state will be punished by BondManager.