## TLDR
I worked on some refactoring, and finished the `GetLightClientUpdatesByRange` RPC handler. [PR Here](https://github.com/prysmaticlabs/prysm/pull/14531)

## Recap of last week
In the last update I spent most of my time fixing some bugs that I found in the light client core module. Read about them [here](https://hackmd.io/@Bastin/r1WiyPnp0)

## What happened this week
For the past 2/3 weeks I have been working on the `GetLightClientUpdatesByRange` RPC handler. We wanted this API to read the updates from the DB, instead of calculating them on demand, which could be very compute heavy and often lead to time-out errors.

Making the changes for this handler was not a big change and was very straightforward. But the hard part was refactoring/writing new tests for it.

I spent some time on deciding what the function should return during different setups. Specifically when we have missing updates in the requested range.
Missing updates can be caused by multiple things, for example a bug in the DB.

I also looked at the [API's provided](https://s1na.github.io/light-sync-endpoints/) by Nimbus, Lodestar, and Helios. And it seemed like the consensus was that we should return the first continuous set of updates in the requested range, starting from the first requested period.

Check out [the PR](https://github.com/prysmaticlabs/prysm/pull/14531)

We also decided to refactor the light client codes to use versioned structs instead of the "version agnostic" ones that we created [before](https://hackmd.io/@Bastin/S1n5EXoh0). This hard choice was made because we had trouble using the SSZ functions on proto structs that use `oneof` fields.

## What's next
Next weeks I will be focusing on saving the updates upon receiving them in the client to the DB, and also when the client is syncing. But I have to learn about the syncing process in Prysm.

For the next two weeks before devcon, the focus will be on getting to a stable state. We should be able to complete the http part of the specs, and have light clients sync the chain using a Prysm node.

## Other notes