---
# System prepended metadata

title: Week 12 Update
tags: [EPF]

---

# Week 12 Update

A greatly productive week! This week started where the [last one](https://hackmd.io/@Odinson/SyvHbi-9le?stext=6775%3A67%3A0%3A1757230472%3AgxEw2h) left off. I got some review comments from Michael on my updated [PR](https://github.com/sigp/lighthouse/pull/7803). So I worked on them, ran benchmarks, lighthouse nodes locally and kept staring at the logs... for a long, long time😅. i might have spent most of last week looking at logs so yeah, can feel the essence of working as a core dev pretty well :P

Other than that, I also worked on an [issue](https://github.com/sigp/lighthouse/issues/7995) that Michael created, regarding 
> extra field in logs being displayed post instrumentation

Will talk more about it below.

Also, Eitan from Lighthouse joined the [Office Hours](https://github.com/eth-protocol-fellows/cohort-six/issues/345) today, and had a great time getting to know his journey, how he transitioned from a fellow to core dev at sigp, and learnt about his work, PeerDAS and more.

## Work for the week

I believe just after I made last week's update, on Monday Michael reviewed my PR again, and left some comments. While mostly some smol changes and stuff, but one important overlook from my side, that was the [subtrees calculation](https://github.com/sigp/lighthouse/pull/7803#discussion_r2312957350) in the `impl MemorySize for BeaconState`. This is the reason that the `beacon_state_memory_size_calculation_time_count` from [Week 11 Update](/oDytdz2CRmOSM81dd5TV2A) was in micro seconds. So I had to work on getting the accurate `MemorySize` of each `BeaconState` and it's tree fields using the macros in the [beacon_state.rs](https://github.com/PoulavBhowmick03/lighthouse/blob/642d348e394c04e20cb15d83489ebfcff9d1fbdb/consensus/types/src/beacon_state.rs) to calculate the nestings.

This was a little difficult to get around because, I had the `memsize.rs` file inside the [store](https://github.com/sigp/lighthouse/blob/9fce9a4914aff936a2d5a671e6961030439aff5c/beacon_node/store/src/memsize.rs) directory. For that reaason I was using a `BeaconStateWrapper` to use the BeaconState from `types` crate and had an additional trait [BeaconStateMemorySize](https://github.com/sigp/lighthouse/blob/9fce9a4914aff936a2d5a671e6961030439aff5c/beacon_node/store/src/memsize.rs#L28) for the `MemorySize` calculation. But once I tried moving the `memsize.rs` to the `types` crate, I was no longer needed to use the wrapper and the trait, which was a plus, but the [BEACON_STATE_MEMORY_SIZE_CALCULATION_TIME](https://github.com/sigp/lighthouse/blob/9fce9a4914aff936a2d5a671e6961030439aff5c/beacon_node/store/src/memsize.rs#L39) metric I had inside the trait to measure the amount of time needed to measure the `MemorySize` was no longer possible to be used, as importing `beacon_node` to the `types` crate led to cyclic dependency problem of 
`types` <=> `beacon_node` <=> `account_utils` <=> `types`

So I had to move the time calculation inside the [state_cache.rs](https://github.com/sigp/lighthouse/blob/c5441b4d513055465dd4d89fc8a9e1f2eba4c08d/beacon_node/store/src/state_cache.rs#L432) `measure_cached_memory_size` function.

One advantage of moving the `memsize.rs` to the `types` crate is that i was able to use the `map_beacon_state_*_tree_list_fields_immutable!` macros for `subtrees` calculation. 

But to implement `subtrees` function, I had to make sure some trait bounds were satisfied. Hence, added `impl Eth1data, Validator, ParticipationFlags, PendingAttestation, HistoricalSummary, PendingDeposit` etc to `memsize.rs`.
Lastly, when I tried to `impl MemorySize for FixedBytes`, it was failing because both `MemorySize` and `FixedBytes` were from external crates. So I had to make a change to Milhouse repo and add the `impl MemorySize for FixedBytes`, for which I opened a [PR](https://github.com/sigp/milhouse/pull/78).

So I made those changes, along side some other minute changes like removing the `state-cache-max-bytes` from `chain_config`, renaming `state-cache-max-bytes` to `state-cache-max-MiB` in store config, changing
```rust
if let Some(max_bytes) = cli_args.get_one::<String>("state-cache-max-bytes")
```
to use `parse_optional` instead, which made it less verbose.

Apart from that, worked on this [issue](https://github.com/sigp/lighthouse/issues/7995) where, instrumentation led to extra fields displayed in logs.

> Aug 27 03:12:14.471 WARN State cache missed state_root: 0xabbf84a7d9e8305916ddd9558f27241aa7a4bc22d5f4455d5ce4b6aea42a50b7, block_root: 0xc6dfece48906334a091f99cd5f07826ff00816b5765fd0caa34771efcafadafe, state_root: 0xabbf84a7d9e8305916ddd9558f27241aa7a4bc22d5f4455d5ce4b6aea42a50b7, block_root: 0xc6dfece48906334a091f99cd5f07826ff00816b5765fd0caa34771efcafadafe, index: 1, block_root: 0x6ddc3ab728146617dc9626938c53c285d8703b0aa234c0e32ec5f9d59fa967d3, slot: Slot(12453293)

Since this is something even I faced while running the logs, worked on this, ran the logs again and found it to be fixed, created a [PR](https://github.com/sigp/lighthouse/pull/8009) for the same
![telegram-cloud-photo-size-5-6188434625676822532-y](https://hackmd.io/_uploads/SJtKh395xg.jpg)


## Resources

1. Project [PR](https://github.com/sigp/lighthouse/pull/7803)
2. [beacon_state.rs](https://github.com/sigp/lighthouse/blob/9fce9a4914aff936a2d5a671e6961030439aff5c/consensus/types/src/beacon_state.rs) in LH's types crate
3. [Lighthouse Book](https://lighthouse-book.sigmaprime.io/advanced_database.html#hierarchical-state-diffs) on HDiffCache and it's memory
4. Extra fields in Logs [issue](https://github.com/sigp/lighthouse/issues/7995)
5. Milhouse [PR](https://github.com/sigp/milhouse/pull/78) to implement `MemorySize` for `FixedBytes`
## Conclusion

A good week overall, awaiting further comments from Michael and Dapplion on the PR. Meanwhile I will be looking forward to running the logs and checking for the `memory_size` change, on spaming HTTP queries, and if possible, pick up some other works in LH codebase.
