* [vote_authorize_with_seed] Add `VoteInstruction::AuthorizeWithSeed`
* [vote_authorize_with_seed] You can now update a vote account's authority if it's a derived key for which you control the base key
* [vote_authorize_with_seed] Add test helper to create a vote account whose authorities are derived keys
* [vote_authorize_with_seed] Write tests to assert the behavior of `VoteInstruction::AuthorizeWithSeed`
* [vote_authorize_with_seed] Feature gate the `VoteInstruction::AuthorizeWithSeed` processor
* [vote_authorize_with_seed] Add `VoteInstruction::AuthorizeWithSeed` to transaction status parser
* [vote_authorize_with_seed] Add `VoteInstruction::AuthorizeWithSeed` to docs
* [vote_authorize_with_seed] Add `VoteInstruction::AuthorizeCheckedWithSeed`
* [vote_authorize_with_seed] You can now update a vote account's authority (while checking that the new authority has signed) if it's a derived
key for which you control the base key
* [vote_authorize_with_seed] Add `VoteInstruction::AuthorizeCheckedWithSeed` to transaction status parser
* [vote_authorize_with_seed] Write tests to assert the behavior of `VoteInstruction::AuthorizeCheckedWithSeed`
There's no direct linkage between account-update events and transaction-events
Issue is linked with geyser plugin interface
Currently, there's no straightforward way to determine what notify_transaction call is related to particular update_account call. So, there's no simple way to determine what transaction caused what changes in accounts. This issue is especially valuable in case when several transactions modifies single account in the same slot.
Add txn_signature field to ReplicaTransactionInfo structure
This additional field will contain the signature of transaction which caused this account update event. This modification is not bringing significant overhead because all necessary information for such linkage already available inside Accounts::collect_accounts_to_store method
https://github.com/solana-labs/solana/pull/25788
permanently disables durable transactions with legacy nonce versions
which are within chain blockhash domain.
This commit adds a new system instruction for a one-time idempotent
upgrade of legacy nonce accounts in order to bump them out of chain
blockhash domain.
https://github.com/solana-labs/solana/pull/25744
separated durable nonce and blockhash domains, which will stop double
execution going forward. However it is possible that a durable
transaction has *already* been executed once as a normal transaction and
it is now a valid durable transaction. #25744 cannot stop such
transactions to be re-executed until the nonce accounts are advanced.
This commit adds a new nonce version indicating that the nonce is moved
out of the blockhash domain, and permanently disables durable
transactions for legacy nonces which are in the blockhash domain.
* fix double count of account index del stats
* refactor to seperate delete and insert account index stats
* fix test
* increase test timing tolerance for bucket age
* Revert "increase test timing tolerance for bucket age"
This reverts commit 2b91cf902208e4585d25dff1d4298d412c9da516.
* Revert "Revert "increase test timing tolerance for bucket age""
This reverts commit 8f07367b64ddc45a9a693729ea2725895627d14c.
* fix double count of account index del stats
* refactor to seperate delete and insert account index stats
* fix test
* increase test timing tolerance for bucket age
* Revert "increase test timing tolerance for bucket age"
This reverts commit 2b91cf902208e4585d25dff1d4298d412c9da516.
* Remove the args param from Measure::this since we don't ever use it
* banking_stage.rs: convert to measure!
* poh_recorder.rs: convert to measure!
* cost_update_service.rs: convert to measure!
* poh_service.rs: convert to measure!
* bank.rs: convert to measure!
* measure.rs: Remove Measure::this now that all have been converted to measure!
Previous commit separates durable nonce and blockhash domains with a
feature gate. A 2nd feature added in this commit enables durable nonce
at least one epoch after the 1st feature.
By the time 2nd feature is activated, some nonce accounts will have an
old blockhash, but no nonce account can have a recent blockhash.
As a result no transaction (durable or normal) can be executed twice.
AdvanceNonceAccount instruction updates nonce to blockhash. This makes it
possible that a durable transaction is executed twice both as a normal
transaction and a nonce transaction if it uses blockhash (as opposed to nonce)
for its recent_blockhash field.
The commit prevents this double execution by separating nonce and blockhash
domains; when advancing nonce account, blockhash is hashed with a fixed string.
As a result a blockhash cannot be a valid nonce value; and if transaction was
once executed as a normal transaction it cannot be re-executed as a durable
transaction again and vice-versa.
* Bank: Batch account stores in collect_rent_eagerly
Previously store() calls were done one-by-one, which leads to suboptimal
performance.
* Accounts: Remove store_slow_cached()
* clippy
Co-authored-by: Jeff Washington (jwash) <wash678@gmail.com>
Alexander Meißner
Jeff Washington (jwash)
Steven Luscher
apfitzge
Michael Vines
Brooks Prumo
Jack May
ivandzen
behzad nouri
Justin Starry
HaoranYi
Ashwin Sekar
Christian Kamm
sakridge
carllin