|
| 1 | +--- |
| 2 | +rskip: 516 |
| 3 | +title: Precompiled contracts for +/* on Secp256k1 |
| 4 | +description: This RSKIP introduces precompiled contracts for elliptic curve operations that are required in order to efficiently perform MuSig2 signature verifications on the Secp256k1 curve. |
| 5 | +status: Draft |
| 6 | +purpose: Usa |
| 7 | +author: SDL (@sergiodemianlerner) |
| 8 | +layer: Core |
| 9 | +complexity: 2 |
| 10 | +status: |
| 11 | +created: 2024-04-10 |
| 12 | +--- |
| 13 | +# Precompiled contracts for +/* on Secp256k1 |
| 14 | + |
| 15 | +|RSKIP | 516 | |
| 16 | +| :------------ |:-------------| |
| 17 | +|**Title** |Precompiled contracts for +/* on Secp256k1| |
| 18 | +|**Created** |10-APR-2024 | |
| 19 | +|**Author** |SDL | |
| 20 | +|**Purpose** |Usa | |
| 21 | +|**Layer** |Core | |
| 22 | +|**Complexity** |2 | |
| 23 | +|**Status** |Draft | |
| 24 | +|**discussions-to** || |
| 25 | + |
| 26 | +# Abstract |
| 27 | + |
| 28 | +This RSKIP adds precompiled contracts for addition and scalar multiplication on a specific to the Secp256k1 curve. This will reduce the gas cost and improve robustness of MuSig2 and other signature aggregation algorithms. |
| 29 | + |
| 30 | +# Motivation |
| 31 | + |
| 32 | +The Solidity language has bigint artichmetic opcodes and a modular exponentiation precompile. However, using these low level functions to build complex protocols over secp256k1 is inefficient, costly and error-prone. Cryptographic libraries should be re-used and not re-implemented because they are security-critical. Therefore, exposing well-tested cryptographic functions to Solidity is desirable. |
| 33 | +For this reason the [EIP-196](https://eips.ethereum.org/EIPS/eip-196) was created. In this RSKIP we propose to introduce precompiles for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "secp256k1". Having efficient operations on this curve is essential to enable musig2 functionality in contracts that need to coordinate the aggregatation of signatures for Bitcoin transactions. |
| 34 | + |
| 35 | + |
| 36 | + |
| 37 | + |
| 38 | +# Specification |
| 39 | + |
| 40 | +Add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "Secp256k1". |
| 41 | + |
| 42 | +Address of ADD: 0x01000016 |
| 43 | +Address for MUL: 0x01000017 |
| 44 | + |
| 45 | + |
| 46 | +## Encoding |
| 47 | + |
| 48 | +Fields are encoded in the same way as [EIP-196](https://eips.ethereum.org/EIPS/eip-196). 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)`. |
| 49 | + |
| 50 | +Tuples of objects are encoded as their concatenation. |
| 51 | + |
| 52 | +For both precompiled contracts, if the input is shorter than expected, it is assumed to be virtually padded with zeros at the end (i.e. compatible with the semantics of the `CALLDATALOAD` opcode). If the input is longer than expected, surplus bytes at the end are ignored. |
| 53 | + |
| 54 | +The length of the returned data is always as specified (i.e. it is not "unpadded"). |
| 55 | + |
| 56 | +## Exact semantics |
| 57 | + |
| 58 | +Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates) is equal or larger than the field modulus p, the contract fails. The scalar can be any number between `0` and `2**256-1`. |
| 59 | + |
| 60 | +#### ADD |
| 61 | +Input: two curve points `(x, y)`. |
| 62 | +Output: curve point `x + y`, where `+` is point addition on the elliptic curve `Secp256k1` . |
| 63 | +Fails on invalid input and consumes all gas provided. |
| 64 | + |
| 65 | +#### MUL |
| 66 | +Input: curve point and scalar `(x, s)`. |
| 67 | +Output: curve point `s * x`, where `*` is the scalar multiplication on the elliptic curve `Secp256k1`. |
| 68 | +Fails on invalid input and consumes all gas. |
| 69 | + |
| 70 | +### Gas costs |
| 71 | + |
| 72 | +ECADD gas costs is set according to [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108). |
| 73 | +ECMUL gas cost is set to be equal to `ECRECOVER`, as `ECRECOVER` already performs a scalar multiplication in the same curve. |
| 74 | + |
| 75 | + - Gas cost for ``ECADD``: 150 |
| 76 | + - Gas cost for ``ECMUL``: 3000 |
| 77 | + |
| 78 | +# Rationale |
| 79 | + |
| 80 | + The Rootstock client already links to a the libsecp256k1 library to provide the ECRECOVER operation, so extending the node to provide ECADD and ECMUL on this currve does not require linking with additional external libraries. Also the these operations are provided by the BouncyCastle library, which can be used as a reference implementation. |
| 81 | + |
| 82 | +The specific curve `secp256k1` was chosen because it is the curve used by Bitcoin for Schnorr and ECDSA signatures. |
| 83 | + |
| 84 | +The representation of elliptic curve points was chosen to be compatible with [EIP-196](https://eips.ethereum.org/EIPS/eip-196). |
| 85 | + |
| 86 | + |
| 87 | +# Backwards Compatibility |
| 88 | + |
| 89 | +As with the introduction of any precompiled contract, this is can only be accomplished with a hard-fork. The addresses were chosen to lie within the range reserved to Rootstock-only precompiles. |
| 90 | + |
| 91 | +## Test Cases |
| 92 | + |
| 93 | +Inputs to test: |
| 94 | + |
| 95 | + - Curve points which would be valid if the numbers were taken mod p (should fail). |
| 96 | + - Both contracts should succeed on empty input. |
| 97 | + - Truncated input that results in a valid curve point. |
| 98 | + - Points not on curve (but valid otherwise). |
| 99 | + - Multiply point with scalar that lies between the order of the group and the field (should succeed). |
| 100 | + - Multiply point with scalar that is larger than the field order (should succeed). |
| 101 | + |
| 102 | +# Implementation |
| 103 | + |
| 104 | +See https://github.com/rsksmart/rskj/tree/secp_ec for canonincal implementation and testing code. This implementation uses the BouncyCastle cryptographic library, which is slower than libsecp256k1. The gas costs are set according to libsecp256k1 performance. |
| 105 | + |
| 106 | +# Security Considerations |
| 107 | + |
| 108 | +This proposal follows the input/output format of [EIP-196](https://eips.ethereum.org/EIPS/eip-196) to avoid introducing new vulnerabilities related to blank or long inputs and outputs. Solidiy wrappers written for the bn128 precompiles should be easily adapted to work with the new precompiles. |
| 109 | + |
| 110 | +Gas cost were chosen as [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108) to match real costs, and should not create new DoS vectors. |
| 111 | + |
| 112 | +The usual code for addition and multiplication over secp256k1 is deterministic and does not present resource-consuming edge cases. |
| 113 | + |
| 114 | + |
| 115 | +The precompiles introduced do not increase the protocol's attack surface as the addition and multiplication functions are already linked by the Rootstock codebase and in use when checking ECDSA signatures. |
| 116 | + |
| 117 | +# Copyright |
| 118 | + |
| 119 | + |
| 120 | +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
0 commit comments