HackMD
EPF Dev Update #2
tl;dr:
- Wrote about Danksharding, The Portal Network, and Verkle Trees.
- Decided to work on The Portal Network!
Overview Articles
As I mentioned in last week's update, I did an overview of the upgrades coming to Ethereum. I took notes on the areas that were most interesting to me:
In the case of Danksharding and Verkle Trees, I wanted to get a better understanding of what they are, so the notes I wrote include a conceptual overview. I had a good idea of what the Portal Network is, so I focused only on the current progress in that article.
Since my background and main interest is engineering, but I also want to try doing some research. I want to pick an area that focuses on implementation, but also allows me to interact with specs.
Proto-Danksharding is too close to production for what I want, and full Danksharding is too far away. Other upgrades like Proposer Builder Separation are needed to get there, but even though PBS is moving to implementation, I don't feel like it's the right fit for me.
Verkle trees are closer to what I want. This is already implemented in some clients, and the specs are still being changed. My issue here is that Reth might not be mature enough to start working on the Verge, and I have a strong preferece on contributing to Reth because It's the only execution client written in Rust.
The Portal Network seems to strike a great balance. I'll talk about it in the next section.
The Portal Network
When I applied to the EPF, I mentioned the portal network as one of my areas of interest. I consider it to be a very important piece of infrastructure and also an interesting technical problem. With the research I did last week, I wrongly concluded that it was still too much on research for me. So I didn't even mention it in my last update.
Since I still thought it was interesting, and it kept showing up while I was researching the other areas, I decided to give it another opportunity.
Turns out it was just what I was looking for!
The Potal Network has four sub-protocols. One of them is already implemented, and the other three are either being implemented or with specs ready to be implemented.
The fact that the specs are ready (mostly) but there are parts not implemented yet, leaves me in a great spot: I can write code, but I would probably have to iterate with the spec as I program.
On top of that, Trin (which is written in Rust) already has some functionality. This is helpful because there will be code I could use as example.
Next Steps
- Now that I know what to focus on, I'll do a deep dive, more technical than conceptual. I'll get a better understanding of how the network works, what is already implemented, and what contribution I could make as my project.
- To get familiar with the Trin repo, I'll pick a good first issue and solve it. This will allow me to get to know the existing codebase and learn what the workflow of the Trin team is.
