feat(json-rpc): add portal_beaconFinalizedStateRoot JSON-RPC endpoint

[ogenev]

A propose to add the portal_beaconFinalizedStateRoot endpoint to beacon JSON-RPC specs.

We already use this endpoint in Trin and it will be useful in hive when testing if a node keeps up with the finalized head.

[acolytec3]

Did we ever decide whether we were going to add full-featured endpoints for beacon network stuff? I know @kdeme mentioned supporting a subset of the actual beacon endpoints specific to what we could return from Portal (e.g. /eth/v1/beacon/light_client/finality_update being the most relevant one here). I'd rather just return the whole finality_update as opposed to just the stateRoot.

[ogenev]

Did we ever decide whether we were going to add full-featured endpoints for beacon network stuff? I know @kdeme mentioned supporting a subset of the actual beacon endpoints specific to what we could return from Portal (e.g. /eth/v1/beacon/light_client/finality_update being the most relevant one here). I'd rather just return the whole finality_update as opposed to just the stateRoot.

Yeah, I was also thinking about this. We need to decide on the public-facing endpoints, probably returning full optimistic and finality updates makes sense for users and hive testing.

For Trin's internals, we will use endpoints that return only the roots, but this is of course client specifics and any client is free to implement whatever endpoints they want as long as the "official" endpoints are implemented too.

[kdeme]

Yeah, I was also thinking about this. We need to decide on the public-facing endpoints, probably returning full optimistic and finality updates makes sense for users and hive testing.

Well, in the beacon API there is also /eth/v1/beacon/states/{state_id}/root.

We can add these portal json rpc versions, but I will definitely add the Beacon REST API versions, as these would be the ones that applications that are build on top of a beacon node will be familiar with.