perf: Groth16 verifier

[yelhousni]

Description

currently we do GT == e(a1,b1)*e(a2,b2)*e(a3,b3) using Pair for the triple-pairing, which means computing the multi-Miller loop and then reducing it to a unique value with FinalExponentiation that should match GT from the VerifyingKey.
In this PR I wanted to check if including GT in the pairing computation (triple-pairing becomes quadruple) and using FinalExponentiationCheck (inside PairingCheck) would result in less constraints (using #1143, #1155, #1207).

N.B.:

• We can do better by implementing a QuadruplePairingCheck method that merges the squares of the equivalence check with the Miller loop (similar to perf: optimize DoublePairingCheck i.e. e(a,b)e(c,d) == 1 #1230 but for 4 pairs). I implemented this and it saves 5.7% but add more code to gnark that is only useful for G16 verifier circuit.
• We can keep GT in the VerifyingKey and include it the triple-Miller loop to compute the hinted witness residue. This also should work but again more specialized methods and more lines of code for a single circuit that we probably don't care about much.

Type of change

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

How has this been tested?

Tests pass.

How has this been benchmarked?

BN254-G16 verifier in a BN254 circuit:

• old: 1,455,104 r1cs
• new: 1,390,556 scs
• new (with QuadruplePairingCheck): 1,310,579 scs

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]

Yes, I agree that maybe it is a very specialized method for Groth16 only which we indeed do not care too much about. We can however avoid defining the QuadruplePairingCheck in the algebra.Pairing interface and then explicitly test that the Pairing object implements it and then switch.

But even in this case this means that we have some overhead in the future when we change some implementation etc (to upgrade all the hints etc.), which I think is not probably worth it (or maybe with a comment which says that we can ditch the implementation if it causes any problems in the future, and everything should continue working nicely because we check that we have Quadruple method. And we can have a test which checks that 2*DoublePairingCheck is less efficient than QuadruplePairingCheck).

If it looks good, then let me know, I can add the interface checks etc. But after #1230 is merged.

[yelhousni]

@ivokub I suggest to close this PR since it's not for a very useful use-case right now and it makes the code more complex and the Groth16 verification different that the out-circuit counter part in gnark. Wdyt?

[ivokub]

@ivokub I suggest to close this PR since it's not for a very useful use-case right now and it makes the code more complex and the Groth16 verification different that the out-circuit counter part in gnark. Wdyt?

I agree. Lets close it for now.