# EPF Cohort 6 - Week 0 Update Before the cohort starts, I aim to narrow down the area I want to spend the most time working on. I have a deep fascination for distributed systems, which led me to gravitate towards consensus layer clients. After catching up on the study group material covering consensus layer topics and validator architecture, I realized I want to contribute effectively to a promising project in its early stages. This approach gives me the opportunity to learn extensively through hands-on experience. As I've been learning Rust for a few months now, the following proposed projects caught my attention: [Ream: Build Beacon Validator Client](https://github.com/eth-protocol-fellows/cohort-six/blob/49e69e4fb8d3bab7ec5b30cdf81faeddb239d50d/projects/project-ideas.md#ream-client---a-beam-client-in-rust-build-beacon-validator-client) [Ream: Build out P2P testing](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#ream-client---a-beam-client-in-rust-build-out-p2p-testing) ## Areas of interest ### Validator Client Ream is developing a Validator Client for the upcoming Beam Chain. To build the necessary experience and tooling infrastructure, they're starting by creating a validator client for the current Beacon Chain. I believe the Beam Chain represents significant improvements to Ethereum's consensus layer, and I'm eager to contribute to a Beam client in the future. Since Ream is building their validator from the ground up, this presents a solid opportunity for me to gain a lot of experience in building a validator. Additionally, working on this project will prepare me for transitioning to the Beam Chain, allowing me to contribute effectively once the specs are released. ## Week 0 I dove into validator architecture to understand the design decisions I'd need to make during my implementation. One of the considerations was whether to use a system timer-based approach to determine the slot for protocol duties or leverage the Beacon Client's events API to perform duties based on events streamed from the beacon node. I reached out to one of the project leads (Kolby ML) and expressed my interest in working on the Validator Client. They welcomed my involvement and were excited to have me on board. I began building the foundation by implementing core consensus specification functions that are used accross the validator. This included functions such as checks for `⁣is_proposer`,`is_aggregator`,`is_assigned_to_sync_committee`, and others defined by the [honest validator specs](https://ethereum.github.io/consensus-specs/specs/electra/validator/). ## Resources The following resources were instrumental in helping me understand Validator Client architecture: - [Relevant Beacon API for Validators](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi) - [Validator Flow](https://ethereum.github.io/beacon-APIs/validator-flow.md) - [Validator Architecture - Prysm](https://epf.wiki/#/eps/day20) - [Ethereum Proof-of-Stake Mechanism](https://www.youtube.com/watch?v=5gfNUVmX3Es&t=165s&ab_channel=AltExplainer)