optimize rounds 3-4 — direct 2N DEEP evaluation + OOD stride reads

[diegokingston]

Reduce memory and compute in rounds 3–4:

• OOD: pass shared scalars from round_3, hoist col_scale
  precompute, read LDE with stride (no Vec copies).
• DEEP: column compression + direct evaluation at all 2N LDE points
  (no iFFT+FFT).

[diegokingston]

/bench 3

[github-actions]

Codex Code Review

1. Medium – Missing input consistency checks can cause silent wrong evaluations or panic

• Where: trace.rs:374, trace.rs:411, trace.rs:431, trace.rs:452
• Issue: get_trace_evaluations_from_lde now trusts externally supplied coset_points, coset_offset_pow_n, n_inv, g_n_inv with no validation against domain.
  • If coset_points.len() < n, interpolation is silently computed on a truncated domain (incorrect result, no error).
  • If coset_points.len() > n, lde_col[i * bf] can go out of bounds and panic.
• Why this matters: This function previously derived these values internally, so mismatches were impossible. The refactor introduced a new correctness/panic surface.
• Fix: Add explicit checks (coset_points.len() == n, expected LDE column lengths) and consider returning Result on invalid input; at minimum use strong assertions with clear messages.

No other concrete security/performance/simplicity issues found in this diff.

I couldn’t run tests in this environment because cargo failed due a read-only rustup temp path (/home/runner/.rustup/tmp/...).

[github-actions]

Benchmark — fib_iterative_8M (median of 5)

_{Table parallelism: auto (cores / 3)}

Metric	main	PR	Δ
Peak heap	56461 MB	53059 MB	-3402 MB (-6.0%) 🟢
Prove time	26.060s	25.527s	-0.533s (-2.0%) ⚪

🎉 Improvement detected — heap or time decreased by more than 5%.

✅ Low variance (time: 1.7%, heap: 1.3%)

_{Commit: 5f4c79f · Baseline: cached · Runner: self-hosted bench}

[diegokingston]

/bench 3

[diegokingston]

/bench 3

[diegokingston]

/bench 3

[diegokingston]

/bench 3

[diegokingston]

/bench 3

[github-actions]

Codex Code Review

1. Medium - Performance/Availability: large memory amplification in DEEP computation

• The new compressed precompute materializes num_eval_points * lde_size extension elements in memory before the hot loop. For large traces this can become very large and cause OOM/major slowdown.
• Reference: prover.rs:1253, prover.rs:1277
• Why it matters: previously the trace-term accumulation was streamed per-row; now memory is multiplied by both lde_size and num_eval_points.
• Action: compute compression in chunks (or per-row/per-block) instead of storing the full 2D matrix.

2. Low - Robustness: new public API relies on caller invariants without checks

• get_trace_evaluations_from_lde now accepts precomputed coset_points, n_inv, etc., but does not validate that coset_points.len() == domain.interpolation_domain_size (and related consistency). A mismatched caller input can panic/out-of-bounds or produce invalid evaluations.
• Reference: trace.rs:368, trace.rs:431, trace.rs:452
• Action: add debug_assert!/checked assertions for key invariants (lengths and domain consistency) at function entry.

No direct memory-safety/unsafe/crypto implementation vulnerability was evident in the diff itself.

[claude]

Review: perf/ood-evaluation

Overall: The math is sound and the changes are correct. The three main transforms (barycentric scalar sharing, stride-free LDE access, direct 2N DEEP evaluation) are all equivalent to the original formulations. No security issues found. One documentation bug and one missing test worth addressing.

---

Bug (Low) — Comment says i * bf but code uses no stride

See inline comment on prover.rs:1238. The Phase 1 block comment describes the old N-point access pattern (trace_col_j[i * bf]), but i now ranges over all lde_size points directly via get_main(i, j). This will mislead anyone who diffs this against the old path.

---

Missing test (Low–Medium) — No unit test for the DEEP poly at 2N points

The most algorithmically significant change — evaluating deep(x) at all 2N LDE points instead of N trace-coset points then iFFT+FFT-extending — has no dedicated comparison test. The prove/verify roundtrip provides indirect coverage, but the PR already adds test_decompose_and_extend_d2_matches_original as a precedent for exactly this kind of "new path == old path" check. A similar test for compute_deep_composition_poly_evaluations would give the same confidence.

---

Design note (Low) — compressed doubles trace evaluation work

compressed[k][i] is precomputed for all num_eval_points × lde_size = 2 × 2N rows across all ~95 columns. The original hot loop ran over only N trace-coset rows. Combined with the 2N evaluation domain, trace-term multiplications roughly double (380N vs 190N). The eliminated iFFT(N)+FFT(2N) saves O(N log N) ≈ 20–30N ops for typical N, which does not offset the extra 190N. Whether this is a net win in wall-clock time depends on parallelism and cache effects — benchmarks should confirm before merging to main.

---

Verified correct ✓

• Barycentric formula refactor in trace.rs: vanishing_factor × Σ_i (coset_pt[i] × inv_denom[i]) × lde_col[i*bf] is algebraically identical to the inlined interpolate_coset_eval_with_g_n_inv it replaces.
• compressed[k][i] - ood_compressed[k] correctly factors the column sum out of the denominator loop since inv_t_k_i doesn't depend on j.
• lde_composition_poly_evaluations[j] has lde_size elements (produced by decompose_and_extend_d2 / extend_half_to_lde), so [j][i] for i in 0..lde_size is in-bounds.
• Denominator slice indexing denoms[(1 + k) * lde_size + i] is within the allocated (1 + num_eval_points) * lde_size length.

[jotabulacios]

/bench 5

[ColoCarletti]

/bench

[diegokingston]

/bench 3

[diegokingston]

/bench 10

[MauroToscano]

/bench 5