Optimism

Optimism L2

Summary

We offer support for two types of rollup based on the Optimism (opens in a new tab) stack, namely rollups that do implement the OP Stack fault proof system (opens in a new tab) (e.g. Optimism Mainnet) and those that do not (e.g. Base (opens in a new tab)). For details on the latter please see our documentation for Base.

High level overview

Optimism is EVM compatible and implements its account and storage tries using your standard Patricia Merkle Trie (opens in a new tab). We verify the returned proofs using Optimism's SecureMerkleTrie.sol library.

The OptimismPortalProxy implements a getter for the DisputeGameFactory through which new FaultDisputeGame instances are created. The creation of a FaultDisputeGame is the mechanism through which a proposal for the current state root of the chain is made.

Anyone* can make a state root proposal and the back and forth process through which games are disputed is what prevents an invalid (for example (opens in a new tab)) L2 state being finalized on L1`.

Context

The context of the request is the game index associated with the latest appropriately resolved FaultDisputeGame.

The appropiate index is discerned by querying the latest rootClaim from the AnchorRegistry and efficiently finding the game that submitted the claim.

Commit

The body of an OP stack chain commit includes L2 block data (blockHash, stateRoot) as well as the hash of the storage trie (storageRoot) for the L2ToL1MessagePasser contract.

Verification

The Unruggable gateway Typescript prover implementation used for OP Stack based chains is EthProver.ts.

OP Stack chains use the standard Patricia Merkle Trie. Proof data is verified using the OPVerifier.sol and OPFaultVerifier.sol contracts deployed on Layer 1.

The OutputRootProof is defined by Optimism (opens in a new tab) as:

    struct OutputRootProof {
        bytes32 version;
        bytes32 stateRoot;
        bytes32 messagePasserStorageRoot;
        bytes32 latestBlockhash;
    }

The gateway returns this data alongside individual account/storage proofs for the requested data. We discern that the OutputRootProof for the game index that the gateway claims it is returning matches data stored on L1 and then we verify the proofs returned against the associated state root.

Notes

Safeguard consideration

It is not the L1 chain that dictates the state of an OP Stack based chain. Rather, it provides the inputs (transactions/ordering) from which the state of the L2 chain can be derived (in for example the op-node/op-geth clients).

We read state data from the AnchorStateRegistry which critically assumes that all dispute games resolve correctly. It does not take into consideration any of the safeguards (opens in a new tab) currently (21/08/24) in place to protect the integrity of the chain, noting that the fault proof system is new, novel, and complex.