diff --git a/EIPS/eip-1962.md b/EIPS/eip-1962.md index 93a6937c8af9a..3ef97b10f9c8c 100644 --- a/EIPS/eip-1962.md +++ b/EIPS/eip-1962.md @@ -25,8 +25,7 @@ This EIP proposes a new precompile to bring cryptographic functionality desired - Implementation pairing operation over elliptic curves from the following "families" with parameters such as base field, extension tower structure, coefficients defined in runtime: - BLS12 - BN - - MNT4/6 -- Implementation pairing operation over elliptic curves found by Cocks-Pinch method. Limit k <= 8. + - MNT4/6 (Ate pairing) Full functionality of the precompile is described below in `Specification` section. @@ -46,106 +45,20 @@ Functionality of this newly proposed precompile is different from [EIP1829](http ## Specification -If `block.number >= XXXXX`, define a new precompile with an address `0x..` and the following functionality. - -This specification will not yet provide concrete numbers for every operation, but will first introduce interfaces and gas calculation approaches. +If `block.number >= XXXXX`, define a set of `10` new precompiles with an addresses `[0x.., 0x.., ...]` and the following functionality. -In every call to the precompile the first byte specifies an operation that should be performed: -- `0x01`: Point addition -- `0x02`: Single point multiplication -- `0x03`: Multiexponentiation -- `0x04`: Pairing +- Addition of points on the curve defined over base field +- Multiplication of a point on the curve defined over base field +- Multiexponentiation for `N` pairs of `(scalar, point)` on the curve defined over base field +- Addition of points on the curve defined over quadratic or cubic extension of the base field +- Multiplication of a point on the curve defined over quadratic or cubic extension of the base field +- Multiexponentiation for `N` pairs of `(scalar, point)` on the curve defined over quadratic or cubic extension of the base field +- Pairing operation on the curve of `BLS12` family +- Pairing operation on the curve of `BN` family +- Pairing operation on the curve of `MNT4` family +- Pairing operation on the curve of `MNT6` family -For parameter encoding there is no dense bit packing. All the parameters (sizes, scalars, field elements, etc.) are Big Endian (BE) encoded unsigned integers. - -Points are always encoded in affine coordinates as `(x, y)`. Extension field elements are always encoded as `(c0, c1, c2, ...)` where the element itself is interpreted as `c0 + c1 * u + c2 * u^2 + ...`. - -During the execution all the parameters that should be interpreted as "points" are first checked that those are "on curve", otherwise error is thrown. - -Maximum proposed field bit size is 1023 bits. - -### Binary interface for non-pairing operations - -Every operation of such kind should specify curve parameters right after the "operation" byte: -- 1 byte that encodes byte size of the modulus for a base field. Will be referred as "field element length". -- BE encoded modulus. Field modulo this parameter is referred as the "base field". -- BE encoded parameter `A` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. -- BE encoded parameter `B` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. -- 1 byte that encodes byte size of the main group on the curve (over which arithmetic should happen). Will be referred as "scalar element length". -- BE encoded size of the main group. Will be referred as "scalar field size". - -While "scalar field size" is not used anywhere in principal operations (point additions, multiplications, multiexponentiations) do not depend on it, this parameter is required to calculate a gas cost for this operation (that's not true for point addition, but interface should be kept universal). E.g. for a naive "double and add" point multiplication approach the worst case scenario is when "add" operation is performed as many times a possible, it can be estimated as if the scalar had the same bit length as a size of the main group, but consisted of only `1` in it's bit decomposition. - -#### Point addition - -After the curve parameters (from above) two points must be specified to perform an addition. Output is a point in affine coordinates. - -#### Point multiplication - -After the curve parameters (from above) one point and one scalar must be specified to perform a multiplication. Output is a point in affine coordinates. Scalar must be less than the size of the group, otherwise error is thrown. - -#### Multiexponentiation - -After the curve parameters (from above) a list of `N` pairs `(point, scalar)` must be specified to perform a multiexponentiation. Output is a point in affine coordinates. Scalars must be less than the size of the group, otherwise error is thrown. For efficiency reasons this operations should use Peppinger algorithm with huge performance benefits. - -#### Gas calculation for non-pairing operations - -For all the operations above arithmetic is performed in a field specified by modulus. Number of operations for point addition is known beforehand, so the bit length (or byte length, more likely) of the modulus clearly must be one of the parameters. Second parameter is length of the bit (or byte) length of the scalar field. Third parameter is number of `(point, scalar)` pairs for multiexponentiation. - -Let's denote field element byte length as `fe_length`, -scalar length as `scalar_length` and number of points as `N`. Concrete coefficients that are to be determined will be labeled as `C_*`. Notation `quadratic` is to indicate a function that is quadratic over it's parameter. - -Quadratic dependency over field element byte length is due to multiplication. - -Proposed formulas: -- Point addition: `C_0*quadratic(fe_length)` -- Point multiplication: `C_1 * quadratic(fe_length) * scalar_length` -- Multiexponentiation: `C_2 * N * quadratic(fe_length) * scalar_length` - -Multiexponentiation formula is different due to use of the specialized algorithm. - -### Binary interface for pairing operations - -Pairing operations have other parameters required to estimate gas costs, so common part of the interface is different from non-pairing operations - -- 1 byte that encodes byte size of the modulus for a base field. Will be referred as "field element length". -- BE encoded modulus. Field modulo this parameter is referred as the "base field". -- BE encoded parameter `A` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. -- BE encoded parameter `B` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. -- 1 byte that encodes curve "family" - - `0x01` BLS12 - - `0x02` BN - - `0x03` MNT4 - - `0x04` MNT6 - - `0x05` Cocks-Pinch (Tate pairing) - -Parameters for a pairing are encoded as a list of `N` pairs `(p1, p2)` with `p1` being point from `G1` (curve over base field) in affine coordinates, and `p2` being point from `G2` (over the extension). - -Pairing operation consists of two major contributors: -- Miller loop. This part does depend from the number of pairs `N` and has number of steps that is specific for every curve family. For example, BLS12 family is generated by a single scalar `x` (standard notation) that determines number of steps in this loop. Any such parameters must be provided in the binary interface for gas costs estimation. -- Final exponentiation. This part does not depend from the number of pairs. Length of the loop for this operation is different for different families and can either be calculated in from other parameters or specified in the interface. In any case, gas costs can be estimated upfront. - -Below there will be proposed interface for BLS12 family of curves with other interfaces being built in a similar manner. - -#### BLS12 family pairing operation interface - -- 1 byte, length of the `x` parameter. -- BE encoding of parameter `x` (unsigned). -- 1 byte, sign of parameter `x`. `0x00` is `+`, `0x01` is `-`. -- 1 byte, specifies type of the pairing. Either `0x01` or `0x02`. This type depends of the curve and does not affect the gas cost. -- structure of the extension tower: - - non-residue for Fp2 extension in BE encoding. This is just a single element in the base field and must be less than modulus. - - non-residue for Fp6 extension (that is "3 over 2"). This is an element in Fp2 and encoded using the rules from the beginning of this EIP. -- Encoding of the "A" parameter in Fp2 for the curve over the extension (Fp2). -- Encoding of the "B" parameter in Fp2 for the curve over the extension (Fp2). - -For BLS12 family `x` parameter is enough for gas costs estimation. It's Hamming weight and bit length determines complexity of the Miller loop. Final exponentiation depends of the base field size. - -Proposed gas cost formula: `C_0 * quadratic(fe_length) + N * C_1 * fe_length * Hamming_and_bit_length(x)` - -#### Pairing operation interface for other families - -Complexity for BN family is also determined by the single scalar parameter, so interface will be similar to BLS12. For MNT4/6 and Cocks-Pinch curves there would be required to specify number of steps in the Miller loop explicitly in the interface. +Due to actuve development of the precompile and a lot of ongoing changes there is a single [source of truth](https://github.com/matter-labs/eip1962/tree/master/documentation). It covers binary interface, gas schedule, integration guide for existing implementations. ### Possible simplifications @@ -164,7 +77,6 @@ In the case of limited set of curve the following set is proposed as a minimal: Only the largest design decisions will be covered: - While there is no arithmetic over the scalar field (which is modulo size of the main group) of the curve, it's required for gas estimation purposes. -- One may separate interfaces for additions, multiplications and multiexponentiations and estimate gas costs differently for every operation, but it would bring confusion for users and will make it harder to use a precompile from the smart-contract. - Multiexponentiation is a separate operation due to large cost saving - There are no point decompressions due to impossibility to get universal gas estimation of square root operation. For a limited number of "good" cases prices would be too different, so specifying the "worst case" is expensive and inefficient, while introduction of another level if complexity into already complicated gas costs formula is not worth is.