Light Client Support - Githubissues

NOTE: This should be done after all code from https://github.com/prysmaticlabs/prysm/pull/12854 is merged.

[x] Implement is_better_update
[x] Add Capella/Deneb changes from corresponding full-node.md spec files
[ ] Add SSZ support for Beacon API endpoints
[ ] Store light client updates in the database (possibly one update per period, but we have to take into account the following:

Also keep in mind, that there may be networks where the sync committee period boundary does not align with the fork schedule, so the database should be flexible enough to support that.
[ ] Update the https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Beacon/getLightClientUpdatesByRange endpoint to return values from the database
[x] Review the two other endpoints to make sure they return correct data and have good performance
[ ] Implement the p2p spec: https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md (and update it for Capella/Deneb)
[ ] Verify light client support in the event stream endpoint works correctly: https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Events/eventstream (it was implemented by the previous contributor)
[x] Stateless function that do not use the blockchain service, such as the ones in /beacon-chain/blockchain/lightclient.go, should be placed under beacon-chain/core. Let's create a new /beacon-chain/core/light-client package and move such functions there.
[ ] Add more solid unit tests to HTTP handlers, as commented here: https://github.com/prysmaticlabs/prysm/pull/12984#discussion_r1347569661
[ ] Make sure we follow this part of the spec:
Full nodes SHOULD provide the best derivable LightClientUpdate (according to is_better_update) for each sync committee period covering any epochs in range [max(ALTAIR_FORK_EPOCH, current_epoch - MIN_EPOCHS_FOR_BLOCK_REQUESTS), current_epoch] where current_epoch is defined by the current wall-clock time. Full nodes MAY also provide LightClientUpdate for other sync committee periods.
- LightClientUpdate are assigned to sync committee periods based on their attested_header.beacon.slot
- LightClientUpdate are only considered if compute_sync_committee_period_at_slot(update.attested_header.beacon.slot) == compute_sync_committee_period_at_slot(update.signature_slot)
- Only LightClientUpdate with next_sync_committee as selected by fork choice are provided, regardless of ranking by is_better_update. To uniquely identify a non-finalized sync committee fork, all of period, current_sync_committee and next_sync_committee need to be incorporated, as sync committees may reappear over time.
[x] Resolve https://github.com/prysmaticlabs/prysm/issues/14206
[ ] Implement https://github.com/ethereum/consensus-specs/pull/3553
[ ] Declare/use protos in v1aplha1 instead of v1/v2
[ ] sendLightClientFinalityUpdate and sendLightClientOptimisticUpdate should only send updates when the block is suitable
[ ] Profile the node to assert that enabling light client support does not consume excessive memory/CPU/bandwidth
[ ] Do a final pass and look for code health improvements
[ ] Add light client to e2e/Kurtosis (?)

prysmaticlabs / prysm

Light Client Support #12991