Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimising proving by avoiding recomputing final Pi polynomial in MLKZG #242

Merged
merged 3 commits into from
Jan 10, 2024

Conversation

storojs72
Copy link
Member

Fixes #228

The obvious solution could be just reducing the number of iteration in following loop to ell-1 with subsequent pushing eval to polys. But, as @adr1anh noted in some of discussions we don't need to compute the commitment to this constant polynomial at prover side, since verifier has all necessary information to do that on its side, so in this PR, the EvaluationArgument created by prover contains comms without commitment to eval. It is recomputed at verifier's side and added to com vector before executing kzg_verify_batch.

Important detail

The following check:

if i == ell - 1 && *eval != Pi[0] {
    return Err(NovaError::UnSat);
}

from initial implementation is no longer needed, because we don't compute final Pi but add eval to polys instead, so it is removed. The wrong eval is now detected during proof verification and unit-test added to enforce this.

Question to reviewers

We don't actually use the C parameter while proving. In original implementation it was used only inside kzg_open_batch just to validate the input size and nowhere else at sensible computations. Is that expected?

Copy link
Contributor

@adr1anh adr1anh left a comment

Choose a reason for hiding this comment

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

This looks correct to me! However, we can be slightly more optimal by avoiding the opening of the constant polynomial entirely.

The prover only needs to open the ell polynomials, where the first one is the initial input one, and the last one is of size 2. In the first phase of the verification, the verifier uses the fact that ypos[ell] = yneg[ell] = Y[ell] = *y (the evaluation of the constant polynomial).

  • Change the size to ell rather than ell+1 in L395
  • Append *y to Y in L400.

src/provider/mlkzg.rs Outdated Show resolved Hide resolved
src/provider/mlkzg.rs Outdated Show resolved Hide resolved
src/provider/mlkzg.rs Outdated Show resolved Hide resolved
@storojs72 storojs72 added this pull request to the merge queue Jan 10, 2024
Merged via the queue into dev with commit 6c0945e Jan 10, 2024
10 checks passed
@storojs72 storojs72 deleted the issue-232 branch January 10, 2024 15:32
huitseeker pushed a commit to huitseeker/arecibo that referenced this pull request Jan 14, 2024
* Revert "Digest simplifications (lurk-lab#238)"

This reverts commit 71ecb66.

* upgrade neptune

* make the public interface uniform wrt refs vs. copies

* simplify prove_step
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Avoid computing polynomial which is constant
2 participants