Light Client Support

[rkapka]

Must have

• Implement is_better_update
• 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
• 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)
• 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.

• Resolve Some places return an epoch where a sync committee period is expected instead #14206
• Conditionally check for light client flag where appropriate to not process light client data without the flag
• Only process finality updates on a new finalized checkpoint instead of for every block

Nice to have

• Change the sync committee requirement for finalized update from 2/3 of all members to MIN_SYNC_COMMITTEE_PARTICIPANTS
• Implement Restrict best LC update collection to canonical blocks ethereum/consensus-specs#3553
• Profile the node to assert that enabling light client support does not consume excessive memory/CPU/bandwidth
• Add light client to e2e/Kurtosis

Fixes

• Beacon API handler to retrieve updates by range has lots of unnecessary code calculating periods etc

Cosmetic

• 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.
• Declare/use protos in v1aplha1 instead of v1/v2
• Rename flag from enable-lightclient to enable-light-client
• Add more solid unit tests to HTTP handlers, as commented here: [2/5] light client http api #12984 (comment)
• Use t.Run in HTTP handler tests and reduce duplication (for example, save updates to the DB once instead of for every test)
• Go through all light client code and see if all functions have appropriate tests.
• Circular imports that cause duplication in tests: LC Updates by Range to read from DB #14531 (comment) and LC Updates by Range to read from DB #14531 (comment)
• Do a final pass and look for code health improvements

Other

• Analyze https://discord.com/channels/595666850260713488/595701319793377299/1078345359643918396
• Think about DB storage optimization. Reference: https://discord.com/channels/476244492043812875/1250034167945760868/1300810377420079136