v3.1: Add check for existing program data account on migration (backport of #8982)#9128
v3.1: Add check for existing program data account on migration (backport of #8982)#9128mergify[bot] wants to merge 1 commit intov3.1from
Conversation
* Add check for existing program data account * Move bank mutation * Update p-token feature id * Simplify program data account lamports handling * Improve owner check (cherry picked from commit 3e5af27)
| use super::Pubkey; | ||
|
|
||
| solana_pubkey::declare_id!("ptokSWRqZz5u2xdqMdstkMKpFurauUpVen7TZXgDpkQ"); | ||
| solana_pubkey::declare_id!("ptokEXBPT9HuYdAQRysaStZNTY9bHsAcQzNscEoA6HC"); |
There was a problem hiding this comment.
why's this under ptoken upgrade instead of its own thing? seems orthogonal
There was a problem hiding this comment.
P-token is the next (only) active migration and this fix should go in before/alongside that codepath, since it's susceptible.
There was a problem hiding this comment.
i'm sorry, how does that justify doing two totally unrelated things under the same feature gate?
There was a problem hiding this comment.
They are related in the sense that the codepath of the fix is only ever executed during a migration of a "loader v2 program -> loader v3 program" (p-token falls in this category); the fix also applies to migration of "native program -> loader v3 program", but we don't have active migrations for this at the moment.
There was a problem hiding this comment.
ok but that's not how we do feature gates. please take it back to master and key it separately. if there's not already a simd for these changes (don't see one referenced here or master pr), that is also required before changing consensus logic
|
are we planning to do this right? |
I suppose technically the correct thing to do is:
Note that implementing the codepath to migrate from a v2 to a v3 program can't really use a feature gate. The code would simply exist off of the hot path and cannot become active until a migration is scheduled. That next migration will be P-Token, so we basically end up in almost the same position. However, I'm personally not against proper procedure here. |
|
Created SIMD-0418 detailing the migration of Loader v2 programs to v3 based on SIMD-0088. @buffalojoec Happy to amend SIMD-0088 with the lamports/owners check once we agree on the wording. |
|
since simd-0088 is already active, i believe we should not modify it. rather this would need to be a separate simd back-referencing simd-0088. luckily we don't seem to have documented how to do this. closest reference i'm aware of is simd-0118 supersedes simd-0015 |
|
@febo any eta on splitting this one up as discussed at breakpoint? |
Most likely by the end of the week. Reviewing the code with @buffalojoec and then creating the PRs. |
great! can we close this now? it comes up every week in the backport review call |
3 participants
Problem
When migrating builtin/loader-v2 programs to loader-v3, the migration can be blocked by pre-funding the program data account so it appears to already exist.
Summary of Changes
Add an additional check when the program data account is found to assert that it is a "real" program data account; otherwise, burn and purge the account so the migration succeeds.
Note: the PR also updates the p-token feature id.
This is an automatic backport of pull request #8982 done by Mergify.