Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 #213

chriseth · 2017-02-13T13:39:01Z

Precompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit.

Replaces #196

axic · 2017-02-13T15:34:14Z

EIPS/ecopts.md

+
+### Encoding
+
+Field elements are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`.


Should also mention how is a scalar encoded.

axic · 2017-02-13T15:35:31Z

EIPS/ecopts.md

+
+Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates or scalar) is equal or larger than the field modulus p, the contract fails.
+
+ADD: Input: two curve points `(x, y)`. Fail on invalid input. Otherwise, return the curve point `x + y` where `+` is point addition on the elliptic curve `alt_bn128` specified above.


Probably better to format it as:

#### ADD Input: two curve points `(x, y)`... Output: resulting curve point ...description...

pirapira · 2017-02-14T15:04:27Z

EIPS/ecopts.md

+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.


I cannot immediately grasp how fixing parameters makes it easier to incorporate advances.

Changed the wording.

pirapira · 2017-02-14T15:06:29Z

EIPS/ecopts.md

+
+### Encoding
+
+Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`.


Isn't zero already used? I guess the elements of F_p are represented by numbers in the range of [0, that prime number - 1].

Yes, but (0,0) should not satisfy the curve equation.

OK. Somehow I was thinking about (0, y)s that might satisfy the equations. Now I realize there (0, y)s are just interpreted as they are when y is not zero.

pirapira · 2017-02-14T15:08:10Z

EIPS/ecopts.md

