Open arnetheduck opened 2 years ago
TODO:
head
but head
is newer than WS point: trust checkpoint or own head? (probably the latter)head
is older than WS point: who do we trust more?For those looking for behavior similar to checkpoint sync in other clients:
# Run TNS when database is missing, skipping the backfill
[ -f "$DATADIR/db/nbc.sqlite3" ] || build/nimbus_beacon_node --data-dir:"$DATADIR" trustedNodeSync --backfill:false
# now run beacon node as normal..
build/nimbus_beacon_node ...
This would be nice!
Yes, huge +1 on this. I'm new to the ETH staking community, and this particular UX discomfort was a big negative of Nimbus compared to others (Lighthouse, Teku, I think Prysm has it or something like it too?)
Just ran into this after my disk filled up. Especially with Docker images and volumes to fuss around with, a flag is nicer than a separate command.
https://nimbus.guide/start-syncing.html#checkpoint-sync
You can use --external-beacon-api-url
with --trusted-state-root
to sync from Checkpointz on main command. DB dir has to be empty though.
--trusted-block-root
doesn't work currently with checkpointz, as it needs LC data to be served. Tracking issue: https://github.com/ethpandaops/checkpointz/issues/143
Only --trusted-state-root
works for now.
Thanks @etan-status, I will use that next time!
Curious to try --trusted-block-root
with Lighthouse's LC data server too.
Are there any plans to support checkpoint sync without specifying a block root/state root ahead of time? I think it could still be slightly more ergonomic, as it wouldn't require editing .service
files, or deployment scripts or similar. Instead the user could check the logs after syncing to ensure they're on the right chain. I'm aware lots of users do not check, so if you want to require them to check the block root, I think the mandatory block root/state root flag is a good middle ground.
Yes, with EIP-7658 it would be possible to bake in a deeply finalized block root into the network metadata and start syncing from there. With light client data being backfillable, its availability on the network would improve, and when full data from the deeply finalized block to a recent one is available, syncing can be performed automatically.
Operation based on a trusted server requires the additional trustedNodeSync
step on Nimbus. The main startup command only supports secure sync with an explicit (not "finalized") --trusted-block-root
(can be an older checkpoint, but requires server to serve LC data; or alternatively with an explicit --trusted-state-root
(has to be a recent checkpoint, but also works with checkpointz). For testnets with post-altair genesis, it also works without any root, as long as the server supports LC data.
EIP-7658 is in this PR: https://github.com/ethereum/consensus-specs/pull/3614
@michaelsproul re Lighthouse LC data server, would be great to get feedback on https://github.com/ethpandaops/checkpointz/issues/143 whether it is acceptable to proxy the LC related routes for you as well. Nimbus/Lodestar are fine with it.
--trusted-node-url
and--backfill
as command line arguments to the normalnimbus_beacon_node
command (i.e. "no action"), and include them if the user specified that they would like to checkpoint sync. I would then set--trusted-node-url
to whatever they specified, and--backfill
to false so Nimbus pulls the historical blocks from gossip once checkpoint syncing has completed.trustedNodeSync
action, I have to manually determine whether or not Nimbus has sync'd before starting it up, and whether or not to start with the special action first and then restart into the conventional mode after. I'd strongly suggest removing the explicit action and building support for this into the "no action" mode so the client itself can make this determination and behave accordingly.Originally posted by @jclapis in https://github.com/status-im/nimbus-eth2/issues/3209#issuecomment-1003598851