Generic pairings for BW6

[swasilyev]

Part of the project of getting BW6-767 the outer curve for BLS12-381 into arkworks, supersedes (fixes) #624

Implements pairings for the BW6 family in a generic way, following https://yelhousni.github.io/phd.pdf, section 4.4.2

1. Introduces generic BW6 curve parameters: CM lifting cofactors and "trace modulo r"
2. Makes the existing miller loop implementation support both BW6-761 and BW6-767. It conflicts with Bw6 miller loop optimization #617. I suggest we adapt the latter later.
3. Implements the hard part of the final exponentiation in generic way for curves with "trace modulo r" = 0 (this is BW6-767)
4. The existing hand-optimized hard part for BW6-761 moved to the curve specification.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the GitHub PR explorer

[swasilyev]

A fun observation. In the Miller loop computation we are currently free to get rid of

        if Self::ATE_LOOP_COUNT_1_IS_NEGATIVE {
            f_1.cyclotomic_inverse_in_place();
        }

For BW6-761 nothing changes as it has X > 0. BW6-767 isn't used afaik, so we have freedom here. @yelhousni wdyt

[mmagician]

The existing hand-optimized hard part for BW6-761 moved to the curve specification.

That's still missing right? Would be good to have that PR open for this to test too, at least locally.

Edit: NVM, just saw this in the 767 PR too.

[swasilyev]

Surprisingly, on my machine

Generic implementation:

Pairing for BW6_761/Final Exponentiation for BW6_761
time: [2.9952 ms 3.0381 ms 3.0840 ms]

Curve specific one:

Pairing for BW6_761/Final Exponentiation for BW6_761
time: [3.1242 ms 3.1320 ms 3.1402 ms]
change: [+1.5416% +3.0911% +4.6056%] (p = 0.00 < 0.05)
Performance has regressed.

what slightly contradicts https://hackmd.io/@gnark/BW6-761-changes#Final-exponentiation. Moreover, the addition chains optimization (#634) is less applicable to the curve specific implementation.

The question then is if we want to support curve-specific final exp implementation for BW-761 for compatibility reasons? The results of the pairing computation will be different, but I don't know any project that would use it for smth other than bilinearity, that still holds.

[swasilyev]

Thank you for the review @mmagician Really exciting findings!

[mmagician]

Looks good 👍🏼

[mmagician]

@swasilyev On second thoughts this should go into breaking changes not features section in the CHANGELOG, WDYT?

[swasilyev]

Btw, i think that currently the change is not breaking, as i moved the existing curve-specific implementation to the curve definition in arkworks-rs/curves#156. Though i would remove it later in another pr.

[Pratyush]

I think it's still a breaking change because defining a BW6 curve now requires specifying more constants.

[mmagician]

@swasilyev I think the last part is to move the CHANGELOG entry from features to breaking changes: I agree with Pratyush that is indeed a breaking change on the API.