+
+Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`.
+
+For both precompiled contracts, if the input is shorter than expected, it is padded with zeros at the end.


Is the padding bit-wise or byte-wise?

Also, does it make sense to pad a big-endian number at the end? 1 and 256 would look the same.

Changed the wording, please see if you come to the conclusion that these questions are irrelevant :-)

I was reading "if any parameter is less than 2^255, thus any parameter is shorter than expected, the caller should pad the input at the end before calling the contract". Now this interpretation is impossible.

pirapira · 2017-02-14T15:19:46Z

EIPS/ecopts.md

+Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates or scalar) is equal or larger than the field modulus p, the contract fails.
+
+#### ADD
+Input: two curve points `(x, y)`.


Does this mean the input has 128 bytes, or are field elements put in RLP or some structure?

Clarified above.

axic · 2017-02-14T16:08:04Z

EIPS/ecopts.md

@@ -0,0 +1,99 @@
+## Preamble
+<pre>


Why the <pre>?

That was part of the template.

You might be using an old template.

Scalars larger than the field characteristic are allowed because it only makes sense to restrict them to the group order, not the field characteristic and adding the group order as another magic constant here would complicated the specification.

chriseth · 2017-03-09T11:33:12Z

TODO: change semantics to throw an exception both for too short and too long input.

chfast · 2017-03-21T13:01:51Z

A comment from my perspective. @chriseth and me are in the process of "implementing" this and #212 EIPs. "Implementing" means to integrate the external library: libff which was a part of bigger libsnark just a month ago. The libff supports only Linux at the moment and nothing indicates that it is activelly developed. After the split the libff does not have tests properly integrated. It also depends on GMP what is another issue.

My personal opinion is this piece of code if to be integrated to any Ethereum client needs full code review and good set of unit tests.

I don't know why alt_bn128 curve is so special, but if we plan to stick with only this one for a long time, we can modify the code base of libff to be less generic and support only this single curve. Such fork can be joint effort of multiple teams if others are interested.

I wander what other libraries do you use. And what is used by ZCash?

chriseth · 2017-03-21T13:27:11Z

@chfast at least in the latest version, zcash uses libsnark (or some fork of it). Note that geth will use a different library, I think it might be this one here: https://github.com/golang/crypto/tree/master/bn256 and there is yet another implementation in rust: https://github.com/zcash/bn

So I think this is a C++-only discussion. We might take libff and swap out GMP for something else.

pirapira · 2017-04-13T08:30:54Z

EIPS/ecopts.md

+
+Add precompiled contracts for point addition (ADD)  and scalar multiplication (MUL) on the elliptic curve "alt_bn128".
+
+Address of ADD: 0x6


EIP 101 also uses this address.

pirapira · 2017-04-13T08:31:06Z

EIPS/ecopts.md

+Add precompiled contracts for point addition (ADD)  and scalar multiplication (MUL) on the elliptic curve "alt_bn128".
+
+Address of ADD: 0x6
+Address for MUL: 0x7


EIP 101 uses this address too.

Can we make sure the precompiled addresses are continuous in the end?

I don't think so. 0x10 and 0x20 are taken in #96 .

The available addresses seem to be 0xa and 0xb.

Would it make sense changing #96 to use continuous addresses?

axic · 2017-04-23T17:00:12Z

EIPS/ecopts.md

+ - Points not on curve (but valid otherwise).
+ - Multiply point with scalar that lies between the order of the group and the field (should succeed).
+ - Multiply point with scalar that is larger than the field order (should succeed).
+


Can someone create those tests cases and include them here?

axic · 2017-09-08T14:21:35Z

I am 100% too late to the party with this, but it could be actually useful to have the inputs ABI encoded and reside on the same address for this reason: in WASM this precompile can be implemented natively as a contract, but with the current API it would be present in two copies.

This of course assumes WASM would come to life in a reasonable timeframe, otherwise the current API is more useful from the implementation perspective.

From in-contract usage perspective having it ABI encoded would enable using them without any complicated bindings, a simple interface contract would be enough in Solidity without the need of touching assembly.

cdetrio · 2017-11-17T22:24:43Z

EIPS/eip-213.md

+ - Truncated input that results in a valid curve point.
+ - Points not on curve (but valid otherwise).
+ - Multiply point with scalar that lies between the order of the group and the field (should succeed).
+ - Multiply point with scalar that is larger than the field order (should succeed).


Multiply point with scalar that is larger than the field order (should succeed).

YES

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/ecmul_7827-6598_9935_28000_96Filler.json#L137

multiplies by scalar (2**256 - 1) 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

@cdetrio do you think a link to the test filler should be added to the EIP?

@pirapira I was intending to link the test cases. But on second thought, we don't do that for other EIPs so I guess having the links in the PR/discussion is enough.

cdetrio · 2017-11-17T22:25:18Z

EIPS/eip-213.md

+ - Both contracts should succeed on empty input.
+ - Truncated input that results in a valid curve point.
+ - Points not on curve (but valid otherwise).
+ - Multiply point with scalar that lies between the order of the group and the field (should succeed).


Multiply point with scalar that lies between the order of the group and the field (should succeed).

YES

order of the group: curve_order = 21888242871839275222246405745257275088548364400416034343698204186575808495617 (in hex: 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000001)

order of the field (same as modulus of the field): field_modulus = 21888242871839275222246405745257275088696311157297823662689037894645226208583 (in hex: 0x30644e72e131a029b85045b68181585d97816a916871ca8d3c208c16d87cfd47)

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/pointMulAdd2Filler.json#L692-L693

uses ECMUL with scalars -1 mod field_order and -2 mod field_order (0x30644e72e131a029b85045b68181585d97816a916871ca8d3c208c16d87cfd46 and 0x30644e72e131a029b85045b68181585d97816a916871ca8d3c208c16d87cfd45)

cdetrio · 2017-11-17T22:25:31Z

EIPS/eip-213.md

+ - Curve points which would be valid if the numbers were taken mod p (should fail).
+ - Both contracts should succeed on empty input.
+ - Truncated input that results in a valid curve point.
+ - Points not on curve (but valid otherwise).


Points not on curve (but valid otherwise).

YES

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/ecadd_0-3_1-2_25000_128Filler.json

(0,3) is not on curve

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/ecmul_1-3_1_28000_128Filler.json#L137

(1,3) is not on the curve

cdetrio · 2017-11-17T22:25:43Z

EIPS/eip-213.md

+
+ - Curve points which would be valid if the numbers were taken mod p (should fail).
+ - Both contracts should succeed on empty input.
+ - Truncated input that results in a valid curve point.


Truncated input that results in a valid curve point.

NO

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/pointAddTruncFiller.json

calls ECADD but only truncates at the 64th byte, i.e. after a full point. does not truncate at e.g. 96th byte (after the x coord of the 2nd point) or at bytes in the middle of a coordinate

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/ecadd_1-3_0-0_25000_80Filler.json

calls ECADD but truncates at the 80th byte of a zero point

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/ecmul_7827-6598_1456_28000_80Filler.json

truncates at the 80th byte, which is the middle of the scalar factor, not the middle of a point

Added such cases in the test google spreadsheet

cdetrio · 2017-11-17T22:25:54Z

EIPS/eip-213.md

+Inputs to test:
+
+ - Curve points which would be valid if the numbers were taken mod p (should fail).
+ - Both contracts should succeed on empty input.


both contracts should succeed on empty input

YES

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/ecadd_0-0_0-0_21000_0Filler.json#L135

calls ECADD with empty input.

https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stZeroKnowledge/ecmul_0-0_0_28000_0Filler.json

calls ECMUL with empty input

pirapira

Looks good to me.

shamatar · 2018-05-11T20:01:09Z

Hello @pirapira

As important optimizations were merged in 1.8.x and actual processor time for every operation (especially MUL) was significantly reduced, what are the plans to reduce a precompile costs?

Sincerely, Alex

pirapira · 2018-05-14T08:11:15Z

@shamatar thanks for the news. Many people would be happier with the lower gas amounts, so my suggestion is to file an EIP about the newer gas costs (if there is none yet).

Shadowfiend · 2018-05-17T20:07:24Z

I've opened #1088 to propose this, as I didn't see any other EIPs on the matter.

Precompiled contracts for elliptic curve operations.

d8992d1

chriseth mentioned this pull request Feb 13, 2017

Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 #196

Closed

axic reviewed Feb 13, 2017

View reviewed changes

pirapira mentioned this pull request Feb 13, 2017

Byzantium changes ethereum/yellowpaper#229

Closed

12 tasks

Update ecopts.md

bc6de05

pirapira reviewed Feb 14, 2017

View reviewed changes

Clarifications.

fdbf2ab

axic reviewed Feb 14, 2017

View reviewed changes

Updated preamble.

0ed49ac

chriseth mentioned this pull request Feb 22, 2017

Integrate libsnark ethereum/aleth#3587

Merged

8 tasks

pirapira mentioned this pull request Mar 3, 2017

EIP 196/197: zkSNARK verification precompiles ethereum/aleth#3619

Closed

arkpar mentioned this pull request Mar 9, 2017

Byzantium release openethereum/parity-ethereum#4833

Closed

12 tasks

pirapira reviewed Apr 13, 2017

View reviewed changes

pirapira mentioned this pull request Apr 13, 2017

[WIP] zkSNARK ethereum/yellowpaper#296

Closed

Arachnid added EIP labels Apr 14, 2017

This was referenced Apr 18, 2017

Byzantium: elliptic curve precompiled contracts ethereum/yellowpaper#297

Closed

All Core Devs Meeting #14 ethereum/pm#12

Closed

chfast mentioned this pull request Apr 21, 2017

[META] Byzantium implementation progress ethereum/aleth#4050

Closed

17 tasks

pirapira mentioned this pull request Apr 21, 2017

Precompiled contract for pairing check. #212

Merged

axic reviewed Apr 23, 2017

View reviewed changes

cdetrio mentioned this pull request Sep 8, 2017

patchy fixes for elliptic pairing precompiles paritytech/bn#3

Merged

holiman mentioned this pull request Sep 11, 2017

Precompiles for ECADD and ECMUL #102

Closed

Added gas costs.

0063de1

michwill mentioned this pull request Sep 12, 2017

Designing Ethereum smart contract for oracles nucypher/nucypher#32

Closed

axic mentioned this pull request Sep 22, 2017

Add ECADD and ECMUL precompiles for secp256k1 #603

Closed

pipermerriam mentioned this pull request Oct 20, 2017

Byzantium Fork Rules ethereum/py-evm#123

Merged

9 tasks

pirapira mentioned this pull request Oct 23, 2017

Apply Byzantium changes pirapira/eth-isabelle#459

Open

10 tasks

pirapira added 2 commits November 17, 2017 19:38

Fix links

68fa87e

Move ecopts.md to eip-213.md

e0c717c

cdetrio reviewed Nov 17, 2017

View reviewed changes

5chdn mentioned this pull request Nov 18, 2017

Move Meta Byzantium to Finalized #770

Closed

pirapira added 2 commits December 1, 2017 13:27

Fix the link format

8f686cc

Specify the block number and make the status final

a0b9771

pirapira approved these changes Dec 1, 2017

View reviewed changes

pirapira merged commit ac33ce6 into master Dec 1, 2017

pirapira deleted the ecopts branch December 1, 2017 12:44

pirapira mentioned this pull request Jan 17, 2018

Byzantium: EIP-196/197 elliptic curve precompiled contracts ethereum/yellowpaper#413

Merged

s-tikhomirov mentioned this pull request Mar 8, 2018

Research: can we implement accumulators using Ethereum crypto pre-compiles? s-tikhomirov/kyce#2

Closed

aerth mentioned this pull request Jun 5, 2018

HF7 @ 36050 aquanetwork/aquachain#24

Merged

mratsim mentioned this pull request Aug 29, 2018

Implement all precompiled contracts status-im/nimbus-eth1#122

Closed

8 tasks

dmgr mentioned this pull request Oct 23, 2018

Private transactions and private smart contract states aeternity/protocol#248

Open

holgerd77 mentioned this pull request Jun 25, 2020

SpuriousDragon HF Support ethereumjs/ethereumjs-monorepo#791

Merged

15 tasks


		### Encoding

		Field elements are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`.


		Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates or scalar) is equal or larger than the field modulus p, the contract fails.

		ADD: Input: two curve points `(x, y)`. Fail on invalid input. Otherwise, return the curve point `x + y` where `+` is point addition on the elliptic curve `alt_bn128` specified above.


		### Encoding

		Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`.


		Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`.

		For both precompiled contracts, if the input is shorter than expected, it is padded with zeros at the end.


		Add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "alt_bn128".

		Address of ADD: 0x6

Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 #213

Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 #213

Conversation

chriseth commented Feb 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pirapira Feb 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pirapira Feb 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pirapira Feb 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chriseth commented Mar 9, 2017

chfast commented Mar 21, 2017

chriseth commented Mar 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

axic commented Sep 8, 2017 • edited Loading

cdetrio Nov 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdetrio Nov 17, 2017 • edited Loading

Choose a reason for hiding this comment

cdetrio Nov 17, 2017 • edited Loading

Choose a reason for hiding this comment

cdetrio Nov 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdetrio Nov 17, 2017 • edited Loading

Choose a reason for hiding this comment

pirapira left a comment

Choose a reason for hiding this comment

shamatar commented May 11, 2018

pirapira commented May 14, 2018

Shadowfiend commented May 17, 2018

pirapira Feb 14, 2017 •

edited

Loading

pirapira Feb 14, 2017 •

edited

Loading

pirapira Feb 14, 2017 •

edited

Loading

axic commented Sep 8, 2017 •

edited

Loading

cdetrio Nov 17, 2017 •

edited

Loading

cdetrio Nov 17, 2017 •

edited

Loading

cdetrio Nov 17, 2017 •

edited

Loading

cdetrio Nov 17, 2017 •

edited

Loading

cdetrio Nov 17, 2017 •

edited

Loading