🛠 How Optimism’s MIPS-Based Fault Proof System Works

6 min readMay 26, 2025

TL;DR:
Optimism’s next-generation fault proof system introduces a modular, verifiable execution of the EVM using a MIPS-based virtual machine. It bridges EVM semantics with provable computation, enabling decentralized fraud proofs. This article explains the architecture, design decisions, execution workflow, and how MIPS fits into the Optimism fault proof pipeline.

🔍 Background: What Are Fault Proofs?

Optimistic rollups like Optimism post transaction batches to Ethereum L1 assuming they’re valid — but allow a window for anyone to challenge incorrect results. A fault proof (fraud proof) verifies whether the L2 block transitions from one state root to another correctly, according to a canonical specification.

A valid fault proof system must:

Provide a deterministic state transition function.
Enable off-chain or on-chain re-execution of that function.
Include a challenge game to identify incorrect execution at a specific step.

Optimism’s new system replaces centralized fraud provers with a fully modular and permissionless framework powered by a MIPS VM.

🧠 What Is the MIPS VM?

MIPS (Microprocessor without Interlocked Pipeline Stages) is a classic RISC architecture introduced in the 1980s. It has:

A small, orthogonal instruction set (ideal for circuit modeling or emulation).
No dynamic behavior like out-of-order execution, making it perfect for deterministic, step-by-step execution.
Strong ecosystem support: emulators (QEMU), toolchains (GCC), and OS ports (Linux).

Optimism chose MIPS because:

It simplifies verifiable computation.
It’s easy to emulate both off-chain and on-chain.
It maps well to zero-knowledge circuits and STARK-based provers (e.g., RISC Zero, SP1).
It enables a general-purpose execution environment.

This means Optimism doesn’t just emulate EVM directly — instead, it compiles the entire L2 state transition logic to run inside a MIPS-based Linux VM.

🏗 Architecture Overview

The Optimism fault proof system is built around three key components:

Preimage Oracle (L1)
MIPS VM (Off-chain and on-chain interpreter)
Challenge Protocol (Interactive dispute resolution)

⚙️ The MIPS VM: Running the OP Program

The MIPS VM is the execution engine that defines what it means for a block to be “valid” in Optimism. But what does it actually run?

🔁 The op-program

The op-program is the name given to the compiled binary that performs the L2 state transition. It includes:

A stripped-down Linux kernel.
The full EVM interpreter (derived from op-geth) compiled to run on MIPS.
Logic for reading input data, applying transactions, updating state, and producing the output root.

This means the state transition function looks like this:

Ethereum (L1) → runs MIPS VM →
    which runs op-program →
        which re-executes EVM transactions →
            which mutates state and outputs a new root.

So in a sense, EVM runs a MIPS VM, which runs an EVM, which runs transactions.

This abstraction may sound recursive — but it’s precisely what allows Optimism to define a canonical execution trace that can be re-executed and verified, instruction by instruction.

🧾 Execution Trace: Pinpointing Failures

As the MIPS VM runs, it produces an execution trace — a list of states for each instruction step:

Program counter (PC)
Register values
Memory and stack contents

During a challenge, the trace allows the protocol to pinpoint the exact instruction where prover and challenger disagree.

This enables a binary search-style challenge game:

Start with the initial and final MIPS state (as claimed by the prover).
Recursively bisect the trace until you isolate a single instruction step.
Run that instruction on-chain to decide the dispute.

Because each MIPS instruction is deterministic and has small state, it’s cheap to execute on-chain.

📥 The Preimage Oracle

To feed the op-program, the MIPS VM needs access to:

Input calldata (e.g., L2 transaction data)
Configuration (block number, timestamp)
Contract state reads/writes
Precompiled trie data

These inputs are broken into chunks and submitted as Merkle tree leaves. The Merkle root of this tree becomes the input hash of the MIPS program. This root is committed to in the posted output root on Ethereum L1.

An on-chain contract (the Preimage Oracle) allows reading individual leaves, enabling the challenge game to execute instructions that reference memory or state reads.

