-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
Groth16 prover #463
base: master
Are you sure you want to change the base?
Groth16 prover #463
Conversation
I just had another look at SnarkJS to see if I can figure out the double Montgomery encoding situation. As it turns out at least I could identify the SnarkJS code that writes the coefficients as doubly Montgomery encoded. This happens here: const nR2 = curve.Fr.mul(n, R2r);
curve.Fr.toRprLE(buffCoeff, 12, nR2); where const R2r = curve.Fr.e(Scalar.mod(Scalar.mul(Rr,Rr), primeR)); Which at the very least finally ends the question of whether I'm imagining things or not. I still have no clue why this is done to be honest. The commits touching these lines are not very illuminating either. |
Otherwise when performing operations on EC points in Jacobian, depending on import these can be missing.
2be3509
to
47ba6f9
Compare
Previously these were generated from the wrong branch of the `{.booldefine.}` variables we had in the code when the PR was still a draft. Instead of parsing the data as doubly Montgomery encoded as they actually are, we parsed them as regular Montgomery encoded resulting in wrong test vectors.
Edit: The PR previously contained a long description of my debugging of the Groth16 prover implementation. For anyone interested, it can still be found here.
This PR implements a Groth16 prover and verifier, which requires SnarkJS produced
.wtns
,.zkey
and.r1cs
binary files.