perf: use G2 precomputed lines for Miller loop

[ivokub]

Description

This PR adds G2 line precomputations as in #874, #925, but initialized lazily and embeded inside G2 element. This lazy computation allows to have all the benefits of using ML with precomputed lines, but without having to change the existing interfaces and allowing for some inputs be provided using lines and other as points (as needed in Groth16).

Additionally, added a way to fix the verification key completely inside the circuit. This provides less versatility than providing the verification key as a witness, but allows for considerable decrease in the number of public witness elements, which matters for Solidity verifier. The decrease of constraints due to fixing VK inside circuit is not substantial compared to providing precomputed lines as our non-native arithmetic is still not sufficiently flexible to handle all cases of operations with constant arguments.

This PR is still not complete - the precomputations and witness assignments are implemented only for BW6-761 currently as it is most critical for our use cases. But I think extending the approach to BLS12-377 first and then to other curves is fairly straightforward. It is not copy-paste though as we have different extension towers and optimisations for line computations.

Type of change

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

How has this been tested?

• TestPairFixedTestSolve - Miller Loop with input G2 element with precomputation
• TestKZGVerificationEmulated3ConstantVk - constant KZG verification key
• TestKZGVerificationEmulated3Precomputed - witness KZG verification key with precomputation
• TestBW6InBN254 - witness G16 verification key without precomputation
• TestBW6InBN254Precomputed - witness G16 verification key with precomputation
• TestBW6InBN254Constant - constant G16 verification key

How has this been benchmarked?

All cases BW6 key emulated in BN254. R1CS constraint system. Decreasing order "no precomputation" -> "precomputed as witness" -> "precomputed as constant":

• KZG verification 5389344 -> 4087448 -> 4066748
• Groth16 verification 6086776 -> 4839928 -> 4748682

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]

I haven't run the full set of benchmarks, but I think the initial results are indicative. Verifying Groth16 over BW6 in BN254 emulated using R1CS I have the decrease from 6086776 constraints to 4748682. This is the case when the verifying key is fully constant.

Additionally, this construction allows for the case of providing precomputed lines as a witness. This is a bit more versatile, allowing to verify different circuits, but then would have to figure out how to provide precomputed lines verifiably. If we provide them as a secret witness, then the outer prover could cheat, but providing as public witness adds 18k elements to public witness. In that case the circuit size is 4839928.

Similarly, for KZG verification only have 5389344->4087448->4066748 constraints.

[ivokub]

@yelhousni - I currently have implemented only for BW6-761 as imo this is most critical for PLONK compression BW6-761->BN254 (currently at 80M constraints without this PR). We could try to implement for all curves (second priority for BLS12-377), but I would rather try to merge this quickly and then do other curves separately in other PR.

[yelhousni]

This is a great refactoring! it takes away the necessity to understand the fixed-arg vs. variable-arg pairing implementation for a user. Great job! I think we can merge and then add the other curves.