As the number of on-chain transactions increases, Layer2 has become an important research area to solve the scaling problem, and there are already grounded solutions in the direction of optimistic rollup, such as Arbitrum (later called arb) and Optimism Cannon (later called op).
Both arb and op use interactive on-chain arbitration techniques. Interactive means that the challenger at Layer1 continuously challenges the intermediate state generated by the block producer in executing the block until both parties disagree on the outcome of the execution of an intermediate instruction, or until there is no disagreement in the end. This arbitration requires that the Layer2 virtual machine be able to preserve proof of the intermediate state generated during the execution of the block, or be able to interrupt the execution of an instruction and preserve proof of the current state.
Since different optimistic rollup solutions may use different VMs, e.g., Arbitrum developed its own AVM, in order to generate proofs of intermediate state, different VMs may need to customize their own proof-of-state techniques, which are less general. Although the technical principle of optimistic rollup is basically the same, nowadays, public chains are blossoming, applications are blossoming, and smart contract languages are evolving rapidly, so implementing an optimistic rollup based on a certain smart contract language for a public chain still requires a lot of repetitive work in engineering.
Based on this, we try to implement a generic and verifiable contract execution environment. This environment is based on Linux and can simulate code execution for different CPU instruction architectures and generate intermediate state (registers + memory data) and state proofs. The overall idea is inspired by Cannon, and borrows part of the implementation of the Qiling framework.
Unlike Qiling, the execution environment of contracts in blockchain is relatively simple, with no complex I/O external interactions, and no need to consider system isolation. In addition, qiling lacks intermediate state generation and proof of state, which is one of the features required for interactive arbitration.
We refer to this contract execution environment as flexEmu.
You can learn flexEmu from Documents.