# Dev Update Week 15

This week I focused mainly on two things:

- Worked on getting my mainnet besu + teku pair up and running on a node provided by Mario. Initially had some issues with the configurations for the clients, but now the EL & CL syncs are both complete with teku up-to-date in archive mode.
- Archive mode in teku is necessary for accessing historic states, which are required to derive light client data.
- We can test the light client API already implemented (light client bootstrap) on this mainnet client pair.
- Worked on the light client updates by range API and the light client data availability problem.
- Light client data, at least for `LightClientUpdate`, is [derived from beacon state](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/full-node.md#create_light_client_update).
- The [light client API](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/full-node.md#create_light_client_update) specifies that servers should provide light client data for a historic period of ~5 months.
- Most nodes, at least in teku, run in prune mode, meaning that they do not store any state beyond the latest finalized. Archive nodes have a significant storage requirement that most nodes will not provide (especially archive nodes running with >= 5 months of historic data, not just e.g. from the latest checkpoint).
- So we have a question of how nodes will store historic light client data and how they will expose it to callers.
- Light client table
- As explored in a [previous dev update](https://hackmd.io/@robzajac/B1sAY9M3j), long-term the solution with best data availability and correctness would be to persist light client data on-disk as blocks are applied and serve from the database upon a light client request.
- In the interim, we began prototyping an implementation that approximates the "best" light client update for a sync committee period by taking the first two beacon states of the period (pre-state and post-state).
- I pushed up a WIP commit with this [here](https://github.com/robzajac/teku/commit/0335e7bc2ccf2c9ddb5b2050863cd371caf35c63).
- However, this approach has several limitations:
- Requires archive nodes to serve the data (hard to find).
- Likely suboptimal data (according to `is_better_update`)
- Code is harder to maintain (edge cases around non-finalized states, pre-altair states, etc.)
- Therefore, we will most likely abandon this approach in favor of specing out a table update in teku for saving historic light client updates.

More on the design & implementation of a light client data table in teku to come this coming week.