NEP-488: Precompile for BLS12-381 curve operations

[olga24912]

A pre-compiled NEAR runtime functions for operations on BLS12-381 curve. It is a necessary set to efficiently perform operations such as BLS signature and zkSNARKs verifications.

Related PR: #446

---

NEP Status (Updated by NEP Moderators)

Status: Approved

Meeting Recording:
https://bit.ly/41V49Ke

SME reviews:

• @abacabadabacaba: NEP-488: Precompile for BLS12-381 curve operations #488 (review)
• @michelabdalla: NEP-488: Precompile for BLS12-381 curve operations #488 (review)

Protocol Work Group voting indications (❔ | 👍 | 👎 ):

• 👍 @birchmd: NEP-488: Precompile for BLS12-381 curve operations #488 (comment)
• 👍 @mfornet: NEP-488: Precompile for BLS12-381 curve operations #488 (comment)
• 👍 @mm-near: NEP-488: Precompile for BLS12-381 curve operations #488 (comment)
• 👍 @bowenwang1996: NEP-488: Precompile for BLS12-381 curve operations #488 (comment)

[frol]

Thank you @olga24912 for submitting this NEP.

As a moderator, I reviewed this NEP and it meets the proposed template guidelines. I am moving this NEP to the REVIEW stage and would like to ask the @near/wg-protocol working group members to assign 2 Technical Reviewers to complete a technical review (see expectations below).

Just for clarity, Technical Reviewers play a crucial role in scaling NEAR ecosystem as they provide their in-depth expertise in the niche topic while work group members can stay on guard of the NEAR ecosystem. The discussions may get too deep and it would be inefficient for each WG member to dive into every single comment, so NEAR Developer Governance designed this process that includes subject matter experts helping us to scale by writing a summary with the raised concerns and how they were addressed.

Technical Review Guidelines

• First, review the proposal within one week. If you have any suggestions that could be fixed, leave them as comments to the author. It may take a couple of iterations to resolve any open comments.

• Second, once all the suggestions are addressed, produce a Technical Summary, which helps the working group members make a weighted decision faster. Without the summary, the working group will have to read the whole discussion and potentially miss some details.

Technical Summary guidelines:

• A recommendation for the working group if the NEP is ready for voting (it could be approving or rejecting recommendation). Please note that this is the reviewer's personal recommendation.

• A summary of benefits that surfaced in previous discussions. This should include a concise list of all the benefits that others raised, not just the ones that the reviewer personally agrees with.

• A summary of concerns or blockers, along with their current status and resolution. Again, this should reflect the collective view of all commenters, not just the reviewer's perspective.

Here is a nice example and a template for your convenience:

### Recommendation

Add recommendation

### Benefits

* Benefit

* Benefit

### Concerns

| # | Concern | Resolution | Status |

| - | - | - | - |

| 1 | Concern | Resolution | Status |

| 2 | Concern | Resolution | Status |

Please tag the @near/nep-moderators once you are done, so we can move this NEP to the voting stage. Thanks again.

[Ekleog-NEAR]

The changes LGTM, thank you!

I think the last question that deserves thinking about is, the encoding of error value returns.

This being said, I would already suggest moving forward with the audit and the stakeholder review, taking into account that there could be minor changes remaining considering the exact encoding of return values.

[abacabadabacaba]

As a subject matter expert, I recommend the working group to accept this NEP.

Here are some points in the discussion that I wish to highlight:

