Implement verifiers that accept Groth16 types

[dconnolly]

Require bellman or bellman community, validators can accept our Groth16 types and validate them, with batching or without.

https://github.com/ZcashFoundation/zebra/blob/main/zebra-chain/src/proofs/groth16.rs

https://zips.z.cash/protocol/protocol.pdf#groth

[hdevalence]

Because there are multiple proof statements, but only one Groth16Proof type, I think we will have to have each verifier call the bellman API rather than wrapping verification into a Groth16Proof method. So it may make sense to recast this issue as the work required to have all of the infrastructure for using proof verification data.

[hdevalence]

To verify proofs we will need to have some mechanism for loading the verification data. Notes from digging through stuff with @dconnolly:

• Groth16 proof verification is done by bellman::groth16::verify_proof, which takes a PreparedVerificationKey.
• zcash_proofs/src/lib.rs has a load_parameters function, which notes:

  We only deserialize the verifying key for the Sprout parameters, which appears at the beginning of the parameter file

• The sizes of the parameter files are large: sapling-output.params is 3.5M, sapling-spend.params is 46M, and sprout-groth16.params is 692M.
• From looking at the parsing logic, it seems like the verifying key is 3*96 + 3*192 + 4 + n*96 bytes long, with n = 6, 8, 10 respectively. This gives PVK sizes of 1444, 1636, 1828 bytes.

Since we don't ever plan to support Sprout-on-Groth16 proving, we probably don't ever have a reason to ship the 700MB file, and since we will only support transaction creation later, it might make sense to split apart the verification keys from the rest of the parameters (and hardcode them in the source). Then later, when we implement tx creation, we can lazily load the other parameters when we are asked to create transactions.

[hdevalence]

cc @str4d @daira -- is that reasoning correct, or did we miss something?

[daira]

That looks correct to me. (I'm making guesses about the format based on a brief skim of https://docs.rs/crate/bellman/0.6.0/source/src/groth16/mod.rs .)

[howardwu]

Since the Sapling spend and output parameters are of reasonable size, we deployed a crate wagyu-zcash-parameters that allows you to import the Sapling parameters natively into your Rust code. The README gives more context on how we do it (with Crates.io's size limit) and we've added this into wagyu (Sapling transaction tests here) for use (our transaction creation tests are passing)

[howardwu]

As a quick note, the crate currently returns the data as buffers (Vec<u8>) and we verify the hash and construct Zcash semantic data structures in wagyu.

For those who want to replace the load_parameters function in zcash_proofs, they can reference how we do it in wagyu here.

[dconnolly]

Related: #406

[dconnolly]

406

[hdevalence]

Underway in #830

[dconnolly]

Closed in #830