# EPF6 - Week 5 Updates

## tl;dr

- Refined the proposal to make it concise, finally opened a [PR](https://github.com/eth-protocol-fellows/cohort-six/pull/177).
- Several discussions about technical stuffs with Nando.
- Started coding!

## Details

I dedicated most of my time to 1) refine the proposal ([PR](https://github.com/eth-protocol-fellows/cohort-six/pull/177) is open now.) and 2) discuss with [Nando](https://github.com/fernantho) about the scope of our project and document management.

### Finalized the Proposal


Last week, we kindly requested to our mentors and Etan for reviewing our proposal. After few rounds of review-and-apply, I believe we made a concrete proposal document that is clearly scoped (and our mentors liked it 👍). You can check the [PR](https://github.com/eth-protocol-fellows/cohort-six/pull/177) that adds the proposal in the EPF repository.

There were two major decisions this week:

- **Concised the proposal**: By directing a link to our [spec document](https://hackmd.io/@junsong/rkAN9lIIxx), I don't have to open an extra PR to change the design details that might be flexible. Also deleted a bunch of lines so it is better in terms of readability.
- **UX consideration**: UX matters, as we aim for our project to be used by real users in this ecosystem. After discussing with [Nando](###Discussion-with-Nando) and Radek, we decided to fix the request/response structure. A response now contains its path as below, so now it's more self-contained. Also `state_root` is renamed to `root` and placed at the upper level of the object: so this reduces redundancy.

{
    "version": "electra",
    "execution_optimistic": false,
    "finalized": true,
    "data": {
        "result": [
            {
                "path": ".validators[100].withdrawal_credentials",
                "value": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
                "proof": [
                    "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"
                ]
            },
            {
                "path": ".len(validators)",
                "value": 1000,
                "proof": [
                    "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"
                ]
            }
        ],
        "root": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"
    }
}

Based on the proposal, we could also be assigned to the meta issues.

- [SSZ Query Language #15343](https://github.com/OffchainLabs/prysm/issues/15343)
- [Merkle proofs of everything #15344](https://github.com/OffchainLabs/prysm/issues/15344)

### Discussion with Nando

Since speccing is one of the core part of this project, collaborating with Nando helps me a lot to broaden my horizens and also to consider bigger pictures of the project. Discussion of this week started by Nando's [open questions](https://github.com/fernantho/SSZ-QL-and-GMP/tree/16c4208fa9349a6f8b13c58c52eb7fa92d7341f2?tab=readme-ov-file#open-questions-to-be-considered). Some notable discussions are below:

#### Adding query paths in the response ➡️ Yes!

Nando suggested two ways to specifying the response: ordering and include `path` string for each query result. I thought it would be better to include `path` string as the result is more self-explained, leading better expereicne for developers.

#### Multiproof Type ➡️ Use basic multiproof.

> I think we can stick to the "normal" multiproof despite some benefits in terms of performance. The reason is:
> - It fits well with current consensus specs, so we don't need to explain about what this algorithm looks like, etc.
> - Performance matters, but in my point of view, multiproof still increases significant performance in terms of space. More complex algorithms are necessary for the case of user queries for 10+ paths, which doesn't take place so often.

Excerpt from my message. There are several candidates for multiproofs, but we finalized ourselves to use the _basic_ multiproof that is already [specified](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) in `consensus-specs`.

### And... started coding 💻

> [Diff](https://github.com/OffchainLabs/prysm/compare/8623a144d92659ed89f8830eb4d7f4c3000be724..syjn99:prysm:f152e192859609e1f1d5f04ecb12d662aafe93da)

I finally started coding myself. Not yet implemented core logics, but there are some confirmed things to do for API handlers.

## What's next

- Create a fine-grained task list (reference: https://github.com/OffchainLabs/prysm/issues/12991)
- Discuss remaining agendas with Nando.
- How do we maintain our spec document?
- [Radek's comment](https://hackmd.io/romP2sD0T8SpJpnbO8nnHQ?comment=a426dc3f-694a-4ebe-b4c5-40c2e9115e11&utm_source=comment-card&utm_medium=icon): For better UX, how can we provide an unified structure for multiproof and non-multiproof?

## Postscript


> [Link](https://discord.com/channels/595666850260713488/595701319793377299/1395368458384048188) to the message.

Happy to find out that our project would be quite useful!