Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon

[0xEscanor]

Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon

Proposal Type: Protocol upgrade

This proposal is intended to be voted on in Cycle 35

Executive Summary

Hi, I’m Lewej, a Technical Program Manager at OP Labs. I prepared this proposal in collaboration with Meredith Baxter, Sebastian Stammler, Paul Dowman, and Ben Clabby from the OP Labs Team, Aurélien from Succinct, and Julian Meyer from Base.

Neither OP Labs nor I or any other entity mentioned represent or speak on behalf of the Optimism Foundation.

This proposal:

• upgrades Cannon, the fault proof VM to a new version that supports the MIPS-64 instruction set and supports running multi-threaded programs, removing memory constraints for the fault proof program (MT-Cannon), and
• introduces the first phase of a mechanism addressing challenges in accurately pricing user fees when chains employ ZK proving, alt-DA, and custom gas tokens (Operator Fee).

Impacted Stakeholders & Expected Outcomes

• Chain operators running fault proofs: new fault proof virtual machine and fault proof program, capable of proving much larger blocks and higher-throughput chains.
• All chain operators: L1 contract upgrades that support the upcoming L1 Pectra upgrade and the upcoming Isthmus hardfork’s operator fee feature.

Motivation

This release focuses on improving the performance and developer experience of OP Stack chains. MT-Cannon allows chain operators to prove much larger blocks more frequently. Operator Fee lays the groundwork for future improvements to fee pricing for ZK, alt-DA, and custom gas token chains. Finally, L2 Withdrawals Root makes it easier to scale the fault proof system in preparation for Superchain-wide interoperability.

This release also prepares for Ethereum’s Pectra upgrade. Pectra will be supported by the Isthmus hardfork, which can’t be deployed until the timing of the Pectra upgrade is set. We can, however, ship the L1 contract upgrades sooner and this upgrade does that.

Specifications

• Blockspace Charter
  • Current Blockspace Charter proposed to be upgraded under this proposal
    • OPerating-manual/Standard Rollup Charter.md at 6dac700f3891b198f0f5881715539a05d634b3a9 · ethereum-optimism/OPerating-manual · GitHub
  • Pull request specifying the upgraded Blockspace Charter
    • Update Standard Rollup Chart for Upgrade 14 by lewejahlil · Pull Request #47 · ethereum-optimism/OPerating-manual · GitHub

Technical Details

• Operator Fee

  We propose the addition of 2 new rollup operator configured scalars, collectively named the Operator Fee Parameters. These scalars are named operatorFeeScalar and operatorFeeConstant, and they factor in the fee calculation as follows:

  operatorFee = operatorFeeConstant + operatorFeeScalar * gasUsed / 1e6
  
  totalFee = operatorFee + gasUsed * (baseFee + priorityFee) + l1Fee
  
  

  These scalars will be updated via the SystemConfig L1 contract. A new fee vault, the OperatorFeeVault, is added to store the operator fee. A future hardfork will add support for reading these values and using them for fee calculations.

  Resources

  • Spec PR
  • FMA PR

• MT-Cannon

  The specification for the potential changes can be found in the Multithreaded Cannon Fault Proof Virtual Machine section of the OP Stack Specification. This spec is currently categorized as “experimental” pending governance approval. If this upgrade is approved, the new spec will be merged into the OP Stack Protocol Fault Proofs section.

  Affected Components

  This potential upgrade affects both the on-chain and off-chain components of Cannon which are generally run by chain operators (and any community members who may be running the infrastructure to permissionlessly challenge fault proofs).

  • Cannon
    • Smart Contract (MIPS.sol):
      • The on-chain version of Cannon, MIPS.sol, will be replaced with a new version: MIPS64.sol. The game types (defined in Types.sol) will remain the same (CANNON / 0 or PERMISSIONED_CANNON / 1).
    • Cannon Go VM (src)
      • The Cannon CLI has been updated to work with programs that target different versions of Cannon.
  • OP-Challenger
    • OP-Challenger, the honest actor in the fault proof system, uses the updated Cannon CLI tool to run the appropriate version of Cannon.
  • OP-Program
    • OP-Program will be compiled for the MIPS64 architecture.

  VM Architecture Changes

  Major changes to the VM architecture include:

  • The emulated CPU architecture is now MIPS64 instead of MIPS32:
    • Registers now hold 64-bit values.
    • Memory address space is dramatically expanded.
    • New 64-bit specific instructions have been added for operations on 64-bit values
  • Cannon now supports reading 8 bytes of data at a time from the pre-image oracle instead of 4.
  • Now supports multi-threading
    • Concurrency is via multitasking rather than true parallel processing with pre-emption and scheduling.
    • The VM now tracks a set of ThreadState objects that represent the state of the CPU for each thread.
    • Thread-safe memory access is enabled by Load Linked Word (ll) and Store Conditional Word (sc) instructions that provide the low-level primitives used to implement atomic read-modify-write (RMW) operations.
    • Extended syscall support for multi-threading.
  • Unrecognized syscalls now raise exceptions, making behavior more predictable, rather than being treated as noops.

  Security Considerations

  Audit Results

  Audits are documented here: optimism/docs/security-reviews/README.md at develop · ethereum-optimism/optimism · GitHub

  • Spearbit Audit: optimism/docs/security-reviews/2025_01-MT-Cannon-Spearbit.pdf at develop · ethereum-optimism/optimism · GitHub
  • Coinbase Protocol Security Audit: optimism/docs/security-reviews/2025_01-MT-Cannon-Base.pdf at develop · ethereum-optimism/optimism · GitHub

  Risks

  The potential failure modes are generally similar to the previous version, including but not limited to:

  • Incorrect Linux/MIPS emulation: bugs in the thread scheduler, incorrect emulation of MIPS64 instructions, and so on.
  • Unimplemented syscalls or opcodes needed by op-program: as with the previous version, we only aim to implement syscalls and opcodes that are required by op-program so there are some unimplemented. The risk is that there is some previously untested code path that uses an opcode or syscall that we haven’t implemented and this code path ends up being exercised by an input condition some time in the future.
  • Mismatch between on-chain and off-chain execution: as with the previous version, there are two implementations that must produce identical results.
  • Livelocks in the fault proof: multithreading introduces new failure modes such as livelocks. Based on our review of op-program and the go runtime internals we don’t expect to see this but monitoring should be used to detect an execution of op-program that takes too long, indicating that a livelock is preventing execution.

