gnark is a fast, open-source library for zero-knowledge proof protocols written in Go



License Go Report Card PkgGoDev

gnark is a framework to execute (and verify) algorithms in zero-knowledge. It offers a high-level API to easily design circuits and fast implementation of state of the art ZKP schemes.

gnark has not been audited and is provided as-is, use at your own risk. In particular, gnark makes no security guarantees such as constant time implementation or side-channel attack resistance.

gnark is optimized for amd64 targets (x86 64bits) and tested on Unix (Linux / macOS).

Get in touch: [email protected]

Proving systems


  • BLS377
  • BLS381
  • BN256
  • BW761

Getting started


You'll need to install Go.

Install gnark

go get

Note that if you use go modules, in go.mod the module path is case sensitive (use consensys and not ConsenSys).


Our blog post is a good place to start. In short:

  1. Implement the algorithm using gnark API (written in Go)
  2. r1cs, err := frontend.Compile(&circuit) to compile the circuit into a R1CS
  3. pk, vk := groth16.Setup(r1cs) to generate proving and verifying keys
  4. groth16.Prove(...) to generate a proof
  5. groth16.Verify(...) to verify a proof


You can find the documentation here. In particular:

Examples and gnark usage

Examples are located in /examples.


  1. To define a circuit, one must implement the frontend.Circuit interface:
