# Week 2

## Recap
This week I spent a lot of my time delving deeper into Ethereum state scalability solutions. After finishing the EPF study group video and reading content to ensure I had a proper understanding of the whole of Ethereum at a high level I began my specific research. Coming from last week I had an interest in the concept of history expiry and how it could drastically help with storage scalability problems on Ethereum. I went fairly deep into how the concept would work in practice and the potential problems that might arise when implementing it. Additionally I looked into potential EL clients that I would be interested in working on in conjunction with my backround in programming. I also looked into the Portal Network and what it aimed to achieve. From there I decided that the Portal Network would better achieve what I would like to see in Ethereum, which is both a storage scalable solution and a more user friendly experience through light clients. After some research I determined that I would like to build a Portal Network client for Besu as it is completely set up for a smooth transition into being able to accomadate such an upgrade.

## Learning
This week I watched a fair amount of presentations and talks on more specific parts of both History Expiry and the Portal Network. I also read various articles and documents to get a deeper understanding as to how both concepts would function in practice. Outside of learning and expanding on these concepts I spent a lot of time learning the Besu client and its various architecture.

### Concepts

#### History Expiry
When starting to really dive deep into the idea of history expiry I encountered a few road blocks that would make the implementation fairly difficult and/or impractical. The first issue is that although it would be a really benificial change the implementation would require a huge structural change in how clients handle their data. This in certain implementations could mean that the protocol would have to be modified in order to accomodate these changes. Additionally, although it would reduce the barrier to entry, it would also increase network reliance on archive nodes which may be an unwanted trade-off. More importantly, there are better solutions that achieve more net benefits, such as the Portal Network or State Expiry. The main takeaway that I got from history expiry as a whole is that although it is useful, there are potentially better ways to achieve the same goal.

##### Resources
1. https://www.blocknative.com/blog/ethereum-roadmap-guide
2. https://notes.ethereum.org/@vbuterin/state_expiry_eip?source=post_page
3. https://inevitableeth.com/home/ethereum/upgrades/statelessness/state-expiry

#### Portal Network
After learning more about the Portal Network when researching history expiry I found the idea to be conceptually more appealing. Primarily because with enough Portal Network nodes on running, they would achieve the same storage benefits as a regular EL client with history expiry. Furthermore the Portal Network inherently encourages a more decentralized network. Doing so by in theory making it drastically easier for anyone to join and contribute an amount of storage/computation available to them. On top of the fact that the Portal Network essentially places a full archive node on the cloud, making it less relient on the operation of archive nodes. This means a more user friendly Ethereum which could lead to more adaoption of the technology.

##### Resources
1. https://ethereum.org/en/developers/docs/networking-layer/portal-network/
2. https://github.com/ethereum/portal-network-specs
3. https://www.youtube.com/watch?v=jAX_bgcESoc
4. https://www.youtube.com/watch?v=0stc9jnQLXA
5. https://ethresear.ch/t/portal-network-verkle/19339

#### Besu
After learning about the Portal Network I decided to look into potential clients that I could do some form of implementation as a potential project. I noticed that the Besu team had listed a Portal Network client as something they were looking for in the list of projects for the cohort. I decided that this was the direction I would like to take and so I began learning about the Besu client. I first forked the client and then built and ran it from source. Then I spent the remainder of my time looking into how it was designed and started learning the codebase.

##### Resources
1. https://besu.hyperledger.org/
2. https://github.com/hyperledger/besu
3. https://wiki.hyperledger.org/display/BESU/Hyperledger+Besu

## Week 3 Plan
I plan to continue to learn the Besu codebase and look into how I can implement a Portal Network client for Besu. I will also have to dive deeper into the Portal Network specs to learn about some implementation specific details. I plan to use this project for my project proposal. In addition to learning the code and specifications I will also begin to reach out to different team members in order to gain a better understanding and learn any other implementation specific details that the Besu team may want.