• Absolute Prestate

  Beginning with this upgrade op-program absolute prestates will now use the “cannon64” variant, and this upgrade includes the absolute prestate for op-program 1.5.1-rc.1, which is 0x03ee2917da962ec266b091f4b62121dc9682bb0db534633707325339f99ee405. This harmonizes the absolute prestate version with the version that’s already on Sepolia, which includes a fix for a blob fee calculation bug that affected Sepolia only, and the full diff between 1.5.0 and 1.5.1-rc.1 can be inspected here.

Impact Summaries

• Operator Fee

  This proposal is planned to be included in Isthmus, but the feature is disabled by default. In order to be able to set the operatorFeeScalar and operatorFeeConstant parameters, the SystemConfig contract must be upgraded.

• MT-Cannon

  • After the proposed upgrade, the on-chain implementation of the fault proof VM will be MIPS64.sol instead of MIPS.sol
  • The off-chain fault proof infrastructure will use the new 64-bit multi-threaded version of Cannon.
  • New dispute game contract implementations will need to be deployed that point to the new MIPS64 VM and a new absolute prestate (compiled for MIPS64).
  • Chains can increase the gas limit to allow much larger blocks without the risk of the fault proof program (op-program) hitting limits of addressable memory in the VM when proving. (There may still be scalability limitations with other systems of course).
  • The VM itself is still subject to the memory constraints of the server that it’s running on, it’s memory usage should be monitored and it should be given sufficient memory.

• Precommitment impact review:

  This Upgrade Proposal does not impact any of the precommitments in the Standard Rollup Charter.

  • Collective Fee Take: no modification or onchain implementation introduced. While an Operator Fee codepath is introduced in this release, it is disabled and will not impact fees as a part of this upgrade.
  • Governor/Servicer Role Separation: no change to role structures or authorization patterns.
  • Ossified GasLimits: no changes to ossified gasLimits
  • Direct Fee Margin Controls: no change to the relevant configuration structure and authorization.

Action Plan

If this proposal is accepted, the upgrade is expected to take place on April 25, 2025. In that case, mulitisig ceremonies will be coordinate such that the following transactions will be executed.

The upgrade will be executed using OP Contracts Manager (OPCM) version 3.0.0:

• The OPCM source code for this release is available at release op-contracts/v3.0.0-rc.2

• This deployment address for this OPCM is available in the superchain-registry: 0x3a1f523a4bc09cd344a2745a108bb0398288094f

• Upgrade transaction commitments

  All of the following data will executed by the relevant multisigs as a DELEGATECALL to Multicall3DelegateCall. If target and calldata in the runbooks prepared for executing the upgrade do not match, they should not be executed.

  1. To upgrade OP Mainnet, Soneium and Ink

     0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000003a1f523a4bc09cd344a2745a108bb0398288094f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000164ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000003000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb290000000000000000000000000543ba4aadbab8f9025686bd03993043599c6fb0403ee2917da962ec266b091f4b62121dc9682bb0db534633707325339f99ee4050000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000089889b569c3a505f3640ee1bd0ac1d557f436d2a03ee2917da962ec266b091f4b62121dc9682bb0db534633707325339f99ee40500000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e8364000000000000000000000000d56045e68956fce2576e680c95a4750cf8241f7903ee2917da962ec266b091f4b62121dc9682bb0db534633707325339f99ee40500000000000000000000000000000000000000000000000000000000
     

  2. To upgrade Base

     0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000003a1f523a4bc09cd344a2745a108bb0398288094f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a10000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000073a79fab69143498ed3712e519a88a918e1f40720000000000000000000000000475cbcaebd9ce8afa5025828d5b98dfb67e059e03ee2917da962ec266b091f4b62121dc9682bb0db534633707325339f99ee40500000000000000000000000000000000000000000000000000000000
     

  3. To upgrade Unichain

     0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000003a1f523a4bc09cd344a2745a108bb0398288094f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda60000000000000000000000003b73fa8d82f511a3cae17b5a26e4e1a2d5e2f2a403ee2917da962ec266b091f4b62121dc9682bb0db534633707325339f99ee40500000000000000000000000000000000000000000000000000000000
     

