# Efficient ECC in zkSNARKs using ZoKrates

May 28, 2021
ZoKrates [https://github.com/Zokrates/ZoKrates] is a toolbox for zkSNARKs on Ethereum. It includes an easy-to-use  domain-specific language for developers to leverage the power of  zero-knowledge proofs in their decentralized applications. Elliptic Curve Cryptography (ECC) is a powerful tool that has many  applications in the blockchain space and cryptography in general. With one of the last releases, we added support for efficient ECC-based cryptographic primitives inside a zkSNARK construction. We outlined how to use these primitives in this previous blog post [https://medium.com/zokrates/building-identity-linked-zksnarks-with-zokrates-a36085cdd40] . In  this blog post, we provide theoretical background with regards to this  process. We explain how to construct an elliptic curve, which is  efficient in zkSNARKs. We start by understanding the zkSNARK prime field  arithmetics programming model before providing an introduction to  elliptic curves. We then describe how to construct an efficient elliptic  curve on top of this abstraction and how to use this curve within  ZoKrates. In a followup blog post, we will dig deeper into the applications of  elliptic curve cryptography in zkSNARKs, e.g., more efficient hashing  and digital signature schemes. While we try to provide all the information necessary to follow along,  this blog post assumes some knowledge of zkSNARKs and the underlying  mathematics. If you are interested in learning more about the  mathematical foundations of zkSNARKs, you may find the following blog  posts by the community helpful: [1] [https://z.cash/technology/zksnarks/], [2] [https://medium.com/@VitalikButerin/zkSNARKs-under-the-hood-b33151a013f6], [3] [/zk-SNARKs-primer-part-one/]. Disclaimer: The goal of this document is to be an  introduction to the matter and hence not all theory is covered  rigorously. Perfect fidelity could interfere with the understanding of  the main concepts when dealing with a complex new topic. zkSNARK Programming — Arithmetics in prime fields Before diving into elliptic curves and their construction, let’s quickly recap the programming model of zkSNARKs. Any computation that you want to prove with a zkSNARK has to be  expressed as arithmetic operations on a finite field. More specifically,  this finite field is a prime field. You can think of it as a set of  natural numbers smaller than a huge prime: $$\mathbb{F}_p = \mathbb{Z}\,mod\, p$$ This set has two basic arithmetic operations, addition and multiplication, which are commutative and associative and together fulfill the distributive law: $$$a + b = c\,(mod\, p), \quad a,b \in \mathbb{F}_p \\ a * b = c\,(mod\, p), \quad a,b \in \mathbb{F}_p.$$$ This  may look complex, but it simply says that you can add and multiply  numbers as you’re used to; however, you need to apply the mod operation afterwards. The operations of a field always have an inverse:  Hence, you can also subtract and divide. Note, however, that the division may behave unlike you’d expect [https://en.wikipedia.org/wiki/Finite_field_arithmetic]. Fortunately,  when working with ZoKrates, you do not need to take care of the  translation into prime field arithmetics. ZoKrates does all the magic  for you as part of the compilation process in the background and  provides an easy to use programming abstraction. Hence, the following  ZoKrates DSL code def f(x): def main(field a, field b) -> (field): field result = a + b return result is actually computing a+b (mod p). The  important takeaway of this section is that in zkSNARK programming all  variables are field elements and we perform all arithmetic operations  modulo a large prime number p. The  prime field we work in when programming zkSNARKs is defined by the  elliptic curve chosen to implement a zkSNARK proving system. To be more  precise, the prime p which represents the field modulus is defined by the group order r of the elliptic curve. This will become clearer after elliptic curves have been introduced in the following section. Ethereum  provides pre-compiled contracts for the BN128 (also known as BN254)  curve, which enable cheap curve operation on the blockchain. Operations  inside a zkSNARK program, constructed using that curve, will wrap around  the prime: p = 21888242871839275222246405745257275088548364400416034343698204186575808495617 Elliptic Curves in 5 Minutes Now,  that we know which operations are available to us in zKSNARKs, let’s  brielfy look at the core properties of elliptic curves, so we know what  we need to implement. From a high-level perspective, an elliptic curve is something very simple: A finite cyclic group. A group is a set with only one operation that fulfills closure, associativity, identity and invertibility [https://en.wikipedia.org/wiki/Group_(mathematics)].  That’s just a fancy way of saying we have an “addition” operation which  obeys all the basic arithmetic rules we’re intuitively used to. A finite group is a group with a finite number of elements. We refer to this finite number of elements in the group as the group’s order r. What’s  peculiar about elliptic curves is the way the elements in this group  look and how the “addition” operation is defined: An element of an  elliptic curve is a pair of prime field elements (remember, we know those from before!). Fun  math fact: Since the prime field is finite, the set of pairs is also  finite, which directly implies finiteness of the group constructed on  top. To be elements of the group, i.e., the elliptic curve, these pairs need  to satisfy an elliptic curve equation that looks like this: $$y^{2}=x^{3}+ax+b$$ However, for the purpose of this post, we do not need to bother about  this too much. What is important to understand is that given an elliptic  curve the points of that curve are the elements of the corresponding  finite group. It’s size is defined by the number of points that satisfy  the equation above. Furthermore, the addition of two points for the  chosen curve-family is a well-defined operation, for which an  exceptionless closed-form formula exists. The addition of two points on  the curve always results in a new point on the curve. As an example,  here is the closed-form formula for adding two points on a particular type of curve [https://en.wikipedia.org/wiki/Twisted_Edwards_curve#Addition_on_twisted_Edwards_curves] : $$\left(x_{1}, y_{1}\right)+\left(x_{1}, x_{2}\right)=\left(\frac{x_{1} y_{2}+y_{1} x_{2}}{1+d x_{1} x_{2} y_{1} y_{2}}, \frac{y_{1} y_{2}-a x_{1} x_{2}}{1-d x_{1} x_{2} y_{1} y_{2}}\right) \quad(\bmod p)$$ Since the elliptic curve is defined over the prime field $\mathbb{F}_p$ , i.e., the curve points (x,y) consist of field elements, the curve addition inherits the mod p operation. Unfortunately, modulo operations are costly in zkSNARKs as they rely on operations (comparisons, …) which are very inefficient. Is this game over for elliptic curves in zkSNARKS, or is there a way to get around this costly modulo operation? Constructing an Embedded Curve In  the elliptic curve addition, we need to apply the modulo operation by  the order of the field the curve is defined over, which we referred to  as p. The alert reader might have spotted already  that we can apply a nifty trick here: Wouldn’t it be convenient if the  order of the field our elliptic curve is defined over would exactly  match the modulus in our zkSNARK arithmetics? In other words, can we  make sure the fields share the same p? This  is the rationale behind the sampling of an embedded curve. An embedded  curve is an elliptic curve where the parameters have been sampled such  that the underlying prime field 𝔽_p matches the group order of a host  curve and hence the modulus in the arithmetic field. Thus, EC operations on the embedded curve boil down to prime field arithmetics using the field-native mod p operations. In other words — we get the modulo operations during  elliptic curve computations “for free”: With the matching moduli the  formula for point addition is reduced to a couple of multiplications and  additions. This makes embedded curve operations very efficient inside a  SNARK. An example of an embedded curve and the one we also use in ZoKrates is the so-called baby_JubJub elliptic curve. Here, curve parameters have been sampled such that the prime field 𝔽_p the baby_JubJub curve is defined over matches the group order of the BN128 curve used in Ethereum. More details on baby_JubJub can be found here [https://github.com/barryWhiteHat/baby_jubjub_ecc]. Zcash [https://z.cash/technology/jubjub/] also published a nice article describing the motivation behind the original JubJub curve, which follows the same rationale as baby_JubJub but is designed for a different modulus p (Zcash is not using the BN128 curve in the zkSNARK proof system anymore). One important takeaway we want to highlight is that the baby_JubJub curve is just another program that is programmed in ZoKrates and then  compiled as a zkSNARK. In case you don’t believe us feel free to have a  look at the standard library [https://github.com/Zokrates/ZoKrates/tree/master/zokrates_stdlib/stdlib/ecc] of ZoKrates. Unsurprisingly, the point addition formula mentioned above is also there [https://github.com/Zokrates/ZoKrates/blob/master/zokrates_stdlib/stdlib/ecc/edwardsAdd.code] : def f(x): import "ecc/babyjubjubParams.code" as context // Add two points on a twisted Edwards curve // Curve parameters are defined with the last argument // https://en.wikipedia.org/wiki/Twisted_Edwards_curve#Addition_on_twisted_Edwards_curves def main(field[2] pt1, field[2] pt2, field[10] context) -> (field[2]): field a = context[0] field d = context[1] field u1 = pt1[0] field v1 = pt1[1] field u2 = pt2[0] field v2 = pt2[1] field uOut = (u1*v2 + v1*u2) / (1 + d*u1*u2*v1*v2) field vOut = (v1*v2 - a*u1*u2) / (1 - d*u1*u2*v1*v2) return [uOut, vOut] Following this small detour, we now have access to efficient elliptic  curve computations inside the zkSNARK and can leverage this for elliptic  curve based constructions like Pedersen hashes and signatures inside a  zkSNARK program. Why secp256k1 and other curves don’t work Ethereum uses a curve called secp256k1 [https://en.bitcoin.it/wiki/Secp256k1] for its signature scheme ECDSA (Elliptic Curve Digital Signature  Algorithm). As the preceding link shows, the curve is defined over the  finite field with the following order: $$r=2^{256}-2^{32}-2^{9}-2^{8}-2^{7}-2^{6}-2^{4}-1$$ Unsurprisingly, in this case, the order, r, does not match the modulo p we have in our zkSNARK construction. In contrast to baby_JubJub, the field order, in that case, is way larger ( r > p ),  hence we can not map all values to elements on the given BN128 curve.  There is a way to represent these values in their binary format, also  called binary expansion, but this clearly is a very  inefficient representation. Note that in this case we also wouldn’t get  the modulo operation “for free” as the moduli don’t match. The resulting constraint system would be so large that it makes it impractical to use Secp256k1 inside zkSNARKs, but fortunately, we now have baby_JubJub 🚀. Conclusion In  the first post of this series, we discussed some of the high-level  properties of elliptic-curve cryptography and showed how we can  construct efficient curves zkSNARKs. Next  time, we will extend our zkSNARK Swiss army knife with the tools  necessary to compute efficient hashes in zkSNARKs. Until then! Acknowledgment We’d like to thank the following contributors and reviewers of the blog post: JacobEberhardt [https://github.com/JacobEberhardt] and Schaeff [https://github.com/Schaeff] from the ZoKrates team, as well as sanchopansa [https://github.com/sanchopansa] and kobigurk [https://github.com/kobigurk/]. 🍻 In addition big thanks to all the people in the ZKP community. In particular to BarryWhitehat [https://github.com/barryWhiteHat] and HarryR [https://github.com/HarryR] for their work on integrating SNARKs into Ethereum. Also folks like Sean Bowe [https://github.com/ebfull] and the whole ECC and Zcash foundation team for their advancements and amazing implementations.