# Week 7

The [2nd PR is up with core LMD-GHOST FCR implementation](https://github.com/harsh-ps-2003/lighthouse/pull/2), yet to be reviewed by Michael. The FFG will be the next PR.

There are some architectural discussions that I will have this week about this PR along with next PR to ensure a basic performant implementation.

### Current Architecuture Observations

Looking at the Ethereum consensus specification, the Store class has `checkpoint_states: Dict[Checkpoint, BeaconState]`, but Lighthouse's `ForkChoiceStore` trait doesn't provide access to checkpoint states because:

* *Memory Efficiency:* Storing all checkpoint states in memory would be prohibitively expensive
* *Separation of Concerns:* The fork choice crate shouldn't directly depend on the store crate
* *Tree-States Architecture:* Lighthouse uses tree-states which makes state access more complex

Michael has suggested to add a `StateProvider` trait, mainly due to these reasons :
* *Modularity:* Keep fork choice independent of store implementation. Also can be stored by multipe store backends.
* *Leverage Existing Infrastructure:* Use HotColdDB's state cache. Good for performance as well
* *Support FCR Requirements:* Provide access to checkpoint states when needed as per spec

Will have fun implementing these after a good review. I make huge PRs, so review might take some time.

From now, will make smaller PRs. For the core implementation, I had to follow the spec directly (almost..) so a big fat PR made sense.

Signing off. Peace...