EPF Cohort 4 Updates: Week 3

# 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](https://ethereum.org/en/developers/docs). 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](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/), the first in a series of blog-posts that led me to [Trin](https://github.com/ethereum/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](https://github.com/ethereum/trin/issues/750) 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](https://github.com/sigp/discv5/pull/209). * 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](https://github.com/paradigmxyz/reth) still has a lot of interesting issues, and I'm hoping to get my hands dirty with one soon. * [Trin](https://github.com/ethereum/trin): Ethereum Portal Network implementation in Rust. * [Beacon-Api-Client](https://github.com/ralexstokes/beacon-api-client). * [Lighthouse](https://github.com/sigp/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](https://github.com/orgs/ethereum/repositories?q=specs&type=all&language=&sort=). * [Crypto primer](https://cryptobook.nakov.com/). * [Kademlia paper](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) & [rust-libp2p implementation](https://github.com/libp2p/rust-libp2p/tree/master/protocols/kad). * [Kademlia visualization](https://kelseyc18.github.io/kademlia_vis/basics/1/) & [Youtube video](https://www.youtube.com/watch?v=1QdKhNpsj8M). * [Portal network talk](https://www.youtube.com/watch?v=0stc9jnQLXA&t=332s). * [Discv5](https://github.com/sigp/discv5) & [Trin-portalnet](https://github.com/ethereum/trin/tree/master/portalnet) crates.