feat: Add OPCM upgrades FMA #173
Conversation
|
|
||
| 1. The use of spacer variables in L1 contracts to prevent storage collisions. | ||
| 2. The use of storage layout lock files tracked in git to detect breaking changes. | ||
| 3. The use of off-chain checks in the `superchain-ops` scripts to ensure that getters |
There was a problem hiding this comment.
Are you talking about a check that looks something like this?
When we eventually use op-deployer for upgrades, are we still going to be using the same superchain-ops setup? i.e.
- Write a script and VALIDATIONS.md file
- Inside the script, we will call
upgrade()on the target opcm. - Inside the post check function in the script we will perform necessary validation.
Am I right in saying we will continue to use the same superchain-ops process once we upgrade to opcm?
There was a problem hiding this comment.
Are you talking about a check that looks something like this?
Yes.
Am I right in saying we will continue to use the same superchain-ops process once we upgrade to opcm?
I think this is an open question, and one that the upgrades team will need to make together. I know there are significant changes to the ops repo planned, so that will have an impact here.
| #### **Mitigations:** | ||
|
|
||
| 1. Define the correct upgrade path in the `superchain-registry`. | ||
| 2. Enforce the correct upgrade path in `op-deployer` which is the official interface for upgrading OP Chains. |
There was a problem hiding this comment.
I wonder if it would be useful to have a solidity script in superchain-ops that helps with double checking the OPCM address is correct for the current version by using a library like: https://github.com/memester-xyz/surl
There was a problem hiding this comment.
In addition the the op-deployer check, this would add some defense in depth.
There was a problem hiding this comment.
Interesting idea. One of the main open gaps is to clarify how superchain-ops fits into the flow and where the line is between it and op-deployer.
Co-authored-by: blaine <[email protected]>
Co-authored-by: blaine <[email protected]>
|
|
||
| #### **Detection:** | ||
|
|
||
| This is detected whenever and however it is detected. |
There was a problem hiding this comment.
Yea it seems like you're calling out the complexity of the process here. Detection of a fault might be accidentally upgrading to the wrong version. In that case, we hope that we have some defense in depth against this. Employing some of the techniques you mentioned earlier in the doc i.e. checking superchain-registry ordering of OPCMs before execution of the upgrade.
There was a problem hiding this comment.
Exactly. I think this might be too fuzzy of a failure mode and it's already covered by "FM4: Failure to follow upgrade path". How do you feel about removing it?
There was a problem hiding this comment.
I think it's fine to remove. Like you said, it's covered in FM4.
Co-authored-by: blaine <[email protected]>
FMA associated with OPCM Upgrades.