Development Update #2

# Development Update #2 It's been awhile since I gave my last update, but a lot has happened since then. I've settled on a triage of three projects, and I'm working on all of them concurrently. That might seem like a lot, but one of them is just a learning thing for me, and just consists of a lot of reading and some writing. The three projects I'm working on are: 1. Implementation of OFFER/ACCEPT/STORE messages for the trin-state and trin-history networks. 2. Building a testing framework for testing p2p networking for trin clients. 3. Writing a devp2p educational guidebook. ## Progress Since there's a few things I'm working on, I broke down everything I'm doing so I can make sure I'm spending some time on each. I've broken my work down into 3 categories: supplementary learning, indirect protocol work, and direct protocol work. A lot of the work I've been doing has been supplementary, in that they are not directly related to the Ethereum protocol, but necessary so I can better understand what's going on. Indirect work is work that's more related to the protocol (not just more general learning) but more so research, reading code, specs, etc. And direct work is "actual work" on the protocol, like programming and designing. #### Supplementary Learning - Concurrent programming, tokio library - Rust language #### Indirect protocol work - Breaking down the trin codebase - Exploring geth testing framework - devp2p guidebook #### Direct protocol work - OFFER/ACCEPT/STORE implementation - Testing framework The supplementary learning helps me to break down the trin codebase, which will help me implement the protocol messages and testing framework. I went through the codebase once already and that helped me to get a pretty good overview of what was going on in trin and how everything was working together at a high level. However, the most confusing things by far were the concurrent programming things with tokio, like the channels, message passing, and threads. I've never worked with concurrent programming before, so I've been trying to teach myself the basic concepts there. ## Next Steps 1. Get a working implementation of OFFER/STORE/ACCEPT - I've read through Jacob's chain history spec to understand what's going on there. I previously implemented Advertise & RequestProofs but these messages will supercede them. - Once I get a better understanding of the context/necessity of these messages, I'll design them according to the spec. 2. Look into geth's testing framework for inspiration and begin designing a portal testing framework. - Previously, I successfully connected 2 bootnodes. - I think a lot of what is holding me back in designing the framework is that I don't have a full understanding of the codebase. So once I have a better understanding of concurrency, I will look into tokio library, and then hopefully have a better idea - I also plan to play with geth's `devp2p` command-line tool, understand what their testing accomplishes, perhaps look into their src code to see how they do it, and then extract any ideas from that to the testing framework I'm trying to build here 3. Finish reading the application-level subprotocol specs (eth, snap, les) - Previously, I had gone into depth on discv4/5. I looked a lot into DHTs, and Chord, but kinda went limp on Kademlia's paper since I was tired of DHTs at that point. But I will probably revisit that - In the past week, I looked in depth into the eth subprotocol. - My plan is to finish reading the RLPx-based subprotocol specs, and then round it off with RLPx. Then go back to review discv4 and 5, and then start writing the guidebook. I've got a lot of good notes on discv4 I believe, and already started writing a bit. I plan to focus on a high-level overview and the design rationale. A critique I give myself is that I always like to work on a lot of things and sometimes have trouble focusing on one thing. Heh. Well, so far its been manageable and enjoyable. Either way, my ultimate goal for this cohort experience is to contribute as much as I can to the protocol via implementations and direct work, but in the worst case if I'm not able to contribute as much code, I'll hopefully have learned a lot about the protocol and the portal network, so that I'm ready to contribute more in the future.