Feat: Bandersnatch 4D-GLV (GLV + fake GLV)

[yelhousni]

Description

Using a twofold half-GCD, one in ℤ and one in $ℤ[\sqrt{-2}]$, it is possible to turn a $n$-bit scalar multiplication $[s]P$ on Bandersnatch curve into a $(n/4+9)$-bit MSM of size 4. However the total number of constraints is worse than simple GLV or fake GLV ($n/2$-bit MSM of size 2). This is due to 2 reasons:

• A 2-MSM in-circuit needs Lookup2 while a 4-MSM needs 16-to-1 Mux. In native arithmetic point arithmetic (dbl/add) has a similar cost to Lookup2 while Mux is way costlier. We can use logderiv lookup argument (at the expense of increasing verifier cost) but it's still costlier.
• The 4-dimensional scalar decomposition needs to be verified modulo Bandersnatch order and not the SNARK order. This is done using non-native arithmetic which makes it even costlier.

N.B. This PR is to show the inefficiency of "GLV + fake GLV" in native circuits (e.g. Bandersnatch) compared to the (systematic) "fake GLV" which works for any curve.
When the circuit is non-native (e.g. bn254 in bn254) the "GLV + fake GLV" method is better because then the cost of the Mux is small compared to the (non-native) point arithmetic.

This PR needs Consensys/gnark-crypto#688.

Type of change

• New feature (non-breaking change which adds functionality)

How has this been tested?

Tests in std/algebra/native/twistededwards/curve_test.go.

How has this been benchmarked?

Bandersnatch	2D Fake GLV	4D Fake GLV (Mux)	4D Fake GLV (logderiv)
R1CS	2401	4552	2728
SCS	4712	11027	6811

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules