EPF cohort 4 has come to an end and I want to wrap it up with some thought. First of all big thank you to https://github.com/taxmeifyoucan and https://github.com/JoshDavisLight for organizing and managing the program. Also special thanks to my mentor https://github.com/jsign and https://github.com/lispc who supported my research of verkle trie in-circuit. What I've done during the cohort: There are 2 projects that I’ve worked on during last 4 months:

Updates: Last week i successfully wrapped up Kev's idea: https://hackmd.io/@6iQDuIePQjyYBqDChYw_jg/H1xXvMatq of having verkle crypto API, and posted in on separate repo: https://github.com/dragan2234/rust_verkle_crypto_api/ . So i can easy experiment with it, optimize it, and port the primitives to besu native repo: https://github.com/hyperledger/besu-native I still want to fix few things, but I'm happy with the work. I think JNI can definitely be used for besu since rust is more performant then Java for cryptography. The only issue is that there's an overhead of 5-10ms when calling a rust function. Maybe this can be optimized even more. Regarding verkle in-circuit, I was thinking if different field could be used for pedersen so it's even more SNARK/STARK friendly, but my conlcusion is that we should stick with bandersnatch since proof systems are improving so fast that there are even field agnostic proof systems and we are already commited to bandersnatch work. Very interesting work and comments: https://x.com/Charles_Chen533/status/1721359542599180406?s=20

Updates: no big updates for this week, no new PRs. I was mostly reading, writing and researching wrote a specs for updating the commitment for Java<->rust communication for besu: https://hackmd.io/bJbN9kDeSyCrMX2x3-j93g learned about proof generation for Java<->rust. Here's a comment: Finally confirmed what we need to send to crypto API to generate proofs. So it's (C_i, f_i(X), z_i, y_i)

This is my understanding how it should work for 1 commitment and 1 leaf: update_commitment(commitment, newValue-oldValue, index) So those are 2 32byte and 1 byte values. Total 65bytes. Rust can easily process that. Then rust takes the commitment (which is a banderwagon element) and we do new_commitment = commitment + (newValue-oldValue)*CRS[index] Where newValue and oldValue are Frs.

This week I finally finished pedersen hash and commitment specified here: https://hackmd.io/kr5Gka1-S82evw4ex9_OBA And tested against go-verkle: -- Pedersen hashing: https://pastebin.com/0RrL3Ryc The format is: addr: bytes in hex treeIndex: The big int number in decimal notation (base 10). It's a "string" because I can put such a big integer in a JSON. treeKey: the result of the perdersen hash bytes

Updates: finalized correct implementation of pedersen hash in trie-key generation and tested against Ignacio test cases. https://github.com/Quadratic-Labs/VerkleTries_Besu/pull/43 worked on the commitment in the trie, but still have issues with that, commitment in the trie is not returning correct results (tested against Ignacio's test cases) it's a bit unpleasant to hear other onlydust contibutors are considering moving to go-ipa JNI, since i invested some time into rust-verkle repo and making it work with Java, writing docs how to communicate Java<->rust. will probably try to make more progress on the verkle tries in-circuit given the situation with development of this lib

This week I worked on Verkle Tries for besu, and 2 PRs are merged: https://github.com/Quadratic-Labs/VerkleTries_Besu/pull/38 https://github.com/Quadratic-Labs/VerkleTries_Besu/pull/39 So spent most of the week trying to understand serialization differences between pedersen hash used in trie-key generation and pedersen "commitment" used in the trie for commiting to children nodes (up to 256). Ignacio generated some test cases for our implementation so we can compare and see if our implementation is correct: -- Pedersen hashing: https://pastebin.com/0RrL3Ryc The format is:

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:

Besu calls pedersen hash with Address32 and TrieIndex32 both are 32bytes What is passed to JNI is the byte slice where values are in the range [-127,128] and each decimal - we can think of it as [0,256] represent one byte In rust we need to unpack this make the 64 bytes and compute pedersen hash with this What does pedersen hash receives: /// Pedersen hash receives an address and a trie index and returns a hash calculated this way: /// H( constant \|| address_low \|| address_high \|| trie_index_low \|| trie_index_high) /// where constant = 2 + 256*64 /// address_low = first 16 bytes of the address /// address_high = last 16 bytes of the address

Saving this as a doc for learning purposes copied from https://t.me/real_crypt telegram channel Pedersen hash weaknesses Pedersen hash has been popularized by Zcash team as ZK-friendly hash function suitable for Merkle trees. Its simplest version operates on an elliptic curve with two fixed generators G and H with unknown discrete log relation. Then to hash two integers (a,b) one computes P = aG + bH and takes some compressed version of P (e.g. x-coordinate) as a result. There are several extensions of this construction to longer messages using multiple generators [1] or just by a recursive Merkle-Damgard calling. In contrast to regular hash functions like Keccak there is a formal security proof for collision resistance as any collision implies a discrete logarithm relation between G and H.

Updates for the week: feels like a productive week, pedersen hash is finally done per specs https://github.com/Quadratic-Labs/VerkleTries_Besu/pull/26 . Verkle tries lack a lot of documentation, this is definitely something that need to be worked on. Had a long call with https://github.com/thomas-quadratic regarding rust cryptography layer <-> Java trie logic layer. Although pedersen hash(PH) is the same as pedersen commitment(PC) - we are returning different values to the trie. For PH we return this: https://github.com/crate-crypto/banderwagon/blob/master/src/element.rs#L33 and for PC we return this: https://github.com/crate-crypto/banderwagon/blob/master/src/element.rs#L80 which is different and we can't do that in Java. Why is this designed in such way i don't know now, but will understand Discussed the idea of having poseidon as a hash instead of pedersen hash for trie-key generation the zk verkle telegram group. Will be interesting learning why this hash can't or can be replaced for pedersen hash and sha256 in fiat-shamir for verkle proof. Will learn more about poseidon for next week. My view is that it is becoming

benchmarks: when i say bandersnatch or banderwagon - i mean an MSM with bandersnatch or banderwagon group. There are benchmarks for bandersnatch in https://github.com/zhenfeizhang/bandersnatch: bandersnatch: cs for base var: 5 cs for scalar var: 256 cs for mul : 2869 cs for result var : 27 cs for equality : 20 total constraints : 3177