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.
This PR retires the
sync_head
concept along with the underlyingsync_header
MMR backend structure.We previously introduced the
sync_head
alongside the existingheader_head
to support the scenario where a peer advertises a large fork with greater total difficulty that requires a header sync + full block sync.head
would refer to the full block with greatest total difficulty.header_head
would refer to the header with greatest total difficulty.sync_head
would refer to the current header along the newly advertised fork as we progress with header sync.This implementation has evolved over time and given our current approach with
get_header_by_height
and the ability to efficiently lookup headers along the best known header chain back fromheader_head
the concept ofsync_head
is effectively redundant.Given the
head
andheader_head
we can (in parallel) effectively support new blocks coming in via p2p relay alongside a newly advertised fork (via updatedheader_head
). Thesync_head
is entirely redundant.The only time
sync_head
will be ahead of and distinct toheader_head
will be during a header sync that involves in excess of 512 headers (multiple batches of headers) and only as long as the new fork is behind the main chain w.r.t. total difficulty. As soon as the total difficulty increases beyond the main chain thenheader_head
will update to reflect the fork.This PR removes
sync_head
and the associated MMR backend and reworks header sync to useheader_head
exclusively and consistently.Performance wise - this should result in a reasonable improvement as we no longer need to maintain a pair of header MMR (header and sync) structures during header sync.
Stability and robustness wise - less data structures to maintain and keep consistent. Less chance of things getting out of alignment etc.