Complete Curdleproof migration to generic group backend #5
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
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
Signed-off-by: Ignacio Hagopian <[email protected]>
jsign
commented
Sep 24, 2023
Comment on lines
-56
to
+70
| z.inner = bls12381.GT{} | ||
| z.inner.SetOne() |
There was a problem hiding this comment.
The default bls12381.GT{} is the neutral element in the additive group. But we live in a multiplicative subgroup, so the correct neutral element is one, not zero.
| @@ -45,15 +47,27 @@ func (z *GtElement) AddAssign(e Element) Element { | |||
| return z | |||
| } | |||
|
|
|||
| func (z *GtElement) SubAssign(e Element) Element { | |||
| ee := e.(*GtElement).inner | |||
| z.inner.Div(&z.inner, &ee) | |||
There was a problem hiding this comment.
SubAssign it's a new one needed. Prob a good idea to have in mind.
Comment on lines
-14
to
+15
| return &GtElement{} | ||
| res := &GtElement{} | ||
| res.inner.SetOne() |
There was a problem hiding this comment.
Improved for correctness, because we're in a multiplicative subgroup of F_12.
Comment on lines
+117
to
+127
| var byts [48 * 12]byte | ||
| for i := 0; i < 6; i++ { | ||
| a, err := r.GetG1Affine() | ||
| if err != nil { | ||
| return bls12381.GT{}, nil | ||
| } | ||
| abytes := a.RawBytes() | ||
| copy(byts[i*(48*2):], abytes[:]) | ||
| } | ||
| var randElem bls12381.GT | ||
| if _, err := randElem.SetRandom(); err != nil { | ||
| if err := randElem.SetBytes(byts[:]); err != nil { |
There was a problem hiding this comment.
Thanks to the test verifiers complaining... we were using SetRandom(), where we should use the randomness from r *Rand to get deterministic setup generation.
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.
This PR completes migrating to the generic backend that can run G1 and GT (or any group with order
Frfield size).TL;DR - Show me the numbers
Here’s the benchmark for a complete curdleproofs run in various setups:
Prover:
Verifier (please see the "Notes and caveats" section):
Internal arguments:
Note: the
(Ams+Bms)refers toAmsfor the verifier logic, andBmsfor the accumulated MSM check.Note: the setups for these are scaled down; IIRC length is usually 128. We could do "more serious" benchmarks for different sizes if needed.
Notes and caveats
The implementation for G1 is the same as the original implementation, so nothing is interesting to say here. There're some inefficiencies due to the generic group abstraction layer. In any case, if G1 is decided to be used we can remove that an probably avoid those inefficiencies (i.e: the original impl).
The implementation for GT is fine but naive/optimizable. The most naive and inefficient implementation is doing MSMs in GT. Mostly because this is implemented now as a sum of scalar multiplications, which could be better. This was done now since the plan was to have this working for a generic group so that we can improve on that. We could use a Pippenger variant over GT, apply any trick for the GT algebraic structure (if any?), or any other idea. This means that the "GT verifier" numbers should be taken with a grain of salt, so adjust your interpretation accordingly.
I'm using a version of gnark-crypto that has a patch I did some days ago to improve the performance of G1 equality checks, which became relevant for the new way the MSM accumulator works. The gnark team still has to review that, but I'm taking that out of the way so it doesn't interfere with the results. When (and if) gets merged, I'll switch back to
gnark-crypto@master, just to avoid pointing to a my fork.Correctness
I also migrated all existing tests, which exist for completeness and soundness. I mostly did this to gain some confidence that things were working as expected; like, the chance of all this working with all that passing and having a mistake is quite low. (And actually, I got into some bug-fixing rabbit holes “thanks” to that).
Run with
go test ./... -v. (I won't paste the output; it's too long).Reproduce in your machine
For curdleproofs:
For tests and internal arguments ~benchs, run:
go test ./... -v -parallel=1Review notes
I'll leave this PR open for a day or two, and then I'll merge it into the base PR and copy this same PR description.
I'm not doing much commenting on the PR since I'm not expecting a review since it's quite massive... but I got into some rabbit holes catching bugs. It's not the nicest thing to see a proof verification failing; that's finding a needle in a haystack... in any case, this had a happy ending.