feat: BN254 pairing

[ivokub]

This PR adds pairing on BN254. The interface which is made public is small, but in general includes G2 and GT operations.

[gbotrel]

note on perf; compile time for R1CS is slowww, and mostly, due to known issues.

1. Lots of assertboolean, that adds DebugInfo which is stored in a .. less than ideal way. Will fix.
2. frontend.Capacity option is not implemented post-refactor PR, will fix, it will help too.
3. The more unknown is that it seems garbage collection is very active, will have to do a pointer hunt.

[ivokub]

note on perf; compile time for R1CS is slowww, and mostly, due to known issues.

1. Lots of assertboolean, that adds DebugInfo which is stored in a .. less than ideal way. Will fix.
2. frontend.Capacity option is not implemented post-refactor PR, will fix, it will help too.
3. The more unknown is that it seems garbage collection is very active, will have to do a pointer hunt.

So, rebased on top of develop and compile time is still slow (a few minutes), but doable. I did a profile but there wasn't anything very particular. There is a lot of work in assertIsBoolean, but this is to be expected (this PR is not using range checking yet. When range checking is merged then will start natively use them).

Added documentation and examples.

[yelhousni]

LGTM. It seems a mutatis-mutandis translation of the BN254 pairing in gnark-crypto, which is working fine. There are couple of circuit-specific optimisations that I started on a different PR. Also I'm thinking of how to do the infinity points filtering in-circuit or just proceed them (as the MultiMillerLoop is what is needed in the ECPAIR precompile). For the record, so far:

• MillerLoop:
  Groth16 9.9M / Plonk 24.9M
• FinalExp:
  Groth16 11.4M / Plonk 29.4M

[yelhousni]

@ivokub One more thing, I would like to reorganise the packages a bit: sw_bls12377 and sw_bls24315 include the pairing computations while for emulated field there is weierstrass package for G1 arithmetic (including BN254) and then pairing_bn254 for the pairing, g1, g2, gt and tower. I would suggest to rename weierstrass to sw_emulated and rearrange pairing_bn254 into sw_bn254 and fields_bn254. I'll do that in the optimisation PR if you don't have any objection to this.

[ivokub]

@ivokub One more thing, I would like to reorganise the packages a bit: sw_bls12377 and sw_bls24315 include the pairing computations while for emulated field there is weierstrass package for G1 arithmetic (including BN254) and then pairing_bn254 for the pairing, g1, g2, gt and tower. I would suggest to rename weierstrass to sw_emulated and rearrange pairing_bn254 into sw_bn254 and fields_bn254. I'll do that in the optimisation PR if you don't have any objection to this.

I'm OK with that. At some point I tried to make the towers more general, but got a bit stuck with non-ideal type inference in Go generics. But it should get better with Go 1.21 and maybe then would make more sense. Right now I wouldn't generalize too much. I had at some point idea to implement BLS12-381 as it is asked for, I'll try it then.

What do you think about having something like algebra/native and algebra/nonnative (or nativealgebra, emulatedalgebra etc). I'd prefer users wouldn't confuse two different approaches for recursion, especially that it is possible to have very efficient 2-chain recursion.

[yelhousni]

What do you think about having something like algebra/native and algebra/nonnative (or nativealgebra, emulatedalgebra etc). I'd prefer users wouldn't confuse two different approaches for recursion, especially that it is possible to have very efficient 2-chain recursion.

Totally agree. That's the best way to go.