alt-bn128 -> bn254

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,15 +562,15 @@ 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
 
 The sign of the point on the elliptic curve is encoded as `u8` type in Rust with two possible values: `0` and `1`. `0` for positive sign, and `1` for negative sign. All other value of `u8` is not allowed and should be interpreted as incorrect.
 
 #### 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).