**#4 Home Edition**

# Proposal: Practical Groth16 Aggregation

**Moderator:** Daniel Benarroch & Eran Tromer
**Presenters:** Anca Nitulescu and Nicolas Gailly

**Authors:**
- Nicolas Gailly
- Mary Maller
- Anca Nitulescu

To be presented on 2021-04-29.

Resources:
* [Latest PDF version](https://docs.zkproof.org/pages/standards/accepted-workshop4/proposal-aggregation.pdf)
* [Miro whiteboard frame](https://miro.com/app/board/o9J_lJQRFxQ=/?moveToWidget=3074457357481295789&cot=14)
* [Additional related links](https://hackmd.io/@workshop4/links)
* [Related conversation]()

----

## Real-time notes
_Note Taker:_ Daira Hopwood

Q. What is $D$ in the batch verification equations?
A. A constant dependent on the verification key.

Q. Daira: on a previous slide it looked like there were four different "toxic waste" secrets, how do you get that from two ceremonies?
A. No, only two secrets (with two generators each).

Q. Deidre: these are good numbers to keep in mind as we compare batch'd groth16 vs recursive halo2
A. Daira: Don't have full benchmarks yet, but Halo 2 probably better performance. Don't quote me!
A. Mary: Halo 2 probably worse proving, better verification.

Q. Mikhail: Applicability to other pairing-based proof systems?
A. Mary: Random oracle queries in the middle of the proof causes this to fall apart.
A. Mary: You need to have an algebraic structure in the statement being proven in the proof system. Wouldn't apply with less algebraic systems.

Q. Eran: What needs to hold about the statements/instances being proven, for this to be applicable?
A. Nicolas: Extendible to different verification keys in a batch, currently needs to be all the same verification key (i.e., same relation).
Observation. Ariel: in zkRollup, you're rolling up SNARK proofs, and there are 3 types of these. The recursive circuit checks that you're using one of the predefined keys from the set.

Antoine: focussing on block chain systems, but in the context where bandwidth complexity matters, using recursion (esp. with succinct proof system) is optimal.

Nicolas: the aggregator can be any third party.

Daira: For Halo, don't want large arity of recursive verification because you pay linear cost at the end.

Q. Mikhail. What's the security paradigm? Same as Groth16?
A. Daira: goal is to have the same security notion, aggregator is untrusted.

### Whence in ZKProof Standardization?

Daira: Stepping stone: standardize Groth16 batch verification (as already used in Zebra and described in [Zcash protocol spec, Appendix B.2](https://zips.z.cash/protocol/protocol.pdf#grothbatchverify)).

Mary: One layer of recursion. Other protocols use many layers. The two settings are related but different.

Eran: We have some specifications of ZKP schemes out there (e.g. Zcash protocol spec), including serialization formats and reference vectors. Should we start a process where we include these?
A. Daira, Thomas, Antoine: +1
A. Daira: Will be happy to help extracting pertinent parts of the Zcash spec. Including ingredients like curve representations etc. Groth16 itself is not specified in the Zcash spec itself (just referring to the Groth16 paper), just adding batch verification.
A. Antoine: There are flavors of Groth16, depending on use case. For example, on Ethereum you do some modifications so that you only manipulate source group elements (because that's what the EVM supports) at the cost of more ops. So need to standardize the flavor that maks the most sense for applications.

Eran: Possible Groth16 standardization milestones:
1. Vanilla Groth16 (some flavor(s), see above)
2. Add batch verification
3. Add aggregation

Q. Eran: what other sufficiently-concrete specs do we have out there?
A. \<silence\>

Antoine: include the many additional implementation choices that come up, such as sampling randomness.
Daira: yes, easier to implement using a library impl as a reference than from a paper, because the impl includes such considerations.
Deidre, Anca: +1: the paper often leaves out assumptions or decisions an implementor has to make.

Q. Daniel: Should we etablish a WG on Telegram to discuss concrete scheme standardization
A. Anca Nitulescu, Daira Hopwood, AntoineR, Deidre Connolly, Mark Blunden, Mary Maller, Stephen Holmes, Eran Tromer: +1