Ethereum cohort week 11

Updates:

• wrote a specs article for besu (trie<->crypto communication for pedersen hash and commitment): https://hackmd.io/kr5Gka1-S82evw4ex9_OBA?view
• reverted the work on pedersen hash since it was removed: https://github.com/Quadratic-Labs/VerkleTries_Besu/pull/38
• researched more on potential changes of hashes in the verkle specs -> goal is to make it even more snark friendly
• conclusion is that verkle tries in-circuit is a complex topic: in simple words: verkle tries in ethereum separate verification from block execution, and that's kind of the same thing what zkEVMs type 1 are trying to do. So speed of development of verkle tries for ethereum will have an impact on the whole ecosystem, and i'm happy to be involved.

Docs are currently all over the place and here's a copy of the message which i sent to Ignacio regarding multiple things i've been researching/thinking about:

---

Hey yes sure, totally makes sense. Will share a few thoughts:

Having a clear separation of cryptography and trie-logic is the way to go when explaining this IMO. This article from Kev is the way i see the whole thing too: https://hackmd.io/PgsD0I0dQHOGuDx7D6o-dg#Table-of-Contents

Generally speaking, he has many important articles for implementing the crypto - there's one more which is not easy to find since it's not on his profile when looking at the all articles: https://hackmd.io/1RcGSMQgT4uREaq1CCx_cg

Like I said I'm not even focusing on the verkle proof for now except reading about IPA multiproof here and there, but this pedersen thing was a bit confusing, so having clear separation of the trie-key generation hash and commitment used in verkle trie are separate things (although both use MSM). I finally understand it, but making things more clear will help any other client implement it(and in general for people to understand the specs - i guess we don't want version of ethereum where only people who actually wrote the code can easily understand what's actually happening).

Reg other devs: it also depends on whether clients create whole thing from scratch or they mock the crypto with existing libraries like rust-verkle or go-ipa and port it to their language (typescript, Java, nim - but seems Java(besu) is the only one for using the API design). How this API is designed is also a question, for that we need a full understanding what should go in crypto lib and what shouldn't. This article for Kev definitely helps: https://hackmd.io/@6iQDuIePQjyYBqDChYw_jg/H1xXvMatq

Just a thought: the way I see "verkle proof" is actually a SNARK - it's just not that we are proving some computation like in zk(E)VMs or groth16(or bulletproof, or STARKs whatever) proving system where we prove we know some polynomial - in this case the polynomial we are proving is the leafs (values stored in ethereum) - and they usually refer to proving polynomial which represents whole computation. So this is an overhead compared to MPT with keccak - it's just a keccak hash and trie structure and that's it(with some overhead with RPL and hex encoding and having multiple MPTs for account, state etc.). This is more or less like a SNARK - people refer to the thing as "moon math" as you probably know - it's far from easy to understand the thing