## Summary
1. Trip to EthCC
2. Talk preparation
3. Finally committed to: SSZ QL and Aribtrary Merkle Proofs generated in a generic/efficient way.
4. First contact with Prysm codebase

## Updates
Living in Seville is amazing, but the main drawback is the small airport. The trip from Seville to Cannes turn into an odyssey - departed at 5.15 and arrived at 16.30. Nice trip from Marseille to Cannes by train (even in an overcrowded train and air conditioning was so so).

My talk is about Merkle Proofs and its potential use cases. You can find the slides in the following [link](https://drive.google.com/file/d/1zFitA-q4vs8WA2_8Mi4dqSrtMwXdWEGM/view?usp=sharing).

The slides are mainly about the motivation to work on this project:
- SSZ QL is much needed to reduce trust in 3rd party indexers. It should be a must for Ethereum clients to provide data in a usable and efficient manner. With this project we target at creating a specification and implementing of Prysm client (potentially triggering other clients to do it as well).
- In relation to Merkle Proofs, I'm more familiar with them and with the potential use cases. The three cases exposed in the slides are:
- *Verification of withdrawal credentials:* in staking pools where the operators are in charge of creating the validators public keys, the operators has a chance to frontrun the legit deposit from the staking pool, setting up their own withdrawal credentials and taking control of the full amount of ETH controlled by the validator. It seems that there are two ways to prevent this, it looks like Lido prevents it using a [deposit security committee](https://docs.lido.fi/guides/deposit-security-manual) and the other trust-minimized approach is the following: the protocol makes a 1ETH deposit to the deposit contract and when this deposit is processed by the Consensus Layer, the withdrawal credentials are verified using Merkle Proofs from the very very bottom (~50ish SHA256 hashes) of the beacon state tree to up the the beacon block root (which is the one provided in EVM thanks to EIP-4788). Once the WC are verified, the protocol can complete the validators with remaining ETH.
*Image 1: withdrawal credentials merkle path*
In relation to this proofs, the verification of WC in EVM is costly due to so many SHA256 hashes. Looking at the Merkle tree, we know we can save computation by using multi merkle proofs when the validators that are to be verified are close in the validators array (which in a staking pool is common as validators are pushed into the validators' beacon state array).
- MEV stealing prevention: in scenarios where the web3signer cannot totally trust in what it is signing, it can verify certain fields e.g. at block proposal time, the web3signer can be provided with Merkle Proofs of the fee recipient, the graffiti, etc, acting accordingly verifying the integrity of the block that is signing.
*Image 2: fee recipient verification at block proposal time*
- The other use case/proposition in the slides is the verification of aggregated data from the Consensus Layer using ZK e.g. reporting the TVL and status of validators for staking pools, performance of validators/operators, etc. This seems a bit far from the current scope of the project but we'll try to handle it.

In relation to first contact with Prysm, I have not much to say. Just looking forward to get my hands dirty with it. I have certain experience in Golang and although my last years I've mostly coded smart contracts, I have recently worked on a Golang project that worked for me as a refresher.

## Next steps
- Coordinate with Junsong and work on the SSZ QL specs
- Make a visual demonstration of Arbitrary Merkle (multi) proofs