-
Notifications
You must be signed in to change notification settings - Fork 94
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
SIMD-0167: Loader-v4 #167
base: main
Are you sure you want to change the base?
SIMD-0167: Loader-v4 #167
Conversation
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.
I also noticed there are several typos on the word "throw"
proposals/0167-loader-v4.md
Outdated
otherwise throw `UnsupportedProgramId` | ||
- the program account is at least as long enough for the header, | ||
otherwise throw `AccountDataTooSmall` | ||
- the status stored in the program account is not retracted, |
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.
why would status of deployed
or finalized
throw an error?
should this be when the status is retracted?
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.
The check asserts that the status is not retracted
, thus only retracted
throws the error.
fc20b4e
to
bd5ab89
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.
Very nice to see this well-written, well-specified SIMD!
Would be great to get more detail on the migration path from v3 to v4.
|
||
- loader-v3 clears the program proxy account (setting its size to zero) | ||
- loader-v3 transfers all funds from the programdata to the proxy account | ||
- loader-v3 gifts the program proxy account to loader-v4 |
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.
How would the gifting work? Do we need to add a new instruction to the v3 loader? Will this upgrade mechanism be specified in a future SIMD?
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.
I see three options here:
- A migrate instruction for loader-v3 which the dApp devs trigger themselves
- A migrate instruction for loader-v3 which we the protocol engineers trigger
- A feature gate which scans the accounts DB and migrates all loader-v3 programs
I would prefer the second option as that allows us to keep the gathering of the loader-v3 program list and then slowly working through it off-chain and still makes sure that all loader-v3 programs get migrated.
No description provided.