Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-2494 Baby Jubjub Elliptic Curve #2494

Merged
merged 38 commits into from
Sep 9, 2020
Merged
Changes from 2 commits
Commits
Show all changes
38 commits
Select commit Hold shift + click to select a range
ff2030e
Create eip-draft_babyjubjub.md
bellesmarta Jan 29, 2020
043e020
Update eip-draft_babyjubjub.md
bellesmarta Jan 29, 2020
9a819c9
Update eip-draft_babyjubjub.md
bellesmarta Jan 29, 2020
7ccdf09
Update eip-draft_babyjubjub.md
bellesmarta Jan 29, 2020
b3e12c9
Update eip-draft_babyjubjub.md
bellesmarta Jan 29, 2020
41569d7
Update eip-draft_babyjubjub.md
bellesmarta Jan 30, 2020
c884b8d
Merge remote-tracking branch 'ethereum/master' into HEAD
axic Aug 28, 2020
da59b37
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
95b3626
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
cf9b168
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
4844702
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
2136366
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
356f16a
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
895ed25
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
4662bc6
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
4aa99d1
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
0cddcf0
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
ac4f964
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
a31a627
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
0e33bb6
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
be6cd6e
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
50690f7
Update eip-draft_babyjubjub.md
bellesmarta Sep 4, 2020
e765ea3
Rename eip-draft_babyjubjub.md to eip-2494.md
MicahZoltu Sep 5, 2020
39603d3
Rename eip-2494.md to EIPS/eip-2494.md
MicahZoltu Sep 5, 2020
213049f
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
8c86a3e
Update eip-2494.md
bellesmarta Sep 9, 2020
2110a6d
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
0e69ff8
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
27e5015
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
dda3975
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
eb67892
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
84afd06
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
cdf893a
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
631944d
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
c46cafa
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
1261504
Update EIPS/eip-2494.md
axic Sep 9, 2020
26d6d0c
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
d8b905d
Update EIPS/eip-2494.md
bellesmarta Sep 9, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
364 changes: 364 additions & 0 deletions eip-draft_babyjubjub.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,364 @@
---
EIP: <to be assigned>
axic marked this conversation as resolved.
Show resolved Hide resolved
axic marked this conversation as resolved.
Show resolved Hide resolved
Title: Baby Jubjub Elliptic Curve
Authors: Barry WhiteHat (@barryWhiteHat),
axic marked this conversation as resolved.
Show resolved Hide resolved
Marta Bellés (@bellesmarta),
Jordi Baylina (@jbaylina)
Discussions-To: https://github.com/ethereum/EIPs/issues/2493
Status: Draft
Type: Standards Track
Category: ERC
Created: 2020-01-29
---

# Simple Summary
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->

This proposal defines Baby Jubjub, an elliptic curve designed to work inside zk-SNARK circuits in Ethereum.

# Abstract
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--A short (~200 word) description of the technical issue being addressed.-->

Two of the main issues behind why blockchain technology is not broadly used by individuals and industry are scalability and privacy guarantees. With a set of cryptographic tools called zero-knowledge proofs (ZKP) it is possible to address both of these problems. More specifically, the most suitable protocols for blockchain are called zk-SNARKs (zero-knowledge Succint Non-interactive ARguments of Knowledge), as they are non-interactive, have succint proof size and sublinear verification time. These types of protocols allow proving generic computational statements that can be modelled with arithmetic circuits defined over a finite field (also called zk-SNARK circuits).

To verify a zk-SNARK proof, it is necessary to use an elliptic curve. In Ethereum, the curve is alt_bn128 (also referred as BN254), which has primer order `r`. With this curve, it is possible to generate and validate proofs of any `F_r`-arithmetic circuit. This EIP describes *Baby Jubjub*, an elliptic curve defined over the finite field `F_r` which can be used inside any zk-SNARK circuit, allowing for the implementation of cryptographic primitives that make use of elliptic curves, such as the Pedersen Hash or the Edwards Digital Signature Algorithm (EdDSA).

