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

BLS12-377 curve operations #2539

Merged
merged 6 commits into from
Sep 22, 2020
Merged

Conversation

shamatar
Copy link
Contributor

This EIP adds a set of precompiles to efficiently implement operations over BLS12-377 curve

EIPS/eip-2539.md Outdated

To encode points involved in the operation one has to encode elements of the base field and the extension field.

Base field element (Fp) is encoded as `48` bytes by performing BigEndian encoding of the corresponding (unsigned) integer. Corresponding integer **must** be less than field modulus.

Choose a reason for hiding this comment

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

@shamatar to be compatible with 32-byte 'words' of the EVM/Solidity (and to allow easy mload and mstore operations of 32-byte values in assembly), perhaps elements of Fp should be encoded as 64 bytes instead?

The first 16-bytes could be enforced to be all zeros, or ignored by the builtin contracts.

It'd be great to get your thoughts.

EIPS/eip-2539.md Outdated

Base field element (Fp) is encoded as `48` bytes by performing BigEndian encoding of the corresponding (unsigned) integer. Corresponding integer **must** be less than field modulus.

For elements of the quadratic extension field (Fp2) encoding is byte concatenation of individual encoding of the coefficients totaling in `96` bytes for a total encoding. For an Fp2 element in a form `el = c0 + c1 * v` where `v` is formal quadratic non-residue and `c0` and `c1` are Fp elements the corresponding byte encoding will be `encode(c0) || encode(c1)` where `||` means byte concatenation.

Choose a reason for hiding this comment

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

@shamatar perhaps elements of Fp2 could be 128 bytes, to enable easier field arithmetic in solidity (since real and 'imaginary' coefficients could each be stored in a uint[2] or bytes32[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.

I’ll make similar adjustments to 2537 and will largely copy-paste and updated spec here

@github-actions
Copy link

github-actions bot commented Sep 8, 2020

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Sep 8, 2020
@prestwich
Copy link

@shamatar We are considering this EIP for inclusion in Celo Blockchain. Has thought been given to updating the precompile list with map to group operations in order to match the #2537 API?

@github-actions github-actions bot removed the stale label Sep 14, 2020
@shamatar
Copy link
Contributor Author

Sure, but I'm not aware of mapping parameters for BLS12-377. The easiest way is to copy-paste #2537 text in here while keeping the curve parameters

@prestwich
Copy link

I don't know that it's strictly necessary for anyone's use case. But it would be nice to have direct feature parity with the other precompile

Copy link
Contributor

@MicahZoltu MicahZoltu left a comment

Choose a reason for hiding this comment

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

Looks good! I left some feedback that I encourage checking out but nothing that blocks merging as a draft.

---

## Simple Summary
This precompile adds operation on BLS12-377 curve (from Zexe paper) as a precompile in a set necessary to *efficiently* perform operations such as BLS signature verification and perform SNARKs verifications. Unique properties of BLS12-377 also later allow to have SNARKs that check BLS12-377 pairing in an efficient way and allow e.g. constant-size BLS signature aggregation.
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove "from Zexe paper". This is a technical document, not a place to give props/kudos/attribution. If you think that the paper is particularly relevant, I recommend adding it to ../assets/eip-2539/zexe-paper.pdf and linking to it in a place where it makes sense that a future reader of this specification would care.

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
This precompile adds operation on BLS12-377 curve (from Zexe paper) as a precompile in a set necessary to *efficiently* perform operations such as BLS signature verification and perform SNARKs verifications. Unique properties of BLS12-377 also later allow to have SNARKs that check BLS12-377 pairing in an efficient way and allow e.g. constant-size BLS signature aggregation.
Adds BLS12-377 curve operations as precompiles.

Simple summary should be a very terse one-line description. Longer than the title, but not meant to convey much information and instead let the reader quickly identify "am I in the right place?". This may show up in a sub-heading somewhere for example. The rest of this should probably go in the motivation, as it is is discussing why this is useful/interesting.


Multiexponentiation operation is included to efficiently aggregate public keys or individual signer's signatures during BLS signature verification.

### Proposed addresses table
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
### Proposed addresses table
### Addresses Table

EIPs don't propose, they assert.

|BLS12_377_PAIRING | 0x19 |

## Motivation
Motivation of this precompile is to add a cryptographic primitive that allows to get 120+ bits of security for operations over pairing friendly curve compared to the existing BN254 precompile that only provides 80 bits of security. In addition it allows efficient one-time recursive proof aggregations, e.g. proofs about existence of BLS12-377 based signature.
Copy link
Contributor

Choose a reason for hiding this comment

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

Consider adding some of the stuff from Simple Summary to here. This is a great place to tell users why this EIP is a useful standard.

x is negative = false
```

#### Fine points and encoding of base elements
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
#### Fine points and encoding of base elements
### Fine points and encoding of base elements

You skipped ### here, this can sometimes break some rendering systems particularly when they try to render table of contents.

Copy link
Contributor

Choose a reason for hiding this comment

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

Same thing with all of the following sections, they are all 1 too deep.


Curve parameters:

BLS12-377 curve is fully defined by the following set of parameters (coefficient `A=0` for all BLS12 curves):
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
BLS12-377 curve is fully defined by the following set of parameters (coefficient `A=0` for all BLS12 curves):
[BLS12-377](../assets/eip-2539/bls12-377.pdf) curve is fully defined by the following set of parameters (coefficient `A=0` for all BLS12 curves):

This would be a good spot to have a relative link out to an attachment of the BLS12-377 paper. (note: if you accept this comment, make sure to actually add the paper as an asset!)

## Backwards Compatibility
There are no backward compatibility questions.

## Important notes
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a non-standard section, and while non-standard sections aren't technically disallowed we prefer they not be included so the repository remains consistent. Can we move this into a subsection of the specification? It feels pretty specification like to me, though I suppose it is really just a "pro-tip".

type: Standards Track
category: Core
created: 2020-02-26
requires: 1109, 2046
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
requires: 1109, 2046

Why are these required? It feels like a chain who doesn't have these implemented would still be able to include this EIP.

@MicahZoltu MicahZoltu merged commit ac73014 into ethereum:master Sep 22, 2020
tkstanczak pushed a commit to tkstanczak/EIPs that referenced this pull request Nov 7, 2020
Adds BLS12-377 curve operations as precompiles.
Arachnid pushed a commit to Arachnid/EIPs that referenced this pull request Mar 6, 2021
Adds BLS12-377 curve operations as precompiles.
@rdubois-crypto
Copy link

Sidenote: the divisibility of (p-1) by 2^44 in BLS12-377 Fp field could also benefit to Starks (PQ-snarks), as the FRI requires NTT operations to interpolate the trace polynomial. https://vitalik.ca/general/2017/11/22/starks_part_2.html.

@burdges
Copy link

burdges commented Sep 19, 2023

It's not discussed here, but..

IRTF hash-to-curve spec says Edwards curves should use Elligator for their hash-to-curve, not WB or SWU. BLS12-377 should fall under this, given it has an Edwards form (and an extremely prominent one).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants