diff --git a/neps/nep-0488.md b/neps/nep-0488.md index 18760fb23..9c0da0521 100644 --- a/neps/nep-0488.md +++ b/neps/nep-0488.md @@ -22,7 +22,7 @@ The host functions implementation for the BLS12-381 curve operations from this N As we have seen above, other blockchains are using the BLS12-381 signature. In the context of cross-chain interactions we want to have a possibility to verify transactions from these blockchains on Near. Usually, it is done by implementing the on-chain client on Near, which will verify the corresponding BLS signatures. It is especially important for the Rainbow Bridge[^17] to send trustless transfers from Ethereum to Near. -zkSNARKs are useful to work with the user's private information[^18][^19]. Zeropool[^20] is a project, which implements zkSNARKs verifier on Near and is currently based on Alt-BN128. Implementation of the host functions for BLS12-381 can make the projects like that more secure. zkSNARKs are also used in Rollups[^21][^22][^23] scaling solution. +zkSNARKs are useful to work with the user's private information[^18][^19]. Zeropool[^20] is a project, which implements zkSNARKs verifier on Near and is currently based on BN254. Implementation of the host functions for BLS12-381 can make the projects like that more secure. zkSNARKs are also used in Rollups[^21][^22][^23] scaling solution. This proposal is based on a similar proposal for Ethereum: EIP-2537[^15], so you will find similar functions there. The closest analogues on Near are functions available for BN254 curve, also known as Alt-BN128[^10]. @@ -562,7 +562,7 @@ The constants used to compute $y_{den}$ are as follows: #### Bool as output -The bool is encoded as a little-endian `u64` type in Rust. The `true` value is encoded as `1` and `false` is encoded as `0`. All other values of `u64` are not allowed and should be interpreted as incorrect. Encoding is the same as for Alt-BN128 implementation in nearcore[^50]. +The bool is encoded as a little-endian `u64` type in Rust. The `true` value is encoded as `1` and `false` is encoded as `0`. All other values of `u64` are not allowed and should be interpreted as incorrect. Encoding is the same as for BN254 implementation in nearcore[^50]. #### Sign @@ -570,7 +570,7 @@ The sign of the point on the elliptic curve is encoded as `u8` type in Rust with #### Scalar -The scalar value is encoded as a big-endian `[u8;32]`. All possible bytes combination is allowed. Encoding is similar with Alt-BN128 implementation in nearcore[^50], but `big-endian` encoding is used instead of `little-endian` as in EIP-2537[^15]. +The scalar value is encoded as a big-endian `[u8;32]`. All possible bytes combination is allowed. Encoding is similar with BN254 implementation in nearcore[^50], but `big-endian` encoding is used instead of `little-endian` as in EIP-2537[^15]. #### Fields elements Fp @@ -888,7 +888,7 @@ Note: ***Gas Estimation:*** -This function should be calculated by Pippenger’s algorithm[^25]. The Complexity of this algorithm is $O(\frac{k}{\log(k)})$. For gas calculation we will use the formula $\frac{k}{\max(\log_2(k), 1)}$ the same way as in the host function for `Alt-BN128`[^10]. +This function should be calculated by Pippenger’s algorithm[^25]. The Complexity of this algorithm is $O(\frac{k}{\log(k)})$. For gas calculation we will use the formula $\frac{k}{\max(\log_2(k), 1)}$ the same way as in the host function for `BN254`[^10]. ```rust let k = (input_bytes+item_size-1)/item_size; @@ -989,7 +989,7 @@ Each point is encoded in decompress form as $(x\colon F_{p^2}, y\colon F_{p^2})$ ***Gas Estimation:*** -This function should be calculated by Pippenger’s algorithm[^25]. The Complexity of this algorithm is $O(\frac{k}{\log(k)})$. For gas calculation we will use the formula $\frac{k}{\max(\log_2(k), 1)}$ the same way as in the host function for `Alt-BN128`[^10]. +This function should be calculated by Pippenger’s algorithm[^25]. The Complexity of this algorithm is $O(\frac{k}{\log(k)})$. For gas calculation we will use the formula $\frac{k}{\max(\log_2(k), 1)}$ the same way as in the host function for `BN254`[^10]. ```rust let k = (input_bytes+item_size-1)/item_size; @@ -1445,7 +1445,7 @@ The BLS12-381 has more security bits than the already existing pairing-friendly ## Alternatives -In the nearcore the host functions for another pairing-friendly curve Alt-BN128 are already implemented[^10]. For some projects[^20] the alternative is just to use the supported curve. However, according to the recent research, this curve contains less than 100 bits of security and is not recommended to use[^13]. Moreover, projects with cross-chain interactions, such as Rainbow Bridge, must use the same curve as in a target protocol, and for Ethereun it is BLS12-381[^3] nowadays. As a result, there is no alternative to using another pairing-friendly curve. +In the nearcore the host functions for another pairing-friendly curve BN254 are already implemented[^10]. For some projects[^20] the alternative is just to use the supported curve. However, according to the recent research, this curve contains less than 100 bits of security and is not recommended to use[^13]. Moreover, projects with cross-chain interactions, such as Rainbow Bridge, must use the same curve as in a target protocol, and for Ethereun it is BLS12-381[^3] nowadays. As a result, there is no alternative to using another pairing-friendly curve. Another alternative is to create one simple host function in nearcore for BLS-signature verification. It was the first suggested solution[^26]. However, this solution is not flexible enough[^28]: (1) projects can use different hash functions; (2) some projects can use G1 subgroup for the public keys, and others – G2; (3) the specification for Ethereum 2.0 continue to be in the draft and details can change, (4) we have one big function instead of a more diverse and flexible set of functions (inspired by EIP-2537's precompiles).