search

Consensys / teku

Open-source Ethereum consensus client written in Java
https://consensys.io/teku
Apache License 2.0
674 stars 283 forks source link

Make it the default to not sync from Genesis #5930

Closed benjaminion closed 12 months ago

benjaminion commented 2 years ago

A weird anti-pattern is that a new Teku installation defaults to syncing from Genesis although we strongly recommend against doing this and encourage people to use checkpoint sync instead.

This is really a conversation starter about how we might go about changing this. Easiest may be to simply to "bake in" a recent checkpoint with releases. In a sense this is what we do with the Genesis file, though post-genesis checkpoints are more controversial. Alternatively, find a set of "trusted" state providers and point --initial-state to one of them, perhaps after verifying that they all agree. For the naive user, this get them up and running quickly, and as safely as syncing from Genesis; the sophisticated user can override this to choose their own provider.

There is a wider conversation going on about how to verify checkpoint states and we should be sure to work in concert with that as it evolves.

ajsutton commented 2 years ago

We could just refuse to sync from a state outside the weak subjectivity period by default and then have a flag to allow it. That will act as a prompt for users to actually source a suitable initial state without us having to bake something in and keep it up to date.

rolfyone commented 1 year ago

This shouldn't be too bad. Currently we specify the finalized state for initial-state for holesky, we could do the same for other networks if we similarly reference checkpoints urls...

As a starting point its probably worth understanding if the networks we support have public checkpoints endpoints we can consume...

zilm13 commented 1 year ago

We could do it same way we gather DepositTreeSnapshot - consuming it from our own test servers, but I have concerns about whole concept of bundling checkpoints. In case of DepositTreeSnapshot if we bundle bad thing, the node will just stuck on sync and couldn't ever propose, even eclipsed . Bundled snapshots on the other side allows some type of attacks probably (say, multi-stage eclipse if someone got access to our repo, needs some in-depth analysis to be sure). I like Adrian's proposal, say, --force-weak-subjectivity-sync. And better user message on exit without flag provided.