Figure out what to hash in IPA

[lucasxia01]

Since the IPA proof is now separate from the ECCVM proof, we need to hash more things like the opening point and evaluation to make it secure.

[notnotraju]

After some discussions with @lucasxia01 and @federicobarbacovi :

1. For good hygiene, we should hash the commitment in the IPA.
   a. Not clear this is 100% necessary, i.e., for soundness, it might (seems to?) suffice to hash the challenge/evaluation: the former is random and the verifier has access to the commitment, so the only place where "not adding the commitment to the hash buffer" might affect soundness is in the choice of $U$, the random group element used to combine the commitment claim and the evaluation claim. (Note that the intermediary IPA claims ($L_i$ and $R_i$) are all added to the transcript to be hashed, so the only possible soundness gap would be with the original $U$, which is responsible for combining the commitment claim and the evaluation claim.)
2. Unfortunately, the prover "does not have access" to the commitment of the claim he is proving!
   a. It seems to touch many parts of the code to modify e.g. Shplonk or something to pass on this piece of data.
   b. Of course the prover shouldn't recompute the commitment to the final polynomial corresponding to the evaluation claim.
3. This could be solved if, when IPA is called (in ECCVM), we didn't maintain a separate transcript for the ipa but instead passed it the regular transcript.

[notnotraju]

To make a few further comments, based on (2) and (3) above.

a'. It would require changing quite a lot of logic to pass on the information of the commitments, as far as I can tell. The very notion of a ProverOpeningClaim does not contain a commitment, as it is assumed that somewhere along the line the prover sent the commitment to verifier earlier. (Contrast this with the data structure OpeningClaim, which does indeed include the commitment.) I don't exactly understand this design decision (I guess it allows one to avoid redundant information being "sent".)
b'. Directly computing the commitment in ipa.hpp approximately doubles the number of MSMs the prover has to do.

[notnotraju]

I'm now of the opinion that the smart thing to do is just recompute the commitment and add it to the hash buffer. Here are some benchmarks (from eccvm_bench):

eccvm_prove – Mean CPU Time (10 runs on mainframe)

Input Size	With MSM (CPU time)	Without MSM (CPU time)	Δ CPU time (%)
12	2055 ms	2006 ms	+2.38 %
13	2023 ms	2086 ms	−3.11 %
14	2090 ms	2079 ms	+0.53 %
15	2145 ms	2111 ms	+1.58 %
16	2231 ms	2208 ms	+1.03 %

[notnotraju]

Here are ClientIVC benchmarks. (The phrase "with extra large MSM" refers to the fact that if the prover directly computes the commitment of the polynomial in ipa.hpp, then we compute a big MSM.)

The performance hit seems acceptable.

IVC Benchmark – CPU and Time Comparison (With vs. Without Extra Large MSM)

Benchmark	Time with extra large MSM (ms)	CPU with extra large MSM (ms)	Time without extra large MSM (ms)	CPU without extra large MSM (ms)	Δ Time (%)	Δ CPU (%)
ClientIVCBench/Full/6	26514.0	22256.0	26480.0	22161.0	0.13 %	0.43 %
ClientIVCBench/Full/2	13559.0	11163.0	13557.0	11150.0	0.01 %	0.12 %
ClientIVCBench/Ambient_17_in_20/6	20334.0	17297.0	20308.0	17269.0	0.13 %	0.16 %
ClientIVCBench/Ambient_17_in_20/2	10656.0	8723.0	10630.0	8694.0	0.24 %	0.33 %
ClientIVCBench/VerificationOnly	85.8	85.2	85.6	85.1	0.23 %	0.12 %