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.
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
Rework validation logic for assumeutxo #27746
Rework validation logic for assumeutxo #27746
Changes from 1 commit
fe86a7c
1cfc887
471da5f
10c0571
272fbc3
3cfc753
d0d40ea
d43a1f1
768690b
0ce805b
3556b85
d4a11ab
a733dd7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
In commit "Move block-storage-related logic to ChainstateManager" (034f920)
It seems like
fHasMoreOrSameWork
will always be false for blocks that were downloaded to be added to the background chain, because they will have less work than the active snapshot chain.Is that intentional? It would helpful to have a comment here either that either explains why this ok, or adds a TODO indicating that there will be some change later.
I do understand there is not a change in behavior here in this commit because in both places where
Chainstate::AcceptBlock
was called previously (inProcessNewBlock
andLoadExternalBlockFile
), it was only called on the active chainstate, so it is still only looking at the active chainstate now.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.
The idea here is that this check is part of a heuristic that we use when we receive a block that was not requested. For anti-DoS reasons, back in #5875 we introduced logic to generally not process unrequested blocks, but we left in an optimization that was intended to not throw away blocks that would immediately advance our tip, in case we had some peer (like Matt's old fast-relay-network, if I remember right) that was sending such blocks (see eg comment here #5875 (comment)).
My view is that we don't need to process unrequested blocks in general, and that if we do so it's just an optimization to make block relay at the tip work better. We could probably add special-case logic to allow processing of unrequested blocks that we haven't yet validated that are ancestors of the ancestor block, but this doesn't strike me as something that is at all necessary (and perhaps not desirable?).
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.
re: c8f4a87#r1251271941
Thanks, that makes sense, and thanks for linking to #5875.
To make this less confusing, I think "Try to process all requested blocks" code comment above could be updated to mention the active chain and better match the code.
Would suggest: "// Check all requested blocks that we do not already have for validity and save them to disk. Skip processing of unrequested blocks as an anti-Dos measure, unless the blocks have more work than the active chain tip, and aren't too far ahead of it, so are likely to be attached soon."
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.
d0d40ea Maybe add:
Background validation always ignores unrequested blocks.
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.
d0d40ea:
// We don't relay background validation blocks.
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.
In commit "Move block-storage-related logic to ChainstateManager" (034f920)
Do you think it would be good if the
IsInitialBlockDownload
method were moved toChainstateManager
. Is there any place it should be actually called on the background chainstate rather than the active chainstate? Could add a TODO comment if IsInitialBlockDownload method should move like other methods are moving.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.
I haven't done a careful review of all the places we use
IsInitialBlockDownload()
to confirm this, but my intuition would be that if we're using an assumeutxo snapshot, what we care about is whether our snapshot-based chainstate is caught up or not -- basically by definition, the background chainstate will always be "in initial block download" until it finishes and is no longer in use, so it wouldn't make sense to condition anything on whether it's behind or not.So yeah I think moving this to ChainstateManager would probably make sense...
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.
re: #27746 (comment)
Thanks, it makes sense that the background chainstate only has one state because it is deleted as soon as it finishes syncing.
Would be great if a followup PR moved
IsInitialBlockDownload
fromChainstate
class toChainstateManager
so theIsInitialBlockDownload
implementation could refer directly to the active chainstate, andIsInitialBlockDownload
callers wouldn't need to figure out which chainstate to call it on.