Abstract My project involved incorporating metrics into Lighthouse, Sigma Prime's consensus layer written in Rust. During this project, my aim was to deepen my understanding of the consensus layer's specifications and how it effectively orchestrates and implements the various rules of the Ethereum protocol. You can find the project proposal here. Project state Expose the Missed block metrics within the monitored pool of validators This was the initial project I embarked on while working on Lighthouse (LH). It necessitated a decent understanding of several aspects of the consensus layer, involving substantial time delving into eth2book, particularly the sections about the beacon node, the state, and their specifications for different fork names. This work marked my first step into working at the consensus level. Additionally, I needed to familiarize myself with certain LH specific concepts as the project focused on their monitoring component, the validator monitor. I also took my time to implement a set of comprehensive tests which really helped me understand exactly how the state is validated throughout its lifetime.

TL;DR As we are all heading to DevConnect, this will be a shorter presentation than usual. Wrapping up my projects, preparing the presentation, preparing the last dev update, rerunning the version of Lighthouse with my changes on Goerli. Exposing Validator Missed Block Metrics Context I recently updated and recompiled the latest version of LH to generate new charts for my upcoming project presentation at Istanbul DevConnect on Friday. Additionally, I configured the validator monitor with 15,000 keys for tracking, ensuring we'll have ample data for our presentation's charts. During this process, I noticed LH was generating numerous warning messages. Upon closer investigation, I discovered an issue with the log message implementation. Michael Sproul had also identified this problem and submitted a pull request to address it. Michael's fix is successfully eliminated the warning messages. As soon as the metrics start rolling in, I plan to update the lighthouse metrics dashboard. I previously created. This update is crucial as it doesn't currently include the latest metrics incorporated into LH. My goal is to ensure that the data in my graphs is current and accurate, making this likely the final update I'll need to make before the presentation.

TL;DR Over the past two weeks, my primary focus has been on starting the last part of my project proposal which aims at adding an attestation simulator in order for Lighthouse to evaluate the implication of attestating 32 times per epoch. That's quite important in terms of performance as well as it helps understand how a consensus client would transition to protocol's behaviour changes such as SSF in combination of increasing the max balance. Digging into the different committees, the caching implementations of LH and the interaction between the Validator Client and the Beacon node when producing and signing the aggregations. Also, I created a PR introducing the first metrics to see how LH behaves if it were to simulate one attestation per slot. I've resolved the last issue with the tests related to the missed block feature, and the PR has been merged into the unstable branch of LH for testing. Exposing Validator Missed Block Metrics Context After Paul helped me wrap up the PR, I realised that the tests did not work for all the different fork names. This issue led me to delve into understanding how the specifications were incorporated into the BN harness (the name assigned to the generated BN in the tests) for those various forks.

TL;DR Over the past two weeks, my primary focus has been on wrapping up the initial two phases of my project proposal and running those changes on Holesky. It actually took more time than initially anticipated and the iterations of my solution also highlighted areas of improvement and potential issues. Hopefully we had the last round of back and forth on the added missed blocks of the monitoring component of Lighthouse. It's quite a critical component as Paul Hauner pointed out. I proposed to the team a chart layout that I added to their lighthouse-metric repository to see the new implemented metrics for the missed blocks. Running my own version of Lighthouse with my changes on Holesky. With that being said, the next report will be about the last step of my project proposal which is adding an attestation simulator in order for Lighthouse to evaluate the implication of attestating 32 times per epoch. That's quite important in terms of performance as well as preparing some transitions such as SSF and increasing the max balance. Exposing Validator Missed Block Metrics

Intro Over the past two weeks, my primary focus has been on completing the initial two phases of my project proposal. Exposing information regarding missed finalized and non-finalized blocks for the selected validators you intend to monitor and its Grafana metrics. Understanding the BeaconProcessor and adding a Grafana dashboard which might highlight some performance issues. This effort marks a step toward achieving the first two steps of my project proposal, enhancing monitoring capabilities, and providing valuable insights to users and developers. Exposing Validator Missed Block Metrics Context

