Introduction

It's been almost exactly two weeks since my last update. In this period, I've taken a few more steps towards understanding the ethereum networking layer, and found an unexpected candidate for a project I'd love to work on. Let's dive in!

Progress

As I outlined in my previous update, my first week was spent reading random resources to get a general idea of the Ethereum protocol, and better pinpoint the areas where I would love to make contributions to.

Of all I read, my favourite resource was the ethereum documentation. I especially enjoyed reading about the networking layer, and that led me down a path of reading about light-clients and the devp2p + libp2p specifications for execution and consensus clients. It was through this process that I found this, the first in a series of blog-posts that led me to Trin.

I took a look at the issues and started a discussion on one that had the most appealing title, beginning a whirlwind of a journey into DHTs, networking specifications, 3 Rust codebases, and a lot of google-searches + notes-taking. That's what it took for me to even begin to understand the problem-definition & proposed solution in the first issue I decided to tackle in the eth ecosystem.

A quick overview about the issue:

• The Trin repo currently consists of 3 portal overlay services all built on a shared discv5 service. The issue with this is that we end up with 4 distinct K-buckets and end up holding duplicate entries for a single peer across all of them. This is not only memory-inefficient, but it means that when a layer finds out about the updated status of a peer, it cannot share that information with others.
• For example, since any external node that sends a request to an overlay needs to establish a session with its discovery, it's guaranteed that such a node would have at least 2 entries: One in the discv5 service's kbuckets, and the other in the k-buckets of the overlay it talked to.
• It's also quite likely that an external node that participates in one overlay network also participates in others, so ideally if we have a node's entry saved for a particular overlay, other overlays that might need to reach out to that node should share that single instance.

Fix:

• The first step in "flattening" out the DHT entries was to modify the discv5 types Trin depends on to be generic over a node type in this PR.
• The idea is that now in Trin, the node type can actually be a thread-safe shared pointer reference around a mutex that masks the actual node entry.
• This would mean that a node entry is only allocated once in memory, but every overlay that cares about it will have a reference to it in their buckets. If any overlay were to detect a change in a node's information, they would be able to modify the single shared entry such that it's visible to other overlays.

Long-term goals

Doing more research into the ethereum networking layer has convinced me that it's the area where I want to focus on the most for the rest of the fellowship. A more precise list that the one in my last update is:

• Reth still has a lot of interesting issues, and I'm hoping to get my hands dirty with one soon.
• Trin: Ethereum Portal Network implementation in Rust.
• Beacon-Api-Client.
• Lighthouse: Ethereum Consensus Client in Rust.

I'd like to spend the rest of the fellowship making contributions to each of these four projects, unless I come across a single problem with a wide enough scope to take up all of that time.

Short-term goals

Make my first set of contributions to the discv5 & trin codebases. Start an examination into the Reth codebase.

References.

• The Ethereum specifications.
• Crypto primer.
• Kademlia paper & rust-libp2p implementation.
• Kademlia visualization & Youtube video.
• Portal network talk.
• Discv5 & Trin-portalnet crates.