// Circuit must be implemented by user-defined circuits
type Circuit interface {
	// Define declares the circuit's Constraints
	Define(curveID gurvy.ID, cs *ConstraintSystem) error
  1. Here is what x**3 + x + 5 = y looks like
// CubicCircuit defines a simple circuit
// x**3 + x + 5 == y
type CubicCircuit struct {
	// struct tags on a variable is optional
	// default uses variable name and secret visibility.
	X frontend.Variable `gnark:"x"`
	Y frontend.Variable `gnark:",public"`

// Define declares the circuit constraints
// x**3 + x + 5 == y
func (circuit *CubicCircuit) Define(curveID gurvy.ID, cs *frontend.ConstraintSystem) error {
	x3 := cs.Mul(circuit.X, circuit.X, circuit.X)
	cs.AssertIsEqual(circuit.Y, cs.Add(x3, circuit.X, 5))
	return nil
  1. The circuit is then compiled (into a R1CS)
var circuit CubicCircuit

// compiles our circuit into a R1CS
r1cs, err := frontend.Compile(gurvy.BN256, &circuit)

Using struct tags attributes (similarly to json or xml encoders in Golang), frontend.Compile() will parse the circuit structure and allocate the user secret and public inputs [TODO add godoc link for details].

  1. The circuit can be tested like so:
assert := groth16.NewAssert(t)

	var witness CubicCircuit

	assert.ProverFailed(r1cs, &witness)

	var witness CubicCircuit
	assert.ProverSucceeded(r1cs, &witness)
  1. The APIs to call Groth16 algorithms:
pk, vk := groth16.Setup(r1cs)
proof, err := groth16.Prove(r1cs, pk, solution)
err := groth16.Verify(proof, vk, solution)


While several ZKP projects chose to develop their own language and compiler for the frontend, we designed a high-level API, in plain Go.

Relying on Go ---a mature and widely used language--- and its toolchain, has several benefits.

Developers can debug, document, test and benchmark their circuits as they would with any other Go program. Circuits can be versionned, unit tested and used into standard continuous delivery workflows. IDE integration (we use VSCode) and all these features come for free and are stable across platforms.

Moreover, gnark is not a black box and exposes APIs like a conventional cryptographic library (think aes.encrypt([]byte)). Complex solutions need this flexibility --- gRPC/REST APIs, serialization protocols, monitoring, logging, ... are all few lines of code away.

Designing your circuit


Three points to keep in mind when designing a circuit (which is close to constraint system programming):

  1. Under the hood, there is only one variable type (field element). TODO
  2. A for loop must have fix bounds. TODO
  3. if statements (named cs.Select() like in Prolog). TODO.

gnark standard library

Currently gnark provides the following components (see gnark/std):

  • The Mimc hash function
  • Merkle tree (binary, without domain separation)
  • Twisted Edwards curve arithmetic (for bn256 and bls381)
  • Signature (EdDSA Algorithm, following
  • Groth16 verifier (1 layer recursive SNARK with BW761)


It is difficult to fairly and precisely compare benchmarks between libraries. Some implementations may excel in conditions where others may not (available CPUs, RAM or instruction set, WebAssembly target, ...). Nonetheless, it appears that gnark, is about three time faster than existing state-of-the-art.

Here are our measurements for the Prover. These benchmarks ran on a AWS c5a.24xlarge instance, with hyperthreading disabled.

The same circuit (computing 2^(2^x)) is benchmarked using gnark, bellman (bls381, ZCash), bellman_ce (bn256, matterlabs).


number of constraints 100000 32000000 64000000
bellman_ce (s/op) 0.43 106 214.8
gnark (s/op) 0.16 33.9 63.4
speedup x2.6 x3.1 x3.4

On large circuits, that's over 1M constraints per second.


number of constraints 100000 32000000 64000000
bellman (s/op) 0.6 158 316.8
gnark (s/op) 0.23 47.6 90.7
speedup x2.7 x3.3 x3.5

Resources requirements

Depending on the topology of your circuit(s), you'll need from 1 to 2GB of RAM per million constraint. Algorithms are very memory intensive, so hyperthreading won't help. Many physical cores will help, but at a point, throughput per core is decreasing.


Please read for details on our code of conduct, and the process for submitting pull requests to us.


We use SemVer for versioning. For the versions available, see the tags on this repository.


This project is licensed under the Apache 2 License - see the LICENSE file for details

  • refactor: std/math/nonnative -> std/math/emulated

    refactor: std/math/nonnative -> std/math/emulated

    This PR refactors std/math/nonnative -> std/math/emulated.

    emulated.Field has no pointer receiver operations, and only usage is through NewField . Emulated arithmetic is now parametrized with the emulated field constants; usage is changed to:

    type Circuit struct {
    	// Limbs of non-native elements X, Y and Res
    	X, Y, Res emulated.Element[emulated.Secp256k1]
    func (circuit *Circuit) Define(api frontend.API) error {
    	// wrap API to work in SECP256k1 scalar field
    	secp256k1, err := emulated.NewField[emulated.Secp256k1](api)
    	if err != nil {
    		return err
    	tmp := secp256k1.Mul(circuit.X, circuit.Y)
    	secp256k1.AssertIsEqual(tmp, circuit.Res)
    	return nil
    // test file:
    func TestEmulatedArithmetic(t *testing.T) {
    	assert := test.NewAssert(t)
    	var circuit, witness Circuit
    	assert.ProverSucceeded(&circuit, &witness, test.WithCurves(ecc.BN254), test.WithBackends(backend.GROTH16), test.NoSerialization())
    opened by gbotrel 11
  • groth16.Verify should be able to verify bellman-generated proof

    groth16.Verify should be able to verify bellman-generated proof

    See #29 for more context.

    Need to parse bellman verifying key and proof data structures, and ensure 100% compatibility with groth16.Verify (and the pairing check).

    new feature 
    opened by gbotrel 9
  • Max limit on `big.Int` input to circuit?

    Max limit on `big.Int` input to circuit?

    Hi there,

    I'm doing some work with large inputs, and seem to have bumped into a limit on the input size.

    I can't seem to pass in inputs larger than 32 bytes through the circuit witness and get it to show up correctly.

    Minimal reproducible code:

    type Circuit struct {
    	Input frontend.Variable
    func (c *Circuit) Define(curveID ecc.ID, api frontend.API) error {
    	api.AssertIsEqual(c.Input, 0)
    	return nil
    func main() {
    	var circuit Circuit
    	r1cs, err := frontend.Compile(ecc.BN254, backend.GROTH16, &circuit)
    	if err != nil {
    	pk, _, _ := groth16.Setup(r1cs)
    	largeInput := []byte{}
    	// OK at 32
    	// Not OK at 33
    	for i := 0; i < 33; i++ {
    		largeInput = append(largeInput, 1)
    	b := big.Int{}
    	var witness Circuit
    	_, _ = groth16.Prove(r1cs, pk, &witness)

    Output with 33 bytes:

    main.go:62 After:
    main.go:63 6804961502579882823803940537337563421717456721072708258376200659378844532988

    Output with 32 bytes:

    main.go:62 After:
    main.go:63 454086624460063511464984254936031011189294057512315937409637584344757371137

    Any ideas on how I can get around this limit?

    opened by vck3000 8
  • Frontend refactoring

    Frontend refactoring

    This PR is a long overdue, it cleans up the way the plonk constraint system is added, and makes the code upgradable for different new constraint systems (custom gates, generalised arithmetic circuits, square constraints, etc).


    The frontend is now organised like this:

    frontend/ ├── compiler ├── cs │   ├── plonk │   └── r1cs └── utils


    api.go provides the API interface that a constraint system should implement (with the usual fonctions like Add, Mul, etc). It also provides an interface System with inherits from API, and provides the fonctions

    type System interface {
    	NewPublicVariable(name string) Variable
    	NewSecretVariable(name string) Variable
    	Compile(curveID ecc.ID) (compiled.CompiledConstraintSystem, error)

    circuit.go provides the interface that a circuit should implement (as before).


    compile.go provides the logic to build a constraint system to its target form (r1cs or sparse r1cs). It provides the same function Compile as in develop. The difference is that buildCS has been renamed bootStrap and takes as parameter the System interface. It acts exactly as in develop, recursively instantiating the inputs and calling Define afterwards.


    cs.go provides the common data shared by each constraint system:

    type ConstraintSystem struct {
    	// input wires
    	Public, Secret []string
    	CurveID ecc.ID
    	// BackendID backend.ID
    	// Coefficients in the constraints
    	Coeffs         []big.Int      // list of unique coefficients.
    	CoeffsIDsLarge map[string]int // map to check existence of a coefficient (key = coeff.Bytes())
    	CoeffsIDsInt64 map[int64]int  // map to check existence of a coefficient (key = int64 value)
    	// map for recording boolean constrained variables (to not constrain them twice)
    	MTBooleans map[int]struct{}

    It is essentially a list of coefficients, to be affected to wires, it is agnostic of the constraints. It inherits from CS defined in package compile.

    r1cs/, plonk/

    Those folders contain the actual instantiation of plonk constraint systme and Groth16 constraint system (respectively sparse_r1cs and r1cs in our naming).

    r1cs/ contains the same api as in develop, the files were merely moved from frontend/ tor1cs/. 'plonk/' contains the equivalent data but for sparseR1CS. In particular an api.go has been created for handling plonk constraints, so there is no longer a conversion from r1cs to sparser1cs.

    Both constraint systems inherit from ConstraintSystem, with an additional field which is the slice of the actual constraints (ex:

    type SparseR1CS struct {
    	Constraints []compiled.SparseR1C


    In both r1cs/and plonk/there is aconversion.go file providing a Compile function which essentially shifts the IDs of the variables in the logs, etc after a circuit is built. This function is internally called by Compile defined in frontend/compiler/compile.go.

    API breaking changes

    • frontend.Compile --> compiler.Compile
    • type Hint struct {ID hint.ID , Inputs []Variable}--> type Hint struct {ID hint.ID, Inputs []interface{}}


    Tests pass, except the circuits_stats tests for several of the circuits used in integration tests have been extended to cover more cases. There is no change in Groth16 in terms of number of constraints (Groth16 logic hasn't been modified at all, the files were merely moved around).

    opened by ThomasPiellard 8
  • Add hint registry

    Add hint registry

    Added hint registry for registering hint functions used in gadgets. Improved the documentation to help explain the usage of hints.


    • [x] Prover should define all registered hint functions.
    • [x] Find usages of hint functions and document a bit more.
    opened by ivokub 7
  • Is there mimc hash implemented by solidity language

    Is there mimc hash implemented by solidity language

    we are constructing a gnark proof system on ethereum. the public input part need be verified by mimc hash on solidity contract as the circuit implemented with gnark. could you tell me if there is corresponding solidiy implement to mimc hash in gnark? many thanks!

    opened by mdj33 6
  • feat: implement non-native field emulation

    feat: implement non-native field emulation

    This PR adds a new standard gadget std/math/nonnative for performing non-native field operations in a circuit. It is trying to follow big.Int-like interface, but is not completely compatible.

    The PR is mostly ready, but still some things to do:

    • [x] add tests for more complex computations
    • [x] implement Select and Lookup2
    • [x] write a nice documentation which lists all the assumptions the library does to ensure the validness of the computation
    new feature 
    opened by ivokub 5
  • feat(std): add LessThan() and IsEqual()

    feat(std): add LessThan() and IsEqual()

    Hi guys,

    I've found some time to give this a go :).

    I have implemented LessThan() and IsEqual() as a new math package under std. Currently, this implementation gives it great isolation and builds on top of the current frontend.api without touching it.

    I was hoping to simplify LessThan() to compute a < b, however, I found that I still needed the full functionality of Compare(). If b is greater than a, it needs to be recorded too and persisted to the end of the loop. Without this, if a has a less significant bit set where b's is not, then it will appear as though a > b incorrectly.

    As such, I wanted to ask whether you guys wanted to relax the feature from LessThan() to Compare() given both require the same amount of work, but Compare() gives more functionality to the user. I can also see the benefit of simplifying the interface and keeping it as LessThan(), so also happy to keep it just as is and include the reduction done in the final lines of the current implementation:

    	// Now, convert output of Convert() into LessThan()
    	return m.IsEqual(output, -1)

    Another thing I was hoping to do was to add it directly into frontend.api. However, I had some issues getting the tests to run. Here is the link to my attempted commit on my fork: LINK

    An example of the error is:

    === RUN   TestCompare/fuzz/bw6_761/plonk
                    Error Trace:    assert.go:356
                    Error:          Received unexpected error:
                                    compilation is not deterministic
                    Test:           TestCompare/fuzz/bw6_761/plonk

    However, this implementation also means that the code has to be duplicated thrice across r1cs, plonk and engine. I could not work out a way to prevent code duplication here if I added it straight into frontend.api.

    What do you guys think? I like the idea of having api.LessThan() and api.IsEqual(); however it may be cleaner to have these in a new std/math package.

    Open to suggestions and feedback!

    opened by vck3000 5
  • feat: added frontend/schema to dynamically create circuit/witness Schema

    feat: added frontend/schema to dynamically create circuit/witness Schema

    This PR uses new APIs introduced in Go 1.17 to clean the circuit structure parser.

    This parser moved from internal/parser to frontend/schema .

    Additionally, this parser now returns a Schema struct when walking through a circuit.

    A Schema can then be instantiated into a typed object using reflect.StructOf and reflect.StructFields[] . See schema_test.go for examples.

    This PR is necessary for witness.ToJSON / FromJSON.

    • feat: added frontend/schema to build circuit and witness schemas

    • fix: remove embbed struct tag

    • [ ] Will clean up the error returns from the parser

    new feature 
    opened by gbotrel 5
  • std/sw: use faster double-and-add for scalar multiplication and add constant scalar multiplication fast-path

    std/sw: use faster double-and-add for scalar multiplication and add constant scalar multiplication fast-path

    Implemented the method for computing (P+Q)+P as described in Then, separated two execution paths for scalar multiplication depending on the scalar type:

    • if scalar is a variable, then executes the generic scalar multiplication on variables (i.e. the scalar can be private,public,constant variable).
    • otherwise, if scalar is a circuit parameter, then compiles the circuit based on the scalar bits.

    For BW6-761 using Groth backend, the number of constraints went down from ~3.7k to 2662.

    There are still some further improvement:

    • [x] every double-and-add adds 7 constraints instead of claimed 5.
    • [x] double-and-add is incomplete for case P=Q. Due to this, we need to handle two high bits separately in the main scalar multiplication loop.
    • [x] scalar multiplication depends on the group order of BLS12-377. The dependence should be on the supplied curve (maybe add a method for getting companion curve params to ecc.ID?)
    • [x] there is additional optimization as described on page in using group endomorphism. This allows to reduce the numbers in the main loop by two.
    • [x] the number of constraints explodes when using PLONK backend.
    • [x] rebase on develop after #186 merged.
    opened by ivokub 5
  • Support PLONK

    Support PLONK

    PLONK is a new zk-snarks algorithm, which is based on Sonic. It can realize SRS (no longer need to generate CRS for each circuit separately), and it is very practical compared to Sonic. Can we modify gnark to support PLONK? I want to make some contributions to the project, so I have the following issues:

    • PLONK's circuit construction method is not based on R1CS. Will we make a big modification on the existing code ?
    • If the modifications are not significant, how will they be modified? Which parts of the code should be modified? Now gnark uses ConstraintSystem to define the Groth16 circuit, whether it is necessary to construct a new class or based on the existing ConstraintSystem.
    opened by SherLzp 5
  • `examples/cubic` test fails with PlonK + FRI

    `examples/cubic` test fails with PlonK + FRI

        --- FAIL: TestCubicEquation/bw6_633/plonkFRI#01 (0.01s)
                    Error Trace:    assert.go:539
                    Error:          plonkFRI(bw6_633): algebraic relation does not hold
                    Test:           TestCubicEquation/bw6_633/plonkFRI#01
    opened by gbotrel 1
  • `std/math/emulated`: constrain the limbs for the inputs and the witness

    `std/math/emulated`: constrain the limbs for the inputs and the witness

    Technically, the API encourages the use of NewElement[T] or Assign which will build element with correct number of limbs.

    But since these limbs are unconstrained, there is no soundness guarantees at the proof system level.

    opened by gbotrel 0
  • Ability to select exponent in MIMC hash function

    Ability to select exponent in MIMC hash function

    Referencing to -

    I think it would be good to have the ability to select the exponent which you want for the MIMC hash inside the circuit. Currently, the library uses exponent 5 for MIMC, but many libraries for Ethereum use exponent 7.

    I would love to take this up with a little bit of guidance on how I shall implement this.

    I made a similar issue in gnark-crypto -

    opened by shryasss 0
  • Can not passed XOR boolean check, even though I only use Binary Operations.

    Can not passed XOR boolean check, even though I only use Binary Operations.

    I have tried a lot of ways to do the xor process, however it wont work. Here's my code.

    the first part is about change the variables to binary, for this function we use the api XOR/OR/AND function as an parameter f

    func UInt64BitOperation(api *frontend.API, a, b frontend.Variable, f func(a, b frontend.Variable) frontend.Variable) frontend.Variable {
    	cs := *api
    	aBits := cs.ToBinary(a, 64)
    	bBits := cs.ToBinary(b, 64)
    	var resBits []frontend.Variable = make([]frontend.Variable, 64)

    And this below which is straight thinking but won't work

    	for i := 0; i < 64; i++ {
    		resBits[i] = f(aBits[i], bBits[i])

    And I have tried another way.

    	for i := 0; i < 64; i++ {
    		aC := (*api).Select(aBits[i], One, Zero)
    		bC := (*api).Select(bBits[i], One, Zero)
    		resBits[i] = f(aC, bC)

    I just check the value in hint function, so weird that aC, bC is all 1, but the XOR result returns a overflow number. And the error keep telling constraint #13307 is not satisfied: [assertIsBoolean] -1 == (0|1)

    I have seen there's saying boolean operations results will always be boolean, but it seems like not the situation. How should I do?thanks.

    opened by ZhAnGeek 2
  • Improve non-native arithmetic gadget

    Improve non-native arithmetic gadget

    Non-native arithmetic gadget has now been implemented. Collecting small snippets and improvement ideas for later improvement:

    • [ ] perf: maybe there is a more efficient method for checking that multiple bits are zeros.
    • [ ] perf: try to have more efficient splitting of a variable (instead of doing full binary decomposition and recomposition of the slices, create only the needed split)
    • [ ] perf: consider the case where the emulated field is a lot smaller than the native field. If the operations never overflow the native field, then maybe there are more efficient ways for reducing the values (we would be interested in Goldilocks field).
    • [ ] perf: implement fast paths for cases where inputs are constants
    • [ ] refactor: we differentiate between constant and variable. Add checks to ensure user does not try to use constant as value receiver (they still get panic, but for other reasons and isn't helpful for the user)
    • [ ] feat/perf: theoretically it is possible to optimise modular exponentiation using Wesolowsky RSA VDF verification. Not high-priority yet.
    • [ ] feat: implement Sqrt
    • [ ] refactor: check that the elements belong to the same field in operations.
    • [ ] refactor: add sanity checks before the operations (e.g. that overflow is sufficient and do not need to reduce)
    • [ ] refactor: split variable.go into variable.go and params.go
    • [ ] perf: look into Montgomery form for representing elements. It may allow for more efficient modular reduction after multiplication (a la Aztec/Jellyfish)
    • [ ] perf: when initialising constant from big.Int, then instead of creating all nbLimbs limbs, create only sufficient number of limbs to fit the constant. NB! in this case we should be certain that the placeholder limb count corresponds to the witness limb count.
    • [ ] perf: for lookup2 and select we need that the inputs have the same number of limbs and overflow. But actually the can be different, just the result has to have maximum number of limbs and overflow
    • [ ] test: implement tests for expected failures
    • [ ] feat: remove Placeholder when compiling circuits.
    consolidate perf 
    opened by ivokub 0
  • test: `ConstraintSystem` solvers should have test vectors

    test: `ConstraintSystem` solvers should have test vectors

    Solvers testing could be improved; instead of just testing provided witness against big.Int test engine, we should add test vectors and compare the full solution vector against expected [edge-cases] values.

    opened by gbotrel 0
  • v0.7.0(Mar 27, 2022)

    [v0.7.0] - 2022-03-25


    • go.mod: go version upgrade 1.16 --> go1.17
    • update to gnark-crpto v0.7.0


    • adds gnark logger. closes #202
    • added internal/stats package: measure number of constraints of circuit snippets for regression
    • adds std/math/bits/ToNAF ToBinary ToTernary


    • enables recursive hints solving #293 and
    • move init() behind sync.Once. remove verbose option in stats binary
    • fixes #266 by adding constant path in Lookup2 and Select
    • incorrect handling of nbBits == 1 in api.ToBinary
    • PlonK vulnerability: thanks to Trail Of Bits for finding this vulnerability and responsibly disclosing it


    • restored frontend.WithCapacity option...
    • plonk: IsConstant -> ConstantValue
    • sw: no need for Lookup2 in constScalarMul
    • remove offset shifts in plonk compile
    • remove post-compile offset id in R1CS builder


    • frontend.Compile now takes a builder instead of backendID as parameter
    • std/signature/eddsa Verify api now takes explicit hash and curve objects
    • make nboutputs of a hint explicit at compile time
    • std/pairing have more consistent apis
    • remove StaticHint wrapper, log duplicate hints (#289)
    • backend.WithOutput -> backend.WithCircuitLogger
    • remove all internal circuits from stats, keep important snippets only
    • frontend: split compiler, api and builder interface into interfaces
    • remove IsBoolean from R1CS variables
    • moved internal/compiled to frontend/compiled

    Pull Requests

    • Merge pull request #295 from ConsenSys/fix/test-println
    • Merge pull request #294 from ConsenSys/fix/recursivehhints
    • Merge pull request #291 from ConsenSys/refactor/std/pairing
    • Merge pull request #281 from ConsenSys/feat/logger
    • Merge pull request #280 from ConsenSys/simplify-r1cs-compile
    • Merge pull request #279 from ConsenSys/feat/statistics
    • Merge pull request #276 from ConsenSys/feat-math-bits
    • Merge pull request #278 from ConsenSys/perf-constant-lookup2
    • Merge pull request #272 from ConsenSys/refactor-hint
    • Merge pull request #275 from ConsenSys/refactor-compiler-builder
    • Merge pull request #271 from ConsenSys/refactor-compiled
    • Merge pull request #267 from ConsenSys/perf/tEd-add
    • Merge pull request #265 from ConsenSys/perf/SW-constScalarMul
    Source code(tar.gz)
    Source code(zip)
  • v0.6.4(Feb 15, 2022)

    [v0.6.4] - 2022-02-15


    • update to gnark-crpto v0.6.1


    • Constraint system solvers (Groth16 and PlonK) now run in parallel


    • api.DivUnchecked with PlonK between 2 constants was incorrect


    • EdDSA: std/algebra/twistededwards takes ~2K less constraints (Groth16). Bandersnatch benefits from same improvments.

    Pull Requests

    • Merge pull request #259 from ConsenSys/perf-parallel-solver
    • Merge pull request #261 from ConsenSys/feat/kzg_updated
    • Merge pull request #257 from ConsenSys/perf/EdDSA
    • Merge pull request #253 from ConsenSys/feat/fft_cosets
    Source code(tar.gz)
    Source code(zip)
  • v0.6.3(Feb 13, 2022)

    [v0.6.3] - 2022-02-13


    • MiMC changes: api doesn't take a "seed" parameter. MiMC impl matches Ethereum one.


    • fixes #255 variable visibility inheritance regression
    • counter was set with PLONK backend ID in R1CS
    • R1CS Solver was incorrectly calling a "MulByCoeff" instead of "DivByCoeff" (no impact, coeff was always 1 or -1)
    • SparseR1CS cbor unmarshal failed #247 for compiled.Term

    Pull Requests

    • Merge pull request #256 from ConsenSys/fix-bug-compile-visibility
    • Merge pull request #249 from ConsenSys/perf-ccs-hint
    • Merge pull request #248 from ConsenSys/perf-ccs-solver
    • Merge pull request #247 from ConsenSys/fix/plonk_cbor
    Source code(tar.gz)
    Source code(zip)
  • v0.6.2(Jan 28, 2022)

    [v0.6.2] - 2022-01-28


    • go version dependency bumped from 1.16 to 1.17


    • added witness.MarshalJSON and witness.MarshalBinary
    • added ccs.GetSchema() - the schema of a circuit is required for witness json (de)serialization
    • added ccs.GetConstraints() - returns a list of human-readable constraints
    • added ccs.IsSolved() - moved from groth16 / plonk to the CompiledConstraintSystem interface
    • added witness.Public() to return Public part of the witness
    • addition of Cmp in the circuit API


    • compiled.Visbility -> schema.Visibiility
    • witness.WriteSequence -> schema.WriteSequence
    • killed ReadAndProve and ReadAndVerify (plonk)
    • killed ReadAndProve and ReadAndVerify (groth16)
    • remove embbed struct tag for frontend.Variable fields


    • backend: unify documentation for options
    • frontend: unify docs for options
    • test: unify documentation for options

    Pull Requests

    • Merge pull request #244 from ConsenSys/plonk-human-readable
    • Merge pull request #237 from ConsenSys/ccs-get-constraints
    • Merge pull request #233 from ConsenSys/feat/api_cmp
    • Merge pull request #235 from ConsenSys/witness-public-api
    • Merge pull request #232 from ConsenSys/cleanup-231-group-options
    • Merge pull request #230 from ConsenSys/ccs-schema
    • Merge pull request #229 from ConsenSys/ccs-issolved-api
    • Merge pull request #228 from ConsenSys/witness-json
    • Merge pull request #226 from ConsenSys/feat-circuit-schema
    • Merge pull request #227 from ConsenSys/build-update-go1.17
    • Merge pull request #222 from ConsenSys/perf/std-sw-glv
    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Jan 4, 2022)

    [v0.6.0] - 2022-01-03

    Important: next release (v0.7.0) will be compatible with Go1.18+ only

    Breaking changes

    • circuit.Define(curveID, api) -> circuit.Define(api); added api.Curve() to retrieve curve info
    • api.Constant(...) was removed. Can now directy assign values with = operator in the circuit definition and the witness assignment.
    • frontend.Variable is now an alias for interface{}
    • assert helper is now under gnark/test. Instead of taking a CompiledConstraintSystem it takes a Circuit as input, enabling easier tests accross curves and proving schemes through the use of test/TestingOption (WithBackends(backend.GROTH16), WithCurves(ecc.BN254), ...)
    • api.NewHint handles multiple outputs and custom solver Hint definition has changed


    • added explicit warning when parser encounters unadressable struct field #169
    • FromInterface supports uintXX and intXX types closes #197
    • lighter stack trace by default for circuits, more verbose when -tags=debug provided
    • added api.Tag and api.AddCounter to measure number of constraints in portion of circuit
    • api.DivUnchecked does not handle zero divisor. api.Div does.
    • added frontend.IsConstant and ConstantValue apis
    • add support for bw6-633 curve
    • added api.Lookup2 method (2-bit lookup)
    • frontend: plonk frontend directly implements the frontend.API interface instead of building on top of the R1CS builder
    • std: fields and pairing over BLS24-315 in BW6-633 circuit
    • test: add Run for running circuit test configurations as subtests
    • test: add Log method for logging in subtests
    • test: assert helper cross check constraint system solver results with big.Int test execution engine


    • std: verifying a Pairing (bls12-377, Groth16) inside a circuit went from ~40k constraints to less than <12k constraints


    • fixes #169 ensure frontend.Circuit methods are defined on pointer receiver
    • fixes #178 by adding cbor.MaxMapPairs options when reading R1CS
    • fixed AssertIsBoolean in plonk (mul by constant failed)
    • fixes #168 adds context to a non-deterministic compilation error in the Assert object
    • frontend: reduce constant by modulus
    • frontend: plonk compiler now outputs a reasonable number of constraints #186


    • updated to gnark-crypto v0.6.0

    Pull Requests

    • Merge pull request #192 from ConsenSys/multi-hint
    • Merge pull request #220 from ConsenSys/feat-from-interface
    • Merge pull request #217 from ConsenSys/fix-internal-compiled
    • Merge pull request #191 from ConsenSys/assert-subtests
    • Merge pull request #200 from ConsenSys/refactor/frontend
    • Merge pull request #205 from ConsenSys/fix/constant-mod-reduction
    • Merge pull request #186 from ConsenSys/fix/plonk_constraints
    • Merge pull request #185 from ConsenSys/feat/bw6-633
    • Merge pull request #189 from ConsenSys/lookup2
    • Merge pull request #183 from ivokub/hint-registry
    • Merge pull request #182 from ConsenSys/std/pairing
    • Merge pull request #176 from ConsenSys/feat-constraint-counter
    • Merge pull request #180 from ConsenSys/refactor-variable-interface
    • Merge pull request #173 from ConsenSys/feat-debug-tag
    Source code(tar.gz)
    Source code(zip)
  • v0.5.2(Nov 3, 2021)

    [v0.5.2] - 2021-11-03

    Breaking changes

    • circuit Define(... cs *frontend.ConstraintSystem) now takes an interface Define( ... api frontend.API)
    • assert helper is now under backend/ (instead of backend/groth16 and backend/plonk)


    • updated to gnark-crypto v0.5.3


    • added api.DivUnchecked and api.Div. DivUnchecked will accept 0 / 0 == 0 as valid.
    • api.Sub takes a variadic list of input (same as api.Add)
    • plonk: kzg test srs is cached up to a certain size for faster tests
    • removed hardcoded bit size in ToBinary, which now depends by default on fr.Element bit size
    • api.ToBinary: constraint unsatisfied now has debugInfo
    • unset variables: error message comes with a stack trace
    • added bandersnatch circuit component under std/
    • frontend.Compile now check that all secret and public inputs are constrained. Check can be ignore through compile option (frontend.IgnoreUnconstrainedInputs)
    • added UnsafeReadFrom for groth16 Proving and Verifying keys, which doesn't perform subgroup checks on the decoded points


    • incorrect formula in api.Select when parameters are constant
    • plonk: reduce duplicate constraint when splitting r1c in the frontend
    • plonk: build permutation index out of bounds


    • added a test/ package with a test execution engine cross checking constraint system with big.Int arithmetic
    • bases for Fuzzing witness and cross checking constraint system output with test execution engine


    • api.AssertIsLessOrEqual: reduced redundant constraints in range check
    • std/groth16: ml with short addition chain (13245cs -> 12297, marginal gain)


    • all circuits use frontend.API in place of *frontend.ConstraintSystem
    • use ecc.Info() where possible to get modulus or field size

    Pull Requests

    • Merge pull request #159 from ConsenSys/std/bandersnatch
    • Merge pull request #164 from ConsenSys/perf-scs-compile
    • Merge pull request #161 from ConsenSys/test-engine-with-hints
    • Merge pull request #162 from ConsenSys/std/pairing
    • Merge pull request #160 from ConsenSys/perf-unsafe-decoding
    • Merge pull request #156 from ConsenSys/std/twistedEdwards
    • Merge pull request #151 from ConsenSys/testable-circuits
    • Merge pull request #153 from ConsenSys/fix/plonk_constraints_blowup
    • Merge pull request #146 from ConsenSys/feat/ml-snark-pairing
    • Merge pull request #148 from ConsenSys/perf-range-check
    Source code(tar.gz)
    Source code(zip)
  • v0.5.1(Sep 21, 2021)

    [v0.5.1] - 2021-09-20



    • adds solver hints cs.NewHint #139
    • adds cs.AssertIsDifferent #131
    • consistent support of cs.Println and debugInfo #142
    • adds sanity check in frontend.Compile to ensure constraint validity
    • adds witness.WriteSequence to export expected witness sequence
    • adds sanity checks in R1CS and SparseR1CS solvers
    • adds ToHTML on SparseR1CS and R1CS
    • add witness reconstruction methods. closes #135


    • IsZero is now implemented with 3 constraints #134
    • Groth16 maximize number of infinity points in G2 part of the ProvingKey #130


    • can constraint linear expressions to be boolean fixes #136
    • eddsa: addition of isOnCurve check
    • eddsa: S not splitted (s<r) + 2,3 Double instead of [cofactor]G


    • groth16.Prove and plonk.Prove takes backend.ProverOption as parameter
    • factorized structs between compiled.SparseR1CS and compiled.R1CS
    • assertions -> constraints in R1CS and SparseR1CS
    • removed r1c.SolvingMethod in favor of cs.NewHint
    • cs.IsZero doesn't need curveID anymore


    • ensure frontend.Compile is deterministic
    • added non regression for cs.Println and debugInfo traces
    • added circuit statistic non regression tests
    • added plonk path to integration_test.go
    • added test from #136
    Source code(tar.gz)
    Source code(zip)
ConsenSys Software
ConsenSys is the software engineering leader of the blockchain space. Our full-stack Ethereum products help developers build next-generation networks.
ConsenSys Software
go-zero is a web and rpc framework written in Go. It's born to ensure the stability of the busy sites with resilient design. Builtin goctl greatly improves the development productivity.

go-zero English | 简体中文 0. what is go-zero go-zero is a web and rpc framework that with lots of engineering practices builtin. It’s born to ensure the

好未来技术 20.6k Sep 19, 2022
beego is an open-source, high-performance web framework for the Go programming language.

Beego Beego is used for rapid development of enterprise application in Go, including RESTful APIs, web apps and backend services. It is inspired by To

astaxie 532 Sep 25, 2022
beego is an open-source, high-performance web framework for the Go programming language.

Beego Beego is used for rapid development of enterprise application in Go, including RESTful APIs, web apps and backend services. It is inspired by To

beego Framework 28.9k Sep 27, 2022
letgo is an open-source, high-performance web framework for the Go programming language.

high-performance Lightweight web framework for the Go programming language. golang web framework,高可用golang web框架,go语言 web框架 ,go web

wjp 349 Sep 7, 2022
go-zero is a web and rpc framework that with lots of engineering practices builtin.

go-zero is a web and rpc framework that with lots of engineering practices builtin. It’s born to ensure the stability of the busy services with resilience design, and has been serving sites with tens of millions users for years.

null 454 Sep 22, 2022
Muxie is a modern, fast and light HTTP multiplexer for Go. Fully compatible with the http.Handler interface. Written for everyone.

Muxie ?? ?? ?? ?? ?? ?? Fast trie implementation designed from scratch specifically for HTTP A small and light router for creating sturdy backend Go a

Gerasimos (Makis) Maropoulos 277 Sep 24, 2022
⚡ Rux is an simple and fast web framework. support middleware, compatible http.Handler interface. 简单且快速的 Go web 框架,支持中间件,兼容 http.Handler 接口

Rux Simple and fast web framework for build golang HTTP applications. NOTICE: v1.3.x is not fully compatible with v1.2.x version Fast route match, sup

Gookit 81 Jul 20, 2022
Fast and Reliable Golang Web Framework

Gramework The Good Framework Gramework long-term testing stand metrics screenshot made with Gramework Stats Dashboard and metrics middleware What is i

null 371 Sep 19, 2022
henrylee2cn 1.6k Sep 16, 2022
Best simple, lightweight, powerful and really fast Api with Golang (Fiber, REL, Dbmate) PostgreSqL Database and Clean Architecture

GOLANG FIBER API (CLEAN ARCHITECTURE) Best simple, lightweight, powerful and really fast Api with Golang (Fiber, REL, Dbmate) PostgreSqLDatabase using

Elias Champi 3 Sep 2, 2022
Fastrest - fast restful framework for golang.

fastrest fast restful framework for golang. Create your app directory, like mkdir myapp; cd myapp; go mod init myapp; Create initial config.toml in a

bingoohuang 0 Jan 11, 2022
Gin is a HTTP web framework written in Go (Golang).

Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.

Gin-Gonic 62.9k Sep 19, 2022
BANjO is a simple web framework written in Go (golang)

BANjO banjo it's a simple web framework for building simple web applications Install $ go get Example Usage Simple Web App

Nazarii Sheremet 19 Jan 24, 2022
⚡️ Express inspired web framework written in Go

Fiber is an Express inspired web framework built on top of Fasthttp, the fastest HTTP engine for Go. Designed to ease things up for fast development w

Fiber 22.4k Sep 19, 2022
Gearbox :gear: is a web framework written in Go with a focus on high performance

gearbox ⚙️ is a web framework for building micro services written in Go with a focus on high performance. It's built on fasthttp which is up to 10x fa

Gearbox 672 Sep 27, 2022
Tigo is an HTTP web framework written in Go (Golang).It features a Tornado-like API with better performance. Tigo是一款用Go语言开发的web应用框架,API特性类似于Tornado并且拥有比Tornado更好的性能。

Tigo(For English Documentation Click Here) 一个使用Go语言开发的web框架。 相关工具及插件 tiger tiger是一个专门为Tigo框架量身定做的脚手架工具,可以使用tiger新建Tigo项目或者执行其他操作。

Karl 1.4k Sep 25, 2022
QOR is a set of libraries written in Go that abstracts common features needed for business applications, CMSs, and E-commerce systems.

QOR English Chat Room: 中文聊天室: For security issues, please send us an email to [email protected] and give us time to respond BEFORE posting as an iss

QOR 5.1k Sep 24, 2022
Headless CMS with automatic JSON API. Featuring auto-HTTPS from Let's Encrypt, HTTP/2 Server Push, and flexible server framework written in Go.

Ponzu Watch the video introduction Ponzu is a powerful and efficient open-source HTTP server framework and CMS. It provides automatic, free, and secur

Ponzu 5.5k Sep 16, 2022
Gearbox :gear: is a web framework written in Go with a focus on high performance

gearbox ⚙️ is a web framework for building micro services written in Go with a focus on high performance. It's built on fasthttp which is up to 10x fa

Gearbox 669 Sep 22, 2022