Disallow genesis sync by default

[realbigsean]

Description

Since withdrawals are now enabled, genesis sync is less secure than checkpoint sync.

Additionally, in deneb there's more reason to disallow it, since finalization has no bearing on the availability of data, and we're required to check if data is available for all deneb blocks. So once we start pruning blobs, we can't validate blocks with blobs outside the prune window.

Proposal

Can be done generally and in it's own PR to unstable:

• Require an override flag to sync from genesis

Specific to deneb:

• When povided the gensis sync flag, consider blocks that are from outside the prune window available if they are finalized
• During checkpoint sync backfill, always consider blobs from prior to the provided checkpoint available regardless of whether the flag is provided

Relevant discussions:

ethereum/consensus-specs#3141
ethereum/consensus-specs#3169

[mrabino1]

if we do that, then shouldn't we default the checkpoint sync to a known (sigp) checkpoint server unless overriden by a flag to select a custom one? otherwise when launched, where will it start?

also this also starts to bring up checkpoint sync and backfill only until the last epoch that was finalized. not sure if we are tracking a PR for this.

[realbigsean]

if we do that, then shouldn't we default the checkpoint sync to a known (sigp) checkpoint server unless overriden by a flag to select a custom one? otherwise when launched, where will it start?

Although this would be more ergonomic, I don't think it'd be good for us to have a default like that because ~30% of the network using the same source isn't great. I also don't think client maintainers should have that much of an influence about what the canonical chain is. It'd be better if sigp is one of many checkpoint sources.

also this also starts to bring up checkpoint sync and backfill only until the last epoch that was finalized. not sure if we are tracking a PR for this.

The last release included a change to backfill only to the weak subjectivity checkpoint (most recent finalized would be too recent) #4082

[mrabino1]

I largely agree that leaving sigp as the default is less than ideal.. but then again so is starting lighthouse and having it fail (as it would neither have a default checkpoint sync..nor allowed to start from genesis... so which is worse? I am largely indifferent.. though I do lean toward a pool of community known checkpoint sync providers. (like 10 of them).. and then if no checkpoint source is provided.. then let lighthouse randomly pick one of the 10 then..

as for the weak subjectivity, curious why the most recently finalized is too recent.. academically speaking, to main the chain any history isnt needed older than finality... (of course ignoring that everyone did that then no one would keep the history back to genesis.. ).. but is there another reason? (this is largely a learning question on my end).. thx.

[realbigsean]

though I do lean toward a pool of community known checkpoint sync providers. (like 10 of them).. and then if no checkpoint source is provided.. then let lighthouse randomly pick one of the 10 then..

Something like this seems like a pretty good middle ground.. but there's also value in requiring node operators to intentionally configure the checkpoint because there is a trust assumption there, and if there were to be some sort of social-recovery-requiring event, node operators will need to know how to do this.

as for the weak subjectivity, curious why the most recently finalized is too recent.. academically speaking, to main the chain any history isnt needed older than finality... (of course ignoring that everyone did that then no one would keep the history back to genesis.. ).. but is there another reason? (this is largely a learning question on my end).. thx.

You can have conflicting finalization though, it just means a very large portion of the network has to be slashed, so in order to resolve which chain is "canonical" we need the weak subjectivity checkpoint.

[ethDreamer]

I agree we should have users be conscious about which checkpoint sync they use. A nice way to do this is just to print an error message pointing them here:

https://eth-clients.github.io/checkpoint-sync-endpoints/

[realbigsean]

implemented in #5038