**#4 - Home Edition**

# ZkpComRef: Deployment Case Studies

Please read the [**editorial disclaimer**](https://hackmd.io/@workshop4/zcr-disclaimer).

## Index
* **[Collaboration Instructions](#Collaboration-Instructions)**
* **[Case study template](#Case-study-TEMPLATE)**
* [1. Application context](#1-Application-context)
* [2. Implementation](#2-Implementation)
* [3. Lessons learned](#3-Lessons-learned)
* **Case studies:** ...

---

## Collaboration Instructions

**Context.** This page was prepared for a breakout session during the [ZKProof 4th workshop](https://zkproof.org/events/workshop4/). The goal of this document is to receive concurrent/collaborative suggestions of content that may be useful for the "[ZKProof Community Reference](https://docs.zkproof.org/pages/reference/reference.pdf)" (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](https://docs.zkproof.org/pages/reference/reference.pdf), 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](https://docs.zkproof.org/general).
* **Comments:** Please include editorial comments when useful, and these will be considered when integrating into ZkpComRef. For example:
> This is an example. [name=Alice]
> > Generic examples belong in Section 42 of ZkpComRef, so move there and reference. [name=Bob]

---
## Case study TEMPLATE
:::warning
**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]_