Upgrade Proposal #4

Technical Proposals 📃 Protocol Upgrade
,
1

Hi I’m Maurelian, an 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 is the fourth proposed network upgrade after Bedrock. It introduces a new L1 contract, the SuperchainConfig, along with improvements to the existing pause mechanism.

Executive Summary

This protocol upgrade would not only strengthens individual chains, but leverages the collective security intelligence of the entire Superchain ecosystem. The proposed upgrade takes the current incident response mechanism a step further, introducing a Superchain-wide pause mechanism that can enhance protection across multiple fronts, including the L1CrossDomainMessenger and withdrawals for ERC-20 and ERC-721 tokens, which are additional security critical code paths that protect user assets.

If this vote passes, the L1 contracts which support the OP Mainnet network will be upgraded to the versions of those contracts in the optimism repo at commit 856c08b (tagged as release candidate op-contracts/v1.2.0-rc.1).

Technical Specification

This is a security focused upgrade. It is limited to the L1 smart contracts, and does not affect the node or execution client software.

The following changes are being introduced with the upgrade:

  1. A new SuperchainConfig contract and improvements to the pausability mechanism providing stronger protection for assets held in the bridge.

  2. The OptimismPortal and L1CrossDomainMessenger are updated to fix an issue (which would only occur during an upgrade), resulting in some values being unnecessarily reset to their defaults after an upgrade.

  3. The L1 OptimismMintableERC20TokenFactory is being updated with two improvements:

    • Support for deploying a token with a custom number of decimals (PR here and here).
    • Using CREATE2 to ensure that tokens with different properties do not have the same addresses on different OP Chains. (PRs here and here).

Security Considerations

This upgrade has been audited by Trust Security, the final report can be found here.

Summary of the audit findings

The audit did not identify any security issues in the system’s newly added functionality.

The audit did however identify an issue in the system’s existing upgrade path. The affected contracts were fixed and upgraded on the Sepolia testnet.

Importantly, the issue could only be exploited if the upgrade was performed in a specific way. In such a case, an attacker could have intercepted the upgrade transaction, to perform a one-time double withdrawal of ETH held in the L1CrossDomainMessenger. Note that this contract currently holds zero ETH at the time of writing. Under normal circumstances, the vast majority of ETH is stored in the OptimismPortal.

Please see TRST-H-1 in the audit report for a detailed discussion of the issue.

This issue is only exploitable during an upgrade, and the upgrade scripts have been fixed, so no future upgrades will be at risk of this issue.

No other findings from the audit presented a risk of a loss of assets.

Impact Summary

OP Labs does not anticipate any down time due to this upgrade, and node operators are not affected.

Existing contracts retain their current interfaces in order to remain backwards compatible with any existing integrations.

The primary new functionality will be an extension of the pause mechanism, which prevents the withdrawal of assets from the system in the event that a vulnerability is identified. This will improve the incident response capacity of OP Labs.

Currently only the OptimismPortal’s proveWithdrawalTransaction()
and finalizeWithdrawalTransaction() functions are pausable.

Following this upgrade, this will expand to include the following additional functions:

  • L1CrossDomainMessenger.relayMessage()
  • L1StandardBridge.finalizeBridgeERC20()
  • L1StandardBridge.finalizeERC20Withdrawal
  • L1tandardBridge.finalizeBridgeETH()
  • L1StandardBridge.finalizeETHWithdrawal
  • L1ERC721Bridge.finalizeBridgeERC721()

Prior to the upgrade, a new proxy (at the address here) and implementation (at 0x53c165169401764778f780a69701385eb0ff19b7) for the SuperchainConfig (version 1.1.0) has been deployed and initialized.

The upgrade will also result in the following changes to the internal state of the existing L1 contracts, with the implementations corresponding to the addresses listed here.

Summary of these changes:
  1. The L1CrossDomainMessenger will be upgraded to version 2.2.0, and a new storage variable superchainConfig will hold the address of the SuperchainConfig proxy contract.
  2. The L1ERC721Bridge contract will be upgraded to version 2.0.0, and a new storage variable superchainConfig will hold the address of the SuperchainConfig proxy contract.
  3. The L1StandardBridge contract will be upgraded to version 2.0.0, and a new storage variable superchainConfig will hold the address of the SuperchainConfig proxy contract.
  4. The OptimismPortal contract will be upgraded to version 2.1.0, and a new storage variable superchainConfig will hold the address of the SuperchainConfig proxy contract.5. The SystemConfig contract will be upgraded to version 1.11.0.6. The L2OutputOracle contract will be upgraded to version 1.7.0.
  5. The OptimismMintableERC20Factory contract will be upgraded to version 1.8.0.

