# Dev Update Week 9 (robzajac)

Last week I continued development of the light client server endpoints in teku:

- Merged in PR for [implementation of `GetLightClientBootstrap`](https://github.com/ConsenSys/teku/pull/6577)
- Made a few iterations on the feature after code review from the teku team
- Tested and confirmed we receive the block header and sync committee associated with the block root given by the caller
- Documented some followups to come out of this PR, like verifying the merkle proof implementation and an acceptance test against the endpoint `/eth/v2/debug/beacon/states/{state_id}`
- Implemented and opened a PR for [the API stub and SSZ types of `GetLightClientUpdatesByRange`](https://github.com/ConsenSys/teku/pull/6623)
- PR adds the REST API endpoint and the backing SSZ types for `LightClientUpdate`
- Identified that this endpoint has a [custom encoding](https://github.com/ethereum/beacon-APIs/blob/master/apis/beacon/light_client/updates.yaml#L37) for the `application/octet-stream` response type. Clarified with the teku team how this can be implemented with the client's serialization library. Planning a followup PR to implement the custom encoding
- Organized the remaining project work in the teku [tracking issue](https://github.com/ConsenSys/teku/issues/4230#issuecomment-1357933576)
- The main work is in the implementation of `GetLightClientUpdatesByRange`, as the remaining endpoints can most likely reuse its business logic
- Another significant piece will be implementing a `LightClientUpdate` cache storing historic light client data, since accessing several historic `BeaconState` would mean a major performance impact
- Outside of the major components, there will be some minor UX/cleanup features, like adding a client flag for light client support and exposing the light client data via libp2p gossip (in addition to the REST API)

This week I would like to work on:
- Merging in the open PR for `GetLightClientUpdatesByRange`
- Adding an acceptance test for `GetLightClientBootstrap`, to verify whether this one is ready for the next teku release.
- Adding the `--light-client-support-enabled` flag. May be helpful before the first endpoint comes online, so that clients have the option of not serving the data (e.g. if hardware-constrained)
- (Time permitting) Beginning business logic of `GetLightClientUpdatesByRange`