Commit Graph

25 Commits

Author SHA1 Message Date
Etan Kissling 8bf801ecc6
Add `block_to_light_client_header` helper
Introduce `block_to_light_client_header` helper function to enable
future forks to override it with additional info (e.g., execution),
without having to change the general light client logic.

Likewise, update existing light client data creation flow to use
`block_to_light_client_header` and default-initialize empty fields.

Furthermore, generalize `create_update` helper to streamline test code
using `block_to_light_client_header`.

Note: In Altair spec, LC header is the same as `BeaconBlockHeader`.
however; future forks will extend it with more information.
2022-12-06 17:44:41 +01:00
Etan Kissling 0fb2447a95
Merge branch 'dev' into lc-blockfuncs 2022-11-19 12:20:18 +01:00
Michael Sproul 897b97990f
Further clarify light client slot checks 2022-11-11 22:09:33 +11:00
Michael Sproul dae1011194
Fix typos
Co-authored-by: Alex Stokes <r.alex.stokes@gmail.com>
2022-11-09 09:41:21 +11:00
Michael Sproul 91de8a09f3
Fix slot checks in light client p2p spec 2022-11-08 17:06:07 +11:00
Etan Kissling 08ff71688f
Merge branch 'dev' into lc-blockfuncs 2022-11-07 15:03:20 +01:00
Hsiao-Wei Wang 87dcb83827
Merge pull request #3063 from etan-status/lc-gossipdigests
Document how to derive fork context for LC gossip
2022-11-02 13:12:23 +08:00
Etan Kissling ff0e525ecc
Pass blocks to LC data creation functions
Future light client protocol extensions may include data from the block
in addition to data from the state, e.g., `ExecutionPayloadHeader`.
To prepare for this, also pass the block to the corresponding functions.
In practice, blocks access is easier than historic state access, meaning
there are no practical limitations due to this change.
2022-10-28 22:14:25 +02:00
Alex Stokes be3c774069
Merge pull request #3065 from etan-status/lc-branchrootdocs
Clarify where LC proofs are rooted
2022-10-28 08:51:26 -06: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
Etan Kissling af54c97a6c
Consistently use `compute_sync_committee_period_at_slot`
A few LC functions were not yet updated to use a more concise function
for computing sync committee period for a slot. Updating to that func.
2022-10-27 21:36:55 +02:00
Etan Kissling c399e11aa7
Document how to derive fork context for LC gossip
For LC gossip, the documentation did not specify what slot number to use
for deriving the gossip objects. This missing documentation is now added
to document using `attested_header.slot`.
2022-10-27 21:23:09 +02:00
Ben Guidarelli d70dcd9926
Fix link to beacon-chain doc 2022-09-15 10:21:06 -04:00
Etan Kissling 52a741f7c6
Improve grammar
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
2022-07-25 15:46:29 +02: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 8ced2c3ae1
Remove newlines between items for visual consistency 2022-07-22 17:46:07 +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