Define endpoints for light client sync

[etan-status]

Introduces additional REST endpoints for light client sync, compatible with the libp2p specification defined in ethereum/consensus-specs: https://github.com/ethereum/consensus-specs/blob/v1.2.0-rc.3/specs/altair/light-client/p2p-interface.md

Endpoints are defined to be fork-aware to allow potential optimizations such as including EL block hash into BeaconBlockHeader in the future.

The getLightClientUpdatesByRange endpoint is a new kind of endpoint, as it introduces the concept of list responses. Each list item could potentially be of a different fork. Likewise, for the events stream, the fork may update between events. Both the list response and the event are additionall wrapped with a per-item version indicator in JSON. For SSZ, the list items are encoded as length/version/payload triples. Note that the events endpoint does not support the SSZ format.

This builds on prior work from:

• @dapplion at Add lightclient routes #181

The proof endpoint in that PR is out-of-scope here, but could be useful as part of the debug API as an eth_getProof equivalent for CL data.

[hujw77]

If beacon light client provide single_proof API would be great for solidity smart contract to verify beacon state easily.
https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md

def calculate_merkle_root(leaf: Bytes32, proof: Sequence[Bytes32], index: GeneralizedIndex) -> Root:
    assert len(proof) == get_generalized_index_length(index)
    for i, h in enumerate(proof):
        if get_generalized_index_bit(index, i):
            leaf = hash(h + leaf)
        else:
            leaf = hash(leaf + h)
    return leaf

[etan-status]

If beacon light client provide single_proof API would be great for solidity smart contract to verify beacon state easily.

Proofs are not specific to light clients, and should be introduced separately, e.g., as part of the /debug namespace that already provides a way to query state. #181 (comment)

They need a separate discussion as there are different possible designs regarding supported complexity and serialization formats. e.g., should it support querying "the last validator's balance" without knowing the number of validators / should it support querying multiple items at a time / should it support proofs for historic states.

For the popular use case of EL block hash to have end-to-end proof of eth_getProof, the EL block hash could simply be moved into BeaconBlockHeader from capella onwards. The libp2p, REST and portal specs are fork-aware for potential changes like that.

[dapplion]

Looks great!

[etan-status]

Implemented in Nimbus at status-im/nimbus-eth2#4213 with a v0 suffix

Sample endpoint:

• http://unstable.mainnet.beacon-api.nimbus.team

[dadepo]

Proofs are not specific to light clients, and should be introduced separately, e.g., as part of the /debug namespace that already provides a way to query state. #181 (comment)

Only thought on this is that to be useful for light client purposes, it should not be put under the /debug namespace (as this shouldn't be exposed publicly).

[dadepo]

LGTM. Aligns with already implemented routes in Lodestar:

• https://lodestar-mainnet.chainsafe.io/eth/v1/beacon/light_client/bootstrap/{block_root}
• https://lodestar-mainnet.chainsafe.io/eth/v1/beacon/light_client/finality_update/
• https://lodestar-mainnet.chainsafe.io/eth/v1/beacon/light_client/optimistic_update/
• https://lodestar-mainnet.chainsafe.io/eth/v1/beacon/light_client/updates/?start_period={period}&count={count}

[rolfyone]

LGTM. Raised teku ticket for prioritisation.

[rolfyone]

Looks like plenty of approval to merge this...