EPF-Week 0 updates

# Week 0 - The prelude The Ethereum Protocol Fellowship (EPF) Cohort 6 has officially begun, and this past week served as an important prelude to the work ahead. I primarily spent time scoping out potential projects to work on, reviewing recent ACD (All Core Devs) calls to understand current protocol priorities, and speaking with core developers I personally know to gain insight into the outcomes of the recent Berlin interop event. These conversations helped clarify which EIPs are likely to be included in the upcoming Glamsterdam upgrade. As part of my fellowship journey, I’ve set two key goals: - To contribute meaningfully to both the Execution Layer (EL) and the Consensus Layer (CL) of the Ethereum protocol. - To align my work with the most impactful and relevant EIPs targeted for Glamsterdam. With these objectives in mind, I’ve chosen to work closely with the Nimbus team, which actively maintains both the EL and CL implementations. Their focus on lightweight clients and protocol efficiency aligns well with my interests and provides an opportunity to engage work across both layers. Given this dual focus, I plan to undertake a project that offers exposure to the core components of both the consensus and execution layer clients — including networking, block production, validation, and related subsystems. By engaging with the full lifecycle of client operations, I aim to build a deep, hands on understanding of how changes at the protocol level are implemented and interact across the stack. This holistic approach will better position me to contribute meaningfully to both layers throughout the fellowship. ## Candidate EIP/Projects For the Cohort ### [FOCIL (EIP-7805) Implementation](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#nimbus-cl-focil-eip-7805-implementation) Fork Choice Inclusion Lists (FOCIL), proposed in [EIP-7805](https://eips.ethereum.org/EIPS/eip-7805), is a potential headline feature for the upcoming *Glamsterdam* upgrade. Given its significance and wide protocol implications, I’ve chosen to focus on implementing FOCIL within the Nimbus consensus client. To familiarize myself with the concept and the broader design trade offs, I’ve been closely studying the following resources: * [FOCIL Implementors’ Note by Jihoon Song](https://hackmd.io/@jihoonsong/ryTt1Fv7le) * [FOCIL for Glamsterdam – EthMagicians thread](https://ethereum-magicians.org/t/eip-7805-fork-choice-inclusion-lists-focil-as-a-candidate-for-glamsterdam/24342) * [Original EthMagicians Proposal](https://ethereum-magicians.org/t/eip-7805-committee-based-fork-choice-enforced-inclusion-lists-focil/21578) * [ETHResearch Post](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870) * [EIP-7805 Specification](https://eips.ethereum.org/EIPS/eip-7805) * [FOCIL Microsite](https://meetfocil.eth.limo/) Additionally, I am reviewing transcripts and summaries from recent breakout discussions and ACD calls along with the FOCIL breakouts,where FOCIL was debated, to gain more insight into community consensus and open questions. On the implementation front, I’ve already had an initial discussion with my assigned mentor, Agnish Ghosh (Nimbus CL), to better scope the work ahead. I’ve begun going throught the Nimbus codebase to identify the modules that would be directly impacted by this EIP — particularly around fork choice logic and Inclusion Lists.I also had a small talk with Jihoon and went over his note for implementors,link to which can be found below To supplement this, I am also reviewing the existing FOCIL related changes made by the Prysm and Lighthouse teams to better understand design patterns, testing strategies, and integration timelines. In the coming weeks, I plan to: * Brush up on Nim programming fundamentals * Draft a minimal “demo commit” outlining the proposed architecture and insertion points. If all goes well, I expect to begin initial code contributions shortly after completing my review and planning phase by this week. ### [deterministic-proposer-lookahead](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#teku--nimbus--lodestar--grandine-implement-eip-7917---deterministic-proposer-lookahead) This appears to be another compelling change within the Consensus Layer. I’ve already spent some time exploring it and, depending on how quickly I’m able to make progress with the FOCIL implementation, I’m considering taking this on as a follow up project. ### [fast-confirmation-rule](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#implement-the-fast-confirmation-rule) This proposal was posted a few days ago.It looks quite interesting and potentially impactful. ### [Pureth](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#besu--erigon--geth--nethermind--nimbus-el--reth-pureth-eip-7919) **EIP‑7919**, also known as **Pureth Meta**, bundles several enhancements aimed at improving Ethereum’s data accessibility, enabling trustless RPC verification, and empowering users to validate data without relying on centralized providers. It modifies block, transaction, and receipt structures to support efficient validity and completeness proofs in RPC responses crucial for preventing data spoofing from malicious or compromised nodes This can lead to better results from the Nimbus verified proxy from what I could understand. #### Materials - https://purified-web3.box/ - https://eips.ethereum.org/EIPS/eip-7919 - https://ethereum-magicians.org/t/eip-7919-pureth-meta/23273 This EIP is expected to be proposed as a headliner in the upcoming All Core Devs (ACD) call. I also had a conversation with Advaita Saha from the Nimbus eth1 (Execution Layer) team, who mentioned that the proposal is quite complex. Currently, some members of the Nimbus team are working on drafting a proof of concept (PoC) implementation to better assess its feasibility and design trade offs. Given its complexity and the early stage of PoC development, I’ve decided this may not be the right project for me to pick up at the moment. I’ll continue to monitor its progress and may revisit it later if it becomes more mature and aligned with the timeline of the fellowship. ### [Nimbus EL – Support Producing and/or Consuming ERA Files](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#nimbus-el-support-producing-andor-consuming-era1-era-e2ss-and-e2hs-files) recently explored the proposal for adding support in **Nimbus EL** to produce and/or consume the new ERA file formats not yet supported. During a recent [All Core Devs call](https://discord.com/channels/595666850260713488/745077610685661265/1384182602436706355), it was mentioned that two new file types are being introduced: - **ERA E** - **ERA C** interesting but not gonna work on it --- #### Other than I will not work on but had a look - **Delayed execution in nimbus** This is actually quite some work and the team needs to be more involved with the fellow for this project. So the nimbus team will themselves be handling this eip. - **ZKVM for nimbus EL** The team is ready but i dont personally wish to persue this topic. I have seen previous work in running the stf inside the diffent zkvms by G ballet for zeam,so dont want to work on something I am already kinda comfortable with. There was one more but forgot :) (maybe it was nimbus el impl of the erigon ideas) # Decided Project - FOCIL (EIP-7805) Implementation ## Plan #### **Phase 1: Familiarization with Relevant Codebases** * Deep dive into the **Nimbus consensus client** codebase to understand key internals. * Parallel exploration of **Prysm** and **Lighthouse** implementations particularly the modules impacted by FOCIL. #### **Phase 2: Test & Dummy Block Production** * Write a suite of **unit and integration tests** to verify FOCIL effects on block production and validator behavior. * **Dummy block production using Inclusion Lists (ILs)** to simulate FOCIL driven block proposal behavior in isolation. * Ensure these tests replicate edge cases and failure scenarios covered in other clients. #### **Phase 3: FOCIL Integration in Nimbus** * Implement the core logic for **FOCIL support in Nimbus** * Ensure compatibility with the latest FOCIL spec and consensus layer updates. * Perform local validation against spec driven test cases and sync behavior. #### Devnet Testing & Refinement * Deploy the updated Nimbus consensus client to a local devnet managed by Jihoon. * Observe behavior in a multi client setting, debug edge cases, and make any necessary adjustments based on real world block propagation and proposer activity. ### Future Work (Post MVP) (huge maybe) * Extend FOCIL implementation to **Nimbus execution layer (EL)** to support downstream integrations. * Explore **deterministic proposer lookahead** This is just a short plan.The better proposal and stuff are deliverables for next week along with everything else to get onboarded on the project # Next week Deliverables - [ ] Proposal draft for Nimbus FOCIL - [ ] Brush up nim and get started with tinkering the codebase - [ ] go through the Above links once again to skectch out a complete - [ ] Make the ppt for presentation at EthCC - [ ] Talk with other fellows and get to know each other - [ ] have a better broken down task list of objectives to tackle in the cohort agnish has done deterministic proposer lookahead :( # Contacts Discord: samyxandy twitter: [@Razorclient](https://x.com/Razorclient)