# Week 3

## Recap
This week I dedicated most of my time to learning about specific details of the Portal Network in order to gain an understanding of how to begin creating such a client. I looked into the Portal Wire Protocol which is the main protocol that the entire network functions on. I then looked into all six of the sub-networks that work together to allow a portal client to have so much functionality. I decided to then look into JSON-RPC design and the major role it plays in both Portal Network clients but also just all other clients. I went through each API endpoint to gain a high level understanding of how and where each endpoint is used throughout communication. Once I had learned about the JSON-RPC itself I also looked to understand why it was used to begin with as a communication method. Finally, because the Portal Wire Protocol is built on top of the Discovery V5 Protocol I figured I should also learn about that protocol. I began with learning about Devp2p and its usage. Then I looked into the specifics of Discovery V5 and how it functions in order to create the network that nodes run on.

## Learning
In terms of learning recources I mainly used various pieces of documentation from specification repositories to get an in depth and specific understanding of the material that I covered. I also dedicated some time to continue learning about the Besu client and its codebase in order to be able to implement a Portal Client.

### Concepts

#### Portal Network
The Portal Network specification repository was incredibly useful in learning about the different moving parts that go towards making a Portal Client function. I first looked into the Portal Wire Protocol which works on top of the Discovery V5 Protocol from Devp2p. I learned about the different parts of node communication from the opening handshake to general data transmission. I then looked into the six different sub-networks for Portal that all use the Portal Wire Protocol. The first was the State Network used to mainly deal with the storage and retrieval of data. Including the specifications on how data throughout the network is to be transmitted trhough gossip. The second network was the History Network which also dealt with data storage and retrieval. However it is more so focused on actual block information as opposed to trie storage and proofs. Third was the Beacon Chain Network. The name is fairly self explanatory in that it is used to ensure that the light clients are able to stay up to date and properly sync. The next three Networks are more so a work in progress and are likely to change as they are developed. The Canonical Chain Transaction and Transaction Gossip Networks will likely be focused around ensuring transactions are both easily locatable and easy to validate when the information regarding them is requested.

##### Resources
1. https://github.com/ethereum/portal-network-specs
2. https://github.com/ethereum/portal-network-specs/blob/master/state/state-network.md
3. https://github.com/ethereum/portal-network-specs/blob/master/history/history-network.md
4. https://github.com/ethereum/portal-network-specs/blob/master/beacon-chain/beacon-network.md
5. https://github.com/ethereum/portal-network-specs/blob/master/canonical-transaction-index/canonical-transaction-index-network.md
6. https://github.com/ethereum/portal-network-specs/blob/master/transaction-gossip/transaction-gossip.md
7. https://github.com/ethereum/portal-network-specs/blob/master/verkle/verkle-state-network.md

#### JSON-RPC
I decided to look into JSON-RPC because it is so instrumental to all client function. I looked into each different JSON-RPC API endpoint to understand each usage case and get a better understanding about inter-node communication. The Portal Network also defined its own JSON-RPC endpoints. I also learned that JSON-RPC was best suited as a communication standard for nodes due to its simplicity, stateless nature, ease of use and the fact that it has no language reliance which is optimal for so many different clients.

##### Resources
1. https://ethereum.org/en/developers/docs/apis/json-rpc/
2. https://playground.open-rpc.org/

#### Discovery V5 Protocol
Because the Portal Network is reliant on large scale adoption to be succesful I decided to learn about the node discovery and communication process. Also because the Portal Wire Protocol is built on to of Discovery V5. I began by learning about Devp2p and how it was designed specifically for Ethereum. I learned that the Discovery V5 Protocol was just a subset of the Devp2p specifications. It was interesting to see how nodes discover each other and perform lookups, as well as the use of a specific Distributed Hash Table to store node information. It should also be noted that there are still parts of Discovery V5 that are not completed but that look to play a useful role in node communication through the use of tickets.

##### Resources
1. https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md
2. https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md
3. https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md
4. https://github.com/ethereum/devp2p/blob/master/discv5/discv5-rationale.md

## Week 4 Plan

After getting a good idea of what specifications a new Portal Client should be able to meet I plan to look into ways to implement such specifications. I will likely take a look at existing Portal Clients to gain insight on how some implementation problems can be tackled. I intend to also continue learning the Besu codebase to find any potential challenges that may arise when designing a Portal Client.