Commit Graph

15 Commits

Author SHA1 Message Date
Etan Kissling b951ce077a
Move helper 2023-01-06 20:01:02 +01:00
Etan Kissling 5230c1ba87
Add `is_valid_light_client_header` and comments 2023-01-06 19:58:23 +01:00
Etan Kissling 5c64a2047a
Add `LightClientHeader` wrapper
In Altair, light client sync protocol exchanges `BeaconBlockHeader`
structures for tracking current progress. Wrapping `BeaconBlockHeader`
inside a `LightClientHeader` allows future extensions of this header,
e.g., to also track `ExecutionPayloadHeader`.

Note: This changes the JSON REST format by adding a `beacon` nesting.
For SSZ, the serialization format stays same (but overall root changes).
2023-01-05 13:36:04 +01:00
Etan Kissling 5b6eb8007a
Clarify where LC proofs are rooted
Add more detailed LC object documentation to explain that the various
merkle proofs are relative to the beacon block's state root.
Likewise, clarify that sync committees relate to the finalized header
(not to the optimistic header, which can be a period ahead).
2022-10-27 21:44:38 +02:00
Ben Guidarelli d70dcd9926
Fix link to beacon-chain doc 2022-09-15 10:21:06 -04:00
Etan Kissling 56363cd94a
Define libp2p protocol for light client sync
While the current Altair specs define structures to aid light client
development, one missing key aspect is the network protocol definition.

Certain implementations have started defining their own REST based APIs,
e.g., Lodestar at https://github.com/ChainSafe/lodestar/blob/master/packages/api/src/routes/lightclient.ts
While such APIs are useful, REST does not seem to be the ideomatic
choice as the sole API available at such a low level for Ethereum.

This patch introduces a libp2p based protocol to allow light clients to
sync to the latest `BeaconBlockHeader` in a trustless and decentralized
manner, building on top of prior work from:
- @hwwhww at https://github.com/ethereum/consensus-specs/pull/2267
- @jinfwhuang at https://github.com/ethereum/consensus-specs/pull/2786
- Lodestar's REST API (also has an endpoint to fetch merkle proofs!)
2022-07-22 17:56:41 +02:00
Etan Kissling 78d336e28d
Describe light client sync process
Provides documentation about the process that a light client may use to
sync a local `LightClientStore`.
2022-07-22 17:12:57 +02:00
Etan Kissling 8643e28f12
`try_...` --> `process_...` 2022-07-22 11:49:07 +02:00
Etan Kissling f9d866eb28
Manually trigger `LightClientStore` force updates
Replaces `process_slot_for_light_client_store` which force updates the
`LightClientStore` automatically based on `finalized_header` age with
`try_light_client_store_force_update` which may be manually called based
on use case dependent heuristics if light client sync appears stuck.
Not all use cases share the same risk profile.
2022-07-21 16:06:46 +02:00
Etan Kissling 95019bb9a9
Improve readability of intro text
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
2022-07-20 17:50:18 +02:00
Etan Kissling 06d9fd8cd3
Add `LightClient(Finality|Optimistic)Update`
Introduces reduced `LightClientUpdate` structures to allow keeping track
of the latest `finalized_header` and `optimistic_header`. This may also
help in scheduling the next query for a full `LightClientUpdate` once
sync committee finality has been reached.
2022-07-20 13:14:58 +02:00
Etan Kissling a126f22cd9
Sync tocs 2022-07-15 13:49:19 +02:00
Etan Kissling de15971ae8
Cleanups 2022-07-15 13:45:34 +02:00
Etan Kissling 88206117c6
Extract full node specifics to separate doc 2022-07-15 13:37:27 +02:00
Etan Kissling d06f44ef55
Move `sync-protocol.md` into `light-client` subdir 2022-07-15 13:22:14 +02:00