Implementation of Mempool Syncer - #2832
Conversation
Eligioo
changed the title
010d273 to
e129d1c
Compare
eabf6dd to
4f5c75a
Compare
0f84490 to
c43f4ae
Compare
2011b40 to
b09686b
Compare
Eligioo
added
the
testnet-restart
95e9128 to
0b03d91
Compare
|
Why is this a breaking change ( |
Because it introduces some new network request messages. Technically it is behind a feature flag because the syncer utilizes an yet unused service flag so these new request messages would only go to peers that also have this new component. So even though it's breaking, it shouldn't be too difficult to get in but for bookkeeping I kept the label around. |
0b03d91 to
0bc22d5
Compare
0bc22d5 to
20da134
Compare
| } | ||
|
|
||
| info!(num = %transactions.len(), "Synced mempool transactions"); | ||
| self.transactions.extend(transactions); |
There was a problem hiding this comment.
What about the response missing transactions that we requested?
There was a problem hiding this comment.
I my opinion that's OK when you don't receive (all) transactions you are asking for. By the time the peer received your request, the particular transaction(s) could already be adopted in a block.
I think I agree with @sisou that it's not breaking, precisely because it uses a previously unused feature flag. |
hrxi
removed
the
testnet-restart
20da134 to
72dba68
Compare
The syncers get initiated once the Mempool Executors are spawned. One Syncer per Executor is started in order to sync the regular and control transactions separately. First the Syncer starts to discover which transaction hashes other nodes with a mempool have and compare those with what we have locally. Then we distribute those unknown hashes among the peers we know have those transactions and retrieve the actual transactions. Lastly for every received transaction we do a full verification which should add it to our local mempool if everything checks out.
…ain a collection of peers that are in live sync
…ool syncer is active
…ConsensusProxy rather than the Consensus directly
- Only try to construct mempool transaction requests if new hashes are discovered - Check the mempool state first before checking the blockchain if a transaction is already known/included - Bound the amount of received hashes that will be processed per peer - Fix tests
bc8a325 to
4cdd033
Compare
4cdd033 to
0b134ad
Compare
|
@hrxi either your comments are resolved or has received a reply |
3 participants
What's in this pull request?
The Mempool Syncer is responsible for acquiring the transactions that are currently in the mempool of other nodes directly after reaching consensus.
The mempool syncers get initiated once the Mempool Executors are spawned. One Syncer per Executor is started in order to sync the regular and control transactions separately. First the Syncer starts to discover which transaction hashes other peers with a mempool have and compare those with what we have locally. Then we distribute those unknown hashes among the peers we know have those transactions and retrieve the actual transaction. Lastly for every received transaction we do a full verification which should add it to our local mempool if everything checks out.
Open design questions
Max transactions we acquire per peer: 25.000
Amount of transaction per request: 500
After 10 minutes
This fixes #2625 .
Pull request checklist
clippyandrustfmtwarnings.