Create and standardize a non-native registry contract for SNARK verification parameters

[EdgeDLT]

In most blockchain ecosystems that use zero-knowledge proofs, a zkdApp developer will often deploy its own verifier contract which hardcodes circuit-specific parameters used for proof verification. A new circuit (even a new version of the same circuit) means a new verifier to be deployed. Lots of time, GAS, and plenty of room for things to go wrong.

ZKP support on Neo N3 is still nascent, but we are likely going to follow along the same tracks and have a chance to get ahead of the problem.

My suggestion is that we design and standardize a registry contract as a non-native utility, akin to NeoNS. It would store circuit-specific verification data (the four curve points and independent commitments) for a given circuit. This data would be retrieved using a circuit identifier and version number.

In N3 ZK tooling, such as NeoGo's zkpbinding package, after a circuit has been setup and verifier/prover keys generated, developers should be prompted to submit the verification elements to the registry, rather than pay to deploy another copy of the verifier logic with this information hardcoded (e.g. as currently in zkpbinding.GenerateVerifier).

To verify a proof, the dApp would call verifyProof on the registry contract directly, providing the circuit identifier and version number alongside the proof.

Simple example implementation

[AnnaShaleva]

Just for the record: as I said earlier in Discord, I agree that having such non-native contract would be beneficial for both Neo and Neo users, because it's more convenient, it doesn't cost a lot to the end-user and provides better user experience (user only have to store verification parameters instead of generating/deploying/maintaining verification contract by himself).

The only concern from my side is why other blockchain projects don't use this approach with a standard registry contract. The only thing that came to my mind is that the problem is in trust: this contract is responsible for verification of important paths, and if this contract is managed by some single outside entity, then it may be too risky for on-chain projects to put their trust into this contract - and here we are, every project wants to deploy its own contract. Thus, I'd like to ask anyone who has an expertise in this topic to name the reason why other chains don't use this approach with a single verification registry.

As an example of verification contracts autogen for other chains, here's a set of Solidity verification contract templates for different proving algorithms provided by consensys/gnark toolchain: https://github.com/Consensys/gnark/blob/fdb2b0de422b1c4fc5c6d08e81e788095ac818a6/internal/generator/backend/main.go

[vncoelho]

I think this can be native or non-native. It is a set of standard parameters.

[AnnaShaleva]

I doubt it should be native. I’m thinking of some standard deployed contract managed by committe.

The main question from my side here is:

name the reason why other chains don't use this approach with a single verification registry.

[cschuchardt88]

name the reason why other chains don't use this approach with a single verification registry.

Registry could have a bug or get compromised

[EdgeDLT]

For me, the native vs non-native discussion comes down to necessity.

Do you need StdLib, Policy, and Ledger contracts in every single Neo blockchain instance? Yes, certainly.

Do you need NeoNS or a SNARK registry? No, probably not, and if you really do, you can just deploy it.

Not sure how core currently distinguishes when to go native or not, but seems to me that this is more appropriate as a deployed service for public networks.