# Week 5

The party has started.

The documentation is really cool. I tried compiling Lighthouse locally (damn those 1107 dependencies took 8min) on my 8GB RAM Mac M1 Air :)

As FCR is a Consensus Layer Feature (operates entirely within the beacon chain's fork choice logic, determining which blocks are "fast confirmed" and should be used as the safe head) I don't need to run Reth/Geth with it.

I will be working on unstable branch, and potentially, if the work goes good enough, the FCR research implementation can get merged after some polishing by Michael later.

This week :
* I wrapped up the high-level Proposal PR.
* Went through the new specification of FCR in detail to figure out the methods that I should be implementing/modifying in the Lighthouse codebase. At the start, I simply need to follow the specs.
* Tried to understand how committe weight estimation has happened. Lot's of probability and python scripting.
* Started punching some code in my unstable fork locally. Will start pushing code this week. As outlined in roadmap, I will create basic structure and CLI this week.

### Technical Fun
After so many days of writing Python, finally I am getting to write some Rust. And I am already learning some new Rusty things.

I noticed something new when going through Lighthouse ForkChoice. It is generic over `T` (the store type implementing `ForkChoiceStore<E>`) and `E` (the EthSpec). FCR will be integrated into ForkChoice, so it should follow the same pattern. However, FCR itself doesn't directly use the store - it will be called by ForkChoice methods. So FCR might only need `E` (EthSpec) and not `T` (store).

The `E: EthSpec` type parameter is needed in FCR struct because:
* `EthSpec` provides network constants - different networks (Mainnet, Testnet, custom networks) have different constants (SLOTS_PER_EPOCH, EPOCHS_PER_ETH1_VOTING_PERIOD, etc.)
* When we implement committee weight calculations - `get_committee_weight_between_slots()` and other FCR logic, we'll need access to `EthSpec` constants
* Most structs in Lighthouse use the `EthSpec` type parameter

So, we will have to wrap this up as `PhantomData<E>` - a zero-sized type that "holds" the type parameter E without actually storing any data.

The entire FCR has to be feature-gated, so that it's easy to enable/diasable, and can be tested independently when enabled.

EXCITED. Lets see how fast can I finish week 1 implementation up.