Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 #196
EIP: Title: Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 Author: Christian Reitwiessner Type: Standard Track Category(*only required for Standard Track): Core Status: Draft Created: 2017-02-02
Precompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit.
This EIP suggests to add precompiled contracts for addition and scalar multiplication on a specific pairing-friendly elliptic curve. This can in turn be combined with #197 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).
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
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.
Add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "alt_bn128".
Address of ADD: 0x6
The curve is defined by:
Field elements are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements
For both precompiled contracts, if the input is shorter than expected, it is padded with zeros at the end.
The length of the returned data is always as specified (i.e. it is not "unpadded").
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
MUL: Input: curve point and scalar
To be determined.
The specific curve
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.
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).
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.
To be written.
Implementation of these primitives are available here:
In both codebases, a specific group on the curve alt_bn128 is used and is called G1.
License: Apache 2.0