Skip to content
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

Merged

Conversation

SWvheerden
Copy link
Collaborator

@SWvheerden SWvheerden commented Sep 20, 2022

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

@SWvheerden SWvheerden changed the title wip_fix: sync handling and increase reorg speed in mempool fix: sync handling and increase reorg speed in mempool Sep 22, 2022
@CjS77 CjS77 added the CR-insufficient_context Your PRs commit messages don't provide enough context to justify accepting the change. label Sep 22, 2022
@hansieodendaal
Copy link
Contributor

hansieodendaal commented Sep 23, 2022

Helps to alleviate issues logged in #3115 as observed with system-level stress testing

hansieodendaal
hansieodendaal previously approved these changes Sep 23, 2022
Copy link
Contributor

@hansieodendaal hansieodendaal left a 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(_) => {},
Copy link
Contributor

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?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

Copy link
Collaborator

@stringhandler stringhandler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine

@stringhandler stringhandler merged commit a3b529a into tari-project:development Sep 26, 2022
stringhandler pushed a commit that referenced this pull request Sep 27, 2022
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
@SWvheerden SWvheerden deleted the sw_fix_sync_handling branch October 5, 2022 05:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CR-insufficient_context Your PRs commit messages don't provide enough context to justify accepting the change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants