Use prepared Groth16 keys for non-batch Sapling validation

[teor2345]

Motivation

Zebra's Sapling proof validation prepares the validation key every time we do non-batch validation. But the parameter loader also creates a prepared copy of the key.

I think we can verify slightly faster if we re-use the prepared key.

This is related to #322, but it's not required.

Solution

• Stop preparing the same key for every non-batch Sapling proof

This PR is based on PR #3091 to avoid unrelated test failures.

Review

I need a cryptographer to review this change.

@conradoplg if you're not sure, let's wait and ask Deirdre next week?

Reviewer Checklist

• Code change is correct
• Existing tests pass

[conradoplg]

This makes sense, the new values must be the same as the previous ones since they're computed the exact same way.

It would be good for @dconnolly to double check but it looks fine.

zebra/zebra-consensus/src/primitives/groth16/params.rs

Lines 72 to 81 in e5f5ac9

	// Prepare verifying keys
	let spend_prepared_verifying_key = groth16::prepare_verifying_key(&spend.vk);
	let output_prepared_verifying_key = groth16::prepare_verifying_key(&output.vk);
	Ok(Self {
	spend,
	spend_prepared_verifying_key,
	output,
	output_prepared_verifying_key,
	})

[teor2345]

CI failed with a listener conflict in a test with a race condition.

If it happens again, we could:

• increase LAUNCH_DELAY
• disable some acceptance tests in coverage CI

We might also need to:

• reduce the number of proptests using the standard env var
• increase the coverage workflow timeout

[dconnolly]

LGTM!

I also reviewed the updated groth16/params changes in this context 💃

[teor2345]

Oops, I auto-merged this into the wrong branch. I'll admin-merge it to main instead.