design doc for the ocpm superchain upgrade fix #310
Conversation
Co-authored-by: Maurelian <[email protected]>
Co-authored-by: Maurelian <[email protected]>
Co-authored-by: Maurelian <[email protected]>
| } | ||
| ``` | ||
|
|
||
| ## Requirements and Expected behaviour |
There was a problem hiding this comment.
We should remove this section since we added a similar one above.
Co-authored-by: Maurelian <[email protected]>
Co-authored-by: Maurelian <[email protected]>
|
|
||
| ## Proposed Solution | ||
|
|
||
| A proposed solution for this is to change the check to version comparisons. We can hardcode an expected version for the SuperchainConfig and compare it to the actual version. If the actual version is equal to the expected version, we can upgrade the SuperchainConfig. Otherwise we continue the execution. |
There was a problem hiding this comment.
To clarify, which of the following will be the upgrade condition
- The current
superchainConfig.version()value is equal to the previous OR - The current
superchainConfig.version()value is not equal to the current
?
| } | ||
| } | ||
| ``` | ||
| - It is also important to note that for any superchain asides the one with its superchainConfig hardcoded in the OPCM, in order to upgrade the superchainConfig, one of it's L1 chains which has the same ProxyAdmin as the SuperchainConfig's ProxyAdmin will need to be upgraded in the same transaction i.e the `OpChainConfig` should not be empty. This is because if the `OpChainConfig` is empty, the function defaults to using a hardcoded superchainConfig and superchainProxyAdmin. |
There was a problem hiding this comment.
I think that this is very important. It means that:
- we do not support a SuperchainConfig having a ProxyAdmin which is not also the owner of an OP Chain
- it is not possible to upgrade a SuperchainConfig without upgrading at least one OP Chain.
| <!-- An overview of what could go wrong. | ||
| Also any open questions that need more work to resolve. --> | ||
| - **A chain might be upgraded when it's superchainConfig is not upgraded:** | ||
| - Mitigation: We can implement a simple loop to assert that all chains in the array are of the same superchain and have tests for this. |
There was a problem hiding this comment.
Above it says:
Note this means that it is possible for OPChains of different superchains to be upgraded in one call to
OPCM.upgrade()as long as they share the same proxyAdminOwner. This means that we must check that each OPChain's superchainConfig is at the correct version before proceeding to upgrade it, otherwise we revert the transaction.
Which way should we go, allow this situation or not?
There was a problem hiding this comment.
we want to allow.
Note this means that it is possible for OPChains of different superchains to be upgraded in one call to OPCM.upgrade() as long as they share the same proxyAdminOwner. This means that we must check that each OPChain's superchainConfig is at the correct version before proceeding to upgrade it, otherwise we revert the transaction.
I have fixed the FMA
design doc for the ocpm superchain upgrade fix