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).
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).
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 thebellmantypes inside opaque newtype wrappers (to prevent downstream users from trying to verify a Spend proof with the Output proof verifying key, for example; thebellmantypes permit that because Groth16 proof encodings do not explicitly bind to the circuit).In
zcashdwe do batch validation at the Sapling bundle level: https://github.com/zcash/sapling-crypto/blob/d23547f0d3c753b706c6a4fd64456855e153d6b7/src/verifier/batch.rs#L17-L22This works fine after the type changes:
zcashdpasses in whole bundles, and the Spend and Output verifying keys, andsapling-cryptoknows what to do with them.zebradtook 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. Refactoringzebradto 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
BatchValidatorforzcashd, whilezebradcan use them directly (and gain type safety in their batch validation Tower services that is currently missing).