-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: sync handling and increase reorg speed in mempool #4706
fix: sync handling and increase reorg speed in mempool #4706
Conversation
16ef9dd
to
9a2c0aa
Compare
Helps to alleviate issues logged in #3115 as observed with system-level stress testing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I thoroughly tested this code with system-level stress testing:
- spending dust - filling up blocks with not so many transactions but each having many many inputs
ToDo:
- normal transactions
- coin splits
}, | ||
BlockSyncComplete(tip_block) => { | ||
self.mempool.process_published_block(tip_block.to_arc_block()).await?; | ||
BlockSyncRewind(_) => {}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
self.mempool.process_published_block(tip_block.to_arc_block()).await?; | ||
BlockSyncRewind(_) => {}, | ||
BlockSyncComplete(_,_) => { | ||
self.mempool.process_sync().await?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine
Description --- Adds in the ability to retrigger the mempool sync if a larger re_org or block sync occurred. Motivation and Context --- As of #4706 the mempool will now properly handle re-orgs and block syncs. But when the base_node is not at the "correct" tip its mempool will reject all invalid transactions. In order to get those transactions back, we need to trigger a mempool sync. This adds in a new config setting to control the maximum number of blocks the base_node added during a reorg or sync before it starts a sync process. The assumption is that in most cases, the blocks removed will be less or the same as the blocks added, so we only need to look at the blocks added. Open Questions --- Do we just sync to one peer, or do we sync to `initial_sync_num_peers` peer? Prerequisite ---- Requires: #4706
Description
This PR updates the handling reorgs and syncs in the mempool.
The reorg code is updated to remove unnecessary checks when handling reorgs.
The sync code is completely redone to now only listen for a sync completed status. As of now the mempool ignores the rewind event as the mempool knows this is not the final state, either the base node will forward to a new tip or reset itself to the old tip. The base node upon receiving sync completed event will re-evaluate all transactions inside of it and reset it state to the correct state.
There will be a followup pr to add mempool sync