Call for Community Standards Proposals

Speaker 1
Speaker 1
Speaker 1

Submit your Community Standard proposal by sending us a PDF to [email protected]


Community Standards

We are now accepting proposals for Community Standards on topics related to the security, implementation and applications of zero-knowledge proofs. Community Standards serve as guidelines agreed upon by the community, that promote correct usage and interoperability of zero-knowledge proofs. (Further work, to be defined in collaboration with standard bodies, will be required to gain official status as a standard.)

Submission Requirements

Submissions must be prepared in LaTeX in 11-point font; there is no page limit.
We encourage submission of every proposal, even if not finalized, because even discussing in-progress proposals is valuable to the community. To submit your proposal send an email with the PDF document at [email protected] with every author in CC.

Submissions should include the following:

  • Title: proposal title, author names, and affiliations.
  • Terminology: for consistency across documents, adopt terminology and definitions used in the ZKProof proceedings, and include pointers to the relevant sections.
  • Scope: an extended abstract should specify the scope of the standard, highlighting what is being standardized and what is not.
  • Potential issues: a section underlining the main open or unresolved questions, as well as any contentious issues that require further discussion.
  • Motivation: a section describing at least one concrete application motivating the proposed standard.
  • Description: a technical description of the proposed scheme, protocol or construction, including definitions and necessary background.
  • Security: if relevant, provide a proof of security.
  • Implementation: if relevant, submit an open source prototype implementation (by including a reference to the repository with the code).
  • Intellectual Property: we aim to ensure that proposals can be freely implemented. Thus, proposals should disclose the existence of any known patents (awarded or pending) which may restrict free implementation. This may affect the decision process, and a detailed policy is being developed.

Initial Timeline

Each community standard proposal will be reviewed by the Proposals Committee (PC) and, if deemed appropriate, will be subsequently discussed in the second workshop. After the workshop, a second draft that includes the suggestions and comments from the discussions must be submitted. Authors of accepted proposals must attend the workshop and must submit each draft in a timely manner, according to the timeline below. After the initial submission, failure to submit the further drafts may result in a rejection of the proposal. Alternatively the Steering Committee (SC) may assign others to continue leading the proposal.

March 1st, 2019, 23:59 (UTC): submission of the first draft of proposals are due
March 20th, 2019: decisions by the PC are communicated to the authors
April 10th, 2019: community discussions start at the workshop, moderated by the PC
May 15th, 2019, 23:59 (UTC): submission of the second draft of proposals are due
May 30th, 2019: review decisions by the PC are communicated to the authors

Online Discussions

After the workshop, shepherds will be assigned to each working draft in order to moderate online discussions that will take place in an open forum (to be determined). The shepherds will attempt to reach consensus by the community on different topics and will publish a “Last Call” and due date for final comments and suggestions. Once these final changes have been made, the shepherds will review the final drafts and submit them to the SC for approval as a Community Standard.

Topics

Proposals on any topic related to zero zero-knowledge proofs are welcome, including:

  • Terminology
    • The first thing to be standardized should be terminology, language and definitions. The field of zero knowledge is packed with terms and concepts that require careful definitions, which vary across the literature (see Security and Implementation tracks).
    • Provide a unified glossary encompassing all (implicit and explicit) terminology in the proceeding documents.
  • Benchmarks
    • There are no clear preferable construction since there are many trade-offs to consider. Even when a trade-off is the same (say proof size vs proving time), these depend on the way the constraint system is represented.
    • Benchmarks can be defined by the size of a specific computation (e.g., SHA256) or by the size of the “most friendly” computation that achieves the same or analogous functionality (e.g., value commitment).
  • Interoperability
    • There is currently a mailing list for discussing interoperability of zkp systems and implementations. Here is an outline of topics that derived from the first workshop.
    • One example can be around R1CS. Today, many constructions have the ability to use this constraint representation and it would be useful to have APIs and file formats standardized for interoperability. An initial proposal was written.
  • Constructions
    • There are many constructions out there, yet some are seeing a lot of adoption and we want to make sure that people are using them correctly, from the scheme description and security, to the instantiation of the underlying primitives.
    • The proposal should describe the scheme in terms of the generalized view on zkp constructions that is outlined in the Security Track proceeding.
    • The effort is not restricted to publicly verifiable schemes since we lose privacy in transferability and do not have proof deniability.
  • Domain specific languages
    • One of the biggest bottlenecks for using zero knowledge systems is the difficulty in writing secure and robust constraint systems, for which a DSL would allow more adoption and usability.
  • Protocols and Applications
    • As is outlined in the Applications Track proceeding there is the case that some (if not most) use-cases share some basic requirements (confidentiality, anonymity, etc…), for which there are several cryptographic primitives that would enable such properties and functionality (i.e.: set membership with Merkle Trees).
    • Ensuring that a zkp based system uses a secure protocol can be tricky, especially since each one can have different privacy requirements or caveats that are not easy to detect.
For any further questions, please email [email protected]