Breakout Session: ZKProof Proceedings and Community Reference

This session was about reviewing the existing proceedings from the first workshop - see

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:

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…(?)

In early April 2019 the NIST-PEC team (“crypto-privacy at nist dot gov”) produced a PDF document with “NIST comments on the initial ZKProof documentation”. These comments were briefly presented during the “ZKProof Proceedings and Community Reference” session at the 2nd ZKProof workshop, and have since then been available online (find link in the initial post in this thread).

This post enumerates the titles of the comments (C1,…,C22 and D1,…,D7) and associates with each item a corresponding short note indicating needed or/and volunteered contributors.

Please consider volunteering to address the several items that indicate “needs contributors” — post a comment mentioning which item(s) you propose to contribute to, and/or send an email to “editors at zkproof dot org” with any question or comment.

The notes below may be updated as more contributors are identified.


  • C1. REFERENCE DOCUMENT: the initial draft is already available; the editors will integrate the new contributions.

  • C2. RECOMMENDATIONS AND REQUIREMENTS: the editors will identify and highlight proposed “recommendations” and “requirements” already contained in the initial draft; other contributors are welcome to suggest additional “recommendations” and “requirements”.

  • C3. SCOPE OF THE CREATIVE COMMONS LICENSE: the “CC-BY-4.0” mention is already in the cover of the initial draft (version 0.1); the editors will promote clarity about the license in the new version of the reference document.

  • C4. GLOSSARY: the editors will complement the current glossary with terms already described in the reference document; other contributors are welcome to suggest new entries.

  • C5. EXECUTIVE SUMMARY: the PEC team volunteers as contributor.

  • C6. EXAMPLES: needs contributors.


  • C7. PROOFS OF KNOWLEDGE: the PEC team proposes adding some text; other contributors are welcome.

  • C8. CONCURRENCY: needs contributors.

  • C9. TRANSFERABILITY: some contributors are identified in the “interactive ZK” session.

  • C10. CIRCUITS VS. R1CS: needs contributors.

  • C11. COMMON VS. PUBLIC: the PEC team proposes adding some clarification text; other contributors are welcome.


  • C12. MOTIVATION: one contributor is identified in the “Community Reference” session (see post above).

  • C13. GADGETS: one contributor is identified in the “Community Reference” session (see post above); more contributors are welcome.

  • C14. INTERACTIVITY VS. TRANSFERABILITY: some contributors are identified in the “interactive ZK” session.

  • C15. IMPLICIT SCOPE OF USE-CASES: needs contributors.

  • C16. REFERENCES: one contributor is identified in the “Community Reference” session (see post above); more contributors are welcome.


  • C17. BACKEND CHOICE NIZK-R1CS: needs contributors.

  • C18. COMPUTATIONAL SECURITY PARAMETER: the PEC team proposes to contribute with some text (likely to suggest changing 120 to 128).

  • C19. STATISTICAL SECURITY: some contributors are identified in the “interactive ZK” session.

  • C20. SIDE-CHANNELS: one contributor is identified in the “Community Reference” session (see post above);

  • C21. VALIDATION: needs contributors.

  • C22. INTELLECTUAL PROPERTY: the PEC team proposes to contribute with some text.


  • D1. TITLE; - D2. PURPOSE; - D3. AIM; - D4. SCOPE; - D5. FORMAT: the editors will consider integrating the proposed elements in the preamble of the reference document.

  • D6. EDITORIAL METHODOLOGY: a proposal was presented during the “ZKProof Proceedings: Review & Process” session at the 2nd ZKProof workshop; the editors will write a corresponding description and submit it for review by the community.

  • D7. INITIAL COMPILATION: already done (draft version “0.1”) and made available.

1 Like


The file ZKProof-PEC-contribs-from-draft-0.1-to-0.2–v20191010.pdf (1.9 MB) (updated Oct 10, 2019)
contains the “NIST-PEC contributions to advance the draft ZKProof Community Reference from version 0.1 to 0.2”.

All contribution items relate to “Issues” previously opened in the ZKProof GitHub repository, and also to earlier “NIST comments on the initial ZKProof documentation” (see post above).

The items address the following seven topics:

  • Intellectual property (Issue #5; C22)
  • Executive summary (Issue #1; C5)
  • Proofs of Knowledge (Issue #2; C7)
  • CRS public or not (Issue #4; C11)
  • Computational security (Issue #3; C18)
  • Statistical security (Issue #10; C19)
  • Transferability (Issue #6; C9)

We welcome feedback.

1 Like