feat!: remove verifier RNG requirement

[AaronFeickert]

The verifier currently requires support for a random number generator, either provided by the caller or taken from OsRng. This is only to produce weights used in the batch verification process; the weights do not need to be cryptographically secure, but must not be known to the prover. This is fine if the verifier has access to a good random number generator, but is not ideal or particularly flexible; in particular, it likely precludes having a WASM verifier.

This PR uses TranscriptRng functionality to produce these weights deterministically. It removes the need for the verifier to supply or support any random number generator.

We start by instantiating a new Merlin weight transcript whose only purpose is to bind all proofs together. After processing each proof's RangeProofTranscript to produce challenges, we include the prover's responses in the transcript and then use the corresponding TranscriptRng to fetch a pseudorandom u64 that goes into the weight transcript. Once all proofs have been bound in this way, we use the weight transcript's TranscriptRng to generate the weights.

Note that because we still use TranscriptRng functionality, we need to include a random number generator to satisfy the API. To do this, we build a fake NullRng that only outputs zero. This is not safe in general, but is fine in this case.

It's important that we include the prover's responses in each transcript. Normally we don't ever need to do this; however, we don't want the prover to be able to manipulate them in an attempt to bias the weight transcript. If we were doing individual verification or random weighting, this would not be problematic. However, we want to guard against a prover who may be able to influence the batch structure used by the verifier. This is defense in depth and costs effectively nothing.

This is technically a breaking change, since it removes verify_batch_with_rng from the public API; the existing verify_batch should be used instead, and no longer requires the rand feature.

Closes #110.

BREAKING CHANGE: Removes verify_batch_with_rng from the public API. No longer requires that verify_batch have the rand feature enabled.

[hansieodendaal]

Maybe the verifier should pass in a standard rng, then inside verify_batch_with_rng we use that to seed a crypto rng. The only interface change would be pub fn verify_batch_with_rng<R: CryptoRngCore> to pub fn verify_batch_with_rng<R: RngCore>.

[AaronFeickert]

This would still limit the effective entropy to that of the RngCore input, and I'm not sure what you gain from it. There already exist seedable CryptoRngCore generators that don't use OS-supplied entropy, but these are similarly limited by the seed quality. The underlying problem is that some targets can't use OS-supplied randomness at all, which implies that they couldn't properly seed any generator.

The idea here is to remove the question of generator quality and availability entirely, and have the verifier handle it using the transcripts instead.

[hansieodendaal]

ACK

Looking at it again, I like using the null rng in there, as it conveys a specific message about the verifier's requirement, and is also reflected in the API.

[AaronFeickert]

It's probably worth noting that we could get the same effect by simply generating a cryptographic hash of all proofs, and then using it to seed a random number generator to get the verifier weights. Indeed, this would likely be faster when using a hasher like those of the Blake2 family (my initial and incomplete tests suggest maybe on the order of a microsecond, if that).

However, I don't think this is an optimal idea:

• It effectively duplicates computation that's already done using the existing verifier transcript reconstruction.
• It requires that the proof hashing be done correctly and safely, which is much easier to do with Merlin.
• It requires a proper choice of seeded random number generator.

Overall, I think the Merlin-based approach in this PR is safer, more idiomatic, and worth any trivial efficiency hit.