make SyncQueue / SyncManager generic
#3401
Conversation
|
| difference = (wallSlot - headSlot), | ||
| max_head_age = man.maxHeadAge, direction = man.direction, | ||
| topics = "syncman" | ||
| when E.K is Slot: |
There was a problem hiding this comment.
This kind of logic conflates what's kind of an implementation detail (the unit of measure of synchronization) with the type of synchronization (forward sync, not light client sync). It happens to work now -- is there reason to be concerned that this bijectivity might not always hold?
There was a problem hiding this comment.
The unit is mentioned in the log message ("wall_head_slot" / "local_head_slot"), the when here is just to support other units in this wrapped log statement as well.
The libp2p light client sync protocol defines an endpoint for syncing historic data that is structured similarly to `beaconBlocksByRange`, i.e., it uses a start/count/step tuple to sync from finalized to head. See ethereum/consensus-specs#2802 As preparation, this patch extends the `SyncQueue` and `SyncManager` implementations to work with such new `ByRange` endpoints as well.
|
Personally i do not like all this renames, i think this PR should me much less intrusive. Lets not mix renames and functionality changes in one PR, because with a lot of renames its very hard to see what was actually changed in terms of functionality. |
|
This PR is no longer needed, because all needed light client data can be obtained in just 1-2 requests. |
The libp2p light client sync protocol defines an endpoint for syncing
historic data that is structured similarly to
beaconBlocksByRange,i.e., it uses a start/count/step tuple to sync from finalized to head.
See ethereum/consensus-specs#2802
As preparation, this patch extends the
SyncQueueandSyncManagerimplementations to work with such new
ByRangeendpoints as well.