🔐 Handling Deposits and Withdrawals in the Preimage

Deposits (from L1 to L2) and withdrawals (from L2 to L1) are key components of any rollup’s trust model. Optimism’s MIPS-based fault proof system ensures that these cross-domain interactions are captured deterministically through the preimage oracle.

📥 L1 ➜ L2: Deposits

When a user deposits ETH or tokens to Optimism from Ethereum, it’s done via the OptimismPortal contract. These deposits are:

Finalized on Ethereum L1.
Serialized and included in the preimage input to the MIPS VM for the relevant L2 block.

How it’s encoded:

Deposits are committed in a DepositTx structure.
Each L2 block includes a set of deposits made since the previous L2 block (usually from the latest finalized L1 block).
These are encoded in the preimage as Merkle leaves, and accessible to the MIPS program via the preimage oracle.

This ensures that the MIPS VM, during execution of the op-program, has access to the exact set of deposits it should process. If a sequencer were to exclude a valid deposit, the discrepancy would appear in the MIPS execution trace and could be challenged.

📤 L2 ➜ L1: Withdrawals

Withdrawals from Optimism back to Ethereum are also part of the canonical state transition.

When an L2 transaction initiates a withdrawal, a withdrawal entry is created and logged in the L2ToL1MessagePasser contract.
The set of withdrawals for a block is part of the L2 output root commitment.
The MIPS program is responsible for recomputing this set deterministically as part of its execution.
At the end of execution, it outputs:
The new L2 state root
The set of messages (withdrawals) to pass to L1

Fraud prevention:

If the prover fabricates or omits a withdrawal, the resulting state root and withdrawal hash won’t match the expected output.
A challenger can replay the MIPS program using the same preimage and show that the claimed withdrawal root is invalid.

Because the preimage contains the entire execution context, including L2 block metadata and all L2 transaction payloads, both deposits and withdrawals are treated as first-class inputs and outputs to the state transition function.

🎮 The Challenge Protocol

Optimism adopts a multi-round interactive fault proof game, similar to Arbitrum:

The prover submits a block and claims it leads from state A to B.
A challenger disputes this execution.
The game plays out as follows:

Parties commit to intermediate MIPS states at different instruction steps.
A binary search is performed to isolate the instruction where they diverge.
The final disputed instruction is executed on-chain using a lightweight MIPS interpreter.

If the instruction proves the challenger correct, the block is rejected. Otherwise, the block is finalized and the challenger is penalized.

The on-chain interpreter ensures this is trustless — no need for consensus clients or oracle attestations.

🔁 End-to-End Flow

Here’s the full lifecycle of a fault-proofable L2 block:

1. L2 sequencer proposes a block → submits calldata + output root to L1
2. Prover generates MIPS input (preimage root) and output (state root)
3. If challenged, the op-program is run locally by both prover and challenger
4. Execution trace divergence triggers challenge game
5. On-chain interpreter evaluates final instruction
6. Dispute resolved trustlessly on Ethereum

🔮 Toward a ZK Future

Though the current system uses interactive fraud proofs, the design is zk-friendly:

The MIPS VM is compatible with zkVM frameworks (like RISC Zero, zk-MIPS, SP1).
The op-program can be wrapped in a SNARK/STARK proof, allowing fully succinct proofs of L2 execution.

This unlocks:

Near-instant L2 finality (once proof is submitted)
Cross-chain composability
Efficient verification of rollup blocks by any client

Optimism envisions this as the final stage of decentralization and scale — and the MIPS design is the bridge to get there.

🧩 Summary

Optimism’s MIPS fault proof system is a significant leap toward decentralized, trustless rollup security. By compiling the full L2 execution logic into a verifiable MIPS program and layering it with a robust challenge protocol, Optimism achieves:

✅ Canonical, deterministic execution
✅ Permissionless proving and challenging
✅ Modular proving backends (fraud or ZK)
✅ Clear resolution path for disputes

It’s not just EVM in a VM — it’s a framework for verifiable computation at the heart of Ethereum’s scaling roadmap.