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.
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
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.
Better linkage on R1CS
Follow comments in PDF by NIST
Comment on Taxonomy: QAP vs linear-PCP
Succinctness and efficient verification is an important topic, which is only achieved by QAP (within all linear-PCPs)
The Reference document should give QAP as an instantiation and not as an abstraction
Not clear that any general linear PCP has specific properties that are useful for some constructions
“Would like to see a comment that this is only efficient example”
Gadgets
Not all gadgets are about SNARKs
There are many gadgets (Proof for Shuffle) that are not necessarily related to SNARKs / NIZK
Should we add a table about gadgets that are represented for non-generic proving systems
Also, there are ways to optimize the gadgets, but hard to minimize the size of a circuit
Instead, there is out-of-the box functionality
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?
Implementation who implements the primitives,
Applications since they compose them into circuit application
Security since they need to define the actual security
Comment on audience of document and specific documentation (who is the reader of this?)
Handling witnesses and private info - using legacy technology
Building use-cases (companies and biz people not easy to read)
Branch out general constructions?
Approaches for general functionality
For some gadgets can use specialized primitives
Suggested Contributions
Name
Email
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?)
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.
=== EDITORIAL:
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.
=== TRACK “SECURITY/THEORY”:
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.
=== TRACK “APPLICATIONS”
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.
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.
=== OTHERS (TOWARDS A REFERENCE DOCUMENT):
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.