Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create specific types for batch-verifying Spend and Output proofs separately #136

Open
str4d opened this issue May 1, 2024 · 0 comments

Comments

@str4d
Copy link
Contributor

str4d commented May 1, 2024

When extracting the Sapling types back into sapling-crypto, we added more type safety. In particular, we made the proof verifying keys typesafe by placing the bellman types inside opaque newtype wrappers (to prevent downstream users from trying to verify a Spend proof with the Output proof verifying key, for example; the bellman types permit that because Groth16 proof encodings do not explicitly bind to the circuit).

In zcashd we do batch validation at the Sapling bundle level:

pub struct BatchValidator {
bundles_added: bool,
spend_proofs: groth16::batch::Verifier<Bls12>,
output_proofs: groth16::batch::Verifier<Bls12>,
signatures: redjubjub::batch::Verifier,
}

This works fine after the type changes: zcashd passes in whole bundles, and the Spend and Output verifying keys, and sapling-crypto knows what to do with them.

zebrad took a different approach, creating independent Tower services for batch-verifying Spend proofs and Output proofs (and every other authorization part). The type safety changes break this use case. Refactoring zebrad to verify only at the bundle level is not feasible (and maybe has a performance impact, IDK).

We should expose individual batch validation types for Spend and Output proofs individually. We can then use them internally to BatchValidator for zcashd, while zebrad can use them directly (and gain type safety in their batch validation Tower services that is currently missing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant