Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NEP-488: Precompile for BLS12-381 curve operations #488

Merged
merged 163 commits into from
Oct 1, 2024

Conversation

olga24912
Copy link
Contributor

@olga24912 olga24912 commented Jul 17, 2023

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:

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

@olga24912 olga24912 requested a review from a team as a code owner July 17, 2023 16:49
@olga24912 olga24912 changed the title NEP-486: Precompile for BLS12-381 curve operations NEP-488: Precompile for BLS12-381 curve operations Jul 17, 2023
@frol frol added WG-protocol Protocol Standards Work Group should be accountable S-draft/needs-moderator-review A NEP in the DRAFT stage that needs a moderator review. A-NEP A NEAR Enhancement Proposal (NEP). labels Jul 30, 2023
@frol
Copy link
Collaborator

frol commented Jul 30, 2023

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.

@frol frol added S-review/needs-wg-to-assign-sme A NEP that needs working group to assign two SMEs. and removed S-draft/needs-moderator-review A NEP in the DRAFT stage that needs a moderator review. labels Jul 30, 2023
@walnut-the-cat
Copy link
Contributor

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

@walnut-the-cat walnut-the-cat added S-voting/needs-wg-voting-indication A NEP in the VOTING stage that needs the working group voting indication. and removed S-review/needs-sme-review A NEP in the REVIEW stage is waiting for Subject Matter Expert review. labels Jan 3, 2024
@bowenwang1996
Copy link
Collaborator

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
Copy link
Contributor

ori-near commented Jan 3, 2024

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
Copy link
Contributor

birchmd commented Jan 4, 2024

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

@mfornet
Copy link
Member

mfornet commented Jan 4, 2024

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
Copy link
Contributor

ori-near commented Jan 4, 2024

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

@ori-near ori-near added S-voting/final-comment-period A NEP in the final REVIEW stage. Last chance to bring up concerns before the voting call. and removed S-voting/needs-wg-voting-indication A NEP in the VOTING stage that needs the working group voting indication. labels Jan 4, 2024
@mm-near
Copy link

mm-near commented Jan 10, 2024

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

@victorchimakanu
Copy link

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

