Fix ed25519 program owner on testnet #23219
Conversation
Codecov Report
@@ Coverage Diff @@
## v1.9 #23219 +/- ##
=========================================
- Coverage 81.7% 81.6% -0.1%
=========================================
Files 529 529
Lines 147946 147951 +5
=========================================
- Hits 120882 120857 -25
- Misses 27064 27094 +30 |
|
|
?
|
I'm not sure this is the direction we want to take. The ed25519 program is owned by the system program because that's how precompiles are added. Maybe that was unintentional? |
|
It's divergent from how the account was created on devnet and MB |
Yeah, I'm aware of that. I think there might be a better way to handle the snapshot issue. Will dig in a bit |
|
True, pre-compiles are added as owned by the system account, but I don't think that was intentional and of the two precompiles, only the ed program is owned by the system program and only on testnet for some reason. I can't think of a reason to not make it consistent across nets and precompiles by switching the owner of the ed program to the native loader. |
|
On mainnet*, ed25519 is a builtin program with account data including the string "ed25519_program" which doesn't apply to precompiles either. So even if we fix the owner, it's still going to be different on mainnet because it was added as a builtin program there already. |
|
You mean on mainnet? |
|
Mainnet-beta and devnet are consistent. I'm in favor of the shortest path to aligning testnet with them |
jackcmay
force-pushed
the
fix-ed25519-program-owner-2
branch
from
e4c9a4a to
389ebcf
Compare
|
I think we need two release to fix this issue, one that sets the owner to native loader on testnet current changes in this pr, and another that adds back the ed25519 program to the builtin list like you had it in your last change. |
There was a problem hiding this comment.
This PR will break mainnet-beta/devnet again, failing test here: jackcmay#363
|
Yeah, that would be fixed by the second release before taking v1.9 to mainnet |
|
We don't need multiple releases, I have a different fix here: #23233 |
|
Closed in lieu of a better fix here: #23233 |
Problem
Testnet's ed25519 program account is owned by the system program and not the native loader. This causes an assertion during snapshot load because the program is expected to exist and be owned by the native loader, if this is not the case then the program is re-added but during snapshot load the bank is frozen and thus panics.
Summary of Changes
Re-add the ed25519 program via a feature, this will reset the account's owner to the native loader.
Fixes #