Serve light client data

[etan-status]

To enable users to start from an older block hash, light client data should be made available via Checkpointz.

• Light client sync protocol: https://github.com/ethereum/beacon-APIs/tree/master/apis/beacon/light_client
• Nimbus server documentation: https://nimbus.guide/light-client-data.html
• Nimbus example client: https://nimbus.guide/trusted-node-sync.html#verify-the-downloaded-state-through-the-nimbus-light-client (pass --trusted-block-root during nimbus_beacon_node trustedNodeSync to use LC api)
• Explanation video: https://www.youtube.com/watch?v=ZHNrAXf3RDE

The light client sync protocol allows to take a very old block root, and transform it into a recent one, without requiring the user to manually copy/paste checkpoint block roots around.

This is more secure than genesis sync, and also more secure than downloading a random finalized state from a third party without validation.

Required APIs that Checkpointz would have to cache and serve:

1. /eth/v1/beacon/light_client/bootstrap/{block_root} - about 25 KB each
   • Has to be cached for each finalized checkpoint, including ones in the past. Should persist these for a really long time (months), these don't expire.
2. /eth/v1/beacon/light_client/updates - about 25 KB each
   • This is a range query with start+count. Historical entries (older than 256 epochs) don't change. The latest entry may rarely change. It is good enough to only cache and make available historical entries (without the most recent one). Should persist these for a really long time (months), these don't expire.
   • Different clients may request different ranges of the data, and the cache should be prepared for that; e.g., cache each period separately so that requests from 20-40 and 15-35 can be served from the same database without requiring separate caches for each possible range.
3. /eth/v1/beacon/light_client/finality_update - about 2 KB
   • This changes each time new finalized checkpoint block is reached. Can expire the cache every epoch (or every time finality changes), and only need to keep the most recent one around for this.

Bonus APIs for full light client data availability:

4. /eth/v1/beacon/light_client/optimistic_update - about 1 KB
   • Changes every slot; not essential for checkpoint syncing but is a nice to have for light client syncing (e.g., web browser wallets).
   • Could be faked by using the finalized_update response and omitting finalized_header and finality_branch in the response. This could work around client limitations when only a partial light client API is available on the server
5. /eth/v1/events
   • light_client_finality_update and light_client_optimistic_update
   • Push mechanism for finality_update and optimistic_update. Don't think checkpointz is used for that, but if eventstream is supported, would be great to also have access to these two topics. They provide the same data as /eth/v1/beacon/light_client/finality_update and /eth/v1/beacon/light_client/optimistic_update.

[etan-status]

Example here based on Nimbus. The server here serves the light client data that this issue proposes should be added to checkpointz. That enables a secure sync experience without having to manually pass any block root or state root. The extra endpoints allow the server to proof that what it is sending as the checkpoint state is not malicious. That allows reducing the trust assumption on the server to simple data availability.

[samcm]

The main blocker for implementing this is that checkpointz doesn't store anything on disk, and is currently fairly light to run. Keen to investigate this.

[etan-status]

Thanks for checking on this!

Hmm. Maybe it's possible to get away without disk? As in, just forwarding the /light_client endpoints to the backing beacon node transparently (without the /eth/v1/events endpoint). If necessary some rate limiting could be added in front of it.

Keep in mind that so far only Lodestar and Nimbus support the /light_client endpoint.

[samcm]

Yup acting as a proxy is certainly an option! Might make sense to check with current providers if that risk is acceptable, the security/load concerns are entirely restricted to Checkpointz atm 🙏

[philknows]

Only able to speak for the ChainSafe checkpoints here, but we'd be happy to try this out and keep an eye on our resource utilization change by enabling this as a proxy to our public nodes. If this feature is kept optional, maybe providers can just choose to enable if the endpoints are available depending on what clients they're running.

[etan-status]

Another aspect to keep in mind is that the BN node behind the checkpointz server should ideally be genesis synced. Light client data cannot be reliably backfilled until the corresponding protocols are in place:

• Enable light client data backfill by tracking best SyncAggregate ethereum/consensus-specs#3614

@philknows would be great if your public nodes have old data available! Also, there's a move to collect canonical data that is deterministic across the backing BN, which simplifies syncing in the future (includes test cases). This way, swapping the backing BN should not result in different data being served:

• Restrict best LC update collection to canonical blocks ethereum/consensus-specs#3553

[etan-status]

Might make sense to check with current providers if that risk is acceptable

With both Nimbus and Lodestar deeming it fine regarding the load of simply exposing the routes as a transparent proxy, I think it's worth giving this a shot.

Namely, the following routes should be proxied:

• /eth/v1/beacon/light_client/bootstrap/{block_root}
• /eth/v1/beacon/light_client/updates
• /eth/v1/beacon/light_client/finality_update
• /eth/v1/beacon/light_client/optimistic_update (optional, but not heavy)

The following route would not be proxied at this time as it is more expensive and not strictly necessary for syncing:

• /eth/v1/events

[etan-status]

@samcm Would it be possible to get the four light client routes (without events) exposed? Extra server load for this is minimal.