From 8e0feb93d371e4a951c49f1db020ebcf654ca770 Mon Sep 17 00:00:00 2001 From: Olga Kunyavskaya Date: Wed, 6 Dec 2023 11:46:24 +0200 Subject: [PATCH] fix motivation grammer --- neps/nep-0488.md | 39 +++++++++++++++++++-------------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/neps/nep-0488.md b/neps/nep-0488.md index b60692407..70981daf7 100644 --- a/neps/nep-0488.md +++ b/neps/nep-0488.md @@ -16,36 +16,35 @@ This NEP introduces host functions to perform operations on the BLS12-381 ellipt ## Motivation -The primary aim of this NEP is to enable fast and efficient verification of BLS signatures and zkSNARKs based on -BLS12-381[^1],[^11],[^52] elliptic curve on NEAR. +The primary aim of this NEP is to enable fast and efficient verification of BLS signatures and zkSNARKs based on the BLS12-381[^1],[^11],[^52] elliptic curve on NEAR. To efficiently verify zkSNARKs[^19], host functions for operations on the BN254 -elliptic curve(also known as Alt-BN128)[^9], [^12] have already been implemented on NEAR[^10]. +elliptic curve (also known as Alt-BN128)[^9], [^12] have already been implemented on NEAR[^10]. For instance, the Zeropool[^20] project utilizes these host functions for verifying zkSNARKs on NEAR. However, recent research shows that the BN254 security level is lower than 100-bit[^13] and it is not recommended for use. BLS12-381, on the other hand, offers over 120 bits of security[^8] and is widely used[^2],[^3],[^4],[^5],[^6],[^7] as a robust alternative. Supporting operations for BLS12-381 elliptic curve will significantly enhance the security of projects similar to Zeropool. Another crucial objective is the verification of BLS signatures. -Initially, host functions for BN254 in NEAR were designed for zkSNARK verification and -are insufficient for BLS signature verifications. -However, even if they were sufficient, it wouldn't work for us. -Projects such as ZCash[^2], Ethereum[^3], Tezos[^5], and Filecoin[^6] incorporate BLS12-381 specifically within their protocols. +Initially, host functions for BN254 on NEAR were designed for zkSNARK verification and +are insufficient for BLS signature verification. +However, even if these host functions were sufficient for BLS signature verification on the BN254 elliptic curve, this would not be enough for compatibility with other projects. +In particular, projects such as ZCash[^2], Ethereum[^3], Tezos[^5], and Filecoin[^6] incorporate BLS12-381 specifically within their protocols. If we aim for compatibility with these projects, we must also utilize this elliptic curve. For instance, to create a trustless bridge[^17] between Ethereum and NEAR, we must efficiently verify BLS signatures based on BLS12-381, as these are the signatures employed within Ethereum's protocol. In this NEP, we propose to add the following host functions: -- ***bls12381_g1_sum —*** sum the signed points from $G_1$ on an elliptic curve. This function is useful for aggregating public keys in BLS Signature. It can be employed for simple addition in $G_1$. It is kept separate from the multiexp function due to gas cost considerations. -- ***bls12381_g2_sum —*** sum the signed points from $G_2$ on an elliptic curve. This function is useful for aggregating signatures in BLS Signature. -- ***bls12381_g1_multiexp —*** for points $g_i \in G_1$ and scalars $s_i$ calculate $\sum g_i s_i$. This operation can be utilized to multiply a group element by a scalar. -- ***bls12381_g2_multiexp —*** for points $g_i \in G_2$ and scalars $s_i$ calculate $\sum g_i s_i$. -- ***bls12381_map_fp_to_g1 —*** maps a base field elements into the $G_1$ points. It does not perform the mapping of the byte string into field elements. -- ***bls12381_map_fp2_to_g2 —*** maps an extension field elements into the $G_2$ points. It does not perform the mapping of the byte string into extension field elements. We need this function to efficiently map a message into a group element. We are not implementing the hash_to_field[^60] function because it can be executed within a contract and various hashing algorithms can be applied. -- ***bls12381_decompress_g1 —*** decompresses the points from $G_1$ provided in the compressed form. Certain protocols offer points on the curve in compressed form (e.g., the light client updates in Ethereum 2.0), and decompression is a time-consuming operation. All the other functions in this NEP only accept decompressed points for simplicity and optimized gas consumption. -- ***bls12381_decompress_g2 —*** decompresses the points from $G_2$ provided in the compressed form. -- ***bls12381_pairing_check —*** verifying that $\prod e(p_i, q_i) = 1$, where $e$ is a pairing operation and $p_i \in G_1 \land q_i \in G_2$. This function is used to verify BLS signatures or zkSNARKs. +- ***bls12381_g1_sum —*** computes the sum of signed points from $G_1$ on an elliptic curve. This function is useful for aggregating public keys in the BLS signature scheme. It can be employed for simple addition in $G_1$. It is kept separate from the `multiexp` function due to gas cost considerations. +- ***bls12381_g2_sum —*** computes the sum of signed points from $G_2$ on an elliptic curve. This function is useful for aggregating signatures in the BLS signature scheme. +- ***bls12381_g1_multiexp —*** calculates $\sum g_i s_i$ for points $g_i \in G_1$ and scalars $s_i$. This operation can be used to multiply a group element by a scalar. +- ***bls12381_g2_multiexp —*** calculates $\sum g_i s_i$ for points $g_i \in G_2$ and scalars $s_i$. +- ***bls12381_map_fp_to_g1 —*** maps base field elements into $G_1$ points. It does not perform the mapping of byte strings into field elements. +- ***bls12381_map_fp2_to_g2 —*** maps extension field elements into $G_2$ points. This function does not perform the mapping of byte strings into extension field elements, which would be needed to efficiently map a message into a group element. We are not implementing the `hash_to_field`[^60] function because the latter can be executed within a contract and various hashing algorithms can be used within this function. +- ***bls12381_decompress_g1 —*** decompresses points from $G_1$ provided in a compressed form. Certain protocols offer points on the curve in a compressed form (e.g., the light client updates in Ethereum 2.0), and decompression is a time-consuming operation. All the other functions in this NEP only accept decompressed points for simplicity and optimized gas consumption. +- ***bls12381_decompress_g2 —*** decompresses points from $G_2$ provided in a compressed form. +- ***bls12381_pairing_check —*** verifies that $\prod e(p_i, q_i) = 1$, where $e$ is a pairing operation and $p_i \in G_1 \land q_i \in G_2$. This function is used to verify BLS signatures or zkSNARKs. Functions required for verifying BLS signatures[^59]: @@ -62,12 +61,12 @@ Functions required for verifying zkSNARKs: - bls12381_g1_multiexp - bls12381_pairing_check -Both zkSNARKs and BLS signatures can be implemented alternatively by swapping G1 and G2. -Therefore, all functions have been implemented for both G1 and G2. +Both zkSNARKs and BLS signatures can be implemented alternatively by swapping $G_1$ and $G_2$. +Therefore, all functions have been implemented for both $G_1$ and $G_2$. An analogous proposal, EIP-2537[^15], exists in Ethereum. The functions here have been designed with compatibility -with Ethereum's proposal in mind. This design approach aims +with that Ethereum's proposal in mind. This design approach aims to ensure future ease in supporting corresponding precompiles for Aurora[^24]. ## Specification @@ -185,7 +184,7 @@ To define these fields, we'll need to set up three irreducible polynomials[^51]: - $F_{p^2} = F_p[u] / (u^2 + 1)$ - $F_{p^6} = F_{p^2}[v] / (v^3 - u - 1)$ -- $F_{p^{12}} = F_{p^6}[w]/(w^2 - v)$ +- $F_{p^{12}} = F_{p^6}[w] / (w^2 - v)$ The second subgroup we'll utilize has an order of r and resides within the same elliptic curve but with elements from $F_{p^{12}}$.