From 7eb99d236dfff497794b2f5b94e32c8928e4dbfc Mon Sep 17 00:00:00 2001 From: chriseth Date: Mon, 13 Feb 2017 14:34:52 +0100 Subject: [PATCH 01/20] Precompiled contract for pairing check. --- EIPS/pairings.md | 130 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 EIPS/pairings.md diff --git a/EIPS/pairings.md b/EIPS/pairings.md new file mode 100644 index 00000000000000..4b85c06a7f9872 --- /dev/null +++ b/EIPS/pairings.md @@ -0,0 +1,130 @@ +## Preamble +
+  EIP: to be assigned
+  Title: Precompiled contracts for optimal ate pairing check
+         on the elliptic curve alt_bn128
+  Author: Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>
+  Type: Standard Track
+  Category(*only required for Standard Track): Core
+  Status: Draft
+  Created: 2017-02-06
+
+ +## Simple Summary + +Precompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit. + +## Abstract + +This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with https://github.com/ethereum/EIPs/issues/196 to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property). + +## Motivation + +Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive +to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced. + +Note that fixing these parameters will in no way limit the use-cases for zkSNARKs, it will even allow for incorporating some advances in zkSNARK research without the need for a further hard fork. + +Pairing functions can be used to perform a limited form of multiplicatively homomorphic operations, which are necessary for current zkSNARKs. This precompile can be used to run such computations within the block gas limit. This precompiled contract only specifies a certain check, and not an evaluation of a pairing function. The reason is that the codomain of a pairing function is a rather complex field which could provide encoding problems and all known uses of pairing function in zkSNARKs only require the specified check. + +## Specification + +Add a precompiled contracts for a bilinear function on groups on the elliptic curve "alt_bn128". We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below. + +Address: 0x8 + +For a cyclic group `G` (written additively) of prime order q let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the integer `n` such that `n * P = x`. + +The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` and their generators `P_1` and `P_2` are defined below: + +``` +Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k +Output: If the length of the input is incorrect or any of the inputs are not elements of + the respective group or are not encoded correctly, the call fails. + Otherwise, return one if + log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 + and zero else. +``` + +### Definition of the groups + +The groups `G_1` and `G_1` are cyclic groups on the elliptic curve `alt_bn128` defined by the curve equation +`Y^2 = X^3 + 3`. + +The group `G_1` is a cyclic group of prime order on the above curve over the field `F_p` with `p = 21888242871839275222246405745257275088696311157297823662689037894645226208583` with generator `P1 = (1, 2)`. + +The group `G_2` is a cyclic group of prime order in the same elliptic curve over a different field `F_p^2 = F_p[X] / (X^2 + 1)` (p is the same as above) with generator +``` +P2 = ( + 11559732032986387107991004021392285783925812861821192530917403151452391805634 * i + + 10857046999023057135944570762232829481370756359578518086990519993285655852781, + 4082367875863433681332203403145435568316851327593401208105741076214120093531 * i + + 8495653923123431417604973247489272438418190587263600148770280649306958101930 +) +``` + + +### Encoding + +Elements of `F_p` are encoded as 32 byte big-endian numbers. An encoding value of `p` or larger is invalid. + +Elements `a * i + b` of `F_p^2` are encoded as two elements of `F_p`, `(a, b)`. + +Elliptic curve points are encoded as a Jacobian pair `(X, Y)` where the point at infinity is encoded as `(0, 0)`. + +Note that the number `k` is derived from the input length. + +The length of the returned data is always exactly 32 bytes and encoded as a 32 byte big-endian number. + +### Gas costs + +To be determined. + +## Rationale + +The specific curve `alt_bn128` was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts. + +The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification: The gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve or does not admit an efficient pairing implementation. + +A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate). + +The encoding of field elements in `F_p^2` was chosen in this order to be in line with the big endian encoding of the elements themselves. + +## Backwards Compatibility + +As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256. + +## Test Cases + +To be written. + +## Implementation + +The precompiled contract can be implemented using elliptic curve pairing functions, more specifically, an optimal ate pairing on the alt_bn128 curve, which can be implemented efficiently. In order to see that, first note that a pairing function `e: G_1 x G_2 -> G_T` fulfills the following properties (`G_1` and `G_2` are written additively, `G_T` is written multiplicatively): + +(1) `e(m * P1, n * P2) = e(P1, P2)^(m * n)` +(2) `e` is non-degenerate + +Now observe that +``` +log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 +``` +if and only if +``` +e(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = e(P1, P2) +``` + +Furthermore, the left hand side of this equation is equal to +``` +e(log_P1(a1) * P1, log_P2(b1) * P2) * ... * e(log_P1(ak) * P1, log_P2(bk) * P2) += e(a1, b1) * ... * e(ak, bk) +``` + +And thus, the precompiled contract can be implemented by verifying that +`e(a1, b1) * ... * e(ak, bk) = e(P1, P2)` + +Implementations are available here: + + - [libsnark](https://github.com/scipr-lab/libsnark/blob/master/src/algebra/curves/alt_bn128/alt_bn128_g1.hpp) (C++) + - [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust) + - [Python](https://github.com/ethereum/research/blob/master/zksnark/bn128_pairing.py) \ No newline at end of file From 110f140cb8a7d589089ff08a242e2c56901f70af Mon Sep 17 00:00:00 2001 From: chriseth Date: Tue, 14 Feb 2017 16:50:23 +0100 Subject: [PATCH 02/20] Typos and clarification. --- EIPS/pairings.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index 4b85c06a7f9872..af9dd05c20243d 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -35,7 +35,7 @@ Address: 0x8 For a cyclic group `G` (written additively) of prime order q let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the integer `n` such that `n * P = x`. -The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` and their generators `P_1` and `P_2` are defined below: +The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` and their generators `P_1` and `P_2` are defined below (they have the same order `q`): ``` Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k @@ -43,17 +43,17 @@ Output: If the length of the input is incorrect or any of the inputs are not ele the respective group or are not encoded correctly, the call fails. Otherwise, return one if log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 - and zero else. + (in F_q) and zero else. ``` ### Definition of the groups -The groups `G_1` and `G_1` are cyclic groups on the elliptic curve `alt_bn128` defined by the curve equation +The groups `G_1` and `G_2` are cyclic groups of prime order `q` on the elliptic curve `alt_bn128` defined by the curve equation `Y^2 = X^3 + 3`. -The group `G_1` is a cyclic group of prime order on the above curve over the field `F_p` with `p = 21888242871839275222246405745257275088696311157297823662689037894645226208583` with generator `P1 = (1, 2)`. +The group `G_1` is a cyclic group on the above curve over the field `F_p` with `p = 21888242871839275222246405745257275088696311157297823662689037894645226208583` with generator `P1 = (1, 2)`. -The group `G_2` is a cyclic group of prime order in the same elliptic curve over a different field `F_p^2 = F_p[X] / (X^2 + 1)` (p is the same as above) with generator +The group `G_2` is a cyclic group on the same elliptic curve over a different field `F_p^2 = F_p[X] / (X^2 + 1)` (p is the same as above) with generator ``` P2 = ( 11559732032986387107991004021392285783925812861821192530917403151452391805634 * i + @@ -127,4 +127,4 @@ Implementations are available here: - [libsnark](https://github.com/scipr-lab/libsnark/blob/master/src/algebra/curves/alt_bn128/alt_bn128_g1.hpp) (C++) - [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust) - - [Python](https://github.com/ethereum/research/blob/master/zksnark/bn128_pairing.py) \ No newline at end of file + - [Python](https://github.com/ethereum/research/blob/master/zksnark/bn128_pairing.py) From a4aa9806519ea24fc9b1ac2d04ba339fff7946ee Mon Sep 17 00:00:00 2001 From: chriseth Date: Tue, 14 Feb 2017 16:52:24 +0100 Subject: [PATCH 03/20] Replace X by i. --- EIPS/pairings.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index af9dd05c20243d..aa5f4541107a7f 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -53,7 +53,7 @@ The groups `G_1` and `G_2` are cyclic groups of prime order `q` on the elliptic The group `G_1` is a cyclic group on the above curve over the field `F_p` with `p = 21888242871839275222246405745257275088696311157297823662689037894645226208583` with generator `P1 = (1, 2)`. -The group `G_2` is a cyclic group on the same elliptic curve over a different field `F_p^2 = F_p[X] / (X^2 + 1)` (p is the same as above) with generator +The group `G_2` is a cyclic group on the same elliptic curve over a different field `F_p^2 = F_p[i] / (i^2 + 1)` (p is the same as above) with generator ``` P2 = ( 11559732032986387107991004021392285783925812861821192530917403151452391805634 * i + From 9ce36b3b65360515d29938cc3047f03fdf3a01b0 Mon Sep 17 00:00:00 2001 From: chriseth Date: Tue, 14 Feb 2017 17:06:41 +0100 Subject: [PATCH 04/20] Clarify k == 0 --- EIPS/pairings.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index aa5f4541107a7f..302ee245b5b0e1 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -5,7 +5,7 @@ on the elliptic curve alt_bn128 Author: Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org> Type: Standard Track - Category(*only required for Standard Track): Core + Category: Core Status: Draft Created: 2017-02-06 @@ -46,6 +46,8 @@ Output: If the length of the input is incorrect or any of the inputs are not ele (in F_q) and zero else. ``` +Note that k is determined from the length of the input. k == 0 is valid and results in returning one. + ### Definition of the groups The groups `G_1` and `G_2` are cyclic groups of prime order `q` on the elliptic curve `alt_bn128` defined by the curve equation From cf9f0e4133712e7c91a1312e87e1c5b3f01f638a Mon Sep 17 00:00:00 2001 From: chriseth Date: Tue, 14 Feb 2017 18:00:22 +0100 Subject: [PATCH 05/20] Updated preamble. --- EIPS/pairings.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index 302ee245b5b0e1..9f8941168082c1 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -1,14 +1,13 @@ ## Preamble -
-  EIP: to be assigned
-  Title: Precompiled contracts for optimal ate pairing check
-         on the elliptic curve alt_bn128
-  Author: Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>
-  Type: Standard Track
-  Category: Core
-  Status: Draft
-  Created: 2017-02-06
-
+ + EIP: to be assigned + Title: Precompiled contracts for optimal ate pairing check + on the elliptic curve alt_bn128 + Author: Vitalik Buterin , Christian Reitwiessner + Type: Standard Track + Category: Core + Status: Draft + Created: 2017-02-06 ## Simple Summary From ffcee11782d0fd1830eea9a73d7bcf9b949943f0 Mon Sep 17 00:00:00 2001 From: chriseth Date: Thu, 18 May 2017 16:02:15 +0200 Subject: [PATCH 06/20] Clarifications and first gas cost suggestion. --- EIPS/pairings.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index 9f8941168082c1..509a86e9c5ce2d 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -45,11 +45,13 @@ Output: If the length of the input is incorrect or any of the inputs are not ele (in F_q) and zero else. ``` -Note that k is determined from the length of the input. k == 0 is valid and results in returning one. +Note that `k` is determined from the length of the input. `k == 0` is valid and results in returning one. + +In order to check that an input is an element of `G_1`, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For `G_2`, in addition to that, the order of the element has to be checked to be equal to the group order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617`. ### Definition of the groups -The groups `G_1` and `G_2` are cyclic groups of prime order `q` on the elliptic curve `alt_bn128` defined by the curve equation +The groups `G_1` and `G_2` are cyclic groups of prime order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617` on the elliptic curve `alt_bn128` defined by the curve equation `Y^2 = X^3 + 3`. The group `G_1` is a cyclic group on the above curve over the field `F_p` with `p = 21888242871839275222246405745257275088696311157297823662689037894645226208583` with generator `P1 = (1, 2)`. @@ -79,7 +81,15 @@ The length of the returned data is always exactly 32 bytes and encoded as a 32 b ### Gas costs -To be determined. +[Benchmarks run on cpp-ethereum](https://gist.github.com/chriseth/4168b56bfe638cae8da1945dd988600b) + +suggest the following gas formula: + +`60000 * k + 40000` + +if we target 20000 gas per millisecond. + +Awaiting benchmarks from other implementations. ## Rationale From 4049242c044c9566c1cff635614aec67f81a2890 Mon Sep 17 00:00:00 2001 From: chriseth Date: Mon, 24 Jul 2017 11:30:22 +0200 Subject: [PATCH 07/20] Updated the specification Note that this is an actual change in the specification, especially in the case of empty input. Thanks to @bbuenz for pointing this out! --- EIPS/pairings.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index 509a86e9c5ce2d..b44eee22be5857 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -32,7 +32,7 @@ Add a precompiled contracts for a bilinear function on groups on the elliptic cu Address: 0x8 -For a cyclic group `G` (written additively) of prime order q let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the integer `n` such that `n * P = x`. +For a cyclic group `G` (written additively) of prime order q let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the smallest non-negative integer `n` such that `n * P = x`. The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` and their generators `P_1` and `P_2` are defined below (they have the same order `q`): @@ -41,11 +41,13 @@ Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k Output: If the length of the input is incorrect or any of the inputs are not elements of the respective group or are not encoded correctly, the call fails. Otherwise, return one if - log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 + log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 1 (in F_q) and zero else. ``` -Note that `k` is determined from the length of the input. `k == 0` is valid and results in returning one. +Note that `k` is determined from the length of the input. Following the section on the encoding below, +`k` is the length of the input divided by `192`. If the input length is not a multiple of `192`, +the call fails. Empty input is valid and results in returning zero. In order to check that an input is an element of `G_1`, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For `G_2`, in addition to that, the order of the element has to be checked to be equal to the group order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617`. @@ -118,7 +120,7 @@ The precompiled contract can be implemented using elliptic curve pairing functio Now observe that ``` -log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 +log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 1 ``` if and only if ``` From 470c61bed3b94d67815557aca224641742badb56 Mon Sep 17 00:00:00 2001 From: chriseth Date: Tue, 25 Jul 2017 15:03:17 +0200 Subject: [PATCH 08/20] Correct equality check and clarify group order. --- EIPS/pairings.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index b44eee22be5857..276342300f0d1b 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -32,22 +32,22 @@ Add a precompiled contracts for a bilinear function on groups on the elliptic cu Address: 0x8 -For a cyclic group `G` (written additively) of prime order q let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the smallest non-negative integer `n` such that `n * P = x`. +For a cyclic group `G` (written additively) of prime order `q` let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the smallest non-negative integer `n` such that `n * P = x`. -The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` and their generators `P_1` and `P_2` are defined below (they have the same order `q`): +The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` and their generators `P_1` and `P_2` are defined below. Both generators have the same prime order `q` and the actual choice of the generators does not matter, as long as they have order `q`. ``` Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k Output: If the length of the input is incorrect or any of the inputs are not elements of the respective group or are not encoded correctly, the call fails. Otherwise, return one if - log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 1 + log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q) and zero else. ``` Note that `k` is determined from the length of the input. Following the section on the encoding below, `k` is the length of the input divided by `192`. If the input length is not a multiple of `192`, -the call fails. Empty input is valid and results in returning zero. +the call fails. Empty input is valid and results in returning one. In order to check that an input is an element of `G_1`, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For `G_2`, in addition to that, the order of the element has to be checked to be equal to the group order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617`. @@ -68,6 +68,8 @@ P2 = ( ) ``` +Note that `G_2` is the only group of order `q` of that elliptic curve over the field `F_p^2`. + ### Encoding @@ -120,11 +122,11 @@ The precompiled contract can be implemented using elliptic curve pairing functio Now observe that ``` -log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 1 +log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q) ``` if and only if ``` -e(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = e(P1, P2) +e(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = 1 (in G_T) ``` Furthermore, the left hand side of this equation is equal to @@ -134,7 +136,7 @@ e(log_P1(a1) * P1, log_P2(b1) * P2) * ... * e(log_P1(ak) * P1, log_P2(bk) * P2) ``` And thus, the precompiled contract can be implemented by verifying that -`e(a1, b1) * ... * e(ak, bk) = e(P1, P2)` +`e(a1, b1) * ... * e(ak, bk) = 1` Implementations are available here: From 9961da4c77659c6217eae41130c3a40d3f526ac4 Mon Sep 17 00:00:00 2001 From: chriseth Date: Mon, 11 Sep 2017 14:35:38 +0200 Subject: [PATCH 09/20] Gas costs. --- EIPS/pairings.md | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/EIPS/pairings.md b/EIPS/pairings.md index 276342300f0d1b..793cd3e1bc7cc1 100644 --- a/EIPS/pairings.md +++ b/EIPS/pairings.md @@ -85,15 +85,8 @@ The length of the returned data is always exactly 32 bytes and encoded as a 32 b ### Gas costs -[Benchmarks run on cpp-ethereum](https://gist.github.com/chriseth/4168b56bfe638cae8da1945dd988600b) - -suggest the following gas formula: - -`60000 * k + 40000` - -if we target 20000 gas per millisecond. - -Awaiting benchmarks from other implementations. +The gas costs of the precompiled contract are `80 000 * k + 100 000`, where `k` is the number of +points or, equivalently, the length of the input divided by 192. ## Rationale From 9706f4fecc6bad77ce5de918973c4bad5c9e355e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 1 Dec 2017 13:47:06 +0100 Subject: [PATCH 10/20] Move pairings.md into eip-212.md --- EIPS/{pairings.md => eip-212.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{pairings.md => eip-212.md} (100%) diff --git a/EIPS/pairings.md b/EIPS/eip-212.md similarity index 100% rename from EIPS/pairings.md rename to EIPS/eip-212.md From daa7689ce831f10d0520ec40c1ab402e994ebde2 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 1 Dec 2017 13:51:11 +0100 Subject: [PATCH 11/20] Assign an EIP number and fix a link --- EIPS/eip-212.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-212.md b/EIPS/eip-212.md index 793cd3e1bc7cc1..692ad7bf6a38a5 100644 --- a/EIPS/eip-212.md +++ b/EIPS/eip-212.md @@ -1,6 +1,6 @@ ## Preamble - EIP: to be assigned + EIP: 212 Title: Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128 Author: Vitalik Buterin , Christian Reitwiessner @@ -15,7 +15,7 @@ Precompiled contracts for elliptic curve pairing operations are required in orde ## Abstract -This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with https://github.com/ethereum/EIPs/issues/196 to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property). +This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with [EIP-213](./eip-213.md) to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property). ## Motivation From 9b9e9c86b8aa7f5077fdcb5030f80484dcbf079e Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 1 Dec 2017 14:03:44 +0100 Subject: [PATCH 12/20] Add the starting block --- EIPS/eip-212.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-212.md b/EIPS/eip-212.md index 692ad7bf6a38a5..768b549b4eec5d 100644 --- a/EIPS/eip-212.md +++ b/EIPS/eip-212.md @@ -28,7 +28,7 @@ Pairing functions can be used to perform a limited form of multiplicatively homo ## Specification -Add a precompiled contracts for a bilinear function on groups on the elliptic curve "alt_bn128". We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below. +For blocks where `block.number >= BYZANTIUM_FORK_BLKNUM`, add a precompiled contracts for a bilinear function on groups on the elliptic curve "alt_bn128". We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below. Address: 0x8 From 2216e5afae5e021f5cb0505b2b48bac920c4d16f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 1 Dec 2017 17:59:50 +0100 Subject: [PATCH 13/20] Fix links --- EIPS/eip-212.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-212.md b/EIPS/eip-212.md index 768b549b4eec5d..ce47582cc4214e 100644 --- a/EIPS/eip-212.md +++ b/EIPS/eip-212.md @@ -133,6 +133,6 @@ And thus, the precompiled contract can be implemented by verifying that Implementations are available here: - - [libsnark](https://github.com/scipr-lab/libsnark/blob/master/src/algebra/curves/alt_bn128/alt_bn128_g1.hpp) (C++) + - [libff](https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.hpp) (C++) - [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust) - - [Python](https://github.com/ethereum/research/blob/master/zksnark/bn128_pairing.py) + - [Python](https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_pairing.py) From d67fea0a1cab737ed3ee31f3a81521ac47822566 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 1 Dec 2017 22:15:51 +0100 Subject: [PATCH 14/20] Fix EIP numbers --- EIPS/{eip-213.md => eip-196.md} | 0 EIPS/{eip-212.md => eip-197.md} | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-213.md => eip-196.md} (100%) rename EIPS/{eip-212.md => eip-197.md} (99%) diff --git a/EIPS/eip-213.md b/EIPS/eip-196.md similarity index 100% rename from EIPS/eip-213.md rename to EIPS/eip-196.md diff --git a/EIPS/eip-212.md b/EIPS/eip-197.md similarity index 99% rename from EIPS/eip-212.md rename to EIPS/eip-197.md index ce47582cc4214e..d8ea5f1d6762e4 100644 --- a/EIPS/eip-212.md +++ b/EIPS/eip-197.md @@ -15,7 +15,7 @@ Precompiled contracts for elliptic curve pairing operations are required in orde ## Abstract -This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with [EIP-213](./eip-213.md) to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property). +This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with [EIP-196](./eip-196.md) to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property). ## Motivation From a9e828bf1c95c72c5ec2f56361639e7d5cb1ebbc Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Fri, 1 Dec 2017 22:19:06 +0100 Subject: [PATCH 15/20] Also change the number in the header --- EIPS/eip-197.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-197.md b/EIPS/eip-197.md index d8ea5f1d6762e4..93f80c37badd3a 100644 --- a/EIPS/eip-197.md +++ b/EIPS/eip-197.md @@ -1,6 +1,6 @@ ## Preamble - EIP: 212 + EIP: 197 Title: Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128 Author: Vitalik Buterin , Christian Reitwiessner From a8494952b0e5143bf083b78b761f6d7c8b6d39e4 Mon Sep 17 00:00:00 2001 From: chriseth Date: Mon, 4 Dec 2017 11:13:46 +0100 Subject: [PATCH 16/20] Update eip-197.md --- EIPS/eip-197.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/EIPS/eip-197.md b/EIPS/eip-197.md index 93f80c37badd3a..d061d17faa4637 100644 --- a/EIPS/eip-197.md +++ b/EIPS/eip-197.md @@ -136,3 +136,7 @@ Implementations are available here: - [libff](https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.hpp) (C++) - [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust) - [Python](https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_pairing.py) + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 22afa8088e602802c184966da43d82a71ff2864f Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 4 Dec 2017 13:03:41 +0100 Subject: [PATCH 17/20] Update the Byzantium list --- EIPS/eip-609.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-609.md b/EIPS/eip-609.md index 4ac787814216f2..3549b17be5c5ee 100644 --- a/EIPS/eip-609.md +++ b/EIPS/eip-609.md @@ -24,7 +24,7 @@ This specifies the changes included in the hard fork named Byzantium. - EIP 100 (Change difficulty adjustment to target mean block time including uncles) - EIP 140 (REVERT instruction in the Ethereum Virtual Machine) - EIP 196 (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) - - EIP 197 (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) + - [EIP 197](./eip-197.md) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) - EIP 198 (Precompiled contract for bigint modular exponentiation) - EIP 211 (New opcodes: RETURNDATASIZE and RETURNDATACOPY) - EIP 214 (New opcode STATICCALL) From f61b4665fb36c4e4642a88dfdf5045f4055b78cf Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 4 Dec 2017 21:37:16 +0100 Subject: [PATCH 18/20] Make eip-197.md Final The EIP is already active on the main net. --- EIPS/eip-197.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-197.md b/EIPS/eip-197.md index d061d17faa4637..2197e5d81a1eca 100644 --- a/EIPS/eip-197.md +++ b/EIPS/eip-197.md @@ -6,7 +6,7 @@ Author: Vitalik Buterin , Christian Reitwiessner Type: Standard Track Category: Core - Status: Draft + Status: Final Created: 2017-02-06 ## Simple Summary From 231cba1730650a38810fca1cfcda4ef0d1dd6873 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 4 Dec 2017 21:53:01 +0100 Subject: [PATCH 19/20] Trying to explain why a generator appears --- EIPS/eip-197.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-197.md b/EIPS/eip-197.md index 2197e5d81a1eca..7e5064784bd0c4 100644 --- a/EIPS/eip-197.md +++ b/EIPS/eip-197.md @@ -34,7 +34,7 @@ Address: 0x8 For a cyclic group `G` (written additively) of prime order `q` let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the smallest non-negative integer `n` such that `n * P = x`. -The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` and their generators `P_1` and `P_2` are defined below. Both generators have the same prime order `q` and the actual choice of the generators does not matter, as long as they have order `q`. +The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` are defined by their generators `P_1` and `P_2` below. Both generators have the same prime order `q`. ``` Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k @@ -68,7 +68,7 @@ P2 = ( ) ``` -Note that `G_2` is the only group of order `q` of that elliptic curve over the field `F_p^2`. +Note that `G_2` is the only group of order `q` of that elliptic curve over the field `F_p^2`. Any other generator of order `q` instead of `P2` would define the same `G_2`. However, a skeptical reader can compare `q * P2` and `P2` to check the existence of a group of order `q` on `G_2`. ### Encoding From 1231f25e4751362c029f539f011a5048feba0f46 Mon Sep 17 00:00:00 2001 From: Yoichi Hirai Date: Mon, 4 Dec 2017 22:03:33 +0100 Subject: [PATCH 20/20] Clearer explanation why P2 appears --- EIPS/eip-197.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-197.md b/EIPS/eip-197.md index 7e5064784bd0c4..0f5534721ddd22 100644 --- a/EIPS/eip-197.md +++ b/EIPS/eip-197.md @@ -68,7 +68,7 @@ P2 = ( ) ``` -Note that `G_2` is the only group of order `q` of that elliptic curve over the field `F_p^2`. Any other generator of order `q` instead of `P2` would define the same `G_2`. However, a skeptical reader can compare `q * P2` and `P2` to check the existence of a group of order `q` on `G_2`. +Note that `G_2` is the only group of order `q` of that elliptic curve over the field `F_p^2`. Any other generator of order `q` instead of `P2` would define the same `G_2`. However, the concrete value of `P2` is useful for skeptical readers who doubt the existence of a group of order `q`. They can be instructed to compare the concrete values of `q * P2` and `P2`. ### Encoding @@ -92,7 +92,7 @@ points or, equivalently, the length of the input divided by 192. The specific curve `alt_bn128` was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts. -The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification: The gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve or does not admit an efficient pairing implementation. +The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification; the gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve or does not admit an efficient pairing implementation. A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).