Perf: save some negations in emulated pairings

[yelhousni]

Description

@feltroidprime pointed out this morning that pre-computing -x/y in emulated pairings would save lines negations at each double/add step in the Miller loop. While it shouldn't in native fields, the idea is interesting for emulated fields. I tried this for 2-chains and emulated BN254 and BLS12-381:

• For 2-chains it does not save anything for both Groth16 and Plonk, as expected.
• For emulated pairings however, the results are a bit weird because of how field emulation works (@ivokub any explanation?):
  • For BLS12-381, it does not save anything in Groth16.
  • For BN254, we lose -385 constraints in Groth16.

However this PR is worth it for Plonk because the addition gates are not free. We save 5960 constraints for BLS12-381 and 2896 for BN254. I applied the changes to 2-chains as well, to homogenise the implementations in native and emulated packages.

Type of change

Please delete options that are not relevant.

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

How has this been tested?

Please describe the tests that you ran or implemented to verify your changes. Provide instructions so we can reproduce.

• Test suite for native and emulated packages.

How has this been benchmarked?

Benchmarks on fixed and variable input pairings of different sizes (1 to 10).

• Benchmark, on Macbook air M1

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

[ivokub]

• For emulated pairings however, the results are a bit weird because of how field emulation works (@ivokub any explanation?):

Yes, I would assume this is due to how field emulation works. When we negate then we increase the overflow of the limbs (because we have to add the subtraction padding to avoid underflowing individual limbs). When the overflow is larger, then we may hit the amortized reduction (for additions) sooner and we have to carry bigger partitions in the equality check.

[ivokub]

I think there is a duplicate line in bn254 precomputation. Otherwise looks good.

PS, if you removed the benchmark from bls12377, then maybe also remove it from bls24315? It is not a proper benchmark anyway (doesn't depend on the number of loops).

[ivokub]

LGTM