# Dev Update Week 10 (robzajac)

Hello after the holiday season and happy new year!

Last week:

- Merged in the PR for the API endpoint stub of `GetLightClientUpdatesByRange` in teku - https://github.com/ConsenSys/teku/pull/6623
- This gives us the interface and SSZ types for LC updates within the teku client
- Currently only supports the JSON return type, as this endpoint has a custom octet-stream encoding defined in its [spec]([https://github.com/ethereum/beacon-APIs/blob/master/apis/beacon/light_client/updates.yaml#L37](https://github.com/ethereum/beacon-APIs/blob/master/apis/beacon/light_client/updates.yaml#L37)) to account for LC updates that are returned from different hard forks
- That custom encoding will be implemented in a followup PR
- Opened a PR adding a light client enable flag to teku’s beacon API options - https://github.com/ConsenSys/teku/pull/6652
- Flag will determine whether the client elects to serve light client data, which can be helpful for hardware constrained nodes or nodes that prefer not to serve the data (altruistically)
- In the future it will also determine whether the client is storing light client updates in local cache, a necessary optimization for serving historical LCUs (as retrieving multiple BeaconStates is an expensive operation)
- Investigated and then put aside an effort to implement `calculate_merkle_root` for merkle proofs and SSZ objects in teku: [https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)
- The original intention was to use `calculate_merkle_root` to verify the correctness of the teku merkle proof implementation
- But this proved redundant to the implementation of calculating the merkle proof itself, and the testing that already exists for that functionality
- Without an intention to expose this feature to callers, it makes sense to prioritize other functionality right now

This week:

- Implement an acceptance test comparing the output of `GetLightClientBootstrap` against `/eth/v2/debug/beacon/states/{state_id}`
- This is a straightforward way to verify the block header and sync committee given in the bootstrap object
- And therefore is helpful to check the correctness of this endpoint
- Work on the custom octet encoding for `GetLightClientUpdateByRange` - https://github.com/ethereum/beacon-APIs/blob/master/apis/beacon/light_client/updates.yaml#L37
- Requires extending a new `ResponseContentTypeDefinition` in teku, which may need some additional testing as this is one of the only endpoints with a custom encoding (including e.g. GetDepositSnapshot)
- Time permitting: begin working on the internals of the light client updates API