The proposal has already been submitted on CPS and can be found here. Given the nature of the project, we found a need to provide more context on what exactly we plan to do and why it’s a desirable toolkit in the current context.
We are simply proposing to add support for the curve operations on the chain. These curve operations have already been proposed and implemented on Ethereum as EIP-196 [precompiled contracts for addition and scalar multiplication] and EIP-197 [precompiled contracts for pairing function]. So, it’s not a R&D but rather using the existing [Ethereum’s bn256] (go-ethereum/crypto/bn256 at master · ethereum/go-ethereum · GitHub) library and exposing it as part of Context in ICON SCORE as follows:
For addition
Context.bn256("add", data)
For multiplication
Context.bn256("mul", data)
For pairing
Context.bn256("pairing", data)
The specification:
`/**
* Returns elliptic curve point multiplication on altBN128 curve
* @param op is an operation to apply to the data. Possible values are:
* add, mul, pairing
* For add operation, the data should have following layout
* 0-31: x-coordinate of point `a` in G1
* 32-63: y-coordinate of point `a` in G1
* 64-95: x-coordinate of point `b` in G1
* 96-127: y-coordinate of point `b` in G1
* For mul operation, the data should have following layout
* 0-31: x-coordinate of point `p` in G1
* 32-63: y-coordinate of point `p` in G1
* 64-95: a scalar of group G1 of bn256 curve
* For pairing operation, the data should have following layout
* 0-31 bytes: x-coordinate of a point `p` in G1
* 32-63 bytes: y-coordinate of a point `p` in G1
* 64-95 real part of x-coordinate of a point `p2` in G2
* 96-127 imag part of x-coordinate of a point `p2` in G2
* 127-159 real part of y-coordinate of a point `p2` in G2
* 160+191 imag part of y-coordinate of a point `p2` in G2
* ... and this layout repeats for each additional pair
* @return a byte array specific to each operation
* For add and mul operation, the layout is
* 0-31: x-coordinate of point `a` in G1
* 32-63: y-coordinate of point `a` in G1
* For pairing operation, the layout is
* 0-1: a single byte with value `0` for failure and `1` for success.
* @throws IllegalArgumentException specified point coordinates are invalid
*/
public static byte[] bn256(String op, byte[] data) {
return null;
}
The implementation of the above EIPs has allowed verification of zkSNARKs in Ethereum smart contracts enabling applications such as DarkForest, TornadoCash and various private applications etc.
We are proposing to add the support for the same curve on the ICON blockchain. Since the curve has been around for a while and is also used on Ethereum, it has lots of tools built around it including circom and snarkjs. We will update these tools to support ICON chain.
One immediate application we can think of is anonymous voting in CPS grant proposal i.e.P-Reps can cast the vote without revealing their identity thus removing undue influence in the voting process.
We feel that Zero Knowledge Proof is a very different way of writing/ designing applications . Exposing this to developers on the ICON eco-system will allow them to start thinking about privacy preserving applications as this seems to be where the industry is moving towards.
Note: On the naming of the curves: bn256 - Barreto-Naehrig Curve with 256 bits implementation. The same curve is also referenced as bn128 or alt_bn128 because of the 128 bits of security it provides.