Upgrade Proposal #6: Multi-Chain Prep (MCP) L1

Technical Proposals 📃 Protocol Upgrade
1

Executive Summary

Hi I’m Diego, a protocol engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not represent or speak on behalf of, the Optimism Foundation.

This protocol upgrade strengthens the security and upgradeability of the Superchain by enabling L1 contracts to be upgraded atomically across multiple chains in a single transaction. To achieve this, this proposal transitions chain-specific deployment configuration from immutable variables into smart contract state. This allows multiple chains to point to a single smart contract implementation, which dramatically simplifies the deployment process and streamlines the upgrade process. This is particularly important for emergency upgrades, which would have previously required multiple upgrade transactions which increases the risk of exploitation in the event of a smart contract vulnerability.

In addition, this upgrade extends the SystemConfig to contain the addresses of the contracts in the network. This improves developer experience by allowing users to discover the system’s contract addresses programmatically using SystemConfig.

If this vote passes, we recommend the upgrade be deployed to OP Mainnet shortly after the end of the veto period. The newly-formed Security Council will be responsible for deploying this upgrade to OP Mainnet.

Specifications

Contracts Changed

The following contracts would be changed as part of this upgrade. Each contract links to the pull request where the changes were made, and the bullet points correspond to the immutable variables moved into state (in format {type} {varName}):

  1. OptimismPortal
    • L2OutputOracle l2Oracle
    • SystemConfig systemConfig
  2. L1CrossDomainMessenger
    • OptimismPortal portal
    • CrossDomainMessenger otherMessenger
  3. L1StandardBridge
    • CrossDomainMessenger messenger
    • StandardBridge otherBridge
  4. L1ERC721Bridge
    • CrossDomainMessenger messenger
    • StandardBridge otherBridge
  5. OptimismMintableERC20Factory
    • address bridge
  6. L2OutputOracle
    • uint256 submissionInterval
    • uint256 l2BlockTime
    • address challenger
    • address proposer
    • uint256 finalizationPeriodSeconds
  7. SystemConfig

Security Considerations

Consistent with the OP Labs Audit Framework, OP Labs had the code audited by Cantina, since the upgrade results in many changes to storage layouts, and mistakes in that process can result in loss of assets due to e.g. a reinitialization bug.

The audit results only contained informational and low-severity issues. As such, we will not be modifying the contracts further in order to keep the contracts code-frozen. See the full audit report here. Additionally, given the low-severity nature of the issues and fixes, we decided not to pursue a fix review.

Any fixes that did not require redeploying contracts have been made and merged. The remaining changes, which do not affect security, will be proposed as part of a future upgrade.

We have also established monitoring systems for detecting events associated with initializations and upgrades of the contracts, the code of which you can find here.

Impact Summary

OP Labs does not anticipate any downtime due to this upgrade. Node operators are not affected. Existing contracts retain their current interfaces in order to remain backward compatible with any existing integrations.

The primary new functionality is the movement of variables out of immutable storage and into state. This is a change that will improve the upgradeability and incident response capacity of the Superchain.

Action Plan

If approved by governance, the upgrade will be executed shortly after the veto period passes, pending coordination with the Security Council. The upgrade is code complete as of commit e6ef3a900c42c8722e72c2e2314027f85d12ced5 (release and tag) in the Optimism monorepo.

This upgrade was successfully deployed to op-sepolia on Jan 19, 2024.

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.

Conclusion

This proposal outlines the Optimism Collective’s MCP L1 upgrade. This upgrade enables atomic, cross-chain upgrades and mitigates potential exploitation risks during emergency, multi-chain upgrades.

As this is a contracts-only upgrade, no action is required by node operators.

18 Likes
2

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

2 Likes
3

Im happy to see upgrades that decrease the response time to address a bug/vulnerability.

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

1 Like
4

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

5

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

6

I’ll be abstaining from this proposal after getting technical input from my Scalar cofounder Jordan. It is a complex change and we did not have strong opinions on it.

7

Firstly thanks for the proposal. It’s a quiet technical proposal so I have a question: Does that enable OP Stack Chains transactions accepted by the same contract on Ethereum Mainnet?

8

GM @diego! Is there a specific reason why this upgrade needs to be released now? I don’t have a technical background so I would like to know why is better to launch this upgrade immediately and then issue another to address the low-security issues later? It is about efficiency? Or do the benefits of this upgrade far outweigh the risks? Thanks! I’ve heard amazing things about your work :sparkles:

2 Likes
9

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

10

In future, consider limiting to one upgrade proposal per voting cycle. This is how Ethereum upgrades have always worked, sequentially, one upgrade at a time, for many good reasons.

5 Likes
11

We voted FOR this proposal.

The proposed upgrade, after reviewing it, we agree that its implementation accomplishes its goal of simplifying upgrade flows. It’s important to emphasize that the proposal has already explained how it impacts sensitive aspects of chain security, based on the framework previously mentioned. We strongly believe that any new issues identified before the implementation phase, not just the critical ones, should be communicated transparently to the community. We advocate for a maximalist and cautious approach before moving forward.

1 Like
12

We extend our gratitude to @diego for crafting the presented proposal. Our team, the ITU Blockchain Delegation, has carefully reviewed the insights on Multi-Chain Prep (MCP) L1. We commend the protocol upgrade’s ability to facilitate the atomic upgrading of L1 contracts across multiple chains in a single transaction. This advancement not only streamlines the deployment process but also mitigates security risks effectively. It is appreciated that developers are also considered.

Given the aforementioned reasons, the ITU Blockchain Delegation team supports and votes ‘FOR’ this proposal.