-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Conversation
Make even with master
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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]).
There was a problem hiding this comment.
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
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. |
@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? |
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 |
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 |
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
### 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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#### 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.
There was a problem hiding this comment.
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): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Adds BLS12-377 curve operations as precompiles.
Adds BLS12-377 curve operations as precompiles.
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. |
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). |
This EIP adds a set of precompiles to efficiently implement operations over BLS12-377 curve