# Development Update #3 Three weeks ago, I gave my second update. In that update, I mainly talked about how I had settled on three projects: working on implementing OFFER/ACCEPT/STORE, working on a testing framework, and writing a devp2p guidebook. In the past few weeks, I have focused almost exclusively on the first goal, as well as doing a lot of supplementary learning. I have also realized these development updates might be used by future CDAP participants, so I will try to write in a way that might help you guys get an idea of this program. ## Previous Goals - Finish a working implementation of OFFER/ACCEPT/STORE - Look into geth's testing framework to begin designing a testing framework - Read application-level subprotocol specs (eth, snap, les) ## Progress ### Offer/Accept/Store So the biggest progress I've made is with regards to the OFFER/ACCEPT (store was dropped) implementation in Trin. This is not much in terms of lines of code--just one method that sends the OFFER message, and then a handler for OFFER messages, which sends ACCEPT messages in response. However, there was a lot of scaffolding and things I discovered in this process. One of the main things was figuring out the "content-id derivation function". I won't bore you with the details, but essentially I read over all of Mike's PR and code of abstracting Trin storage logic. This was very informative, both with giving me insight on what he was doing, and we both talked and tossed around some ideas of implementation details, and how my code would interface with his. Additionally, I looked over Kolby's implementation of uTP and tried to extract the main ideas, ie, the interface I would be using, since my code (the node sending the ACCEPT) message, then uses a uTP stream to receive data. Before all of this, I read Jacob's history spec, and got a good overview of the history network, since again, the protocol messages I am implementing will be used by that subnet as well as the state network. So in summary, I really dove into what my fellow CDAP participants are working on, and this was great. It turns out the implementation of two "little" protocol messages is at the heart of many different things. As of now, I have a stub implementation of OFFER/ACCEPT. Once Mike merges his PR, I should be able to have a fully working implementation, and then focus on integrating it to use uTP. ### Testing Framework With my focus on the above, consequently I have had very little time to work on the testing framework. In the beginning, I worked a bit with Ogenev on this. He has started a branch for integration testing framework that should work for cross client testing. I helped a bit in brainstorming/thinking about how the framework should be designed. His idea is having a dummy node and a target client. The node sends requests, which the target client (the node under test) then responds to. In this way, we can test the proper responses. I think this is a great approach, and is similar to how geth runs their framework. I did write a small script to automatically connect two nodes and issue a suite of tests. This is not very robust, but may be used later. Anyways, I think I will put this project on the shelf, since Ogenev has largely taken over it, and I will focus my efforts elsewhere. ### Devp2p Guidebook I completed my goal of reading the eth, snap, and les specs, mainly focusing on the eth spec. However, beyond that I have not had much time to work on this. I think an appropriate goal would be to focus on the discv4, v5, RLPx, and eth specs, and have the guidebook focus on these protocols. I will get this written though. I am not GRR Martin. ## Next Week's Goals (9/18/21) To avoid a dependency blocker, I will leave my stub implementation as is. However, during implementation of this, I discovered quite a few other things to work on. An easy fish to tackle is writing the content-id derivation function. A larger thing to tackle is writing an API for decoding and handling responses, as well as looking into reconfiguring the architecture of how Trin handles requests (these go somewhat hand in hand). - Write a content-id derivation function & open a PR (there will be some details to consider here, with regards to the now many-to-one mapping of content-key to id) - Look into Python DDHT implementation for how to possibly rearchitect the way Trin handles requests, and how it can handle responses - Review my previous notes on discv4 and discv5 and write a draft explanation of them as part of my guidebook ## Summary I plan to write weekly, shorter updates since I've been notoriously bad at writing my updates. With weekly goals, I also can focus better on a few things specifically, without being overwhelmed. A lot of what I have been doing is "supplementary", ie, not directly contributing to the protocol/codebase, but learning things that help my understanding. For example, I have been spending around an hour or two each day learning: the Rust language, concurrent programming and the Tokio library, and about Merkle trees and proofs (I switch between these, (just like a concurrent program, sorry)). While this has been incredibly helpful, I often find myself diving in too far, like for example I want to understand all about tries in Ethereum. There is a line between "work fast and break things" vs. learn everything, almost entirely to fill in all gaps of knowledge, then begin working. This week, I plan to dig in faster and start implementing PoCs, and then improving them over time. ### Note to future participants This update is already long as is, but I wanted to add a tip that might be useful to future participants. The past weeks, I have spent a lot of time looking over other people's PRs, code reviews, new issues, reading the threads and participating in discussion. I have also spent more time getting familiar with what my fellow participants are doing, and talking with them on Zoom about it. This has helped me be and stay up to date with what is going on, and learn from peers as well. So a good (maybe obvious) tip is don't get completely lost in your own work, spend some time getting familiar with other people's work, and read, especially participant, in the discussions.