# Motivation
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->

A [zero knowledge proof](https://en.wikipedia.org/wiki/Zero-knowledge_proof) (ZKP) is a protocol that enables one party, the prover, to convince another, the verifier, that a statement is true without revealing any information beyond the veracity of the statement. [Non-Interactive ZKPs](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Zero%20Knowledge/Noninteractive_Zero-Knowkedge.pdf) (NIZK) are a particular type of zero-knowledge proofs in which the prover can generate the proof without interaction with the verifier. NIZK protocols are very suitable for Ethereum applications, because they allow a smart contract to act as a verifier. This way, anyone can generate a proof and send it as part of a transaction to the smart contract, which can perform some action depending on whether the proof is valid or not. In this context, the most preferable NIZK are [zk-SNARK](https://eprint.iacr.org/2013/279.pdf) (Zero-knowledge Succint Non Interactive ARgument of Knowledge), a set of non-interactive zero-knowledge protocols that have succint proof size and sublinear verification time. The importance of these protocols is double: on the one hand, they help improve privacy guarantees, and on the other, they are a possible solution to scalability issues (e.g. see [zk-Rollup](https://github.com/barryWhiteHat/roll_up) project).

Like most ZKPs, zk-SNARKs permit proving computational statements. For example, one can prove things like: the knowledge of a private key associated with a certain public key, the correct computation of a transaction, or the knowledge of the preimage of a particular hash. Importantly, one can do these things without leaking any information about the statements in question. In other words, without leaking any information about the private key, the transaction details, or the value of the preimage. More specifically, zk-SNARKs permit proving any computational statement that can be modelled with an `F_r`-arithmetic circuit, a circuit consisting of set of wires that carry values from the field `F_r` and connect them to addition and multiplication gates `mod r`. This type of circuits are often called zk-SNARK circuits.

The implementation of most zk-SNARK protocols (e.g. [[Pinnochio]](https://eprint.iacr.org/2013/279.pdf) and [[Groth16]](https://eprint.iacr.org/2016/260.pdf)) make use of an elliptic curve for validating a proof. In Ethereum, the curve used is alt_bn128 (also referred as BN254), which has prime order `r`. While it is possible to generate and validate proofs of `F_r`-arithmetic circuits with BN254, it is not possible to use BN254 to implement elliptic-curve cryptography within these circuits. To implement functions that require the use of elliptic curves inside a zk-SNARK circuit -- such as the [Pedersen Hash](https://github.com/zcash/zips/blob/master/protocol/protocol.pdf) or the [Edwards Digital Signature Algorithm](https://tools.ietf.org/html/rfc8032) (EdDSA) -- a new curve with coordinates in `F_r` is needed. To this end, we propose in this EIP *Baby Jubjub*, an elliptic curve defined over `F_r` that can be used inside any `F_r`-arithmetic circuit. In the next sections we describe in detail the characteristics of the curve, how it was generated, and which security considerations were taken.

```
inputs zk-SNARK (alt_bn128) ouput
+--------------------------------------------+
| +--------------------+ |
--->| | EdDSA (Baby Jubjub)| |
| +--------------------+ |
--->| |--->
| +-----------------------------+ |
--->| | Pedersen Hash (Baby Jubjub) | |
| +-----------------------------+ |
+--------------------------------------------+
```

# Specification
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->

## Definition
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
Let `F_r` be the prime finite field with `r` elements, where
```
r = 21888242871839275222246405745257275088548364400416034343698204186575808495617
```

Let `E` be the twisted Edwards elliptic curve defined over `F_r` described by equation
```
ax^2 + y^2 = 1 + dx^2y^2
```
with parameters
```
a = 168700
d = 168696
```
We call **Baby Jubjub** the curve `E(F_r)`, that is, the subgroup of `F_r`-rational points of `E`.

## Order
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved

Baby Jubjub has order

```
n = 21888242871839275222246405745257275088614511777268538073601725287587578984328
```

which factors in
```
n = h x l
```
where
```
h = 8
l = 2736030358979909402780800718157159386076813972158567259200215660948447373041
```
The parameter `h` is called *cofactor* and `l` is a prime number of 251 bits.

## Generator point
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved

The point `G = (x,y)` with coordinates
```
x = 995203441582195749578291179787384436505546430278305826713579947235728471134
y = 5472060717959818805561601436314318772137091100104008585924551046643952123905
```
generates all `n` points of the curve.

## Base point
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved

The point `B = (x,y)` with coordinates

```
x = 5299619240641551281634865583518297030282874472190772894086521144482721001553
y = 16950150798460657717958625567821834550301663161624707787222815936182638968203
```
generates the subgroup of points `P` of Baby Jubjub satisfying `l * P = O`. That is, it generates the set of points of order `l` and origin `O`.

## Arithmetic
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved

Let `P1 = (x1, y1)` and `P2 = (x2, y2)` be two arbitrary points of Baby Jubjub. Then `P1 + P2 = (x3, y3)` is calculated in the following way:
```
x3 = (x1*y2 + y1*x2)/(1 + d*x1*x2*y1*y2)
y3 = (y1*y2 - a*x1*x2)/(1 - d*x1*x2*y1*y2)
```
Note that both addition and doubling of points can be computed using a single formula.

# Rationale
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

The search for Baby Jubjub was motivated by the need for an elliptic curve that allows the implementation of elliptic-curve cryptography in `F_r`-arithmetic circuits. The curve choice was based on three main factors: type of curve, generation process and security criteria. This section describes how these factors were addressed.

**Form of the curve**

Baby Jubjub is a **twisted Edwards** curve birationally equivalent to a **Montgomery** curve. The choice of this form of curve was based on the following facts:
1. The Edwards-curve Digital Signature Scheme is based on twisted Edwards curves.
2. Twisted Edwards curves have a single complete formula for addition of points, which makes the implementation of the group law inside circuits very efficient [[Crypto08/013, Section 6]](https://eprint.iacr.org/2008/013.pdf).
3. As a twisted Edwards curve is generally birationally equivalent to a Montgomery curve [[Crypto08/13,Theorem 3.2]](https://eprint.iacr.org/2008/013.pdf), the curve can be easily converted from one form to another. As addition and doubling of points in a Montgomery curve can be perfomed very efficiently, computations outside the circuit can be done faster using this form and sped up inside circuits by combining it with twisted Edwards form (see [here](http://hyperelliptic.org/EFD/g1p/index.html)) for more details).

**Generation of the curve**

Baby Jubjub was conceived as a solution to the circuit implementation of cryptographic schemes that require elliptic curves. As with any cryptographic protocol, it is important to reduce the possibility of a backdoor being present. As a result, we designed the generation process to be **transparent** and **deterministic** -- in order to make it clear that no external considerations were taken into account, and to ensure that the process can be reproduced and followed by anyone who wishes to do so.

The algorithm chosen for generating Baby Jubjub is based in the criteria defined in [[RFC7748, Appendix A.1]](https://tools.ietf.org/html/rfc7748) and can be found in [this github repository](https://github.com/barryWhiteHat/baby_jubjub). Essentially, the algorithm takes a prime number `p = 1 mod 4` and returns the lowest `A>0` such that `A-2` is a multiple of 4 and such that the set of solutions in `F_p` of `y^2 = x^3 + Ax^2 + x` defines a Montgomery curve with cofactor 8.

Baby Jubjub was generated by running the algorithm with the prime

`r = 21888242871839275222246405745257275088548364400416034343698204186575808495617`,

which is the order of alt_bn128, the curve used to verfiy zk-SNARK proofs in Ethereum. The output of the algorithm was `A=168698`. Afterwards, the corresponding Montgomery curve was transformed into twisted Edwards form. Using SAGE libraries for curves, the order `n` of the curve and its factorization `n = 8*l` was calculated.

- **Choice of generator** : the generator point `G` is the point of order `n` with smallest positive `x`-coordinate in `F_r`.
- **Choice of base point**: the base point `B` is chosen to be `B = 8*G`, which has order `l`.

**Security considerations**

It is crucial that Baby Jubjub be safe against well-known attacks. To that end, we decided that the curve should pass [SafeCurves](https://safecurves.cr.yp.to/) security tests, as they are known for gathering the best known attacks against elliptic curves. Supporting evidence that Baby Jubjub satisfies the SafeCurves criteria can be found [here](https://github.com/barryWhiteHat/baby_jubjub).


# Backwards Compatibility
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->

Baby Jubjub is a twisted Edwards elliptic curve birational to different curves. So far, the curve has mainly been used in its original form, in Montomgery form. and in another (different representation) twisted Edwards form -- which we call the reduced twisted Edwards form.

Below are the three representations and the birational maps that make it possible to map points from one form of the curve to another. In all cases, the generator and base points are written in the form **`(x,y)`.**

## Forms of the curve
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved

All generators and base points are written in the form (x,y).

**Twisted Edwards form** (standard)

- Equation: ``ax^2 + y^2 = 1 + dx^2y^2``
- Parameters: ``a = 168700, d = 168696``
- Generator point:
```
(995203441582195749578291179787384436505546430278305826713579947235728471134, 5472060717959818805561601436314318772137091100104008585924551046643952123905)
```
- Base point:
```
(5299619240641551281634865583518297030282874472190772894086521144482721001553, 16950150798460657717958625567821834550301663161624707787222815936182638968203)
```

**Montgomery form**

- Equation: ``By^2 = x^3 + A x^2 + x``
- Parameters: ``A = 168698, B = 1``
- Generator point:
```
(7, 4258727773875940690362607550498304598101071202821725296872974770776423442226)
```
- Base point:
```
(7117928050407583618111176421555214756675765419608405867398403713213306743542, 14577268218881899420966779687690205425227431577728659819975198491127179315626)
```

**Reduced twisted Edwards form**

- Equation: ``a' x^2 + y^2 = 1 + d' x^2y^2``
- Parameters:
```
a' = -1
d' = 12181644023421730124874158521699555681764249180949974110617291017600649128846
```
- Generator point:
```
(4986949742063700372957640167352107234059678269330781000560194578601267663727, 5472060717959818805561601436314318772137091100104008585924551046643952123905)
```
- Base point:
```
(9671717474070082183213120605117400219616337014328744928644933853176787189663, 16950150798460657717958625567821834550301663161624707787222815936182638968203)
```

## Conversion of points
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved

Following formulas allow to convert points from one form of the curve to another. We will denote the coordinates

* ``(u, v)`` for points in the Montomgery form,
* ``(x, y)`` for points in the Twisted Edwards form and
* ``(x', y')`` for points in reduced Twisted Edwards form.

Note that in the last conversion -- from Twisted Edwards to Reduced Twisted Edwards and back -- we also use the scaling factor `f`, where:
```
f = 6360561867910373094066688120553762416144456282423235903351243436111059670888
```
In the expressions one can also use direcly `-f`, where:
```
-f = 15527681003928902128179717624703512672403908117992798440346960750464748824729
```

**Montgomery --> Twisted Edwards**
```
(u, v) --> (x, y)

x = u/v
y = (u-1)/(u+1)
```

**Twisted Edwards --> Montgomery**
```
(x, y) --> (u, v)

u = (1+y)/(1-y)
v = (1+y)/((1-y)x)
```

**Montgomery --> Reduced Twisted Edwards**
```
(u, v) --> (x', y')

x' = u*(-f)/v
y' = (u-1)/(u+1)
```

**Reduced Twisted Edwards --> Montgomery**
```
(x', y') --> (u, v)

u = (1+y')/(1-y')
v = (-f)*(1+y')/((1-y')*x')
```

**Twisted Edwards --> Reduced Twisted Edwards**
```
(x, y) --> (x', y')

x' = x*(-f)
y' = y
```

**Reduced Twisted Edwards --> Twisted Edwards**
```
(x', y') --> (x, y)

x = x'/(-f)
y = y'
```

# Test Cases
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->

**Test 1 (Addition)**

Consider the points ``P1 = (x1, y1)`` and ``P2 = (x2, y2)`` with the following coordinates:
```
x1 = 17777552123799933955779906779655732241715742912184938656739573121738514868268
y1 = 2626589144620713026669568689430873010625803728049924121243784502389097019475

x2 = 16540640123574156134436876038791482806971768689494387082833631921987005038935
y2 = 20819045374670962167435360035096875258406992893633759881276124905556507972311
```
Then their sum `` P1+P2 = (x3, y3)`` is equal to:
```
x3 = 7916061937171219682591368294088513039687205273691143098332585753343424131937
y3 = 14035240266687799601661095864649209771790948434046947201833777492504781204499
```

**Test 2 (Doubling)**

Consider the points ``P1 = (x1, y1)`` and ``P2 = (x2, y2)`` with the following coordinates:
```
x1 = 17777552123799933955779906779655732241715742912184938656739573121738514868268,
y1 = 2626589144620713026669568689430873010625803728049924121243784502389097019475

x2 = 17777552123799933955779906779655732241715742912184938656739573121738514868268
y2 = 2626589144620713026669568689430873010625803728049924121243784502389097019475
```
Then their sum `` P1+P2 = (x3, y3)`` is equal to:
```
x3 = 6890855772600357754907169075114257697580319025794532037257385534741338397365
y3 = 4338620300185947561074059802482547481416142213883829469920100239455078257889
```

**Test 3 (Doubling the identity)**

Consider the points ``P1 = (x1, y1)`` and ``P2 = (x2, y2)`` with the following coordinates:
```
x1 = 0
y1 = 1

x2 = 0
y2 = 1
```
Then their sum `` P1+P2 = (x3, y3)`` results in the same point:
```
x3 = 0
y3 = 1
```

**Test 4 (Curve membership)**

Point ``(0,1)`` is a point on Baby Jubjub.

Point ``(1,0)`` is not a point on Baby Jubjub.

**Test 5 (Base point choice)**

Check that the base point `` B = (Bx, By)`` with coordinates

```
Bx = 5299619240641551281634865583518297030282874472190772894086521144482721001553
By = 16950150798460657717958625567821834550301663161624707787222815936182638968203
```
is 8 times the generator point ``G = (Gx, Gy)``, where
```
Gx = 995203441582195749578291179787384436505546430278305826713579947235728471134
Gy = 5472060717959818805561601436314318772137091100104008585924551046643952123905
```
That is, check that ``B = 8 x G``.

**Test 6 (Base point order)**

Check that the base point `` B = (Bx, By)`` with coordinates

```
Bx = 5299619240641551281634865583518297030282874472190772894086521144482721001553
By = 16950150798460657717958625567821834550301663161624707787222815936182638968203
```
multiplied by `l`, where
```
l = 2736030358979909402780800718157159386076813972158567259200215660948447373041
```
results in the origin point `O = (0, 1)`. This test checks that the base point `B` has order `l`.

# Implementation
bellesmarta marked this conversation as resolved.
Show resolved Hide resolved
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->

Arithmetic of Baby Jubjub and some cryptographic primitives using the curve have already been implemented in different languages. Here are a few such implementations:

- Python: https://github.com/barryWhiteHat/baby_jubjub_ecc
- JavaScript: https://github.com/iden3/circomlib/blob/master/src/babyjub.js
- Circuit (circom): https://github.com/iden3/circomlib/blob/master/circuits/babyjub.circom
- Rust: https://github.com/arnaucube/babyjubjub-rs
- Solidity: https://github.com/yondonfu/sol-baby-jubjub

# Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).