-
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
Fix ed25519 builtin program handling #23182
Conversation
35ed5c5
to
c9a1fb3
Compare
* Fix ed25519 builtin program handling * Fix tests * Add integration tests for processing transactions with ed25519 ixs * Fix another test * fix formatting (cherry picked from commit 813725d) # Conflicts: # runtime/src/bank.rs # runtime/src/genesis_utils.rs
* Fix ed25519 builtin program handling * Fix tests * Add integration tests for processing transactions with ed25519 ixs * Fix another test * fix formatting (cherry picked from commit 813725d)
|
||
[dev-dependencies] | ||
assert_matches = "1.5.0" | ||
ed25519-dalek = "=1.0.1" |
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.
Is this typo?
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.
Are you a bot? Elaborate
* Fix ed25519 builtin program handling (#23182) * Fix ed25519 builtin program handling * Fix tests * Add integration tests for processing transactions with ed25519 ixs * Fix another test * fix formatting (cherry picked from commit 813725d) * fix tests Co-authored-by: Justin Starry <[email protected]> Co-authored-by: Jack May <[email protected]>
recent_blockhash, | ||
); | ||
|
||
assert_matches!(client.process_transaction(transaction).await, Ok(())); |
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.
hehe, i'm not familiar with those tokio based integration tests. but it seems these are nice. :)
also, it's pretty fast compared to the dreadful local-cluster thing.. ;)
2842-running 3 tests
2843-test test_failure ... ok
2844-test test_success ... ok
2845:test test_success_call_builtin_program ... ok
2846-
2847-test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.30s
so, this test is checking ed25519 instruction still success as long as it's directly embedded into tx (i.e. not via CPI) regardless prevent_calling_precompiles_as_programs
is activated or not.
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.
lgtm
Apparently this causing panic when starting a validator off master on testnet:
|
Yep! Fix is here #23233 |
* Fix ed25519 builtin program handling * Fix tests * Add integration tests for processing transactions with ed25519 ixs * Fix another test * fix formatting
* Fix ed25519 builtin program handling * Fix tests * Add integration tests for processing transactions with ed25519 ixs * Fix another test * fix formatting
* Fix ed25519 builtin program handling * Fix tests * Add integration tests for processing transactions with ed25519 ixs * Fix another test * fix formatting
* Fix ed25519 builtin program handling * Fix tests * Add integration tests for processing transactions with ed25519 ixs * Fix another test * fix formatting
This PR has been automatically locked since there has not been any activity in past 14 days after it was merged. |
Problem
Master and v1.9 branches are incompatible with v1.8.
The ed25519 program was originally added as a "builtin" program which means that ed25519 instructions would be loaded by the native loader. However, on master and v1.9, ed25519 was changed to be a "precompile" program to prevent it from being invoked by on-chain programs (it always returns success so this would be confusing).
On devnet/testnet/mainnet-beta, the ed25519 program has already been activated as a builtin, and so both precompile programs, secp256k1 and ed25519, are still invokable because the
prevent_calling_precompiles_as_programs
feature wasn't back ported to v1.8 and so hasn't been activated yet. In order to transition those clusters to v1.9, the precompiles need to be handled as builtins until theprevent_calling_precompiles_as_programs
feature is activated.Summary of Changes
At a high level, this PR just ensures that ed25519 is treated the same way as secp256k1. When the
prevent_calling_precompiles_as_programs
feature is activated, both programs will be transitioned from builtins to precompiles.prevent_calling_precompiles_as_programs
feature is activatedprevent_calling_precompiles_as_programs
feature is activatedFixes #23180
this regression is introduced at #19918 and #19930