[zk-token-sdk] Add VerifyGroupedCiphertext2HandlesValidity and VerifyBatchedGroupedCiphertext2HandlesValidity proof instructions

[samkim-crypto]

Problem

The zk-token-proof program does not yet have instructions that can verify whether a ciphertext is valid.

Summary of Changes

Add VerifyGroupedCiphertext2HandlesValidity and VerifyBatchedGroupedCiphertext2HandlesValidity instructions.

The verification for these instructions were benched in a devserver and CU units were computed assuming that 1 CU should take roughly 33ns (as per #25464 (comment)). I hope to create another PR with the benchmark code as a follow-up.

This will be the last set of instructions to be added to the proof program for token-2022.

Fixes #

[codecov]

Codecov Report

Merging #31816 (08bf5ec) into master (1d6b033) will decrease coverage by 0.1%.
The diff coverage is 80.6%.

@@            Coverage Diff            @@
##           master   #31816     +/-   ##
=========================================
- Coverage    81.9%    81.9%   -0.1%     
=========================================
  Files         757      759      +2     
  Lines      207054   207187    +133     
=========================================
+ Hits       169648   169750    +102     
- Misses      37406    37437     +31     

[CriesofCarrots]

One nit, otherwise looks good to me.
Question, though: Is there a possibility we would ever want to support more than 2 handles? I was idly speculating which things could or should be generic for 2+, but I assume it is not worth the trouble.

[samkim-crypto]

Yeah, so that is a good question. The 1 and 3 handle cases are quite natural/useful as well.

For the 1 handle case especially, we would definitely want to support a validity proof for it at some point. The 1 handle grouped ciphertext is just a standard ElGamal, so it could just be CiphertextValidityProof.

For >3 handles, I think it starts becoming much less useful, so it is unlikely we would support it in the future.

It would be really nice to make some of these instructions more generic (if not these instructions, then range proof instructions for different bit-sizes), but it was not clear how since the context and proof sizes are all different. I think it is not out of the question, but I think we would need to use something other than Pod in bytemuck. Probably not worth the trouble at this point as you said...

[samkim-crypto]

Oh, and I will also update the names for the sigma proof from CiphertextValidity and AggregatedCiphertextValidity to GroupedCiphertextValidity and BatchedGroupedCiphertextValidity respectively in a follow-up 🙏