owned this note   changed 4 years ago  
Published Linked with GitHub

#4 - Home Edition

ZkpComRef: Deployment Case Studies

Please read the editorial disclaimer.

Index

Collaboration Instructions

Context. This page was prepared for a breakout session during the ZKProof 4th workshop. The goal of this document is to receive concurrent/collaborative suggestions of content that may be useful for the "ZKProof Community Reference" (ZkpComRef).

Goal. We will create a new section in ZkpComRef that containing brief case studies describing real-world deployment of ZK proof system, and lessons learned from them.

Content. Each "case study" should briefly describe a real-world deployment of a ZKP system, in about 2 pages. The aim is to enable a reader to gain insight on what it takes to actually implement a ZKP system that resolves a real-world application need. Each case study covers an application context, implementation choices, and lessons learned.

Expectations. This material is collected for inclusion into ZkpComRef, subject to review and editing by the ZKProof editors. It is licensed under CC-BY 4.0 International License. After inclusion in the ZkpComRef, it may be updated as part of the usual ZkpComRef editorial process.

Contributions. To contribute a new case study, duplicate the template below, fill in the details, and send an email to "editors at zkproof dot com" to confirm your contribution.

Guidelines:

  • Size: The overall description of a case study should be 1–2 pages (in the ZkpComRef style), excluding diagrams (which are very welcome and do not count for the space limit).
  • Simplicity: While trying to be cryptographically precise, feel free to handwave some explanations or arguments, for readability purposes. Try to modularize high-level explanations and low-level concrete technicalities.
  • Terminology: When possible, rely on concepts/terminology already present in the ZkpComRef, such as "frontend/backend" (from "Chapter 3. Implementation"), "gadgets" (from chapter "4. Applications"), the "Asset Transfer" application class (ditto), or "IT model" and "cryptographic compiler" (from chapter "2. Paradigms").
  • Introducing general concepts: If you need to introduce general concepts that best belong earlier in the ZkpComRef, please mark these as such and point out the desired location. The ZkpComRef editors will help relocating the text to its proper place, and it won't count towards page limit.
  • References: Add URLs or DOIs for further reading (whether inline or in the end).
    Rules. All interaction/contributions must abide to the ZKProof Charter, IP Policy and Code of Conduct.
  • Comments: Please include editorial comments when useful, and these will be considered when integrating into ZkpComRef. For example:

This is an example. Alice

Generic examples belong in Section 42 of ZkpComRef, so move there and reference. Bob

Case study TEMPLATE

Do not edit or delete this template; instead, copy-paste its content inside one of the available suggestion placeholders below, and then edit it there.

Replace all italicized text, about ¼ page per item.

Contributors: [fill in]

1. Application context

Application

Contextualize the application and the privacy needs/goals for this deployment.

ZK statement

_What's to prove? Describe the statement (relation, instance, witness) being proven in ZK. _

Requirements

What are the implementation requirements imposed/favored by the application? Examples: proof size, verification time, proving time, privacy/integrity requirements (statistical/computational? bit-level? postquantum?), setup requirements, integration with existing codebase/language.

2. Implementation

Backend

Which cryptographic backend (scheme and software) were chosen, and why? Why are the backend’s native constraint system representation and resulting complexity suitable for the application (e.g., uniformity, special structure, arithmetic vs boolean)?

Frontend

What decisions were made on how to generate/express the constraint system using a library, compiler, gadgets, API, etc. Mention the relevant tools.

Setup

Does the system require a trusted setup, such as a Structured Reference String (SRS) or a Uniform Reference String (URS)? If so, how was it generated (e.g., an MPC ceremony)?

3. Lessons learned

Quantitative evaluation

Constraint system size, proving/verification time, proof size, instance size, proving/verification key size, SRS size( (if any), MPC ceremony time, etc. Report helpful concrete benchmarks.

Challenges faced

What hurdles were encountered and should be planned for, or avoided?

Possible improvements

In retrospect, what can be done better or given subsequent progress? Are there new schemes/backends/frontends that should be considered if someone builds a similar application from scratch? Or were there issues in the MPC ceremony?

Case study 1: FILL IN

[Content here]

Case study 2: FILL IN

[Content here]

Case study 3: FILL IN

[Content here]

Select a repo