---
# System prepended metadata

title: EPF cohort 4 Week 10 - 11 update

---

# Week 10 - 11 
## Intro
Over the past two weeks, my primary focus has been on completing the initial two phases of my project proposal.

1. Exposing information regarding missed finalized and non-finalized blocks for the selected validators you intend to monitor and its Grafana metrics.
2. Understanding the [BeaconProcessor](https://github.com/sigp/lighthouse/tree/unstable/beacon_node/beacon_processor) 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
- In my last update, I emphasized that the final step would involve implementing comprehensive tests to examine the code, which introduces missed block metrics in LH.

- I found myself delving into the code to comprehend how tests were conducted for other components, given the lack of available tests for the validator monitor component - the one responsible for appending metrics to a validator list that the node operator wants metrics from. Luckily, the LH team created a useful utility named 'harness beacon chain.' This tool conveniently allows a developer to mock its dependencies and establish the state of a beacon chain at a specified slot. Consequently, this facilitated the crafting of several test scenarios for my code, such as (eg. scenario 1):

![](https://hackmd.io/_uploads/HJHis8hl6.jpg)

- Folowing this, I had quite a lot of back and forth with Paul Hauner on my [PR](https://github.com/sigp/lighthouse/pull/4731/files) fixing a few issues. It should be merged very soon!

## Scheduler analysis
### Context
- As adding the missed non-finalized blocks is almost done, I moved on to the second part of my EPF project which is analyzing the [BeaconProcessor](https://github.com/sigp/lighthouse/tree/unstable/beacon_node/beacon_processor) and adding a Grafana dashboard that would potentially highlight some performance issues.

- After a talk with Paul asking if I was on the right path, I kept on learning more about that Scheduler and the different tasks it's handling as well as its technical implementation.

- I had to read a few things about the network layer [Gossip](https://ethereum.org/en/developers/docs/networking-layer/#gossip) and some specific events such as [Gossip Lightclient events](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md). You can find a comprehensive list [here](https://github.com/sigp/lighthouse/blob/stable/beacon_node/beacon_processor/src/lib.rs#L1350).

### Next steps
- Having concluded the tests and validated the (nearly) final modifications with Paul Hauner, I will proceed to integrate the chart  into the lighthouse-metrics repository. Consequently, Part 1 of my project proposal has nearly reached completion.

- Upon conducting a more thorough investigation into Gossip, I will also incorporate a Grafana Dashboard.

- Once everything is merged, I plan to compile my own version of LH and deploy it on either Holesky or Sepolia, depending upon the stability of the network. Interestingly, more missed blocks would actually be advantageous in my situation!
