35ca086269
## Limit Backfill Sync This PR transitions Lighthouse from syncing all the way back to genesis to only syncing back to the weak subjectivity point (~ 5 months) when syncing via a checkpoint sync. There are a number of important points to note with this PR: - Firstly and most importantly, this PR fundamentally shifts the default security guarantees of checkpoint syncing in Lighthouse. Prior to this PR, Lighthouse could verify the checkpoint of any given chain by ensuring the chain eventually terminates at the corresponding genesis. This guarantee can still be employed via the new CLI flag --genesis-backfill which will prompt lighthouse to the old behaviour of downloading all blocks back to genesis. The new behaviour only checks the proposer signatures for the last 5 months of blocks but cannot guarantee the chain matches the genesis chain. - I have not modified any of the peer scoring or RPC responses. Clients syncing from gensis, will downscore new Lighthouse peers that do not possess blocks prior to the WSP. This is by design, as Lighthouse nodes of this form, need a mechanism to sort through peers in order to find useful peers in order to complete their genesis sync. We therefore do not discriminate between empty/error responses for blocks prior or post the local WSP. If we request a block that a peer does not posses, then fundamentally that peer is less useful to us than other peers. - This will make a radical shift in that the majority of nodes will no longer store the full history of the chain. In the future we could add a pruning mechanism to remove old blocks from the db also. Co-authored-by: Paul Hauner <paul@paulhauner.com> |
||
|---|---|---|
| .. | ||
| beacon_chain | ||
| builder_client | ||
| client | ||
| eth1 | ||
| execution_layer | ||
| genesis | ||
| http_api | ||
| http_metrics | ||
| lighthouse_network | ||
| network | ||
| operation_pool | ||
| src | ||
| store | ||
| tests | ||
| timer | ||
| Cargo.toml | ||