optimizations for prover & verifier by quangvdao · Pull Request #1 · a16z/dory

quangvdao · 2025-11-08T22:43:15Z

PR title

Reduce verifier to O(nu) time and optimize first-round D2 pairings

Summary

Verifier no longer folds 2^nu-length tensors. It computes final s1, s2 via O(nu) accumulators using per-dimension coordinates.
Prover first round: compute D2L/D2R as MSM(G1, scalars) + one pairing with h2 instead of multi-pairing.
Correct round-to-dimension mapping on verifier (last dimension folds first).
Keep C+/C− unchanged, since v2 is no longer fixed-base after the first combine.
Cleanups: remove dead imports, no behavior change elsewhere.

Details

Verifier math
- s1_final = ∏(y_t + α_t·(1 − y_t))
- s2_final = ∏(x_t + α_t^{-1}·(1 − x_t))
- Consume y_t, x_t in reverse of variable order, matching folding.
Implementation
- DoryVerifierState now holds s1_acc, s2_acc and s1_coords, s2_coords. No tensor folding.
- verify_evaluation_proof passes per-dimension coords; if sigma < nu, pad s2 coords with 1.
- process_round derives index from nu and updates accumulators per round.
- Prover state carries optional v2_scalars only for round 1; compute_first_message uses MSM+pairing for D2L/D2R when available; apply_first_challenge drops scalars.
Compatibility
- Public API functions setup, prove, verify unchanged.
- Internal DoryVerifierState::new and DoryProverState::new signatures changed; all internal call sites updated.
Performance impact
- Verifier memory drops from O(2^nu) to O(1) and time per round becomes O(1) for s1/s2 folding.
- Prover first round replaces two multi-pairings with two MSMs + two pairings.
Testing
- Run: cargo test --features backends
- The accumulator indexing uses idx = nu - 1 to match fold order.
Follow-ups
- Add Criterion benches under benches/ to quantify improvements.
- Cache affine bases in setup for faster MSMs.

Why this is correct

Folding a Kronecker product with per-round [α, 1] weights factorizes into a product of 2-term dot products, giving the O(nu) formulas above.
For round 1, v2[i] = h2·s_i, so ⟨Γ1', v2_half⟩ = e(Σ s_i·Γ1'[i], h2).

markosg04

Thanks a lot! Just bunch of nits

markosg04 · 2025-11-09T17:09:43Z

-        left_vec,        // s2 = left_vec
+        row_commitments,     // v1 = T_vec_prime (row commitments)
+        v2,                  // v2 = v_vec · g_fin
+        Some(v_vec.clone()), // v2_scalars available for first-round optimization


can we avoid this clone? seems that prover_state is the last thing to consume v_vec

markosg04 · 2025-11-09T17:11:17Z

+    // The verifier uses O(nu) accumulators derived from per-dimension coordinates.
+    // We take the first `nu` coordinates for s1, and the last `nu` coordinates for s2.
+    // If there are fewer than `nu` remaining for s2 (when sigma < nu), pad with ones (neutral).
+    let s1_coords: Vec<F> = point[..nu].to_vec();
+    let mut s2_coords: Vec<F> = point[nu..(nu + nu).min(point.len())].to_vec();
+    if s2_coords.len() < nu {
+        s2_coords.resize_with(nu, F::one);
+    }


could we use sigma for the remainder? we are requiring square dimensions anyways. It might make the comments here clearer as well

markosg04 · 2025-11-09T17:13:33Z

    /// # Parameters
    /// - `v1`: Initial G1 vector
    /// - `v2`: Initial G2 vector
+    /// - `v2_scalars`: If v2 = h2 * scalars (first round), pass scalars for MSM+pair optimization


Suggested change

/// - `v2_scalars`: If v2 = h2 * scalars (first round), pass scalars for MSM+pair optimization

/// - `v2_scalars`: Use the scalars in the first round to avoid a multi-pairing by instead performing a (cheaper) MSM + Pairing

markosg04 · 2025-11-09T17:15:46Z

+        if let Some(ref sc) = v2_scalars {
+            debug_assert_eq!(sc.len(), v2.len(), "v2_scalars must match v2 length");
+        }


