Fix vocabulary, inconsistent use of names, incorrect terminology

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 precompiles 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 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.
 
 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].
@@ -55,8 +55,6 @@ By using the functions introduced above, we can reproduce all functionality from
 
 **Definition:** The field $F_p$ for some *prime* $p$ is a set of integer elements $\textbraceleft 0, 1, \ldots, p - 1 \textbraceright$ with two operations: multiplication $\cdot$ and addition $+$. These operations are performed as multiplication/addition for integers number and then taking the remainder modulo $p$.
 
-
-
 **Definition:** The elliptic curve $E(F_p)$  is a set of all pairs $(x, y) \in F_p$:
 
 $$
@@ -564,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 Alt-BN128 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 Alt-BN128 implementation in nearcore[^50], but `big-endian` encoding is used instead of `little-endian` as in EIP-2537[^15].
 
 #### Fields elements Fp
 
@@ -695,7 +693,7 @@ x[0] = x[0] | 0x40;
 
 The rule of encoding is consistent with zkcrypto[^53] and with implementation in milagro lib[^29].
 
-### Precompile functions
+### Host functions
 
 #### bls12381_g1_sum
 
@@ -890,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 precompile 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 `Alt-BN128`[^10].
 
 ```rust
 let k = (input_bytes+item_size-1)/item_size;
@@ -980,18 +978,18 @@ The $E'(F_{p^2})$ curve,  points on the curve and the addition operation are def
 
 Note:
 
-- We take as input any points on the curve, not only from   $G_2$.
+- We take as input any points on the curve, not only from $G_2$.
 - The scalar is an arbitrary unsigned integer and can be bigger than the group order.
 
 ***Input:*** the sequence of pairs $(p_i, s_i)$, where $p_i \in E'(F_{p^2})$ is a point on the curve and $s_i \in \mathbb{N}_0$ is a scalar. 
 
 Each point is encoded in decompress form as $(x\colon F_{p^2}, y\colon F_{p^2})$ and a scalar has a type `u256` and BigEndian encoded in 32 bytes. Expected `224*k` bytes as an input that is interpreted as byte concatenation of `k` slices, each slice is the concatenation of uncompressed point from $E'(F_{p^2})$ — `192` bytes and scalar — `32` bytes. More details are in the Curve Points Encoding section.
 
-***Output:*** the output is 192 bytes — the one point $\in E'(F_{p^2})$ in decompressed form. For empty input it returns point on infinity(see  Curve Points Encoding section).
+***Output:*** the output is 192 bytes — the one point $\in E'(F_{p^2})$ in decompressed form. For empty input it returns point on infinity(see Curve Points Encoding section).
 
 ***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 precompile 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 `Alt-BN128`[^10].
 
 ```rust
 let k = (input_bytes+item_size-1)/item_size;
@@ -1270,8 +1268,6 @@ pub fn bls12381_pairing_check(&mut self, value_len: u64, value_ptr: u64) -> Resu
 
 ***Description:***  Function decompress compressed points from $E(F_p)$. The input is an arbitrary number of points $p_i \in E(F_p)$ in compressed format, and the output is the same number of points from $E(F_p)$ in decompressed format. More about the decompressed and compressed formats you can read in the Curve Points Encoding section.
 
-
-
 ***Input:***  the sequence of point $p_i \in E(F_p)$, each point encoded in compressed form. Expected `48*k` bytes as an input that is interpreted as byte concatenation of `k` slices, each slice is the compressed point from $E(F_p)$. More details are in the Curve Points Encoding section.
 
 ***Output:*** the sequence of point $p_i \in E(F_p)$, each point encoded in decompressed form. Expected `96*k` bytes as an output that is interpreted as byte concatenation of `k` slices, each slice is the decompressed point from $E(F_p)$. `k` the same as in input. More details are in the Curve Points Encoding section.
@@ -1426,7 +1422,7 @@ First of all, for integration with nearcore, we are interested in libraries in t
 6. ***FileCoin implementation*** [^35]
 7. ***zkCrypto*** [^36]
 
-To compile the list, we used the links from EIP-2537[^43], pairing-curves specification[^44], and an article with benchmarks[^45]. This list may be incomplete but should cover the core BLS12-381 implementations. In any case, to implement precompiles from that NEP we will need to modify any of that libraries.
+To compile the list, we used the links from EIP-2537[^43], pairing-curves specification[^44], and an article with benchmarks[^45]. This list may be incomplete but should cover the core BLS12-381 implementations. In any case, to implement host functions from that NEP we will need to modify any of that libraries.
 
 In addition, there are implementations in other languages that are not so interesting to us in this context, but can be used as references:
 
@@ -1437,23 +1433,23 @@ In addition, there are implementations in other languages that are not so intere
 5. Go, ***Matter Labs Go EIP-1962 implementation***[^41]
 6. C++, ***Matter Labs Go EIP-1962 implementation***[^42]
 
-The draft implementation to nearcore you can find by this link[^54]. This implementation is based on blst library[^30]. This library one of the fastest[^45] and audited[^55].
+The draft implementation to nearcore you can find by this link[^54]. This implementation is based on *blst* library[^30]. This library one of the fastest[^45] and the most audited[^55].
 
 ## Security Implications
 
 The implementation security relies on the security of the chosen library, which supports operations with BLS curves.
 
