-
Notifications
You must be signed in to change notification settings - Fork 20.3k
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
eth/downloader: resolve local header by hash for beacon sync #24691
Merged
Merged
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
7abaf28
eth/downlaoder: resolve local header by hash for beacon sync
rjl493456442 c98ff83
eth/downloader: fix error message
rjl493456442 9986865
eth/downloader: cap the reverse header resolving
rjl493456442 4e5e436
eth/downloader: re-enable tests
rjl493456442 8ac432b
eth/downloader: add warning logs
rjl493456442 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
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 don't think this is a good idea. The new
getAncestorHeader
is a linear scanning fromtail
down tofrom
. Given that we're in a loop already, that would be an O(n^2) blowup.However, I'm unsure I understand why this lookup was introduced in the first place. When filling the chain from the beacon headers, why are we looking at the chain? IMHO if something's missing from the beacon chain, we should abort sync, not "sync from ourselves".
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.
It was introduced here, but I don't understand why https://github.com/ethereum/go-ethereum/pull/24610/files#diff-8cb29165929b2bd4c8f7c019a95cc8a69d3e36320703308f5c835fa97bdd8f31R270
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 guess the use case was that if I just switched to merge transition then I may not have 64 headers yet, so the pivot is pre-merge (and pre-skeleton) and thus feeding pivot and post-pivot headers needs a local lookup. Still feels kind of wonky, very weird special case that will keep haunting us.
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.
Btw, with the scanning thing, we're scanning over and over and over again the exact same header range. We could have stopped after one scan and collected all the needed headers.
Also IMHO if this case should handle some very short (transition length) range, we should put some cap on the iteration count, otherwise it's asking for trouble if someone manages to iterate all the way back to the genesis somehow.
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 reason for adding lookup in local chain is exactly what you said, in this special scenario we need the feed the header from local. But this scenario is kind of common right now, we have a bunch of panics recently are all relevant with this scenario.
And also it's true that the scanning range should be short, we can limit the scanning length to be 64 to avoid the bad situation.
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.
Yes, I think adding a 64 limit should be welcome as that should cover the pivot leaking into the legacy sync part, but should still prevent any weird attacks. Perhaps let's add an error log if we can't find the needed header within the
fsMinFullBlocks
threshold and return an error + tear down sync to avoid the panics.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.
And perhaps I would also add a warning log for the normal case - just for a few months before/after the merge - so we can see if/when it's happening and see if the bug is indeed just a transition issue or if it appears somewhere else too that can be fixed.
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.
All pushed, please take another look