# EPF6 - Week 6 Updates ## tl;dr - Project proposal is now merged! The proposal is now [live](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/ssz-ql-with-merkle-proofs.md) on EPF repo. - Navigated a couple of options to implement SSZ-QL on Prysm. ([Write-up](https://hackmd.io/@junsong/Byr3_lfPxl)) It's always possible to implement something theoretically, but I believe aligning with the current codebase (and near future plans) is also important. ## Details ### Merging our project proposal In this week, we spent some hours to resolve [Radek's comment](https://hackmd.io/romP2sD0T8SpJpnbO8nnHQ?comment=a426dc3f-694a-4ebe-b4c5-40c2e9115e11&utm_source=comment-card&utm_medium=icon): > The structure of this response differs significantly from the previous one. We should aim to unify them for better UX. Is it possible to treat a non-multiproof response as a special case of multiproof? It was important to unify the response structure between a non-multiproof one and a multiproof one. At first, I thought it would be so **challenging** to do so, as a verifier needs totally different data structures for those. For multiproof one, the verifier needs the leaves value as well as generalized indices. (So using data structure like hash map is inevitable.) However, for non-multiproof one, the verifier only needs a sorted array of hash values so that she can iterate and keep hashing the array. [Nando](https://github.com/fernantho) helped a lot to resolve my misconception about the data structure: it is true that we do have to provide generalized indices, but we can **simply provide two sorted arrays** of generalized indices and proofs respectively. For non-multiproof response, the verifier can just take **the first element** from each array. It was also sweet that we can still use the verification functions [specified](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md) in `consensus-specs` (e.g., `calculate_merkle_root`). ```python! def calculate_merkle_root(leaf: Bytes32, proof: Sequence[Bytes32], index: GeneralizedIndex) -> Root: ``` You can check out our finalized version of the response schema [here](https://hackmd.io/@junsong/rkAN9lIIxx#Query-Result). So, we are finally here. After resolving concerns from Mario, the project proposal is merged! Really thrilled to write some code 💻 --- Also, it would be worth writing some lines of Python codes for verification.I assumed the functions like `calculate_merkle_root` and `calculate_multi_merkle_root` are already implemented, because it has been specified in `consensus-specs`. #### Non-multiproof ```python # Suppose we have `response` here. expected_root = response.data.root results: Sequence[QueryResult] = response.data.results for item in responses: # Just get the head element from the array. root = calculate_merkle_root(item.leaves[0], item.proof, item.gindices[0]) assert expected_root == root ``` #### Multiproof ```python # Suppose we have `response` here. expected_root = response.data.root result: QueryResult = response.data.results[0] assert calculate_multi_merkle_root(result.leaves, result.proof, result.gindices) == root ``` --- ### Navigating Options to implement the project on Prysm {%preview https://hackmd.io/@junsong/Byr3_lfPxl %} We divided up [responsibilites](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/ssz-ql-with-merkle-proofs.md#fellows) for ourselves, and I'm going to focus on implementing the query language itself. It's possible to write 100> lines of code and submit a PR right now, but I wanted to make sure that I'm going on the right track. I [wrote](https://hackmd.io/@junsong/Byr3_lfPxl) what I learned by exploring Prysm codebase and and a couple of way to implement SSZ-QL. You might check the write-up for more technical details.