backend: add ExportNeoGo for Groth-16 BLS12-381 curve

[AnnaShaleva]

Hello, devs!

First of all, thank you for your amazing zk-SNARK packages! Currently we are adapting them to create and verify Groth-16 BLS12-381 proofs on the Neo blockchain.

PR motivation

We (as developers of Neo node implementation written in Go) are about to add Groth-16 verification support for Neo smart contracts in the upcoming 0.102.0 release. We've successfully adapted your libraries to build an example circuit, generate proof for it and build/invoke Verifier Neo smart contract deployed to the Neo blockchain: nspcc-dev/neo-go@5a19f81. However, to create Verifier contract we have to retrieve paramters of groth16.VerifyingKey via its serialized representation (firstly use vk.WriteTo(&buf) and after that deserialise alpha, beta, gamma, delta and Kvks points from the resulted byte slice, take a look at the lines). It's not very convenient, but at the same time we can't use bls12-381-specific VerifyingKey implementation and directly access these parameters since it's located under the internal subdirectory.

At the same time, I've noticed that exported groth-16.VerifyingKey interface has ExportSolidity method that is supported for BN254 and provides the ability to generate Solidity Verifier contract by gnark library itself.

It would be very helpful for Go smart contract developers of Neo ecosystem to have a similar ExportToNeoGo method which is defined for Groth-16 BLS12-381 curve and iss able to generate Go Verifier contract for Neo blockchain. It allows to reduce the number of steps needed to build Verifier contract for contract developers.

PR content

This PR contains a very initial implementation of VerifyingKey.ExportToNeoGo method that was successfully tested with end-to-end test (the idea of the test is same as for ExportSolidity test in https://github.com/Consensys/gnark-tests/blob/main/solidity/solidity_groth16_test.go). There's a large space for improvement in this PR, but if it's OK for you to add this API, then I'll finish it and fix all the review comments.

The question

Is there any chance that this new VerifyingKey.ExportToNeoGo API will be added to your library?

I'll appreciate any comments and opinions on this topic. Thank you for your time!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[AnnaShaleva]

Here's the end-to-end test of the new VerifyingKey.ExportToNeoGo API: Consensys/gnark-tests#3.

[gbotrel]

hi @AnnaShaleva , thanks for the PR :)

My initial thoughts on that;
The reasons ExportSolidity exists are:

1. While gnark is blockchain agnostic, lots of gnark users are on EVM based chains.
2. Originally, curve specific groth16.VerifyingKey impl were not exposed and hidden in internal packages, so it was cumbersome for an external package to access the curve specific VerifyingKeystruct. This is not the case anymore (on develop branch: https://github.com/Consensys/gnark/tree/develop/backend/groth16), you can directly access the VerifyingKey data struct.
   (3. Convenience for us, since we are maintaining (fixing audit reports etc) the solidity part too.)

TLDR; with 2., I think ExportToNeoGo should not live in gnark repo (will be more convenient for you to maintain).

We are a bit behind on the new release, couple of bug fixes / api coherence (between Groth16 and PlonK) fixes and v0.9.0 should be released 👍

[AnnaShaleva]

@gbotrel, thank you for the reply!

This is not the case anymore (on develop branch)

Well, that solves our problem, we'll be glad to meet the v0.9.0 :)

(will be more convenient for you to maintain)

That's also true, thus, I'm closing this PR as not planned.