feat: add debug_getHistoricalSummaries endpoint

[acolytec3]

Motivation

The Portal Network needs a way to access the HistoricalSummaries property on the BeaconState for post Capella beacon state since the HistoricalSummaries are used to anchor EL block header proofs to the beacon state roots in light client updates that the serve as the source of truth for verifying the authenticity of post capella EL block headers. This currently requires downloading the entire Beacon State from a beacon node willing to serve the debug endpoints and then throwing away everything except for the desired data (or else downloading an ERA file from a willing endpoint). It is desirable to be able to access this data more efficiently directly from beacon nodes.

Description

This adds a new getHistoricalSummaries endpoint to the debug namespace on the REST API that serves the HistoricalSummaries field from the current head BeaconState as SSZ bytes. We only need the most current one for use in constructing proofs of recent EL block headers embedded in a beacon block.

This mirrors similar experimental work being done in the nimbus client

Steps to test or reproduce

git checkout historicalSummaries-endpoint
./lodestar beacon \
--rest.namespace='*' \
--checkpointSyncUrl=https://beaconstate.info \

In a separate terminal

curl -X GET --header "Accept: application/octet-stream" "http://127.0.0.1:9596/eth/v1/debug/historical_summaries" > ./hs.ssz

Then, use a script like below to verify that historical summaries are correctly returned

    import { ssz } from '@lodestar/types'

    const summariesBytes = fs.readFileSync('./test/util/hs.ssz')
    const summaries = ssz.capella.BeaconState.fields.historicalSummaries.deserialize(summariesBytes)
    console.log(summaries)

[CLAassistant]

All committers have signed the CLA.

[nflaig]

If this endpoint is useful for Portal it makes sense to standardize it on the beacon-api or at least get rough consensus there

if we wanna add a non-standardized api we should rather go with v0 or add to lodestar namespace instead of debug

[acolytec3]

Fair point and this is early days still. I looked at the Nimbus PR again and it looks like they moved it under a client specific namespace so maybe I should mirror this on the lodestar side for now?

[nflaig]

Yeah, it would be better to move the api there but I am also fine with v0, although it's not clear if this should be in debug or beacon namespace

[acolytec3]

Understood. I've switched to v0 for the moment. I chatted @deme who's working on the Nimbus equivalent and he's hoping to get a PR for the consensus specs to further general conversation there sometime soon.

[nflaig]

any reason why this shouldn't also support JSON?

[acolytec3]

No specific reason other than it's most useful for portal clients to download the ssz encoded variant as it requires less work to integrate it into our own work. Will add a JSON option as well.

[nflaig]

Generally we support both return formats and the client decides based on Accept header, if header is not present we default to JSON

[g11tech]

lgtm, we can always move the endpoint once we have it in beacon apis, CI running

[nflaig]

imo hard coding this to head is not great, we should probably align this with other apis which take a state_id parameter

[g11tech]

correct, stateid in the route and corresponding change here makes sense