With my co-authors Aurore Guillevic and Diego F. Aranha, we published on ePrint mid-May a survey of elliptic curves for proof systems (ePrint 2022/586). Recently, there have been many tailored constructions of these curves that aim at efficiently implementing different kinds of proof systems. In that survey we provide the reader with a comprehensive view on existing work and revisit the contributions in terms of efficiency and security. We present an overview at three stages of the process:
In this post, we are only interested in the first case. For pairing-based SNARKs, such as the circuit-specific Groth16 [1], bilinear pairings () are needed for the proof verification. For universal SNARKs, such as PLONK [2] or Marlin [3], a polynomial commitment scheme is needed. An example of an efficient one is the Kate-Zaverucha-Goldberg (KZG) scheme [4]. The verifier needs to verify some polynomial openings using bilinear pairings.
So far, for both circuit-specific and universal constructions, the verification algorithms boil down mainly to pairing computations. However, the prover work is not the same. For Groth16, it is mainly multi-scalar-multiplications (MSM) in both and while for KZG-based schemes it is mainly MSMs in only. In section 4 of the survey paper, we look at a particular family of pairing-friendly elliptic curves suitable for KZG. We derive algorithm 6 to tailor this family to the SNARK context. Note that KZG is also useful for other compelling applications such as Verkle trees for blockchain stateless clients.
A pairing is a non-degenrate bilinear map
where
We usually deal with type-3 pairing where
The integer is defined as the smallest integer such that and coordinates can be sometimes compressed into a smaller field because can be isomorphic to the -torsion on a different curve for some (the twist degree) that characterizes the curve .
A pairing-friendly curve construction aims at generating a curve with not too big (for efficient arithmetic in and ) and not too small (for hard discrete logarithm DLP in ). The widely used BLS12-381 curve [5], is defined over a field of size 381 bits and has a prime subgroup order of 255 bits. It has so is over and so is over . This curve is derived from the Barreto-Lynn-Scott of embedding degree 12 (BLS12) family and aims at optimizing the computations in all fronts:
In some applications as we will see in KZG, not all fronts should be optimized to the same extent. One can for example reduce the size of the at the cost of the size.
A polynomial commitment scheme allows to commit to a polynomial and then open it at any point (showing that the value of the polynomial at a point is equal to a claimed value, i.e. ).
correctnes:
So far, we have seen that the KZG commitment is a MSM computation in only. Thus, a KZG-friendly curve should be a pairing-friendly curve where is the smallest possible, the pairing fast and can be big though. The BLS24 family is suitable for these goals because one can reduce size (w.r.t. DLP in ) and still have a fast pairing (curve seed is 32 bits, half the size of BLS12). However, for SNARKs, we need to be highly 2-adic, i.e. to be able to implement efficient polynomial arithmetic using radix-2 Fast Fourier Transforms (FFT).
However, as mentioned in this GitHub thread [6], there are only possible seeds that fit lead to bits and by enumerating these the best high 2-adicity achieved is 22. In the survey paper, we propose a different Hensel-like technique for lifting multiple roots and thus increasing the 2-adicity. With this technique (Alg. 6), we found a particular BLS24 curve of 2-adicity 60. It has similar properties to BLS12-381 but is tailored for KZG-based SNARKs.
curve | seed | 2-adicity | security | ||||
---|---|---|---|---|---|---|---|
BLS24-317 | 0xd9018000 (HW=6) | 60 | 255 | 317 | 1268 | Yes | 127 |
BLS12-381 | -0xd201000000010000 (HW=6) | 32 | 255 | 381 | 762 | Yes | 126 |
I implemented this curve in gnark-crypto and Diego implemented it in Relic. Hereafter, I benchmark KZG operations (gnark-crypto) over BLS24-317 and BLS12-381 curves on a AMD EPYC 7R32 AWS machine.
We see that the commitments and openings are ~20% faster on the new BLS24-317 while the verification is way slower but still acceptable (3.3 ms vs. 1.4 ms). This is due to the cost of in the pairing computation. However, this can be somewhat reduced following [7], which we have not implemented in gnark-crypto yet.
For KZG-based applications that want to speed up the commitment (and opening) parts of the computations (e.g. PLONK or Marlin prover), it seems that the BLS24-317 curve is faster than the well-optimized BLS12-381 curve. However, this comes at the cost of a slower verification although, in many applications, the timings are acceptable (e.g. 3.7 ms for a batch verification of 10 commitments). It was also believed that BLS24 are incompatible with high 2-adicity in which we proved it is not.
[1] https://eprint.iacr.org/2016/260.pdf
[2] https://eprint.iacr.org/2019/953.pdf
[3] https://eprint.iacr.org/2019/1047.pdf
[4] https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf
[5] https://hackmd.io/@benjaminion/bls12-381
[6] https://github.com/arkworks-rs/curves/issues/10#issuecomment-714863120
[7] https://eprint.iacr.org/2010/104.pdf
Author: Youssef El Housni.
I'm part of a research team at ConsenSys. If you are interested in our work (fast finite field arithmetic, elliptic curves, pairings, and zero-knowledge proofs), give us a shout.