-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OPCM L1 Upgrades #159
OPCM L1 Upgrades #159
Conversation
f86a99c
to
34679b3
Compare
e7a7285
to
15af9a9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
love this
contracts within one block. | ||
- **Declarative design:** As much as possible, a developer should be able to simply indicate what | ||
bytecode should be deployed, and what storage values (if any) should be initialized or modified. | ||
- **Deterministic upgrade calldata:** The exact calldata to be submitted during the upgrade should |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maurelian The AnchorStateRegistry
is a possible exception to this where the calldata is based on recent chain state and that state cannot be known at the time of the governance proposal. While we can relax this chain state requirement for initializing the ASR, perhaps it would be good to callout this as design principle when writing smart contract initializers.
Describes a fully onchain upgrade process.