# Week 1 Update: Odinson
This week I explored various topics regarding the project I am planning to create a proposal on, and worked on some issues. Went further into the codebase of Lighthouse and studied about Caching

I have been thinking of choosing one of the projects to look into, research and work on, between Lighthouse's [Checkpoint sync from non-finalized endpoint](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#lighthouse-checkpoint-sync-from-a-non-finalized-checkpoint) and [Better state cache heuristics](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#lighthouse-better-state-cache-heuristics) and finally decided to go with the latter. So after that, I looked into the caching system of Lighthouse, how the LRU cache implementation works. Looked into different types of caching algorithms and what would be the most promising for the requirements during a time of non finality or similar to what happened in Holesky incident.

Apart from that, I also went through the [Consensus Layer Data Structure](https://www.youtube.com/watch?v=1CWqDDZauoU) lecture by Michael Sproul during the study group, to understand about the Beacon State, how the state management happens and its internal structure. The Beacon State is a data structure containing validator registries, balances, attestations, and various fields organized in a merkleized tree format. During block processing, Lighthouse processes state transitions by applying operations like deposits, attestations, and exits sequentially, updating the branches of the state tree. The state is stored using a forkchoice aware DB (BeaconChain store) where historical states are maintained with a hot/cold split: recent states in the hot database for quick access and older finalized states in the freezer database.

## Research

### Caching in Lighthouse

Currently Lighthouse uses a fixed LRU caching algorithm, having default size 128, that is unable to adapt to volatile network conditions. During the [v7.0.0 release](https://github.com/sigp/lighthouse/releases/tag/v7.0.0), it was changed to [32](https://github.com/sigp/lighthouse/pull/7101/files) to manage memory during non-finality, but it caused significant cache misses, which led to [v7.0.1 hotfix](https://github.com/sigp/lighthouse/releases/tag/v7.0.1), changing the default size to [128](https://github.com/sigp/lighthouse/pull/7364)

This custom time based LRU cache implementation has it's own advantages, but it does not distinguish between finality and non finality conditions and uses the same strategy regardless of the state.

The [common/lru_cache/src/time.rs](https://github.com/sigp/lighthouse/blob/999b0451/common/lru_cache/src/time.rs) file is where the `LRUTimeCache` struct is defined, having a dual data structure approach with `FnvHashSet` for fast lookups and `VecDeque` an ordered list to maintain insertion order.
Most LRU caches in Lighthouse use the external `lru` crate which provides a standard implementation.
The [beacon_node/store/src/state_cache.rs](https://github.com/sigp/lighthouse/blob/999b0451/beacon_node/store/src/state_cache.rs) has the `StateCache` struct which has custom culling logic with

#[derive(Debug)]
pub struct StateCache<E: EthSpec> {
    finalized_state: Option<FinalizedState<E>>,
    // the state_root
    states: LruCache<Hash256, (Hash256, BeaconState<E>)>,
    block_map: BlockMap,
    max_epoch: Epoch,
    head_block_root: Hash256,
    headroom: NonZeroUsize,
}

Lastly, the `BlockCache` in [beacon_node/store/src/hot_cold_store.rs](https://github.com/sigp/lighthouse/blob/999b0451/beacon_node/store/src/hot_cold_store.rs) provides the caching for blocks and data columns using separate LRU caches for each

#[derive(Debug)]
struct BlockCache<E: EthSpec> {
    block_cache: LruCache<Hash256, SignedBeaconBlock<E>>,
    blob_cache: LruCache<Hash256, BlobSidecarList<E>>,
    data_column_cache: LruCache<Hash256, HashMap<ColumnIndex, Arc<DataColumnSidecar<E>>>>,
}

## Resources
This past week, I went through these articles, videos, codebase and looked into it
- [CL Data Structure](https://www.youtube.com/watch?v=1CWqDDZauoU)
- [Beacon State Specs](https://eth2book.info/latest/part3/containers/state/)
- [Adaptive Replacement Caching algorithm](https://60sec.site/terms/what-is-arc-in-computing-adaptive-replacement-cache)
- [Beacon Chain Explainer](https://ethos.dev/beacon-chain)
- [Holesky Post-mortem](https://github.com/ethereum/pm/blob/master/Pectra/holesky-postmortem.md)
- [Checkpoint Sync in Lighthouse](https://lighthouse-book.sigmaprime.io/advanced_checkpoint_sync.html)
- [Database configuration in Lighthouse](https://lighthouse-book.sigmaprime.io/advanced_database.html)
- In order to solve an issue, looked and read the [PeerDAS specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/fulu/das-core.md)
## Work for the week

- [Lighthouse(Box inside `BeaconChainError`)](https://github.com/sigp/lighthouse/pull/7623)
- [Lighthouse(Removing `DataColumnInfo` from PeerDAS implementation)](https://github.com/sigp/lighthouse/pull/7624)

## Conclusion

A decent week overall, the project proposal is taking some shape and I have asked for the initial feedback from Mario. Apart from that, I plan to look into the database configuration of Lighthouse, their split DB architecture of hot and freezer db. Also, I will be looking for more issues to work on, and get myself comfortable working with the codebase. I will be looking for resources, articles for ARC implementation, how that works, and one again go over some other interesting topics from the Study group.