-In this NEP, we do not require a constant execution time for all operations. This is not a problem if you use precompiles to verify the BLS signature. These precompiles should not be used if you need a constant-time algorithm.
+In this NEP, we do not require a constant execution time for all operations. This is not a problem if you use host functions to verify the BLS signature. These host functions should not be used if you need a constant-time algorithm.
 
 The BLS12-381 has more security bits than the already existing pairing-friendly curve BN254, as a result, the security of the projects which need the pairing-friendly curve will improve.
 
 ## Alternatives
 
-In the nearcore the precompiles 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 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 Eth2.0 it is BLS12-381[^3]. As a result, there is no alternative to using another pairing-friendly curve.
+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.
 
-Another alternative is to create one simple precompile 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 for public keys G1 subgroup, another G2; (3) the specification for Eth2.0 continue to be in the draft and details can change, (4) in such implementation we can't support precompiles from EIP-2537.
+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).
 
-The next alternative is to execute BLS12-381 operations off-chain. In that case, the applications which used the BLS curve will not be trustless anymore.
+The next alternative is to execute BLS12-381 operations off-chain. In that case, the applications which are using the BLS curve will not be trustless anymore.
 
 ## Future possibilities
 
@@ -1463,8 +1459,8 @@ In the future, it is possible to support work with other curves, not only BLS12-
 
 ### Positive
 
-- Projects, which used BN254 will be able to switch on BLS12-381 curve, and it will improve security.
-- The trustless cross-chain interactions with blockchains that use BLS12-381 in protocols(such as Ethereum 2) will become possible.
+- Projects, which are using BN254 will be able to switch on BLS12-381 curve, and it will improve their security.
+- The trustless cross-chain interactions with blockchains using BLS12-381 in protocols (such as Ethereum 2.0) will become possible.
 
 ### Neutral
 
@@ -1489,7 +1485,7 @@ The previous NEP for supporting BLS signature based on BLS12-381[^26]
 [^7]: Specification of pairing friendly curves with a list of applications in the table: [https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-09#name-adoption-status-of-pairing-](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-09#name-adoption-status-of-pairing-)
 [^8]: Specification of pairing friendly curves, the security level for BLS12-381: [https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-09#section-4.2.1](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-09#section-4.2.1)
 [^9]: BN2005: [https://eprint.iacr.org/2005/133](https://eprint.iacr.org/2005/133)
-[^10]: NEP-98 for BN254 precompile on NEAR: [https://github.com/near/NEPs/issues/98](https://github.com/near/NEPs/issues/98)
+[^10]: NEP-98 for BN254 host functions on NEAR: [https://github.com/near/NEPs/issues/98](https://github.com/near/NEPs/issues/98)
 [^11]: BLS12-381 for the Rest of Us: [https://hackmd.io/@benjaminion/bls12-381](https://hackmd.io/@benjaminion/bls12-381)
 [^12]: BN254 for the Rest of Us: [https://hackmd.io/@jpw/bn254](https://hackmd.io/@jpw/bn254)
 [^13]: Some analytics of different curve security: [https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-02.html#name-for-100-bits-of-security](https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-02.html#name-for-100-bits-of-security)
@@ -1505,7 +1501,7 @@ The previous NEP for supporting BLS signature based on BLS12-381[^26]
 [^23]: Ledger post about Roll Ups: [https://www.ledger.com/academy/what-are-blockchain-rollups](https://www.ledger.com/academy/what-are-blockchain-rollups)
 [^24]: Precompiles on Aurora: [https://doc.aurora.dev/evm/precompiles/](https://doc.aurora.dev/evm/precompiles/)
 [^25]: Pippenger Algorithm: [https://github.com/wborgeaud/python-pippenger/blob/master/pippenger.pdf](https://github.com/wborgeaud/python-pippenger/blob/master/pippenger.pdf)
-[^26]: NEP-446 proposal for BLS-signature verification precompile: [https://github.com/nearprotocol/neps/pull/446](https://github.com/nearprotocol/neps/pull/446)
+[^26]: NEP-446 proposal for BLS-signature verification: [https://github.com/nearprotocol/neps/pull/446](https://github.com/nearprotocol/neps/pull/446)
 [^27]: EIP-1962 EC arithmetic and pairings with runtime definitions: [https://eips.ethereum.org/EIPS/eip-1962](https://eips.ethereum.org/EIPS/eip-1962)
 [^28]: Drawbacks of NEP-446: [https://github.com/near/NEPs/pull/446#pullrequestreview-1314601508](https://github.com/near/NEPs/pull/446#pullrequestreview-1314601508)
 [^29]: BLS12-381 Milagro: [https://github.com/sigp/incubator-milagro-crypto-rust/tree/057d238936c0cbbe3a59dfae6f2405db1090f474](https://github.com/sigp/incubator-milagro-crypto-rust/tree/057d238936c0cbbe3a59dfae6f2405db1090f474)