Today at Zcon1, Daniel Benarroch (@daniben31) and I led a workshop about the ZKProof standardization effort, focusing on zkInterface as well as needs that can benefit from zkProof attention going future.
The participants in the latter part were:
and Anna Kaplan (on the other side of the lens).
And our notes, as recorded on the board, edited for clarity:
What do you need, beyond the current ZKProof community reference and draft community standards?
- Deployment
- Modules interop
- Packaging
- Commitments (e.g., for the commit-and-prove pattern common to many ZK schemes and applications)
- Choice of commitment schemes
- Bit-level standardization
- Reductions and serialized formats for instances and witnesses
- Abstracted API (engine descriptions)
- APIs for building blocks (gadget interfaces), .e.g, “give me a set-membership scheme”
- Commit-and-prove
- Benchmarks
- Relate to circuit / constraint system formats used in MPC, FHE and obfuscation
- Application-level interfaces and encapsulation (e.g., “asset transfer”
- Unambiguous naming conventions for schemes
We also discussed the different components of the workflow when using ZK proofs, and that it would be helpful to add a nice diagram showing the data flow between these to the community reference:
- Front-end compiler(s)
- Possibly a chain, including optimization and verification
- Setup
- Witness generation
- Prover
- Verifier
All of these have some of their inputs or outputs covered by zkInterface, but other inputs/outputs, as well as deployment needs, can benefit from more attention.