1b83dc2476
Mostly it's about Go 1.22+ syntax with ranging over integers, but it also prefers ranging over slices where possible (it makes code a little better to read). Notice that we have a number of dangerous loops where slices are mutated during loop execution, many of these can't be converted since we need proper length evalutation at every iteration. Signed-off-by: Roman Khimov <roman@nspcc.ru> |
||
---|---|---|
.. | ||
go.mod | ||
go.sum | ||
main.go | ||
main_test.go | ||
README.md | ||
response8 |
Example description
This example demonstrates how to create your own circuit and generate Groth-16 proof based on BLS12-381 elliptic curve points with the help of consensys/gnark. It also shows how to generate, deploy and invoke Verifier smart contract to verify proofs for the given circuit on the Neo chain with the help of zkpbindings NeoGo package. The package also contains circuit tests implemented with gnark/test to check the circuit validity and end-to-end proof generation/verification test implemented with neotest to demonstrate how to build, deploy and verify proofs via Verifier smart contract for the given circuit.
Groth-16 setup notes
Common reference string (CRS) is needed to generate proving and verifying keys for the given constrained system. In production environment, CRS generation can be performed via Multi-Party Computation (MPC) ceremony that includes two phases: Phase 1 (a.k.a. Powers of Tau) that is curve-specific and those results may be used by all circuits; and Phase 2 that is circuit-specific and uses the result of Phase 1 as an input.
For testing setups, check out the TestCubicCircuit_EndToEnd
keys generation stage. For production usage, read the information below.
Both phases for BLS12-381 curve can be implemented in the Go programming language
using the corresponding consensys/gnark
API (see the
test example)
and the example of a
CLI tool that uses the API with BN254 elliptic curve
to organize the ceremony and generate proving and verifying keys for a circuit.
However, both phases take a significant amount of time and computations to be
performed. Luckily for the developers, it is possible to omit a curve-specific
part of the MPC and reuse the existing results of Phase 1 got from a trusted
source, e.g. from Zcash PowersOfTau
held by the Zcash Foundation.
TestCubicCircuit_EndToEnd_Prod
test of the current circuit example demonstrates
how to use the response
output file from the Phase 1 of the Filecoin's Powers
of Tau ceremony for BLS12-381 curve:
response8
file is the response output from the ceremony that was run locally based on the Filecoin Powers of Tau with theREQUIRED_POWER
set to 8 (to reduce computations and response file size). The ceremony itself was run with the help of testing script. To get the response file for a production environment, the user has two options:- Organize his own ceremony with required number of powers following the guide from the ceremony source repo.
- Download the existing suitable
response
file from the trusted existing ceremony. Please, be careful while choosingresponse
file and ensure that it has enough powers computed (at least as much as the number of the circuit's constraints requires). Example of suitable ceremonies:- Zcash Powers Of Tau attestations page (up to 2^21)
- Filecoin Perpetual Powers Of Tau attestations page (up to 2^27)
- main_test contains the
TestCubicCircuit_EndToEnd_Prod
test itself and demonstrates how to properly initialize Phase 2 based on the given response file and make some dummy contributions into it.
Take the TestCubicCircuit_EndToEnd_Prod
test logic as a basis
while generating the circuit-specific proving and verifying keys for the production
usage. Currently, we don't have a BLS12-381 specific Groth-16 setup CLI utility
like for BN254 curve, but eventually
it will be included into the NeoGo toolkit to make the development process easier.
Don't hesitate to contact us if you're looking for a similar CLI utility for
BLS12-381 curve.