-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Open
Labels
Description
Must have
- Implement
is_better_update - Add Capella/Deneb changes from corresponding
full-node.mdspec 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
- Implement Restrict best LC update collection to canonical blocks ethereum/consensus-specs#3553
- spec tests (including Fulu, see Fulu general spectests #15682)
- Check out the gossip-spamming issue
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 underbeacon-chain/core. Let's create a new/beacon-chain/core/light-clientpackage and move such functions there. - Declare/use protos in
v1aplha1instead ofv1/v2 - Rename flag from
enable-lightclienttoenable-light-client - Add more solid unit tests to HTTP handlers, as commented here: [2/5] light client http api #12984 (comment)
- Use
t.Runin 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
nicopernas, syjn99, guha-rahul and Alleysira