# EPF Final Project Update
As we've reached the end of the cohort 5, we are expected to slowly wrap up the projects, and prepare this final development update. I will try to go over the details of the project, as well as the journey alongside it.
###### (This document is being written almost 4 weeks after the cohort end date.)
## Project
I chose this project at the start almost randomly. I was looking to learn Go, and a friend of mine mentioned that this is a valuable project. But I basically had no grasp of the meaning of the project. But it turned out to be a great choice.
The title of the project was [**"Prysm - Implementing a server for light clients"**](https://hackmd.io/q8fe302MQIayhtb9Aj-BJQ). At first I really didn't understand what this means exactly, but I started to slowly see the high level view. The resources that I used that helped a lot with understanding the project at the early stages, were the [consensus specs](https://github.com/ethereum/consensus-specs), two videos [[1]](https://www.youtube.com/watch?v=ZHNrAXf3RDE) [[2]](https://www.youtube.com/watch?v=85MeiMA4dD8) of previous DevCon talks by [Etan](https://github.com/etan-status/), and the videos of [Light Client Summit Devconnect Amsterdam 22](https://www.youtube.com/playlist?list=PLJijNYoOwnst-feT7PsCLaSdiFYzWtf7j).
I gained most of the knowledge needed for the project along the way of implementing it. Getting into the code actually forces you to learn stuff, Which is nice. But here is a project abstract, written with my current knowledge:
**Light Clients** are pieces of software that partially sync the chain in a verifiable way. Partially here means that they only keep a chain of block headers, and they don't have access to the block body or the state. The reason this is valuable is because while syncing the block headers, you get access to the State Root for each block. And this means that if you have a piece of data from the state, and it's Merkle proof, then you can compare it to your state root and make sure that the data is valid.
For these light clients to be able to sync the chain of headers, there has to be full clients that offer the data. This was the purpose of my project.
More specifically, a full node has to
- Gather and save the light client data as it receives new blocks.
- Process that data
- Expose that data through the JSON-RPC methods and the P2P network.
Read more about the details in [the light client consensus specs](https://github.com/Inspector-Butters/light-client-consensus-specs).
## State of the Project
We used this [tracking issue](https://github.com/prysmaticlabs/prysm/issues/12991) as our roadmap.
We started slow, but picked up the pace later on as we were more comfortable with the codebase. My first task was to create a key-value database interface for the light client updates. We worked on a large number of things, which led to lots of pull requests and discussions. Some of the things we worked on are:
- Saving light client updates and bootstraps when receiving blocks.
- Creating databases for updates and bootstraps.
- Implementing 4 RPC endpoints that expose the data.
- Implementing the P2P topics.
- Defining the data structures for light client data.
A large portion of our time was spent on defining the data structures. At first we decided to have fork specific objects. Then I convinced others that we can abstract away the fork-specific parts of the objects, and have generic types for every fork. This led to a very big refactor that took me almost a month to implement. But joke's on me because later on we found out that this makes everything extremely complex, and decided to go back to the previous model :). This also required a large refactor, which [Radek](https://github.com/rkapka), our mentor, took charge of.
One other interesting fact is that most of my time working on this project, was spent on writing tests rather than logic implementations, which was a new experience, and it showed me what a real project should look like.
All in all, after almost 6 months of working on this project, it's almost finished. We have all the parts, and everything works (you can try it on my [Holesky beacon node](http://prysm.bastin.io/eth/v1/beacon/light_client/optimistic_update)), but there are still some fine tuning left to be done, which are mostly optimizations and cosmetic changes.
## Future of the Project
I will try to finish the project, as defined in our roadmap. I doubt that it will take more than one month for it to be complete, but since the holidays are coming up it's hard to say for sure.
I would also like to get my RPC node on the list of [light sync endpoints](https://s1na.github.io/light-sync-endpoints/).
Hopefully I will try to maintain this project as changes occur at forks or new features come up.
## EPF Journey
First I would like to express my gratitude to the organizers of EPF. Mario, Josh, and EF.
Participating in EPF was probably one of the most beneficial things I did in my life. It allowed me to get into the core development space without any friction, and offered me the opportunity to learn from some of the smartest people in the ecosystem, all while making lasting connections and friendships with the fellows and mentors.
I strongly encourage anyone reading this to participate if you are interested.
Reflecting on my journey, I think generally I had a decent performance. I could have put in more time, which might have meant that the project finishes sooner. I also spent much time on choosing a project, which now I understand was not needed. All the projects are challenging and interesting, and offer opportunities to learn.
I made great friends throughout the fellowship, both in Brussels and Bangkok, and I hope that these connections remain open for a long time. I do believe that I missed to follow the progress of most of the other projects during the cohort. But there are many projects and it's really hard to keep up with all of them.
I really gained a lot out of this program, notably getting to be among the core devs at Devcon, discussing technical topics with them, and making connections.
It has been a pleasure.