Honk proofs are structs(?)

[codygunton]

This seems much better--you can read what's in the proof and you can explicitly see how thing serialize because there's a function that shows the serialization.

Luke: Also, this would allow for more explicit testing of invalid proofs in the recursive verification setting. E.g. this would make it easy to supply an incorrect multilinear evaluation or an bad wire commitment. See the honk recursive verifier tests for an example.

[itsajay1029]

Can you assign this issue @codygunton and also please ellaborate on the issue a little

[codygunton]

Hi @itsajay1029, sorry for the delay, I must have missed a notification.

To elaborate: here

barretenberg/cpp/src/barretenberg/honk/proof_system/prover.hpp

Line 48 in 7592641

plonk::proof& construct_proof();

and here

barretenberg/cpp/src/barretenberg/honk/proof_system/ultra_prover.hpp

Line 43 in 7592641

plonk::proof& construct_proof();

we see that the Honk provers output a plonk::proof (this is already weird, since Plonk and Honk are different proving systems). Elsewhere you will see that plonk::proof is simply an alias for a std::vector<uint8_t>. My idea is that, for Honk, we, should have more informative structures. Namely, each "flavor" (e.g., Ultra and Standard, but there are others, and more to come) should have a custom struct defined as a container for the proof. Each should have an explicit serialization method (say, serialize) that creates a std::vector or std::array of uint8_ts. This will make it very easy to see the exact structure of a proof, which currently has to be read by looking at the appropriate construct_proof function for calls to transcript.send_to_verifier. I like the explicitness of this struct solution, the fact that it localizes the proof information making it very easy to answer "what's in the proof", and believe that it will also help with debugging serialization issues (which I expect to be a major pain point farther down the line).

Does that make sense? Are you saying you'd like to have a crack at this?

[codygunton]

Btw @ludamad if our proofs were structs, would we want this serialization method, or do we have some magic with msgpack that would let us deserialize to structs? I feel like the potential to catch bugs here is huge.

[maramihali]

Also folding "proofs" when implemented

[codygunton]

To be closed by AztecProtocol/aztec-packages#2668

[lucasxia01]

Also folding "proofs" when implemented

@maramihali What do you mean by this? That we need to structure these proofs, or that it would help with implementing the folding scheme?

[maramihali]

Not entirely sure how you ended up structuring the transcript, happy to discuss more concretely once you have the PR ready. The point is that, ideally, folding proofs (which are not exactly proofs, just data to construct an accumulator) should be structured as well rather than std::vector<uint8_t> which is what you extract from the current transcript atm.