The Portal Network teams suggested that I change the focus of my EPF project to something else. Piper suggested that I should investigate how we could serve Engine API data from the portal clients. I thought that was a very interesting idea, so I'll evaluate if I should use this as my new project.
Why do I think this is important?
I have an anecdote related to this:
Before the EPF, I was contributing to Lighthouse. There was an instance where I wanted to benchmark some changes to the beacon API, and I needed to run Lighthouse locally. This was troubling because I didn't have an SSD big enough for running an execution layer client alongside Lighthouse.
I had to rely on an internal Sigma Prime endpoint to get access to an EL node.
And that's the problem we're facing: If we want to run a consensus client, we need to also have the resources to run an execution client alongside. I was fortunate to get access to the sigp node, but running something locally would've been better.
Piper specifically mentioned staking as an area that would benefit if this gets solved.
Doing this research, and implementing it if possible, would greatly help stakers that want to run their validators on a resource constrained device. It would help other users, like CL contributors, as I learned some months ago, but I think focusing on stakers right now helps give a better scope to my project.
The way this would solve the problem is by allowing users to run a portal client instead of an execution client alongside their consensus client. This would greatly reduce the resource usage of the machines they use for their validators. Without having to rely on someone else for getting the data.
If my research shows that this data can't be served from the Portal Network, I think understanding why, would be helpful for future developments towards solving this problem.
As a side note, working on this would allow me to study a "cross-section" of Ethereum. It would push me to learn more about staking, EL clients, CL clients, how they interact with each other, how the portal network serves data, etc. Also, This project would include a lot of research. Some weeks ago, I would have considered this a problem, since my background is in engineering. But now I think this is a good opportunity to get some experience researching. And, if my research concludes that this can be done, I would implement this into Trin. This would make the project more "complete" than picking something to implement and start coding it.