-
Notifications
You must be signed in to change notification settings - Fork 495
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
Extract permutation argument and introduce typed challenges #70
Conversation
Codecov Report
@@ Coverage Diff @@
## main #70 +/- ##
==========================================
+ Coverage 80.63% 80.72% +0.08%
==========================================
Files 24 28 +4
Lines 3254 3330 +76
==========================================
+ Hits 2624 2688 +64
- Misses 630 642 +12
Continue to review full report at Codecov.
|
Rebased to fix merge conflicts with #59. |
mod verifier; | ||
|
||
#[derive(Debug, Clone)] | ||
pub(crate) struct Proof<C: CurveAffine> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This currently uses a single permutation "proof" to represent all the permutations added to the circuit. This was the most straight-forward refactoring of the existing code (making review of the moving pieces easier), but we will probably want to alter this in a subsequent PR to instead have a proof per permutation (similar to the lookup argument PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've now extracted the permutation keygen logic as well, and I've done so in the same way as the lookup argument (Vec<permutation::Argument>
).
.chain( | ||
permutation_product_cosets_owned | ||
.into_iter() | ||
.map(move |coset| Polynomial::one_minus(coset) * &pk.l0), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting tidbit: strictly speaking the pk.l0
is needed for just the permutation argument, but because it's also used by the lookup argument (not yet introduced) keeping it in pk
is fine with me. Just worth pointing out.
// Sample gamma challenge | ||
let gamma = ChallengeGamma::get(&mut transcript); | ||
|
||
// Commit to permutations, if any. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose we wouldn't need to sample beta
and gamma
in the first place if there are no permutations/lookups -- though this scenario is unlikely to begin with, so it might not be worth fussing over.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's look at this again once the lookups PR is merged. Opened #82
This also centralises the challenge generation logic in Challenge::get, ensuring it is consistent across the codebase.
Once we refactor the permutation argument implementation to be integrated as Vec<permutation::Proof>, we can change this again to just map from the Vec<permutation::Argument> inside ConstraintSystem.
Rebased to fix conflicts with #61. |
Also added types for these challenges, even though it's not technically necessary yet because we don't pass these around anywhere.
The argument to the poly::commitment prover and verifier was mistakenly represented as a challenge, when in fact the commitments may be opened at any scalar (which just happens to be a challenge within poly::multiopen). The poly::commitment APIs are now public again.
Part of #62.