Ethereum cohort week 15

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)


These 4 things we have (almost, Thomas can confirm better) in our implementation. Let's forget for a second about _i part and describe this: C, f(X), z and y.


C is our pedersen commitment
f(X) is the whole vector (up to 256 Fr values)
z is the index of the value we want to prove
y is the value itself (Fr).


Then finally _i part is for each value(trie value, not DB value like storageSlot) in the trie that we want to prove, we need to send this tuple to the prove() function. Again, this is not "the proof", the proof is what prove() returns. Then this proof is used for stateless clients (and the verifier etc.).

so there is no fiat shamir part here, but rather inside the prove()


Reg _i part it's reffering to "number of openings". I'll copy over Ignacio's description of one example that I asked(proving 1 key-value):


You have:
One for the root node.
One for the other internal node at depth 1
In the leaf node you have many others:
Here you have a vector [1, stem, C1, C2] ... here you have to open the first, second and third element (assuming that the value you want lives in C1)
In C1 you have to open two values (since we split in two)

So would be 7.


For proving multiple key-values we just add even more _i tuples, but i think in any case they are all "merged" to one multipoint proof. Or maybe it's a bit different story how are these collected in that case. I think it's part of what rust does here: https://github.com/crate-crypto/rust-verkle/blob/master/verkle-trie/src/proof/prover.rs#L22 and https://github.com/crate-crypto/rust-verkle/blob/master/verkle-trie/src/proof/opening_data.rs this file in general. So this logic should go to Java since it's "trie" logic and there's no need for banderwagon scalar mul or something like that (math related)