Update EIP-2537: Editorial #8274
Conversation
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
| @@ -67,10 +69,10 @@ Twist type: M | |||
| B coefficient for twist c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004 | |||
| B coefficient for twist c1 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004 | |||
| Generators: | |||
| G1: | |||
| H1: | |||
There was a problem hiding this comment.
Just to resolve ambiguity. Because G1 is used for a group of points.
|
If clarifications are in the process, then we should double check (as I no longer remember if it was well covered in the original documents, it was too long ago):
I will check a the original document, but second confirmation will be great Note: if we require(!) and not suggest all implementations to do fast subgroup checks, then actually it will be fine to require inputs to be in the main subgroups (G1/G2) and not just "on curve". Otherwise slow subgroup check via multiplication will ruin gas schedule and make additions expensive |
Both are true in the current document. |
Co-authored-by: Alex Stokes <[email protected]>
EIPS/eip-2537.md
Outdated
| @@ -320,7 +333,8 @@ There are no backward compatibility questions. | |||
|
|
|||
| ### Subgroup checks | |||
|
|
|||
| A subgroup check **is mandatory** during the pairing call. Implementations *should* use fast subgroup checks: at the time of writing, multiplication gas cost is based on the `double-and-add` multiplication method that has a clear "worst case" (all bits are equal to one). For pairing operations, it is expected that implementations use faster subgroup checks, e.g. by using the wNAF multiplication method for elliptic curves that is ~ `40%` cheaper with windows size equal to 4. (Tested empirically. Savings are due to lower hamming weight of the group order and even lower hamming weight for wNAF. Concretely, subgroup check for both G1 and G2 points in a pair are around `35000` combined). | |||
| The subgroup check for point `H` verifies that `H` multiplied by scalar `q` yields the infinity point on the respective curve. | |||
There was a problem hiding this comment.
rather than use this naive expensive subgroup check (in particular for G2) I'd rather suggest to point to https://eprint.iacr.org/2021/1130.pdf
There was a problem hiding this comment.
Can we provide complexity estimates for this method? What is the value of u?
There was a problem hiding this comment.
it's all in the paper. 'u' is the seed for generating BLS12-381 and pretty short ( -0xd201000000010000)
There was a problem hiding this comment.
Yes, you should not require "check by multiplication" only. Whether we should require fast subgroup checks or not is a separate question
There was a problem hiding this comment.
Reformulated the text with your link @asanso
I agree with @khovratovich that the current situation is ambiguous. Moreover, it is even more convoluted than that, as leaving the responsibility to callers to check the subgroup for non-pairing operations opens the door to subtle issues. For example, in order to expedite scalar multiplication, implementers might be tempted (within their rights) to apply GLV endomorphism optimization. However, the problem arises because the GLV is defined and valid only within the 'magic subgroup'. |
|
If no one knows a good reasonable case for explicit wanting to mix-in not-main-subgroup point for non-pairing cases, I can perform some basic gas measurements in case of fast subgroup check. Hopefully costs should not change too much for multiplication and addition since they are dominated by one final inversion |
|
The commit 21f396f (as a parent of ba051b3) contains errors. |
|
The CI validator does not like a link to ePrint. Probably we can ignore this error. |
|
@khovratovich IMHO it would be good to separate the really good editorial changes and typos you corrected from the subgroup check discussion. How about slit this PR in 2 so we could merge the editorial changes/typos first ? |
Edited a few sentences that were ambiguous.
Added the Fp, Fp2, G1, G2 definitions.