# EPF6 - Week 20 Updates
## Summary
1. Improved SSZ Info sanity checks in `ParsePath`.
2. Study of different Merkle Proofs approaches

## Details
### 1. [`ParsePath` PR](https://github.com/OffchainLabs/prysm/pull/15935) merged
In this PR I made several improvements to the code. Data types to hold the path now handle properly the requests:

type Path struct {
	Length   bool
	Elements []PathElement
}

type PathElement struct {
	Name string
	// [Optional] Index for List/Vector elements
	Index *uint64
}

With this change:
- A “length query” is always terminal, an SSZ-QL path cannot contain more than one len request.
- Path processing is simpler and more efficient, as the queries fit into types.

Prior to this PR, the path parsing function could parse any given path even if it was wrong. The function was 100% SSZ object-agnostic. With the feedback from mentor Radek, we agreed that it felt philosophically wrong.
In this regard, we agreed certain [rules for the sanity check of the arguments](https://github.com/OffchainLabs/prysm/pull/15935#issuecomment-3466756246) and a test suite to cover all these cases.

This PR relies on a function `func validateRawPath(rawPath string) error` which makes a cascade of sanity checks. We discarded `ChatGPT` generated regular expression because of it complexity. It feels better having a bunch of short understable steps rather than a regular expression of the size of a few lines paragraph long.

In general, this PR is not complex at all, but I'd like to highlight the positive outcomes from the discussions with Radek and Jun, which extended the scope and improve the clarity and efficiency of the code.

### 2. Merkle Proofs approaches
This is still a draft version of the different approaches to compute [general merkle proofs of arbitrary objects](https://hackmd.io/4W7J3qUdSuyzCBKFbF4iPw). This review takes into account the Merkle Proofs that are already computed in Prysm client (related to the Beacon State):
- `CurrentSyncCommitteeProof`
- `NextSyncCommitteeProof`
- `FinalizedRootProof`
I would need to extend it to be able to compute generic proofs and also, beyond the Beacon State merkle proofs, I have to compute the Merkle Proofs for Beacon Block to cover all two beacon-chain API endpoints introduced in SSZ-QL so far.

On the other side, we could foster `Fastssz` and `Dynssz` libraries to easily introduce a generic merkle prover.

[In my local repo](https://github.com/fernantho/prysm/tree/feat/introduce-merkle-proofs), I have worked on the implementation following DynSSZ approach. At this point, we can see merkle proofs generated for any top-level field of the Beacon State by using [ComputeFieldRootsWithHasher](https://github.com/fernantho/prysm/blob/27009f293b0e790408b5ee08ca61b09aef992aa8/encoding/ssz/query/treeproof/treeproofs.go#L15)

fieldRoots, err := state_native.ComputeFieldRootsWithHasher(context.Background(), st)

With little modifications, the behaviour of this implementation can be extended from top-level fields to any arbitrary element.

### Next steps
- Complete the study and implement the chosen solution
- Prepare the slides and the final report