-
Notifications
You must be signed in to change notification settings - Fork 81
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
Beacon Light Client Network RPC endpoints #241
Comments
I'm not sure if we need a |
I don't disagree. The only reason I thought of having a separate |
So I was planning here to provided on one end, just the regular But I haven't actually done this yet, so I'm not sure if there would be something missing that we cannot do with either of these. |
Interesting. Hadn't thought of the idea of using the beacon API routes. I kind of like that idea, especially since we're going to be exposing the historical roots object at some point |
@g11tech, do you have any thoughts here about beacon REST API endpoints that should be exposed by the portal network RPC? Note, we only have light client data structures within Portal Network so |
Now we have #331 as an idea to add a |
Based on some questions I received on Discord around how to use the various networks that Ultralight supports (and specifically what we could do with the beacon network), I started thinking about what might be some useful data to expose from the RPC as it related to the Beacon network.
Ultralight currently exposes the following endpoints that are related to the beacon network.
Under a new Beacon namespace (I imagine it to correspond to the
eth
namespace except it supplies the beacon data that Portal Network can serve in a relatively user friendly way as opposed to requiring the RPC consumer to construct content keys and use the lower levelbeacon_sendFindContent
beacon_getHead
- returns the Light Client Header corresponding to the currentLightClientOptimisticUpdate
stored by the embedded CL light clientbeacon_getFinalized
- returns the Light Client Header corresponding to the currentLightClientFinalizedUpdate
stored by the embedded CL light clientbeacon_getLightClientUpdate
- accepts a prefixed hexadecimal number representation of a Sync Committee Period and returns theLightClientUpdate
for that period if foundNon-standard utility endpoint exposed for convenience
portal_beaconStartLightClient
- equivalent to a CLI flag--trustedBlockRoot
that accepts a block root corresponding to a trusted checkpoint and then starts the embedded Lodestar light client using that hash as the bootstrap hashThis is just thoughts at this point as Ultralight needed some way to make this data available but something like above feels like a good starting point for making this data available (since it's not readily available through existing high level endpoints in the JSON-RPC) spec
The text was updated successfully, but these errors were encountered: