Replace txn_signature in ReplicaAccountInfo with transaction#30189
Replace txn_signature in ReplicaAccountInfo with transaction#30189lijunwangs merged 5 commits intosolana-labs:masterfrom
Conversation
| /// write_version. | ||
| pub write_version: u64, | ||
|
|
||
| /// Reference to transaction caused this account modification |
| pub write_version: u64, | ||
|
|
||
| /// Reference to transaction caused this account modification | ||
| pub txn: Option<&'a SanitizedTransaction>, |
There was a problem hiding this comment.
Can SanitizedTransaction change under our feet and resulting in missing a version update?
There was a problem hiding this comment.
I'm not sure how can it be possible. update_account notification happens syncronously after transaction processing in a single thread, reference is immutable. If such change is possible then it definitely happens regardless plugin behaviour.
There was a problem hiding this comment.
I meant update in different validator versions. I don't have a good solution either -- duplicating the object is an overkill and will likely impact performance. In the end the plugin has to compile with the validator and test to make sure it works.
There was a problem hiding this comment.
But there's no cloning here. It all depends on behaviour of plugin. In my implementation of plugin there's no cloning at all. This field is used to proceed filtration at the very beginning of account_update handler and not passed any further.
There was a problem hiding this comment.
Plugin than pass only signature of transaction to account table. And it will be enough to match accounts and transactions in different tables in database
There was a problem hiding this comment.
If you are talking about compatibility between different versions of validator (in case when SenitizedTransaction changed internally) then of course you should always have plugin built against corresponding validator libraries. But it is the same as for TransactionReplicaInfo - we have the same reference to SanitizedTransaction inside. Of course better way for compatibility is to have special structure which clones internals of transaction. But this approach is very inefficient in terms of performance. So I think this implementation of ReplicaAccountInfo doent not bring any additional drawbacks other than already exists in plugin engine design.
There was a problem hiding this comment.
Yes, we faced such issues when moving from 1.14.10 to 1.14.12 (if i'm not mistaken with numbers) - SanitizedTransaction changed it's message field type.
|
There is also some CI issues, please remember to do |
3 participants
Current implementation of ReplicaAccountInfo restricts possibilities for inflight account filtration
Current implementation includes transaction signature in ReplicaAccountInfo. This approach does not allow to filter accounts by matching other accounts in transaction in-flight (e. g. accept only those accounts included in transactions for specific programs). Current implementation forces to collect ALL accounts and transactions for some period of time and perform such complex filtration afterwards.
Pass reference to transaction object instead of transaction signature into ReplicaAccountInfo
Advanced in-flight filtration can be implemented in plugins by passing reference to transaction for every update_account event. This change doesn't bring any overhead comparing to current implementation (only data type of reference is changed) and brings only minor changes in source code.