feat: Implement batch operations in non_hiding_kzg module

[huitseeker]

• Added a batch_commit method to generate multiple commitments from a list of polynomials.
• Introduced a batch_open functionality for evaluating multiple polynomials at different points.
• Implemented batch_verify function for validation of polynomial evaluations in a multi-commitment setup.
• Verified the correctness of the batch operations with a new unit test batch_check_test.

These basic variants of batch KZG were originally part of #145

[storojs72]

As Adrian mentioned (and I then could also convince myself by observing the implementation), this form of pairings check is more optimal, comparing to:

let left = E::pairing(..., ...);
let right = E::pairing(..., ...);
assert_eq!(left, right);

as it saves one multi_miller_loop and one final_exponentiation call. However that requires some manipulating with input parameters, which differs from what is necessary to pass to pairing couple. For example, given vanilla KZG10 specification, described here, the final check is specified like:

e(C_q, a⋅G2−b⋅G2) == e(C_f−G1⋅c, G2) 

which has following Rust equivalent:

let g1 = srs.powers_of_g[0];
let g2 = srs.powers_of_h[0];

let left = pairing(
  &Cq.to_affine(),
  &(srs.powers_of_h[1] - (g2 * b)).to_affine(),
);
let right = pairing(&(Cf.to_affine() - (g1 * c).to_affine()).to_affine(), &g2);
assert_eq!(left, right);

Alternatively (more optimally), one can write this check as:

// Alternatively (more optimal as it doesn't require executing final_exponentiation twice)
let term1 = (
  &(srs.powers_of_g[0] * c - Cq * b - Cf).to_affine(),
  &G2Prepared::from_affine(srs.powers_of_h[0]),
);
let term2 = (
  &Cq.to_affine(),
  &G2Prepared::from_affine(srs.powers_of_h[1]),
);
let result = multi_miller_loop(&[term1, term2]).final_exponentiation();
assert_eq!(result.is_identity().unwrap_u8(), 0x01);

which I derived empirically.

I wonder if there is a systematic way that allows turning the e() == e() formula into more optimal one:

term1 = ...
term2 = ...
multi_miller_loop(term1, term2).final_exponentiation().is_identity()

Thanks in advance, for answering, @huitseeker !

[huitseeker]

I believe the underpinnings of the speed of this API have been discussed elsewhere, but to summarize:

1. the vectorized API allows us to perform less (a single) final exponentiation, which is an expensive operation,
2. the initial part of the pairing computation, the Miller loop, is a fancy double-and-add algorithm that's easy(-ish) to mutualize in an SIMD fashion, giving the vectorized API a bit of an edge,

Hence the API you're remarking on above. The equivalent API in Arkworks is perhaps a bit simpler, but leads to the same idea:
https://github.com/arkworks-rs/algebra/blob/bf96a5b2873e69f3c378c7b25d0901a6701efcc4/ec/src/pairing.rs#L104-L109