Add /eth/v1/beacon/light_client/* to BeaconAPI

[DragonDev1906]

🚀 Feature Request

Description

Since Beacon-API version v2.4.0, the Beacon-API specs contain 4 endpoints that are extremely useful for light clients or anything else that does not want to or cannot fully trust the full node (consensus + execution).

Since I've stumbled onto the fact that Prysm doesn't have these api methods, yet, need them for a project and would prefer not to have to use the p2p networking protocol for that, I'd like to propose adding these to the Beacon-API. This has the extra benefit of helping the light client ecosystem, which would be useful for more decentralized wallet applications.

MetaMask, for example, could use the standardized Beacon-API to update its light client (taking only a few seconds if really outdated) and then can verify everything it needs by asking the execution-layer node for merkle proofs. A powerfull ability but not really useful of they're not supported by the most commonly used beacon-chain nodes.

Getting the data for these endpoints shouldn't be too difficult, as it is used for other things, too. The biggest difficulty could be adding /eth/v1/beacon/light_client/updates if infromation about the sync committees and their signatures are pruned (though they might still be necessary for the p2p protocol, I don't know if Prysm has support for light clients on the p2p network.

Describe the solution you'd like

Addition of the following Beacon-API endpoints:

• /eth/v1/beacon/light_client/bootstrap/{block_root} for bootstrapping
• /eth/v1/beacon/light_client/updates for getting historic sync committee changes (I assume prism doesn't prune these)
• /eth/v1/beacon/light_client/finality_update for getting necessary information to stay at the head of the (finalized) chain

Allowing SSZ encoding for those endpoints, as whoever wants to use the data likely wants it to be compact and requires knowledge about forks, the consensus and the relevant types anyways. The JSON encoding is far less compact, but it could be useful to provide both encodings.

Optionally:

• /eth/v1/beacon/light_client/optimistic_update for getting more up-to-date information that may not be finalized, yet
• Events for light_client_finality_update and light_client_optimistic_update for easy access to the newest data

Describe alternatives you've considered

As of now I see the following workarounds:

• Use a different Beacon-Chain node implementation (and re-sync that one, at the moment the only node that supports light clients over the API, that I know of, is Nimbus)
• Hack together a list of calls to get the data in multiple calls (far from ideal, especially because they're standardized methods, not sure if possible without getting all blocks)
• Maybe use the p2p networking (if supported), but that's not as easy to use as the REST API.

[james-prysm]

we are not prioritizing this yet , there's been a stale PR opened to attempt to address but we have a few other focus areas before returning to it #11815

[rkapka]

Closing in favor of #12991