HackMDDev Update Week 12
This week:
- Completed and merged in PR defining the SSZ serialization of
GetLightClientUpdatesByRangein teku- This endpoint has a custom octet encoding defined in
beacon-apisthat requires a different handling than that of the default SSZ library in teku. The JSON and SSZ output types differ, requiring us to define a custom SSZ type - This was the last piece remaining to define the interface to LightClientUpdates, meaning we can begin the internal implementation
- This endpoint has a custom octet encoding defined in
- Implemented a set of API changes from etan wrapping light client data in a
LightClientHeaderobject- Wrapping in a parent object makes the API more extensible to adding light client data in the future, e.g. the
ExecutionPayloadHeaderin Capella - Change was made to the Altair defintions, so we implemented it now to preserve compatibility
- Wrapping in a parent object makes the API more extensible to adding light client data in the future, e.g. the
- Synced up with teku mentor Paul Harris about the remainder of the light client work
- Tracking in issue
- The big remaining piece to tackle before we have an e2e flow is the internals of
GetLightClientUpdatesByRange - After that endpoint is implemented, we should be able to test an e2e light client sync using a tool like
heliossynced against a teku node- This article has a good example of this sync
Next week we will mainly take on the implementation of GetLightClientUpdatesByRange. Time permitting, we can begin implementing the gossip topic of GetLightClientBootstrap.
