Checkpoint sync

Consensus clients support syncing from a recent finalized checkpoint. This is substantially faster than syncing from genesis, while still providing all the same features. For more details on this feature see Lighthouse's documentation.

slingnode.ethereum role enables checkpoint sync by default using one of the community maintained endpoints.

Variables

Checkpoint sync can be disabled by setting the consensus_checkpoint_sync_enabled to false.

The checkpoint endpoint defaults to Goerli (the same as the network). If you want to use checkpoint sync the on network other than Goerli, you will need to set the consensus_checkpoint_sync_url variable to the desired endpoint (public or private).

The variables are common for all clients, and are defined in 'defaults/main/main.yml'.

consensus_checkpoint_sync_enabled: true
consensus_checkpoint_sync_url: https://sync-goerli.beaconcha.in

Client support

Technically, all clients support checkpoint sync however when using slingnode.ethereum with Nimbus this is feature is not currently available. This is due to the way Nimbus implements the checkpoint sync (it requires starting and restarting the client with different flags which is cumbersome to implement cleanly in Docker and Ansible). The table below shows support matrix and links to the client specific documentation for reference.

Client	Available using the role	Official docs
Lighthouse	yes	https://lighthouse-book.sigmaprime.io/checkpoint-sync.html
Prysm	yes	https://docs.prylabs.network/docs/prysm-usage/checkpoint-sync
Teku	yes	https://docs.teku.consensys.net/HowTo/Get-Started/Checkpoint-Start/
Nimbus	no	https://nimbus.guide/trusted-node-sync.html
Lodestar	yes	https://chainsafe.github.io/lodestar/usage/beacon-management/#checkpoint-sync

Public endpoint availability

It happens that the public endpoints are temporarily unavailable. If that is the case the client will fail to start. If the consensus client fails to start during the initial deployment, this may be the reason. To verify if that is the case, either check the logs in your log analytics solution or login to the server you are deploying to and check container logs.

sudo docker logs --follow consensus

The exact error message depends on the client.

Lighthouse

{"msg":"Remote BN does not support EIP-4881 fast deposit sync","level":"WARN","ts":"2023-03-15T11:04:03.933663777Z","service":"beacon"}
{"msg":"Failed to start beacon node","level":"CRIT","ts":"2023-03-15T11:04:04.054012397Z","reason":"Finalized block missing from remote, it returned 404"}

Prysm

could not load genesis from file: Error retrieving genesis state from https://example.com/: error requesting state by id = genesis: code=404, url=https://example.com/eth/v2/debug/beacon/states/genesis, body=response body:

Teku

2023-03-15 11:06:18.011 FATAL - Failed to load initial state from both https://example.com/ and https://example.com/eth/v2/debug/beacon/states/finalized : Invalid SSZ: trying to read more bytes than available

Lodestar

Jul-07 11:05:26.209[] info: Fetching checkpoint state checkpointSyncUrl=https://example.com
 ✖ Error: Unable to fetch weak subjectivity state: Not Found:
    at fetchWeakSubjectivityState (file:///usr/app/packages/cli/src/networks/index.ts:175:11)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at fetchWSStateFromBeaconApi (file:///usr/app/packages/cli/src/cmds/beacon/initBeaconState.ts:199:35)
    at Object.beaconHandler [as handler] (file:///usr/app/packages/cli/src/cmds/beacon/handler.ts:66:41)