Update for single step upgrades #486
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite. This stack of pull requests is managed by Graphite. Learn more about stacking. |
maurelian
requested review from
protolambda,
tynes,
ajsutton,
sebastianst and
mslipper
as code owners
| 1. the first upgrade is to an `InitializerResetter` which resets the `initialized` value. | ||
| 1. the implementation is updated to the final address and `upgrade()` is called on that address. | ||
| 3. For each address: | ||
| 1. If it is receiving new state variables (only the SystemConfig for Isthmus), a call is made to: |
There was a problem hiding this comment.
I don't think its great to leak the implementation details like only sys config for isthmus into the spec. How I would propose structuring this is having a section "Network Upgrades" and then having a subheading for each network upgrade and define the specifics for that upgrade in there
| Thus for Isthmus, the System config will receive the following new function. | ||
|
|
||
| ```solidity | ||
| function upgradeIsthmus(IsthmusConfig _isthmusConfig) external; |
There was a problem hiding this comment.
What is the definition of this config?
There was a problem hiding this comment.
specs/specs/experimental/op-contracts-manager.md
Lines 214 to 220 in bb119d0
| This approach requires that all contracts have an `upgrade()` function which sets the `initialized` | ||
| value to `true`. The `upgrade` function body should be empty unless it is used to set a new state | ||
| variable added to that contract since the last upgrade. | ||
| Thus for Isthmus, the System config will receive the following new function. |
There was a problem hiding this comment.
We would replace this function in the next release and put upgradeKarst(KarstConfig _config)?
There was a problem hiding this comment.
hypothetically if there was another change
Changes: