Light client specs checklist

[hwwhww]

• 1. Server discovery: How can light clients find servers efficiently?
• 2. Find LightClientSnapshot initially: as @djrtwo mentioned, Req/Resp may not be good snapshot resource.
  • [Proposal] Can we say, we expect 3rd party to provide LightClientSnapshot + Merkle proofs or multi-proof of each field, where the proof can be verified against WS source?
• 3. Block tree verification in current time-out procedure and reorg: In the current spec, a timeout-triggered (8192 slots, ~27 hours ) update logic exists:
  • Step 1, on_light_client_update, light client appends the valid update
  • Step 2, when timeout, call apply_light_client_update to update the store snapshot with the most voted update from store.valid_updates.
  • [Proposal]: In step 1, for the non-finality update (update.finality_header == BeaconBlockHeader()), should we add assert of checking if the update.header is descendant of snapshot.header. (<-- as @vbuterin suggested, make the light client updates always rooted in a finalized block.)
    • This procedure assumes that the light client already has store.valid_updates before timeout. That is, at the timeout slot, either (i) the server has to send a chain of updates to the light clients, or (ii) the light client has to request for the updates.
  • Or apply other reorgable light client solutions? (Light client reorg mechanism #2182)
• 4. Use gossip as default sync resource and then servers just as backup?
  • Note: the size of LightClientUpdate object:
    • header: 200
    • next_sync_committee: about 48*1024 + 48*16 = 49920
    • next_sync_committee_branch: about 32*5 = 160
    • finality_header: 200
    • finality_branch: about 32*6 = 192
    • sync_aggregate: about 1024 + 96 = 1120
    • fork_version: 4
    • Total: ~51,796 bytes
  • Edited: @vbuterin suggested making light client only download 256 members from sync committee instead of 1024
  • Updated: SYNC_COMMITTEE_SIZE has been updated to 512 via Adjust sync committee size and duration #2371
• 5. More comprehensive/production client-server model
  • @protolambda: If this is a push-update, and there is no explicit subscription kind of approach for a light client, then we should spec out when and how often the server pushes the update.

Other questions:

• EPOCHS_PER_SYNC_COMMITTEE_PERIOD is 2**8 epochs = 2**13 slots ~= 27 hours. LIGHT_CLIENT_UPDATE_TIMEOUT is also 2**13 slots ~= 27 hours.
  1. Should we just keep one constant?
  2. If not, is EPOCHS_PER_SYNC_COMMITTEE_PERIOD >= LIGHT_CLIENT_UPDATE_TIMEOUT an invariant?
  • Updated: LIGHT_CLIENT_UPDATE_TIMEOUT has been removed via Updates to Altair light client sync protocol #2378