# Dev Update Week 11 (robzajac)

This week:
- Merged in a [feature flag](https://github.com/ConsenSys/teku/pull/6652) for light client support in teku. Helps keep nodes from serving the data before APIs are ready, and some nodes may elect not to serve the data at all.
- Read and discussed a set of light client API changes from etan:
- https://github.com/ethereum/consensus-specs/pull/3190
- https://github.com/ethereum/consensus-specs/pull/3151
- The change is technically backwards incompatible as it modifies the existing Altair APIs. However in this case we decided it's an acceptable cost while adoption is low.
- Additionally the SSZ format remains unchanged, and this is the best format for consumption by most clients due to smaller payload sizes than JSON
- Adding `LightClientHeader` will make light client data extensibility easier in the future, e.g. adding the `ExecutionPayloadHeader` in Capella, which will allow light clients to correlate CL and EL data.
- We will update the API in teku after the official `beacon-api` endpoint is updated https://github.com/ethereum/beacon-APIs/pull/287
- Opened a draft PR for the SSZ encoding of `GetLightClientUpdatesByRange` https://github.com/ConsenSys/teku/pull/6685
- The serialization is custom to this endpoint (https://github.com/ethereum/beacon-APIs/blob/master/apis/beacon/light_client/updates.yaml#L37), which requires a little extra work than just the default SSZ serialization
- The remaining step is to compute the `ForkDigest` of each `LightClientUpdate`, which I have asked the teku team for ideas

Readings
- [The Road Ahead for Ethereum Light Clients](https://blog.chainsafe.io/the-road-ahead-for-ethereum-light-clients-b6fdb7c3b603), helpful overview of the LC dev ecosystem
- Discussions of RLP vs. SSZ for `withdrawal_root` in Shanghai: https://hackmd.io/@benjaminion/Hkm5x5acj#CLEL-TX-and-withdrawals-commitment-to-better-support-light-clients and #consensus-dev
- The encoding choice is significant for light clients because they verify data by tree root, and an encoding mismatch would not allow this
- Shows the tradeoffs of incurring some tech debt now (keeping `withdrawal_root` as RLP) for increased velocity (Shanghai is not delayed)

Next week:
- Complete SSZ encoding of `GetLightClientUpdatesByRange` and merge in
- Begin implementation of light client update internals
- Update APIs according to etan's change