Part of #27463.
This PR does 3 things:
(1) It modularizes transaction download logic into a TxDownloadManager
. Transaction download logic refers to the process of deciding what transactions to request, download, and validate.[1] There should be no behavior changes. Using --color_moved=dimmed_zebra -w
may help.
(2) It adds unit and fuzz (:magic_wand:) testing for transaction download.
(3) It makes a few small behavioral changes:
- Stop (debug-only) logging tx invs during IBD
- Just like all other transactions, require orphans have RecursiveDynamicUsage < 100k before adding to vExtraTxnForCompact
- Don’t return a 1p1c that contains a parent or child in recent rejects. Don’t process any orphan already in recent rejects. These cases should not happen in actual node operation; it’s just to allow tighter sanity checks during fuzzing.
There are several benefits to this interface, such as:
- Unit test coverage and fuzzing for logic that currently isn’t feasible to test as thoroughly (without lots of overhead) and/or currently only lightly tested through
assert_debug_log
(not good) in functional tests. - When we add more functionality (e.g. package relay messages, more robust orphan handling), the vast majority of it will be within
TxDownloadManager
instead ofPeerManager
, making it easier to review and test. See #28031 for what this looks like. PeerManager
will no longer know anything about / have access toTxOrphanage
,TxRequestTracker
or the rejection caches. Its primary interface withTxDownloadManager
would be much simpler:- Passing on
ValidationInterface
callbacks - Telling
txdownloadman
when a peer {connects, disconnects} - Telling
txdownloadman
when a {transaction, package} is {accepted, rejected} from mempool - Telling
txdownloadman
when invs, notfounds, and txs are received. - Getting instructions on what to download.
- Getting instructions on what {transactions, packages, orphans} to validate.
- Get whether a peer
HaveMoreWork
for theProessMessages
loop
- Passing on
- (todo) Thread-safety can be handled internally.
[1]: This module is concerned with tx download, not upload. It excludes transaction announcements/gossip which happens after we download/accept a transaction. Txreconciliation (erlay) is excluded from this module, as it only relates to deciding which inv
s to send or helping the other peer decide which inv
s to send. It is independent from this logic.