-
Notifications
You must be signed in to change notification settings - Fork 158
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
Feat/fold pedersen #407
Merged
Merged
Feat/fold pedersen #407
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
lgtm, just to be sure could you add a test where a proof is tampered to check that it "fails successfully ^^" ? |
ThomasPiellard
approved these changes
Jun 9, 2023
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.
In anticipation of multicommits for Groth16, this PR provides the possibility to verify multiple proofs of knowledge for Pedersen commitments more efficiently (by consolidating MSMs, generating the proof might be a bit faster as well)
Similarly to KZG, a value$r$ is obtained from a single-challenge Fiat-Shamir object using byte arrays provided by the user (the reason for custom byte arrays explained later.) Then instead of shipping $\set{(C_i, \pi_i)}_i$ where $C_i$ are commitments and $\pi_i$ the corresponding proofs of knowledge, the prover sends $(\set{C_i}_i, \pi \coloneqq \sum_i r^i\pi_i)$ .$C \coloneqq \sum_i r^iC_i$ and instead of checking $e(C_i,g)=e(\pi_i,g^{1/\sigma})$ multiple times, checks once that $e(C,g)=e(\pi,g^{1/\sigma})$ .
The verifier in turn computes
From the user's perspective, the breaking change is that the function
pk.Commit
does not yield a proof of knowledge anymore. A later call topk.ProveKnoweldge
orpedersen.BatchProve
will be necessary. Another potentially annoying change is thatpedersen.Setup
returns([]ProvingKey, VerifyingKey, error)
instead of the previous(ProvingKey, VerifyingKey, error)
so even a user that is dealing with one commitment only has to deal with a slice and write lines likepk[0].Commit...
.Remark: Normally in Fiat-Shamir one would expect hashing all the commitments that are to be verified, perhaps along with a nonce coming from the user. However, if we allow the user to take control of this, in the Groth16+Commitments verifier we could hash the representations of the commitment values in Fr, rather than the larger group elements. An alternative could be for the
Fold
functions to hash the compressed representations of the commitment values directly. Would welcome your input on this design choice.