GLV implementation for BLS12_377, BLS12_381 and BN254

[mmagician]

Description

Updates #147 by @simonmasson to use the slightly improved trait interface from arkworks-rs/algebra#644.

Update:
Benchmarks show that there is a significant improvement for BLS12-377, BLS12-381 (40%, 37% respectively), moderate improvement for BN254 (10%) and a small improvement for Bandersnatch at 2%. The rest perform worse with GLV enabled by default. For the last group I've left the implementation of the GLV trait in, but haven't enabled it by default.
PR title reflects the defaults only.

closes: #147

---

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

[Pratyush]

Why did these generators change?

[Pratyush]

How did the curve coefficients change? That seems fishy.

Regardless, we can use the original short values here, namely:

Suggested change

	MontFp!("52435875175126190479447740508185965837690552500527637822603658699934817984513");
	MontFp!("−3763200000");

[simonmasson]

There were changes on the coefficients in order to optimize slightly one computation.
We should use these new coefficients (matching https://eprint.iacr.org/2021/1152.pdf).
Note that the two curves are isomorphic (same order, etc.), as this SageMath script shows:

p = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001

Fp = GF(p)

HD = hilbert_class_polynomial(-8)

# new coefficients from the commit, can be written using negative numbers
A1 = 52435875175126190479447740508185965837690552500527637822603658699934817984513
B1 = 52435875175126190479447740508185965837690552500527637822603658621262613184513

# previous coefficients from the commit
A2 = 10773120815616481058602537765553212789256758185246796157495669123169359657269
B2 = 29569587568322301171008055308580903175558631321415017492731745847794083609535

E1 = EllipticCurve(Fp, [A1,B1])
E2 = EllipticCurve(Fp, [A2,B2])

assert HD(E1.j_invariant()) == 0
assert HD(E2.j_invariant()) == 0

[Pratyush]

Suggested change

	/// COEFF_A = 52435875175126190479447740508185965837690552500527637822603658699934817984513
	/// COEFF_A = -3763200000

[Pratyush]

Suggested change

	MontFp!("52435875175126190479447740508185965837690552500527637822603658621262613184513");
	MontFp!("-78675968000000");

[Pratyush]

Suggested change

	/// COEFF_B = 52435875175126190479447740508185965837690552500527637822603658621262613184513
	/// COEFF_B = -78675968000000

[Pratyush]

Hm, inverting in the endomorphism seems to defeat the purpose, no? The endomorphism is supposed to be fast.

[Pratyush]

I see, the endomorphism is fast in the Edwards form.

[Pratyush]

Since the endomorphism is slow here, we should just use the normal scalar multiplication.

[Pratyush]

In fact, could we adapt #102 for this task? That constructs GLV multiplication for the TE form directly, and should get the expected speed up

[Pratyush]

(We could do that in a follow up PR)

[mmagician]

@Pratyush I'm thinking to just pull out the Bandersnatch changes into a separate PR, as I don't know why a new parameter set is used. Maybe later @simonmasson can add more details on this change, but I think we should move forward with the rest for now, WDYT?

[mmagician]

@asanso maybe you can shed some light on the new parameters as we discussed today?

[Pratyush]

@mmagician Handling Bandersnatch in a different PR seems reasonable!

[mmagician]

The failing tests for curves with GLV enabled should be fixed when #171 is merged.
As explained there, overriding mul_projective with the new GLV implementation forces the scalars passed to be at most MODULUS (in particular, at most N limbs), and otherwise panics upon conversion from more than N limbs. This is a breaking change, and maybe we should think about a way to either 1) impose the same behaviour for non-GLV implementations 2) change the trait signature to directly receive a Scalar 3) distinguish the two cases here and handle appropriately.