feat: Gemini PolynomialBatcher

[ledwards2225]

Introduces new class in Gemini called PolynomialBatcher that is responsible for storing references to the polynomials to be batched and actually computing the various batched polynomials required in Gemini. This serves two purposes: (1) it separates the polynomial batching logic from the "gemini" logic (i.e. constructing univariate claims from a multilinear poly via gemini-style "folding"), and (2) it facilitates the input of different types of polynomial sets into Gemini. This latter point is needed for the new merge protocol which will add yet another type of polynomial into the mix: to_be_k_shifted_polynomials, which the ever-expanding gemini interface with defaulted inputs would not easily support.

Note: Currently the PolynomialBatcher only handles the unshifted and to_be_shifted polynomials. It would be natural to include the concatenation polynomials as well. I held off for now due to expected changes to the way concatenations are handled.

Note 2: Upcoming follow ons will introduce a similar mechanism for the analogous verifier logic.

[maramihali]

Thanks for the cleanup, I've added some suggestions and requests for more docs

[maramihali]

will you please add docs to the more complex functions and to the class

[maramihali]

i find this pattern a bit confusing, maybe it would make more sense to add the randomising polynomials to the list of unshifted polyomials to be batched?

[ledwards2225]

I agree its confusing. This is basically just preserving the existing pattern which was far from explicit. It could be made a lot clearer at the expense of memory efficiency but I was trying to preserve the original pattern which does not require storage of an additional poly. I'll think about ways to make it clearer while maintaining the memory.

[maramihali]

The pattern

batched_unshifted = batch(unshifted, challenge, running_scalar)

seems cleaner to me. Is there a reason why it doesn't work?

[ledwards2225]

hah I had something like this and changed it back at the last minute. It wasn't quite so clear as you suggest simply because generally batched_unshifted is already initialized (with the random poly) so the above would not work. Maybe the answer is just to give up the memory efficiency to improve the clarity

[ledwards2225]

cleaned up this pattern at the expense of storing the random_polynomial in its own memory. Made an issue to reconsider this if it becomes relevant in the future

[maramihali]

Maybe rather than repeating these three lines in every prover + tests you create an appropriate constructor

PolynomialBatches polynomial_batches(N, unshifted, to_be_shifted);

[ledwards2225]

I considered this too but I was trying to get away from things like like this that we currently have in the code:

                                                       RefVector(pcs_instance_witness.unshifted_commitments),
                                                       {},
                                                       RefVector(pcs_instance_witness.unshifted_evals),
                                                       {},
                                                       challenge,
                                                       this->vk()->get_g1_identity(),
                                                       verifier_transcript,
                                                       {},
                                                       true,
                                                       &consistency_checked,
                                                       libra_commitments,
                                                       libra_evaluation,
                                                       pcs_instance_witness.sumcheck_commitments,
                                                       pcs_instance_witness.sumcheck_evaluations);```

[ledwards2225]

I considered something like PolynomialBatches polynomial_batches(.full_batched_size = N, .unshifted = unshifted, .to_be_shifted = to_be_shifted); This is maybe better in some ways but its just as many lines and it has the disadvantage that it allows someone to construct a PolynomialBatches without specifying full_batched_size. I'll think about whether there's a good compromise

[maramihali]

I wonder whether we have the redundant-move warning enabled when building to prevent us from doing unnecessary moves

[ledwards2225]

This is not a redundant move - there were several places in Gemini prior to my last PR where such moves were missing which results in copies

[ledwards2225]

As discussed, these moves are indeed redundant! thanks

[github-actions]

Changes to public function bytecode sizes

Generated at commit: 529bbbe8dc4f53714fc35fc69d5a6896a51724a8, compared to commit: cd990afca34493ae0d0d203f3263bc9dc815aab5

🧾 Summary (100% most significant diffs)

Program	Bytecode size in bytes (+/-)	%
AvmTest::bulk_testing	+4 ❌	+0.02%
AvmTest::public_dispatch	-338 ✅	-0.54%

---

Full diff report 👇

Program	Bytecode size in bytes (+/-)	%
AvmTest::bulk_testing	22,606 (+4)	+0.02%
AvmTest::public_dispatch	61,944 (-338)	-0.54%

[ledwards2225]

This pattern is slightly less nice than batched = batch(polys) but I need to initialize the batched_unshifted and batched_to_be_shifted_by_one prior to this to ensure they're correctly sized. I thought about initializing within the method based on e.g. the size of the first poly in the set to be batched but there's no guarantee that all of the polys have the "full" size.