Ognyan CDAP Development Update 2

# Ognyan CDAP Development Update 2 In my first development update, my target project was code chunk tracking by modifying existing EVM implementation. After some discussions with Piper, we defined the following goals for the project: 1. Implement code chunk tracking in existing client. 2. Benchmark the EVM implementation. After some research, I realized that this is more involved project than I expected because verkle tree [implementation](https:github.com/gballet/go-verkle) in Go is still in progress and does not cover all the specs in the recent [EIP](https://notes.ethereum.org/@vbuterin/verkle_tree_eip). A natural way to attack the problem was to join for example the `go-verkle` team efforts and start working on the verkle tree implementation plus code verkleization and then eventually implement this in the geth client. ## The switch In my initial research, when I started to learn more about Ethereum and preparing for the CDAP adventure, I was really fascinated by the vision of the [portal network project](https://github.com/ethereum/stateless-ethereum-specs/blob/master/portal-network.md). Just imagine that everyone can run light nodes on low cpu devices or on their mobile phones. It is huge! This will improve Ethereum decentralization and bring more secure transactions. And only if I could be a part of it... One day Piper mentioned in #portal-network channel in [Eth R&D Discord server](https://discord.gg/qGpsxSA) that a chain history implementation of portal network would be a good CDAP project. I was really interested in this, a team was starting to form to work on it, and I didn't think twice before asking whether I could join. This is the first time in my software engineering venture when I'm feeling it is something that makes sense to work on and build. That meant I had to abandon the code chunk tracking project and I did ( at least for now ). ## Trin and Chain history Portal network CDAP team decided to implement the chain history network in Trin. Trin is a working prototype of a portal network client in Rust. I started to look into [Trin's code base](https://github.com/carver/trin) trying to get more familiarity with the code and the current architecture. I picked two simple issues from the repo, just to get the ball spinning and to build more experience with Rust. I opened two PRs in Trin repository: 1. Implementing StructOpt for parsing cli arguments 2. Sorting closest nodes by distance in FoundContent response There was a little [discussion](https://github.com/carver/trin/pull/43) on 2) about what is the most efficient implementation, but we agreed that it doesn't make sense to benchmark this for now and it is better to just go with the most readable solution. While Jacob Kaufmann is working on a draft for [Chain History specs](https://hackmd.io/ctTNH9xsSu2ci9DeGidUsQ?view), I'm looking to pick more Trin issues just to gain more experience with the code and to be in better position to bootstrap quicker our chain history implementation. It seems also important that chain history branch doesn't split too far away from the main Trin branch, because it will be harder to rebase later. There are still decisions to be made, for example: How exactly we are going to implement multiple networks in Trin? Can we move all subprotocol message data to TALKREQ? Do we need PING/PONG for subprotocols? Part of those are currently discussed in [this issue](https://github.com/carver/trin/issues/48) and in an `overlay network` [draft](https://notes.ethereum.org/tPzmxQD_S3S3uvtpUSA0-g) from Piper. I hope we will soon outweigh all pros and cons and decide on a plan to implement multiple networks in Trin's architecture.