Week 6 - 7 Intro This report will be relatively more concise compared to my usual reports as I had a brief holiday break. I dedicated my time to more reading, focusing on topics that would prove beneficial for certain aspects of my project proposal— specifically regarding optimizing programming performance in Rust. Additionally, during these two weeks, I have successfully finalized and prepared my project proposal presentation scheduled for week 8 as well as reaching out to the Lighthouse team. Project's proposal You can read it here: https://github.com/eth-protocol-fellows/cohort-four/blob/master/projects/improve-metrics-and-performance-lighthouse.md and the slides are here: https://app.pitch.com/app/presentation/08f399bb-082c-48d5-964f-9eb8b89e9d63/5f8d7864-707d-487a-a7ee-a1559a8940e7/aec7f5e7-f5b3-49f1-8064-9a3ad9936577 Improving Lighthouse metrics and performance

Intro Over the past two weeks, my primary focus has been on completing the initial phase of my project proposal, which involves incorporating essential metrics into Lighthouse. LH offers the capability to monitor a specific set of validators, enhancing the accessibility of crucial metrics through Prometheus. The initial phase entails the following key tasks: Exposing information regarding missed finalized and non-finalized blocks for the selected validators you intend to monitor. Implementing a Grafana dashboard that allows Lighthouse users to observe these missed blocks in real-time. This effort marks a step toward achieving the first step of my project's proposal, enhancing monitoring capabilities, and providing valuable insights to users.

Week 4 - 5 Intro I started working on some issues on Reth, but I quickly realized that the project was more complex than I had anticipated. The code base was highly intricate, making it difficult for me to dive straight in and get started. Additionally, there were many other developers interested in committing to the project, including both fellows and non-fellows. This made it highly competitive just to apply to issues that would help me understand the code base and get familiar with the different crates (packages). Also, it seems that although you are the first responder to a "first good issue", the chances of being "snipped" by another developer are pretty high. We decided with another fellow Alessandro to contact the Reth team trying to get a research topic or something more significant that would help us get started and feel more comfortable with the code base. We asked for more sustainable projets that they have in their backlog. As the validator client is still in an alpha state, the devs were feeling more comfortable by tackling those issues themselves - which is totally understandable. While Reth is an amazing project with highly competent and passionate developers, I found it overwhelming as a newcomer to the world of core development and that as I am also still working for my current company, I need a slightly different set up in order to succeed in making this cohort a success and struggling over getting issues jeapordise my goals. That sets me back to looking more into Lighthouse's project ideas and I really enjoyed looking and learning m that area of core development and I have decided to work on several projects.

Hey, I am Joel Rousseau and these are my updates for the week 2 of the cohort 4. My primary goal for these first two weeks (most likely the second week as I exceptionally couldn't free myself the first week) was to read more about the different project(s) and find out what I would be most interested in working as well as the programming language I will be using. TL;DR Read a lot of documentation, many different EIPs, technical implementations and finally committing to Rust validator clients (el/cl) Played around with validator clients code base Lighthouse and Reth Looked at those projects’ PRs, development books, basically getting ready to start contributing Looked into some of our own issues while running the couple Lighthouse/Reth on Goerli

Hey, I am Joel Rousseau and this is my update for the week 3 of the cohort 4. My primary goal for this third week was to prepare myself for contributing to the code base of Reth. I quickly realized that there were barely any "first good issues" available that were not already claimed and that if I wanted to tackle more serious issues, I would need to improve my overall knowledge of the project as well as my Rust skills as I encountered some unfamiliar concepts while going through the code base. Learning I usually use Rust for casual setups, such as writing a quick client or a bot. However, delving into the Reth codebase made me realize that in order to achieve good composition, I also need to be familiar with more advanced concepts, including: Advanced Traits