Optimize FRI remainder polynomial check #1670
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Feb 26, 2025
Open
Al-Kindi-0
force-pushed
the
al-update-recursive-verifier-after-horner-eval-and-optimize-remainder
branch
from
693f6a8 to
9dfec5e
Compare
Al-Kindi-0
force-pushed
the
al-update-recursive-verifier-after-horner-eval-and-optimize-remainder
branch
from
7f5a4e6 to
361ffab
Compare
bobbinth
reviewed
Mar 19, 2025
adr1anh
reviewed
Mar 19, 2025
| where | ||
| E: FieldElement, | ||
| { | ||
| p.iter().fold(E::ZERO, |acc, &coeff| acc * E::from(x) + coeff) |
There was a problem hiding this comment.
Suggested change
| p.iter().fold(E::ZERO, |acc, &coeff| acc * E::from(x) + coeff) | |
| p.iter().reduce(|acc, &coeff| acc * E::from(x) + coeff).unwrap_or(E::ZERO) |
There was a problem hiding this comment.
I think fold is a bit cleaner to me, but no strong preference, let me know
There was a problem hiding this comment.
That's perfectly fine, especially since this is a test, and it only saves one multiplication.
| let remainder = channel.read_remainder::<4>(remainder_commitment)?; | ||
| for (pos, eval) in final_pos_eval.iter() { | ||
| if remainder[*pos] != *eval { | ||
| let remainder_poly = channel.read_remainder::<4>(remainder_commitment)?; |
There was a problem hiding this comment.
Can we replace the const generic with a constant?
There was a problem hiding this comment.
With the recent changes, we don't need the const anymore so I removed it now
Thank you for pointing it out
|
@Al-Kindi-0 - v0.12.2 |
plafer
approved these changes
Mar 19, 2025
Al-Kindi-0
force-pushed
the
al-update-recursive-verifier-after-horner-eval-and-optimize-remainder
branch
from
a517393 to
36abaf7
Compare
bobbinth
approved these changes
Mar 20, 2025
bobbinth
deleted the
al-update-recursive-verifier-after-horner-eval-and-optimize-remainder
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up to #1665.$64$ , $128$ , $256$ on the degree of the remainder polynomial where tested and the choice $128$ was found to be optimal when the number of FRI queries is $27$ .
Instead of using the probabilistic NTT to do the FRI remainder polynomial check, we use direct polynomial evaluation using
horner_eval_ext.In the process of this PR, the strict bounds
The recursive verifier in #1665, verifies an execution trace of size
1 << 20rows in:The recursive verifier in this PR, verifies an execution trace of size
1 << 20rows in:Putting in draft until the preceding PRs get merged.