-
Notifications
You must be signed in to change notification settings - Fork 489
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
RFC35/Common Ancestor Approach #386
Conversation
…2.15-beta3-candidate
* Bump Go version to v1.18.1
This will create a static build using Go native networking stack. Checked and it works stable for all archs and distros.
Codecov Report
@@ Coverage Diff @@
## master #386 +/- ##
==========================================
- Coverage 56.75% 56.65% -0.10%
==========================================
Files 578 580 +2
Lines 68312 68428 +116
==========================================
- Hits 38771 38770 -1
- Misses 26182 26293 +111
- Partials 3359 3365 +6
Continue to review full report at Codecov.
|
return 0, common.Hash{}, errEndBlock | ||
} | ||
|
||
hash := fmt.Sprintf("%v", block["hash"]) |
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.
Could we use Hex() method?
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 overall.
52562d3
to
b19d5e1
Compare
This PR is the first step towards reducing reorgs and is a part of RFC35.
It adds a new background service called checkpoint whitelist which keeps running and asks it's heimdall for the latest checkpoint entries. Similar to the
--whitelist
flag, it stores the<block number> -> <block hash>
mapping. The interesting part is that it leverages the heimdall checkpoints for making these entries. Basically it adds every end block number to end block hash entry to this in memory map (which is capped to 10).This is to prevent the node to connect to wrong/invalid peers which are not on the correct fork. We decide that before even asking the peer for new blocks i.e. in the
findAncestor
function in downloader. Basically, we ask for the last checkpointed block of ours from the peer. If we're able to validate the details, then and then only we'll allow that peer to connect. In case of mismatch, we will eventually drop or stall the peer until it has relevant and correct blocks.Sufficient unit tests are added and devnet testing has been carried on for the same. The next step is to make modifications in the forkchoice rule. Refer #425 for the next step.