Node operators should ensure they are running up-to-date versions of op-node and op-geth:

• op-node: op-node/v1.12.2
• op-geth: op-geth/v1.101503.1

For chain operators running fault-proof infrastructure, ensure you are running up-to-date versions of the following:

• op-challenger: op-challenger/v1.3.3 (preferred) or at least op-challenger/v1.3.1
• op-dispute-mon: op-dispute-mon/v1.4.0

If a critical security issue is discovered before upgrading, OP Labs will collaborate with the community to extensively communicate that the upgrade will no longer occur.

Emergency Cancellation

The optimistic mainnet releases will be activated on the above mentioned date. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation.

Conclusion

This proposal outlines the implementation of MT-Cannon which removes memory constraints for the fault proof program, and introduces the Operator Fee which is the first phase of addressing the challenges in accurately pricing user fees when chains employ ZK proving, alt-DA, and custom gas tokens. We hope to gain your support for the implementation of these changes.

[GoBOB]

I am an Optimism delegate [BOB - Delegate Communication Thread] with sufficient voting power and I believe this proposal is ready to move to a vote.

[olimpio]

I am an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

[SEEDGov]

The SEEDGov delegation, as we have communicated here, being an Optimism delegation with sufficient voting power, we believe this proposal is ready to move towards a vote.

[nanobro]

It’s good that this proposal come with audit results.

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

[katie]

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

[PGov]

I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

[Jrocki]

I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

[Superseed]

At Superseed we’re an Optimism Delegate with sufficient voting power and we believe this proposal is ready to be voted on.

[Jepsen]

I would like to comment on behalf of the Developer Advisory board with the goal of making the WHY of this proposal clear to governance.

Summary of upgrade 14 MT-Cannon + Opperator Fee:

The main goal of the MT cannon upgrade is to improve the OP proving systems in two ways primarily focused on eliminating memory constraints. The first change is support for 64bit mips instruction set architectures(ISA), which increases the fault VMs memory address space from 32 bits to 64 bits removing constraints on memory sizes. This means proving complicated state transitions are now feasible. The second change here is the support for multi-threading (MT-cannon) in the fault VM which will increase the computation capabilities of the fault proof system enabling it to proof more rich state transitions for example OP chains that wish to support larger gas limits.

The Operator Fee improvement was designed by succinct to enable customizability of execution prices which can enable OP stack to use their proving stack. With the Operator Fee change, OP stack operators can price execution according to their needs for example the utilization of a different proving stack. This protocol fee can technically by used to charge for anything; enabling a chain to do things like rebates, pay for block explorers, etc. This change opens up the design space of chains in a big way and enables OP chains to support other proof systems. This will not impact any chains running the standard OP chain config. Importantly this change doesn’t make these changes on mainnet it just sets up the contracts for the Isthmus hardfork in the next upgrade.

[SEEDGov]

We’re voting FOR this proposal.

The proposal introduces improvements to the Fault Proof system, which seem very much needed for chains to grow in capacity properly. The addition of the OperatorFee fields in the SystemConfig is a minimal yet effective change that allows general-purpose cost charging for users. We think this is a good step toward providing flexibility for future cost structures in rollups.
As usual, we encourage the proposers to halt the upgrade immediately if any issues are found and ensure that such issues are communicated promptly.

Thanks to @Jepsen for commenting on the proposal.

[Tane]

Hi @0xEscanor, we are just aware of the deprecation of Custom Gas Tokens announced last month and the related codes already being removed from the Optimism repository. While the Operator Fee mechanism isn’t only for the chains with custom gas tokens, we think this should have been mentioned since the document specified You can continue to operate your chain as is and not pull in the latest upgrades to the OP Stack.

[samlaf]

which increases the fault VMs memory address space from 32 bits to 64 bits removing constraints on memory sizes

How close was the current op-program to hitting the 4GiB RAM limit? aka how many blocks/txs/frames could it manage?

more rich state transitions for example OP chains that wish to support larger gas limits

Why do larger gas limits require multi-threading support? Is the idea to prove block ranges in goroutines? Couldn’t this just be done by increasing frequency of root posting?