# EPF Final Dev Update

## Project abstract

Light clients have always been something that the Ethereum community wants. The Portal Network seems to be the most promising attempt to get light access to all data on the Ethereum network. It has been under heavy research and development for the last couple of years, and it seems to be close to delivering its purpose. For this reason, it's a good moment to figure out ways we can use this new piece of infrastructure. This project aims to enable one use-case for the portal network: replacing execution layer clients with portal clients on staking setups.

To learn more about the project, you can read my [project proposal.](https://github.com/eth-protocol-fellows/cohort-four/blob/master/projects/portal-network-validator.md)

## Status report

I started my research by learning how the portal network and the Flashbots PBS architecture work. This was with the hope of finding a way to use the PBS infrastructure to outsource block building out of the portal clients.

I quickly realized that 1) trying to make this isolated from the rest of the validator functionality (mainly, block validation) wouldn't make much sense and 2) this would be fairly simple once that other functionality is sorted out.

With this in mind, I tried to understand first how a node was started. There weren't a lot of resources that explained this, so I went directly to the lighthouse codebase to figure it out.

Doing this gave me a very detailed view of all the processes and preparations a node had to take before calling the engine API endpoints it needed to start.

After this, I decided it was time to go deep into the engine API, so I allocated a lot of time to learning about it.

If I stick strictly to what I planned in the project proposal, my status report would be:

> *After my research during the EPF, I can conclude that the minimal set of endpoints a Portal Client must serve for it to be able to replace an execution layer client is:*
>
> - *engine_exchangeCapabilities*
> - *engine_forkchoiceUpdated*
> - *engine_newPayload*
>
> *This is possible only if the validator builds blocks through MEV-Boost or any other Builder client.*

This would mean that I *barely* completed the "research only" scenario I set as a goal in my proposal.

But that's not all.

I wanted (and, probably needed) to understand how everything works under the hood before trying to implement anything. As I researched more and more, I began to realize how hard was to start learning about some aspects of the protocol. So, I decided to start writing articles explaining what I was learning. And this is a part of the project I feel very proud of.

The articles I liked the most are:

- [Notes on Kademlia Distributed hash table (DHT)](https://hackmd.io/@danielrachi/SkQuHtMi2)
- [Flashbots PBS Architecture](https://hackmd.io/@danielrachi/HJxXjUwC2)
- [Lighthouse Node Startup](https://hackmd.io/@danielrachi/S1u2Veflp)
- [Engine API: A Visual Guide.](https://hackmd.io/@danielrachi/engine_api)

I think the article about the engine API was especially relevant. That API is a very important piece of infrastructure with not a lot of resources beyond the spec. There was interest in getting an article of that kind written for some time.

After finishing the article and getting feedback, a link to it was included in the [*references* section of the Engine API spec readme](https://github.com/ethereum/execution-apis/tree/main/src/engine#references).

Similarly, I published my article about Kademlia on the [portal network website](https://www.ethportal.net/concepts/protocols/kademlia).

## Future of the project

What I want to do next is to write a proper spec. I want to get into the details of what data is necessary to serve those endpoints, the timing that data needs to have, etc.

After the spec, the obvious path to take would be implementing the endpoints into a portal client. (Trin, probably.) But that won't be possible right now. A lot of the data that is needed will be served by the portal *state* network, which won't be ready for some time.

So, what I'll do after having a spec ready is to work with the portal network teams to get the state network running.

After that, It'll come the time to implement those endpoints into a portal client. But there's a long way before I get to that.

## Self-evaluation

I'm happy with my results and the growth I had.

Even though I'd have liked to get further on the project itself, I consider the articles I wrote to be a meaningful contribution that helped me a lot and will probably help more people in the future.

However, there's an area where I could improve.

I chose [another project](https://github.com/eth-protocol-fellows/cohort-four/blob/master/notes/danielrachi/old-proposal/proposal.md) early in the program. After I started working on it and started talking with the portal network teams, it was clear that what I wanted to do wasn't too important.

Maybe this is just an intuition you get by learning more, but still, there's an opportunity for improvement here. I'll get better at evaluating what projects to work on.

## Feedback about the EPF

Perhaps the best things about the program are the simplest: the weekly updates and the standup calls. Reporting my progress to the group added an extra pressure that I wanted to have, and having to write updates constantly was great to let me reflect on what I was spending my time on.

An extremely underrated aspect of the fellowship is the Discord channel. I think it's amazing how we were able to ask anything about any area of the protocol and have the question answered quickly by the people who know the most about the topic in the world. Of course, with this comes the responsibility of asking good questions, and I hope the questions I asked there were fine.

The AMA sessions were also great. I had the opportunity to ask some things to developers I was already familiar with but hadn't had the chance to talk to.

As mentioned earlier, my main problem with the program was picking a project. I'm not sure about what could be done to improve this. Maybe try something like a template for project suggestions, so the mentors give more context about why is the project important, what is their team focusing on, etc.

## Closing thoughts

I'm very grateful for having the opportunity to participate in the protocol fellowship. I learned a lot of things, met a lot of interesting people, wrote a lot about topics I've been interested in for a while, and started to get used to the mechanics of being a core dev. And of course, had fun working on something I care about.

Beyond this, probably the most impactful thing for me is that now I have an interesting project to work on. Something I was looking for when I joined the program.

Sometimes I feel like I could have done more, especially because I didn't implement anything during the program. I hope the articles I wrote can help more people as much as they helped me understand everything. Hopefully, they have an impact as good as any program I could've written in that time.

I'd like to extend my sincere thanks to Josh and Mario for making all of this possible and for allowing me to work on something I'm genuinely passionate about. Piper Merriam deserves a special mention for proposing the idea behind this project. I'm also grateful to the Trin team for their warm welcome and support over these months. Reporting my progress to them twice a week provided valuable motivation. Finally, a heartfelt thank you to Jason Carver for his exceptional guidance, for helping me overcome roadblocks, providing direction when I needed it, and, of course, for agreeing to co-present at the Stakers event on Devconnect.