-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serve light client data #143
Comments
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. |
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. |
Thanks for checking on this! Hmm. Maybe it's possible to get away without disk? As in, just forwarding the Keep in mind that so far only Lodestar and Nimbus support the |
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 🙏 |
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. |
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: @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: |
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:
The following route would not be proxied at this time as it is more expensive and not strictly necessary for syncing: |
@samcm Would it be possible to get the four light client routes (without |
To enable users to start from an older block hash, light client data should be made available via Checkpointz.
--trusted-block-root
duringnimbus_beacon_node trustedNodeSync
to use LC api)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:
/eth/v1/beacon/light_client/bootstrap/{block_root}
- about 25 KB each/eth/v1/beacon/light_client/updates
- about 25 KB each/eth/v1/beacon/light_client/finality_update
- about 2 KBBonus APIs for full light client data availability:
/eth/v1/beacon/light_client/optimistic_update
- about 1 KBfinalized_update
response and omittingfinalized_header
andfinality_branch
in the response. This could work around client limitations when only a partial light client API is available on the server/eth/v1/events
light_client_finality_update
andlight_client_optimistic_update
finality_update
andoptimistic_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
.The text was updated successfully, but these errors were encountered: