# EPF6 - Week 3 Updates

## tl;dr

Now I'm leaving Cannes! In this week, I DID

- [Presented](https://youtu.be/UqkQdlyEwdA?si=c0CqHxvU8lz7yWEL&t=1336) (Timeline: 00:22:16 - 00:31:00) my initial proposal at EPF day. ([Slide](https://docs.google.com/presentation/d/1YMbUS3J7YAartbJ56r4vensSIwpcSV_Jc-lzUeNv-tM/edit?usp=sharing))
- Worked with [Nando](https://github.com/fernantho/) to finish [our initial project proposal](https://hackmd.io/@junsong/HkQ9XBEHel). One-liner for our project:
- We propose **a new [Beacon API](https://github.com/ethereum/beacon-APIs) endpoint** that introduces an **SSZ Query Language (SSZ-QL)**, including the ability to generate **merkle proofs** for the queried data.

## Details

### EPF Day

It was so glad to meet other fellows in person, and we talked a lot so we get to know each other better. All fellows have different backgrounds, so I could learn their insights and thoughts!

[Presentation](https://youtu.be/UqkQdlyEwdA?si=c0CqHxvU8lz7yWEL&t=1336) was quite smooth. I practiced myself to present as fluent as I can, and I'm satisfied about my talk 🤣.

### [First Draft](https://hackmd.io/@junsong/HkQ9XBEHel) is Ready for Review!


After EPF day, I met [Nando](https://github.com/fernantho/) and we decided to collaborate for the same project. We will design and implement [SSZ Query Language](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#prysm-ssz-query-language) with corresponding [merkle proofs](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#prysm-merkle-proofs-of-everything) in Prysm.

The goal for this cohort is quite clear: **Add a Beacon API endpoint for this feature**. While writing [motivation](https://hackmd.io/@junsong/HkQ9XBEHel#Motivation), I'm pretty sure that this feature can be helpful for consumers as well as core devs.

I expect implementing the feature is not that hard, but Nando argues that before actual coding we need some concrete specification (and I totally agreed with him). As we have a couple of weeks to submit our project proposal at the Github repository, we plan to commit those weeks for speccing and few rounds of feedback loops.

We kindly requested to mentors for reviewing the proposal in the following week. You might check the [message](https://discord.com/channels/476244492043812875/1387734369527136297/1391414058711908414) here.

#### An example for `GET` request

GET /prysm/v1/beacon/states/head/query?path=.finalized_checkpoint.root&include_proof=true

This request will be handled and return like:

{
  "version": "electra",
  "execution_optimistic": false,
  "finalized": true,
  "data": [
    {
      "value": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
      "proofs": ["0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"],
      "state_root": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
    }
  ]
}

So the user may hash for `len(proofs)` time to verify the data.

#### Some Challenges

I think it is obvious for the specification of [`GET` request](https://hackmd.io/@junsong/HkQ9XBEHel#GET-request), but I found that speccing of [`POST` request](https://hackmd.io/@junsong/HkQ9XBEHel#POST-request) is quite challenging. To note those points:

- **How should the `query` object (for `POST` request) look like?**: The schema would be critical for user experience. I think if I stick into some JSON-formatted data, the schema should be created using this [tool](https://json.ophir.dev/). Also, it would be very nice to deploy an Web App that can construct the query in a real- time. At the moment I imagine the UI like [GraphQL Playground](https://studio.apollographql.com/sandbox/explorer/?).
- **Multiproof**: Definitely multiproof is the one efficient way to verify the proofs for multiple data. But the design matters: how can we make a struct for `MultiProof` for example? In my [past experience](https://hackmd.io/@reamlabs/B1SJuEoxle#Merkle-Multiproof), I was used to make a struct containing two mappings:

/// Multiproof is a structure that contains the leaves to be verified with
/// their corresponding proofs.
#[derive(Debug, Clone, Default, Serialize, Deserialize)]
pub struct Multiproof {
    /// The leaves to be verified.
    /// Keyed by their generalized indices.
    pub leaves: HashMap<u64, B256>,

    /// The proof nodes.
    /// Keyed by their generalized indices.
    /// Keys of ``proofs`` will be sorted in descending order when generating a single proof.
    pub proofs: BTreeMap<u64, B256>,
}

But to be honest I think there can be a better interface for this.

## What's next

- By getting some feedbacks from my mentors, I would finalize the specification and correct if we're on the wrong way. It needs several iterations of review and feedback, so I'm going to focus on clarifying my project as much as I can in next week.