Skip to content

Light Client Support #12991

@rkapka

Description

@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.

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.

Nice to have

  • Change the sync committee requirement for finalized update from 2/3 of all members to MIN_SYNC_COMMITTEE_PARTICIPANTS
  • 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

Metadata

Metadata

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions