-
Notifications
You must be signed in to change notification settings - Fork 138
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
[Idea] Upgradable actors #717
Comments
IMO, this should simply be implemented as runtime-provided function. Actors can call the "replace code" function to upgrade themselves.
|
We'll also likely need an "upgrade" method on deployed actor code. I.e., when some actor calls
Without this, we'll have a security issue:
|
So, one interesting issue will be re-entrancy. E.g.:
We're going to need to forbid this. My thinking is, when B returns to A, we'd check to make sure the code hasn't changed. If it has, we'd revert and tell A that the call failed because it would create a re-entrant upgrade. |
The approach to upgradeability interacts with other items, such as #721, #729 and Account Abstraction. I am firmly in the camp that it would be a beneficial first-class primitive, and we can make a better development environment by enshrining it, rather than force proxy patterns (which will in turn require more complex FVM primitives like delegatecall that we might otherwise avoid). Another part of the upgrade story is the permission to execute an upgrade, often attributed to an That may be unnecessary, though. The alternative is that every contract manages it's own ownership address (inline, rather than in a proxy) and is responsible for the access-control check before invoking |
@raulk do we need the implementation of this to land in Iron? If not, which milestone would it be needed in? |
No, assuming we can reach consensus on the current actor addressing proposals. |
|
One idea that @Stebalien and I chatted about today is introducing first-class support for upgradable actors in the FVM. This conversation forked from the "how do we upgrade system actors?" question.
Most serious smart contract operators on Ethereum use the proxy pattern to enable contract logic to evolve. There are many ways of doing this, here are some resources:
Upgradability might be a bit polarizing. One could argue for either of these views:
One solution would be to allow actors to implement an "Upgradable" trait, which implements the logic to authenticate an upgrade message.
The text was updated successfully, but these errors were encountered: