tynes
commented
2 weeks ago This could be good as an individual repository that contains some scripts that build the data (set of storage slots) for each chain that need to be set. The L2 ProxyAdmin owner will be responsible for performing the upgrade, on OP Mainnet this is the aliased L1 governance multisig. All chains will need to be owned by the L1 governance multisig to be part of interop to guarantee that they do not run, so no need for extra tooling. Doing multisig upgrades goes through the superchain-ops process, to ensure that we do the upgrade correctly.
We can compute the mapping storage slots given the sentinel slot and the storage key. We did a lot of this work in Go historically for the bedrock migration. Really any language is fine to generate this, we probably want a JSON file that contains all of the slots that we can audit/perform security analysis on.
Ideally this is complete when we have a task written in superchain-ops that performs the upgrade. The msup tool by Clabby is great for making the JSON files required for the tasks.
We will want to grab all of the events for contracts being deployed through the factory. There are some additional edge cases:
- for OP Mainnet, some tokens are from before bedrock or if they are very old then they are from the regenesis. If they are before regenesis, we may need to do some archeology since the events are not available. We can compare against the token list. We can compute
CREATEaddresses and see if they are in the token list or see if addresses in the token list match the specific bytecode of theOptimismMintableERC20 - For Base, some tokens are deployed from a non standard deployer. This was because the legacy factory used
CREATEand they did not want to have colliding addresses between different assets on two different chains. We will want to grandfather in this tokens, meaning even though they were deployed using a different factory, we will want to
The interop upgrade introduces a way to convert
OptimismMintableERC20tokens intoSuperchainERC20tokens that are portable and fungible across the superchain. The key to enabling this is a new storage slot introduced into theOptimismMintableERC20Factory. This storage slot is used to authenticate bytecode as "trusted" - we know that it doesn't have a backdoor in it, so we can trust it when converting to theOptimismSuperchainERC20token.Ideally we can role out the update to the
OptimismMintableERC20Factoryas part of holocene so that the mapping begins to be updated with deployed tokens. We will need to backport the tokens that were deployed before this update into storage as a one time upgrade across all of the interop chains, otherwise they will need to withdraw and re-deposit to be able to convert their tokens to the interoperable form.This looks like a one time state surgery where the canonical list of storage entries for each chain is computed offchain. We atomically upgrade the predeploy to the
StorageSettercontract and then backfill the storage slots and then upgrade back to the implementation of the factory.