NEP-446: Efficient BLS-signature verification

[olga24912]

Summary

A pre-compiled NEAR runtime function for verifying BLS12-381 signatures.
That enables running Ethereum 2 light clients on-chain.

[mfornet]

I'm surprised that the aggregate_verify function fits in a single block. See near/nearcore#8184. It would be great to have a second confirmation that the cost correlates to wall clock time.

A similar NEP already merged: #364 that adds ED25519 verification as a host function. From experience with #364, this document should clearly state how all edge cases should be treated and not rely on a particular 3rd party implementation.

[mariocao]

Thanks for proposing this NEP as we were interested in using the BLS12-381 curve. 👏

This NEP also has the additional motivation of providing a cryptographic primitive that allows getting ~120 bits of security [1] over a pairing-friendly curve compared to the existing supported BN254 (alt_bn128), which only provides 100 bits of security (dropped after new algorithms from Kim-Barbulescu [2]).

This primitive will promote building more secure protocols and facilitate interoperability with already-existing cryptographic systems using signature aggregation schemes based on the BLS12-381 curve.

[1] https://www.nccgroup.trust/globalassets/our-research/us/public-reports/2019/ncc_group_zcash2018_public_report_2019-01-30_v1.3.pdf
[2] https://eprint.iacr.org/2015/1027.pdf

[ori-near]

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). If you want to assign yourself, please mention that you are acting as the Technical Reviewers.

Please find some guidelines below for completing the technical review.

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 recommendation for the working group if the NEP is ready for voting (it could be approving or rejecting recommendation)
  • A summary of benefits
  • A summary of concerns and blockers that were identified on the way and their status (some will be resolved, others dismissed, etc)
    Here is a nice example and a template for your convenience:

## Example
### 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.

[bowenwang1996]

I'd like to nominate @mfornet and @abacabadabacaba as the SME reviewers for this NEP

[ori-near]

Hi @mfornet and @abacabadabacaba thank you so much for agreeing to review this NEP. Per the NEP workflow, the expectation is for you to complete the review within one week (~February 22, 2023). Please find some guidelines below for completing the technical review.

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 recommendation for the working group if the NEP is ready for voting (it could be approving or rejecting recommendation)
  • A summary of benefits
  • A summary of concerns and blockers that were identified on the way and their status (some will be resolved, others dismissed, etc)
    Here is a nice example and a template for your convenience:

## Example
### 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.

[ori-near]

Hi @abacabadabacaba and @mfornet – just wanted to follow up on the SME review. Can you please complete it per the guidelines in #446 (comment)? Thank you.

[abacabadabacaba]

Hi @ori-near @olga24912,
There are two major issues with this NEP:

1. The functionality introduced by this NEP seems very limited. It makes our code base depend on a rather complex BLS12-381 curve implementation, and yet it only allows verifying one type of signatures.
   It is preferable for functionality to be exposed in a general way, so that we won't need to make more protocol changes if someone needs, for example, to check some different type of BLS12-381 based signature. EIP-2537 provides a number of functions for BLS12-381 curve, and its design looks good in terms of being general enough to support a variety of use cases. Also, being able to implement EIP-2537 functions using NEAR host functions would be immediately beneficial for Aurora, which is another reason why it is a good idea to allow this.
2. The specification provided in this NEP is clearly insufficient. This NEP lists multiple existing implementations, however, having a specification is important. Different implementations may behave differently, and even the same implementation can behave differently depending on version and other factors. For a blockchain, consistent behavior is essential, so a NEP should include a specification, and an implementation should include tests that verify that the specification is actually followed.
   By the way, while EIP-2537 omits some of the details of the functions that it implements, it seems to include enough to describe the functions unambigously.
   Also, different error conditions and their outcomes should be precisely defined. In general, contract execution should only be terminated in cases which can be easily avoided, such as invalid input length.

[ori-near]

Hi @olga24912 – as the moderator, I just wanted to confirm you received the feedback above: #446 (review)

Please let us know if you plan to address the feedback. Thank you.

[olga24912]

Hi @olga24912 – as the moderator, I just wanted to confirm you received the feedback above: #446 (review)

Please let us know if you plan to address the feedback. Thank you.

Hi @ori-near

I confirm that I received the feedback. And we are planning to address that. Currently, we are trying to figure out the best way to verify BLS-signature in case we have precompiled BLS primitives.

Thank you!

[ori-near]

Hi @olga24912, as the moderator – I wanted to follow up on this NEP and see if you are still working on it? We typically close NEPs that are inactive for more than two months, so please let us know if you need more time.

[olga24912]

Hi @olga24912, as the moderator – I wanted to follow up on this NEP and see if you are still working on it? We typically close NEPs that are inactive for more than two months, so please let us know if you need more time.

Sorry for the long response!

I think it's a good idea to go the way Evgeny suggested, but with small changes:
In EIP-2537(https://eips.ethereum.org/EIPS/eip-2537) all points are accepted in a super uncompressed way. For points from G1 it takes 128 bytes instead of 48, for G2: 256 instead 96. According to my calculation, uncompressing compressed points is gas consuming operation (and we should do it for ~500 points). So I propose to accept in all functions both points versions: compressed and uncompressed.

In the case of implementing low-level functions from EIP-2537, I propose closing this NEP and creating a new one due to significant changes.

[bowenwang1996]

@olga24912 sounds good. Let's close this NEP then