EPF6 - Week 1 Updates

# EPF6 - Week 1 Updates ## Summary - Explored the existing Prysm's codebase. - Reviewed other options for Prysm (e.g. Migrate e2e using [Assertoor](https://github.com/ethpandaops/assertoor)) ## Details As I shared in [Week 0 updates](https://hackmd.io/@junsong/By7s6Dp7eg), I'm interested in **[generalizing merkle proofs for Prysm](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#prysm-merkle-proofs-of-everything)**. Since Prysm uses [Bazel](https://bazel.build/) as a main build tool, I've reviewed my experience of using Bazel and ran some tests (e.g. e2e) in my local environment. Prysm has hard-coded logics for each field in the beacon state(See [`proofs.go`](https://github.com/OffchainLabs/prysm/blob/develop/beacon-chain/state/state-native/proofs.go)). Some of the functions and constants can be generalized: 1. [`finalizedRootIndex`](https://github.com/OffchainLabs/prysm/blob/667aaf15648346a72aff5b24d425cf6a18802a42/beacon-chain/state/state-native/proofs.go#L13-L15) (and also `CurrentSyncCommitteeGeneralizedIndex`, `NextSyncCommitteeGeneralizedIndex`): currently precomputed as `105`, but if we want to generalize the proof generation, this can be replaced. 2. [`CurrentSyncCommitteeProof`](https://github.com/OffchainLabs/prysm/blob/667aaf15648346a72aff5b24d425cf6a18802a42/beacon-chain/state/state-native/proofs.go#L62-L78), [`NextSyncCommitteeProof`](https://github.com/OffchainLabs/prysm/blob/667aaf15648346a72aff5b24d425cf6a18802a42/beacon-chain/state/state-native/proofs.go#L62-L78) and [`FinalizedRootProof`](https://github.com/OffchainLabs/prysm/blob/667aaf15648346a72aff5b24d425cf6a18802a42/beacon-chain/state/state-native/proofs.go#L80-L108): These functions share almost identical logic, the only different point is calling `RealPosition()` function for dedicated field. --- Also, I slightly reviewed other options in the [project list](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md), and found [**Prysm: Migrate e2e to Kurtosis**](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#prysm-migrate-e2e-to-kurtosis) is also quite interesting. Based on my previous experience, using Kurtosis to spin up a custom devnet was cool in terms of its convenience and also integrating with CI. Lighthouse already runs a [script](https://github.com/sigp/lighthouse/blob/999b04517e35f8fce78525132d0b8e0a4816f31e/.github/workflows/local-testnet.yml) for local testnet in part of CI. In my knowledge, Prysm uses [Buildkite](https://buildkite.com/) to leverage its Bazel-based build system, but I believe Kurtosis can also fit well to the CI tools other than Github Action. [Assertoor](https://github.com/ethpandaops/assertoor) is also great: developers can pre-define and custom test suites for specific cases. Moreover, it provides a high visibility UI which might help new contributors a lot. I didn't explore much about the `endtoend` package in Prysm and what it evaluates as well, so I need to spare more time on this for a couple of days. ## What's next - Structurize of the process for each proof generation. - Explore `endtoend` package in Prysm.