gnark-crypto provides efficient cryptographic primitives, in Go:

• Elliptic curve cryptography & Pairing on:
  • bn254 (audit report)
  • bls12-381 (audit report)
  • bls24-317
  • bls12-377 / bw6-761
  • bls24-315 / bw6-633
  • bls12-378 / bw6-756
  • Each of these curves has a twistededwards sub-package with its companion curve which allow efficient elliptic curve cryptography inside zkSNARK circuits.
• field/goff - Finite field arithmetic code generator (blazingly fast big.Int)
• fft - Fast Fourier Transform
• fri - FRI (multiplicative) commitment scheme
• fiatshamir - Fiat-Shamir transcript builder
• mimc - MiMC hash function using Miyaguchi-Preneel construction
• kzg - KZG commitment scheme
• permutation - Permutation proofs
• plookup - Plookup proofs
• eddsa - EdDSA signatures (on the companion twistededwards curves)

gnark-crypto is actively developed and maintained by the team (gnark@consensys.net | HackMD) behind:

• gnark: a framework to execute (and verify) algorithms in zero-knowledge

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

To report a security bug, please refer to gnark Security Policy.

gnark-crypto packages are optimized for 64bits architectures (x86 amd64) and tested on Unix (Linux / macOS).

gnark-crypto is tested with the last 2 major releases of Go (currently 1.19 and 1.20).

go get github.com/consensys/gnark-crypto

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

Most (but not all) of the code is generated from the templates in internal/generator.

The generated code contains little to no interfaces and is strongly typed with a field (generated by the gnark-crypto/field package). The two main factors driving this design choice are:

1. Performance: gnark-crypto algorithms manipulate millions (if not billions) of field elements. Interface indirection at this level, plus garbage collection indexing takes a heavy toll on perf.
2. Need to derive (mostly) identical code for various moduli and curves, with consistent APIs. Generics introduce significant performance overhead and are not yet suited for high performance computing.

To regenerate the files, see internal/generator/main.go. Run:

go generate ./...

Benchmarking pairing-friendly elliptic curves libraries

The libraries are implemented in different languages and some use more assembly code than others. Besides the different algorithmic and software optimizations used across, it should be noted also that some libraries target constant-time implementation for some operations making it de facto slower. However, it can be clear that consensys/gnark-crypto is one of the fastest pairing-friendly elliptic curve libraries to be used in zkp projects with different curves.

If you use gnark-crypto in your research a citation would be appreciated. Please use the following BibTeX to cite the most recent release.

@software{gnark-crypto-v0.11.2,
  author       = {Gautam Botrel and
                  Thomas Piellard and
                  Youssef El Housni and
                  Arya Tabaie and
                  Gus Gutoski and
                  Ivo Kubjas},
  title        = {ConsenSys/gnark-crypto: v0.11.2},
  month        = jan,
  year         = 2023,
  publisher    = {Zenodo},
  version      = {v0.11.2},
  doi          = {10.5281/zenodo.5815453},
  url          = {https://doi.org/10.5281/zenodo.5815453}
}

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.