[Tracker] OPCM Upgrades (Upgrade 12)

[maurelian]

Description

This is a tracking issue for the work outlined in the L1 Upgrades Design Doc.

Milestone: Devnet

Items which must be completed prior to the devnet deployment.

• Ensure tests run against both the fresh and upgraded system (Upgrade 12) #13079
• Support for optional block number to just test-upgrade (Upgrade 12) #13339
• Add all necessary contracts to the SystemConfig’s Addresses struct (Upgrade 12) #13073
• Add temporary reverts to code paths using a custom gas token (Upgrade 12) #13589
• New release() getter to represent the release (Upgrade 12) #13076
• Add an upgrade() function to all L1 contracts (Upgrade 12) #13072
• Vendor in OZ V5 Initializable implementation (Upgrade 12) #13071
• Fully remove CGT code from L1 contracts (Upgrade 12) #13671
• Add SuperchainConfig and ProtocolVersions to the OPCM's Implementations struct (Upgrade 12) #13682

Milestone: Testnet

Items which must be completed prior to the testnet deployment.

• New opcm.upgrade() method (Upgrade 12) #13078
• Add upgrade path testing for all supported chains in CI. (Upgrade 12) #13607
• Deploy all implementations using Create2 (Upgrade 12) #13644
• CI job that runs the upgrade tests for all base chain <> OP Chain pairings (Upgrade 12) #13401
• Expand set of tests run in forked upgrade path (Upgrade 12) #13411
• Update FMA status to 'implementing actions' (Upgrade 12) #13593
• -rc is removed when upgrade() is called by the Upgrade Controller. (Upgrade 12) #13077
• OPCM: New addGameType() method. (Upgrade 12) #13070
• Testing to detect when a release has occurred and any non-empty upgrade() methods should be reset. (Upgrade 12) #13080
• Implement the initial superchain-ops runbook (Upgrade 12) #13362
• [EPIC] op-deployer changes for OPCM upgrades (Upgrade 12) #13081
• Deprecate snake cased OPCM.OUTPUT_VERSION() method. (Upgrade 12) #13388
• benchmark cost of superchain upgrade #13835
• Add _postCheck() function to OPCM #13836

Milestone: Mainnet

Items which must be completed prior to the mainnet deployment.

• superchain-registry changes - Design and implement the mechanism for mapping release versions to an OPCM (Upgrade 12) #13082
• Detect superchain-registry changes affecting upgrade fork tests (Upgrade 12) #13380
• opcm: Define on canonical representation for OPCM addresses in SCR (Upgrade 12) superchain-registry#806
• OPCM to release 1.0.0 (Upgrade 12) #13599

Milestone: Post-Mainnet

Items which must be completed shortly after mainnet.

• Checklist for shipping contracts to prod (Upgrade 12) #13228
• Modify Test Setup to use op-deployer rather than Deploy.s.sol (Upgrade 12) #13331
• Document manual monorepo steps associated with a new upgrade (Upgrade 12) #13410
• New InitializedResetter contract (Upgrade 12) #13074

[K-Ho]

Sharing Product context on the importance of OPCM:

Problem:
There are two major pain points with upgrading the L1 contracts for the chains in the Superchain

1. Because many chains in the superchain currently have different versions of their L1 contracts, upgrading contracts requires a time consuming process of tracking every different version of the contracts for different chains and handling each upgrade differently.
   If we do nothing, the contract changes for Isthmus would force us to perform the same time consuming manual tasks to track down all versions of the contracts and require more work to get all contracts to the same version.
2. If we keep adding chains to the SC with our upgrades process as-is, there is an enormous amount of increased manual labor for the OP Labs security team and for the Security Council. This includes manual validation of every storage slot, for every upgrade, for every chain—along with the ability to track any subtle variations that may exist for chains that are on different versions. This creates a lot of surface area for something to go wrong.
   Solution
3. OPCM upgrades will allow us to easily get all chains in the Superchain to the same version of the contracts with the Isthmus upgrade(although some chains will be permissioned vs. permissionless), making this version hell a thing of the past.
4. OPCM streamlines the security council signing process

Risks
If we do not thoroughly test out the OPCM upgrade for Isthmus on devnets before the Isthmus testnet upgrade we could risk errors in the upgrade process.