ZKProof Workshop at Zcon1

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.

4 Likes

Hi. Nice work. I would like to have come to this. I think auditing of protocols and circuits is an issue that needs more attention. I’d like to see guidelines for auditors, e.g. patterns to avoid, or to recommend. Also things like hash functions that are considered ‘safe’, or at least a statement about the trade-offs.

2 Likes