# Week 1 This week, I completed reviewing the "Key Resources" section of the Beam Chain Roadmap, gaining a solid understanding of the rationale behind the Beam chain. I contributed two PRs ([1](https://github.com/ReamLabs/beamroadmap/pull/29) & [2](https://github.com/ReamLabs/ream-study-group/pull/45)) to fix content links. Additionally, I joined the Ream Telegram Group and read through the first two months of messages. ## Ream Labs Repositories Overview Following this, I began exploring the repositories under [Ream Labs](https://github.com/ReamLabs): * [beamroadmap](https://github.com/ReamLabs/beamroadmap): this is the code for website https://beamroadmap.org * [ream-study-group](https://github.com/ReamLabs/ream-study-group): Documents the content from Ream's weekly study group sessions, held every Monday. * [ssz_types](https://github.com/ReamLabs/ssz_types) & [ethereum_hashing](https://github.com/ReamLabs/ethereum_hashing): These are common/primitive libraries forked from [Lighthouse](https://github.com/sigp/lighthouse). * [consenzero](https://github.com/ReamLabs/consenzero), [consenzero-bench](https://github.com/ReamLabs/consenzero-bench), [consensp1us](https://github.com/ReamLabs/), [zkvm-playground](https://github.com/ReamLabs/zkvm-playground): Repos focused on snarkifying the state transition function (and benchmarking it) of the consensus layer. * [ream](https://github.com/ReamLabs/ream): The Beam chain consensus client, written in Rust from scratch. I utilized [Deepwiki](https://deepwiki.com/ReamLabs/ream/1-overview) to understand the architecture of Ream, and now have a general grasp of its structure. ## Project selection Based on the knowledge acquired this week. I've considered four potential projects related to Ream: * [Ream Client - A Beam client in Rust: Build Beacon Validator Client](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#ream-client---a-beam-client-in-rust-build-beacon-validator-client): Since [The validator node depends on the beacon node through HTTP API communication](https://deepwiki.com/search/whats-the-relationship-of-beac_27c9b0d6-6e26-495e-a2e4-b2424bac7e71), but I prefer to focus on a single component with less context switching. Therefore, implementing the Beacon API, a key dependency, might be a more suitable project for me. * [Ream Client - A Beam client in Rust: 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): While I have limited experience with network programming and the implementation details of [rust-libp2p](https://github.com/libp2p/rust-libp2p), I would be happy to work on this project if the Beacon API project isn't feasible. * [Ream Client - A Beam client in Rust: Implement Beacon API Endpoints](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#ream-client---a-beam-client-in-rust-implement-beacon-api-endpoints): I would like to choose this project. It presents an excellent opportunity to learn the inner workings of the beacon chain through hands-on practice. My plan is to reference the [Annotated Beacon Chain Specification](https://eth2book.info/capella/part3/),[Consensus Specifications](https://github.com/ethereum/consensus-specs) & [Lighthouse](https://github.com/sigp/lighthouse). In Week 2, I will dedicate most of my time to this direction. * [Ream Client - A Beam client in Rust: Benchmark zkVM performance on Ream's Beacon state transition functions](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#ream-client---a-beam-client-in-rust-benchmark-zkvm-performance-on-reams-beacon-state-transition-functions): I have a basic understanding of Zero-Knowledge proofs (ZK) but lack hands-on experience with [Risc0](https://github.com/risc0/risc0), [SP1](https://github.com/succinctlabs/sp1) or other ZKVMs. I recognize that the snarkification of the Consensus layer is a primary goal of the Beam chain, and I intend to learn ZK and ZKVMs by following the Ream Study Group. ## Resources [Ream Telegram Group](https://t.me/ReamLabs) [sszb](https://github.com/ghiliweld/sszb): a more performant implementaion of SSZ, Ream devs mentioned they want to use but currently [ethereum_ssz](https://github.com/sigp/ethereum_ssz) is in use. [Hash-based signatures II - Lamport and Winternitz one-time signatures](https://www.youtube.com/watch?v=K8Mvnau5zlE): Post-quantum cryptography content shared in Ream Telegram Group. [alloy-core](https://github.com/alloy-rs/core): Ream primarily utilizes its primitives and RLP library.