ZKProof - The Zero-Knowledge Community Forum

Breakout Session: ZKProof Proceedings and Community Reference


This session was about reviewing the existing proceedings from the first workshop - see zkproof.org/documents.html

Short abstract: in this session we aim to review the documents, as well as the newly drafted Community Reference, which is a LaTeX version of the proceedings (thanks @Luis!). We will discuss 3 different topics, to be decided by the participants during the session.

NIST also took the time to create a detailed list of comments around the Reference document.

Here are the slides of the presentation about the editorial process: https://docs.google.com/presentation/d/1_W5qEkAxJtB86KbJNhQl8C65NplHjm-_hVt7ZI7VboM/edit?usp=sharing

And see this folder for all the ZKProof public documentation

For all note taker, here is the view only document for SCRIBES:

Again, here is the LaTeX PDF of the ZKProof Reference Document v0.1:

ZKProofCommunityReference (1).pdf (790.4 KB)


Here are my notes from the session:

Moderators: Luis Brandao and Daniel Benarroch
Scribes: Daniel Benarroch and Eduardo Moraes

General Notes

Overview of the comments by NIST (attached):

  • How to bring all the comments into the Reference document?
  • Want larger audience and contributors to help

R1CS vs Circuits

  1. Could be useful to have more clear description of r1cs representation and how it is mapped to and from circuits, as well as advantages over other representations.
  2. Better linkage on R1CS
  3. Follow comments in PDF by NIST

Comment on Taxonomy: QAP vs linear-PCP

  1. Succinctness and efficient verification is an important topic, which is only achieved by QAP (within all linear-PCPs)
  2. The Reference document should give QAP as an instantiation and not as an abstraction
  3. Not clear that any general linear PCP has specific properties that are useful for some constructions
  4. “Would like to see a comment that this is only efficient example”


  1. Not all gadgets are about SNARKs
  2. There are many gadgets (Proof for Shuffle) that are not necessarily related to SNARKs / NIZK
  3. Should we add a table about gadgets that are represented for non-generic proving systems
  4. Also, there are ways to optimize the gadgets, but hard to minimize the size of a circuit
  5. Instead, there is out-of-the box functionality
  6. Gadgets table is more about
1.Canonical use-cases for creating circuits
2.These are “functions” that you can call in programming language”
3.Can be seen from the point of view of composability (this is a concer, there is also many primitives that allow for composability)
4.This table is about standardization
5.Can also be seen as the specific protocols
6.Used for building specific applications

Composability: who’s responsibility is it?

  1. Implementation who implements the primitives,
  2. Applications since they compose them into circuit application
  3. Security since they need to define the actual security

Comment on audience of document and specific documentation (who is the reader of this?)

  1. Handling witnesses and private info - using legacy technology
  2. Building use-cases (companies and biz people not easy to read)

Branch out general constructions?

  1. Approaches for general functionality
  2. For some gadgets can use specialized primitives

Suggested Contributions

Specific Contribution / Action Point

Name Contribution / Action point
Mariana Raykova QAP vs Linear PCP efficiency and instantiation
Luis Brandao Specific comments integration from NIST
Eduardo Morais Motivation and reference of the applications (NIST Comment C12, C16)
Eduardo Morais Gadgets improvement table (NIST comment C13)
Armando Fac NIST C20
Daniel Benarroch Describe better gadget purpose / functionality (start discussion of scope)
Daniel, Angela Applications need to be better explained and worked on, as well as the predicates
Angelo de Caro How to integrate legacy technology to applications in ZK (lego SNARK?)

Sorry if I mispelled any name…(?)