Implementation of Mempool Syncer #2832
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Eligioo
changed the title
Eligioo
force-pushed
the
stefan/mempool-syncer
branch
2 times, most recently
from
010d273 to
e129d1c
Compare
hrxi
reviewed
Aug 19, 2024
mempool/src/executor.rs
Outdated
| }; | ||
|
|
||
| network.validate_message::<T>(pubsub_id, acceptance); | ||
| if let Some(pubsub_id) = pubsub_id { |
There was a problem hiding this comment.
We should still somehow punish the sender of an invalid transaction, even if it's not sent via gossipsub.
There was a problem hiding this comment.
Added this. If some of the verification variants are encountered, the peer is banned.
Eligioo
force-pushed
the
stefan/mempool-syncer
branch
3 times, most recently
from
eabf6dd to
4f5c75a
Compare
Eligioo
force-pushed
the
stefan/mempool-syncer
branch
3 times, most recently
from
0f84490 to
c43f4ae
Compare
Eligioo
force-pushed
the
stefan/mempool-syncer
branch
3 times, most recently
from
2011b40 to
b09686b
Compare
Eligioo
added
the
testnet-restart
Eligioo
force-pushed
the
stefan/mempool-syncer
branch
2 times, most recently
from
95e9128 to
0b03d91
Compare
Open
3 tasks
|
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. |
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
Eligioo
force-pushed
the
stefan/mempool-syncer
branch
from
0b03d91 to
0bc22d5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.