---
# System prepended metadata

title: EPF cohort 4 Week 8 - 9 update

---

# Week 8 - 9 
## 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:

1. Exposing information regarding missed finalized and non-finalized blocks for the selected validators you intend to monitor.
2. 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.

## Exposing Validator Missed Block Metrics
### Context
- Gain a comprehensive understanding of the sequential steps required to flag a missed non-finalized block, including the relationship between slots and block_root_hash.
- Anticipate potential false positives that may arise in cases where the blockchain forks, affecting the accuracy of the metrics.
- Identify specific code components that require modification, such as sharing a cache between different code components, altering existing code such as state.proposer_shuffling_decision_root and addressing any cache limitations is crucial.

### Technical Reading:

During the implementation of the initial draft, numerous questions surfaced, prompting a return to "[the Ethereum Bible](https://eth2book.info/)" for clarification such as:

- The validation frequency of the state and its technical implementation — whether it undergoes validation for every state or every epoch — can be found in the source: https://eth2book.info/capella/part3/initialise/.
- The content of "that object" state in terms of the number of slots it encompasses, and whether it constitutes the entire or partial state history since the merge. eg. Is all the data that I need is already in the state?
- Consideration of maintaining a shared cache with consistent mutex across different repository components.
- Further insights into Ethereum concepts:
    - A deeper dive into the crystallized state and active state, with reference to historical information: https://eth2book.info/capella/part3/containers/state/#historical-note.
    - Understanding the fundamentals of block proposer shuffling, a critical building block in the Ethereum ecosystem: https://eth2book.info/capella/part2/building_blocks/shuffling/.
- While working on the initial draft, I encountered some challenges with the Rust borrow checker, which prompted me to delve deeper into its intricacies while refactoring existing code.

### Solution
After a review with a team member at LH, I opened a [PR](https://github.com/sigp/lighthouse/pull/4731) aimed at incorporating missed non-finalized metrics into LH.

In response to the feedback from the team, I undertook some refactoring to enhance readability and refine the algorithm so becomes smaller. This effort serves the dual purpose of making it easier to integrate the missed finalized blocks metrics alongside the missed non-finalized blocks metrics once this is merged. Furthermore, this step will enable us to conduct a meaningful comparison and assess the difference between the missed non-finalized blocks vs finalized blocks.

If there's only a few differences and that it's actually relevant, we could modify the Ethereum recommended Prometheus metrics repository. 

### Next steps
I am in the final stages of adding the necessary tests and finishing the Grafana dashboard.
