Our team is continually working to improve the security, performance and usability of our privacy-preserving shielded transactions. As we mentioned in our near future priorities blog post, we are working on a collection of cryptographic improvements for the next version of Zcash named Sapling. One of our goals is to make shielded payments more efficient and less memory intensive. We also intend to improve the concrete security level of the elliptic curve construction that we use for our zk-SNARK proofs.

I spent some time last month designing and implementing a new pairing-friendly elliptic curve construction that is optimal for zk-SNARKs at the 128-bit security level. The construction minimizes performance and usability costs while increasing our security margins.

The construction will appear in an upcoming paper by our scientists, where it will be accompanied by a more thorough description of the construction and how it was selected.

## Barreto-Naehrig curves

Barreto-Naehrig (BN) curves are a class of pairing-friendly elliptic curve constructions built over a base field :math:`\mathbb{F}_q` of order :math:`r`, where :math:`r \approx q`. Our current curve construction has :math:`q \approx 2^{254}`. Last year, Kim and Barbulescu presented a variant of the Number Field Sieve algorithm which reduced a conservative [1] estimate of the security level to around 110 bits based on a recent paper.

It is possible to construct a new BN curve that targets 128-bit security, even according to this conservative estimate, by selecting a curve closer to :math:`q \approx 2^{384}`. However, the larger group order :math:`r` impairs the performance of multi-exponentiation, fast fourier transforms and other cryptographic operations that we need to perform efficiently in zk-SNARK schemes and multi-party computations. Additionally, the larger scalar field :math:`\mathbb{F}_r` makes keying material unnecessarily large.

## Barreto-Lynn-Scott curves

Barreto-Lynn-Scott (BLS) curves are a slightly older class of pairing-friendly curves which now appear to be more useful for targeting this security level. Current research suggests that with :math:`q \approx 2^{384}`, and with an embedding degree of 12, these curves target the 128-bit security level. Conveniently, the group order for these curves is :math:`r \approx 2^{256}`, which allows us to avoid the performance and usability drawbacks that accompany a larger scalar field.

## BLS12-381

In zk-SNARK schemes, we need to manipulate very large polynomials over the scalar field :math:`\mathbb{F}_r`. We can perform efficient multi-point evaluation/interpolation with fast fourier transforms, so long as we ensure :math:`\mathbb{F}_r` is equipped with a large :math:`2^s` root of unity.

As is common, we target a subfamily of these curves that has optimal extension field towers and simple twisting isomorphisms. In order to ensure Montgomery reductions and other approximation algorithms are space-efficient, we target :math:`r \approx 2^{255}` so that the most significant bit of :math:`r` (and :math:`q`) are unset with 64-bit limbs.

As usual, in order to optimize for pairing performance, we ensure the parameterization of the BLS curve has low Hamming weight. The curve we have ultimately chosen is named **BLS12-381** as :math:`q \approx 2^{381}`.

u = -0xd201000000010000k = 12q = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaabr = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001E(Fq) := y^2 = x^3 + 4Fq2 := Fq[i]/(x^2 + 1)E'(Fq2) := y^2 = x^3 + 4(i + 1)

## Rust language implementation

I have begun working on an implementation of the construction in Rust as part of my pairing library. The library has the goal of being portable, standards compliant, and high performance. Due to the nature of zk-SNARK schemes, it is difficult to efficiently construct proofs in constant time, and so the library does not currently focus on side channel resistance.

Future blog posts will describe a number of techniques and tools that our scientists have devised for using this curve construction to optimize Zcash.

[1] | Menezes, Sarkar and Singh (http://eprint.iacr.org/2016/1102.pdf) show 2^110 is a conservative estimate for the size of the space of polynomials that needs to be scanned for smooth polynomials. However, for the case q=p^12 relevant for BN curves there is no currently published efficient method for scanning this space. (Checking each polynomial separately for smoothness would result in total running time larger than 2^128.) Thus, to the best of our knowledge the most efficient currently known fully described algorithm for breaking the curve Zcash is presently using is Pollard’s rho, which would run in time sqrt(q)~2^127. (Our thanks to Palash Sankar and Shashank Singh for helping understand their result.) |