• Scope of the proposed functionality: unlike the previous BLS NEP (NEP-446: Efficient BLS-signature verification #446), this NEP introduces an API suitable for different uses, including verification of BLS signatures and zkSNARKs, as well as different variants of BLS signatures and zkSNARKs. This is desirable because different variants may be in use by existing systems, and with this NEP NEAR will be able to interoperate with them without having to introduce separate functions for each of them. One aspect of functionality that led to a disagreement is whether there should be a means to reduce the inputs to the map-to-curve functions modulo $p$. Such functionality could be provided either as a part of the aforementioned map-to-curve functions or as a separate function. The point against providing this functionality was that in RFC 9380, which describes hashing to elliptic curves, reduction modulo $p$ is a part of the hash_to_field function. This function can use multiple different hash functions, so it is not possible to provide all of them in a single host function. Another point is that the input to be reduced modulo $p$ can be of variable length, which complicates the API (especially when multiple inputs need to be provided at once) and also complicates the gas pricing. The point for adding such functionality is that several hash functions are already available as host functions in NEAR, so adding a function to reduce values modulo $p$ would mean that it would be possible to verify BLS signatures without performing any substantial computations in WASM. For the Eth2NEAR bridge, the gas cost of performing the reduction in WASM was found to be acceptable, but this may not be the case for other uses. Anyway, this functionality can be added later (as a separate function).
• Detailed API design: during the discussion of this NEP, concerns were raised about the specifics of the proposed API, especially about error handling. The original proposal included terminating the smart contract on invalid inputs, but this was found to complicate certain uses. Instead, the proposal was changed to return an error code in those situations. The current proposal provides for a single error code to be returned for any kind of invalid data, so that the implementation is not constrained in how it checks for errors. Another change that resulted from the discussion was that now some functions operate on multiple values, while in the original proposal they only operated on a single value.
• Last but not least, there were discussions about what information should be included in the specification and what shouldn't, how it should be presented, and also the reviewers pointed out multiple minor errors in the text. While this is less important than the substance, it is important nevertheless.

Also I wish to say thank you to all the reviewers, it's not often that you have to review a NEP this large, and you did it.

[walnut-the-cat]

With approvals from two SMEs, I will work with protocol working group to schedule the working group call for the final approval stage.

[bowenwang1996]

As a working group member, I lean towards approving this NEP. The BLS host function allows us to restore completely trustless bridging from Ethereum to NEAR, which is quite important for the entire NEAR ecosystem.

[ori-near]

As the moderator, I would like to thank @abacabadabacaba and @michelabdalla for submitting the technical review. Based on your comments above, it seems like this proposal is ready for the working group members for review. @near/wg-protocol – Can you please fully read this NEP and comment in the thread if you are leaning towards approving or rejecting it? Please make sure to include your rationale and any feedback that you have for the author. Once we get 2/3 voting indications, we will schedule a public call for the author to present the NEP and for the working group members to formalize the voting.

[birchmd]

As a working group member, I lean towards approving this NEP for the same reason as @bowenwang1996

[mfornet]

As a working group member, I lean towards approving this NEP. It allows going back to a trustless bridge between NEAR and Ethereum, and provides important primitives to develop ZK technology on top of NEAR.

I appreciate the effort from @olga24912 and all SME (@abacabadabacaba @Ekleog-NEAR @michelabdalla), for pushing this NEP to the finish line, it has been a massive effort, and the quality of the whole process was very high.

[ori-near]

As the moderator, I would like to thank @olga24912 for submitting this Protocol NEP and for the @near/wg-protocol work group members for your review. Based on the voting indications above, it seems like this proposal is close to a decision. We are therefore scheduling the seventh Work Group Name Working group meeting next week, where this NEP can enter the final voting stage. Anyone can discuss the technical details by adding your comments to this discussion. And join the call to learn about the final decision and how to get more involved.

Meeting Info
📅 Date: Wednesday, Jan 10, 4pm UTC
✏️ Add to calendar

[mm-near]

As a working group member, I lean towards approving this NEP.

[victorchimakanu]

Thank you to everyone who attended the Seventh Protocol Work Group call today! The work group members reviewed NEP-488 and reached the following consensus:

Status: Approved

👍@birchmd:NEP-488: Precompile for BLS12-381 curve operations #488 (comment)
👍 @mfornet: NEP-488: Precompile for BLS12-381 curve operations #488 (comment)
👍@mmnear: NEP-488: Precompile for BLS12-381 curve operations #488 (comment)
👍@bowenwang1996: NEP-488: Precompile for BLS12-381 curve operations #488 (comment)

Meeting Recording:
https://bit.ly/41V49Ke

@olga24912 Thank you for authoring this NEP!

Next Steps:

• Internal review by rainbow bridge team (@olga24912 , @karim-en)
• PR marked ‘Ready for review’
• Nearcore review process; merge; release

[adr1anh]

The link seems to have changed to https://doc.aurora.dev/dev-reference/precompiles/

[olga24912]

fixed: 59c7f7f

[adr1anh]

GitHub doesn't render the latter LaTeX expression $E'(F_{p^2})$ .

[olga24912]

fixed: 52f9559

[olga24912]

Hi everyone!

I would like to know your opinion about the input for sum/multiexp.

I propose to accept any points on the curve as input for sum, and only points from the subgroup for multiexp.

Initially, in the NEP, I suggested accepting any points on the curve as input for both sum and multiexp to save gas. However, the implementation is currently under audit, and already the second auditor has expressed doubts about this decision. Recently, I changed the input for sum and multiexp to only points from G1/G2. However, now I think that the optimal solution would be to allow sum to accept any points, while multiexp should only accept points from G1/G2.

I will now write my thoughts on this matter:

1. For reasonable applications of these functions, it is sufficient for them to work only with points from the subgroups.

2. A user cannot simply verify that a point belongs to a subgroup within the contract because it requires a lot of gas.

3. Theoretically, it is possible to add several points not from the subgroup and obtain a point in the subgroup. In this case, the user will not know that the original data was incorrect.

4. EIP-2537 works only with points from G1 or G2 and returns an error otherwise. To be compatible with these functions, we also need to check subgroup membership.

5. In the case of multiexp, if the points belong to the subgroup, it will be possible to use additional optimizations in the future, such as Pippenger's algorithm.

6. I calculated the gas, and for the sum function, it changed from 0.002 TGas to 0.08 TGas per element and from 0.005 TGas to 0.1 TGas per element. This means gas consumption has increased tenfold.

7. For multiexp, the changes are not as dramatic. It changed from 0.2 TGas to 0.3 TGas per element and from 0.5 TGas to 0.6 TGas per element. I have not applied Pippenger's algorithm.

8. A similar discussion recently took place regarding EIP-2537, and it was decided not to check subgroup membership for the sum function: https://ethereum-magicians.org/t/eip-2537-bls12-precompile-discussion-thread/4187/65

9. We can use multiexp for addition with subgroup membership verification and the regular sum function to save gas without subgroup membership verification.

As a result, it seems reasonable to me to accept points from the subgroup as input for multiexp and to accept any points on the curve for sum.

What is your opinion? @abacabadabacaba @Ekleog-NEAR @michelabdalla @adr1anh @akhi3030

[akhi3030]

I don't have a deep enough technical understanding to have an opinion unfortunately.