## Summary

- Reviewed list of proposed projects (one again), overall the projects related to [this light client list](https://hackmd.io/@etan-status/electra-lc#Light-client-roadmap-for-Electra).
- Continued catching up with latest CL trends and ZK.

## Updates

During the week 1, my main concern has been the selection of a project. As depicted in [my week 0](https://hackmd.io/jrepFb3ySCW9dCoIYD4siQ#List-of-projects) update, my idea prior to the beginning of the cohort was to make a project in the line of [Prysm: Merkle Proofs of Everything](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#prysm-merkle-proofs-of-everything). I think this project can fit into my EPF as I'll be part time (at least at the beginning) and I have prior knowledge generating merkle proofs of beacon state's validator field:
- withdrawals credentials
- exit epochs
- slashed

So, making proofs generalization in this project would be great, no need for a catch up, just directly hands on coding (plus the potential extension or side use of it mixing with ZK). During this week I've locally had a look at Prysm's code.

I also have reviewed [Prysm: SSZ Query Language](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#prysm-ssz-query-language) forwarding me to [this](https://hackmd.io/@etan-status/electra-lc#SSZ-query-language). Thanks to this I was led to these two interesting EIPs (I did not know):
- [EIP-7495: SSZ StableContainer](https://eips.ethereum.org/EIPS/eip-7495)
- [EIP-7688: Forward compatible consensus data structures](https://eips.ethereum.org/EIPS/eip-7688)

Forward compatibility is a MUST. Merkle proofs of validators' fields are not forward compatible from Deneb to Pectra as the `Beacon State` container has been modified ([increased the fields reaching to a new power of two](https://ethereum-magicians.org/t/eip-7688-forward-compatible-consensus-data-structures/19673/2)) leading to a change in generalized indexes. While these changes are little and fixes can be made in no time, it is not desirable to have to make it, protocols upgrade are always critical and, in general, one of the target of blockchain projects is to ossify, to be immutable to prevent trust (even in multisigs).

Last but not least, I have also reviewed the project [Implement the Fast Confirmation Rule](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#implement-the-fast-confirmation-rule). I find it very promising and appealing. I still need to deep dive into it: understand properly the rule and check:
- how it would behave in extreme conditions as the Pectra holesky issue
- what would have happen in this escenario where the majority of the chain was misconfigured?
- how this Fast Confirmation Rule works in period of deep reorgs?

## Next steps
- Choose the project and make a plan so I can present it at EPF day