[WIP] Light client protocol + Req/Resp interaction by hwwhww · Pull Request #2267 · ethereum/consensus-specs

hwwhww · 2021-03-23T14:20:26Z

WIP!!!

New and moved files

specs/altair/light-client/sync-protocol.md
specs/altair/light-client/p2p-interface.md

hwwhww · 2021-04-05T15:47:13Z

tests/core/pyspec/eth2spec/utils/ssz/ssz_impl.py

    return obj.copy()
+
+
+def build_proof(anchor, leaf_index):


note: it's for the incoming get_light_client_update helper

protolambda · 2021-04-05T16:13:35Z

specs/altair/light-client/p2p-interface.md

+)
+```
+
+No Response Content.


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.

Which begs the question -- can we have this by default on gossip?

Even so, I would suspect we need req/resp as backup, but as for the req/resp backup, I would suspect this might need to be pull and have some sort of payload for the request. If my lightclient has been offline for a day, I need to be able to make specific requests to catchup to the head and can't rely entirely on head updates because I'm not yet there

Relying on LightClientUpdate data structure to update a lightclient head is very wasteful since it only need to get the next_sync_committee pubkeys once every 256 epochs. To be honest the LightClientUpdate data structure works fine in a spec but it's not great in practice. The process of syncing can be split into two steps:

Get the pubkeys of the current sync committee. Use req/resp on demand to query LightClientUpdate(s)

Get latest SyncAggregate + header. More optimal to be gossiped once or more per slot.

However, gossiping SyncAggregate has an issue of how to decide which messages to accept and ignore. There are many combinations of the same signatures that results in different SyncAggregate objects (i.e. #2183).

djrtwo

A general comments and questions to start

specs/altair/light-client/README.md

djrtwo · 2021-04-05T18:56:02Z

specs/altair/light-client/p2p-interface.md

+
+#### GetLightClientSnapshot
+
+**Protocol ID:** `/eth2/beacon_chain/req/get_light_client_snapshot/1/`


I'm not certain that this needs to be on the req/resp protocol. Essentially, LightClientSnapshot is something kept locally. A light client starts with some snapshot and then uses iterative LightClientUpdates to transition their local snapshot

Right, Req/Resp was the simplest way to get a snapshot for MVP.

Alternatively, what do you think about saying that we expect 3rd party to provide LightClientSnapshot + Merkle proofs or multi-proof of each field, where the proof can be verified against WS source?

Alternatively, what do you think about saying that we expect 3rd party to provide LightClientSnapshot + Merkle proofs or multi-proof of each field, where the proof can be verified against WS source?

Agree 👍

djrtwo · 2021-04-05T18:56:43Z

specs/altair/light-client/p2p-interface.md

+)
+```
+
+No Response Content.


Which begs the question -- can we have this by default on gossip?

Even so, I would suspect we need req/resp as backup, but as for the req/resp backup, I would suspect this might need to be pull and have some sort of payload for the request. If my lightclient has been offline for a day, I need to be able to make specific requests to catchup to the head and can't rely entirely on head updates because I'm not yet there

djrtwo · 2021-04-05T18:59:57Z

specs/altair/light-client/sync-protocol.md

+
+## Sync protocol
+
+Note that in this syncing mechanism, the server is trusted.


Why do you say the server is trusted?

The proofs make this trustless from a safety standpoint (assuming no sync committee corruption)

djrtwo · 2021-04-05T19:00:41Z

specs/altair/light-client/sync-protocol.md

+### Initialization
+
+1. The client sends [`Status` message](./../../phase0/p2p-interface.md#status) to the server to exchange the status information.
+2. Instead of sending [`BeaconBlocksByRange` request](./../../phase0/p2p-interface.md#beaconblocksbyrange) in the beacon chain syncing, the client sends [`GetLightClientSnapshot` request](./p2p-interface.md#getlightclientsnapshot) to the server.


So a light client must not just trust the server for a good snapshot. They must instead start from a known safe place and transition trustlessly from there

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>

dapplion · 2021-12-05T09:31:39Z

specs/altair/light-client/sync-protocol.md

-    sync_committee_signature: BLSSignature
+    sync_aggregate: SyncAggregate
    # Fork version for the aggregate signature
    fork_version: Version


I believe almost all consumers of this data structure can compute the fork_version on their own. The only scenario where it could make sense is in LC embedded in blockchains, but even then you can input fork info in other ways.

dapplion · 2021-12-05T10:34:27Z

specs/altair/light-client/p2p-interface.md

+)
+```
+
+The `LightClientSnapshot` SSZ container defined in [light client sync protocol](./sync-protocol.md#lightclientsnapshot).


To initialize a lightclient you don't need the next_sync_committee, but only the current_sync_committee. You can get the next via syncing.

hwwhww added 2 commits March 23, 2021 22:13

Move sync-protocol.md -> light-client/sync-protocol.md

7dd59ce

Move light client tests

dab2f6a

hwwhww added the lightclients label Mar 23, 2021

WIP

729ccf2

hwwhww force-pushed the light-client-docs branch from 185f20d to 729ccf2 Compare March 23, 2021 14:21

hwwhww changed the title ~~[WIP] Light client protocol~~ [WIP] Light client protocol + Req/Resp interaction Mar 23, 2021

hwwhww added 3 commits April 5, 2021 20:07

Merge branch 'dev' into light-client-docs

1691b32

Update docs

8206ede

Update docs

43f4fe1

hwwhww commented Apr 5, 2021

View reviewed changes

hwwhww marked this pull request as ready for review April 5, 2021 16:15

protolambda reviewed Apr 5, 2021

View reviewed changes

hwwhww added 2 commits April 6, 2021 00:52

Fix the links

8101ce7

Fix typo in GetLightClientSnapshot

f834813

djrtwo reviewed Apr 5, 2021

View reviewed changes

hwwhww and others added 3 commits April 6, 2021 17:12

Apply Danny's suggestions from code review

5dd7119

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>

Update docs

1091bd7

Merge branch 'dev' into light-client-docs

5a32d22

etan-status mentioned this pull request Nov 30, 2021

Implement light client syncing status-im/nimbus-eth2#2337

Closed

arnetheduck mentioned this pull request Dec 4, 2021

Add lightclient routes ethereum/beacon-APIs#181

Closed

dapplion reviewed Dec 5, 2021

View reviewed changes

philknows mentioned this pull request Dec 13, 2021

Light Client Planning Tracker ChainSafe/lodestar#3469

Closed

5 tasks

etan-status mentioned this pull request Jan 13, 2022

Define libp2p protocol for light client sync #2802

Merged

hwwhww closed this Jul 22, 2022

jtraglia deleted the light-client-docs branch January 22, 2025 20:01


		#### GetLightClientSnapshot

		Protocol ID: `/eth2/beacon_chain/req/get_light_client_snapshot/1/`


		## Sync protocol

		Note that in this syncing mechanism, the server is trusted.

Conversation

hwwhww commented Mar 23, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dapplion Dec 5, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djrtwo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dapplion Dec 5, 2021 •

edited

Loading