perf(gkr): apply Gru24 Section 3.2 to single-source sumcheck levels

[peter941221]

Summary

This implements a narrow v1 of the optimization discussed in #1724.

For GkrSumcheckLevels whose claims all refer to the same distinct GkrClaimSource, we switch the zero-check round relation from the legacy unweighted form to the weighted Section 3.2 recurrence from Gru24. This lets the prover send a degree-d round polynomial instead of degree-d+1 for those eligible levels.

Folded multi-source levels keep the legacy path unchanged.

What changes

• add a schedule-side eligibility helper:
  • constraint.GkrSumcheckLevel.SingleClaimSource()
• reduce ZeroCheckDegree(...) only for eligible levels
• update both verifier paths:
  • native verifier
  • in-circuit verifier
• update the prover to use a reduced eq-table path for eligible levels
  • the current-variable eq factor is stripped after each fold
• refresh generated GKR backends and affected test vectors

Why the scope is narrow

Section 3.2 is not just a local prover micro-optimization. It changes the round relation seen by the verifier.

In gnark's current GKR schedule, some levels fold claims coming from multiple distinct evaluation points. I did not try to force the new recurrence onto those shapes in this PR. Instead, the optimization is only enabled when the whole level collapses to one distinct source.

That keeps the patch aligned with the paper identity without widening into a larger schedule/protocol refactor.

Evidence

The regenerated test vectors show the expected proof-size reduction only on eligible levels. For example:

• single_mul_gate_two_instances.json: total partial-sum coefficient count 3 -> 2
• single_mimc_gate_two_instances.json: 8 -> 7
• single_mimc_gate_four_instances.json: 16 -> 14

Non-eligible / legacy-only vector shapes stayed unchanged.

Validation

• go test ./internal/gkr/... -count=1
• go run . from internal/gkr/test_vectors

I also added a TestZeroCheckDegreeDispatch assertion to the generated curve-test packages to check that:

• eligible single-source levels use the reduced degree
• folded multi-source levels stay on the legacy degree

And I added direct coeff == 1 reconstruction tests for both verifier surfaces:

• generated native sumcheck verifier tests
• frontend / in-circuit sumcheck verifier test

Notes

• I intentionally did not try to optimize folded multi-source levels in this PR.
• I also did not include benchmark numbers here because the existing BenchmarkGkrMimc17 benchmark currently panics on my Windows setup on both clean HEAD and this branch, so it did not provide a trustworthy regression signal for this change.

---

Note

Medium Risk
Touches core GKR sumcheck prover/verifier logic and changes proof serialization/verification semantics for a subset of levels, so subtle soundness or compatibility regressions are possible despite added tests.

Overview
Implements a single-claim-source fast path for GKR zero-check sumchecks: GkrSumcheckLevel.SingleClaimSource() gates a Gru24 §3.2 recurrence that lets eligible levels send degree-d round polynomials instead of degree-d+1.

This updates both prover and verifier (native backends, generator templates, and in-circuit verifier) to use a coefficient-aware reconstruction in sumcheckVerify, adds an optimized prover roundPolynomialSingleSource plus per-round eq-table factor stripping, and adjusts ZeroCheckDegree to return the reduced degree only for eligible levels.

Adds targeted tests to ensure degree dispatch and coefficient-1 reconstruction correctness, and refreshes affected GKR test vectors to match the new proof shape.

^{Written by Cursor Bugbot for commit 7ff05ef. This will update automatically on new commits. Configure here.}

[Tabaie]

Thank you @peter941221 for the submission! This duplicates #1742 as far as I can see.
Also curious about the benchmark, will it also fail with a smaller size constant?

[peter941221]

Thanks for the feedback!

I agree there is significant overlap with #1742. My intent here was to validate the narrower single-source-only path and keep the protocol / schedule surface area small. If you'd prefer to keep the main optimization consolidated in #1742, I'm happy to rework this into a supporting PR that contributes any useful pieces (for example tests, eligibility plumbing, or narrower verifier/prover scaffolding) rather than competing with it.

On the benchmark side, the panic reproduces for me on clean HEAD as well, so I didn't want to treat it as a branch-specific signal. I haven't yet tried reducing the size constant, but I'm happy to do that and report back.