# EPF-5 | Week 3

This week I majorly spent my time in going deep into Prysm and libP2P codebase. Completed the following:
* https://github.com/prysmaticlabs/prysm/tree/develop/beacon-chain/p2p (mainly: discovery, dial, broadcaster, gater, gossip, handshake, pubsub, subnets and the utilities used along side like service, iterator, address store etc)
* https://github.com/libp2p/go-libp2p/tree/master/core/host
* https://github.com/libp2p/go-libp2p/blob/master/core/peer/peer.go
* https://github.com/libp2p/go-libp2p/blob/master/core/peer/addrinfo.go

## Questions
* There are some filtering of nodes being done while pinging or discovering peers, what is the basis of this filter? Need to dive more deeper.

## Future Roadmap
* Cover other segments of Prysm codebase wrt to libP2P
* beacon-chain/sync
* cmd/prysmctl/p2p
* crypto/ecdsa
* Get familiar with constantine codebase briefly.
I am feeling going through the codebase all at once might not work so well for me so maybe i will start with some components and their dependent codebases at a time and then proceed further.

## 💡 Weekly pill
Went through the article(one of the dicussions in the last ACD call on 27th June): https://nethermind.notion.site/Allowing-validators-to-provide-client-information-privately-bfea6436bfe246d28afdcda125d9049c

### Key Takeaways:
* There is lack of a standard method for anonymously showcasing the EL and CL clients being utilized, which is crucial for network resilience and diversity.
* The aim is to maintain user anonymity and avoid compromising network performance while gathering this crucial data.
* Several methods such as Homomorphic Encryption with MPC, MixNets (the models used by Orion Tor and Dandelion), use of Nullifier(as in Semaphore or better in PLUME), time-lock encryption are discussed along with their inherent problems and potential mitigation solutions.
* Significant discussions on the appropriate statistical data sample and the size of sample needed are also researched.
* Results of posting the data on grafitti field (modifications not possible), sharing of data over gossip network (slight changes can make it compatible for the usecase) etc show some of the possible solutions.

### Questions:
* What are the future steps if the validator client data is once available?
* How will client diversity be ensured if the client data is available, since the choice is open to the validators?
* If we are concerned with client diversity, can't we have some sort of channel or aggregator of clients to which a validator connects rather than connecting to a client and which in turn directs the validators towards a particular client based on the factors like availability, usage etc?