All L1 contracts have also had modifications to the source code formatting (white space and comment-style) which do not otherwise affect their behavior.

Action Plan

If this proposal passes a Token House vote, the L1 contracts will be upgraded following the completion of the Citizens’ House Cycle #18 Veto Period. The upgrade will be completed atomically such that all affected L1 contracts will be upgraded within a single transaction.

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

24 Likes
2

Hey @maurelian!

Quick note. The superchain config spec link seems broken. Right link maybe(?) in a different repo: specs/specs/superchain-configuration.md at 8eb74667841c9cf86747cd133175272c76dd86f0 · ethereum-optimism/specs · GitHub

So with this upgrade someone can pause L1 withdrawals from Optimism? Who is this someone? Who would have the power to do so?

7 Likes
3

OP Mainnet, as well as Base and other OP stack chains, already have a Guardian role that can pause the L1 side of the bridge. My understanding is that the SuperchainConfig contract will be shared among chains to better coordinate this functionality.

This Guardian is going to be the Foundation, right?

2 Likes
4

This is correct as it applies to OP Mainnet. It is important to note that for now, this upgrade only applies to OP Mainnet. Other chains can follow this upgrade or not, given the current scope of the vote. In the future, it may become a mandatory requirement to use the shared guardian role for the Optimism Collective to provide sufficient, uniform security guarantees alongside further tech milestones (like interoperability).

Today, if other OP Chains elect to follow this upgrade, they can continue to designate “ownership” of the Extended Pause functionality to the entity or entities currently responsible for the Guardian role on their chain, though it’s our strong recommendation that the most robust incident response plan would be to transfer guardian role to the Foundation. The Optimism Foundation may not be able to react quickly/through its primary incident response protocol in the event of critical vulnerabilities present on chains which do not use Foundation as their guardian. [Note: this scope only applies to standard OP Chains. not forks. Optimism Foundation is not proposing a security SLA for forks or unofficial chains at this time, please do not transfer the guardian role before direct communication with the Optimism Foundation.]

7 Likes
5

If there is a vulnerability on a core app of one of the chains and a withdrawal is initiated, what should be the emergency response not to pause all the other chains too?

6

The Optimism Foundation would not activate this pause mechanism in the event of a bug in an application running on an OP Chain, as that would undermine his would undermine the User Protection of State Transition and Messaging Validity.

The pause functionality is only intended to be used to protect against withdrawals which should be invalid, but are possible due to unforeseen bugs in the OP Stack bridge or elsewhere in the protocol.

Given that all OP Chains will share the same logic across contracts in the L1 system, it is expected that a bug present in one OP Chain will be present in all. Therefore it is essential to pause all chains at once. If a bug is present, any delay between pausing the first chain and pausing others will:

  • reveal to the world that a bug is likely to be present
  • provide time for a hacker to find and exploit the bug in any OP Chain which is not yet paused.

It is also worth highlighting that this is not new functionality, but rather an enhancement of existing functionality. Per the proposal:

It gives us greater confidence that if a pause is necessary to protect against a bug, it will indeed provide the protection required, thus providing the time to put in place the proper fix.

2 Likes
7

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

8
9

Yes, that was the correct link, I’ve updated the original, thanks!

10

As a top 100 delegate I believe this proposal is ready to proceed to a vote. Agora - OP Voter

1 Like
11

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

1 Like
12

Hey @Pr0 & @Michael ! Could you please update your approvals to follow the format outlined in the Operating Manual, which includes a link to your delegate commitments?

Thanks! :sparkles:

13

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

3 Likes
14

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

1 Like
15

I am an optimism delegate with sufficient voting power and believe this proposal is ready to proceed to a vote

2 Likes
16

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

1 Like
17

Hi @maurelian, thanks for putting together the details of the upgrade proposal to strengthen the security within Superchain.

The link to the SuperchainConfig is broken. Could you navigate us to the correct page?

18

GM @Tane! This is the right link :slight_smile:

1 Like
19

I’ve also fixed the original link now, thank you.

2 Likes
20

Kind of a no brainer, but since I explain my voting methodology in each post i am writing to state I voted for this proposal onchain.

1 Like