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