Fault Proof Deep-Dive Part 1: MIPS.sol

The Fault Proof Deep-Dive Series is a collaboration between Coinbase’s Blockchain Security (BlockSec) team and OP Labs to provide in-depth information on all major components of Fault Proofs. By sharing this information, we hope to encourage others to learn more about the architecture and technical aspects of Fault Proofs. Together, we can move towards the decentralized future of OP Stack L2 blockchains.

In this blog post, we’ll be covering the Fault Proof Virtual Machine (FPVM) smart contract MIPS.sol.

What is MIPS.sol?

The MIPS.sol smart contract is an onchain implementation of a virtual machine (VM) that encompasses the 32-bit, Big-Endian, MIPS III Instruction Set Architecture (ISA). This smart contract is the counterpart to the off-chain MIPSEVM golang implementation of the same ISA. Together, the onchain and off-chain VM implementations make up Cannon, OP’s first FPVM. 

Cannon is an instance of a FPVM, which is used as part of the Fault Dispute Game for optimistic rollup L2 blockchains that use the OP Stack. The dispute game itself is modular, allowing for any FPVM to be used; however, Cannon is currently the only FPVM implemented and consequently will be used in all disputes.

Fault Proof Control Flow

Taking a step back, let’s focus briefly on where the MIPS.sol contract resides in the Fault Proof process.

In the above diagram recreated from the Fault Proof Walkthrough video by Clabby, we can see that the MIPS.sol contract interacts with two other contracts: FaultDisputeGame.sol and PreimageOracle.sol. FaultDisputeGame.sol is the deployed instance of a Fault Dispute Game for an active dispute. PreimageOracle.sol is the deployed instance of a Pre-image Oracle that will store Pre-images for all Dispute Games that use the same FPVM. So, in our case, there is a single PreimageOracle.sol contract for all games that use MIPS.sol as the FPVM.

The MIPS.sol contract is called by a running instance of a dispute game, and is only called once a dispute game reaches a leaf node in the state transition tree that is currently being disputed. A leaf node represents a single MIPS instruction (in the case that we’re using Cannon as the FPVM) that can then be run on-chain. Given the pre state, which is the previously agreed-upon L2 state up until this instruction, and the instruction state to run in the MIPS.sol contract, the fault dispute game can determine the true post state. This true post state will then be used to resolve the fault dispute game by comparing the disputed post state at the leaf node with the post state proposed by the opponent in the dispute game instance.

Smart Contract Control Flow

There is a single entry point to the MIPS.sol smart contract: the step() function. This is the function that is called by the running dispute game, which will execute a single MIPS instruction onchain. At a high-level, the following operations will be performed:

1. The VM execution state data input is parsed and loaded into memory. This data is generated by the Cannon golang counterpart that the game participants run off-chain via the OP-Challenger.
2. The memory proof input is read and verified. This memory proof points to a location in memory where the next MIPS instruction should be loaded from and run.
3. The next MIPS instruction is executed. The majority of the logic in the MIPS.sol contract handles executing a MIPS instruction according to the MIPS III specification. When handling the MIPS instructions, the only instruction that does not follow a strict specification is the SYSCALL (system call) instruction. The behavior of system calls are unique to the operating system, and in the case of MIPS.sol, the system calls that can be performed are only a fraction of the total system calls. The primary purpose of the system calls are to handle reads from the PreimageOracle.sol contract and simulate writes to the contract.
4. The results of the instruction may be written back to a register or to memory. In the case of writing to memory, a second memory proof will have been provided as input by the dispute game. The second memory proof should coincide with the location in memory that is expected to be written to, and the MIPS.sol smart contract will use the new value and the memory proof to calculate the new memory merkle root.

Upon completion of the MIPS instruction, a state hash will be returned to the dispute game instance. The state hash is the keccak256 hash of the VM execution state where the first byte does not correspond to the hash but instead is overridden with a value to indicate the status of the VM. The dispute game will use the state hash and VM status to resolve the dispute.

MIPS.sol Contract State

As mentioned previously, the MIPS.sol contract interacts with two other smart contracts: FaultDisputeGame.sol and PreimageOracle.sol. The FaultDisputeGame.sol contract provides the current VM execution state, and up to two memory proofs. The PreimageOracle.sol contract provides Pre-images that can be used by MIPS.sol to help determine the true L2 state. The content derived in a Pre-image may include data from both L1 and L2, which can be block headers, transactions, receipts, contract state, and more.

Together, these two contracts provide all the relevant information necessary to execute a single MIPS instruction. The MIPS.sol contract does not store any information about an instruction execution in storage. This way, the contract can be used by any Fault Dispute Game without having to reset any values. Consequently, the MIPS.sol contract only ensures that the calculated merkle root from the provided memory proofs is equal to the merkle root in the VM execution state. Otherwise, it is up to the FaultDisputeGame.sol contract to ensure the correctness of the information provided and actions taken by a participant in the dispute game.

Documentation For MIPS.sol

This concludes our deep-dive of the MIPS.sol smart contract. In addition to this blog post, Coinbase has created in-depth documentation that provides details on each function in the smart contract, lists the MIPS instructions supported by the FPVM, and more. Check it out at Fault Proofs - MIPS.sol | Optimism Docs.