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