Plonk: transcript hasher

[dtebbs]

It could be useful to have the following interface for transcript hashing:

template<typename ppT> class transcript_hasher
{
public:
   void add_element(const libff::Fr<ppT> &element);
   void add_element(const libff::G1<ppT> &element);
   void add_element(const libff::G2<ppT> &element);

   libff::Fr<ppT> get_hash();
};

• Plonk: transcript hasher #61

[vesselinux]

Issue description (bullet 11): Compute the challenges alpha, beta, gamma, zeta, nu, u using a hash function rather than passing them as pre-computed inputs as part of the transcript_hash_t structure. The latter is done now for the purposes of unit testing. In the long run we might want something like a transcript_hasher which can accept field and group elements as they are available, and then output a digest when required. See discussion at #49 (comment) and #49 (comment)

[vesselinux]

Just to clarify: in the transcript_hasher class shouldn't we also have a (private) vector variable (or a buffer) that accumulates all the elements added by add_element? Since the elements are of different types (Fr, G1, G2) we can probably tansform them to string or binary data before we add them to the vector (resp. buffer). The get_hash method will then return the hash of whatever is in the vector (buffer) at the moment.

And another question that arises: how would the existence of the transcript_hasher class solve the problem with the unit tests that we discussed. Namely, that in order to verify the test vector values in the unit tests, we'll still have to somehow pass the corresponding precomputed hashes to the prover? Currently this is done through the transcript_hash_t struct https://github.com/clearmatics/libsnark/blob/plonk/libsnark/zk_proof_systems/plonk/srs.hpp#L183-L208, which of course is temporary solution to make the unit tests work.

[dtebbs]

The above would be the interface for the hasher. We can then pass any implementation we want into the prover and verifier. The implementation may or may not include an internal vector, depedning on how it works (as discussed in the catchup, the hash implementations usually accumulate input into a kind fo state block, so the vector of values may not be necessary, but that's an implementation detail).

A "dummy" implementation (just for the purposes of unit testing) could simply return the test values from subsequent calls to get_hash. Once the interface is defined, we only need this implementation in order to run the unit tests. In fact, I'd recommend this is what we do. i.e.

1. define the interface. It doesn't have to be exactly as above - that's an initial proposal.
2. add the "dummy" implementation which results in exactly the same values in the tests.
3. moify the tests to create a dummy trascript hasher implementation and pass it to both prover and verifier.
4. update the plonk impl and tests until the tests pass
5. Implement at leaast one real transcript hasher (a simple SHA or blake one should be pretty easy).

[vesselinux]

Thank you for the detailed explanation. I have addressed points 1-4 and committed the changes.