Starting from a weak subjectivity point / arbitrary finalized epoch #1891
Labels
A1
consensus
An issue/PR that touches consensus code, such as state_processing or block verification.
Networking
Comments
bors bot
pushed a commit
that referenced
this issue
Dec 13, 2020
## Issue Addressed Related to #1891, The error is not in the spec yet (see ethereum/consensus-specs#2131) ## Proposed Changes Implement the proposed error, banning peers that send it ## Additional Info NA
bors bot
pushed a commit
that referenced
this issue
Dec 14, 2020
## Issue Addressed Related to #1891, The error is not in the spec yet (see ethereum/consensus-specs#2131) ## Proposed Changes Implement the proposed error, banning peers that send it ## Additional Info NA
bors bot
pushed a commit
that referenced
this issue
Dec 15, 2020
## Issue Addressed Related to #1891, The error is not in the spec yet (see ethereum/consensus-specs#2131) ## Proposed Changes Implement the proposed error, banning peers that send it ## Additional Info NA
7 tasks
bors bot
pushed a commit
that referenced
this issue
Sep 22, 2021
## Issue Addressed Closes #1891 Closes #1784 ## Proposed Changes Implement checkpoint sync for Lighthouse, enabling it to start from a weak subjectivity checkpoint. ## Additional Info - [x] Return unavailable status for out-of-range blocks requested by peers (#2561) - [x] Implement sync daemon for fetching historical blocks (#2561) - [x] Verify chain hashes (either in `historical_blocks.rs` or the calling module) - [x] Consistency check for initial block + state - [x] Fetch the initial state and block from a beacon node HTTP endpoint - [x] Don't crash fetching beacon states by slot from the API - [x] Background service for state reconstruction, triggered by CLI flag or API call. Considered out of scope for this PR: - Drop the requirement to provide the `--checkpoint-block` (this would require some pretty heavy refactoring of block verification) Co-authored-by: Diva M <divma@protonmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
It is desirable to avoid long syncs by simply supplying a trusted finalised state and starting lighthouse from this point.
Some of the issues needed to support this are:
Handling block history - A LH node that starts at an arbitrary point does not have the block history and cannot respond correctly to it's peers requests who wish to sync from points before that arbitrary start. The spec indicates that we must maintain blocks from the most recent weak subjectivity point or in the case of long periods of non finality
min(finalized_epoch, weak_subjectivity_point).One solution is to attempt to download blocks backwards, however this runs into issues with block verification (in its current form) as we cannot verify blocks in a "backwards fashion". A somewhat cleaner solution would be to only allow LH to start from weak subjectivity points which allows us to maintain our sync logic and sync forward to the current head. The drawback here is if the weak subjectivity period is the order of months, we must spend the time to sync and verify all the blocks to the current head.
Handling peers in sync that only partially support the full history - We need to enhance a peer handling in sync to support peers with only partial views of the chain. I'll make a separate issue for this once we have decided on how peers will identify themselves as having a partial view of the block history.
The text was updated successfully, but these errors were encountered: