Asynchronous Groth16 verification

[hdevalence]

This PR is the first step in getting a groth16 proving system fully integrated with the rest of zebra. This PR implements the initial async API, but none of the actual batching logic necessary for our eventual verifier design.

Once the batch verification API from bellman has been implemented we will need to swap out the "Batch" type defined in this crate with the new batch::Verifier defined in bellman.

Follow Up Work

• Integrate Spend and Output async groth verifiers with transaction verifier #1645
• Batch Verification API zkcrypto/bellman#59

[hdevalence]

Rebased onto main with changes from #821

[hdevalence]

Using a WIP branch on the ZF fork of librustzcash for now. Unsure whether it's better to create an intermediate step of having the batch verification API do single verification internally or just go directly to what we want, but I'm leaning towards the latter, since we already know (from the Ed25519 and Redjubjub cases) that an async API with this shape will work.

Now leaning towards a middle option, to create a fake-batch branch that uses the batch verification interface currently defined but internally implements batch verification by calling single verification N times. This lets us reuse the interface, the item types, etc., and we can swap out the math later when we have more time.

[dconnolly]

It builds!

[dconnolly]

@yaahc I moved to 'ready for review' to get the other CI jobs running, you can move back if you want EDIT: i can trigger those jobs without moving from draft

[dconnolly]

@yaahc I rebased because of a conflict related to a bls12 dependency update

[teor2345]

As far as I understand, this code looks good.

But it's hard to review without:

• a PR description that explains the current purpose of this PR
• doc comments on functions and types
• tests

I don't want to block this ticket

[teor2345]

If we're planning multiple PRs that change the same code, let's leave the doc comments until the later PRs, so we don't accidentally delete or revert any more comments.

[yaahc]

If we're planning multiple PRs that change the same code, let's leave the doc comments until the later PRs, so we don't accidentally delete or revert any more comments.

@teor2345 is this resolved btw? I assumed you meant "lets leave adding the doc comments until the later PR" but it never got approved after I did the rest of the cleanup so now I'm unsure if there's still something left for me to do on this PR.

[dconnolly]

I wonder if we should merge this now, knowing that when zkcrypto/bellman#59 is merged in there will be changes anyway, or try to support this pattern now

[yaahc]

I wonder if we should merge this now, knowing that when zkcrypto/bellman#59 is merged in there will be changes anyway, or try to support this pattern now

I think merge personally, the PR is already setup to make it easy for the follow up bellman stuff, I don't see any reason to block this PR on it. As for the static verifiers, I think it might be good to add those with the PR that also adds the PreparedVerifyingKeys, since each static will need to hold a reference to a different key.

[dconnolly]

Merging, tracking followup work in #1645

[teor2345]

If we're planning multiple PRs that change the same code, let's leave the doc comments until the later PRs, so we don't accidentally delete or revert any more comments.

@teor2345 is this resolved btw? I assumed you meant "lets leave adding the doc comments until the later PR" but it never got approved after I did the rest of the cleanup so now I'm unsure if there's still something left for me to do on this PR.

I've been focused on other work.

Last time I checked this PR, it was unclear how much work was remaining, so I couldn't really approve it. So the best I could do was dismiss my review so I wasn't blocking it.