Besiktas19033
commented
3 years ago After implementing a rough POC web-based light-client consumer in Lodestar, I would like to share some feedback about it.
In
validate_light_client_updatethis condition invalidates updates that are technically valid.if update_period == snapshot_period: sync_committee = snapshot.current_sync_committee assert update.next_sync_committee_branch == [Bytes32() for _ in range(floorlog2(NEXT_SYNC_COMMITTEE_INDEX))]The update provider (server) does not know in advance if the update_period is > snapshot_period. It could just check before if
update.next_sync_committeeis zeroed and verify it otherwiseAn update provider may want to send the light-client consumer an update for the same slot but with higher consensus. This happens frequently for finalized sync where sync committees will be producing valid updates for the same
update.header.slotduring an epoch but they may have more bits than the previous. This condition invalidates useful updates and I believe it can be omitted.assert update.header.slot > snapshot.header.slotIn
LightClientStorethe purpose ofvalid_updatesis to potentially use one of those if there is an update timeout. Instead,LightClientStorecould just keep a singlebest_updateand run the logic the pick the best on every new update. To comply with SSZ it can be zeroed initially to represent a no value.The UX for finalized sync is not great, the distance from the header you have in the snapshot vs current chain head is way to big. I'm writing this to signal the importance of getting a safe sound protocol for a re-org capable light-client close to Altair release.
Sharing the API we are using currently as a potential proposal for a REST API or to eventually translate it to a ReqResp protocol
GET /eth/v1/lightclient/best_updates/:periods Return updates in batch to a range of periods. Must return exactly 1 update per period requested. The definition of "best-update" is vague so nodes have the freedom to optimize what to store. For example, to persist the latest LightclientUpdate that has the most bits within a period. GET /eth/v1/lightclient/latest_update_finalized/ Request the latest finalized update seen by the node GET /eth/v1/lightclient/latest_update_nonfinalized/ Request the latest non finalized update seen by the nodeCC: @wemeetagain
After implementing a rough POC web-based light-client consumer in Lodestar, I would like to share some feedback about it.
In
validate_light_client_updatethis condition invalidates updates that are technically valid.The update provider (server) does not know in advance if the update_period is > snapshot_period. It could just check before if
update.next_sync_committeeis zeroed and verify it otherwiseAn update provider may want to send the light-client consumer an update for the same slot but with higher consensus. This happens frequently for finalized sync where sync committees will be producing valid updates for the same
update.header.slotduring an epoch but they may have more bits than the previous. This condition invalidates useful updates and I believe it can be omitted.In
LightClientStorethe purpose ofvalid_updatesis to potentially use one of those if there is an update timeout. Instead,LightClientStorecould just keep a singlebest_updateand run the logic the pick the best on every new update. To comply with SSZ it can be zeroed initially to represent a no value.The UX for finalized sync is not great, the distance from the header you have in the snapshot vs current chain head is way to big. I'm writing this to signal the importance of getting a safe sound protocol for a re-org capable light-client close to Altair release.
Sharing the API we are using currently as a potential proposal for a REST API or to eventually translate it to a ReqResp protocol
CC: @wemeetagain