# EPF6 - Week 3 Updates
## Summary
1. EPFDay
2. Attended a few talks at EthCC and joined a few side events.
3. Met some Prysm team members
4. Worked in the project with [Jun](https://github.com/syjn99)

## Details
### 1. EPF Day
At the EPFDay, I presented the following [slides](https://drive.google.com/file/d/1zFitA-q4vs8WA2_8Mi4dqSrtMwXdWEGM/view). They are more visual than "text-heavy". The main target of the slide was to show the motivation of this project. My personal assessment is that there is a lot of room for improvement in this area and devConnect is the chance to kill it.

### 2. EthCC: Talks, panels, networking
My personal feeling is that the level of the talks was very high. I attended a few but very disordered even though I had a plan prior to the event. I need a few week to catch up with the ones I missed. There was a great pannel in which Justin Drake, Zak Cole and Marek Olszewski. It showed us how diverse the Ethereum Ecosystem is right now, two radically different approaches of facing the future with the same goal, to make Ethereum succeed.

### 3. Core devs meeting
We got initial thoughts from Radek and Manu from Prysm team and Etan from Nimbus. All those comments are helpful to refine the scope of the project.

### 4. Project: SSZ-QL and GMP project
[Jun](https://github.com/syjn99) and I decided to collaborate in this project. Taking advantages of our stance in Cannes, we managed to work two days on the project. At least, we could debate about several aspects of it and the [project proposal](https://hackmd.io/@junsong/HkQ9XBEHel) is almost ready.

Again, the main target of the project proposal is the motivation. We made a strong case against using the full beacon state any time a consumer dApp or light client needs to verify any data. The rough numbers are (at this moment):
- `BeaconState` is ~280MB
- `validators` field is ~240MB
- `balances` field is ~16MB

How efficient is to use a whole `BeaconState` to verify a specific little piece of data? How can we overcome this?
The solution is clear for us, **SSZ-QL/GMP**. The impact can be massive for all the dApps that needs to verify data from mainnet (staking pools, bridges, L2,...)

As a summary, we have defined two new endpoints that are to be added to the Beacon-API: i)`GET` endpoint for lightweight queries and ii) `POST` queries that enables users to retrieve any arbitrary data and their proofs.

In this regards, we may need to find more edge/crazy cases to be added the schema.

In relation to the Merkle proofs, the scope is almost clear. We need to refactor all those three class-specific merkle proofs and code a generic way of generating merkle proofs, so the can be used to prove any field contained in the `BeaconState`, any other class like `BeaconBlock`, `BeaconBlockBody`, `BeaconBlockHeader`, etc.

### Next steps
- Finish the project proposal and the specification adding the feedback from mentors.
- Keep playing around with Python, coding a visual GMP if possible (if it ends up not being very visual, I'll just take all the learnings 😅).
- Get used to Prysm codebase (probably no coding this week).