Skip to content

Conversation

@CarloModicaPortfolio
Copy link
Contributor

Addressing issue:

#228

Copy link
Owner

@tcoratger tcoratger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just left a couple of comments. I'm not sure about the usefulness of the added tests.

They don't seem to directly test the functions in the file, but rather similar behaviors, which is pretty weird because then we don't have any complete tests calling batch_prove or selector_round functions.

@CarloModicaPortfolio
Copy link
Contributor Author

You are right the tests were ill-formed. I added a new test for selector_round, however I have not added one for batch prove as the function is still in progress. In the meantime I also added the folded OOD constraints, using the same points for both polynomials

let alpha: EF = challenger.sample_algebra_element();

// ==== Step 3: Extract claims from statements ====
// For now, we assume single-constraint statements
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No of course I have no problem to merge it as fast as possible. Even on the contrary, I prefer that we merge a first iteration with polynomials of same size and single constraint so that we can have a first idea and then iterate on the rest with followup PRs.

But I would still like us to have an end to end test with single constraint and for example 2 polynomials of the same size where the prove/verify workflow is working so that we are sure what we are doing is fully right.

Does this make sense?

My goal here is to make sure we don't merge code that is false and not working. In our case I think that the only way to confirm everything is working fine is by running the full end to end test.

Co-authored-by: Thomas Coratger <[email protected]>
@kilic
Copy link
Contributor

kilic commented Dec 26, 2025

Should we move first ood points sampling from CommitmentWriter::commit to Prover::prove. So that this PR can also use CommitmentWriter::commit

// Compute sumcheck polynomial coefficients:
// h(X) = Σ_b f_c(X, b) · w(X, b)
// We compute c0 = h(0) and c2 (quadratic coefficient)
let (c0, c2) = combined_poly.sumcheck_coefficients(&combined_weights);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we should allocate two new large space for concatenated polys. Notice that in sumcheck polys we already split them in the middle. Maybe for this use case we can introduce a new sumcheck_coefficient function instead of more memory usage

// σ' = h(r_0)

// Folded polynomial in extension field
let g = EvaluationsList::linear_combination(f_a, r_0, f_b, EF::ONE - r_0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly maybe it is possible to combine f_a and f_b onto f_a by getting f_a with mut value

.iter()
.zip(eq_z_b.iter())
.map(|(&a, &b)| r_0 * a + (EF::ONE - r_0) * b)
.collect();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. We can do it with only one multiplication r*(a-b) + b
  2. Or constructing eqs with r like EL::new_from_point(z_a.as_slice(), alpha *r ) and EL::new_from_point(z_a.as_slice(), alpha *(r-1)) and simple sum would work?
  3. Maybe this sum can be better in parallel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants