Beacon Light Client Network RPC endpoints

[acolytec3]

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 level beacon_sendFindContent

• beacon_getHead - returns the Light Client Header corresponding to the current LightClientOptimisticUpdate stored by the embedded CL light client
• beacon_getFinalized - returns the Light Client Header corresponding to the current LightClientFinalizedUpdate stored by the embedded CL light client
• beacon_getLightClientUpdate - accepts a prefixed hexadecimal number representation of a Sync Committee Period and returns the LightClientUpdate for that period if found

Non-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 hash

This 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

[acolytec3]

cc @ogenev @kdeme for your thoughts here

[ogenev]

I'm not sure if we need a beacon_ namespace, because we already have this concept of portal namespace + network name (aka portalbeacon...). I think the idea of a `portalnamespace is to distinguish explicitly by other endpoints from the Ethereum ecosystem likeeth_` for example.

[acolytec3]

I don't disagree. The only reason I thought of having a separate beacon namespace is that our portal_ namespace feels very dedicated to the fine grained endpoints that drive the Portal Network client as opposed to the sort of endpoints I'm proposing above which are more "userland" level, not requiring specific knowledge of Portal Network content keys and the like. Either way, happy to make whatever changes the group finds consensus on.

[kdeme]

So I was planning here to provided on one end, just the regular portal_beaconABCD type of calls, like we do for the other networks, and on the other end provide a partial implementation of the consensus layer REST API: calls such as /eth/v1/beacon/headers/{block_id}, /eth/v1/beacon/states/{state_id}/root and the ones for the light client objects such as /eth/v1/beacon/light_client/optimistic_update, etc.

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.

[acolytec3]

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

[acolytec3]

@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 LightClientUpdate, OptimisticUpdate, FinalityUpdate, and LightClientBootstrap

[acolytec3]

Now we have #331 as an idea to add a portal_finalizedStateRoot endpoint for the RPC so would be curious if there has been any further thoughts here. I'm good with not having a specialized beacon_... namespace so curious if people would rather go the route of using the beacon spec endpoint route for serving our beacon network content like @kdeme suggested here or how we should proceed? I don't have strong opinions beyond thinking we should agree upon endpoints that allow a consuming app to retrieve the data structures directly (so either use the existing beacon API routes or else some portal_* type endpoints.