Suggested change

if let Some(ref sc) = v2_scalars {

debug_assert_eq!(sc.len(), v2.len(), "v2_scalars must match v2 length");

}

if let Some(sc) = v2_scalars.as_ref() {

debug_assert_eq!(sc.len(), v2.len(), "v2_scalars must match v2 length");

}

ref is older rust and as_ref() is clearer anyways

markosg04 · 2025-11-09T17:16:49Z

        // D₂L = ⟨Γ₁', v₂L⟩, D₂R = ⟨Γ₁', v₂R⟩
-        let d2_left = E::multi_pair(g1_prime, v2_l);
-        let d2_right = E::multi_pair(g1_prime, v2_r);
+        // If v2 was constructed as h2 * scalars (first round), compute MSM(Γ₁', scalars) then one pairing.


Suggested change

// If v2 was constructed as h2 * scalars (first round), compute MSM(Γ₁', scalars) then one pairing.

// In the first round, v2 = h2 * scalars, so we can compute this as the Pairing of MSM(Γ₁', scalars)

markosg04 · 2025-11-09T17:17:24Z

-        let d2_left = E::multi_pair(g1_prime, v2_l);
-        let d2_right = E::multi_pair(g1_prime, v2_r);
+        // If v2 was constructed as h2 * scalars (first round), compute MSM(Γ₁', scalars) then one pairing.
+        let (d2_left, d2_right) = if let Some(ref scalars) = self.v2_scalars {


let's use as_ref() here as well

markosg04 · 2025-11-09T17:18:45Z

            self.v2[i] = self.v2[i] + self.setup.g2_vec[i].scale(&beta_inv);
        }
+
+        // After first combine, v2 is no longer fixed-base; drop scalars to avoid misuse


Suggested change

// After first combine, v2 is no longer fixed-base; drop scalars to avoid misuse

// After first combine, the `v2_scalars` optimization does not apply.

markosg04 · 2025-11-09T17:20:48Z

+        // Use accumulated folded scalars
+        let s1_final = self.s1_acc;
+        let s2_final = self.s2_acc;


would it be possible to avoid having both s1/2_final and s1/2_acc ?

markosg04 · 2025-11-09T17:21:46Z

-        }
-        self.s2_tensor.truncate(n2);
+        // Update folded scalars in O(1): s1_final *= (α·(1−y_t) + y_t), s2_final *= (α⁻¹·(1−x_t) + x_t)
+        // Determine current round index implicitly from remaining rounds (last dimension folds first).


question: (last dimension folds first) -> this is because of endian-ness?

quangvdao added 2 commits November 8, 2025 15:43

optimizations for prover & verifier

f5065b6

cargo fmt

6246e18

markosg04 reviewed Nov 9, 2025

View reviewed changes

quangvdao added 2 commits November 9, 2025 11:44

addressed comments

252827d

endianness comment

b5fe463

markosg04 approved these changes Nov 9, 2025

View reviewed changes

markosg04 merged commit 83918cf into a16z:main Nov 9, 2025
3 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

optimizations for prover & verifier#1

optimizations for prover & verifier#1
markosg04 merged 4 commits into
a16z:mainfrom
quangvdao:main

quangvdao commented Nov 8, 2025 •

edited

Loading

Uh oh!

markosg04 left a comment

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

markosg04 Nov 9, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	/// - `v2_scalars`: If v2 = h2 * scalars (first round), pass scalars for MSM+pair optimization
	/// - `v2_scalars`: Use the scalars in the first round to avoid a multi-pairing by instead performing a (cheaper) MSM + Pairing

	// If v2 was constructed as h2 * scalars (first round), compute MSM(Γ₁', scalars) then one pairing.
	// In the first round, v2 = h2 * scalars, so we can compute this as the Pairing of MSM(Γ₁', scalars)

	// After first combine, v2 is no longer fixed-base; drop scalars to avoid misuse
	// After first combine, the `v2_scalars` optimization does not apply.

Conversation

quangvdao commented Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR title

Summary

Details

Why this is correct

Uh oh!

markosg04 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

quangvdao commented Nov 8, 2025 •

edited

Loading