@ori-near ori-near added S-approved A NEP that was approved by a working group. and removed S-voting/final-comment-period A NEP in the final REVIEW stage. Last chance to bring up concerns before the voting call. labels Jan 11, 2024
neps/nep-0488.md Outdated
[^17]: Article about Rainbow Bridge [https://near.org/blog/eth-near-rainbow-bridge](https://near.org/blog/eth-near-rainbow-bridge)
[^19]: Intro into zkSNARKs: [https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b](https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b)
[^20]: Zeropool project: [https://zeropool.network/](https://zeropool.network/)
[^24]: Precompiles on Aurora: [https://doc.aurora.dev/evm/precompiles/](https://doc.aurora.dev/evm/precompiles/)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed: 59c7f7f

neps/nep-0488.md Outdated

For elements from $F_p$ the first three bits will always be $0$, because the first byte of $p$ equals $1$. As a result,
we can use these bits to encode extra information: the encoding format, the point at infinity, and the points' sign.
Read more in sections: Uncompressed/compressed points on curve $E(F_p)$/$E'(F_{p^2})$.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed: 52f9559

@olga24912
Copy link
Contributor Author

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
Copy link
Contributor

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

github-merge-queue bot pushed a commit to near/nearcore that referenced this pull request Jul 4, 2024
Implementation for NEP-488: near/NEPs#488

# Gas Estimation
The test vectors for gas estimation were taken from EIP-2537 and adopted
for our input format:
https://eips.ethereum.org/assets/eip-2537/bench_vectors

- `bls12381_p1_sum_0_100` — the empty input
- `bls12381_p1_sum_50_100` — two points from `G1 addition example input`
form EIP-2537(https://eips.ethereum.org/assets/eip-2537/bench_vectors)
duplicated 25 times.
- `bls12381_p2_sum_0_100` — the empty input
- `bls12381_p2_sum_50_100` — two points from `G2 addition example input`
form EIP-2537(https://eips.ethereum.org/assets/eip-2537/bench_vectors)
duplicated 25 times.
- `bls12381_p1_multiexp_0_100` — the empty input
- `bls12381_p1_multiexp_50_100` — the data from `G1 mul double and add
worst case` from
EIP-2537(https://eips.ethereum.org/assets/eip-2537/bench_vectors)
duplicated 50 times.
- `bls12381_p2_multiexp_0_100` — the empty input
- `bls12381_p2_multiexp_50_100` — the data from `G2 mul double and add
worst case` from
EIP-2537(https://eips.ethereum.org/assets/eip-2537/bench_vectors)
duplicated 50 times.
- `bls12381_map_fp_to_g1_0_100` — the empty input
- `bls12381_map_fp_to_g1_50_100` —
https://github.com/matter-labs/eip1962/blob/master/src/test/test_vectors/eip2537/fp_to_g1.csv
— the first test input duplicate 50 times
- `bls12381_map_fp2_to_g2_0_100` — the empty input
- `bls12381_map_fp2_to_g2_10_100` —
https://github.com/matter-labs/eip1962/blob/master/src/test/test_vectors/eip2537/fp2_to_g2.csv
— the first input duplicate 10 times
- `bls12381_pairing_0_100` — the empty input
- `bls12381_pairing_5_100` — the first pair from `Pairing case for 2
pairs` from
EIP-2537(https://eips.ethereum.org/assets/eip-2537/bench_vectors)
duplicated 5 times.
- `bls12381_p1_decompress_0_100` — the empty input
- `bls12381_p1_decompress_50_100` — some random point duplicated 50
times
- `bls12381_p2_decompress_0_100` — the empty input
- `bls12381_p2_decompress_50_100` — some random point duplicated 50
times

Command for gas estimation (from
`runtime/runtime-params-estimator/emu-cost` folder):
```
cargo run --release --package runtime-params-estimator --all-features --bin runtime-params-estimator -- --home "./tmp_home_dir" --accounts-num 20000 --additional-accounts-num 200000 --iters 1 --warmup-iters 1 --containerize --metric icount
```

Gas Estimation results:
```
Bls12381MapFpToG1Base                                  420_103_750 gas [     3360.83i 0.00r 0.00w] UNCERTAIN (computed in 71.36s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381MapFpToG1Element                            83_940_185_431 gas [   671521.48i 0.00r 0.00w] UNCERTAIN (computed in 398.97s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381MapFp2ToG2Base                                 425_460_312 gas [     3403.68i 0.00r 0.00w] UNCERTAIN (computed in 25.86s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381MapFp2ToG2Element                          296_382_845_775 gas [  2371062.77i 0.00r 0.00w] UNCERTAIN (computed in 306.68s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381PairingBase                                703_330_359_812 gas [  5626642.88i 0.00r 0.00w] UNCERTAIN (computed in 92.34s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381PairingElement                             850_444_740_812 gas [  6803557.93i 0.00r 0.00w] UNCERTAIN (computed in 478.76s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P1SumBase                                    5_329_433_250 gas [    42635.47i 0.00r 0.00w] UNCERTAIN (computed in 27.68s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P1SumElement                                 1_952_367_105 gas [    15618.94i 0.00r 0.00w] UNCERTAIN (computed in 37.53s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P2SumBase                                    6_136_626_312 gas [    49093.01i 0.00r 0.00w] UNCERTAIN (computed in 27.79s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P2SumElement                                 4_920_333_450 gas [    39362.67i 0.00r 0.00w] UNCERTAIN (computed in 54.97s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381G1MultiexpBase                               5_323_237_875 gas [    42585.90i 0.00r 0.00w] UNCERTAIN (computed in 27.53s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381G1MultiexpElement                          303_497_441_743 gas [  2427979.53i 0.00r 0.00w] UNCERTAIN (computed in 1730.00s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381G2MultiexpBase                               6_120_231_625 gas [    48961.85i 0.00r 0.00w] UNCERTAIN (computed in 31.46s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381G2MultiexpElement                          662_703_174_257 gas [  5301625.39i 0.00r 0.00w] UNCERTAIN (computed in 3852.99s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P1DecompressBase                               429_739_937 gas [     3437.92i 0.00r 0.00w] UNCERTAIN (computed in 27.09s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P1DecompressElement                         26_855_436_628 gas [   214843.49i 0.00r 0.00w] UNCERTAIN (computed in 151.64s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P2DecompressBase                               400_538_375 gas [     3204.31i 0.00r 0.00w] UNCERTAIN (computed in 26.52s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
Bls12381P2DecompressElement                         54_577_904_272 gas [   436623.23i 0.00r 0.00w] UNCERTAIN (computed in 264.86s) HIGH-VARIANCE: runtime/runtime-params-estimator/src/utils.rs:354:24
```
github-merge-queue bot pushed a commit to near/nearcore that referenced this pull request Jul 22, 2024
…1818)

Stabilize NEP-488: Host Functions for BLS12-381 Curve Operations

* NEP-488: near/NEPs#488
* Implementation: #9317
@flmel flmel merged commit 32c7029 into near:master Oct 1, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NEP A NEAR Enhancement Proposal (NEP). S-approved A NEP that was approved by a working group. WG-protocol Protocol Standards Work Group should be accountable
Projects
Status: APPROVED NEPs
Development

Successfully merging this pull request may close these issues.