-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Enable rolling update of "Permit paying oneself" / "No longer allow create-account to add funds to an existing account" #10375
Conversation
runtime/src/builtin_programs.rs
Outdated
BuiltinProgram::new( | ||
"system_program", | ||
system_program::id(), | ||
system_instruction_processor::process_instruction, // TODO: This is the OLD system instruction processor |
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.
Big advantage to this approach IMO is that system_instruction_processor
doesn't need to be peppered with if
checks. We make a copy of system_instruction_processor.rs
into legacy_system_instruction_processor.rs
with the old code, then system_instruction_processor.rs
only contains the new code. Now devs don't need to dance around if
s as they make future modifications to system_instruction_processor.rs
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.
Instead of "legacy" how about starting off with a version in case there are more of these kinds of changes later?
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.
Once the new system_instruction_processor
is deployed to all clusters I was thinking we delete legacy_system_instruction_processor
from master and then we're back to just system_instruction_processor
. But yes in that time it means we could ends up with a legacy_legacy_instruction_processor
.
I like the idea of keeping the latest version just named system_instruction_processor
. maybe legacy_system_instruction_processor0
instead of legacy_system_instruction_processor
so there's room to add legacy_system_instruction_processor1
if needed?
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 went with legacy_system_instruction_processor0
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.
Yeah, okay. Legacy copies will add to compile times, but I don't see any other drawbacks.
Slightly yes. But we can/should also purge the legacy copies once all three clusters have moved beyond their respective activation epoch |
Need to deal with solana/programs/bpf_loader/src/syscalls.rs Line 770 in 03abd3d
|
Blocked on #10383 |
unblocked! |
Codecov Report
@@ Coverage Diff @@
## master #10375 +/- ##
=========================================
+ Coverage 81.4% 81.5% +0.1%
=========================================
Files 294 295 +1
Lines 68258 69132 +874
=========================================
+ Hits 55582 56366 +784
- Misses 12676 12766 +90 |
Two recent system program changes will cause a hard fork if deployed without feature gating:
The system_instruction_processor without these two features is now found in legacy_system_instruction_processor.rs. legacy_system_instruction_processor will be used for testnet/mainnet-beta for now, while system_instruction_processor is used for devnet.
Once this PR is backported to v1.2 and v1.1, separate PRs will be created at the appropriate time to activate these two new features on testnet/mainnet-beta