# Table of Contents - [The Unreasonable Power of the Sum-CheckProtocol - ZKProof Standards](#the-unreasonable-power-of-the-sum-checkprotocol-zkproof-standards) - [About ZKProof - ZKProof Standards](#about-zkproof-zkproof-standards) - [Events - ZKProof Standards](#events-zkproof-standards) - [Homepage - ZKProof Standards](#homepage-zkproof-standards) - [The Art of Zero Knowledge - ZKProof Standards](#the-art-of-zero-knowledge-zkproof-standards) - [Gallery - ZKProof Standards](#gallery-zkproof-standards) - [ZKProof 7 in Sofia - ZKProof Standards](#zkproof-7-in-sofia-zkproof-standards) - [The Art of Zero Knowledge Archives - ZKProof Standards](#the-art-of-zero-knowledge-archives-zkproof-standards) - [Sangria: a Folding Scheme for PLONK - ZKProof Standards](#sangria-a-folding-scheme-for-plonk-zkproof-standards) - [Jonathan Gross, Author at ZKProof Standards](#jonathan-gross-author-at-zkproof-standards) - [Ulrich Haböck, Author at ZKProof Standards](#ulrich-hab-ck-author-at-zkproof-standards) - [Practical SNARK-based VDF - ZKProof Standards](#practical-snark-based-vdf-zkproof-standards) - [Email Protection | Cloudflare](#email-protection-cloudflare) - [Darlin: Proof-carrying data based on Marlin - ZKProof Standards](#darlin-proof-carrying-data-based-on-marlin-zkproof-standards) - [Zero-Knowledge Proofs for Set Membership - ZKProof Standards](#zero-knowledge-proofs-for-set-membership-zkproof-standards) - [Inductive Proof Systems and Recursive SNARKs - ZKProof Standards](#inductive-proof-systems-and-recursive-snarks-zkproof-standards) - [Justin Thaler, Author at ZKProof Standards](#justin-thaler-author-at-zkproof-standards) - [ZKProof Standards, Author at ZKProof Standards](#zkproof-standards-author-at-zkproof-standards) - [ZKProof 6 in Berlin - ZKProof Standards](#zkproof-6-in-berlin-zkproof-standards) - [ZKProof Policy @ DC - ZKProof Standards](#zkproof-policy-dc-zkproof-standards) - [ZKProof Policy @ DC Archives - ZKProof Standards](#zkproof-policy-dc-archives-zkproof-standards) - [Justin Thaler - ZKProof Standards](#justin-thaler-zkproof-standards) - [Jonathan Rouach - ZKProof Standards](#jonathan-rouach-zkproof-standards) - [Zero-Knowledge Financial Regulation Compliance by Eran Tromer - ZKProof Standards](#zero-knowledge-financial-regulation-compliance-by-eran-tromer-zkproof-standards) - [ZK Proofs for Balancing Privacy and Accountability by Anna Lysyanskaya - ZKProof Standards](#zk-proofs-for-balancing-privacy-and-accountability-by-anna-lysyanskaya-zkproof-standards) - [Privacy and Compliance: Striking a Delicate Balance by Pablo Kogan - ZKProof Standards](#privacy-and-compliance-striking-a-delicate-balance-by-pablo-kogan-zkproof-standards) - [NISTs Views on Standardisation of Advanced Cryptography by René Peralta - ZKProof Standards](#nists-views-on-standardisation-of-advanced-cryptography-by-ren-peralta-zkproof-standards) - [ZKProof 5.5 talks summary Archives - ZKProof Standards](#zkproof-5-5-talks-summary-archives-zkproof-standards) - [ZKPs and Post-Quantum Signatures From VOLE-in-the-Head at ZKProof.org by Peter Scholl - ZKProof Standards](#zkps-and-post-quantum-signatures-from-vole-in-the-head-at-zkproof-org-by-peter-scholl-zkproof-standards) - [Scaling Trustless DNN Inference, zkml applications at ZKProof.org by Daniel Kang - ZKProof Standards](#scaling-trustless-dnn-inference-zkml-applications-at-zkproof-org-by-daniel-kang-zkproof-standards) - [Recursive Proof Composition at ZKProof.org by Ying Tong Lai - ZKProof Standards](#recursive-proof-composition-at-zkproof-org-by-ying-tong-lai-zkproof-standards) - [Page not found - ZKProof Standards](#page-not-found-zkproof-standards) - [Lessons from DARPA SIEVE at ZKProof.org by James Parker & Kimberlee Model - ZKProof Standards](#lessons-from-darpa-sieve-at-zkproof-org-by-james-parker-kimberlee-model-zkproof-standards) - [The Plonk Effort at ZKProof.org by Mary Maller - ZKProof Standards](#the-plonk-effort-at-zkproof-org-by-mary-maller-zkproof-standards) - [Setup Ceremonies - ZKProof Standards](#setup-ceremonies-zkproof-standards) - [Call for Papers: 3rd ZKProof Workshop - ZKProof Standards](#call-for-papers-3rd-zkproof-workshop-zkproof-standards) - [Workshop 5 - ZKProof Standards](#workshop-5-zkproof-standards) - [Zebra: Zcash Zero-Knowledge Proofs at Scale - ZKProof Standards](#zebra-zcash-zero-knowledge-proofs-at-scale-zkproof-standards) - [HashWires: Range Proofs from Hash Functions - ZKProof Standards](#hashwires-range-proofs-from-hash-functions-zkproof-standards) - [Page not found - ZKProof Standards](#page-not-found-zkproof-standards) - [Playing with Randomness and Interactions to Prove Theorems - ZKProof Standards](#playing-with-randomness-and-interactions-to-prove-theorems-zkproof-standards) - [Standards Archives - ZKProof Standards](#standards-archives-zkproof-standards) - [ZKProof 5.5 - A day in Barcelona - ZKProof Standards](#zkproof-5-5-a-day-in-barcelona-zkproof-standards) - [Zero-Knowledge Proofs from Information-Theoretic Proof Systems - Part II - ZKProof Standards](#zero-knowledge-proofs-from-information-theoretic-proof-systems-part-ii-zkproof-standards) - [Zero-Knowledge Proofs from Information-Theoretic Proof Systems - Part I - ZKProof Standards](#zero-knowledge-proofs-from-information-theoretic-proof-systems-part-i-zkproof-standards) - [ZK Score - ZK hardware ranking standard  - ZKProof Standards](#zk-score-zk-hardware-ranking-standard-zkproof-standards) - [Call For Papers: 7th ZKProof Workshop - ZKProof Standards](#call-for-papers-7th-zkproof-workshop-zkproof-standards) - [Albert Garreta - ZKProof Standards](#albert-garreta-zkproof-standards) - [Teor, Author at ZKProof Standards](#teor-author-at-zkproof-standards) - [Webinar Archives - ZKProof Standards](#webinar-archives-zkproof-standards) - [Daniele Cozzo - ZKProof Standards](#daniele-cozzo-zkproof-standards) - [Antoine Rondelet, Author at ZKProof Standards](#antoine-rondelet-author-at-zkproof-standards) - [Education Archives - ZKProof Standards](#education-archives-zkproof-standards) - [Announcing the Expert Series Webinar on Zero-Knowledge Proofs - ZKProof Standards](#announcing-the-expert-series-webinar-on-zero-knowledge-proofs-zkproof-standards) - [Yuval Ishai, Author at ZKProof Standards](#yuval-ishai-author-at-zkproof-standards) - [Tech Archives - ZKProof Standards](#tech-archives-zkproof-standards) - [Eylon Yogev - ZKProof Standards](#eylon-yogev-zkproof-standards) - [Giacomo Fenzi - ZKProof Standards](#giacomo-fenzi-zkproof-standards) - [Zero-knowledge proofs Archives - ZKProof Standards](#zero-knowledge-proofs-archives-zkproof-standards) - [Izaak Meckler, Author at ZKProof Standards](#izaak-meckler-author-at-zkproof-standards) - [Helger Lipmaa - ZKProof Standards](#helger-lipmaa-zkproof-standards) - [Antonio Faonio - ZKProof Standards](#antonio-faonio-zkproof-standards) - [Alexander Hicks - ZKProof Standards](#alexander-hicks-zkproof-standards) - [James Parker - ZKProof Standards](#james-parker-zkproof-standards) --- # The Unreasonable Power of the Sum-CheckProtocol - ZKProof Standards The Unreasonable Power of the Sum-Check Protocol ================================================ March 16, 2020 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Justin Thaler](https://zkproof.org/author/justinthaler/) Introduction ------------ When designing an efficient interactive proof system, there is only one hammer you need to have in your toolbox: the _sum-check protocol_ of [Lund, Fortnow, Karloff, and Nisan](https://dl.acm.org/doi/10.1145/146585.146605) . The power of this protocol seems to be a bit under-appreciated in the ZKProofs community. I speculate that there are two reasons for this. The first is that the protocol inherently leads to proofs of at least logarithmic length, which means that in applications where super short proofs are really important—say, because these proofs need to be stored for all eternity on a blockchain—other techniques may be preferable (e.g., protocols derived from the work of [Gennaro, Gentry, Parno, and Raykova](https://eprint.iacr.org/2012/215) , which tend to have constant proof length). Second, the sum-check protocol by itself is not zero-knowledge nor “succinct for NP statements”. This means that, for NP statements, the proof length achieved by the sum-check protocol is not sublinear in the size of the NP witness. Note that there is [strong evidence](https://www.math.ias.edu/~avi/PUBLICATIONS/MYPAPERS/ODED/IP/FINAL/paper.pdf) that _no_ interactive proof can be succinct for NP statements. This is in contrast to argument systems (which unlike interactive proofs, are only computationally sound). However, in the last few years, researchers have figured out how to combine the sum-check protocol with cryptographic commitments to obtain arguments that are both zero-knowledge and succinct for NP statements. This has led to zk-SNARKs with state of the art performance (e.g., [Hyrax](https://eprint.iacr.org/2017/1132) , [zk-vSQL](https://eprint.iacr.org/2017/1146) , [Libra](https://eprint.iacr.org/2019/317) , [Virgo](https://eprint.iacr.org/2019/1482.pdf) , [Spartan](https://eprint.iacr.org/2019/550) ). So if you are interested in zk-SNARKs and satisfied with proofs of logarithmic length, then I urge you to learn about the sum-check protocol and how to use it. To this end, the goal of this blog post is to describe the problem solved by the sum-check protocol and why it is so useful. For readers interested in learning more, I have posted a [more detailed (and unfortunately more technical) exposition here](http://people.cs.georgetown.edu/jthaler/blogpost.pdf) . This entire post will be framed in the context of interactive proofs (IPs). This means that the goal is for a verifier $V$ to offload an expensive computation to an untrusted prover $P$, while achieving work-saving for the verifier. We want the verifier to run in time linear in the input size, while keeping the proof short (logarithmic size) and the prover efficient. In a future post, I will explain how to combine the ideas described here with cryptographic commitments to get state of the art zk-SNARKs. The Sum-Check Protocol ---------------------- Suppose we are given a $v$-variate polynomial $g$ defined over a finite field $\\mathbf{F}$. Let us further assume that $g$ has degree at most 2 in each variable, as this will be the case in all of the applications in both this post and [its more detailed version](http://people.cs.georgetown.edu/jthaler/blogpost.pdf) . The purpose of the sum-check protocol is to compute the sum: $$ H:=\\sum\_{b\_1 \\in \\{0,1\\}} \\sum\_{b\_2 \\in \\{0, 1\\}} \\dots \\sum\_{b\_v \\in \\{0, 1\\}} g(b\_1, \\dots, b\_v) \\text{ } (1)$$ Summing up the evaluations of a polynomial over all Boolean inputs may seem like a contrived task with limited practical utility. But to the contrary, later sections of this post will show that many natural problems can be directly cast as an instance of Equation (1). To keep this post as nontechnical as possible, I will say only a little about how the sum-check protocol actually works; see the [more detailed post](http://people.cs.georgetown.edu/jthaler/blogpost.pdf) for a complete description of the protocol and why it is sound. The protocol consists of $v$ rounds, one for each variable of $g$. In each round $i$, the prover sends to the verifier a degree 2 univariate polynomial $g\_i$ ($g\_i$ can always be specified with just 3 field elements, by either sending its coefficients, or its evaluations at 3 designated inputs in $\\mathbf{F}$). The verifier performs some simple randomized consistency checks on each message $g\_i$; these checks involve evaluating $g\_i$ at a handful of inputs and checking that these evaluations are consistent with previous messages sent by the prover. The verifier can process each message sent by the prover in $O(1)$ time, and at the very end of the protocol the verifier also needs to evaluate $g$ at single point. Throughout, we assume any addition or multiplication operation in $\\mathbf{F}$ takes $O(1)$ time. ### What does the verifier gain by using the sum-check protocol? The verifier could clearly compute $H$ via Equation (1) on her own by evaluating $g$ at $2^v$ inputs (namely, all inputs in $\\{0,1\\}^v$), but we are thinking of $2^v$ as an unacceptably large runtime for the verifier. Using the sum-check protocol, the verifier’s runtime is $$O(v + \\text{\[the cost to evaluate } g \\text{ at a single input in } \\mathbf{F}^v \])$$ This is much better than the $2^v$ evaluations of $g$ required to compute $H$ unassisted. It also turns out that the prover in the sum-check protocol can compute all of its prescribed messages by evaluating $g$ at $O(2^v)$ inputs in $\\mathbf{F}^v$. This is only a constant factor more than what is required simply to compute $H$ without proving correctness. The soundness error of the sum-check protocol is $O(v/|\\mathbf{F}|)$. As long as $g$ is defined over a field of size significantly greater than $v$, this error is very small. Applications ------------ At this point in the post, we have our hammer in hand: the sum-check protocol, which allows a verifier to offload the computation expressions of the form of Equation (1) to an untrusted prover. However, wielding this hammer to solve problems people care about can require a good deal of cleverness. The goal of the rest of this post is give a flavor of how this typically works. The general challenge is the following: suppose the verifier has an input $x$ and asks the prover to compute some function $F$ of $x$. To apply the sum-check protocol to compute $F$, we need to be able to express $F(x)$ as an instance of Equation (1). This means that we need to identify some $v$-variate polynomial $g$ of degree 2 in each variable such that $F(x)$ can be inferred from the sum of $g$’s values over all inputs in $\\{0, 1\\}^{v}$. Moreover, the verifier needs to be able to evaluate $g(r)$ at any desired input $r \\in \\mathbf{F}^v$ in linear time. I will explain one illustrative example of this paradigm, in which the input $x$ is the adjacency matrix of a graph, and $F(x)$ is the number of triangles in that graph. To accomplish this, I have no choice but to introduce one technical notion, called multilinear extensions, defined in the lemma below. To avoid unnecessary details, I do not prove the lemma, but it follows readily from [Lagrange interpolation](https://en.wikipedia.org/wiki/Lagrange_polynomial) . ### Multilinear Extension Lemma Let $f \\colon \\{0, 1\\}^n \\to \\mathbf{F}$. Then there is a unique multilinear polynomial $\\tilde{f}$ over $\\mathbf{F}$ such that $\\tilde{f}(x) = f(x)$ for all $x \\in \\{0,1\\}^n$. Here, a polynomial is said to be multilinear if it has degree at most 1 in each variable. $\\tilde{f}$ is called the _multilinear extension_ (MLE) of $f$. Given as input a list of all $2^n$ evaluations of $f$, and an arbitrary point $r \\in \\mathbf{F}^n$, there is an algorithm that can evaluate $\\tilde{f}(r)$ in $O(2^n)$ time. ### An Application: An IP for Counting Triangles Let $G$ be an undirected graph on $n$ vertices with edge set $E$. Let $A \\in \\{0, 1\\}^{n \\times n}$ be the adjacency matrix of $G$, i.e., $A\_{i,j}=1$ if and only if $(i, j) \\in E$. In the counting triangles problem, the input is the adjacency matrix $A$, and the goal is to determine the number of vertex triples $(i, j, k)$ that are all connected to each other by edges. At first blush, it is totally unclear how to express the number of triangles in $G$ as the sum of the evaluations of a degree-2 polynomial $g$ over all inputs in $\\{0, 1\\}^v$. After all, the counting triangles problem itself makes no reference to any low-degree polynomial $g$, so where will $g$ come from? This is where multilinear extensions come to the rescue. For it to make sense to talk about multilinear extensions, we need to view the adjacency matrix $A$ not as a matrix, but rather as a function $f\_A$ mapping $\\{0, 1\\}^{\\log n} \\times \\{0, 1\\}^{\\log n}$ to $\\{0, 1\\}$. The natural way to do this is to define $f\_A(x, y)$ so that it interprets $x$ and $y$ as the binary representations of some integers $i$ and $j$ between $1$ and $n$, and outputs $A\_{i, j}$. Then the number of triangles in $G$ is simply: $$ \\Delta := \\frac{1}{6} \\sum\_{x, y, z \\in \\{0, 1\\}^{\\log n}} f\_A(x, y) \\cdot f\_A(y, z) \\cdot f\_A(x, z) \\textit{ } (2)$$ To see that this equality is true, observe that the term for $x, y, z$ in the above sum is 1 if edges $(x, y)$, $(y, z)$, and $(x, z)$ all appear in $G$, and is 0 otherwise. The factor $1/6$ comes in because the sum over _unordered_ node triples $(i, j, k)$ counts each triangle 6 times, once for each permutation of $i$, $j$, and $k$. Let $\\mathbf{F}$ be a finite field of size $p \\geq n^3$, where $p$ is a prime, and let us view all entries of $A$ as elements of $\\mathbf{F}$. Here, we are choosing $p$ large enough so that $6\\Delta$ is guaranteed to be in $\\{0, 1, \\dots, p\\}$. This ensures that, if we associate elements of $\\mathbf{F}$ with integers in $\\{0, 1, \\dots, p\\}$ in the natural way, then Equation (2) holds even when all additions and multiplications are done in $\\mathbf{F}$ rather than over the integers. (Choosing a large field to work over has the added benefit of ensuring good soundness error, as the soundness error of the sum-check protocol decreases linearly with field size.) At last we are ready to describe the polynomial $g$ to which we will apply the sum-check protocol to compute $6 \\Delta$. Recalling that $\\tilde{f}\_A$ is the MLE of $f\_A$ over $\\mathbf{F}$, define the $(3 \\log n)$-variate polynomial $g$ to be: $$g(X, Y, Z) = \\tilde{f}\_A(X, Y) \\cdot \\tilde{f}\_A(Y, Z) \\cdot \\tilde{f}\_A(X, Z)$$ It is easy to see that $$6 \\Delta = \\sum\_{x, y, z \\in \\{0, 1\\}^{\\log n}} g(x, y, z),$$ so applying the sum-check protocol to $g$ yields an IP computing $6\\Delta$. This IP requires $3 \\log n$ rounds, with the prover sending 3 field elements in each round. The verifier’s runtime is dominated by the time required to evaluate $g$ at a single input $(r\_1, r\_2, r\_3) \\in \\mathbf{F}^{3 \\log n}$, for which it suffices to evaluate $\\tilde{f}\_A$ at the three inputs $(r\_1, r\_2)$, $(r\_2, r\_3)$, and $(r\_1, r\_3)$. This can be done in $O(n^2)$ time using the Multilinear Extension Lemma. This is much faster than the fastest known algorithm for counting triangles, which runs in matrix multiplication time (superlinear in the input size). It turns out that the prover in this IP can compute all of its prescribed messages in $O(n^3)$ time. This is not obvious, and for brevity, I’ll omit the details of how to accomplish this. Note that this runtime for the prover matches that of the the naive algorithm for counting triangles that iterates over all triples of vertices in $G$ and checks if they are all connected to each other. ### More Applications Hopefully the above gives a sense of how problems that people care about can be expressed as instances of Equation (1) in non-obvious ways. The general paradigm works as follows. An input $x$ of length $n$ is viewed as a function $f\_x$ mapping $\\{0, 1\\}^{\\log n}$ to some field $\\mathbf{F}$. And then the multilinear extension $\\tilde{f}\_x$ of $f\_x$ is used in some way to construct a low-degree polynomial $g$ such that, as per Equation (1), the desired answer equals the sum of the evaluations of $g$ over the Boolean hypercube. The [full version](http://people.cs.georgetown.edu/jthaler/blogpost.pdf) of this post covers some additional examples of this paradigm. In the hopes of enticing you to check it out, here is a summary of the examples covered there. First, it gives a more sophisticated IP for counting triangles in which the prover is much more efficient than the above. Specifically, the prover runs the best-known algorithm to solve the triangles problem, and then does a low-order amount of extra work to prove the answer is correct. I don’t know of any other IPs or argument systems that achieve this super-efficiency for the prover while keeping the proof length sublinear in the input size. Second, it gives a similarly super-efficient IP for matrix-powering. Given any $n \\times n$ matrix $A$ over field $\\mathbf{F}$, this IP is capable of computing any desired entry of the powered matrix $A^k$. The number of rounds and communication cost of the IP are $O(\\log(k) \\cdot \\log n)$, and the verifier’s runtime is $O(n^2 + \\log(k) \\cdot \\log n)$. Finally, it uses this matrix-powering protocol to re-prove the following important result of [Goldwasser, Kalai, and Rothblum](https://www.microsoft.com/en-us/research/wp-content/uploads/2008/01/GoldwasserKR08a.pdf) (GKR): all problems solvable in logarithmic space have an IP with a quasilinear-time verifier, polynomial time prover, and polylogarithmic proof length. The basic idea of the proof is that executing any Turing Machine $M$ that uses $s$ bits of space can be reduced to the problem of computing a single entry of $A^{2^s}$ for a certain matrix $A$ ($A$ is in fact the [configuration graph](https://en.wikipedia.org/wiki/Configuration_graph) of $M$). So one can just apply the matrix-powering IP to $A$ to determine the output of $M$. While $A$ is a huge matrix (it has at least $2^s$ rows and columns), configuration graphs have a ton of structure, and this enables the verifier to evaluate $\\tilde{f}\_A$ at a single input in $O(s \\cdot n)$ time. If $s$ is logarithmic in the input size, then this means that the verifier in the IP runs in $O(n \\log n)$ time. The original paper of GKR proved the same result by constructing an arithmetic circuit for computing $A^{2^s}$ and then applying a sophisticated IP for arithmetic circuit evaluation to that circuit. The approach described above is simpler, in that it directly applies a simple IP for matrix-powering, rather than a more complicated IP for the general circuit-evaluation problem. * * * ![](https://secure.gravatar.com/avatar/762930bf4e5729c872d96573ea566297?s=240&d=identicon&r=g) ##### [Justin Thaler](https://zkproof.org/author/justinthaler/ "Justin Thaler post page") [All author posts](https://zkproof.org/author/justinthaler/ "Justin Thaler post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2020/03/16/sum-checkprotocol/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # About ZKProof - ZKProof Standards About ZKProof ============= * [ZKProof Standards](#aboutus) * [Zero-Knowledge Proofs](#standards) ZKProof is an open-industry academic initiative that seeks to mainstream zero-knowledge proof (ZKP) cryptography through an inclusive, community-driven standardization process. The organization is part of a global movement advocating for the standardization of advanced cryptography, and is actively developing a ZKP trust ecosystem to facilitate industry usage. ZKProof believes broader adoption of ZKP cryptography is best achieved through the establishment of a widely accepted framework that will bring better security assurance and greater interoperability to data privacy products and applications. The organization’s work, as reflected in the [ZKProof Community Reference document](https://github.com/zkpstandard/zkreference/) , is fast becoming the primary resource for developers and practitioners in need of a trusted specification for implementing cryptographically-secure ZKP schemes and protocols. ZKProof hosts annual conferences attended by top-tier cryptographers and practitioners from around the world and is supported by industry leading enterprises and standardization bodies like the National Institute of Standards and Technology (NIST). The community’s enthusiasm for rigorously discussing, reviewing and testing proposals is paving the path for a best-practice ZKP standard. At their core, zero-knowledge proofs are a privacy-enhancing cryptographic technique that allow one party (a prover) to convince another party (a verifier) that some computational statement is correct without revealing any information except the veracity of the statement. This breakthrough technology enables us to prove the integrity of data, without revealing any underlying details about the data itself. Zero-knowledge proofs were first introduced by Professors Shafi Goldwasser, Silvio Micali and Charles Rackoff in the mid 80’s. In [\[GMR89\]](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.419.8132&rep=rep1&type=pdf) , they created a new proving procedure for communicating a proof, or in modern terms, an efficient interactive proof system. An interactive proof is a process in which a prover probabilistically convinces a verifier of the correctness of a mathematical proposition. In 2012, Professors [Goldwasser](https://amturing.acm.org/award_winners/goldwasser_8627889.cfm) and [Micali](https://amturing.acm.org/award_winners/micali_9954407.cfm) received the A.M. Turing Award “for transformative work that laid the complexity-theoretic foundations for the science of cryptography.” Further research resulted in the study of non-interactive zero knowledge proofs (NIZKs), a variant that does not require interaction between the prover and the verifier. Building on top of these, [modern NIZK systems](http://zkp.science/) have become more efficient, including succinct proofs, sub-linear verifiers and highly efficient provers, such as SNARKs such as \[[PGHR](https://eprint.iacr.org/2013/279.pdf)\ , [BCTV14](https://eprint.iacr.org/2013/879.pdf)\ , [Groth16](https://eprint.iacr.org/2016/260.pdf)\ \], STARKs such as [\[BBHR18\]](https://eprint.iacr.org/2018/046.pdf) , and Bulletproofs [\[BBBPWM17\]](https://eprint.iacr.org/2017/1066.pdf) , yet there are plenty of other constructions ([Ligero](https://acmccs.github.io/papers/p2087-amesA.pdf) , [Hyrax](https://eprint.iacr.org/2017/1132.pdf) , [Aurora](https://eprint.iacr.org/2018/828.pdf) , etc.). ZKPs are relevant for a wide range of industries across many verticals and use cases. For example, in the identify management space, they could be used to prove that someone maintains certain attributes (e.g:  they live in the United States and are above the legal voting age of 18), without revealing a particular credential such as a driver’s license to attest to those attributes (in this case, presenting a driver’s license would reveal much more than the subject’s national residence or age bracket – they would expose the birth date, gender and home address of the ID’s owner). Similarly, ZKPs could be deployed on a blockchain to affirm the validity of an asset transfer without revealing any sensitive transactional details. A more detailed explanation of various use-cases can be found in the [ZKProof Community Reference document](https://zkproof.org/ZKProofCommunityReference.pdf) . ZKProof Team ------------ ![Daniel Benarroch](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/77A5005-1-e1580068464804.jpg?fit=300%2C300&ssl=1) ### Daniel Benarroch [](https://twitter.com/benarrochdaniel "twitter") [](/cdn-cgi/l/email-protection#e581848b8c8089a59f8e95978a8a83cb8a9782 "envelope-o") ![Jonathan Rouach](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?fit=200%2C203&ssl=1) ### Jonathan Rouach Executive Director for ZKProof, CEO and Founder, QEDIT ![Liad Zohar](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/06/liad_square.jpg?fit=300%2C300&ssl=1) ### Liad Zohar Events & HR Manager at QEDIT FAQ ------- [What is ZKProof?](#d21d5937-3bb0-21555678914001) ZKProof is an academic and industry open initiative for standardizing Zero Knowledge Proofs, with a growing and active community. [What is a standard?](#6dad8f3c-7309-81555678914001) From Wikipedia: a technical standard is an established norm or requirement in regard to technical systems. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes, and practices. A technical standard may be developed between relevant entities, increasing product safety and quality as well as fostering trust in the technology. [Why do we need a ZKP standard? And why now?](#9346230d-a835-91555678914001) A standard fosters trust in the technology within industry usage, removing the need to rely on a single company for the security of the system and the confidentiality of their data. There is a growing interest in this technology and we want to see the industry grow with a strong foundation. [Where does ZKProof stand at the moment?](#1555679162900-3-1) We held our first workshop back in May, which proved to be a success. We published three documents relating the discussions we had during the breakout sessions, as well as the state-of-the-art in each of the topics. [I want to help, how can I join the effort?](#376ecfb2-1bc5-0) There are several ways to get involved with ZKProof: * Join the ZKProof community group to receive the latest updates and stay in the loop * Join the Interoperability WG to contribute to the open problems and standard proposals around library and compiler interoperability * Become a sponsor of the effort by sending us an [email](/cdn-cgi/l/email-protection#cfaca0a1bbaeacbb8fb5a4bfbda0a0a9e1a0bda8) * Follow us on twitter [@zkproof](https://twitter.com/zkproof) . [](#) --- # Events - ZKProof Standards ZKProof Events ============== ### **Save the date!** #### **ZKProof 7 - Sofia**March 23-25 2025 [learn more](https://zkproof.org/events/zkproof-7-sofia/ "ZKProof 7 @ Sofia") [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-63-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-63-uai-2064x1376.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_461-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_461-uai-2064x1376.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-5.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-5.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-141-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-141-uai-2064x1399.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-179-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-179-uai-2064x1376.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0422-e1580124997833-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0422-e1580124997833-uai-2064x1732.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0343-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0343-uai-2064x1376.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-98-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-98-uai-2064x1376.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_326-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_326-uai-2064x1376.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_653-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_653-uai-2064x1068.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_032-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_032-uai-2064x1376.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0176-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0176-uai-2064x1376.jpg) [View gallery >](https://zkproof.org/gallery/) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-63-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-63-uai-2064x1376.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_461-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_461-uai-2064x1376.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-5.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-5.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-141-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-141-uai-2064x1399.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-179-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-179-uai-2064x1376.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0422-e1580124997833-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0422-e1580124997833-uai-2064x1732.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0343-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0343-uai-2064x1376.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-98-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-98-uai-2064x1376.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_326-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_326-uai-2064x1376.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_653-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_653-uai-2064x1068.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_032-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_032-uai-2064x1376.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0176-uai-2064x1548.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0176-uai-2064x1376.jpg) [View gallery >](https://zkproof.org/gallery/) Upcoming events --------------- [](https://zkproof.org/documents.html "Events") ##### [Images](https://zkproof.org/documents.html "Events") [](https://zkproof.org/documents.html "Events") ##### [Videos](https://zkproof.org/documents.html "Events") [](https://zkprooforg.wpcomstaging.com/events/ "Events") ##### [Documentation](https://zkprooforg.wpcomstaging.com/events/ "Events") [](https://zkproof.org/first_workshop.html "Events") ##### [Event details](https://zkproof.org/first_workshop.html "Events") [Upcoming event name #1 - Date, 2020](#0b1628e1-5784-10) ZKP team: To create a new section, do not duplicate this one (it will assign a duplicate ID which will make the tabs defunct) – modify the accordion, select add new section, and then duplicate the content in a different section and place the elements into this section. Past events ----------- [ZKProof 6 in Berlin - May 22-24 2024](#1727293798890-8-8) [](https://zkproof.org/gallery/ "Images") ##### [Images](https://zkproof.org/gallery/ "Images") [](https://www.youtube.com/@zkproofstandards1776/playlists "Videos") ##### [Videos](https://www.youtube.com/@zkproofstandards1776/playlists "Videos") [](https://zkproof.org/events/zkproof-6-berlin/ "ZKP6 Berlin") ##### [Event details](https://zkproof.org/events/zkproof-6-berlin/ "ZKP6 Berlin") [ZKProof Policy @ DC- November 30th, 2023](#1698579922779-4-7) With zero-knowledge-proofs in the headlines, ZKProof Policy @ DC assembled to explore how the technology can be used for enhanced privacy for all, and discuss the trade-offs and interactions with law enforcement and regulations. [](https://zkproof.org/events/zkproof-policy-at-washington-dc/ "Events") ##### [Event details](https://zkproof.org/events/zkproof-policy-at-washington-dc/ "Events") [The 5.5 ZKProof Standards Workshop- August 2, 2023](#1727294347374-8-2) The 5.5 ZKProof workshop was part of ZK week that took place in Barcelona. During the event, we had workshops on PLONK Standardization, Recursive Proof Composition, and more. [](https://zkproof.org/events/zkproof-5-5-barcelona/ "Events") ##### [Event details](https://zkproof.org/events/zkproof-5-5-barcelona/ "Events") [The 5th ZKProof Workshop - November 15 2022](#1698584933536-5-4) [](https://www.ronengoldman.com/zkproof-highlights-by-ronen-goldman "Events") ##### [Images](https://www.ronengoldman.com/zkproof-highlights-by-ronen-goldman "Events") [](https://www.youtube.com/watch?v=TrcT3-VPOz4&list=PLOEty2U8Y69ULDD8YxqQ8kWg8Qn7N8XHZ "Events") ##### [Videos](https://www.youtube.com/watch?v=TrcT3-VPOz4&list=PLOEty2U8Y69ULDD8YxqQ8kWg8Qn7N8XHZ "Events") [](https://zkproof.org/events/workshop5/ "Events") ##### [Event details](https://zkproof.org/events/workshop5/ "Events") [ZKProof Community Event Amsterdam — October 28, 2019](#10282019) The first-ever community event for the ZKProof standardization initiative in Europe. The two-day event brought together top researchers, developers and business practitioners to showcase the latest academic achievements and practical applications for ZKP privacy schemes. [](https://photos.app.goo.gl/U82z3dvfDwvSxa646 "Gallery") ##### [Images](https://photos.app.goo.gl/U82z3dvfDwvSxa646 "Gallery") [](https://www.youtube.com/playlist?list=PLOEty2U8Y69XK60bxOT0r26SrpJnAVgFg "Youtube") ##### [Videos](https://www.youtube.com/playlist?list=PLOEty2U8Y69XK60bxOT0r26SrpJnAVgFg "Youtube") [](https://community.zkproof.org/t/presentation-slides-from-the-zkproof-community-event-in-amsterdam/314 "Events") ##### [Documentation](https://community.zkproof.org/t/presentation-slides-from-the-zkproof-community-event-in-amsterdam/314 "Events") [](https://www.eventbrite.com/e/zkproof-community-event-amsterdam19-tickets-68989889617 "Events") ##### [Event details](https://www.eventbrite.com/e/zkproof-community-event-amsterdam19-tickets-68989889617 "Events") [The 2nd ZKProof Standards Workshop — April 10, 2019](#0ea671e4-da62-7) The second annual ZKProof Workshop took place in Berkeley, CA, and was attended by 150 top researchers and industry leaders. The review committee accepted four community proposals that address the interoperability and security of zero-knowledge proofs. In addition, the community collaborated with NIST to establish the first Community Reference document for ZKPs. [](https://drive.google.com/drive/u/1/folders/1cpjfGqNl81SFbJ6ZHax1lUyoqM-73PkS "Gallery") ##### [Images](https://drive.google.com/drive/u/1/folders/1cpjfGqNl81SFbJ6ZHax1lUyoqM-73PkS "Gallery") [](https://www.youtube.com/playlist?list=PLOEty2U8Y69VKX0THZvO_liqwV3Ngf1wt "Youtube") ##### [Videos](https://www.youtube.com/playlist?list=PLOEty2U8Y69VKX0THZvO_liqwV3Ngf1wt "Youtube") [](https://docs.zkproof.org "Events") ##### [Documentation](https://docs.zkproof.org "Events") [](https://zkpstandard.github.io/zkproof.github.io/workshop2/main.html "Events") ##### [Event details](https://zkpstandard.github.io/zkproof.github.io/workshop2/main.html "Events") [1st Workshop on Advanced Cryptography Standardization — August 18, 2019](#9713715b-556f-1) In order to consolidate the different cryptography standardization efforts, and to promote collaboration, ZKProof partnered with the [Homomorphic Encryption standards effort](https://homomorphicencryption.org/) to launch the first Advanced Cryptography Standardization (ACS) workshop. This event focused on zero-knowledge proofs, fully homomorphic encryption and threshold cryptography, and featured a keynote by Luís Brandão from the National Institute of Standards and Technology (NIST). ##### Images [](https://www.youtube.com/playlist?list=PLeeS-3Ml-rppVt0HL2CziljGocohCH62A "Youtube") ##### [Videos](https://www.youtube.com/playlist?list=PLeeS-3Ml-rppVt0HL2CziljGocohCH62A "Youtube") [](https://docs.zkproof.org "Events") ##### [Documentation](https://docs.zkproof.org "Events") [](https://sites.google.com/view/acs19 "Events") ##### [Event details](https://sites.google.com/view/acs19 "Events") [The 1st ZKProof Standards Workshop — May 10, 2018](#05102018) The first ever ZKProof Workshop took place in Boston, MA, where an initial community of experts convened to discuss topics underlying the standardization of ZKPs. The participants produced a series of three documents that establish a best-practice framework for the Security, Implementation and Applications of zero-knowledge proofs. [](http://www.lghtbx.com/u/contact@zkproof.org/1EqcFPddkotCIEbJoQ2AZ_0EJZYKo6ddL "Gallery") ##### [Images](http://www.lghtbx.com/u/contact@zkproof.org/1EqcFPddkotCIEbJoQ2AZ_0EJZYKo6ddL "Gallery") [](https://www.youtube.com/playlist?list=PLOEty2U8Y69XadRILKwdG5eADUdAJ96ou "Youtube") ##### [Videos](https://www.youtube.com/playlist?list=PLOEty2U8Y69XadRILKwdG5eADUdAJ96ou "Youtube") [](https://docs.zkproof.org "Events") ##### [Documentation](https://docs.zkproof.org "Events") [](https://zkpstandard.github.io/zkproof.github.io/first_workshop.html "Events") ##### [Event details](https://zkpstandard.github.io/zkproof.github.io/first_workshop.html "Events") [](#) --- # Homepage - ZKProof Standards ZKProof Standards ================= A global movement to standardize and mainstream advanced cryptography by building a community-driven trust ecosystem ==================================================================================================================== ### Upcoming event #### ZKProof 7 March 23-25, Sofia [Tell me more!](https://zkproof.org/events/zkproof-7-sofia/ "ZKProof 7 @ Sofia") About ZKProof ------------- ZKProof is an open-industry academic initiative that seeks to mainstream zero-knowledge proof (ZKP) cryptography through an inclusive, community-driven standardization process that focuses on interoperability and security. Annually-held ZKProof workshops, attended by world-renowned cryptographers, practitioners and industry leaders, are the optimal forum for discussing new proposals, reviewing cutting edge projects and advancing a community reference document that will ultimately serve as a trusted specification for the implementation of ZKP schemes and protocols. [Learn More](https://zkprooforg.wpcomstaging.com/about/ "About ZKProof") ### Global Community Join our growing community and collaborate with working groups [Meet the community](https://community.zkproof.org/) ### Documentation Contribute to the reference documentation and define best practices [View Resources](https://docs.zkproof.org "General Resources") ### Submissions Present your proposals and advance the standardization effort [View call for papers](https://zkproof.org/events/papers/ "Call for Papers") Steering Committee ---------------------- [![Justin Thaler](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/02/headshot1.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/justin-thaler/) ### [Justin Thaler](https://zkproof.org/team/justin-thaler/ "Justin Thaler") [Research Partner, a16z. Associate Professor, Georgetown University](https://zkproof.org/team/justin-thaler/ "Justin Thaler") [![Dan Boneh](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/danboneh_a16zcrypto.jpg?resize=150%2C150&ssl=1)](http://crypto.stanford.edu/~dabo/) ### [Dan Boneh](http://crypto.stanford.edu/~dabo/ "Dan Boneh") [Stanford University](http://crypto.stanford.edu/~dabo/ "Dan Boneh") [![Ran Canetti](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/ran_canetti-e1576008389650.jpg?resize=150%2C150&ssl=1)](https://www.cs.tau.ac.il/~canetti/) ### [Ran Canetti](https://www.cs.tau.ac.il/~canetti/ "Ran Canetti") [Boston University, Tel Aviv University](https://www.cs.tau.ac.il/~canetti/ "Ran Canetti") [![Alessandro Chiesa](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/chiesa.jpeg?resize=150%2C150&ssl=1)](https://people.eecs.berkeley.edu/~alexch/) ### [Alessandro Chiesa](https://people.eecs.berkeley.edu/~alexch/ "Alessandro Chiesa") [EPFL](https://people.eecs.berkeley.edu/~alexch/ "Alessandro Chiesa") [![Shafi Goldwasser](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/shafi-268x246.png?resize=150%2C150&ssl=1)](https://people.csail.mit.edu/shafi/) ### [Shafi Goldwasser](https://people.csail.mit.edu/shafi/ "Shafi Goldwasser") [Director, Simons Institute, UC Berkley](https://people.csail.mit.edu/shafi/ "Shafi Goldwasser") [![Jonathan Rouach](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/jonathan-rouach/) ### [Jonathan Rouach](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [Executive Director for ZKProof, CEO and Founder, QEDIT](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [![Muthu Venkitasubramaniam](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Copy-of-GBP_20190412_1086-e1576450323148.jpg?resize=150%2C150&ssl=1)](https://www.cs.rochester.edu/u/muthuv/) ### [Muthu Venkitasubramaniam](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [Associate Professor, Georgetown University  CTO and co-founder, Ligero Inc.](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [![Jens Groth](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/JensGroth-2-e1576008345317.jpg?resize=150%2C150&ssl=1)](http://www0.cs.ucl.ac.uk/staff/j.groth/) ### [Jens Groth](http://www0.cs.ucl.ac.uk/staff/j.groth/ "Jens Groth") [Nexus](http://www0.cs.ucl.ac.uk/staff/j.groth/ "Jens Groth") [![Yuval Ishai](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/yuval-ishai.jpg?resize=150%2C150&ssl=1)](http://www.cs.technion.ac.il/~yuvali/) ### [Yuval Ishai](http://www.cs.technion.ac.il/~yuvali/ "Yuval Ishai") [Technion University](http://www.cs.technion.ac.il/~yuvali/ "Yuval Ishai") [![Eran Tromer](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/CA5_0227_edt2_sqr.jpg?resize=150%2C150&ssl=1)](http://www.tau.ac.il/~tromer/) ### [Eran Tromer](http://www.tau.ac.il/~tromer/ "Eran Tromer") [Professor, Boston University founder, Sealance](http://www.tau.ac.il/~tromer/ "Eran Tromer") [![Yael Kalai](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/yael_kalai.jpeg?resize=150%2C150&ssl=1)](https://www.microsoft.com/en-us/research/people/yael/) ### [Yael Kalai](https://www.microsoft.com/en-us/research/people/yael/ "Yael Kalai") [Microsoft Research](https://www.microsoft.com/en-us/research/people/yael/ "Yael Kalai") [![Hugo Krawczyk](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Hugo-2018-BIU.jpg?resize=150%2C150&ssl=1)](https://algorand.foundation/who-we-are) ### [Hugo Krawczyk](https://algorand.foundation/who-we-are "Hugo Krawczyk") [Algorand Foundation](https://algorand.foundation/who-we-are "Hugo Krawczyk") [![Aviv Zohar](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/aviv_zohar-e1576008291385.jpg?resize=150%2C150&ssl=1)](http://www.avivz.net/) ### [Aviv Zohar](http://www.avivz.net/ "Aviv Zohar") [Hebrew University, QEDIT](http://www.avivz.net/ "Aviv Zohar") * * * Our Partners ---------------- To learn more about becoming a partner, email us at [\[email protected\]](/cdn-cgi/l/email-protection) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/03/Aleo_Logo.png?fit=1981%2C577&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/AlgorandFoundation_Full-logo_black_small.png?fit=833%2C416&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/logo-new.png?fit=3005%2C680&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/beam.png?fit=1800%2C1800&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/CPIIS.png?fit=605%2C150&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/clearmatics-e1576882710141.png?fit=1548%2C387&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/COBRA-logo_H%C3%BFJOPL%C3%BFSNING-pixel_AU-bla%C2%A6%C3%A8.jpg?fit=822%2C184&ssl=1)](https://cs.au.dk/research/centers/concordium/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/deloitte-e1579330965773.png?fit=1246%2C594&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/DHVCLogo.png?fit=1797%2C630&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/03/ajFYQ0T8.png-large.png?fit=2048%2C1024&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/ethereum-foundation.png?fit=467%2C145&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/11/ethereum-foundation-logo-B01D3C8BAD-seeklogo.com_.png?fit=300%2C93&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/04/Firo-logo-dark.png?fit=4150%2C2167&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/03/logo_color_466x156px.png?fit=650%2C216&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/hacera.jpg?fit=1024%2C340&ssl=1)](https://hacera.com/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/03/HL_LOGO_2_RGB_onLight.png?fit=1856%2C732&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/hyperledger-color.png?fit=1001%2C219&ssl=1)](https://www.hyperledger.org/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/ING.png?fit=1621%2C662&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/09/ingonyama-full-logo-yellow.png?fit=8001%2C4501&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/03/IOHK-png-transparent.png?fit=10001%2C2346&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/03/LeastAuthority_Logo_RGB_Horizontal.png?fit=2208%2C417&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/04/matter_labs_logo_dark.png?fit=3898%2C1080&ssl=1)](https://matter-labs.io/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/ms-logo.jpg?fit=242%2C58&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/mystenlabs2.png?fit=1766%2C225&ssl=1)](https://mystenlabs.com/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/nervos-logo-horizontal.png?fit=1414%2C365&ssl=1)](https://www.nervos.org/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/03/NoviWordmark%402x.png?fit=1059%2C518&ssl=1)](https://research.fb.com/category/blockchain-and-cryptoeconomics/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/protocol-labs-logo-horizontal-alt-black.png?fit=354%2C170&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/qedit-padding.png?fit=1920%2C722&ssl=1)](https://qed-it.com) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/R3Logo.png?fit=800%2C609&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/risc0.png?fit=200%2C200&ssl=1)](https://www.risczero.com/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/stratumn.png?fit=1100%2C196&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/Tezos-Logo.jpg?fit=1341%2C435&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/thunder.png?fit=400%2C400&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/trailofbits-resize.png?fit=2500%2C1128&ssl=1)](https://www.trailofbits.com/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/URVenturesLogo.png?fit=357%2C72&ssl=1)](http://www.rochester.edu/ventures/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/VMware-e1576545210774.jpg?fit=972%2C425&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/zcashfoundation-1.png?fit=2102%2C1663&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/03/ZK_logo_purple-1.png?fit=3175%2C2682&ssl=1) Latest Updates -------------- Unable to load Tweets [](https://twitter.com/share) [Follow](https://twitter.com/zkproof) [View all tweets >](https://twitter.com/zkproof) * * * [](#) --- # The Art of Zero Knowledge - ZKProof Standards The Art of Zero Knowledge ========================= * [Show all](#) * [Webinar](#) * [Standards](#) * [The Art of Zero Knowledge](#) * [ZKProof 5.5 talks summary](#) * [ZKProof Policy @ DC](#) [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/) [![](https://zkproof.org/wp-content/uploads/2024/03/tromer-uai-258x172.png)](https://zkproof.org/2024/04/04/zero-knowledge-financial-regulation-compliance-by-eran-tromer/) April 4, 2024 ### [Zero-Knowledge Financial Regulation Compliance by Eran Tromer](https://zkproof.org/2024/04/04/zero-knowledge-financial-regulation-compliance-by-eran-tromer/) [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/) [![](https://zkproof.org/wp-content/uploads/2024/03/Screenshot-2024-03-19-at-13.14.36-uai-258x172.png)](https://zkproof.org/2024/04/03/nists-views-on-standardisation-of-advanced-cryptography-by-rene-peralta/) April 3, 2024 ### [NISTs Views on Standardisation of Advanced Cryptography by René Peralta](https://zkproof.org/2024/04/03/nists-views-on-standardisation-of-advanced-cryptography-by-rene-peralta/) [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/) [![](https://zkproof.org/wp-content/uploads/2024/03/unnamed-uai-258x172.png)](https://zkproof.org/2024/04/01/privacy-and-compliance-striking-a-delicate-balance-by-pablo-kogan/) April 1, 2024 ### [Privacy and Compliance: Striking a Delicate Balance by Pablo Kogan](https://zkproof.org/2024/04/01/privacy-and-compliance-striking-a-delicate-balance-by-pablo-kogan/) [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/) [![](https://zkproof.org/wp-content/uploads/2024/03/Screenshot-2024-03-21-at-14.52.18-uai-258x172.png)](https://zkproof.org/2024/03/21/zk-proofs-for-balancing-privacy-and-accountability-by-anna-lysyanskaya/) March 21, 2024 ### [ZK Proofs for Balancing Privacy and Accountability by Anna Lysyanskaya](https://zkproof.org/2024/03/21/zk-proofs-for-balancing-privacy-and-accountability-by-anna-lysyanskaya/) [Standards](https://zkproof.org/category/standards/) [![](https://zkproof.org/wp-content/uploads/2023/10/DALL·E-2023-10-19-13.53.26-Illustration-of-a-balance-scale.-On-one-side-theres-a-microchip-representing-ZK-Hardware-and-on-the-other-a-lightning-symbol-representing-energy-J-uai-258x172.png)](https://zkproof.org/2023/10/23/zk-score-blog/) October 23, 2023 ### [ZK Score – ZK hardware ranking standard](https://zkproof.org/2023/10/23/zk-score-blog/)   [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-18-at-10.49.09-uai-258x172.png)](https://zkproof.org/2023/09/18/zkml-where-are-we-now-where-do-we-go-from-here-talk-summary-zkproof-5-5-daniel-kang/) September 18, 2023 ### [Scaling Trustless DNN Inference, zkml applications at ZKProof.org by Daniel Kang](https://zkproof.org/2023/09/18/zkml-where-are-we-now-where-do-we-go-from-here-talk-summary-zkproof-5-5-daniel-kang/) Daniel Kang gave a comprehensive overview of the current capabilities of… [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-12-at-15.03.52-uai-258x172.png)](https://zkproof.org/2023/09/12/zkps-and-post-quantum-signatures-from-vole-in-the-head-at-zkproof-org-by-peter-scholl/) September 12, 2023 ### [ZKPs and Post-Quantum Signatures From VOLE-in-the-Head at ZKProof.org by Peter Scholl](https://zkproof.org/2023/09/12/zkps-and-post-quantum-signatures-from-vole-in-the-head-at-zkproof-org-by-peter-scholl/) Peter presented the FAEST signature scheme, which achieves similar performance to… [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-12-at-14.50.09-uai-258x172.png)](https://zkproof.org/2023/09/12/lessons-from-darpa-sieve-at-zkproof-org-by-james-parker-kimberlee-model/) September 12, 2023 ### [Lessons from DARPA SIEVE at ZKProof.org by James Parker & Kimberlee Model](https://zkproof.org/2023/09/12/lessons-from-darpa-sieve-at-zkproof-org-by-james-parker-kimberlee-model/) James and Kimberlee clearly explained the SIEVE IR, a collaborative specification… [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/) [![](https://zkproof.org/wp-content/uploads/2023/09/02-zkproof5.5_recursive_proof_composition.pptx-uai-258x172.jpg)](https://zkproof.org/2023/09/12/recursive-proof-composition-by-ying-tong-lai/) September 12, 2023 ### [Recursive Proof Composition at ZKProof.org by Ying Tong Lai](https://zkproof.org/2023/09/12/recursive-proof-composition-by-ying-tong-lai/) Ying Tong Lai delivered an illuminating presentation that advanced understanding of… [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/) [![](https://zkproof.org/wp-content/uploads/2023/09/01-zkproof55_2023_Page_36-uai-258x172.jpg)](https://zkproof.org/2023/09/12/plonk-standardization-zkproof-5-5-mary-maller-talk-summary/) September 12, 2023 ### [The Plonk Effort at ZKProof.org by Mary Maller](https://zkproof.org/2023/09/12/plonk-standardization-zkproof-5-5-mary-maller-talk-summary/) Mary Maller's overview of the modular approach to specifying Plonk. In this talk,… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x172.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present Sangria, a Nova-style folding scheme for the… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x172.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation, the Filecoin Foundation, Supranational,… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x172.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin, a recursive zk-SNARK which we will use to… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2021/06/cover_img_setup-uai-258x172.jpg)](https://zkproof.org/2021/06/30/setup-ceremonies/) June 30, 2021 ### [Setup Ceremonies](https://zkproof.org/2021/06/30/setup-ceremonies/) We often refer to zero-knowledge proofs monolithically, but there are many… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2021/06/Zeal-Twitter-banner-2-uai-258x172.png)](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) June 3, 2021 ### [Zebra: Zcash Zero-Knowledge Proofs at Scale](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) The Zcash protocol has used a number of different zk-SNARK proof systems since its… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2021/05/fiber-4814456_1920-uai-258x172.jpg)](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) May 5, 2021 ### [HashWires: Range Proofs from Hash Functions](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) In this two-part extended blog post I will discuss a modular approach to the design… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2020/10/mitchell-luo-cuOKT4AI5Ro-unsplash-uai-258x172.jpg)](https://zkproof.org/2020/10/15/randomness-and-interactions/) October 15, 2020 ### [Playing with Randomness and Interactions to Prove Theorems](https://zkproof.org/2020/10/15/randomness-and-interactions/) In this blog post, I will go back to some of the early results that pioneered the… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) October 15, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part II](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) In this two-part extended blog post I will discuss a modular approach to the design… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) August 12, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part I](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) In this two-part extended blog post I will discuss a modular approach to the design… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2020/06/Untitled_Artwork-uai-258x172.jpg)](https://zkproof.org/2020/06/08/recursive-snarks/) June 8, 2020 ### [Inductive Proof Systems and Recursive SNARKs](https://zkproof.org/2020/06/08/recursive-snarks/) This blog post describes a powerful technique for defining systems that allows for… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2020/03/arfan-a-GVYRkT5f1tA-unsplash-e1584382350753-uai-258x172.jpg)](https://zkproof.org/2020/03/16/sum-checkprotocol/) March 16, 2020 ### [The Unreasonable Power of the Sum-CheckProtocol](https://zkproof.org/2020/03/16/sum-checkprotocol/) When designing an efficient interactive proof system, there is only one hammer you… [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/) [![](https://zkproof.org/wp-content/uploads/2020/02/omar-flores-ZzofPs-xvZk-unsplash-e1582796027210-uai-258x172.jpg)](https://zkproof.org/2020/02/27/zkp-set-membership/) February 27, 2020 ### [Zero-Knowledge Proofs for Set Membership](https://zkproof.org/2020/02/27/zkp-set-membership/) In this post, I will attempt to present the problem of proving set membership in… [Webinar](https://zkproof.org/category/webinar/) [![](https://zkproof.org/wp-content/uploads/2017/03/Webinar-Template-uai-258x172.png)](https://zkproof.org/2020/01/01/fundamentals-of-zero-knowledge/) January 1, 2020 ### [Announcing the Expert Series Webinar on Zero-Knowledge Proofs](https://zkproof.org/2020/01/01/fundamentals-of-zero-knowledge/) ZKProof has joined forces with leading organizations in our ecosystem to launch a… [](#) --- # Gallery - ZKProof Standards Gallery ======= ### ZKProof 6 Berlin [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1828-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1828-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1830-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1830-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1840-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1840-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1844-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1844-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1849-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1849-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1853-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1853-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1855-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1855-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1818-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1818-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1861-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1861-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1873-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1873-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1875-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1875-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1882-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1882-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1886-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1886-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1966-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1966-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1900-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1900-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1919-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1919-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1922-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1922-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1925-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1925-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1933-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1933-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1943-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1943-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1957-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1957-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1965-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1965-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1974-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1974-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1829-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1829-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2022-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2022-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2023-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2023-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2041-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2041-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2055-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2055-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2075-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2075-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2104-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2104-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2106-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2106-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2108-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2108-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2142-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2142-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2114-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2114-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2138-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2138-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2153-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2153-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2175-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2175-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2180-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2180-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2193-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2193-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2217-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2217-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2219-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2219-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2222-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2222-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2232-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2232-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2235-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2235-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2248-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2248-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2272-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2272-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2285-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2285-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2295-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2295-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2303-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2303-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2328-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2328-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2341-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2341-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2371-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2371-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2374-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2374-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2378-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2378-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2383-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2383-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2388-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2388-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2395-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2395-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2404-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2404-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2408-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2408-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2411-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2411-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2412-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2412-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2415-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2415-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2417-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2417-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2420-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2420-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2424-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2424-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2469-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2469-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2405-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2405-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2431-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2431-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2471-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2471-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2499-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2499-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2445-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2445-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2510-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2510-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2520-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2520-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2522-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2522-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2527-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2527-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2529-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2529-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2536-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2536-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2552-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2552-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2555-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2555-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2556-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2556-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2559-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2559-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2561-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2561-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2570-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2570-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2575-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2575-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2581-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2581-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2598-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2598-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2620-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2620-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2626-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2626-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2636-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2636-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2657-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2657-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2660-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2660-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1970-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1970-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2666-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2666-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_1959-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_1959-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2702-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2702-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2711-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2711-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2731-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2731-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2735-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2735-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2743-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2743-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2762-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2762-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2779-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2779-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2783-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2783-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2785-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2785-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2787-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2787-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2800-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2800-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2826-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2826-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2862-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2862-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2867-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2867-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2871-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2871-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2875-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2875-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2902-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2902-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2909-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2909-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2917-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2917-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2920-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2920-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2929-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2929-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2931-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2931-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2937-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2937-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2966-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2966-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2971-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2971-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2998-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2998-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3045-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3045-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3065-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3065-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3067-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3067-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3075-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3075-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3108-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3108-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3110-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3110-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3143-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3143-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3148-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3148-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3186-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3186-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3198-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3198-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3202-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3202-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3208-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3208-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3210-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3210-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3213-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3213-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3218-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3218-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3225-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3225-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2946-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2946-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3250-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3250-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3255-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3255-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3287-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3287-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3289-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3289-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3299-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3299-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3304-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3304-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3437-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3437-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3447-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3447-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3465-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3465-uai-1032x1548.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3469-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3469-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3522-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3522-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3528-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3528-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3529-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3529-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3535-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3535-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3555-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3555-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2938-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2938-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3589-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3589-uai-1032x1548.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3607-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3607-uai-1032x1548.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3610-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3610-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3611-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3611-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3619-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3619-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3629-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3629-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3635-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3635-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3637-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3637-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3649-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3649-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3666-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3666-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3673-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3673-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3681-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3681-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_3715-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_3715-uai-1032x688.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2682-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2682-uai-1032x689.jpg) [### ZKProof 6 Berlin (2024)\ \ ![](https://zkproof.org/wp-content/uploads/2024/06/KHK_2731-1-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/06/KHK_2731-1-uai-1032x689.jpg) ### ZKProof 5 Tel Aviv [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7989-uai-258x387.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7989.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8432-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8432-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE6767-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE6767-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE9250-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE9250-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE9233-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE9233-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE9230-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE9230-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8985-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8985-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8921-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8921-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8890-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8890-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8761-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8761-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8751-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8751-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8739-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8739-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8647-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8647-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE9070-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE9070-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE9276-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE9276-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8394-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8394-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE8335-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE8335-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7900-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7900-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7662-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7662-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7649-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7649-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7652-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7652-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7565-uai-258x387.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7565.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7541-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7541-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7528-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7528-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/01/RONE7520-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7520-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7717-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7717-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7680-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7680-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7581-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7581-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7580-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7580-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7503-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7503-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7227-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7227-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7253-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7253-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7272-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7272-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7323-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7323-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7350-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7350-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7417-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7417-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7441-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7441-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7430-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7430-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7446-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7446-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7494-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7494-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7215-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7215-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7194-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7194-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7111-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7111-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7091-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7091-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7035-uai-258x387.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7035-uai-1032x1547.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7006-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7006-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE6877-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE6877-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE6810-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE6810-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8258-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8258-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE9156-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE9156-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE9179-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE9179-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE9195-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE9195-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE9221-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE9221-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE9306-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE9306-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7941-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7941-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7946-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7946-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8049-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8049-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8063-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8063-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8274-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8274-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE9143-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE9143-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8800-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8800-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8776-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8776-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8735-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8735-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8860-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8860-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE8902-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE8902-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE9016-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE9016-uai-1032x688.jpg) [![](https://zkproof.org/wp-content/uploads/2024/06/RONE7700-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2024/06/RONE7700-uai-1032x688.jpg) ### Past Events [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-63-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-63-uai-1032x688.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-141-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-141-uai-1032x700.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-5-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-5-uai-1032x774.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-129-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-129-uai-1032x688.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-124-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-124-uai-1032x688.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-179-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-179-uai-1032x688.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-98-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-98-uai-1032x688.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-39-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-39-uai-1032x1376.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-22-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-22-uai-1032x688.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-4-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event_2019-4-uai-1032x685.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event-2019_Day-2-127-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event-2019_Day-2-127-uai-1032x688.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event-2019_Day-2-107-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event-2019_Day-2-107-uai-1032x705.jpg) [### ZKProof Community Event Amsterdam (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event-2019_Day-2-65-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZK-Proof-Event-2019_Day-2-65-uai-1032x689.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0253-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0253-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0247-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0247-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0234-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0234-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0200-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0200-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0176-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0176-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0109-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0109-uai-1032x1548.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0073-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0073-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0047-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0047-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0011-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0011-uai-1032x1548.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0005-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0005-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_828-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_828-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_490-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_490-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_484-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_484-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_461-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_461-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_326-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_326-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_152-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_152-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_064-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_064-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190412_1044-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190412_1044-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190412_944-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190412_944-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_711-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_711-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_653-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_653-uai-1032x534.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_630-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_630-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_577-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_577-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_523-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_523-uai-1032x1548.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_513-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_513-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_493-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190411_493-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_440-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_440-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_032-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_032-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_029-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_029-uai-1032x748.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_017-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_017-uai-1032x688.jpg) [### The 2nd ZKProof Standards Workshop (2019)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_005-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/GBP_20190410_005-uai-1032x736.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0653-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0653-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0649-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0649-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0623-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0623-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0528-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0528-uai-1032x581.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0439-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0439-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0422-e1580124997833-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0422-e1580124997833-uai-1032x866.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0394-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0394-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0365-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0365-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0343-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0343-uai-1032x688.jpg) [### The 1st ZKProof Standards Workshop (2018)\ \ ![](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0323-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2020/01/ZKProof-0323-uai-1032x688.jpg) [### RONE7871\ \ ![](https://zkproof.org/wp-content/uploads/2024/01/RONE7871-uai-258x193.jpg)](https://zkproof.org/wp-content/uploads/2024/01/RONE7871-uai-1032x688.jpg) [](#) --- # ZKProof 7 in Sofia - ZKProof Standards **ZKProof 7 in Sofia** ====================== **March 23-25, 2025** --------------------- =============================================== [Watch the streams](https://www.youtube.com/@zkproofstandards1776/playlists) [![](https://zkproof.org/wp-content/uploads/2025/03/Group-photo-with-zk-logo-for-WEB-uai-258x172.jpg)](https://zkproof.org/wp-content/uploads/2025/03/Group-photo-with-no-logo-for-WEB.jpg) #### ZKProof is an initiative focused on the standardization of Zero-Knowledge Proofs. This community of over 1000 practitioners converges stakeholders from academia, startups, and law enforcement, creating a bridge between theory and practical implementation. #### This year we are thrilled to announce that ZKProof7 will occur in Sofia from March 23rd to March 25th! #### It’s perfectly timed – join a week of advanced cryptography, with [RWC](https://rwc.iacr.org/2025/) , HACS and more, so mark your calendars! On the Agenda: * #### **Day 1 (starts at 4:30pm): Kickoff & Keynotes & Kombucha – Special Talk by Ron Rothblum about the Fiat-Shamir attack ** * #### ****Day 2: Identity, TLSNotarization, zkLogin and more – with guest speakers** Dan Boneh**, Muthu Venkitasubramaniam**** * #### **Day 3: zkEVM Formal Verification, the Verified Verifier, PLONK standard – with Alexander Hicks, Eran Tromer** #### Further details will follow. #### Important Information **Date:** March 23-25, 2025 **Registration is closed** **Location:**  [Hilton Sofia, Bulgaria Blvd., Sofia, 1421, Bulgaria](https://www.google.com/maps/search/?api=1&query=Hilton+Sofia%2C+1%2C+Bulgaria+Blvd.+Sofia+BG) [Call for Papers](https://zkproof.org/events/zkproof-7-sofia/call-for-papers-7th-zkproof-workshop/) ### ZKProof 7 : Agenda Speakers ------------ [![Albert Garreta](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Albert-Garreta.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/albert-garreta/) ### [Albert Garreta](https://zkproof.org/team/albert-garreta/ "Albert Garreta") [Nethermind Research](https://zkproof.org/team/albert-garreta/ "Albert Garreta") [![Alexander Hicks](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Alexander-Hicks.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/alexander-hicks/) ### [Alexander Hicks](https://zkproof.org/team/alexander-hicks/ "Alexander Hicks") [Ethereum Foundation](https://zkproof.org/team/alexander-hicks/ "Alexander Hicks") [![Antonio Faonio](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/FAONIO-Antonio_00.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/antonio-faonio/) ### [Antonio Faonio](https://zkproof.org/team/antonio-faonio/ "Antonio Faonio") [EURECOM](https://zkproof.org/team/antonio-faonio/ "Antonio Faonio") [![Arseni Kalma](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Arseni-Kalma.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/arseni-kalma/) ### [Arseni Kalma](https://zkproof.org/team/arseni-kalma/ "Arseni Kalma") [QEDIT](https://zkproof.org/team/arseni-kalma/ "Arseni Kalma") [![Carla Ràfols](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/carla-rafols.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/carla-rafols/) ### [Carla Ràfols](https://zkproof.org/team/carla-rafols/ "Carla Ràfols") [Universitat Pompeu Fabra](https://zkproof.org/team/carla-rafols/ "Carla Ràfols") [![Christian Knabenhans](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Christian-Knabenhans.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/christian-knabenhans/) ### [Christian Knabenhans](https://zkproof.org/team/christian-knabenhans/ "Christian Knabenhans") [EPFL](https://zkproof.org/team/christian-knabenhans/ "Christian Knabenhans") [![Dan Boneh](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/danboneh_a16zcrypto.jpg?resize=150%2C150&ssl=1)](http://crypto.stanford.edu/~dabo/) ### [Dan Boneh](http://crypto.stanford.edu/~dabo/ "Dan Boneh") [Stanford University](http://crypto.stanford.edu/~dabo/ "Dan Boneh") [![Daniele Cozzo](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Daniele-Cozzo.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/daniele-cozzo/) ### [Daniele Cozzo](https://zkproof.org/team/daniele-cozzo/ "Daniele Cozzo") [IMDEA Software Institute](https://zkproof.org/team/daniele-cozzo/ "Daniele Cozzo") [![Eran Tromer](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/CA5_0227_edt2_sqr.jpg?resize=150%2C150&ssl=1)](http://www.tau.ac.il/~tromer/) ### [Eran Tromer](http://www.tau.ac.il/~tromer/ "Eran Tromer") [Professor, Boston University founder, Sealance](http://www.tau.ac.il/~tromer/ "Eran Tromer") [![Eylon Yogev](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/ey.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/eylon-yogev/) ### [Eylon Yogev](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [Professor, Bar-Ilan University](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [![Giacomo Fenzi](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Giacomo-Fenzi.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/giacomo-fenzi/) ### [Giacomo Fenzi](https://zkproof.org/team/giacomo-fenzi/ "Giacomo Fenzi") [EPFL](https://zkproof.org/team/giacomo-fenzi/ "Giacomo Fenzi") [![Helger Lipmaa](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Helger-Lipmaa.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/helger-lipmaa/) ### [Helger Lipmaa](https://zkproof.org/team/helger-lipmaa/ "Helger Lipmaa") [University of Tartu, Estonia](https://zkproof.org/team/helger-lipmaa/ "Helger Lipmaa") [![Hyunok Oh](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Hyunok-Oh.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/hyunok-oh/) ### [Hyunok Oh](https://zkproof.org/team/hyunok-oh/ "Hyunok Oh") [Hanyang University](https://zkproof.org/team/hyunok-oh/ "Hyunok Oh") [![Ilia Vlasov](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Ilia-Vlasov.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ilia-vlasov/) ### [Ilia Vlasov](https://zkproof.org/team/ilia-vlasov/ "Ilia Vlasov") [Nethermind](https://zkproof.org/team/ilia-vlasov/ "Ilia Vlasov") [![James Parker](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/JamesP.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/james-parker/) ### [James Parker](https://zkproof.org/team/james-parker/ "James Parker") [Research Engineer, Galois](https://zkproof.org/team/james-parker/ "James Parker") [![Jan Bobolz](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/jan_photo.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/jan-bobolz/) ### [Jan Bobolz](https://zkproof.org/team/jan-bobolz/ "Jan Bobolz") [University of Edinburgh](https://zkproof.org/team/jan-bobolz/ "Jan Bobolz") [![Jannik Spiessens](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Jannik-Spiessens.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/jannik-spiessens/) ### [Jannik Spiessens](https://zkproof.org/team/jannik-spiessens/ "Jannik Spiessens") [COSIC, KU Leuven](https://zkproof.org/team/jannik-spiessens/ "Jannik Spiessens") [![Jonathan Rouach](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/jonathan-rouach/) ### [Jonathan Rouach](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [Executive Director for ZKProof, CEO and Founder, QEDIT](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [![Lasse Letager Hansen](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Lasse-Letager-Hansen.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/lasse-letager-hansen/) ### [Lasse Letager Hansen](https://zkproof.org/team/lasse-letager-hansen/ "Lasse Letager Hansen") [Aarhus University](https://zkproof.org/team/lasse-letager-hansen/ "Lasse Letager Hansen") [![Masato Tsutsumi](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Masato-Tsutsumi.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/masato-tsutsumi/) ### [Masato Tsutsumi](https://zkproof.org/team/masato-tsutsumi/ "Masato Tsutsumi") [Waseda University](https://zkproof.org/team/masato-tsutsumi/ "Masato Tsutsumi") [![Michael Adjedj](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Michael-ADJEDJ.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/michael-adjedj/) ### [Michael Adjedj](https://zkproof.org/team/michael-adjedj/ "Michael Adjedj") [Fireblocks](https://zkproof.org/team/michael-adjedj/ "Michael Adjedj") [![Michele Orru](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Michele-Orru-2.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/michele-orru/) ### [Michele Orru](https://zkproof.org/team/michele-orru/ "Michele Orru") [CNRS](https://zkproof.org/team/michele-orru/ "Michele Orru") [![Muthu Venkitasubramaniam](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Copy-of-GBP_20190412_1086-e1576450323148.jpg?resize=150%2C150&ssl=1)](https://www.cs.rochester.edu/u/muthuv/) ### [Muthu Venkitasubramaniam](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [Associate Professor, Georgetown University  CTO and co-founder, Ligero Inc.](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [![Oleksandr Kurbatov](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Oleksandr-Kurbatov.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/oleksandr-kurbatov/) ### [Oleksandr Kurbatov](https://zkproof.org/team/oleksandr-kurbatov/ "Oleksandr Kurbatov") [Rarimo protocol](https://zkproof.org/team/oleksandr-kurbatov/ "Oleksandr Kurbatov") [![Pablo Castellanos](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Pablo-Castellanos.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/pablo-castellanos/) ### [Pablo Castellanos](https://zkproof.org/team/pablo-castellanos/ "Pablo Castellanos") [IMDEA Software](https://zkproof.org/team/pablo-castellanos/ "Pablo Castellanos") [![Quang Dao](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Quang-Dao.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/quang-dao/) ### [Quang Dao](https://zkproof.org/team/quang-dao/ "Quang Dao") [CMU School of Computer Science](https://zkproof.org/team/quang-dao/ "Quang Dao") [![Roberto Parisella](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Roberto-Parisella.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/roberto-parisella/) ### [Roberto Parisella](https://zkproof.org/team/roberto-parisella/ "Roberto Parisella") [Simula UiB](https://zkproof.org/team/roberto-parisella/ "Roberto Parisella") [![Ron Rothblum](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Ron-Rothblum.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/ron-rothblum/) ### [Ron Rothblum](https://zkproof.org/team/ron-rothblum/ "Ron Rothblum") [Succinct.](https://zkproof.org/team/ron-rothblum/ "Ron Rothblum") [![Shaltiel Eloul](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Eloul-Shaltiel.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/shaltiel-eloul/) ### [Shaltiel Eloul](https://zkproof.org/team/shaltiel-eloul/ "Shaltiel Eloul") [JPMorgan, Global-Tech.](https://zkproof.org/team/shaltiel-eloul/ "Shaltiel Eloul") [![Sofia Celi](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Sofia-Celi_round_1.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/sofia-celi/) ### [Sofia Celi](https://zkproof.org/team/sofia-celi/ "Sofia Celi") [Brave](https://zkproof.org/team/sofia-celi/ "Sofia Celi") [![Stefanos Chaliasos](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Stefanos-Chaliasos-pic.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/stefanos-chaliasos-2/) ### [Stefanos Chaliasos](https://zkproof.org/team/stefanos-chaliasos-2/ "Stefanos Chaliasos") [Imperial College London](https://zkproof.org/team/stefanos-chaliasos-2/ "Stefanos Chaliasos") [![Thomas den Hollander](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Thomas-den-Hollander.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/thomas-den-hollander/) ### [Thomas den Hollander](https://zkproof.org/team/thomas-den-hollander/ "Thomas den Hollander") [University of the Bundeswehr Munich](https://zkproof.org/team/thomas-den-hollander/ "Thomas den Hollander") [![Tobias Rothmann](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Tobias_Rothmann.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/tobias-rothmann/) ### [Tobias Rothmann](https://zkproof.org/team/tobias-rothmann/ "Tobias Rothmann") [TU Munich](https://zkproof.org/team/tobias-rothmann/ "Tobias Rothmann") [![Ulrich Haboeck](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Ulrich-Haboeck.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/ulrich-haboeck/) ### [Ulrich Haboeck](https://zkproof.org/team/ulrich-haboeck/ "Ulrich Haboeck") [StarkWare](https://zkproof.org/team/ulrich-haboeck/ "Ulrich Haboeck") [![Yash Satsangi](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Yash-Satsangi.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/yash-satsangi/) ### [Yash Satsangi](https://zkproof.org/team/yash-satsangi/ "Yash Satsangi") [JPMorgan, Global-Tech.](https://zkproof.org/team/yash-satsangi/ "Yash Satsangi") [![Ziyi Guan](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/ziyi-guan.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ziyi-guan/) ### [Ziyi Guan](https://zkproof.org/team/ziyi-guan/ "Ziyi Guan") [EPFL](https://zkproof.org/team/ziyi-guan/ "Ziyi Guan") ### Accepted Submissions | Title | Author(s) | | --- | --- | | SNARKs for Virtual Machines are Non-Malleable | Matteo Campanelli (Offchain Labs); Antonio Faonio, Luigi Russo (EURECOM) | | Security Bounds for Proof-Carrying Data from Straightline Extractors | Alessandro Chiesa, Ziyi Guan (EPFL); Shahar Samocha (StarkWare); Eylon Yogev (Bar-Ilan University) | | WHIR: Reed–Solomon Proximity Testing with Super-Fast Verification | Giacomo Fenzi, Alessandro Chiesa (EPFL); Gal Arnon (Weizmann Institute); Eylon Yogev (Bar-Ilan University) | | A Crack in the Firmament: Restoring Soundness of the Orion Proof System and More | Thomas den Hollander, Daniel Slamanig (Universität der Bundeswehr München) | | Blind zkSNARKs for Private Proof Delegation and Verifiable Computation over Encrypted Data | Jannik Spiessens, Jiayi Kang, Frederik Vercauteren (COSIC, KU Leuven); Emad Heydari Beni (Nokia Bell Labs); Mariana Botelho da Gama (COSIC, KU Leuven) | | Relativized Succinct Arguments in the ROM Do Not Exist | Annalisa Barbara (Bocconi University); Alessandro Chiesa, Ziyi Guan (EPFL) | | Private, Auditable, and Distributed Ledger for Financial Institutes | Shaltiel Eloul, Yash Satsangi (JP Morgan Chase); Yeoh Wei Zhu (CISPA Helmholtz Center/JP Morgan Chase) | | Towards a verified Jolt zkVM | James Parker, Ben Hamlin, Benoit Razet, Ben Selfridge, Brett Decker (Galois, Inc.) | | Towards a Formal Foundation for Blockchain ZK Rollups | Stefanos Chaliasos (Imperial College London); Denis Firsov (Input Output); Ben Livshits (Imperial College London) | | Application of ZK Proofs to MPC: Round-Optimized 2PC ECDSA at the Cost of only 1 OLE | Michael Adjedj, Constantin Blokh (Fireblocks); Geoffroy Couteau (CNRS, IRIF); Antoine Joux (CISPA Helmholtz Center for Information Security); Nikolaos Makriyannis (Fireblocks) | | Benchmarking zkVMs: Efficiency, Bottlenecks, and Best Practices | Masato Tsutsumi, Kazue Sako (Waseda University) | | Groth16 is UC-Secure: The Brave New World of Global Generic Groups and UC-Secure Zero-Overhead SNARKs | Jan Bobolz (University of Edinburgh); Pooya Farshim (Durham University, IOG); Markulf Kohlweiss (University of Edinburgh, IOG); Akira Takahashi (JPMorgan AI Research & AlgoCRYPT CoE) | | On the Fiat–Shamir Security of FIOP-Based Succinct Arguments | Alessandro Chiesa, Ziyi Guan, Christian Knabenhans, Zihan Yu (EPFL) | | Polymath: Groth16 Is Not The Limit | Helger Lipmaa (University of Tartu) | | On the Formal Verification of Polynomial Commitment Schemes: the KZG and beyond | Tobias Rothmann (Technical University of Munich (TUM), Arcium) | | On Knowledge-Soundness of Plonk in ROM from Falsifiable Assumptions | Helger Lipmaa (University of Tartu); Roberto Parisella (Simula UiB); Janno Siim (University of Tartu) | | Verifiable Computation for Approximate Homomorphic Encryption Schemes | Daniele Cozzo (IMDEA Software Institute); Anamaria Costache (Norwegian University of Science and Technology (NTNU)); Ignacio Cascudo, Dario Fiore, Antonio Guimarães (IMDEA Software Institute); Eduardo Soria Vazquez (Technology Innovation Institute) | | Recursive Proofs and Private Delegation of zkSNARK Provers from Amortized Holography | Carla Ràfols, Nikitas Paslis (Universitat Pompeu Fabra); Alexandros Zacharakis (No affiliation) | | PLINK: Verified Generation of Constraints for PLONK | Pablo Castellanos, Ignacio Cascudo, Dario Fiore, Niki Vazou (IMDEA Software Institute) | | zkVoting: Zero-knowledge proof based coercion-resistant and E2E verifiable e-voting system and its application to national election commission of the Republic of Korea | Seongho Park (Hanyang University); Jaekyoung Choi (Zkrypto); Jihye Kim (Kookmin University); Hyunok Oh (Hanyang University) | | ZK-SecreC: a Domain-Specific Language for Zero-Knowledge Proofs | Raul-Martin Rebane, Peeter Laud (Cybernetica AS) | | Using Hax for Correct and Secure Zero-Knowledge Implementations | Lasse Letager Hansen, Bas Spitters, Eske Hoy Nielsen (Aarhus University) | | Zinc: a hash-based SNARK without arithmetization overheads | Luca Dall'Ava, Albert Garreta, Katerina Hristova, Hendrik Waldner (Nethermind) | | Implementing LatticeFold: Advancing Post-Quantum Folding | Ilia Vlasov, Isaac Villalobos, Matthew A. Klein, Marko Čupić, Emanuel S. Vieira, Albert Garreta, Antonio Larriba (Nethermind) | Program Chairs ------------------ [![Eran Tromer](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/CA5_0227_edt2_sqr.jpg?resize=150%2C150&ssl=1)](http://www.tau.ac.il/~tromer/) ### [Eran Tromer](http://www.tau.ac.il/~tromer/ "Eran Tromer") [Professor, Boston University founder, Sealance](http://www.tau.ac.il/~tromer/ "Eran Tromer") [![Ran Canetti](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/ran_canetti-e1576008389650.jpg?resize=150%2C150&ssl=1)](https://www.cs.tau.ac.il/~canetti/) ### [Ran Canetti](https://www.cs.tau.ac.il/~canetti/ "Ran Canetti") [Boston University, Tel Aviv University](https://www.cs.tau.ac.il/~canetti/ "Ran Canetti") Program Committee --------------------- [![Michel Abdalla](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/01/2022-07-Michel.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/michel-abdalla/) ### [Michel Abdalla](https://zkproof.org/team/michel-abdalla/ "Michel Abdalla") [Nexus](https://zkproof.org/team/michel-abdalla/ "Michel Abdalla") [![Dahlia Malkhi](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/11/dahliabest.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/dahlia-malkhi/) ### [Dahlia Malkhi](https://zkproof.org/team/dahlia-malkhi/ "Dahlia Malkhi") [Professor of Computer Science, UC Santa Barbara, and Distinguished Scientist, Chainlink Labs](https://zkproof.org/team/dahlia-malkhi/ "Dahlia Malkhi") [![Ruihan Wang](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/03/WhatsApp-Image-2024-02-29-at-20.16.13.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ruihan-wang/) ### [Ruihan Wang](https://zkproof.org/team/ruihan-wang/ "Ruihan Wang") [Ligero, Inc.](https://zkproof.org/team/ruihan-wang/ "Ruihan Wang") [![Eylon Yogev](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/ey.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/eylon-yogev/) ### [Eylon Yogev](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [Professor, Bar-Ilan University](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [![Ariel Gabizon](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/Ariel-Gabilzon.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ariel-gabilzon/) ### [Ariel Gabizon](https://zkproof.org/team/ariel-gabilzon/ "Ariel Gabizon") [Aztec Labs](https://zkproof.org/team/ariel-gabilzon/ "Ariel Gabizon") [![Pablo Kogan](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/Pablo-pic.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/pablo-kogan/) ### [Pablo Kogan](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [Director of Engineering, QEDIT](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [![James Parker](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/JamesP.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/james-parker/) ### [James Parker](https://zkproof.org/team/james-parker/ "James Parker") [Research Engineer, Galois](https://zkproof.org/team/james-parker/ "James Parker") [![Carmit Hazay](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/carmitHazay-e1579981003254.jpg?resize=150%2C150&ssl=1)](https://www.eng.biu.ac.il/hazay/) ### [Carmit Hazay](https://www.eng.biu.ac.il/hazay/ "Carmit Hazay") [Professor, Bar-Ilan University; Co-founder, Ligero](https://www.eng.biu.ac.il/hazay/ "Carmit Hazay") [](https://twitter.com/CarmitHazay "twitter") [](https://www.eng.biu.ac.il/hazay/ "globe") [![Muthu Venkitasubramaniam](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Copy-of-GBP_20190412_1086-e1576450323148.jpg?resize=150%2C150&ssl=1)](https://www.cs.rochester.edu/u/muthuv/) ### [Muthu Venkitasubramaniam](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [Associate Professor, Georgetown University  CTO and co-founder, Ligero Inc.](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [![Dan Boneh](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/danboneh_a16zcrypto.jpg?resize=150%2C150&ssl=1)](http://crypto.stanford.edu/~dabo/) ### [Dan Boneh](http://crypto.stanford.edu/~dabo/ "Dan Boneh") [Stanford University](http://crypto.stanford.edu/~dabo/ "Dan Boneh") Our Sponsors ---------------- To learn more about becoming a sponsor, email us at [\[email protected\]](/cdn-cgi/l/email-protection) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/ef.webp?fit=800%2C259&ssl=1)](https://ethereum.foundation/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/qedit-padding.png?fit=1920%2C722&ssl=1)](https://qed-it.com) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Gradient_large.png?fit=6000%2C2509&ssl=1)](https://inversed.tech/) [![](https://zkproof.org/wp-content/uploads/2025/02/ligero_new.svg)](https://ligero-inc.com/) [![](https://zkproof.org/wp-content/uploads/2025/02/starkware.svg)](https://starkware.co/) #### The event will be held in Sofia, Bulgaria Hotel [Hilton Sofia](https://www.google.com/maps/search/?api=1&query=Hilton+Sofia%2C+1%2C+Bulgaria+Blvd.+Sofia+BG) [](#) --- # The Art of Zero Knowledge Archives - ZKProof Standards The Art of Zero Knowledge ========================= [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x172.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present Sangria, a Nova-style… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x172.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation, the Filecoin… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x172.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin, a recursive zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) [![](https://zkproof.org/wp-content/uploads/2021/06/cover_img_setup-uai-258x172.jpg)](https://zkproof.org/2021/06/30/setup-ceremonies/) June 30, 2021 ### [Setup Ceremonies](https://zkproof.org/2021/06/30/setup-ceremonies/) We often refer to zero-knowledge proofs monolithically, but… * * * [![](https://secure.gravatar.com/avatar/269929faf63fc4a46e78e3414a9e5e91?s=40&d=identicon&r=g)by Anthony Mpho Matlala](https://zkproof.org/author/tony007matlala/) [![](https://zkproof.org/wp-content/uploads/2021/06/Zeal-Twitter-banner-2-uai-258x172.png)](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) June 3, 2021 ### [Zebra: Zcash Zero-Knowledge Proofs at Scale](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) The Zcash protocol has used a number of different zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/b0a4d5878b49d2ddc7d783b4fa35105e?s=40&d=identicon&r=g)by Teor](https://zkproof.org/author/teor/) [![](https://zkproof.org/wp-content/uploads/2021/05/fiber-4814456_1920-uai-258x172.jpg)](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) May 5, 2021 ### [HashWires: Range Proofs from Hash Functions](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/651414b06e6324585def2c030b35590a?s=40&d=identicon&r=g)by Kostas Chalkias](https://zkproof.org/author/kostascrypto/) [![](https://zkproof.org/wp-content/uploads/2020/10/mitchell-luo-cuOKT4AI5Ro-unsplash-uai-258x172.jpg)](https://zkproof.org/2020/10/15/randomness-and-interactions/) October 15, 2020 ### [Playing with Randomness and Interactions to Prove Theorems](https://zkproof.org/2020/10/15/randomness-and-interactions/) In this blog post, I will go back to some of the early… * * * [![](https://secure.gravatar.com/avatar/dc3f0db7d6834d4f4d8308e5e309d092?s=40&d=identicon&r=g)by Antoine Rondelet](https://zkproof.org/author/antoinerondelet/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) October 15, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part II](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) August 12, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part I](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [![](https://zkproof.org/wp-content/uploads/2020/06/Untitled_Artwork-uai-258x172.jpg)](https://zkproof.org/2020/06/08/recursive-snarks/) June 8, 2020 ### [Inductive Proof Systems and Recursive SNARKs](https://zkproof.org/2020/06/08/recursive-snarks/) This blog post describes a powerful technique for defining… * * * [![](https://secure.gravatar.com/avatar/77741d2b0efc0c5077e3938b8f9c8c71?s=40&d=identicon&r=g)by Izaak Meckler](https://zkproof.org/author/izaakm/) * 1 * [2](https://zkproof.org/category/the-art-of-zero-knowledge/page/2/) * [](https://zkproof.org/category/the-art-of-zero-knowledge/page/2/) [](#) [ZKProof Standards](https://zkproof.org/) [Proudly powered by WordPress](https://wordpress.org/) Theme: Uncode. [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Sangria: a Folding Scheme for PLONK - ZKProof Standards February 21, 2023|In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |18 Minutes Sangria: a Folding Scheme for PLONK =================================== [![ZKProof Standards](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)](https://zkproof.org/author/contact70d66e844e/) By [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x257.png)](#) Nico Mohnblatt As shown in Nova [\[KST22\]](https://eprint.iacr.org/2021/370) , incrementally verifiable computation (IVC) can be realised using a folding scheme and a zkSNARK. In this article, we present a folding scheme for a variant of the PLONK arithmetization [\[GWC19\]](https://eprint.iacr.org/2019/953) . We then extend our relaxed PLONK arithmetization to accept custom gates of degree 2 and circuits with higher gate arity. Finally we outline avenues for future work including folding higher degree gates, supporting lookup gates and designing an IOP for the relaxed PLONK arithmetization. > ⚠️ This article is a condensed version of the [Sangria technical note](https://github.com/geometryresearch/technical_notes/blob/main/sangria_folding_plonk.pdf) > . See the full version for proofs and extended discussions. We assume the reader is familiar with IVC and Nova. Suggested preliminary viewing and reading: [Justin Drake’s ZK Whiteboard Session](https://youtu.be/SwonTtOQzAk) >  and this [Lambdaclass blog entry](https://www.notamonadtutorial.com/incrementally-verifiable-computation-nova/) > .\* Preliminaries ------------- ### PLONK Arithmetization In PLONK, computations are represented as a matrix $\\mathbf{M}$ with three columns $\\mathbf{a}, \\mathbf{b}, \\mathbf{c}$ and $n+s+1$ rows. $n$ is the number of public inputs, $s$ is the number of gates and the extra row checks that the final result is 1 (i.e. that the circuit is satisfied). ![](https://i0.wp.com/i.imgur.com/9SBefJp.png?w=840&ssl=1) A PLONK computation trace The values at the $i$-th row — $\\mathbf{a}\_i, \\mathbf{b}\_i, \\mathbf{c}\_i$ — correspond respectively to the left input, right input and output of the $i$-th gate. The $i$-th gate is defined as: $$ C\_{\\mathcal{Q}, i}(\\mathbf{a}, \\mathbf{b}, \\mathbf{c}) := (\\mathbf{q\_L})\_i\\mathbf{a}\_i + (\\mathbf{q\_R})\_i\\mathbf{b}\_i + (\\mathbf{q\_O})\_i\\mathbf{c}\_i + (\\mathbf{q\_M})\_i\\mathbf{a}\_i\\mathbf{b}\_i + (\\mathbf{q\_C})\_i $$ where $(\\mathbf{q\_L})\_i, (\\mathbf{q\_R})\_i, (\\mathbf{q\_O})\_i, (\\mathbf{q\_M})\_i, (\\mathbf{q\_C})\_i$ are the $i$-th value of each selector vector. We denote $\\mathcal{Q} = \\left\\{\\mathbf{q\_L}, \\mathbf{q\_R}, \\mathbf{q\_O}, \\mathbf{q\_M}, \\mathbf{q\_C} \\right\\}$ the set of selector vectors. Gates are “wired” together using copy constraints enforcing for example that $\\mathbf{a}\_3 = \\mathbf{c}\_1$ — the left input to Gate 3 is the output of Gate 1. We denote $\\mathcal{S}$ the set of copy constraints. A circuit is fully defined by the tuple $(\\mathcal{Q}, \\mathcal{S})$. ### Folding Schemes The Nova paper introduces folding schemes and provide the following intuitive definition: \> \[…\] a folding scheme for a relation $\\mathcal{R}$ is a protocol that reduces the task of checking two instances in $\\mathcal{R}$ to the task of checking a single instance in $\\mathcal{R}$. The full definition is given in the paper under Definition 6. ### Commitment Schemes Our scheme makes use of a hiding and binding additively homomorphic commitment scheme for vectors of elements in a finite field $\\mathbb{F}$. We denote such a scheme as $\\mathsf{Com}$ and write $\\overline{A} = \\mathsf{Com}(\\mathsf{pp}\_C, \\mathbf{a};{r})$ a commitment to the vector $\\mathbf{a}$ using randomness value $r \\in \\mathbb{F}$ and commitment parameters $\\mathsf{pp}\_C$. Sangria ------- Nova builds a folding scheme for the R1CS arithmetization. Here we present a folding scheme for the PLONK arithmetization. We use the same insights as Nova: – folding is performed by taking a \*\*random linear combination\*\* of the input instance-witness pairs. – cross terms are absorbed into an \*\*error\*\* (or slack) vector and a \*\*scaling factor\*\*. – the scheme is made non-trivial by working over \*\*additively homomorphic commitments\*\* to the witness and slack vector. ### Relaxed PLONK Gate Equation For a scalar $u \\in \\mathbb{F}$ and error (or slack) vector $\\mathbf{e} \\in \\mathbb{F}^{n+s+1}$ we define the relaxed PLONK gate equation as: $$ \\begin{equation} C’\_{\\mathcal{Q}, i}(\\mathbf{a}, \\mathbf{b}, \\mathbf{c}, u, {\\mathbf{e}}) := {u}\\left\[(\\mathbf{q\_L})\_i\\mathbf{a}\_i + (\\mathbf{q\_R})\_i\\mathbf{b}\_i + (\\mathbf{q\_O})\_i\\mathbf{c}\_i \\right\] + (\\mathbf{q\_M})\_i\\mathbf{a}\_i\\mathbf{b}\_i + (\\mathbf{q\_C})\_i + {\\mathbf{e}\_i} \\end{equation} $$ Copy constraints in relaxed PLONK are identical to the PLONK copy constraints. A relaxed PLONK trace is represented by the tuple $(\\mathbf{a}, \\mathbf{b}, \\mathbf{c}, u, \\mathbf{e})$. For a PLONK instance-witness pair $(\\mathbf{X}, \\mathbf{W})$, we define a relaxed PLONK instance-witness pair $(U, W)$ as: $$ \\begin{align} U &:= (\\mathbf{X}, u, \\overline{W\_a}, \\overline{W\_b}, \\overline{W\_c}, \\overline{E}) \\\\ W &:= (\\mathbf{W}, \\mathbf{e}, r\_a, r\_b, r\_c, r\_{e}) \\end{align} $$ where $\\overline{W\_a} = \\mathsf{Com}({\\mathsf{pp}\_W},{\\mathbf{w\_a}};{r\_a})$, $\\overline{W\_b} = \\mathsf{Com}({\\mathsf{pp}\_W},{\\mathbf{w\_b}};{r\_b})$, $\\overline{W\_c} = \\mathsf{Com}({\\mathsf{pp}\_W},{\\mathbf{w\_c}};{r\_c})$ and $\\overline{E} = \\mathsf{Com}({\\mathsf{pp}\_E},{\\mathbf{e}};{r\_e})$. Importantly, any PLONK relation can be transformed into a relaxed PLONK relation by setting $u=1$, $\\mathbf{e} = \\overrightarrow{0}$ and providing the necessary commitments. Thus the relaxed PLONK arithmetization is $\\mathsf{NP}$-complete. ### Folding Scheme for Relaxed PLONK Following the notation from Nova, a folding scheme is defined by 4 algorithms $\\mathcal{G}, \\mathcal{K}, \\mathcal{P}, \\mathcal{V}$: – $\\mathcal{G}(1^\\lambda) \\rightarrow \\mathsf{pp}$: output size bounds $n, s \\in \\mathbb{N}$ and commitment parameters $\\mathsf{pp}\_W$ and $\\mathsf{pp}\_E$ for vectors of size $s$ and $n+s+1$ respectively. – $\\mathcal{K}(\\mathsf{pp}, (\\mathcal{Q}, \\mathcal{S})) \\rightarrow (\\mathsf{pk}, \\mathsf{vk})$: pick $r\_{q\_C} \\leftarrow \\mathbb{F}$ and compute $\\overline{Q\_C} = \\mathsf{Com}({\\mathsf{pp}\_E},{\\mathbf{q\_C}};{r\_{q\_C}})$. Output $\\mathsf{vk} \\leftarrow \\overline{Q\_C}$ and $\\mathsf{pk} \\leftarrow (\\mathsf{pp}, \\mathsf{vk}, (\\mathcal{Q, \\mathcal{S}}), r\_{q\_C})$. The verifier $\\mathcal{V}$ is given the verifier key $\\mathsf{vk}$ and two committed relaxed PLONK instances, $\\left(\\mathbf{X’}, u’, \\overline{W’\_a}, \\overline{W’\_b}, \\overline{W’\_c}, \\overline{E’} \\right)$ and $\\left(\\mathbf{X”}, u”, \\overline{W”\_a}, \\overline{W”\_b}, \\overline{W”\_c}, \\overline{E”} \\right)$. The prover $\\mathcal{P}$ is given the prover key $\\mathsf{pk}$ and both instances with their corresponding witnesses $\\left( \\mathbf{W’}, \\mathbf{e’}, r’\_a, r’\_b, r’\_c, r’\_{e} \\right)$ and $\\left( \\mathbf{W”}, \\mathbf{e”}, r”\_a, r”\_b, r”\_c, r”\_{e} \\right)$. The Sangria folding scheme proceeds as follows: 1\. $\\mathcal{P}$ samples $r\_t$ at random and sends $\\overline T = \\mathsf{Com}({\\mathsf{pp}\_E},{\\mathbf{t}};{r\_t})$ where $\\mathbf{t}$ is computed as: $$\\begin{equation} \\mathbf{t} := u”(\\mathbf{q\_L}\\circ\\mathbf{a’} + \\mathbf{q\_R}\\circ\\mathbf{b’} + \\mathbf{q\_O}\\circ\\mathbf{c’}) + u'(\\mathbf{q\_L}\\circ\\mathbf{a”} + \\mathbf{q\_R}\\circ\\mathbf{b”} + \\mathbf{q\_O}\\circ\\mathbf{c”}) + \\mathbf{q\_M} \\circ (\\mathbf{a’}\\circ\\mathbf{b”} + \\mathbf{a”}\\circ\\mathbf{b’}) \\end{equation} $$ where $\\circ$ denotes element-wise multiplication. 2\. $\\mathcal{V}$ samples the challenge $r$ at random. 3\. $\\mathcal{P}$ and $\\mathcal{V}$ output the folded instance $(\\mathbf{X}, u, \\overline{W\_a}, \\overline{W\_b}, \\overline{W\_c}, \\overline{E})$ where: $$ \\begin{align} \\mathbf{X} &\\leftarrow \\mathbf{X’} + r\\mathbf{X”} \\\\ u &\\leftarrow u’ + ru” \\\\ \\overline{W\_a} &\\leftarrow \\overline{W’\_a} + r\\overline{W”\_a} \\\\ \\overline{W\_b} &\\leftarrow \\overline{W’\_b} + r\\overline{W”\_b} \\\\ \\overline{W\_c} &\\leftarrow \\overline{W’\_c} + r\\overline{W”\_c} \\\\ \\overline{E} &\\leftarrow \\overline{E’} – r\\overline{T} + r^2 (\\overline{E”} + \\mathsf{vk}.\\overline{Q\_C}) \\end{align} $$ 4\. $\\mathcal{P}$ outputs the folded witness $\\left( \\mathbf{W}, \\mathbf{e}, r\_a, r\_b, r\_c, r\_e \\right)$ where: $$ \\begin{align} \\mathbf{W} &\\leftarrow \\mathbf{W’} + r\\mathbf{W”} \\\\ r\_a &\\leftarrow r’\_{a} + r \\cdot r”\_{a} \\\\ r\_b &\\leftarrow r’\_{b} + r \\cdot r”\_{b} \\\\ r\_c &\\leftarrow r’\_{c} + r \\cdot r”\_{c} \\\\ \\mathbf{e} &\\leftarrow \\mathbf{e’} – r\\mathbf{t} + r^2 (\\mathbf{e”} + \\mathsf{pk}.\\mathbf{q\_C}) \\\\ r\_e &\\leftarrow r’\_{e} – r \\cdot r\_t + r^2 \\cdot (r”\_{e} + \\mathsf{pk}.r\_{q\_C}) \\end{align} $$ **Theorem**: The above construction is a public-coin folding scheme for the committed relaxed PLONK arithmetization with perfect completeness, knowledge soundness, and zero-knowledge. **_Proof intuition:_** Perfect completeness can be shown by following the algebra until establishing that $$ C’\_{\\mathcal{Q}, i}(\\mathbf{a}, \\mathbf{b}, \\mathbf{c}, u, \\mathbf{e}) = C’\_{\\mathcal{Q}, i}(\\mathbf{a’}, \\mathbf{b’}, \\mathbf{c’}, u’, \\mathbf{e’}) + r^2 C’\_{\\mathcal{Q}, i}(\\mathbf{a”}, \\mathbf{b”}, \\mathbf{c”}, u”, \\mathbf{e”}) $$ We also show that copy constraints are preserved. We prove knowledge soundness using the same strategy as \[\[KST22\]\]([https://eprint.iacr.org/2021/370](https://eprint.iacr.org/2021/370) ). Specifically, we apply the forking lemma for folding schemes (Lemma 1 in \[\[KST22\]\]([https://eprint.iacr.org/2021/370](https://eprint.iacr.org/2021/370) )) to obtain three transcripts. We then show that the extractor uses all three transcripts to interpolate the original $\\mathbf{e’}, r’\_e$ and $\\mathbf{e”}, r”\_e$ values, and any two transcripts to interpolate the values $(\\mathbf{W’}, r’\_a, r’\_b, r’\_c)$ and $(\\mathbf{W”}, r”\_a, r”\_b, r”\_c)$. We then show that the interpolated values belong to traces that each satisfy the circuit’s gate equalities and copy constraints. Finally zero-knowledge holds as the prover’s messages are hiding commitments and the verifier only sends a public random value. A proof is presented in the \[full technical note\]([https://github.com/geometryresearch/technical\_notes/blob/main/sangria\_folding\_plonk.pdf](https://github.com/geometryresearch/technical_notes/blob/main/sangria_folding_plonk.pdf) ). $\\square$ ### Degree 2 Custom Gates We write a degree 2 custom gate and its selector as: $$ \\begin{equation} G\_i(\\mathbf{a}, \\mathbf{b}, \\mathbf{c}) := (\\mathbf{q\_G})\_i \\cdot g(\\mathbf{a}\_i, \\mathbf{b}\_i, \\mathbf{c}\_i) \\end{equation} $$ To fold such a gate, write $g$ as a sum of monomials and separate the monomials by their degrees. Let $g\_C$, $g\_1$ and $g\_2$ be the sums of the constant, degree 1 and degree 2 monomials respectively. We can write the relaxed constraint equation as: $$ \\begin{align} C’\_{\\mathcal{Q}, i}(\\mathbf{a}, \\mathbf{b}, \\mathbf{c}, u, \\mathbf{e}) &:= u\\left\[(\\mathbf{q\_L})\_i\\mathbf{a}\_i + (\\mathbf{q\_R})\_i\\mathbf{b}\_i + (\\mathbf{q\_O})\_i\\mathbf{c}\_i + {(\\mathbf{q\_G})\_i \\cdot g\_1(\\mathbf{a}\_i, \\mathbf{b}\_i, \\mathbf{c}\_i)} \\right\] \\\\ &\\qquad + (\\mathbf{q\_M})\_i\\mathbf{a}\_i\\mathbf{b}\_i + {(\\mathbf{q\_G})\_i \\cdot g\_2(\\mathbf{a}\_i, \\mathbf{b}\_i, \\mathbf{c}\_i)} + (\\mathbf{q\_C})\_i + {(\\mathbf{q\_G})\_i \\cdot g\_C} + \\mathbf{e}\_i \\end{align} $$ Folding $(\\mathbf{a’}, \\mathbf{b’}, \\mathbf{c’}, u’, \\mathbf{e’})$ with $(\\mathbf{a”}, \\mathbf{b”}, \\mathbf{c”}, u”, \\mathbf{e”})$ is still performed by taking random linear combinations, however the $\\mathbf{t}$ vector must be adjusted to absorb the cross terms that arise from each of the following degree 2 expressions: – $(u’ + u”)\\bigl\[(\\mathbf{q\_L})\_i(\\mathbf{a’}\_i + \\mathbf{a”}\_i) + (\\mathbf{q\_R})\_i(\\mathbf{b’}\_i + \\mathbf{b”}\_i) + (\\mathbf{q\_O})\_i(\\mathbf{c’}\_i + \\mathbf{c”}\_i) + {(\\mathbf{q\_G})\_i \\cdot g\_1((\\mathbf{a’}\_i + \\mathbf{a”}\_i), (\\mathbf{b’}\_i + \\mathbf{b”}\_i), (\\mathbf{c’}\_i + \\mathbf{c”}\_i))} \\bigr\]$ – $(\\mathbf{q\_M})\_i(\\mathbf{a’}\_i + \\mathbf{a”}\_i)(\\mathbf{b’}\_i + \\mathbf{b”}\_i)$ – $(\\mathbf{q\_G})\_i \\cdot g\_2\\left((\\mathbf{a’}\_i + \\mathbf{a”}\_i), (\\mathbf{b’}\_i + \\mathbf{b”}\_i), (\\mathbf{c’}\_i + \\mathbf{c”}\_i)\\right)$ ### Higher Fan-In and Fan-Out The current scheme can support higher arity circuits as long as the degree of the gate equation is smaller or equal to 2. Each additional gate input or output requires an additional witness column commitment. Future Work ----------- This note establishes a folding scheme for the standard PLONK arithmetization and introduces some customisation features. We conclude by briefly highlighting directions for future (and upcoming) work. ### Succinct IVC using a zkSNARK for Sangria Nova shows that a folding scheme directly implies IVC. However those IVC proofs are neither succinct nor zero-knowledge. To achieve both of these properties, one must devise a zkSNARK for the newly relaxed arithmetization. One possible direction is to convert the Sangria trace into a PLONKish trace with an extra witness column for the slack vector. Another direction would be to modify the IOP directly to manage the newly introduced $u$ and $\\mathbf{e}$ values. ### Lower Recursion Overhead In the current construction, the folding verifier works with 1 commitment per witness column. The scheme can also work by flattening the witness matrix $\\mathbf{W}$ into a single column vector, thus allowing the verifier to work with a single witness commitment (as in Nova). Doing so requires the reference string $\\mathsf{pp}\_W$ to be three times longer for a circuit with “fan-in 2, fan-out” 1 gates. It might also introduce extra checks and commitment openings later in the full IVC scheme given that the standard PLONK IOP uses commitments to each witness column. ### Higher Degree Custom Gates Higher degree custom gates can be achieved in the “random linear combination” folding strategy. They will potentially require the introduction of more scaling factors ($d-1$ for a degree $d$ gate). The number of cross terms will also grow, leading to a bigger and more computationally intensive expression for $\\mathbf{t}$. **Degree 3.** A suggestion using the random linear combination strategy for degree 3 gates using two scalars $u$ and $v$: $$ \\begin{equation} v \\bigl\[ u\\left\[(\\mathbf{q\_L})\_i\\mathbf{a}\_i + (\\mathbf{q\_R})\_i\\mathbf{b}\_i + (\\mathbf{q\_O})\_i\\mathbf{c}\_i \\right\] + (\\mathbf{q\_M})\_i\\mathbf{a}\_i\\mathbf{b}\_i \\bigr\] + (\\mathbf{q\_{3}})\_i \\mathbf{a}\_i\\mathbf{b}\_i\\mathbf{c}\_i + (\\mathbf{q\_C})\_i + \\mathbf{e}\_i \\end{equation} $$ where the error term is appropriately adjusted to absorb cross terms. ### Lookup Gates PLONKish arithmetizations differentiate themselves from R1CS in part by their ability to integrate lookup arguments. We are keen to preserve this flexibility by developing folding strategies for lookup-enabled arithmetizations. Acknowledgments --------------- We thank Andrija Novakovic, Lai Ying Tong, Kobi Gurkan and Koh Wei Jie for their helpful inputs and contribution. References ---------- [\[GWC19\]](https://eprint.iacr.org/2019/953)  Gabizon, Ariel, Zachary J. Williamson, and Oana Ciobotaru. Plonk: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge. Cryptology ePrint Archive, Paper 2019/953, 2019. [https://eprint.iacr.org/2019/953](https://eprint.iacr.org/2019/953) [\[KST22\]](https://eprint.iacr.org/2021/370)   Kothapalli, Abhiram, Srinath Setty, and Ioanna Tzialla. “Nova: Recursive zero-knowledge arguments from folding schemes.” Annual International Cryptology Conference. Springer, Cham, 2022. [https://eprint.iacr.org/2021/370](https://eprint.iacr.org/2021/370) * * * ![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Jonathan Gross, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=200&d=identicon&r=g) Jonathan Gross ============== November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation, the Filecoin Foundation, Supranational, Microsoft Research, and the Electric Coin Company are pleased to announce a collaboration to… * * * [0 Comments](https://zkproof.org/2021/11/24/practical-snark-based-vdf/#respond "title") 11 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Ulrich Haböck, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=200&d=identicon&r=g) Ulrich Haböck ============= September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin, a recursive zk-SNARK which we will use to build Latus sidechains, i.e. succinct blockchains of Horizen’s Zendoo ecosystem. * * * [0 Comments](https://zkproof.org/2021/09/29/darlin-recursive-proofs/#respond "title") 18 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Practical SNARK-based VDF - ZKProof Standards November 24, 2021|In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |11 Minutes Practical SNARK-based VDF ========================= [![Jonathan Gross](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)](https://zkproof.org/author/jpgross3/) By [Jonathan Gross](https://zkproof.org/author/jpgross3/) Collaboration Introduction -------------------------- [Protocol Labs](https://protocol.ai/) , the [Ethereum Foundation](https://ethereum.org/en/foundation/) , the [Filecoin Foundation](https://fil.org/) , [Supranational](https://www.supranational.net/) , [Microsoft Research](https://www.microsoft.com/en-us/research/) , and the [Electric Coin Company](https://electriccoin.co/) are pleased to announce a collaboration to improve the performance of SNARKs and to produce a practical SNARK-based VDF design and implementation. SNARKs and [verifiable delay functions](https://eprint.iacr.org/2018/601.pdf) (or VDFs) have the potential to improve the security, privacy, and scalability of blockchain platforms. Privacy and scalability are two of the main concerns that prevent the broader use of blockchain in many end-user applications. By developing new SNARK systems with expanded capabilities and accelerating the cryptographic primitives at the core of them, we can leverage novel cryptography to help address these concerns. With these improved capabilities we hope to unlock new use cases, and reduce cost, thereby enabling broader adoption. Background on VDFs ------------------ In distributed protocols sometimes computations are made deliberately difficult or time consuming as a way to ensure that some amount of time or energy is expended by participants in those systems. As an example, Bitcoin’s proof-of-work ensures that a large amount of computation is performed for each block to make rewriting the ledger history difficult. However, proof-of-work computations are _distributed_ computations and the network periodically adjusts the difficulty of the work as computation is added or removed in the network. If it didn’t, the network would lose control over the rate at which blocks are produced. For some applications however, we need computations that are just as time-consuming to perform even with access to large amounts of (distributed) computational power. By ensuring a computation can only be efficiently computed with serial operations (unlike proof-of-work) we can ensure an efficient computer or dedicated hardware will be no less capable of performing the computation than an army of machines or supercomputers would be. At the same time, we need the computation’s result to be efficient to check, even if the operation is deliberately difficult to actually perform in the first place.  VDFs fulfill all of the above goals, they are **f**unctions that are efficiently **v**erifiable while introducing a **d**elay that cannot be sped up through parallel computation. One example of this is computing a 5th root operation in a finite field: checking that the result is correct is a matter of exponentiating by five, which involves just a couple squarings and a multiplication – far cheaper than computing the root. [VDFs](https://www.youtube.com/watch?v=3hg4GM7UQXA&list=PLhuBigpl7lquL-lYMPEEJy9bHGZcsWMna&index=10) can be used to produce cryptographically secure randomness, prevent denial-of-service attacks, and enable cryptographically provable storage replication. VDFs are being evaluated by a number of the leading blockchain platforms including [Ethereum](https://ethereum.org/en/) , [Filecoin](https://filecoin.io/) , [Tezos](https://tezos.com/) , and [Zcash](https://z.cash/) ; and improving their performance is critical to bringing them to production. Collaboration Goals ------------------- Currently many verifiable and confidential computing techniques like SNARKs and VDFs can not be brought into production due to their computationally expensive nature. This renders these proof systems impractical for many use cases. In this collaboration, we will perform research and development that will improve the performance and cost of these operations. In particular we will develop a VDF based on a variant of the [Sloth](https://eprint.iacr.org/2015/366) algorithm, with proofs generated by the [Halo 2](https://electriccoin.co/blog/explaining-halo-2/) and [Nova](https://github.com/microsoft/Nova) proving systems. Optimized implementations will be developed that leverage both CPU and GPU architectures, and initial research will be conducted on the feasibility and performance of an ASIC-based system, with the ultimate goal of developing a system that can support general-purpose recursive SNARKs and improves cost and performance by a factor of 10. SNARK-based VDF Implementation ------------------------------ In the case of SNARK-based VDFs, there are two key functions that must be improved: VDF evaluation and proof generation. Each of these functions must be optimized and made efficient to improve the user experience, reduce cost, and improve the security of the VDF. For VDF evaluation, it is critical that the implementation be as fast as possible. VDF evaluation is a ‘single-threaded’ process that requires a series of sequential modular multiplication and modular squaring operations, and as such should be optimized for low latency. VDF proving on the other hand requires a large number of similar operations, but these operations can be done in parallel, and as such the implementation should target high throughput. The result of these differing optimization goals can lend itself to the selection of different software and hardware architectures.  ### VDF Evaluation When optimizing VDF evaluation for latency there are a number of factors that can improve the speed of the function. While VDFs are designed to require a number of serial operations, there are a number of algorithmic choices at the software and hardware levels that can improve their performance. Such examples include the use of [addition chains](https://mathworld.wolfram.com/AdditionChain.html) to compute the fifth root, the use of alternative representations such as [Montgomery representation](https://en.wikipedia.org/wiki/Montgomery_modular_multiplication) to improve the performance of each modular operation, and the use of different hardware algorithms that reduce the circuit depth of the modular arithmetic core. In addition to these algorithmic choices, the underlying hardware platform will also impact the speed of the operation with factors like the [word size](https://en.wikipedia.org/wiki/Word_(computer_architecture)) of the architecture and the frequency of the processor impacting the overall time to perform each operation. During this research we intend to implement the VDF evaluation function on commodity CPUs in order to achieve a fast implementation using ‘off-the-shelf’ hardware. This implementation will leverage algorithmic techniques and handwritten assembly to improve the performance as much as possible. In addition to the CPU implementation we will also design a custom hardware circuit to perform the VDF evaluation and then perform a variety of analyses to better understand the potential performance improvements that custom silicon provides. ### VDF Proof Generation For VDF proof generation we will use [proofs of knowledge](https://link.springer.com/content/pdf/10.1007/3-540-48071-4_28.pdf) to show that the VDF verification operation was performed correctly. In particular, we use [Proof-Carrying Data](https://people.eecs.berkeley.edu/~alexch/docs/CT10.pdf) (PCD) and [Incrementally Verifiable Computation](https://link.springer.com/content/pdf/10.1007%2F978-3-540-78524-8_1.pdf) – realized using [Halo 2](https://zcash.github.io/halo2/background/recursion.html?highlight=proof-carrying#recursion) and [Nova](https://eprint.iacr.org/2021/370) – to distribute the task of building the proof to different platforms to accelerate the process. In the end, a single relatively small proof is created and can be checked much more efficiently than running the verification algorithm yourself. The provers will need to keep pace with the evaluator – a computer or dedicated ASIC hardware – by letting the evaluator produce interstitial results at regular intervals during evaluation. These results are portioned out among the provers, which produce proofs (in parallel) that contiguous portions of the verification algorithm have been correctly executed. These are shown as leaves in the diagram below. ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/11/ZKProof-VDF-Blog.png?resize=666%2C382&ssl=1) \[Figure 1: An example of a left-heavy binary tree proof composition strategy. By the time the prover receives the final VDF result, it would have already completed most of the recursive proofs.\] The leaves are then chained together via PCD, which folds contiguous _proofs_ together as they are created. The number of provers and complexity of the proofs are adjusted so that the latency between the completion of the evaluator and the production of the final proof is as small as possible. The choice of VDF operation also affects the relative performance of the prover and evaluator. The prover calculates witnesses in the fast direction, x → x5, giving it approximately a 94× advantage over the evaluator which is computing x → x1/5. We do not use the common x → x3 construction because the [Pallas/Vesta curves](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) used in Halo 2 and Nova have a 3-order multiplicative subgroup, meaning exponentiation by 3 is not a permutation. As with VDF evaluation, VDF proving can also be optimized through the use of algorithms, low-level programming, and custom silicon. However, unlike evaluation, VDF and SNARK proving are highly parallel operations, lending themselves to many-core architectures like [GPGPUs](https://www.tacc.utexas.edu/documents/13601/88790/8Things.pdf) . During our research we intend to implement algorithms that accelerate the SNARK proof generation for VDFs by writing custom CUDA code. This CUDA code will target core arithmetic functions required for proof generation like multi-scalar multiplication and number-theoretic transformations. In addition to this GPU implementation we also intend to perform a study to determine how the cost and performance of SNARK proof generation could be improved through the use of custom silicon. With the appropriate design, we believe it is possible to develop a system with over an order of magnitude or more performance improvement over existing designs. We hope that these improvements in performance, cost, and access will enable new use cases that have previously been impractical. [proofs](https://zkproof.org/tag/proofs/) [vdf](https://zkproof.org/tag/vdf/) [verifiable computation](https://zkproof.org/tag/verifiable-computation/) * * * ![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=240&d=identicon&r=g) ##### [Jonathan Gross](https://zkproof.org/author/jpgross3/ "Jonathan Gross post page") [All author posts](https://zkproof.org/author/jpgross3/ "Jonathan Gross post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Email Protection | Cloudflare Please enable cookies. Email Protection ================ You are unable to access this email address zkproof.org ------------------------------------------------------- The website from which you got to this page is protected by Cloudflare. Email addresses on that page have been hidden in order to keep them from being accessed by malicious bots. **You must enable Javascript in your browser in order to decode the e-mail address**. If you have a website and are interested in protecting it in a similar way, you can [sign up for Cloudflare](https://www.cloudflare.com/sign-up?utm_source=email_protection) . * [How does Cloudflare protect email addresses on website from spammers?](https://support.cloudflare.com/hc/en-us/articles/200170016-What-is-Email-Address-Obfuscation-) * [Can I sign up for Cloudflare?](https://support.cloudflare.com/hc/en-us/categories/200275218-Getting-Started) Cloudflare Ray ID: **929f69dfa8fe13fa** • Your IP: Click to reveal 54.237.218.47 • Performance & security by [Cloudflare](https://www.cloudflare.com/5xx-error-landing) --- # Darlin: Proof-carrying data based on Marlin - ZKProof Standards September 29, 2021|In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |18 Minutes Darlin: Proof-carrying data based on Marlin =========================================== [![Ulrich Haböck](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)](https://zkproof.org/author/ulrichhorizenlabsio/) By [Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) In this blog post, we describe _Darlin_, a recursive zk-SNARK which we will use to build _Latus sidechains_, i.e. succinct blockchains of [Horizen’s _Zendoo_ ecosystem](https://www.horizen.io/sidechain/) . Latus sidechains are configurable specific purpose blockchains which a user can tailor and bootstrap in a decentralized manner by help of the Zendoo mainchain and its cryptocurrency ZEN. Latus sidechains come with a succinct proof of their current state, and such proof will be composed recursively by an orchestrated group of \`SNARKers’, nodes that are compensated in ZEN. If you are interested in details on the Zendoo ecosystem and how tokens can be exchanged between Zendoo sidechains and the mainchain, you can have a look at our papers on [Zendoo](https://eprint.iacr.org/2020/123) and its incentive scheme [Latus Incentive Scheme](https://eprint.iacr.org/2021/399) . Darlin is a recursion-friendly variant of Marlin, a zk-SNARK for rank-one constraint systems (R1CS). Like many second-wave SNARKs, Marlin is built modularly on any secure polynomial commitment scheme. Our design choices are largely influenced by Halo, from which we learned a lot about how to bundle verifier computations over time, and construct efficient recursive schemes without a trusted setup. The most important cornerstones of our Darlin scheme are: * As Halo 1 and 2, we use the “dlog” polynomial commitment scheme, which does not require a trusted setup and allows for ordinary sized cycles of elliptic curves (such as the Pasta curves). * We use Halo’s strategy for aggregating the dlog \`hard parts’. We further generalize their strategy for amortizing the evaluation checks for bivariate polynomials $s(X,Y)$ to linear combinations of bivariate polynomials as occurring in the “inner sumcheck” of Marlin (see below). This public aggregation scheme works cross-circuit, i.e. it scales over the number of circuits used in recursion while still keeping the proof sizes compact. We estimate the speed up by inner sumcheck aggregation by about 30% in tree-like recursion as ours (with in-degree 2) and beyond for purely linear schemes. See our paper on [Darlin](https://eprint.iacr.org/2021/930) . Let’s give a rough intro to recursive SNARKs and aggregation schemes, and explain the above-mentioned inner sumcheck aggregation. SNARKs... --------------- SNARKs are succinct proofs certifying that a given large computation has been performed. The computation in question is typically formalized as an arithmetic circuit over a finite field $F$ (i.e. a circuit that has addition and multiplication gates), and satisfiability of that circuit on some given input is translated into the algebraic world of polynomials. Polynomials have the wonderful property that their values on a small set implies their values on the full domain (if their degree is small compared to the size of the finite field). This local determinism is leveraged by SNARKs which reduce algebraic identities on such polynomials to “local” checks at just a few (typically a single) random challenge points. The prover of course has to do a lot of computations. It computes polynomials of degree as large as the circuit, and computes the commitments of those, which typically involves expensive multi-scalar multiplications in an elliptic curve. In practice, SNARKs such as Groth16, Marlin or even Plonk are able to handle circuits up 1 Mio gates within about 1 minute on a normal off-the-shelf computer, but for larger circuits proof creation becomes increasingly costly in both time and memory. ... and recursive proofs ------------------------ A recursive SNARK proves the existence of a previous valid proof. For that the arithmetic circuit processed by the SNARK implements the verifier of a previous proof. And this previous proof again might certify the existence of pre-previous valid proof, and so on. This is fine in theory, but in practice, recursion is obstructed by many technical constraints. (We won’t dwell on the issue of simulating arithmetics or cycle of curves in this short blog post). In particular, transparent SNARKs based on the dlog commitment scheme face a big issue: Although the proof itself is a succinct piece of data, the verification of it is expensive (or, “non-succinct”). To check an evaluation proof for a dlog polynomial commitment, one has to perform a multi-scalar multiplication of the size of the polynomial itself. In recursion, this leads to growing circuit sizes (unless one uses the dlog commitment scheme in combination with another commitment scheme) — a show stopper for infinite recursion. Aggregation schemes ------------------- In their seminal paper on [Halo](https://eprint.iacr.org/2019/1021) , Bowe et al. introduced an entirely new way of handling the expensive dlog verifiers in recursion. They identified a portion of the dlog verifier (a multi-scalar multiplication) of such a structure, which allows merging several such parts through the help of a succinct challenge-response protocol, an _aggregation protocol_. Although the reduced instance (the _aggregator_, or _accumulator_) is still expensive to verify, it is just one expensive check as a substitute for all the expensive parts that have been absorbed by the aggregator over time. Hence, if one aggregates recursively over a longer time, the final check becomes succinct compared to the huge bulk of circuits that is bundled in a recursive proof. Since their discovery, aggregation schemes became a vivid research topic. Soon more radical aggregation schemes came up, e.g. the one from [Boneh et al.](https://eprint.iacr.org/2020/1536) which accumulates the full-length preimages of additive polynomial commitments, or by [Bünz et al.](https://eprint.iacr.org/2020/1618) who follow a similar idea aggregating the full-length solutions of an R1CS. While those approaches speed up recursion significantly, they come with large proof sizes, and it depends on the application whether such proof sizes are acceptable. In the context of Latus sidechains, we need to keep with small proof sizes as we cannot rely on network assumptions which might not be met in practice. Aggregating Marlin's inner sumchecks ------------------------------------ Beyond the dlog verifier, Bowe et al. introduced another aggregation scheme that hasn’t received as much attention as the one for the dlog verifier. The scheme allows to merge evaluation proofs for Sonic’s bivariate polynomial $s(X,Y)$ which encodes the circuit to be proven. We asked ourselves how to carry their strategy over to Marlin, which is more performant than Sonic but uses three bivariate polynomials $A(X,Y)$, $B(X,Y)$ and $C(X,Y)$ instead to represent the circuit. (These polynomials correspond to the matrices $A$, $B$, $C$ of the R1CS describing the circuit.) A naive way would be to apply the Halo principle to the three matrices separately, but this approach does not scale. It becomes too costly if recursion is composed of several different circuits as in the case of Latus sidechains. We explain how to do better. Marlin's inner sumcheck ----------------------- A significant part of Marlin is devoted to an evaluation proof for a random linear combination $$ T\_\\eta(X,Y) = \\eta\_A\\cdot A(X,Y)+ \\eta\_B\\cdot B(X,Y)+ \\eta\_C\\cdot C(X,Y), $$ at a random point $(\\alpha,\\beta)$, where $\\eta\_A,\\eta\_B,\\eta\_C$ and $(\\alpha,\\beta)$ depend on the protocol run. To do so, Marlin reduces such an evaluation proof to a univariate “sumcheck” argument (the so-called inner sumcheck) for $$ T\_\\eta(\\alpha,Y) $$ over a cyclic subgroup, the size of which is as large as there are non-zero entries in the matrices $A$,$B$, $C$. In practice and depending on the type of circuit, this domain is about 2–4 times larger than the number of constraints, and the inner sumcheck consumes 50-75% of the full proving time. Single circuit aggregation -------------------------- Instead of doing Marlin’s inner sumcheck , we aggregate instances of the form \\\[ \ acc = (\\alpha,(\\eta\_A,\\eta\_B,\\eta\_C),C), \ \\\] where $C$ is the (non-hiding) commitment of the polynomial $T\_\\eta(\\alpha,Y)$ described by $\\alpha$ and the coefficients $(\\eta\_A,\\eta\_B,\\eta\_C)$. Checking such an inner sumcheck aggregator is expensive, it demands to compute the claimed polynomial $T\_\\eta(\\alpha,Y)$ and check that $C$ is in fact the commitment of it. Now suppose that \\\[ \ acc’ = (\\alpha’,(\\eta\_A’,\\eta\_B’,\\eta\_C’),C’) \ \\\] is another such instance from a previous proof, and $acc$ from above corresponds to the current proof. (Notice that the claimed polynomials are the “sections” of different linear combinations of $A$,$B$,$C$ at different points $\\alpha$ and $\\alpha’$.) The underlying principle is similar as for the dlog hard parts. To check a public polynomial $s(x,Y)$ behind a commitment, one probes it at a random challenge $Y=y$ point and compares the opening value versus the expected one. However, the expected one is not computed succinctly from some public data but again expressed as the value of another committed polynomial, the horizontal slice $s(X,y)$ at $X=x$. * Step 1: The verifier samples a random point $y$ and asks the prover to provide commitments for the “bridging polynomials” $T\_\\eta(X,y)$ and $T’\_\\eta(X,y)$, which we denote by \\\[ \ C\_b, C\_b’ \ \\\] and asks the prover to show that their openings are related to $C$ and $C’$ by \\\[ \ C\_b\\big|\_{X=\\alpha} = C\\big|\_{Y=y} \ \\\] and \\\[ \ C\_b’\\big|\_{X=\\alpha’} = C’\\big|\_{Y=y}, \ \\\] where we use the notation $C|\_{Y=y}$ for the opening of the commitment $C$ at the point $y$. Observe that if $C\_b$ is, in fact, the commitment of $T\_\\eta(X,y)$ then its opening at $X=\\alpha$ is in fact $T\_\\eta(\\alpha,y)$ and therefore the polynomial “behind” $C$ responds with the expected value $T\_\\eta(\\alpha,y)$ when being probed at a random $y$. This proves (with overwhelming probability) that the polynomial behind $C$ is, in fact, the claimed one. The same argument holds for $C’$. By now we did not improve in terms of the verifier effort. To check that $C\_b$ and $C\_b’$ carry the claimed polynomials is as costly as checking the initial $C$ and $C’$. However, the current instances share the same point $y$. We use this fact to compress them by another round similar to Step 1: * Step 2: The verifier samples random scalars $\\lambda$, $x$ and asks the prover to provide the commitment $C”$ for the polynomial \\\[ \ T\_\\eta(x,Y)+\\lambda\\cdot T\_{\\eta’}(x,Y), \ \\\] together with a proof that the linear combination $C\_b+\\lambda\\cdot C\_b’$ opens at the new $x$ to the same point as the new $C”$ at the “old” $y$, \\\[ \ C”\\big|\_{Y=y} = (C\_b +\\lambda \\cdot C\_b’)\\big|\_{X=x}. \ \\\] Note that the expected polynomial behind $C”$ is \\\[ \ T\_\\eta (x,Y)+\\lambda \\cdot T\_{\\eta’}(x,Y) = T\_{\\eta”}(x,Y) \ \\\] with \\\[ \ \\eta” = (\\eta\_A,\\eta\_B,\\eta\_C)+ \\lambda\\cdot(\\eta\_A’,\\eta\_B’,\\eta\_C’). \ \\\] Again, if $C”$ in fact carries the polynomial corresponding to $x$ and $\\eta”$, then it opens to the correct value $T\_{\\eta”}(x,y) = T\_\\eta(x,y)+\\lambda\\cdot T\_{\\eta’}(x,y)$ and therefore the random linear combination $C\_b+\\lambda\\cdot C\_b’$ responds with the expected value when being probed at a random point $x$. Hence with overwhelming probability the polynomials behind both $C\_b$ and $C\_b’$ are the expected ones. Finally, the new aggregator is \\\[ \ acc” = (x, \\eta” , C”) \ \\\] with $\\eta”$ as computed above. ![](https://zkproof.org/wp-content/uploads/2021/09/BridgingPolys-1-uai-258x203.png) The two replacement steps of inner sumcheck aggregation. Cross-circuit generalization ---------------------------- The case of several circuits is an immediate generalization of the single circuit case. The accumulator for a collection $\\Gamma=\\{\\Gamma\_1,…,\\Gamma\_M\\}$ of circuits keeps track of the cross-circuit linear combination \\\[ \ T\_\\Gamma(\\alpha,Y) = \\sum\_{k=1}^M \\eta\_A\[k\]\\cdot A\_k(\\alpha,Y) + \\eta\_B\[k\]\\cdot B\_k(\\alpha,Y) + \\eta\_C\[k\]\\cdot C\_k(\\alpha,Y) \ \\\] through the random coefficients $\\eta\_A\[k\],\\eta\_B\[k\],\\eta\_C\[k\]$ for each of the circuits $\\Gamma\_k$ separately. (Here, $A\_k$, $B\_k$, $C\_k$ are the R1CS matrices of $\\Gamma\_k$). As mentioned above, cross-circuit aggregation is useful for schemes with a larger collection of recursive nodes. For example, the block proof of a Latus sidechain is a dynamically arranged tree of Merge-2, Merge-1 and a variety of different base proofs. See our paper [Darlin](https://eprint.iacr.org/2021/930) for further details. Zero-knowledge -------------- A Darlin node is run in zero-knowledge mode whenever it needs to secure private witness data. There are many applications in which zero-knowledge is favourable, such as shielded transactions, zero-knowledge audits or any other type of correctness proof for private state transitions. You may want to read our [Zendoo paper](https://eprint.iacr.org/2020/123) if you are interested in where the Zendoo ecosystem applies zero-knowledge. What else? ---------- The [Darlin proof system](https://eprint.iacr.org/2021/930) comes with a few other tweaks. We introduce an alternative way to handle the univariate sumcheck argument, a “cohomological” argument influenced by Plonk. This argument does not rely on individual degree bounds (and their proofs) and allows a more lightweight information-theoretic protocol notion. We also use a slightly different arithmetization for the R1CS matrices. (During the zk-proof workshop we learned that we are not the only ones doing the latter. [Lunar](https://eprint.iacr.org/2020/1069) uses the same arithmetization — we would like to thank Anaïs Querol for the interesting discussion!) We believe that Darlin might be useful for other projects which target recursive proofs but still want to stay with R1CS and small proof sizes. And we are curious how Darlin (once our implementation is ready) performs against Plonk based recursive schemes such as Halo 2 or Mina’s Pickles. [Education](https://zkproof.org/tag/education/) [Tech](https://zkproof.org/tag/tech/) [Zero-knowledge proofs](https://zkproof.org/tag/zero-knowledge-proofs/) * * * ![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=240&d=identicon&r=g) ##### [Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/ "Ulrich Haböck post page") [All author posts](https://zkproof.org/author/ulrichhorizenlabsio/ "Ulrich Haböck post page") ### Leave a Reply[Cancel reply](/2021/09/29/darlin-recursive-proofs/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Zero-Knowledge Proofs for Set Membership - ZKProof Standards Zero-Knowledge Proofs for Set Membership ======================================== February 27, 2020 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Dario Fiore](https://zkproof.org/author/dariofiore/) Introduction ------------ In this post, I will attempt to present the problem of proving set membership in zero-knowledge — proving that an element is part of a large public set without disclosing which element — while discussing the main existing solutions, with their pros and cons, and a recent paper on this topic. The post is intended for researchers and practitioners interested in the topic of zero-knowledge, and it tries to convey high-level explanations while sometimes turning into the mathematical details of the solutions. For the latter, I assume familiarity with basic computer science concepts like binary trees and computational complexity, as well as with some discrete maths like the notions of finite [rings](https://en.wikipedia.org/wiki/Ring_(mathematics)) and [groups](https://en.wikipedia.org/wiki/Group_(mathematics)) . Set Membership -------------- Set membership is the problem of checking whether an element $x$ belongs to some, possibly public, set $S$. It arises in a large variety of contexts, mostly in applications that have large lists of data, where checking if an element is in the list can be very costly, or in those applications that require some form of privacy assurance either on the set, $S$, or on the element, $x$. One example is with financial regulation, where a bank must prove to the regulator that a new client is a citizen of the given country. In order to do this, the bank will prove that the new client belongs to the set of all citizens of that country. In this setting, the list itself may be public (at least to the banks and regulators), but the bank may not want to reveal the specific client it is checking membership for. This implies that the bank would like to use some zero-knowledge version of the system, to prove to the regulator the set-membership without revealing the specific query. Another example is where a company wants to prove to their investors that they belong to the list of certified ecological companies. In this case, however, there is seemingly no need for privacy. Indeed, there are plenty of other examples where set-membership appears in business and governamental-level applications. More recently, this problem has also emerged in the context of blockchain, mainly in cryptocurrency designs. In Bitcoin for example, the blockchain is supposed to maintain the so-called set of “unspent transaction outputs” (UTXO, in short). In a nutshell, the UTXO set contains all the coins that have not been already spent and therefore are eligible to be spent in a new transaction. In this scenario, validating a transaction that wants to spend (or consume) a coin $x$ involves checking that $x$ is in the set UTXO. The same setting is given in the Zcash cryptocurrency, but in this case, the element $x$ must actually be hidden from the blockchain, making the set-membership proof zero knowledge. When looking at applications of set membership there are at least two intriguing questions that arise: 1. **Scalability:** _Is it possible to check that an element $x$ is part of a set $S$ without having to store $S$ and by spending time significantly faster than its size $|S|$?_ 2. **Privacy:** _Is it possible to check that $x$ is in $S$ for an unknown element $x$?_ If we leave them as they are, the questions above look impossible to solve, but if make a twist to the problem we can make the impossible possible. The twist is: let us assume an asymmetry of roles. There is one party, the _prover_, for which we are not concerned about achieving scalability and privacy. Namely, the prover knows $x$ and $S$ and can afford computational and storage costs proportional to $|S|$. Everybody else are instead the _verifiers_, who can invest only small computing and storage resources, and against which we want to achieve privacy (namely, they should not learn $x$). Adopting this asymmetric setting, then the idea to solve the problem is to _let the prover compute and send a short proof_ about $x \\in S$ to the verifiers, who can then check the proof in short time. In what follows I will first review some solutions that solve **scalability**, and then I will discuss techniques that enable extensions that achieve also **privacy**. Verifying Set Membership, _Efficiently_ --------------------------------------- Solutions to this problem date back to 1980 and 1994 when [_Merkle trees_](https://en.wikipedia.org/wiki/Merkle_tree) , by [Ralph Merkle](https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/merkle.pdf) and [cryptographic accumulators](https://link.springer.com/chapter/10.1007/3-540-48285-7_24) respectively were proposed. In its basic form, an accumulator can be seen as a triple of algorithms $(\\textsf{Acc}, \\textsf{Prove}, \\textsf{Verify})$ with the following functionality: * $A \\leftarrow \\textsf{Acc}(S)$ compresses a set of values $S$ into a short value $A$, the accumulator. * $\\pi\_{x} \\leftarrow \\textsf{Prove}(S, x)$ generates a membership proof $\\pi\_x$ about $x \\in S$. * $\\textsf{Verify}(A, x, \\pi\_{x})$ accepts or rejects the proof by using only knowledge of the accumulated set $A$. To assure verifiers against malicious provers, accumulators come with the guarantee that creating false proofs (i.e., a proof $\\pi^{\*}$ that is accepted by $\\textsf{Verify}(\\textsf{Acc}(S), x, \\pi^{\*})$ for an $x \\notin S$) is impossible under certain computational assumptions. If this is the functionality provided by accumulators, we are then left to discuss the main question of this section: _why accumulators enable efficient verification of set membership?_ This is achieved thanks to a key property of them: the size of accumulator values $A$, proofs $\\pi\_{x}$ and the running time of $\\textsf{Verify}$ are much smaller than the length of $S$; for example they can be logarithmic $O(\\log |S|)$ or even constant (note: in the literature, with the term “accumulators” one typically refers to schemes with constant-size proofs and verification.) One detail that I kept hidden from the description above is that all algorithms actually take an additional input, which is a public set of parameters that are generated in a probabilistic and trusted way. Nowadays, we know several realizations of accumulators. Nevertheless, here I want to mention two popular realizations: [Merkle trees](https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/merkle.pdf) and [RSA Accumulators](https://link.springer.com/chapter/10.1007/3-540-48285-7_24) . Interestingly enough, they are not only the oldest proposals but also the only ones that by now achieve all desired properties by using _constant-size_ public parameters. At this point it is worth mentioning that they offer different efficiency tradeoffs: proofs size and verification time are $O(\\log |S|)$ in Merkle trees, and $O(1)$ in RSA accumulators. Let us briefly review how these two accumulators constructions work. ### Merkle Trees With a Merkle tree one can accumulate _sets made of arbitrary elements_ using a collision-resistant hash function. We refer to [this resource](https://hackernoon.com/merkle-trees-181cb4bc30b4) or [this one](https://nakamoto.com/merkle-trees/) for a more detailed explanation, but the basic idea is the following. The public parameters simply consist of an hash function (e.g., SHA-256). In order to accumulate a set $S = \\{x\_1, \\ldots, x\_n\\}$ (let us assume for simplicity that $n$ is a power of $2$), one builds a binary tree in which $ \\{x\_1, \\ldots, x\_n\\}$ are the leaves, and every internal node is the hash of its two children. The accumulator value $A$ is then the value at the root of such tree. To create a proof $\\pi\_j$ that a certain $x\_j \\in S$, one returns all the sibling nodes that are in the path from the leaf $x\_j$ until the root. From the binary tree structure one then gets that these proofs consist of $\\log(n)$ strings of $\\ell$ bits each (where $\\ell$ is the hash’s output bit length), and can be verified by using the siblings to recompute the nodes in the path and then check if the final result is equal to the root $A$. Merkle trees are a very powerful construct, with countless applications and a lot of nice properties. They are actually more powerful than accumulators; they realize a so-called [vector commitment](https://eprint.iacr.org/2011/495.pdf) , since the position of each leaf in the tree is also encoded in a binding way, in the sense that it is computationally impossible to claim two distinct values at the same position. ### RSA Accumulators With [RSA Accumulators](https://link.springer.com/chapter/10.1007/3-540-48285-7_24) one can accumulate _sets made of prime numbers_. The main ingredient of these constructions are _groups of unknown order_, of which RSA groups (from which the name) or [class groups](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.7192) are candidate realizations. Let us show how this works in RSA groups. The public parameters consist of an RSA modulus $N=p \\cdot q$ product of two large prime numbers $p$ and $q$, and of a random generator $G \\in \\mathbb{Z}\_{N}^{\*}$. Here, $\\mathbb{Z}\_{N}$ denotes the ring of non-negative integers modulo $N$—the set $\\{0, 1, \\ldots, N-1\\}$—while $\\mathbb{Z}^{\*}\_{N}$ is the subset of elements in $\\mathbb{Z}\_{N}$ that are also coprime with $N$, which form a _group_ under multiplication. In order to accumulate a set $S$ of prime numbers $\\{e\_1,\\ldots e\_{n}\\}$, one computes $$A \\leftarrow G^{\\prod\_{i=1}^{n} e\_i} \\bmod N.$$ To create a proof that a certain $e\_j \\in S$, one computes $$\\pi\_j \\leftarrow G^{\\prod\_{i=1,i\\neq j}^{n} e\_i} \\bmod N = A^{1/e\_j} \\bmod N$$ which can be verified by checking if $$\\pi\_j^{e\_j} = A \\bmod N$$ Overall, RSA accumulators are a quite simple and elegant construction. While the basic construction above has the limitation that elements must be prime numbers, this can be solved by using appropriately constructed hash functions that map arbitrary strings into primes. Compared to Merkle trees, they have the appealing property that everything is constant-size: both $A$ and the proof $\\pi\_j$ consist of one group element each, and verification requires one modular exponentiation only. On top of this, they enjoy further properties. For example, it is possible to efficiently add elements to the accumulator value (i.e. it is dynamic), to create proofs of non-membership (it is universal), and to create short proofs for membership of many elements. See for example this recent work by [Boneh, Bunz and Fisch](https://eprint.iacr.org/2018/1188.pdf) to read about these and more properties. Verifying Set Membership, _Efficiently and Privately_ ----------------------------------------------------- We have seen how accumulators can provide a solution to the problem of proving and verifying set membership in an efficient manner. Let us now move to the question of how to make these proofs also privacy-preserving, namely how to prove that $x \\in S$ without revealing $x$. Actually, in most applications, the privacy requirement about $x$ typically goes together with the need of proving more than just membership. One may wish to prove that a property $P(x)$ holds for some element $x \\in S$, without revealing exactly for which element. In other (more cryptographic) words, one is interested in making a zero-knowledge proof (ZKP) for the [NP relation](https://cs.stanford.edu/people/trevisan/cs254-12/lecture02.pdf) $R(S, x) := x\\in S \\wedge P(x)$, where $S$ is public and $x$ is secret. A ZKP for $R$ however is not necessarily “efficient” in the same sense as discussed earlier since the verifier should read $S$, and the proof itself may not be succinct. To make the proof also short and efficient to verify, a solution is to mix ZKPs with accumulators, that is to build a ZKP for the following relation $$R(A, (x, \\pi\_x)) := \\textsf{Verify}(A, x, \\pi\_{x}) \\wedge P(x)$$ that, in words, proves existence of an element $x$ for which $P$ holds and for which there is a valid accumulator proof relative to $A$, which in turn implies membership in the set accumulated in $A$. This blueprint can be applied to both Merkle trees and RSA accumulators. In the rest of this post, we review the main existing solutions that follow these two approaches, and then we conclude by mentioning a recent work. ### ZKPs for Set Membership via Merkle Trees ZKPs for set membership via Merkle trees are a straightforward application of the ZKP & Accumulators mixing approach mentioned above. Notably, this idea has been implemented in the [Zcash](https://z.cash) protocol, which used the general-purpose power of zkSNARKs in order to prove in zero-knowledge existence of a valid Merkle path (in addition to other properties modeling the validity of a transaction). This in turn translates into proving correctness of about $\\log |S|$ hash computations on secret inputs. Encoding hash computations in the zkSNARK is what makes this approach particularly expensive for the prover. Zcash’s [Sapling](https://github.com/zcash/zips/blob/master/protocol/protocol.pdf) provided significant speedups of this approach via an ingenious choice of a pairing-friendly elliptic curve and the Pedersen hash function. Nevertheless, proving set membership is by now the most expensive part of proof generation in Zcash. ### ZKPs for Set Membership via RSA Accumulators For the case of RSA Accumulators, a notable work is that of [Camenisch and Lysyanskaya](https://cs.brown.edu/people/alysyans/papers/camlys02.pdf) who designed a ZKP protocol for the knowledge of an integer $e$ that is in the accumulator and that is committed in a group $\\mathbb{G}$ of prime order $q$. More technically, given an accumulator $A$ and a Pedersen commitment $C\_{e}\\in \\mathbb{G}$ as public values, they show how to prove knowledge of $(e, W, r)$ such that $$A = W^{e} \\bmod N \\wedge C\_e = g^{e} h^{r} \\in \\mathbb{G}$$ Having the commitment $C\_{e}$ comes in handy if the final goal is to prove some property $P$ about the set element $e$: one simply creates another commit-and-prove ZKP for proving knowledge of $(e, r)$ such that $C\_e = g^{e} h^{r} \\in \\mathbb{G}$ and $P(e)$ holds. The [Camenisch-Lysyanskaya](https://cs.brown.edu/people/alysyans/papers/camlys02.pdf) protocol is potentially more efficient than the one based on Merkle trees as it does not require expensive general-purpose ZKPs that encode hash computations. Nevertheless, its use can be cumbersome due to some technical details. Most notably, the accumulated sets must be prime numbers of a specific size (which also imposes a minimum size for the prime-order group), and the hash-to-prime trick to avoid this problem cannot be used straightforwardly to mitigate this issue. ZKPs for Set Membership: Efficient, Succinct, Modular ----------------------------------------------------- In the last part of this post, I would like to mention a [recent work \[BCFK19\]](https://eprint.iacr.org/2019/1255) that investigates _modular_ and _efficient_ constructions of ZKPs for set membership. ### Modularity in ZKP Design One is often confronted with creating ZKPs for “composite statements”, e.g., statements of the form “I know a value $x$ that belongs to a set $S$ and for which properties $P\_1(x)$ and $P\_2(x)$ hold”. In such a case, it can be convenient to create a proof by using three different proof systems, one for each subtask, e.g., $\\Pi\_{mem}$ for set membership, $\\Pi\_1$ for $P\_1$, $\\Pi\_2$ for $P\_2$. This modular approach can be beneficial in multiple ways: one can focus on designing efficiency-optimized ZKPs for specific tasks, the same scheme can be re-used and replaced in a plug-and-play fashion, and it is just a simple design paradigm. Technically, this approach can be realized by using _commit-and-prove_ ZKP systems. In a nutshell, a proof system $\\Pi$ for a property $P$ is commit-and-prove if it can prove statements of the form “I know $x$ such that $P(x)$ holds and $C\_{x}$ is a commitment to $x$”. Since commitments are binding, generating two such proofs with respect to the same commitment immediately implies an AND composition of the two proven statement. Essentially, commitments act as a “secure glue” between different proof systems. While commit-and-prove has been known and used extensively in cryptography constructions, the recent [LegoSNARK](https://eprint.iacr.org/2019/142) paper studied this paradigm in the context of succinct ZKPs, aka zkSNARKs. ### Modular in ZKP for Set-Membership The [\[BCFK19\]](https://eprint.iacr.org/2019/1255) paper starts from the observation that _an accumulator value can be seen as a commitment to a set_, and that the whole accumulator primitive can be seen as a succinct commit-and-prove system for set membership relations. In this sense, accumulators with ZK proofs of knowledge (i.e., that can prove “I know a valid accumulator proof for an $x$ in the commitment”) can be seen as commit-and-prove zkSNARK for set membership relations involving two types of commitments, a commitment to a set—the accumulator—and a commitment to an element. So, one theoretical contribution of the paper is to extend the model of commit-and-prove zkSNARKs (and their composability properties) to the setting of typed-commitments, namely commitments to messages of different types (e.g., strings and sets over strings). ### More Flexible and Modular ZKPs for RSA Accumulators On the more practical side, [\[BCFK19\]](https://eprint.iacr.org/2019/1255) proposes new commit-and-prove zkSNARKs for set-membership, notably two solutions based on RSA accumulators that can be combined modularly and efficiently with other popular ZKP systems, such as [Bulletproofs](https://eprint.iacr.org/2017/1066.pdf) or [Groth16](https://eprint.iacr.org/2016/260.pdf) . The latter feature is useful since it allows one to prove statements of the form “I know a value $x$ that belongs to a set $S$ and for which property $P(x)$ holds'”, by using this specialized scheme for the set-membership part and a general-purpose one for any other property about $x$. Going more into the detail, [\[BCFK19\]](https://eprint.iacr.org/2019/1255) proposes two solutions based on RSA. Both of them provide a functionality similar to the ZKP of [Camenisch and Lysyanskaya](https://cs.brown.edu/people/alysyans/papers/camlys02.pdf) mentioned earlier, in the sense that the element $x$ object of the membership proof is committed in a Pedersen commitment $C\_x$ over a group $\\mathbb{G}$ of prime order $q$. One key difference that helps efficient modularity however is that in [\[BCFK19\]](https://eprint.iacr.org/2019/1255) $\\mathbb{G}$ can be of standard size (e.g., 256 bits for 128 bits of security). This, we recall, means that other commit-and-prove systems that want to use $C\_x$ do not need to suffer efficiency slowdowns due to inflated sizes of $\\mathbb{G}$. In terms of supported sets, both solutions in [\[BCFK19\]](https://eprint.iacr.org/2019/1255) allow more flexible choices of sets than the [Camenisch-Lysyanskaya](https://cs.brown.edu/people/alysyans/papers/camlys02.pdf) protocol: the first scheme supports the accumulation of sets whose elements are arbitrary binary strings, while in the second scheme elements are prime numbers of exactly $\\mu$ bits (for various flexible choices of $\\mu$). ### Deep Diving into Linking Pedersen Commitments in Different Groups Let us go even deeper and see how [\[BCFK19\]](https://eprint.iacr.org/2019/1255) achieves these improvements. In a nutshell, this is due to a new way to link a proof of membership for RSA accumulators to a Pedersen commitment in a prime order group, together with a careful analysis showing how this can be secure under parameters _not requiring a larger prime order group_. For this post we only summarize the main idea for the scheme supporting sets of primes; we refer the interested readers to the paper for further details. Let us recall the setting. The statement known to the verifier consists of an accumulator $A = G^{\\prod\_{i=1}^{n} e\_i} \\bmod N$, which is a commitment to a set $S = \\{e\_1, \\ldots, e\_n\\}$, and of a Pedersen commitment $C\_{e}$ in a group $\\mathbb{G}$ of prime order $q$. The goal of the prover is to argue knowledge of $(e, r)$ that open $C\_e$, i.e., $C\_{e} = g^{e} h^{r}$, and such that $e \\in S$ where $A = \\textsf{Acc}(S)$. This is achieved through a combination of the following: * $C^{\*}\_e$, a commitment to $e$ created by the prover in the RSA group: $C^{\*}\_{e} = G^{e} H^{s} \\bmod N$. * $\\Pi\_{root}$, a ZKP of a committed root for $A$, i.e., a proof of knowledge of $e, s$ and $W$ such that $$W^{e} = A \\bmod N \\quad \\textrm{and} \\quad C^{\*}\_{e} = G^{e} H^{s} \\bmod N.$$ * $\\Pi\_{modeq}$, a ZKP that $C^{\*}\_{e}$ and $C\_{e}$ commit to the same value modulo $q$. * $\\Pi\_{range}$, a ZKP that $C\_{e}$ commits to an integer in the range $(2^{\\mu-1}, 2^{\\mu})$. Intuitively, $\\Pi\_{root}$ shows that $C^\*\_{e}$ commits to an integer that is accumulated in $A$ (at this point, however, such integer may be a trivial root, i.e., $1$). The goal of $\\Pi\_{modeq}$ and $\\Pi\_{range}$ is to rule out this corner case $e=1$ and to “securely link” the commitment $C^\*\_e$ in the RSA group created by the prover with the prime-order group commitment $C\_e$ known to the verifier, namely to ensure that these two commitment open to the same integer $e$. This is less straightforward than expected because $\\Pi\_{modeq}$ is only able to prove that the equality of the values committed in $C^\*\_e$ and $C\_e$ holds _modulo_ $q$ _and not necessarily over the integers_. Also, from $\\Pi\_{root}$ alone, one can only infer that $C^\*\_{e}$ commits to some integer $e^\*$ that divides $\\prod\_{i=1}^{n} e\_i$. So, the bad case that malicious provers may trigger and that the protocol must exclude is that $e^\*$ and $e^\* \\bmod q$ are _different_ over the integers. This can be shown with a quite detailed analysis whose basic idea is to use the fact that $\\Pi\_{root}$ nevertheless guarantees that $e^\*$ can be the product of only few primes in $S$ (say 1, 2, depending on the difference between $\\mu$ and $|q|$), and that $\\Pi\_{range}$ ensures that $e^\* \\bmod q$ lies in the range $(2^{\\mu-1}, 2^{\\mu})$. To summarize, this technique enables linking the commitments in the RSA and prime-order group in an efficient way, and this enables to use this ZKP for set membership in combination with other SNARKs that are instantiated over the same prime-order group. Conclusion ---------- To conclude, in this post we went on a journey about the set membership problem. We started from seminal works (Merkle trees and RSA accumulators) that provide a solution to the scalability problem of set membership. Next, we went on to discuss solutions that allow one to maintain the privacy of the element involved in the set membership statement — a problem that is key in a number of applications from different domains, including finance, and business- or governmental-level interaction. Given the emergence of ZKP applications in the real-world, we expect that new solutions to the problem of privacy-preserving set membership will come out. * * * ![](https://secure.gravatar.com/avatar/fbd08dd5224ac605776db51974cd3879?s=240&d=identicon&r=g) ##### [Dario Fiore](https://zkproof.org/author/dariofiore/ "Dario Fiore post page") [All author posts](https://zkproof.org/author/dariofiore/ "Dario Fiore post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2020/02/27/zkp-set-membership/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Inductive Proof Systems and Recursive SNARKs - ZKProof Standards Inductive Proof Systems and Recursive SNARKs ============================================ June 8, 2020 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Izaak Meckler](https://zkproof.org/author/izaakm/) This blog post describes a powerful technique for defining systems that allows for scalable, verifiable computation on partially private data. There are many applications, some more exciting than others depending on your tastes, but I hope something for everybody: * Private, verifiable elections (which we’ll discuss in this post) * [Succinct blockchains](https://codaprotocol.com/) * Private, scalable DEXes * Auditable machine learning * Private, verifiable social [wealth funds](https://www.peoplespolicyproject.org/projects/social-wealth-fund/) * A web app that proves to its users that it’s deleting all information older than a year (or at least not using it) * [Verifying authenticity of a photo](https://www.cs.tau.ac.il/~tromer/photoproof/photoproof-oakland16.pdf) even when it has been edited multiple times by multiple people (and accompanied by a log of who edited it) The technology for accomplishing this is essentially what has been called [proof carrying data](https://eprint.iacr.org/2012/095.pdf) , but we’ll be introducing some new notation and call the resulting concept and notation “inductive proof systems”. We at [Coda](https://codaprotocol.com) have implemented inductive proof systems in the [pickles library](https://github.com/CodaProtocol/coda/tree/develop/src/lib/pickles) , which combined with a universal SNARK allows arbitrary applications (a.k.a., “Turing complete computations”) to be deployed in a _scalable_ way on top of scalable public blockchains like Coda. Verifiable voting as an inductive proof system ---------------------------------------------- To get a feel for this technology, let’s dive into the specific example of a private, verifiable election$^{\[1\]}$. It will be private in the sense that each vote will have no identifying information attached to it. It will be verifiable in the sense that at the end we’ll have a small proof of the result (on the order of a few kBs) that can be easily checked on almost any device, including a browser or a phone. For simplicity let’s say we have an election with two choices: 0 and 1. We’ll have two types of participants in this system: 1. **Voters.** Voters will create a zero-knowledge proof that proves “I am eligible to vote, my vote is for choice $c$ and $s$ is my ballot-stub”. The public input for this ZKP will be the pair $(c, s)$. The “ballot-stub” will be a piece of data that is unique to a registered voter, cannot be linked to that voter’s identity, and not knowable by anyone else. Think of it as a kind of unique signature on the message “I voted” with the voter’s secret-key. We’ll use this to make sure no one votes more than once. 2. **Aggregators.** Aggregators will collect votes and then produce a zero-knowledge proof that proves “I know a set of votes resulting in vote totals $(n\_0, n\_1)$ and with the corresponding set of ballot stubs $S$”. The public input for this ZKP will be $((n\_0, n\_1), S)$. Actually, to keep things succinct, it will not be $S$ but a succinct representation thereof, which we can get into later. Once all the votes have been aggregated, we will be left the final vote-count $(n\_0, n\_1)$ and stub set $S$ with a single tiny SNARK which proves the existence of valid votes corresponding to $S$ which add up to the claimed values. Thus, we’ll achieve our goal of a private and verifiable voting system. Toward a specification ---------------------- Now that we have an informal specification of what we want, we need a cryptographer to translate it into a mathematical description, and then a programmer to translate that into a fully formal description (i.e., a program). To that end, let’s describe a mathematical notation for capturing this specification. This notation will have the advantage of being quite close to the fully formal description that a programmer would write and can execute using the [pickles library](https://github.com/CodaProtocol/coda/tree/develop/src/lib/pickles) , which we’ll discuss in more detail later on. First, define a set $\\mathsf{Vote}$ which has the following property > **IF** there exists$^{\[2\]}$ a voting secret key $\\mathsf{sk}$ such that $\\mathsf{pk} := \\mathsf{privKeyToPubKey(sk)}$, $\\mathsf{isEligible(pk)} = \\mathsf{true}$, $s = \\mathsf{ballotStub}(sk)$, and there exists a signature$^{\[3\]}$ $\\mathsf{sig}$ such that $\\mathsf{sigVerify}(\\mathsf{sig}, \\mathsf{pk}, c) = \\mathsf{true}$, **THEN** $(c, s) \\in \\mathsf{Vote}$. We are assuming that we have some algorithm $\\mathsf{isEligible}$ that checks eligibility of a public key, a way of obtaining public keys from private voting keys, and a way of creating and verifying signatures using a voting private-public keypair. This is a bit hard to read. We can more compactly represent this property with the notation $$ \\frac{ \\mathsf{pk} = \\mathsf{privKeyToPubKey(sk)} \\qquad \\mathsf{isEligible(pk)} \\qquad \\mathsf{sig} \\colon \\mathsf{Signature} \\qquad \\mathsf{sigVerify}(\\mathsf{sig}, \\mathsf{pk}, c) }{(c, \\mathsf{ballotStub(sk)}) \\in \\mathsf{Vote}} $$ The way one reads this notation is “If everything on the top is true, then the bottom is true.” You can also read it backwards, like “in order to prove $(c, s) \\in \\mathsf{Vote}$ it suffices to provide everything on the top.” This notation is known as a “natural deduction-style inference rule.” You can read more about this notation in the context of logic [here](https://en.wikipedia.org/wiki/Natural_deduction#Judgments_and_propositions) or [here](https://www.cs.cmu.edu/~fp/courses/atp/handouts/ch2-natded.pdf) . Next, we’ll give similar rules that describe how we can prove aggregate vote totals. We’ll give a description of a set $\\mathsf{VoteCount}$ whose elements will be the tuples $((n\_0, n\_1), S)$ such that there exists a set of votes with corresponding stubs $S$ and such that the total number of votes for $0$ is $n\_0$ and for $1$ is $n\_1$. The first rule is $$ \\frac{ (c, s) \\in \\mathsf{Vote} }{ ( (\\textsf{if } c = 0 \\textsf{ then } (1, 0) \\textsf{ else } (0, 1)), \\{ s \\} ) \\in \\mathsf{VoteCount} } $$ The second rule is$^{\[4\]}$ $$ \\frac{ ((n\_0, n\_1), S) \\in \\mathsf{VoteCount} \\qquad ((m\_0, m\_1), T) \\in \\mathsf{VoteCount} \\qquad }{ ( (n\_0 + m\_0, n\_1 + m\_1), S \\cup T ) \\in \\mathsf{VoteCount} } $$ You can see that these two rules completely characterize $\\mathsf{VoteCount}$ in that any member of $\\mathsf{VoteCount}$ can be proven to be a member by repeated application of these rules. For instance, let’s say we have votes $(0, s\_1), (0, s\_2), (1, s\_3), (0, s\_4) \\in \\mathsf{Vote}$ and we would like to prove that $((3, 1), \\{ s\_1, s\_2, s\_3, s\_4 \\}) \\in \\mathsf{VoteCount}$. This we can do as follows: $$ \\frac{ \\frac{ \\frac{ (0, s\_1) \\in \\mathsf{Vote} }{ ((1, 0), \\{ s\_1 \\}) \\in \\mathsf{VoteCount} } \\qquad \\frac{ (0, s\_2) \\in \\mathsf{Vote} }{ ((1, 0), \\{ s\_2 \\}) \\in \\mathsf{VoteCount} } }{ ((1 + 1, 0 + 0), \\{ s\_1 \\} \\cup \\{ s\_2 \\} \\in \\mathsf{VoteCount} } \\qquad \\frac{ \\frac{ (1, s\_3) \\in \\mathsf{Vote} }{ ((0, 1), \\{ s\_3 \\}) \\in \\mathsf{VoteCount} } \\qquad \\frac{ (0, s\_4) \\in \\mathsf{Vote} }{ ((1, 0), \\{ s\_4 \\}) \\in \\mathsf{VoteCount} } }{ ((0 + 1, 1 + 0), \\{ s\_3 \\} \\cup \\{ s\_4 \\} \\in \\mathsf{VoteCount} } }{ ((2 + 1, 0 + 1), \\{ s\_1, s\_2 \\} \\cup \\{s\_3, s\_4 \\}) \\in \\mathsf{VoteCount} } $$ This setup as an inductive proof system --------------------------------------- Taken together, the one rule describing the set $\\mathsf{Vote}$ and the two rules describing the set $\\mathsf{VoteCount}$ give a full description of the system we would like, or at least the part of it related to producing proofs. What we want is to obtain a “prover” algorithm for each of our rules. That way, we get a prover which lets voters produce voting-proofs, and provers which lets aggregators merge together voting proofs into proofs that prove the correctness of a corresponding vote count. We term the collection of prover algorithms that fit together in the appropriate way an “inductive proof system”. Then, each application of an inductive-rule will correspond to producing a SNARK and each assumption of the form $\\mathsf{someStatement} \\in \\mathsf{SomeSet}$ will correspond to the recursive verification of a previous SNARK. Schematically, this whole “proof tree” is represented in this figure, where each purple square represents a voter and the proof they produce, and the big blue square represents the aggregator(s) and the proofs that they produce. ![](https://zkproof.org/wp-content/uploads/2020/06/27IB50Z-uai-258x255.jpg) Toward a generalization ----------------------- We can give a mathematical definition which captures the general notion of which the above sets of inductive rules are specific examples. We won’t give the full definition here, but the idea is to define an “inductive NP set” as an NP set which can be specified by a sequence of “inductive NP rules”; and an “inductive NP rule” as an efficient algorithm which checks a statement against some witness data and a sequence of predecessor statements whose membership in some NP sets is assumed. We can then describe a “compiler” which takes an inductive NP set and compiles it into an inductive proof system with a verifier and one prover corresponding to each inductive rule. A fully formal specification and implementation ----------------------------------------------- A fully formal specification of the above rules would be a program that specifies the inductive NP rules precisely. The [pickles library](https://github.com/CodaProtocol/coda/tree/develop/src/lib/pickles) allows one to do just this. It provides a compiler that turns a sequence of inductive rules into a verifier and one prover for each rule. It is joint work with Vanishree Rao and Vitaly Zelov. It’s currently being used in Coda, and at mainnet launch, we’ll be releasing a SNApps (“snarkified apps”) toolkit built on top of **pickles** for anyone to build their own private and scalable snarkified smart-contracts on Coda. * * * \[1\]: A fully private election would be one in which you only find out the winner. This election system will be only partially private in that you will learn intermediate and the final vote counts as well. In that sense it’s a bit like government elections (at least in the US) where you learn the vote totals for each district, state, etc. \[2\]: Actually, by “there exists…”, we mean “there \*really\* exists…”. That is, “an efficient program can produce…”. \[3\]: One could do this more efficiently by relying on the signature-of-knowledge interpretation of the SNARK that pickles uses, but this is fine for explanatory purposes. \[4\]: It is difficult to implement a succinct accumulator that supports taking unions, and so really we would do something different than taking unions in the second rule, but please permit this white lie for the sake of a clearer explanation. * * * ![](https://secure.gravatar.com/avatar/77741d2b0efc0c5077e3938b8f9c8c71?s=240&d=identicon&r=g) ##### [Izaak Meckler](https://zkproof.org/author/izaakm/ "Izaak Meckler post page") [All author posts](https://zkproof.org/author/izaakm/ "Izaak Meckler post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2020/06/08/recursive-snarks/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Justin Thaler, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/762930bf4e5729c872d96573ea566297?s=200&d=identicon&r=g) Justin Thaler ============= March 16, 2020 ### [The Unreasonable Power of the Sum-CheckProtocol](https://zkproof.org/2020/03/16/sum-checkprotocol/) When designing an efficient interactive proof system, there is only one hammer you need to have in your toolbox: the sum-check protocol of Lund, Fortnow, Karloff, and Nisan. * * * [0 Comments](https://zkproof.org/2020/03/16/sum-checkprotocol/#respond "title") 20 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # ZKProof Standards, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=200&d=identicon&r=g) ZKProof Standards ================= * [](http://zkprooforg.wordpress.com) September 18, 2023 ### [Scaling Trustless DNN Inference, zkml applications at ZKProof.org by Daniel Kang](https://zkproof.org/2023/09/18/zkml-where-are-we-now-where-do-we-go-from-here-talk-summary-zkproof-5-5-daniel-kang/) Daniel Kang gave a comprehensive overview of the current capabilities of zero-knowledge proofs for machine learning (ZKML), clearly explaining what types of models like ImageNet,… * * * [0 Comments](https://zkproof.org/2023/09/18/zkml-where-are-we-now-where-do-we-go-from-here-talk-summary-zkproof-5-5-daniel-kang/#respond "title") 3 Minutes September 12, 2023 ### [ZKPs and Post-Quantum Signatures From VOLE-in-the-Head at ZKProof.org by Peter Scholl](https://zkproof.org/2023/09/12/zkps-and-post-quantum-signatures-from-vole-in-the-head-at-zkproof-org-by-peter-scholl/) Peter presented the FAEST signature scheme, which achieves similar performance to hash-based signatures under only AES security, and provides post-quantum signatures under 5KB and… * * * [0 Comments](https://zkproof.org/2023/09/12/zkps-and-post-quantum-signatures-from-vole-in-the-head-at-zkproof-org-by-peter-scholl/#respond "title") 2 Minutes September 12, 2023 ### [Lessons from DARPA SIEVE at ZKProof.org by James Parker & Kimberlee Model](https://zkproof.org/2023/09/12/lessons-from-darpa-sieve-at-zkproof-org-by-james-parker-kimberlee-model/) James and Kimberlee clearly explained the SIEVE IR, a collaborative specification enabling interoperability between frontends and backends. They invited the community to learn… * * * [0 Comments](https://zkproof.org/2023/09/12/lessons-from-darpa-sieve-at-zkproof-org-by-james-parker-kimberlee-model/#respond "title") 2 Minutes September 12, 2023 ### [Recursive Proof Composition at ZKProof.org by Ying Tong Lai](https://zkproof.org/2023/09/12/recursive-proof-composition-by-ying-tong-lai/) Ying Tong Lai delivered an illuminating presentation that advanced understanding of recursive proof composition, clearly explaining techniques like folding schemes, highlighting… * * * [0 Comments](https://zkproof.org/2023/09/12/recursive-proof-composition-by-ying-tong-lai/#respond "title") 2 Minutes September 12, 2023 ### [The Plonk Effort at ZKProof.org by Mary Maller](https://zkproof.org/2023/09/12/plonk-standardization-zkproof-5-5-mary-maller-talk-summary/) Mary Maller's overview of the modular approach to specifying Plonk. In this talk, Mary clearly explained the components of the forming standard and rationale. * * * [0 Comments](https://zkproof.org/2023/09/12/plonk-standardization-zkproof-5-5-mary-maller-talk-summary/#respond "title") 3 Minutes February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present Sangria, a Nova-style folding scheme for the PLONK arithmetization. In the same way that Nova introduces “relaxed R1CS”, the main ingredient in… * * * [0 Comments](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/#respond "title") 18 Minutes January 1, 2020 ### [Announcing the Expert Series Webinar on Zero-Knowledge Proofs](https://zkproof.org/2020/01/01/fundamentals-of-zero-knowledge/) ZKProof has joined forces with leading organizations in our ecosystem to launch a new webinar series. With the aim of making Zero-Knowledge Proof technology more accessible to new… * * * [0 Comments](https://zkproof.org/2020/01/01/fundamentals-of-zero-knowledge/#respond "title") 4 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # ZKProof 6 in Berlin - ZKProof Standards **ZKProof 6 in Berlin**  ======================== **May 22-24, 2024** ------------------- =========================================== [Watch the streams](https://www.youtube.com/@zkproofstandards1776/playlists "ZKP 6 Berlin streams") #### ZKProof is an initiative focused on the standardization of Zero-Knowledge Proofs. This community of over 1000 practitioners converges stakeholders from academia, startups, and law enforcement, creating a bridge between theory and practical implementation. This year, we’re preparing for a 3 days event in Berlin. On the Agenda: * #### Day 1: zkVMs builders will discuss ZKP, Programmability, and Scale * #### Day 2: Standardization and the Verified Verifier – what’s the target scheme to formally verify? Mary Maller will lead PLONK Standards Working groups * #### Day 3: Addressing Vulnerabilities in SNARKs * #### With Keynotes by Alessandro Chiesa (EPFL), Jens Groth (Nexus), Kostas Chalkias (Mysten Labs) #### Important Information **Date:** May 22-24, 2024 **Registration is closed** **Location:**  [DoubleTree by Hilton Berlin](https://maps.app.goo.gl/WrV5RjgHBhCUnyn79) ### ZKProof 6 : Agenda Speakers ------------ [![Alessandro Chiesa](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/chiesa.jpeg?resize=150%2C150&ssl=1)](https://people.eecs.berkeley.edu/~alexch/) ### [Alessandro Chiesa](https://people.eecs.berkeley.edu/~alexch/ "Alessandro Chiesa") [EPFL](https://people.eecs.berkeley.edu/~alexch/ "Alessandro Chiesa") [![Andrew Zitek-Estrada](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Andrew-Zitek-Estrada-pic.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/andrew-zitek-estrada/) ### [Andrew Zitek-Estrada](https://zkproof.org/team/andrew-zitek-estrada/ "Andrew Zitek-Estrada") [EPFL](https://zkproof.org/team/andrew-zitek-estrada/ "Andrew Zitek-Estrada") [![Arasu Arun](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Arasu-headshot-photo.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/arasu-arun/) ### [Arasu Arun](https://zkproof.org/team/arasu-arun/ "Arasu Arun") [New York University](https://zkproof.org/team/arasu-arun/ "Arasu Arun") [![Ben Livshits](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/ben2_cropped.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/ben-livshits/) ### [Ben Livshits](https://zkproof.org/team/ben-livshits/ "Ben Livshits") [VP of Research, Matter Labs](https://zkproof.org/team/ben-livshits/ "Ben Livshits") [![Calum Moore](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Calum-Moore-pic.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/calum-moore/) ### [Calum Moore](https://zkproof.org/team/calum-moore/ "Calum Moore") [Payy](https://zkproof.org/team/calum-moore/ "Calum Moore") [![Daniel Benarroch](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/77A5005-1-e1580068464804.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/daniel-benarroch/) ### [Daniel Benarroch](https://zkproof.org/team/daniel-benarroch/ "Daniel Benarroch") [](https://twitter.com/benarrochdaniel "twitter") [](/cdn-cgi/l/email-protection#3f5b5e51565a537f45544f4d50505911504d58 "envelope-o") [![Daniel Marin](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Daniel-Marin.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/daniel-marin/) ### [Daniel Marin](https://zkproof.org/team/daniel-marin/ "Daniel Marin") [Nexus](https://zkproof.org/team/daniel-marin/ "Daniel Marin") [![Doron Zarchy](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Doron-Zarchy-pic.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/stefanos-chaliasos/) ### [Doron Zarchy](https://zkproof.org/team/stefanos-chaliasos/ "Doron Zarchy") [University of Luxembourg](https://zkproof.org/team/stefanos-chaliasos/ "Doron Zarchy") [![Eylon Yogev](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/ey.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/eylon-yogev/) ### [Eylon Yogev](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [Professor, Bar-Ilan University](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [![Giacomo Fenzi](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Giacomo-Fenzi.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/giacomo-fenzi/) ### [Giacomo Fenzi](https://zkproof.org/team/giacomo-fenzi/ "Giacomo Fenzi") [EPFL](https://zkproof.org/team/giacomo-fenzi/ "Giacomo Fenzi") [![Hadas Zeilberger](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Hadas-Zeilberger-pic.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/hadas-zeilberger/) ### [Hadas Zeilberger](https://zkproof.org/team/hadas-zeilberger/ "Hadas Zeilberger") [Yale University](https://zkproof.org/team/hadas-zeilberger/ "Hadas Zeilberger") [![Harish Karthikeyan](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Harish-Karthikeyan-pic-1.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/harish-karthikeyan/) ### [Harish Karthikeyan](https://zkproof.org/team/harish-karthikeyan/ "Harish Karthikeyan") [JP Morgan AI Research, J.P. Morgan AlgoCRYPT CoE](https://zkproof.org/team/harish-karthikeyan/ "Harish Karthikeyan") [![Hyeonbum Lee](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/HyeonbumLee.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/hyeonbum-lee/) ### [Hyeonbum Lee](https://zkproof.org/team/hyeonbum-lee/ "Hyeonbum Lee") [Hanyang University](https://zkproof.org/team/hyeonbum-lee/ "Hyeonbum Lee") [![Jens Groth](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/JensGroth-2-e1576008345317.jpg?resize=150%2C150&ssl=1)](http://www0.cs.ucl.ac.uk/staff/j.groth/) ### [Jens Groth](http://www0.cs.ucl.ac.uk/staff/j.groth/ "Jens Groth") [Nexus](http://www0.cs.ucl.ac.uk/staff/j.groth/ "Jens Groth") [![Jonas Nick](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Jonas-Nick-pic.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/jonas-nick/) ### [Jonas Nick](https://zkproof.org/team/jonas-nick/ "Jonas Nick") [Blockstream](https://zkproof.org/team/jonas-nick/ "Jonas Nick") [![Jonathan Rouach](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/jonathan-rouach/) ### [Jonathan Rouach](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [Executive Director for ZKProof, CEO and Founder, QEDIT](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [![Kostas Chalkias](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/Kostas-Chalkias.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/kostas-chalkias/) ### [Kostas Chalkias](https://zkproof.org/team/kostas-chalkias/ "Kostas Chalkias") [Mysten Labs](https://zkproof.org/team/kostas-chalkias/ "Kostas Chalkias") [![Luigi Russo](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/russo.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/luigi-russo/) ### [Luigi Russo](https://zkproof.org/team/luigi-russo/ "Luigi Russo") [EURECOM](https://zkproof.org/team/luigi-russo/ "Luigi Russo") [![Marcin Kostrzewa](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Marcin-Kostrzewa-pic.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/marcin-kostrzewa/) ### [Marcin Kostrzewa](https://zkproof.org/team/marcin-kostrzewa/ "Marcin Kostrzewa") [Reilabs](https://zkproof.org/team/marcin-kostrzewa/ "Marcin Kostrzewa") [![Mark Greenslade](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/mark-greenslade-headshot-1.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/mark-greenslade/) ### [Mark Greenslade](https://zkproof.org/team/mark-greenslade/ "Mark Greenslade") [Casper](https://zkproof.org/team/mark-greenslade/ "Mark Greenslade") [![Mary Maller](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/02/marymaller-e1614114950795.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/mary-maller/) ### [Mary Maller](https://zkproof.org/team/mary-maller/ "Mary Maller") [Cryptography Researcher, Ethereum Foundation](https://zkproof.org/team/mary-maller/ "Mary Maller") [](http://marymaller.com/ "globe") [![Matteo Campanelli](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Matteo-Campanelli-pic2.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/matteo-campanelli/) ### [Matteo Campanelli](https://zkproof.org/team/matteo-campanelli/ "Matteo Campanelli") [Matter Labs](https://zkproof.org/team/matteo-campanelli/ "Matteo Campanelli") [![Michael Zhu](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Michael-Zhu-15-pic.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/michael-zhu/) ### [Michael Zhu](https://zkproof.org/team/michael-zhu/ "Michael Zhu") [a16z crypto research](https://zkproof.org/team/michael-zhu/ "Michael Zhu") [![Michele Orru](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Michele-Orru-2.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/michele-orru/) ### [Michele Orru](https://zkproof.org/team/michele-orru/ "Michele Orru") [CNRS](https://zkproof.org/team/michele-orru/ "Michele Orru") [![Muthu Venkitasubramaniam](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Copy-of-GBP_20190412_1086-e1576450323148.jpg?resize=150%2C150&ssl=1)](https://www.cs.rochester.edu/u/muthuv/) ### [Muthu Venkitasubramaniam](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [Associate Professor, Georgetown University  CTO and co-founder, Ligero Inc.](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [![Nikitas Paslis](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/NIKTAS-PASLIS.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/nikitas-paslis/) ### [Nikitas Paslis](https://zkproof.org/team/nikitas-paslis/ "Nikitas Paslis") [Universitat Pompeu Fabra](https://zkproof.org/team/nikitas-paslis/ "Nikitas Paslis") [![Norbert Vadas](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Norbert-Vadas.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/norbert-vadas/) ### [Norbert Vadas](https://zkproof.org/team/norbert-vadas/ "Norbert Vadas") [Gevulot](https://zkproof.org/team/norbert-vadas/ "Norbert Vadas") [![Oana Ciobotaru](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Oana-Ciobotaru-pic.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/oana-ciobotaru/) ### [Oana Ciobotaru](https://zkproof.org/team/oana-ciobotaru/ "Oana Ciobotaru") [OpenZeppelin](https://zkproof.org/team/oana-ciobotaru/ "Oana Ciobotaru") [![Pablo Kogan](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/Pablo-pic.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/pablo-kogan/) ### [Pablo Kogan](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [Director of Engineering, QEDIT](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [![Robin Linus](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/robin-linus.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/robin-linus/) ### [Robin Linus](https://zkproof.org/team/robin-linus/ "Robin Linus") [ZeroSync](https://zkproof.org/team/robin-linus/ "Robin Linus") [![Stefanos Chaliasos](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Stefanos-Chaliasos-pic.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/stefanos-chaliasos-2/) ### [Stefanos Chaliasos](https://zkproof.org/team/stefanos-chaliasos-2/ "Stefanos Chaliasos") [Imperial College London](https://zkproof.org/team/stefanos-chaliasos-2/ "Stefanos Chaliasos") [![Ying Tong Lai](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/2023-04-28-12.45.09-1.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ying-tong-lai/) ### [Ying Tong Lai](https://zkproof.org/team/ying-tong-lai/ "Ying Tong Lai") [Research Associate, Geometry](https://zkproof.org/team/ying-tong-lai/ "Ying Tong Lai") ### Accepted Submissions * SoK: What don’t we know? Understanding Security Vulnerabilities in SNARKs – Stefanos Chaliasos (Imperial College London) * A Time-Space Tradeoff for the Sumcheck Prover – Andrew Zitek-Estrada (EPFL) * STIR: Reed-Solomon Proximity Testing with Fewer Queries – Eylon Yogev (Bar-Ilan University) * SLAP: Succinct Lattice-Based Polynomial Commitments from Standard Assumptions – Giacomo Fenzi (EPFL) * zkSNARKs in the ROM with Unconditional UC-Security – Giacomo Fenzi (EPFL) * Tooling: Practical Formal Verification for Arithmetic Circuits – Marcin Kostrzewa (Reilabs) * Basefold : Efficient field-agnostic multilinear polynomial commitment schemes from foldable codes – Hadas Zeilberger (Yale University) * On the Security of Nova Recursive Proof System – Hyeonbum Lee (Hanyang University) * On Comparing Proof Systems and their Implementations (or “It would be cool to have the L2BEAT of proof systems!”) – Matteo Campanelli and Marco Stronati (Matter Labs) * State of the Sigmas – Michele Orru (CNRS) * PriDe CT: Using Zero-Knowledge Proofs to Unlock Public Consensus with Private, Concurrent, and Batchable Transactions with Forward Secrecy in Decentralized Payments – Harish Karthikeyan (JP Morgan AI Research, J.P. Morgan AlgoCRYPT CoE) * Jolt: SNARKs for virtual machines via Lookups – Arasu Arun (New York University) and Michael Zhu (a16z crypto research) * Why There’s No ZK in Bitcoin: The Missing Pieces – Jonas Nick (Blockstream ) * SNARK Flipper. FLIP & Prove multiple instances efficiently – Nikitas Paslis and Carla R\`afols (Universitat Pompeu Fabra) * Aggios: Scalable Aggregator-Based Voting – Doron Zarchy (University of Luxembourg) * Real-world Universal zkSNARKs are non-malleable – Luigi Russo (EURECOM, Sophia Antipolis, France) **Submissions are no longer being accepted.** ZKProof 6 Program Chairs ---------------------------- [![Carmit Hazay](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/carmitHazay-e1579981003254.jpg?resize=150%2C150&ssl=1)](https://www.eng.biu.ac.il/hazay/) ### [Carmit Hazay](https://www.eng.biu.ac.il/hazay/ "Carmit Hazay") [Professor, Bar-Ilan University; Co-founder, Ligero](https://www.eng.biu.ac.il/hazay/ "Carmit Hazay") [](https://twitter.com/CarmitHazay "twitter") [](https://www.eng.biu.ac.il/hazay/ "globe") [![Muthu Venkitasubramaniam](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Copy-of-GBP_20190412_1086-e1576450323148.jpg?resize=150%2C150&ssl=1)](https://www.cs.rochester.edu/u/muthuv/) ### [Muthu Venkitasubramaniam](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [Associate Professor, Georgetown University  CTO and co-founder, Ligero Inc.](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") ZKProof 6 Program Committee ------------------------------- [![Ruihan Wang](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/03/WhatsApp-Image-2024-02-29-at-20.16.13.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ruihan-wang/) ### [Ruihan Wang](https://zkproof.org/team/ruihan-wang/ "Ruihan Wang") [Ligero, Inc.](https://zkproof.org/team/ruihan-wang/ "Ruihan Wang") [![Emmanuela Orsini](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/DeM.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/emmanuela-orsini-2/) ### [Emmanuela Orsini](https://zkproof.org/team/emmanuela-orsini-2/ "Emmanuela Orsini") [Assistant Professor, Bocconi University](https://zkproof.org/team/emmanuela-orsini-2/ "Emmanuela Orsini") [![Alessandra Scafuro](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/alesc.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/alessandra-scafuro/) ### [Alessandra Scafuro](https://zkproof.org/team/alessandra-scafuro/ "Alessandra Scafuro") [Associate Professor, NCSU](https://zkproof.org/team/alessandra-scafuro/ "Alessandra Scafuro") [![Alex Block](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/alex-block.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/alex-block/) ### [Alex Block](https://zkproof.org/team/alex-block/ "Alex Block") [Georgetown University, University of Maryland](https://zkproof.org/team/alex-block/ "Alex Block") [![Eylon Yogev](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/ey.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/eylon-yogev/) ### [Eylon Yogev](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [Professor, Bar-Ilan University](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [![Benedikt Bünz](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/Benedikt-Bunz-2.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/benedikt-bunz/) ### [Benedikt Bünz](https://zkproof.org/team/benedikt-bunz/ "Benedikt Bünz") [New York University](https://zkproof.org/team/benedikt-bunz/ "Benedikt Bünz") [![Ariel Gabizon](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/Ariel-Gabilzon.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ariel-gabilzon/) ### [Ariel Gabizon](https://zkproof.org/team/ariel-gabilzon/ "Ariel Gabizon") [Aztec Labs](https://zkproof.org/team/ariel-gabilzon/ "Ariel Gabizon") [![Kostas Chalkias](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/Kostas-Chalkias.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/kostas-chalkias/) ### [Kostas Chalkias](https://zkproof.org/team/kostas-chalkias/ "Kostas Chalkias") [Mysten Labs](https://zkproof.org/team/kostas-chalkias/ "Kostas Chalkias") [![Pablo Kogan](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/Pablo-pic.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/pablo-kogan/) ### [Pablo Kogan](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [Director of Engineering, QEDIT](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [![Kimberlee Model](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/kimee.jpg.webp?resize=150%2C150&ssl=1)](https://zkproof.org/team/kimberlee-model/) ### [Kimberlee Model](https://zkproof.org/team/kimberlee-model/ "Kimberlee Model") [Research Software Engineer, Stealth Software Technologies](https://zkproof.org/team/kimberlee-model/ "Kimberlee Model") [![Kobi Gurkan](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/WhatsApp-Image-2022-10-10-at-2.22.37-PM.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/kobi-gurkan/) ### [Kobi Gurkan](https://zkproof.org/team/kobi-gurkan/ "Kobi Gurkan") [Head of Research, Geometry](https://zkproof.org/team/kobi-gurkan/ "Kobi Gurkan") Our Sponsors ---------------- To learn more about becoming a sponsor, email us at [\[email protected\]](/cdn-cgi/l/email-protection) ### Platinum Sponsors [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/qedit-padding.png?fit=1920%2C722&ssl=1)](https://qed-it.com) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/sui_logo_ocean_padded.png?fit=3716%2C1942&ssl=1)](https://sui.io/) ### Gold Sponsors [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/casper_smaller.png?fit=2560%2C1440&ssl=1)](https://casper.network/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Gradient_large.png?fit=6000%2C2509&ssl=1)](https://inversed.tech/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Screenshot-2024-05-02-at-13.06.19.png?fit=378%2C130&ssl=1)](https://nexus.xyz/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/full_logo_zksync-black.png?fit=4392%2C866&ssl=1)](https://zksync.io/) ### Silver Sponsors [![](https://zkproof.org/wp-content/uploads/2024/04/EF-ESP-logo.svg)](https://esp.ethereum.foundation/) [![](https://zkproof.org/wp-content/uploads/2024/04/gevulot-logo-black-on-transparent.svg)](https://gevulot.com/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/05/Ligero.png?fit=596%2C420&ssl=1)](https://ligero-inc.com/) [![](https://zkproof.org/wp-content/uploads/2024/04/OZ_logo_color.svg)](https://www.openzeppelin.com/) ![](https://zkproof.org/wp-content/uploads/2024/06/ZKProof6-Group-Jonedit-uai-258x119.jpg) [](#) --- # ZKProof Policy @ DC - ZKProof Standards ZKProof Policy @ DC =================== Washington DC, USA ================== [Register now!](https://www.eventbrite.com/e/zkproof-policy-dc-tickets-726710098467?aff=oddtdtcreator "ZKProof Telegram") **Join us in Washington DC on November 30th to the ZKProof Policy Day**  With zero-knowledge-proofs in the headlines, we’ll dedicate this day to explore how the technology can be used for enhanced privacy for all, and discuss the trade-offs and interactions with law enforcement and regulations. Join us for a “real-talk” day, deep dive with us into these very important topics. See you there! This is event was made possible thanks to the generous sponsorship of QEDIT, Sterne Kessler IP Law-firm, and organized by the QEDIT team. #### Important Information **Date:** November 30th, 2023 **Registration: [Join us](https://www.eventbrite.com/e/zkproof-policy-dc-tickets-726710098467?aff=oddtdtcreator)**   **Location:** Washington DC, USA at Sterne Kessler offices **Address**: 1101 K St NW 10th floor, Washington, DC 20005, United States Invited Speakers -------------------- [![René peralta](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/Rena.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/rene-peralta/) ### [René peralta](https://zkproof.org/team/rene-peralta/ "René peralta") [Computer Scientist, NIST](https://zkproof.org/team/rene-peralta/ "René peralta") [![Nasreen Djouini](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/1632606041385.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/nasreen-djouini/) ### [Nasreen Djouini](https://zkproof.org/team/nasreen-djouini/ "Nasreen Djouini") [Senior Advisor, Office of the National Cyber Director, The White House](https://zkproof.org/team/nasreen-djouini/ "Nasreen Djouini") [![Houman Shadab](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/unnamed.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/houman-shadab/) ### [Houman Shadab](https://zkproof.org/team/houman-shadab/ "Houman Shadab") [Cofounder, ICME | Counsel, Scale LLP](https://zkproof.org/team/houman-shadab/ "Houman Shadab") [![Linda Jeng](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/image-1.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/linda-jeng/) ### [Linda Jeng](https://zkproof.org/team/linda-jeng/ "Linda Jeng") [CEO & Co-founder, Digital Self Labs ǀ Head of Global Web3 Strategy ,CCI ǀ Senior Fellow & Adjunct Prof, Georgetown & Duke Law](https://zkproof.org/team/linda-jeng/ "Linda Jeng") [![Pablo Kogan](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/Pablo-pic.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/pablo-kogan/) ### [Pablo Kogan](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [Director of Engineering, QEDIT](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [![Carol Van Cleef](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/carol.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/carol-van-cleef/) ### [Carol Van Cleef](https://zkproof.org/team/carol-van-cleef/ "Carol Van Cleef") [Board member, BTCS Founder, Comptegrity | Luminous Group](https://zkproof.org/team/carol-van-cleef/ "Carol Van Cleef") [![Trisha Datta](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/Trisha-Datta.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/trisha-datta/) ### [Trisha Datta](https://zkproof.org/team/trisha-datta/ "Trisha Datta") [PhD student, Stanford University](https://zkproof.org/team/trisha-datta/ "Trisha Datta") [![Anna Lysyanskaya](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/Anna-Lysyanskaya.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/anna-lysyanskaya/) ### [Anna Lysyanskaya](https://zkproof.org/team/anna-lysyanskaya/ "Anna Lysyanskaya") [Professor, Brown University](https://zkproof.org/team/anna-lysyanskaya/ "Anna Lysyanskaya") [![Joe E. Mutschelknaus](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/Mutschelknaus-Joseph-wide.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/joe-e-mutschelknaus/) ### [Joe E. Mutschelknaus](https://zkproof.org/team/joe-e-mutschelknaus/ "Joe E. Mutschelknaus") [Director, Sterne Kessler](https://zkproof.org/team/joe-e-mutschelknaus/ "Joe E. Mutschelknaus") [![Ryan C. Richardson](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/Richardson-Ryan-wide.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ryan-c-richardson/) ### [Ryan C. Richardson](https://zkproof.org/team/ryan-c-richardson/ "Ryan C. Richardson") [Director, Sterne Kessler](https://zkproof.org/team/ryan-c-richardson/ "Ryan C. Richardson") [![James Parker](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/JamesP.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/james-parker/) ### [James Parker](https://zkproof.org/team/james-parker/ "James Parker") [Research Engineer, Galois](https://zkproof.org/team/james-parker/ "James Parker") [![Justin Thaler](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/02/headshot1.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/justin-thaler/) ### [Justin Thaler](https://zkproof.org/team/justin-thaler/ "Justin Thaler") [Research Partner, a16z. Associate Professor, Georgetown University](https://zkproof.org/team/justin-thaler/ "Justin Thaler") [](http://people.cs.georgetown.edu/jthaler/ "globe") [![Jonathan Rouach](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/jonathan-rouach/) ### [Jonathan Rouach](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [Executive Director for ZKProof, CEO and Founder, QEDIT](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [![Eran Tromer](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/CA5_0227_edt2_sqr.jpg?resize=150%2C150&ssl=1)](http://www.tau.ac.il/~tromer/) ### [Eran Tromer](http://www.tau.ac.il/~tromer/ "Eran Tromer") [Professor, Boston University founder, Sealance](http://www.tau.ac.il/~tromer/ "Eran Tromer") [![Muthu Venkitasubramaniam](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Copy-of-GBP_20190412_1086-e1576450323148.jpg?resize=150%2C150&ssl=1)](https://www.cs.rochester.edu/u/muthuv/) ### [Muthu Venkitasubramaniam](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [Associate Professor, Georgetown University  CTO and co-founder, Ligero Inc.](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") | | Session | Title | Speaker | Streaming Links | | --- | --- | --- | --- | --- | | 9:00 - 09:30 | Coffee, Registration & Mingling | Get your tags | | | | 09:30 - 09:35 | Introduction | Welcome to ZKProof Policy at DC | | Morning Sessions: | | 09:35 - 10:05 | | IP and Standardization for Emerging FinTech | Joseph E. Mutschelknaus & Ryan Richardson (Sterne Kessler) | [https://www.youtube.com/live/K1fA3Yqe85o?si=pEJZj4z80JJBZGb9](https://www.youtube.com/live/K1fA3Yqe85o?si=pEJZj4z80JJBZGb9) | | 10:05 - 10:35 | | Revisiting accepted wisdom in SNARK design | Justin Thaler (a16z / Georgetown University) | | | 10:35 - 11:00 | Morning Coffee Break | | | | | 11:00 - 11:30 | | Zero-Knowledge Financial Regulation Compliance | Eran Tromer (Boston University / Sealance) | | | 11:30 - 12:00 | | Ligetron | Muthu Venkitasubramaniam (Georgetown University / Ligero Inc) | | | 12:00 - 13:00 | Lunch Break | | | | | 13:00 - 13:30 | | Privacy and Compliance - Striking a Delicate Balance | Pablo Kogen (QEDIT) | Afrernoon Sessions: | | 13:30 - 14:00 | | Zero-Knowledge Proofs for Balancing Privacy and Accountability | Anna Lysyanskaya (Brown University) | [https://youtube.com/live/TmCoURJ-stk?feature=share](https://youtube.com/live/TmCoURJ-stk?feature=share) | | 14:00 - 14:30 | | ZKP for Trust in Software and Hardware | James Parker (Galois) | | | 14:30 - 15:00 | COFFEE BREAK | | | | | 15:00 - 15:30 | | NIST's views regarding the standardization of advanced cryptography | René Peralta (NIST) | | | 15:30 - 16:00 | | Using Zero-Knowledge Proofs to Fight Disinformation | Trisha Datta (Stanford University) | | | 16:10 - 17:00 | Panel Discussion | Roundtable: Law Enforcement and ZKP | Moderator: Jonathan Rouach (QEDIT) Panelists: Carol Van Cleef (Luminous Group), Linda Jeng (Crypto Council), Houman Shadab (ICME), Nasreen Djouini (White House) | | #### The event will be held in:[Sterne Kessler Offices](https://maps.app.goo.gl/eXKae8PJiHaasUYs8) [](https://maps.app.goo.gl/eXKae8PJiHaasUYs8) ##### 1101 K St NW, 10th floor, Washington, DC 20005, United States [](#) --- # ZKProof Policy @ DC Archives - ZKProof Standards ZKProof Policy @ DC =================== [![](https://zkproof.org/wp-content/uploads/2024/03/tromer-uai-258x172.png)](https://zkproof.org/2024/04/04/zero-knowledge-financial-regulation-compliance-by-eran-tromer/) April 4, 2024 ### [Zero-Knowledge Financial Regulation Compliance by Eran Tromer](https://zkproof.org/2024/04/04/zero-knowledge-financial-regulation-compliance-by-eran-tromer/) * * * [![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) [![](https://zkproof.org/wp-content/uploads/2024/03/Screenshot-2024-03-19-at-13.14.36-uai-258x172.png)](https://zkproof.org/2024/04/03/nists-views-on-standardisation-of-advanced-cryptography-by-rene-peralta/) April 3, 2024 ### [NISTs Views on Standardisation of Advanced Cryptography by René Peralta](https://zkproof.org/2024/04/03/nists-views-on-standardisation-of-advanced-cryptography-by-rene-peralta/) * * * [![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) [![](https://zkproof.org/wp-content/uploads/2024/03/unnamed-uai-258x172.png)](https://zkproof.org/2024/04/01/privacy-and-compliance-striking-a-delicate-balance-by-pablo-kogan/) April 1, 2024 ### [Privacy and Compliance: Striking a Delicate Balance by Pablo Kogan](https://zkproof.org/2024/04/01/privacy-and-compliance-striking-a-delicate-balance-by-pablo-kogan/) * * * [![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) [![](https://zkproof.org/wp-content/uploads/2024/03/Screenshot-2024-03-21-at-14.52.18-uai-258x172.png)](https://zkproof.org/2024/03/21/zk-proofs-for-balancing-privacy-and-accountability-by-anna-lysyanskaya/) March 21, 2024 ### [ZK Proofs for Balancing Privacy and Accountability by Anna Lysyanskaya](https://zkproof.org/2024/03/21/zk-proofs-for-balancing-privacy-and-accountability-by-anna-lysyanskaya/) * * * [![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Justin Thaler - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/02/headshot1.png?fit=840%2C732&ssl=1) Justin Thaler ------------- **Research Partner, a16z Associate Professor, Georgetown University** Justin Thaler is a Research Partner at a16z and an Associate Professor in the Department of Computer Science at Georgetown University. His research interests include verifiable computing, complexity theory, and algorithms for massive data sets. In 2011, he produced the first implementation of a general-purpose interactive proof system. He is the author of a comprehensive survey on SNARKs titled Proofs, Arguments, and Zero-Knowledge, and a co-creator of Apache DataSketches, an open-source library of production-quality streaming algorithms. Before joining a16z Crypto and Georgetown, Justin was a Research Scientist at Yahoo Labs. Before that, he completed her PhD in Computer Science at Harvard University. [](http://people.cs.georgetown.edu/jthaler/ "globe") [](#) --- # Jonathan Rouach - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?fit=200%2C203&ssl=1) Jonathan Rouach --------------- **Executive Director, ZKProof.org** **CEO and co-Founder, QEDIT** Jonathan S. Rouach is the co-founder and CEO of QEDIT, helping enterprises leverage their data using Privacy Enhancing Techniques such as Zero-Knowledge Proofs. Before that, he co-founded a blockchain security company (sold to Digital Asset Holding), co-founded the Israeli Bitcoin Association , and co-founded Bits of Gold LTD, the leading Bitcoin exchange in Israel. Jonathan is an Electrical-Engineer from the Technion, served as an analyst in the Israeli Intelligence. [](#) --- # Zero-Knowledge Financial Regulation Compliance by Eran Tromer - ZKProof Standards April 4, 2024|In [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/ "View all posts in ZKProof Policy @ DC") |5 Minutes Zero-Knowledge Financial Regulation Compliance by Eran Tromer ============================================================= [![ZKProof Standards](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)](https://zkproof.org/author/vivek99f886b602/) By [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) In his talk ([slides](https://github.com/zkpstandard/docs/raw/master/pages/presentations/2023-11-dc/20231130-zkproof-dc--Eran-Tromer--Zero-Knowledge-Financial-Regulation-Compliance.pdf) , [video](https://youtu.be/K1fA3Yqe85o&t=1h45m06s) ), Eran Tromer (Boston University and Sealance Corp.) talks about how as blockchain and cryptocurrency adoption grows, there is an inherent tension between financial regulations requiring visibility into transactions for compliance purposes, and the privacy protections that users demand. Traditional approaches have struggled to strike the right balance in this emerging decentralized landscape. The Challenges of Regulating Decentralized Finance ================================================== Financial regulations exist to combat issues like terrorism financing, money laundering, securities violations, and tax evasion. Regulatory bodies rely on collecting information, surveillance, reporting, and visibility into transactions. However, there are also important reasons to protect privacy – safeguarding personal and corporate data, preventing discrimination and censorship, and even national security considerations. The traditional financial system attempts to balance these priorities by subjecting licensed intermediaries like banks to regulations, while preserving privacy for individual customers. In decentralized finance (DeFi) protocols operating on public blockchains, the transparency required for effective regulation becomes a hindrance. DeFi developers can’t reasonably handle collecting and securing users’ sensitive personal data. And regulators lose the ability to influence centralized intermediaries since protocols are decentralized and often pseudonymous. On-chain analytics that trace transactions suffer from the blockchain transparency problem – too much irrelevant information is publicly visible, while associating transactions with real identities is unreliable. Privacy protections like mixers, rollups, and bridges further impede the effectiveness of these methods. Fundamentally, the traditional regulatory approach of mandating licensed intermediaries lacks a clear mapping to DeFi’s decentralized, disintermediated, and often anonymous architectures. ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/03/Eran-talk.png?resize=840%2C395&ssl=1) ================================================================================================== A Zero-Knowledge Solution ========================= The key to achieving better compliance in DeFi may lie in leveraging zero-knowledge proofs – cryptographic techniques that enable proving a statement is true without revealing any information beyond the fact that it is true. The core idea is to embed regulatory compliance rules directly into DeFi protocols and smart contracts. Transactions would only be processed if they satisfy programmable policies around identity, sanctions screening, transaction limits, suspicious activity reporting, the “travel rule” sharing of counterparty data, and more. Rather than relying on centralized data collection, the protocols can leverage external “regulatory attestation providers” that cryptographically certify identity attributes and screening results about wallet holders. Users would hold certificates encoding this compliant data. Zero-knowledge protocols then allow users to cryptographically prove their certificates satisfy programmable on-chain policies, without revealing the underlying private data from the certificates themselves. Nodes and smart contracts can efficiently validate these proofs to enforce compliance at the protocol level. This enables the creation of “compliant asset pools” where all participants satisfy relevant policies, allowing fully private transactions amongst a group who have been vetted for factors like sanctions compliance. Users retain privacy from the public, while protocols have visibility into compliance without raw personal data. Research Developments --------------------- This vision has already seen promising academic advances laying the foundations: * The original Zerocash paper introducing Zcash foresaw using zero-knowledge proofs for policy compliance beyond just proving coin ownership. * Subsequent works like Zether, Provisions, and Trovato have proposed and built prototypes for privacy-preserving regulation technologies. * Eran Tromer’s startup Sealance is commercializing privacy-preserving compliance solutions for both legacy and emerging blockchains. While technical challenges remain around scalability of zero-knowledge circuits, techniques like PLONK and FRI are rapidly improving capabilities. Integration challenges relate more to settling on the right policies with regulators’ blessing. Ultimately, getting buy-in from notoriously risk-averse compliance officers requires building confidence that zero-knowledge math can keep funds away from sanctioned entities as effectively as human processes at traditional institutions. Initiatives like ZKProof and open research are key to establishing consensus around robust cryptography assumptions and threat models. But progress is being made towards balancing privacy and regulation through zero-knowledge protocols tailored for DeFi. * * * ![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # ZK Proofs for Balancing Privacy and Accountability by Anna Lysyanskaya - ZKProof Standards March 21, 2024|In [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/ "View all posts in ZKProof Policy @ DC") |4 Minutes ZK Proofs for Balancing Privacy and Accountability by Anna Lysyanskaya ====================================================================== [![ZKProof Standards](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)](https://zkproof.org/author/vivek99f886b602/) By [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) In a captivating talk ([slides here](https://github.com/zkpstandard/docs/raw/master/pages/presentations/2023-11-dc/20231130-zkproof-dc--Anna-Lysyanskaya---ZKPs-for-Balancing-Privacy-and-Accountability.pdf) , [youtube here](https://youtu.be/TmCoURJ-stk&t=37m36s) ), Anna Lysyanskaya from Brown University took us on a deep dive into the cryptographic building blocks that can enable systems balancing privacy and accountability. Building on the ideas of David Chaum’s seminal work on anonymous digital cash in the 1980s, she walked through innovative protocols that put user privacy front and center while still providing important safeguards. The Functions of Digital Money and e-cash ----------------------------------------- Lysyanskaya started by simplifying the concept of digital money down to three core functions: * withdrawing from the bank, * spending with a merchant, * and the merchant depositing funds back to the bank. The key challenge is making this entire cycle unforgeable and private. Chaum’s blind signatures provided an elegant solution, allowing users to withdraw “tokens” from the bank without revealing any information, and then spend them with merchants in an anonymized form. But Lysyanskaya wanted to take this basic e-cash framework further. She described how “**compact e-cash**” protocols allow users to withdraw multiple coins in a single transaction and then incrementally spend them with different merchants. The complexity grows only logarithmically with the size of the “wallet”, making it much more efficient. The core techniques powering these protocols are digital signatures, secure two-party computation, zero-knowledge proofs, and pseudorandom functions. In a withdraw transaction, the bank provides the user with random “seed” values and a blind signature, without learning anything about the user’s identity. The user can then derive unique serial numbers and double-spending equations to anonymously spend the tokens with merchants, proving the validity of the transactions without revealing their source. Cryptography for Compliance --------------------------- Lysyanskaya demonstrated how this base protocol can be augmented to enable important compliance features as well. For example, by having two linked serial numbers for each token – one for the coin itself, and one for the specific coin and merchant pair – it becomes possible to set limits on how much a user can transact with any single merchant before their identity is cryptographically revealed. This creates an automated way to prevent money laundering that’s impossible with physical cash. She also outlined protocols for “glitch protection”, where a user’s identity is only revealed after multiple instances of double-spending, as well as features for adding encrypted watchlists that allow auditors to secretly track certain users’ transactions. All of these advanced capabilities stem from composing various cryptographic primitives like Pedersen commitments, CL digital signature schemes, and pseudorandom proofs. The key is choosing and combining the right tools to construct verifiable, private, and auditable transactions. Lysyanskaya emphasized that much of this foundational work has actually been around for years, proven secure in theory. The remaining barriers are more around standardization, practical implementations, and alignment on policy requirements. While promising standards like **BBS+ signatures** are emerging and platforms like Hyperledger are experimenting, there is still a need for further collaboration between cryptographers, developers, businesses, and policymakers. As digital currencies and decentralized systems become more pervasive, the ability to maintain privacy while enabling compliance is becoming increasingly vital. No-one wants a future where all transactions are indiscriminately surveilled, but unchecked anonymity also carries risks. Lysyanskaya’s talk highlights how cutting-edge cryptography can bridge this divide, opening up new possibilities for inclusive and responsible systems – paving the way to the proverbial scenario of “having your cake and eating it too.” The journey to realizing this vision will require continued innovation and dialogue across multiple domains. But as Lysyanskaya demonstrated, many of the core cryptographic components are already well-understood. The path is illuminated – now we must choose to walk it. * * * ![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Privacy and Compliance: Striking a Delicate Balance by Pablo Kogan - ZKProof Standards April 1, 2024|In [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/ "View all posts in ZKProof Policy @ DC") |4 Minutes Privacy and Compliance: Striking a Delicate Balance by Pablo Kogan ================================================================== [![ZKProof Standards](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)](https://zkproof.org/author/vivek99f886b602/) By [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/03/Screenshot-2024-04-01-at-11.34.15.png?resize=840%2C317&ssl=1) As blockchain and cryptography advance, we are faced with a delicate challenge – how can we design systems that protect user privacy while still allowing for necessary compliance and regulation? In his talk ([slides](https://github.com/zkpstandard/docs/raw/master/pages/presentations/2023-11-dc/20231130-zkproof-dc--Pablo-Kogan--Privacy-and-Compliance-Striking-a-Delicate-Balance.pdf) , [video](https://youtu.be/TmCoURJ-stk&t=2m36s) ), Pablo Kogan from QEDIT explored this dilemma and presented some innovative approaches that aim to strike the right balance. Privacy and Compliance lie on a spectrum ---------------------------------------- Pablo started by framing the issue on a spectrum – at one extreme, we have fully transparent systems like traditional databases, where user data is decrypted and exposed to execute operations. At the other end, we have fully opaque and private systems like Monero and Zcash, where transactions reveal virtually no information. The goal, he argued, is to find a middle ground – systems that provide meaningful privacy guarantees while still enabling compliance where needed. He presented two potential paths to reach this middle ground – **start with a transparent system and add selective privacy**, or **start with an opaque system and layer on selective compliance mechanisms**. Using the example of Zcash’s Orchard protocol, he discussed an approach for the latter – enforcing “viewing keys” that would allow authorized entities like regulators to decrypt and view transaction histories, but only when necessary and with proper safeguards. This could be achieved through techniques like verifiable encryption and provable granularity of disclosure. ### Blacklists, Traceability and Privacy Budgets Another avenue he explored was the idea of blacklists and whitelists. A blacklisting system could allow authorities to temporarily freeze funds from suspicious addresses. The sender would then need to provide a cryptographic proof that their address is not on the blacklist before the transaction is permitted. Careful consideration would be needed around aspects like who controls the blacklist, whether canonical or re-randomized addresses are blacklisted, and effective circumvention. In a different vein, Pablo discussed an approach focused on “traceability” rather than blacklisting. Here, the aim is to prove that funds didn’t pass through any malicious entities or “hops” retroactively defined by authorities after the fact. This could be achieved by cryptographically enforcing the inclusion of canonical identities within encrypted transactions, making the transaction trail auditable without compromising privacy. A distinct concept presented was that of a “privacy budget”. Inspired by proposals like UTT (Unspent Transaction Tree), this involves providing users with a daily privacy allowance token. Small transactions up to the budget can remain fully shielded, while larger ones exceeding it would be auditable. This models the current cash vs banking system paradigm in the digital realm. ### No “one-size-fits-all” approach! Importantly, Pablo emphasized there is no universal solution. Different jurisdictions and use cases will demand different levels of privacy and compliance. He advocated for a real-world testing methodology, where protocols are iteratively refined based on practical experience. This could involve launching test blockchains with various configurations, multiple shielded asset pools with different feature sets on the same chain, or even specialized shielded pools isolating assets with particular compliance properties. The talk highlighted the nuances involved in blending privacy and compliance. There are technical challenges around efficient cryptographic proof systems, key management, and modeling different use cases. But there are also policy considerations – who holds the keys, who defines blacklists and audit requirements, and how to fairly provision privacy budgets. As blockchain and digital currencies gain traction, it will become increasingly important to navigate these complexities. Pablo’s proposals provide a thoughtful framework, leveraging cryptography and selective disclosures to find the sweet spot between confidentiality and accountability. The next steps will be iterative real-world experimentation and ongoing dialogue between technologists, businesses, and policymakers to shape inclusive and balanced solutions. * * * ![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # NISTs Views on Standardisation of Advanced Cryptography by René Peralta - ZKProof Standards April 3, 2024|In [ZKProof Policy @ DC](https://zkproof.org/category/zkproof-policy-dc/ "View all posts in ZKProof Policy @ DC") |4 Minutes NISTs Views on Standardisation of Advanced Cryptography by René Peralta ======================================================================= [![ZKProof Standards](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=40&d=identicon&r=g)](https://zkproof.org/author/vivek99f886b602/) By [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/) In his presentation, René Peralta described ([slides](https://github.com/zkpstandard/docs/raw/master/pages/presentations/2023-11-dc/20231130-zkproof-dc--Rene-Peralta--NISTs-Views-on-Standardization-of-Advanced-Cryptography.pdf) , [video](https://youtu.be/TmCoURJ-stk&t=2h11m23s) ) the role and “spirit” of NIST. The National Institute of Standards and Technology (NIST) is a non-regulatory government agency focused on driving innovation, industrial competitiveness, measurement science, standards of technology, economic security, and quality of life. NIST’s cryptographic technology group plays a pivotal role in researching, developing, and providing guidelines on best practices for cryptographic algorithms and problems. NIST and Cryptography --------------------- ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/03/Screenshot-2024-03-19-at-13.14.36.png?resize=840%2C357&ssl=1)![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/03/peralta.png?resize=840%2C123&ssl=1) NIST has been actively involved in various cutting-edge cryptographic projects, including the generation of random numbers through the NIST Randomness Beacon, quantum-resistant cryptography to address the vulnerabilities posed by large-scale quantum computers, and circuit complexity analysis for optimizing cryptographic computations. As NIST explores standardization in advanced cryptography domains beyond traditional encryption, hashing, and digital signatures, they face several key challenges. With limited resources, NIST must carefully consider the risks of standardizing techniques prematurely, as once a standard is issued, companies invest heavily in complying with it, making it difficult to backtrack. When should we standardize? --------------------------- One critical question is determining when a cryptographic technique is sufficiently mature for standardization. Should NIST prioritize standardizing quantum-resistant techniques or address the immediate needs of industry by standardizing non-quantum-resistant but practically useful techniques like pairing-based cryptography? NIST’s privacy-enhanced cryptography project aims to track and leverage cryptographic tools that enhance privacy, including zero-knowledge proofs, multi-party computation, fully homomorphic encryption, private set intersection, group signatures, functional encryption, private information retrieval, and structured encryption. The COVID-19 pandemic highlighted the importance of these techniques for privacy-preserving contact tracing. When deciding whether and when to standardize a technique like zero-knowledge proofs, NIST considers various criteria: 1. Market demand: If an application using zero-knowledge gains significant traction, the market may speak for standardization. 2. Stakeholder needs: Government agencies like the Social Security Administration or the Census Bureau may express specific needs for techniques like zero-knowledge proofs or private set intersection. 3. Killer application: A groundbreaking application requiring zero-knowledge may emerge, necessitating standardization. 4. Ad-hoc guidance: NIST may choose to provide recommendations on an ad-hoc basis rather than formal standardization. Interpreting these criteria is challenging, as different stakeholders may have conflicting interests. NIST aims to serve as an impartial arbiter, relying on its technical expertise to navigate these complexities. ### Why submit to be a NIST Standard? NIST has launched a call for submissions regarding multi-party threshold schemes, including a category focused on advanced cryptography like zero-knowledge proofs. This initiative aims to collect and curate reference implementations, gain trust and transparency, and encourage consensus within the cryptographic community. While NIST standards are not legally binding, the federal government’s market power as a significant customer incentivizes industry compliance. However, NIST’s role extends beyond issuing standards; by providing reference materials and serving as an honest broker of ideas, NIST hopes to positively influence the adoption of robust cryptographic solutions. NIST recognizes the limitations of market forces in protecting rights like privacy and acknowledges the need for guidance and regulations in areas where unfettered markets may fail. As an impartial government agency, NIST strives to navigate the complex landscape of advanced cryptography, balancing stakeholder needs, technical maturity, and long-term security considerations to drive the development and adoption of robust privacy-enhancing cryptographic solutions. * * * ![](https://secure.gravatar.com/avatar/1a2421ef22525705bae98c1bfac157a4?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/vivek99f886b602/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # ZKProof 5.5 talks summary Archives - ZKProof Standards ZKProof 5.5 talks summary ========================= [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-18-at-10.49.09-uai-258x172.png)](https://zkproof.org/2023/09/18/zkml-where-are-we-now-where-do-we-go-from-here-talk-summary-zkproof-5-5-daniel-kang/) September 18, 2023 ### [Scaling Trustless DNN Inference, zkml applications at ZKProof.org by Daniel Kang](https://zkproof.org/2023/09/18/zkml-where-are-we-now-where-do-we-go-from-here-talk-summary-zkproof-5-5-daniel-kang/) Daniel Kang gave a comprehensive overview of the current… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-12-at-15.03.52-uai-258x172.png)](https://zkproof.org/2023/09/12/zkps-and-post-quantum-signatures-from-vole-in-the-head-at-zkproof-org-by-peter-scholl/) September 12, 2023 ### [ZKPs and Post-Quantum Signatures From VOLE-in-the-Head at ZKProof.org by Peter Scholl](https://zkproof.org/2023/09/12/zkps-and-post-quantum-signatures-from-vole-in-the-head-at-zkproof-org-by-peter-scholl/) Peter presented the FAEST signature scheme, which achieves… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-12-at-14.50.09-uai-258x172.png)](https://zkproof.org/2023/09/12/lessons-from-darpa-sieve-at-zkproof-org-by-james-parker-kimberlee-model/) September 12, 2023 ### [Lessons from DARPA SIEVE at ZKProof.org by James Parker & Kimberlee Model](https://zkproof.org/2023/09/12/lessons-from-darpa-sieve-at-zkproof-org-by-james-parker-kimberlee-model/) James and Kimberlee clearly explained the SIEVE IR, a… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/02-zkproof5.5_recursive_proof_composition.pptx-uai-258x172.jpg)](https://zkproof.org/2023/09/12/recursive-proof-composition-by-ying-tong-lai/) September 12, 2023 ### [Recursive Proof Composition at ZKProof.org by Ying Tong Lai](https://zkproof.org/2023/09/12/recursive-proof-composition-by-ying-tong-lai/) Ying Tong Lai delivered an illuminating presentation that… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/01-zkproof55_2023_Page_36-uai-258x172.jpg)](https://zkproof.org/2023/09/12/plonk-standardization-zkproof-5-5-mary-maller-talk-summary/) September 12, 2023 ### [The Plonk Effort at ZKProof.org by Mary Maller](https://zkproof.org/2023/09/12/plonk-standardization-zkproof-5-5-mary-maller-talk-summary/) Mary Maller's overview of the modular approach to… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # ZKPs and Post-Quantum Signatures From VOLE-in-the-Head at ZKProof.org by Peter Scholl - ZKProof Standards September 12, 2023|In [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/ "View all posts in ZKProof 5.5 talks summary") |2 Minutes ZKPs and Post-Quantum Signatures From VOLE-in-the-Head at ZKProof.org by Peter Scholl ===================================================================================== [![ZKProof Standards](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)](https://zkproof.org/author/contact70d66e844e/) By [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-12-at-15.03.52-uai-258x145.png)](#) **ZKProof 5.5 in Barcelona** was a blast! We focused on standardization,and all the 100 participants, well, participated! ![:slightly_smiling_face:](https://i0.wp.com/a.slack-edge.com/production-standard-emoji-assets/14.0/apple-medium/1f642.png?w=840&ssl=1) Here’s summary of the talks, for those who couldn’t make it, but also as reference for the workgroups we formed. **Peter** illuminated a promising new paradigm for efficient zero-knowledge proofs using VOLE-in-the-head [(slides are here)](https://docs.google.com/presentation/d/1a9Dhvh4ZzF1U7-LWPpjd20Ua6YGhMYKd) . With crisp clarity, he mapped out how this novel approach builds on the VOLE tool from multi-party computation to enable simple, high-performance proofs with minimal cryptographic assumptions. His articulate explanations revealed the power of VOLE for building homomorphic commitments, as well as the elegance of making interactive VOLE proofs non-interactive. Peter presented the FAEST signature scheme, which achieves similar performance to hash-based signatures under only AES security, and provides post-quantum signatures under 5KB and fast signing/verification. ### VOLE Functionality:  * VOLE allows a prover to commit to a vector that the verifier can evaluate. This provides a linearly homomorphic commitment scheme. * Peter demonstrated how VOLE commitments can be used for circuit proofs, with local operations for linear gates and simple techniques for proving multiplications. ### VOLE-in-the-Head: * The prover secret shares the witness and converts the shares into a set of VOLE inputs. * A challenge from the verifier determines which commitments to open, allowing verification.This approach is far more efficient than heavy MPC computation.Advantages: * Simplicity of constructions make VOLE proofs easy to explain and implement. * High performance for prover as computations use VOLE commitments. * Minimal cryptographic assumptions, just symmetric primitives. * Concrete overhead as low as 10-16 bits per AND gate.Application to Signatures: * Peter presented the FAEST signature scheme using VOLE proofs of AES computation. * Achieves similar performance to hash-based signatures under only AES security. * Signatures under 5KB and fast signing/verification. * Overall, Peter made a compelling case for exploring VOLE-in-the-head as a new paradigm for simple and practical zero-knowledge proofs, opening up potential new applications. * * * ![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Scaling Trustless DNN Inference, zkml applications at ZKProof.org by Daniel Kang - ZKProof Standards September 18, 2023|In [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/ "View all posts in ZKProof 5.5 talks summary") |3 Minutes Scaling Trustless DNN Inference, zkml applications at ZKProof.org by Daniel Kang ================================================================================ [![ZKProof Standards](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)](https://zkproof.org/author/contact70d66e844e/) By [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-18-at-10.49.09-uai-258x144.png)](#) **ZKProof 5.5 in Barcelona** was a blast! We focused on standardization,and all the 100 participants, well, participated! ![:slightly_smiling_face:](https://i0.wp.com/a.slack-edge.com/production-standard-emoji-assets/14.0/apple-medium/1f642.png?w=840&ssl=1) Here’s summary of the talks, for those who couldn’t make it, but also as reference for the workgroups we formed. Daniel Kang gave a comprehensive overview ([slides here](https://docs.google.com/presentation/d/1NBQ9ub1URM5PFYq5-uY2EK6PG-KlcmDC) ) of the current capabilities of zero-knowledge proofs for machine learning (ZKML), clearly explaining what types of models like ImageNet, Twitter’s recommendation system, and GPT-2 can be proven today. He made a compelling case for the future potential of ZKML to enable trust in an increasingly digital world once efficiency improves, presenting benchmarks showing 50x faster proving with new hardware. By highlighting concrete applications like privacy-preserving inference and training audits and open sourcing frameworks, Kang is driving collaboration to advance ZKML and recruit participants to help make it practical at scale. ### Overview: * Daniel gave a comprehensive technical overview of the capabilities of zero-knowledge proofs for machine learning (ZKML) today using frameworks like his open source ZKML. * He clearly explained the key applications that are practical now like privacy-preserving inference and outlined the advances needed to expand adoption. * By highlighting concrete benchmarks and use cases, he made a compelling case for the potential of ZKML once efficiency improves. ### Current Capabilities: * Daniel discussed the guarantees of ZK proofs for ML, emphasizing how they enable trustless verification without interaction between parties. * He showed through benchmarks that today ZKML can handle models up to ImageNet scale for vision, production recommendation systems like Twitter’s, and small language models like GPT-2. * Daniel gave examples of applications like selective revealing of model weights/data for inference, training audits, generative model prompt marketplaces, and biometric ID. ### Advances Needed: * He presented data on proving times today using CPUs and how new hardware like FPGAs can accelerate proofs 50x. * Daniel explained how innovations in proving systems like CQ and circuit optimizations will expand what’s possible. * He highlighted the need for collaboration to improve efficiency through frameworks like his open source ZKML. ### Key Takeaways: * Daniel made a compelling case that ZKML will enable trust in an increasingly digital world. * But for mainstream adoption, advances are still needed to reduce proving costs, which he is driving through open source. * By showcasing concrete benchmarks and applications, he recruited participants to help make ZKML practical at scale. * This presentation built excitement for the potential of ZKML once efficiency catches up with the theory. * * * ![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Recursive Proof Composition at ZKProof.org by Ying Tong Lai - ZKProof Standards September 12, 2023|In [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/ "View all posts in ZKProof 5.5 talks summary") |2 Minutes Recursive Proof Composition at ZKProof.org by Ying Tong Lai =========================================================== [![ZKProof Standards](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)](https://zkproof.org/author/contact70d66e844e/) By [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-12-at-14.38.11-uai-258x113.png)](#) **ZKProof 5.5 in Barcelona** was a blast! We focused on standardization, and all the 100 participants, well, participated! ![:slightly_smiling_face:](https://i0.wp.com/a.slack-edge.com/production-standard-emoji-assets/14.0/apple-medium/1f642.png?w=840&ssl=1) Here’s summary of the talks, for those who couldn’t make it, but also as reference for the workgroups we formed. **Ying Tong Lai** delivered an illuminating presentation ([slides are here](https://docs.google.com/presentation/d/1SyKzge23KXyNJrIMpoTUKJVXPVft8-AE) ) that advanced understanding of recursive proof composition, clearly explaining techniques like folding schemes, highlighting implementations in areas like neural networks, outlining insightful criteria for comparison, and recruiting participants to drive progress on open problems around specifications, benchmarks, tooling, and theory through collaborative initiatives like ZK Proof. ### Overview: * Ying Tong gave an overview of recursive proof composition, covering motivations like reducing proof size and enabling incrementally verifiable computation. * She explained core techniques like full recursion, accumulation schemes, and folding schemes. * Ying highlighted real-world implementations applying these techniques to use cases like verifiable delay functions and virtual machines. ### Details: * She covered how full recursion represents the verifier circuit inside proofs, requiring a succinct verifier. * Ying explained how accumulation and folding schemes reduce overhead by only verifying parts of the computation. * She outlined criteria for comparing systems like zero knowledge, field size, threshold, and efficiency. * Ying detailed the security bug found in the Nova implementation. ### Discussion: * Proposed working groups on topics like tooling, benchmarking, specifications, and theoretical foundations. * Emphasized need to improve specifications and standards around things like curve cycles. * Discussed tradeoffs between small field FRI and folding schemes. ### Key Takeaways: * Recent advances have reduced overhead of recursive proofs, enabling large computations. * A variety of real-world implementations are applying these techniques. * Open problems remain around specifications, benchmarks, tooling, and theory. * Collaborative initiatives like ZK Proof standards can help drive progress. * * * ![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Page not found - ZKProof Standards 404 === ##### Page Not Found * * * [Return Home](https://zkprooforg.wpcomstaging.com/ "Homepage") [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Lessons from DARPA SIEVE at ZKProof.org by James Parker & Kimberlee Model - ZKProof Standards September 12, 2023|In [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/ "View all posts in ZKProof 5.5 talks summary") |2 Minutes Lessons from DARPA SIEVE at ZKProof.org by James Parker & Kimberlee Model ========================================================================= [![ZKProof Standards](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)](https://zkproof.org/author/contact70d66e844e/) By [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/Screenshot-2023-09-12-at-14.50.09-uai-258x113.png)](#) **ZKProof 5.5 in Barcelona** was a blast! We focused on standardization, and all the 100 participants, well, participated! ![:slightly_smiling_face:](https://i0.wp.com/a.slack-edge.com/production-standard-emoji-assets/14.0/apple-medium/1f642.png?w=840&ssl=1)  Here’s summary of the talks, for those who couldn’t make it, but also as reference for the workgroups we formed. **James and Kimberlee** clearly explained the SIEVE IR ([slides here](https://docs.google.com/presentation/d/1A_NccFauTjQ065EXHUPu6rvLJx6KtHqo) ), a collaborative specification enabling interoperability between frontends and backends. They invited the community to learn from their experience, presenting the IR as an extensible standard that could outlive the SIEVE program. By sharing lessons learned, they recruited participants to advance this specification effort, aligned on goals like flexibility and scalability, and built momentum to evolve these standards beyond SIEVE. ### Overview: * The IR provides a circuit representation of ZK proofs, designed through a formal process with multiple SIEVE teams. * Enables frontends to interface with diverse backends, promoting modular interoperability. * Language features like types, gates, functions demonstrate extensibility. * Memory management and field conversions handle large proofs across prime fields. * Tools built on IR show range of applications in vulnerabilities, policy enforcement. ### Lessons Learned: * Understand different visions and find common ground across teams. * Have a standard process with unbiased arbiter to move things forward. * Flexibility and scalability were critical goals to support innovation. * Specification has proven useful enough to continue leveraging. ### Looking Ahead: * IR could become a broader standard or interoperate with Plonk. * Community should try it out and consider evolving it. * Can build plugins to extend functionality without syntax changes. * Resources available on GitHub to get started. * Continued feedback will be important as standards iterate. ### Key Takeaways: * IR provides a collaborative, extensible specification for ZK circuits. * Enables modular interoperability between frontends and backends. * Valuable lessons on designing standards by committee. * Opportunity to build on this and advance ZK standards. * Community involvement will be critical to evolve IR beyond SIEVE. * * * ![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # The Plonk Effort at ZKProof.org by Mary Maller - ZKProof Standards September 12, 2023|In [ZKProof 5.5 talks summary](https://zkproof.org/category/zkproof-5-5-talks-summary/ "View all posts in ZKProof 5.5 talks summary") |3 Minutes The Plonk Effort at ZKProof.org by Mary Maller ============================================== [![ZKProof Standards](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)](https://zkproof.org/author/contact70d66e844e/) By [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2023/09/01-zkproof55_2023_Page_36-uai-258x145.jpg)](https://zkproof.org/wp-content/uploads/2023/09/01-zkproof55_2023_Page_36.jpg) [![](https://zkproof.org/wp-content/uploads/2023/09/01-zkproof55_2023_Page_12-uai-258x145.jpg)](https://zkproof.org/wp-content/uploads/2023/09/01-zkproof55_2023_Page_12.jpg) **ZKProof 5.5 in Barcelona** was a blast! We focused on standardization, and all the 100 participants, well, participated! ![:slightly_smiling_face:](https://i0.wp.com/a.slack-edge.com/production-standard-emoji-assets/14.0/apple-medium/1f642.png?w=840&ssl=1)  Here’s summary of the talks, for those who couldn’t make it, but also as reference for the workgroups we formed. ### **Mary Maller’s overview of the modular approach to specifying Plonk** In this talk ([slides are here](https://drive.google.com/file/d/1VltZSQjqYqy9xIXGABmiXVtAKLi_nsn4/view?usp=sharing) ), Mary clearly explained the components of the forming standard and rationale. She successfully called for community involvement through working groups and iterative development. By leading the discussion, she recruited participants to advance the standards effort, aligned on goals like interoperability and simplicity, and built momentum to drive this complex long-term project forward. ### Overview: * Mary gave an overview of the goal to write specifications for Plonk in a modular way, covering the constraint system, optimizer, interactive oracle proof (IOP), polynomial commitments, and Fiat-Shamir transform. * She emphasized the need for simplicity, interoperability, and concrete applications to drive adoption. * The process will involve multiple working groups for each component, requiring close collaboration over many years. ### Constraint System: * Discussed the Plonk constraint system and the need for simplicity, comprehensiveness, and wide compatibility. * Presented the Plonk optimizations like shifts and rotations and the need to preserve meaning. * Showed examples of draft specs they are working on for Plonk constraints. ### **Interactive Oracle Proof:** * Explained how IOPs work at an abstract level with polynomials. * The IOP working group needs to focus on interoperability with other components. ### Oracle Compiler: * This compiles the IOP into an actual interactive protocol using polynomial commitments. * The choice of polynomial commitment scheme defines properties like proof size, crypto assumptions, etc. * The oracle compiler enables switching out polynomial commitments easily. * APIs and security requirements need to be defined. ### Polynomial Commitments: * Working groups needed for specific schemes like Bulletproofs, FRI, and KZG. * Consistent APIs needed across schemes. * Important to get 128 bits of security even with grinding attacks. * Need to standardize things like pairings. ### Fiat-Shamir Compiler: * Can leverage prior work from sigma protocol specifications. ### Discussion: * Participants split into groups to discuss forming working groups, timelines, goals, and interdependencies. * Emphasized need for concrete applications and constraints to drive adoption. * Discussed how standards could allow switching to quantum-safe schemes. * Talked through open questions and challenges around modularity. ### Key Takeaways: * Modular specifications enabling interoperability are critical. * Community involvement through working groups will be essential to succeed. * Managing timelines and dependencies between groups will be challenging but important. * Keeping specifications simple, even if less optimized will promote adoption. * Concrete applications like threshold crypto will help drive use. * This will be an iterative, multi-year process requiring continuous feedback. * * * ![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=240&d=identicon&r=g) ##### [ZKProof Standards](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [All author posts](https://zkproof.org/author/contact70d66e844e/ "ZKProof Standards post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Setup Ceremonies - ZKProof Standards Setup Ceremonies ================ June 30, 2021 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Anthony Mpho Matlala](https://zkproof.org/author/tony007matlala/) _–Written by Alex Pruden and Anthony Matlala_ Introduction ------------ Zero-knowledge proofs (ZKPs) have a particularly important history in the context of cryptocurrencies since [Zerocoin](http://zerocoin.org/media/pdf/ZerocoinOakland.pdf) and [Zerocash](http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) . While early implementations focused on enabling general privacy for financial transactions, ZKPs have found increasing applicability outside of mere obfuscation. For example, zkRollups are a technique to increase the scalability of Ethereum by enabling greater transaction throughput. Recursive proof constructions, such as described in [Halo](https://eprint.iacr.org/2019/1021.pdf) , can be used to create succinct blockchains, reducing the burden on light clients. Proposals such as [Proof-of-Necessary Work](https://eprint.iacr.org/2020/190.pdf) leverage the capabilities of zkSNARKs to provide security at the consensus layer of the network. Finally, constructions such as [Zexe](https://eprint.iacr.org/2018/962.pdf) enable an entirely new programming model of off-chain computation, on-chain verification upon which new classes of applications can be built not only for the cryptocurrency use cases but the traditional web as well. ZKPs are not one-size fits all ------------------------------------ We often refer to zero-knowledge proofs monolithically, but there are many different flavors of ZKPs. Strictly speaking, a ZKP scheme provides the property of “zero-knowledge” such that the verifier of a proof learns nothing about the facts underlying the statement being proved. ZKPs can be both interactive and non-interactive, although non-interactive schemes have traditionally garnered more interest. There are several classes of non-interactive ZKPs that fulfill that criteria, including: * Non-interactive Zero-Knowledge Arguments (NIZKs) * Succinct Non-interactive Zero-Knowledge Arguments (SNARGs) * Succinct Non-interactive Zero-Knowledge Arguments of Knowledge (SNARKs or sometimes zkSNARKs) zkSNARKs have been the most popular for use in cryptocurrencies due to their succinctness and efficiency. The first real-life deployment of a SNARK was the Pinnochio protocol in ZCash Sprout, later replaced by a pairing-based zk-SNARK introduced by Jens Groth in [Groth16](https://eprint.iacr.org/2016/260.pdf) . Now colloquially referred to as “Groth16,” this construction has become popular in a variety of cryptocurrency applications because of its relatively small proof sizes and constant-time proof verification. Despite their adoption to date, there are two main critiques of zk-SNARKs. First, constructions such as [Groth16](https://eprint.iacr.org/2016/260.pdf) are not universal but fixed to a single NP-relation. In other words, proofs are specific to a given program. Changing the program means starting over, throwing out the old parameters, and generating new ones. Thus, the flexibility of these zkSNARKs is limited. Second, zkSNARKs rely on a common reference string (CRS) as a public parameter for proving & verifying. This CRS must be generated in advance by a trusted party. The information used to create the CRS, called ‘toxic waste’ needs to be destroyed as soon as the CRS is created. Otherwise, it can be used by adversaries to forge fraudulent proofs. Academic research on universal SNARKs (e.g. Marlin, PLONK, etc) has largely addressed the first critique. As for the second, we know of zero-knowledge proof constructions that allow for transparent parameter generation. [Bulletproofs](https://web.stanford.edu/~buenz/pubs/bulletproofs.pdf) and [STARKs](https://starkware.co/) (Scalable Transparent Arguments of Knowledge) for example do not require any trusted setup. However, while both STARKs and Bulletproofs have great applications, zkSNARKs (and especially non-universal SNARKs like Groth16) have yet to be beaten in terms of practical efficiency. A notable advantage of zkSNARKs is their relatively small proof sizes and constant-time verification. These make them the tool of choice for many blockchain-based applications. Securely generating the CRS via MPC ----------------------------------- Because of their advantages, zkSNARKs are not going away anytime soon. But the reality is that the security of a system based on zkSNARKs largely boils down to how the CRS was generated. Doing so without compromising the ideals of privacy-preserving blockchain-based systems: (security and decentralization) is very important. The generation of public parameters for zkSNARKs is called the “setup ceremony” because of its importance and (as we will see) the need for multiple independent parties to contribute to the process. So far, the preferred technique for setup ceremonies has been multi-party computation (MPC). Setup ceremony MPC schemes are interactive protocols involving multiple parties who contribute randomness to iteratively construct the CRS. Key to this technique is that all parties need to keep the inputs (their sampled randomness) hidden. In fact, honest participants should delete this “toxic waste,” immediately. Otherwise, a malicious party with knowledge of these inputs could exploit the underlying mathematical structure of the CRS to create unsound proofs. A typical ceremony consists of $N$ number of players, the coordinator, and the verifier. The MPC protocols are always of a round-robin nature, where a player $P\_i$ receives a single message from player $P\_{i-1}$. Player $P\_i$ adds their input to accumulated randomness before passing it onto Player $P\_{i+1}$. In the end, the final result is the CRS. In the intermediate state, as it is being passed between players, the message is referred to as the “transcript.” The first family of MPC protocols for ZKPs was proposed by Ben-Sasson et al. in \[[BCGTV15](http://www.ieee-security.org/TC/SP2015/papers-archived/6949a287.pdf)\ \]. The authors prove that the CRS generated with these protocols is secure as long as at least one contributing party is honest. Since then, the goal of setup ceremonies has been to maximize the number of honest and independent contributors. If there are many, independent participants, then intuitively the likelihood that all are dishonest is reduced to the point of negligibility. Zcash used the BCGTV scheme to generate the CRS for the first version of ZCash, “Sprout” as described in this [post](https://electriccoin.co/blog/the-design-of-the-ceremony/) and [episode](https://www.wnycstudios.org/podcasts/radiolab/articles/ceremony) of the U.S. National Public Radio show, Radiolab. Despite its novelty, a drawback of the BCGTV protocol requires that participants be identified in advance. So participation in the ceremony was cumbersome and limited to experts who could be trusted to perform it properly. Because of the limited participation, critics argued that the degree of trust required was still too high and contradicted the ideals of the decentralized system the zkSNARK being set up to secure. The Zcash ceremony demonstrated that successfully running a setup ceremony boils down to the logistics and efficiency of coordinating participants, who ideally are unrelated to one another. This ensures a lower (real and perceived) likelihood that all contributors might maliciously collude. But it can be challenging to coordinate geographically distributed participants who must remain available for the entire duration of the ceremony. In 2017, Bowe et al. introduced a second family of MPC protocols \[[BGM17](https://eprint.iacr.org/2017/1050.pdf)\ \] specifically for pairing-based zk-SNARKs like Groth16. This paper aimed to address some of the drawbacks of prior schemes. In their proposed protocol called MMORPG, a central “coordinator” manages messages between the participants. The CRS is generated in two phases. The first phase referred to as “Powers of Tau”, produces generic setup parameters that can be used for all circuits of the scheme, up to a given size. The second phase converts the output of the Powers of Tau phase into an NP-relation-specific CRS. ![](https://zkproof.org/wp-content/uploads/2021/06/powers_of_tau-uai-258x67.jpg) Figure 1: A diagram of the original BGM17 MPC Protocol The “Powers of Tau” ceremony has several advantages over earlier schemes. First, contributors do not need to be selected in advance. Instead, the protocol uses a random beacon that produces public, random values at set intervals to enable a continuous ceremony. Participants, therefore, do not always need to be available and online. The random beacon also ensures public verifiability of the coordinator. As a result, the protocol can theoretically support hundreds or even thousands of participants. Since the original publication of the paper, Powers of Tau ceremonies have become the industry standard. Projects such as [Filecoin](https://filecoin.io/blog/posts/participate-in-our-trusted-setup-ceremony/) , Ethereum ([Semaphore](https://github.com/appliedzkp/semaphore) ), and Zcash [Sapling](https://z.cash/technology/paramgen/) have used it to generate a CRS for their systems. But how does it work under the hood? Powers of Tau, in depth ----------------------- Pairing-based zk-SNARKs involve a bilinear map $e : \\mathbb{G}\_1 \\times \\mathbb{G}\_2 \\to \\mathbb{G}\_T$ defined by $e( a \\cdot g\_1 , b \\cdot g\_2 ) = {g\_T}^{ab}$ where $\\mathbb{G}\_i$ is a group of order $p$ , and for each $i \\in \\{ 1, 2, T \\}$, $g\_i$ is the generator of $G\_i$. In order to appreciate the serialized process of Powers of Tau, as well as to see the cumulative nature of the CRS elements, consider a toy example: a 3-player MPC ceremony for a zk-SNARK where $P(x) = 3x^2 + 9x + 13$ is the polynomial associated with the arithmetic circuit of the NP-relation. The CRS in this example is a triple $\\big( \\mathbf{s} \\cdot g\_1 ,\\ \\ \\mathbf{s}^2 \\cdot g\_1 ,\\ \\ \\alpha P(\\mathbf{s}) \\cdot g\_1 \\big)$, where $\\mathbf{s} = s\_{N+1} s\_N s\_{N-1} \\cdots s\_2 s\_1$ and $\\mathbf{ \\alpha } = \\alpha\_{N+1} \\alpha\_N \\alpha\_{N-1} \\cdots \\alpha\_2 \\alpha\_1$ are scalar multiples that have been cumulatively computed in a serial manner. Following the MPC protocol in \[[BGM17](https://eprint.iacr.org/2017/1050.pdf)\ \], each player contributes their multiplicative factor to intermediate values of the CRS from previous players, as depicted in Figure 1 below. ![](https://zkproof.org/wp-content/uploads/2021/06/toy-3-player-uai-258x143.png) Figure 2: A simplified 3-player MPC setup protocol The toxic waste in this example is $\\{ \\mathbf{s} , \\mathbf{s}^2 , \\alpha \\}$. Note that with each successive contribution, the independent randomness chosen by the player accumulates in the transcript. Because we assume discrete log is hard in these groups, it’s infeasible for Player $N$ to “unwind” the transcript to determine any of the prior contributions of Players $0 \\dots N-1$. We can observe that the toxic waste in Phase 1 is $\\{ \\mathbf{s} , \\mathbf{s}^2 \\}$ because $ deg(P(x)) = 2$. For a general polynomial of degree $n$ , and if the traditional symbol $\\tau$ is used instead of $\\mathbf{s}$ , the toxic waste in Phase 1 would be $\\tau , \\tau^2 , \\tau^3 , \\dots , \\tau^n$ and thus the name “powers of tau”. Optimistic Pipelining --------------------- MMORPG was a step forward in the design of setup ceremonies, enabling greater participation and streamlining the procedure by introducing a coordinator. Yet the serialized nature of the protocol remains a drawback. Even though participants no longer have to be online for the entire ceremony, they can still only participate one at a time. Because the CRS scales linearly with the size of the circuit, individual contributions can take a long time, and as a result, setup ceremonies are less likely to attract participants the longer they go on. Fortunately, there have been recent proposals on how to improve MMORPG to parallelize the process. For example, Justin Drake of the Ethereum foundation proposed [optimistic pipelining](https://ethresear.ch/t/accelerating-powers-of-tau-ceremonies-with-optimistic-pipelining/6870) . In such a scheme, instead of waiting (on one long queue in order) to contribute to the entire transcript, the CRS is split into smaller segments called rounds to which participants contribute in the normal way (sequentially but waiting in shorter queues) before the round result is submitted to the ‘aggregate’ transcript. Vitalik Buterin made an observation, in the form of a comment on Justin Drake’s [post](https://ethresear.ch/t/accelerating-powers-of-tau-ceremonies-with-optimistic-pipelining/6870) , that the players’ contributions do not need to be made in the strict order of exponents. The key insight is that contributions can be applied to different parts of the CRS simultaneously, enabling participants to contribute to an MMORPG ceremony in parallel. This significantly reduces end-to-end computation time for the MPC. We describe setups that use this method as “optimistic setups.” Although these schemes might suffer from denial-of-service attacks, in the worst case the coordinator could simply discard the contributions of players from a single round. This is much better than aborting the entire ceremony. Kobi Gurkan proposed an MMORPG MPC variant, where the security of Drake’s optimistic setup is enhanced by splitting verification into the proof-of-knowledge **CheckPOK** and consistency check. In this case, the verifier runs **CheckPOK** for every segment but runs the consistency check only once at the end of the ceremony. This results in an optimized and secure MPC for an arithmetic circuit with parameters of any size. ![](https://zkproof.org/wp-content/uploads/2021/06/optimistic_pipelining-uai-258x295.jpg) Figure 3: Powers of Tau with Optimistic Pipelining Celo’s recent setup ceremony [Plumo](https://celo.org/plumo) used the optimistic MMORPG MPC. [Aleo](https://aleo.org/) plans to follow suit with its forthcoming setup ceremony. The MMORPG MPC scheme is particularly well suited for systems such as Zexe, as the powers of tau parameters can be used as the system’s general parameters while allowing flexibility with individual applications choosing their specific arithmetic circuit CRS in Phase 2. Further Optimization Strategies ------------------------------- Several other strategies have been used to unravel this MPC logistic conundrum. Note that the original MMORPG used a central “coordinator” to manage messages to and from participants, and assembles the transcript. Historically, this role has been performed manually. But by automating the coordinator, the process becomes less logistically intensive AND makes the ceremony more secure by reducing the chance of human error. This is the path teams have followed recently. For example, Celo’s recent [Plumo](https://celo.org/plumo) ceremony featured an automated coordinator (see the [Espero](https://www.youtube.com/watch?v=LKbDNc-LrA4)) talk by Kobi Gurkan for more details). Beyond pure decentralization and security concerns, teams are increasingly viewing these ceremonies as products in their own right. For example, [Tornado.cash](https://ceremony.tornado.cash/) ran a setup ceremony that enabled users to contribute directly from the web browser, resulting in a record-breaking number of 1114 participants. The success of the Tornado setup shows that, in contrast to prior ceremonies, which were viewed as a necessary evil, modern setup ceremonies that put the user experience ‘front and center’ not only encourage more contributions but can be viewed as products in their own right. Conclusion ---------- Though many have argued that the requirement to generate the CRS is a critical flaw for zkSNARKs, one must acknowledge their efficiency advantages over other ZKP schemes. This is why they remain the industry standard, and why so many teams and researchers have evolved and improved these ceremonies to where we are today. And thanks to improvements to the protocol, infrastructure, and UX layers, participation rates have gone up significantly. Whereas the original Zcash ceremony had only six participants, modern ceremonies can theoretically scale to support hundreds or even thousands of participants. And since only a single honest participant is required for the CRS to be secure, more participants generally equals more security, as each independent member who joins makes collusion much more inconceivable. And as academia and industry continue to evolve and refine best practices around setup ceremonies, the challenge of running the MPC protocol to set up parameters for zkSNARKs will only get easier over time. Innovations that are making setup ceremonies more efficient are mirrored in the breathtaking pace of ZKP research. Schemes are becoming more efficient, making applications practical, encouraging further innovation and development. This has led to a “Moore’s Law”-like curve of improvement for ZKPs. Now there are even so-called “transparent” zkSNARKs (such as [Fractal](https://eprint.iacr.org/2019/1076.pdf) and [SuperSonic](https://eprint.iacr.org/2019/1229) ) that remove the requirement for a trusted setup altogether. Despite these innovations, the efficiency of existing zkSNARKs such as Groth16 means that they will likely continue to be applied for years to come. Therefore, setup ceremonies can provide an opportunity for a collaborative community celebration of and for the project that is implementing them. So they represent an opportunity to embrace, rather than a necessary evil to overcome. [Credentials](https://zkproof.org/tag/credentials/) [Education](https://zkproof.org/tag/education/) [Tech](https://zkproof.org/tag/tech/) [Zero-knowledge proofs](https://zkproof.org/tag/zero-knowledge-proofs/) * * * ![](https://secure.gravatar.com/avatar/269929faf63fc4a46e78e3414a9e5e91?s=240&d=identicon&r=g) ##### [Anthony Mpho Matlala](https://zkproof.org/author/tony007matlala/ "Anthony Mpho Matlala post page") Mathematician Cryptographer, Blockchain enthusiast, with interests in Privacy and Zero-knowledge Proofs, ... bridging the gap between theory and real-life application. [All author posts](https://zkproof.org/author/tony007matlala/ "Anthony Mpho Matlala post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2021/06/30/setup-ceremonies/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Call for Papers: 3rd ZKProof Workshop - ZKProof Standards Call for Papers: 3rd ZKProof Workshop ===================================== Workshop Submissions -------------------- The [ZKProof Standardization effort](https://zkproof.org/) is now accepting submissions to the 3rd ZKProof Workshop, which will be held in London, in 4-6 April 2020. The workshop addresses the security, implementation and applications of zero-knowledge proofs. The main goal of this workshop is to convey and facilitate progress in zero-knowledge proof technology, by sharing knowledge among participants and by creating public living documents that convey the state of the art. Towards this goal, submissions can be along the following tracks: **Community Proposals** serve as references and guidelines agreed upon by the community, that promote correct usage and interoperability of zero-knowledge proofs. We envision that subsequent work, to be defined in collaboration with standard bodies, will be required to gain official status as a normative standard. **Systematization-of-Knowledge (SoK)** papers serve to map the state of the art on some specific aspect of the workshop’s scope. They should be comprehensive in covering the main approaches to that aspect, compare-and-contrast them, and offer effective conceptual frameworks for understanding the relations between these alternatives (e.g., models, distinguishing properties, metrics and decomposition into building blocks). The accepted submissions may be invited for publication in a dedicated lecture notes volume; however, unlike a standard conference format, we expect the authors to make revisions to their initial submissions _based on feedback and discussion_ at the workshop, as discussed below. #### Important Dates * **2 February 2020, 23:59pm PST:** submission deadline * **25 February 2020:** notification of acceptance/rejection to the workshop * **4-6 April 2020 (London):** in-workshop presentation and discussion * **TBD:** Revised version due [Submit Paper](https://submissions.zkproof.org) * [Scope](#tab-07c11dd0-d7cb-3) * [Process](#tab-b030f093-2724-2) * [Submission Requirements](#tab-1579400953-1-83) * [Reviewing Committee](#tab-1579400953-2-68) Submissions on any topic related to zero-knowledge proofs are welcome. Please review the current [ZKProof documents](https://zkproof.org/documents.html) for examples. This includes, _but is not limited to_, the following: * Terminology, definitions and models * ZK proof-system constructions and their building blocks * Implementation of ZK proof system * Interoperability and integration between proof-system implementation, or components thereof (e.g., APIs and file formats) * Benchmarking * Applications of ZK proof systems (in particular, reusable/abstracted application-level protocols) * Domain-specific languages for expressing statements to be proven in zero knowledge * Security analysis and formal verification The process is oriented towards curating pertinent work along the above tracks; sharing it among the workshop participants to disseminate the knowledge and collect feedback, and then guiding it towards subsequent inclusion in the body of documents maintained by the ZKProof Standardization effort. It will proceed as follows. ### Pre-workshop Submissions can be made at [submissions.zkproof.org](https://submissions.zkproof.org/) until the submission deadline (2nd February 2020, 23:59pm PST) Each submission will be reviewed by the **Review Committee**, which will decide whether to accept it to the workshop. Author names will be visible to reviewers; reviewer names will not be visible to authors. ### At-workshop Accepted submissions will be presented at the workshop by one of the authors, and discussed by workshop participants in dedicated working groups. Notes will be taken. ### Post-workshop Based on feedback collected at the workshop, the Review Committee will decide whether to incorporate these submissions as part of the ongoing ZKProof standardization and its [editorial process](https://github.com/zkpstandard/zkreference) (it is expected that most presented submissions will pass this bar). In this case, revisions (reflecting community input) are expected. The revised versions will be made part of the ZKProof Standardization document repository, and may also be invited for publication in a dedicated lecture notes volume. Subsequently, the authors are _encouraged_ to remain engaged in the revision and updating of their Proposal or SoK. Submissions must be prepared in LaTeX, 11-point font, single-column. There is no page limit. The structure is up to authors’ discretion, but should include all of the following: * Title, prefixed with either “Proposal:” or “SoK:” to designate the track. * Author names and affiliations. * Background and motivation: contextualize the problem being addressed, and motivate its importance and the potential impact of the submission. Provide references.. * Scope: it should be clear what the scope of submission and what is excluded. * Terminology: use terminology consistent with the existing [ZKProof Standardization documents](https://zkproof.org/documents.html) , and in particular the Community Reference, whenever possible. When new terminology is required, introduce it explicitly. * Security: explicitly discuss security implications of the submission (if any). * Implementation: if relevant, submit an open source prototype/prototype implementation, by including a reference to the code repository with the code. ### Expectations on disclosure and licensing of intellectual property See the [ZKProof intellectual property policy](https://zkproof.org/ip.html) . ### Chairs * Abhi Shelat (Northeastern University) * Eran Tromer (Columbia University and Tel Aviv University) ### Members * Daniel Benarroch, QEDIT * Jonathan Bootle, Berkeley * Benedikt Buenz, Stanford * Dario Fiore, IMDEA Software * Ben Fisch, Stanford * Steven Goldfeder, Cornell Tech * Carmit Hazay, Bar-Ilan University * Daira Hopwood, Electric Coin Co. * Mary Maller, Ethereum Foundation * Izaak Mekler, O(1) Labs * Mariana Raykova, Google * Alessandra Scafuro, NCSU * Justin Thaler, Georgetown University * Riad Wahby, Stanford * Yupeng Zhang, Texas A&M University [Submit Paper](https://submissions.zkproof.org) For any further questions, please email [\[email protected\]](/cdn-cgi/l/email-protection#096a66677d686a7d497362797b66666f27667b6e) . [](#) --- # Workshop 5 - ZKProof Standards ZKProof 5th Workshope ===================== Tel-Aviv ,Israel ================ [Watch it](https://www.youtube.com/watch?v=TrcT3-VPOz4&list=PLOEty2U8Y69ULDD8YxqQ8kWg8Qn7N8XHZ "Watch it") _**The ZKProof Steering Committee is happy to announce the 5th ZKProof Workshop, to be hosted in Tel Aviv in November 15-17.**_ The goals of the ZKProof initiative are to promote the standardization of zero-knowledge proof cryptography and to increase the engagement of companies and researchers worldwide. We are aware that a virtual event limits the personal interaction that is desirable for strengthening any community, especially in the cryptography community, which benefits greatly from these interactions. We will focus on productive interactions and the high-quality discussions, strive to make the workshop accessible and enable even more community members to take an active role in the standardization initiative. We strongly encourage everyone to join us in every session, because we value community participation and many of the discussions will continue from one session to another. Furthermore, we are hosting networking sessions throughout the event where you will be able to meet your peers, have tea with a friend, and more. **Where to sleep?** The workshop will take place at the Tel Aviv Stock Exchange, next to Rothschild boulevard, the area called “Lev Hair,” meaning “The heart of the city.” Most of the hotels in Neve Zedek, Rotchild boulevard, and the rest of the area will be a good choice if you are looking for accommodation in the venue area. Here are some of the hotels we like at different price levels [Hotel 65](https://www.booking.com/hotel/il/65.en-gb.html?aid=318615&label=New_Hebrew_HE_IL_20193534265-WOuEdgyszfdR7jrmwF%2AHCwS217272261743%3Apl%3Ata%3Ap1%3Ap2%3Aac%3Aap%3Aneg&sid=a65e93c8b9e89e27848b66d0ec9b75d8&all_sr_blocks=190195901_284631630_1_0_0&checkin=2022-11-14&checkout=2022-11-17&dest_id=1901959&dest_type=hotel&dist=0&group_adults=1&group_children=0&hapos=26&highlighted_blocks=190195901_284631630_1_0_0&hpos=1&lang=en-gb&matching_block_id=190195901_284631630_1_0_0&no_rooms=1&req_adults=1&req_children=0&room1=A&sb_price_type=total&soz=1&sr_order=popularity&sr_pri_blocks=190195901_284631630_1_0_0__277300&srepoch=1663842117&srpvid=723948887bee00ba&type=total&ucfs=1&lang_click=other&cdl=he&lang_changed=1) – Atlass Hotels, boutique hotel on Rothchild bulevard [Fabric Hotel](https://www.booking.com/hotel/il/fabric-an-atlas-boutique.en-gb.html?aid=318615&label=New_Hebrew_HE_IL_20193534265-WOuEdgyszfdR7jrmwF%2AHCwS217272261743%3Apl%3Ata%3Ap1%3Ap2%3Aac%3Aap%3Aneg&sid=a65e93c8b9e89e27848b66d0ec9b75d8&all_sr_blocks=356779108_279606109_1_0_0&checkin=2022-11-14&checkout=2022-11-17&dest_id=1901959&dest_type=hotel&dist=0&group_adults=1&group_children=0&hapos=39&highlighted_blocks=356779108_279606109_1_0_0&hpos=14&lang=en-gb&matching_block_id=356779108_279606109_1_0_0&no_rooms=1&req_adults=1&req_children=0&room1=A&sb_price_type=total&soz=1&sr_order=popularity&sr_pri_blocks=356779108_279606109_1_0_0__246000&srepoch=1663842117&srpvid=723948887bee00ba&type=total&ucfs=1&lang_click=other&cdl=he&lang_changed=1)  – an Atlas Boutique Hotel [Ruby](https://www.booking.com/hotel/il/ruby.en-gb.html?aid=311984&label=ruby-mt8coB06DKnJgbEG9_tPqgS540983082138%3Apl%3Ata%3Ap1%3Ap2%3Aac%3Aap%3Aneg%3Afi%3Atikwd-893739003767%3Alp20517%3Ali%3Adec%3Adm%3Appccp%3DUmFuZG9tSVYkc2RlIyh9YXdX6HrtnYy-Ml68sH-ljtU&sid=a65e93c8b9e89e27848b66d0ec9b75d8&all_sr_blocks=571342325_218877820_0_0_0;checkin=2022-11-14;checkout=2022-11-17;dest_id=-781545;dest_type=city;dist=0;group_adults=2;group_children=0;hapos=1;highlighted_blocks=571342325_218877820_0_0_0;hpos=1;matching_block_id=571342325_218877820_0_0_0;no_rooms=1;req_adults=2;req_children=0;room1=A%2CA;sb_price_type=total;sr_order=popularity;sr_pri_blocks=571342325_218877820_0_0_0__225225;srepoch=1663848445;srpvid=df1f553ed74000d1;type=total;ucfs=1&#hotelTmpl)  – Small, minimalist, quiet, and beautiful boutique hotel (no breakfast option). [Selina Tel Aviv Beach](https://www.booking.com/hotel/il/selina-tel-aviv-beach.html?aid=318615&label=New_Hebrew_HE_IL_20193534265-WOuEdgyszfdR7jrmwF%2AHCwS217272261743%3Apl%3Ata%3Ap1%3Ap2%3Aac%3Aap%3Aneg&sid=a65e93c8b9e89e27848b66d0ec9b75d8&all_sr_blocks=817447002_344252965_0_2_0&checkin=2022-11-14&checkout=2022-11-17&dest_id=1901959&dest_type=hotel&group_adults=1&group_children=0&hapos=12&highlighted_blocks=817447002_344252965_0_2_0&hpos=12&lang=en-us&matching_block_id=817447002_344252965_0_2_0&no_rooms=1&req_adults=1&req_children=0&room1=A&sb_price_type=total&soz=1&sr_order=popularity&sr_pri_blocks=817447002_344252965_0_2_0__42480&srepoch=1663841938&srpvid=723948887bee00ba&type=total&ucfs=1&lang_click=other&cdl=he&lang_changed=1) – a lovely hostel with various accommodation options. It is located next to the beach and features a young atmosphere and an amazing rooftop. We thank our sponsors for their support. To become a sponsor, email us at [\[email protected\]](/cdn-cgi/l/email-protection) #### Important Information **Dates:** November 15th – 17th **Registration:** [Now open!](https://www.eventbrite.com/e/5th-zkproof-workshop-tickets-414521363557) **Location:** Tel Aviv, Israel **Schedule:** [See here](#agenda) Note that virtual participants do not need to register #### Info for Registered Participants Welcome to the 5th ZKProof Workshop! * Talks will be recorded and streamed live on our Youtube Channel * Discussions will not be recorded, to enable an open dialogue and ensure the privacy of participants, based on [Chatham House rules](https://www.chathamhouse.org/about-us/chatham-house-rule#:~:text=The%20Rule%20reads%20as%20follows,other%20participant%2C%20may%20be%20revealed.) * The [community forum](http://community.zkproof.org) and our Telegram group for online communication and chats * Collaborative tools for simultaneous work: (1) [hackmd](https://zkproof.org/workshop3-signatures) for writing and note-taking; (2) [Miro](http://miro.com) for visuals and diagrams Invited Speakers -------------------- [![Orly Grinfeld](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/Orly-Grinfeld_picture.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/orly-grinfeld/) ### [Orly Grinfeld](https://zkproof.org/team/orly-grinfeld/ "Orly Grinfeld") [CEO, TASECH](https://zkproof.org/team/orly-grinfeld/ "Orly Grinfeld") [![Kobi Gurkan](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/WhatsApp-Image-2022-10-10-at-2.22.37-PM.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/kobi-gurkan/) ### [Kobi Gurkan](https://zkproof.org/team/kobi-gurkan/ "Kobi Gurkan") [Head of Research, Geometry](https://zkproof.org/team/kobi-gurkan/ "Kobi Gurkan") [![Omer Shlomovits](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/photo_2022-10-13-16.31.16.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/omer-shlomovits/) ### [Omer Shlomovits](https://zkproof.org/team/omer-shlomovits/ "Omer Shlomovits") [CEO, Ingonyama](https://zkproof.org/team/omer-shlomovits/ "Omer Shlomovits") [![Mary Maller](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/02/marymaller-e1614114950795.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/mary-maller/) ### [Mary Maller](https://zkproof.org/team/mary-maller/ "Mary Maller") [Cryptography Researcher, Ethereum Foundation](https://zkproof.org/team/mary-maller/ "Mary Maller") [](http://marymaller.com/ "globe") [![Justin Thaler](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/02/headshot1.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/justin-thaler/) ### [Justin Thaler](https://zkproof.org/team/justin-thaler/ "Justin Thaler") [Research Partner, a16z. Associate Professor, Georgetown University](https://zkproof.org/team/justin-thaler/ "Justin Thaler") [](http://people.cs.georgetown.edu/jthaler/ "globe") [![Jonathan Rouach](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/jonathan-rouach/) ### [Jonathan Rouach](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [Executive Director for ZKProof, CEO and Founder, QEDIT](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [![Yuval Ishai](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/yuval-ishai.jpg?resize=150%2C150&ssl=1)](http://www.cs.technion.ac.il/~yuvali/) ### [Yuval Ishai](http://www.cs.technion.ac.il/~yuvali/ "Yuval Ishai") [Technion University](http://www.cs.technion.ac.il/~yuvali/ "Yuval Ishai") ### Agenda ### **Day 1 - 15th November**[Live Stream](https://youtube.com/playlist?list=PLOEty2U8Y69ULDD8YxqQ8kWg8Qn7N8XHZ) [![](https://zkproof.org/wp-content/uploads/2022/11/Screen-Shot-2022-11-14-at-12.40.12-uai-258x167.png)](https://qed-it.notion.site/5th-ZKProof-Workshop-Agenda-b361bff229fe4d9d96eb542f6c293377) ### **Day 2 - 16th November**[Live Stream](https://youtube.com/playlist?list=PLOEty2U8Y69ULDD8YxqQ8kWg8Qn7N8XHZ) [![](https://zkproof.org/wp-content/uploads/2022/11/Screen-Shot-2022-11-16-at-12.40.19-uai-258x196.png)](https://qed-it.notion.site/5th-ZKProof-Workshop-Agenda-b361bff229fe4d9d96eb542f6c293377) ### **Day 3 - 17th November**Live Stream [![](https://zkproof.org/wp-content/uploads/2022/11/Screen-Shot-2022-11-14-at-12.41.18-uai-258x158.png)](https://qed-it.notion.site/5th-ZKProof-Workshop-Agenda-b361bff229fe4d9d96eb542f6c293377) ### Accepted Submissions **Tutorial Workshops** * Tutorial: Attacks on Zero-Knowledge Proof Systems – Anna Kaplan (Least Authority) * Tutorial: Designing ZK Application Protocols, Hands-On – TBD (QEDIT) **Applications of ZK** * UnTraceable Transactions (UTT) with Accountable Privacy and Technological Experimentation with the Bank of Israel – Ittai Abrahamm (VMware) * FROMAGER – A Scalable Toolchain for Complex ZK Proofs About Software – James Parker (Galois, Inc) * Zero-Knowledge Machine Learning – Jason Morton (ZKonduit / 0xPARC) * ZK-WASM: A ZK Virtual Machine that Supports WebAssembly – Gao Sinka (DelphinusLab) **ZK Primitives** * Succinct Zero-Knowledge Batch Proofs for Set Accumulators – Hyunok Oh (Hanyang university and Zkrypto Inc.) * Curve Trees: Practical and Transparent Zero-Knowledge Accumulators – Simon Holmgaard Kamp (Aarhus University) **Developer Tooling** * Building Functional Commitments: the Benefits of Implementing and Optimizing at the Polynomial Level – Andrija Novakovic (Geometry) * Anemoi and Jive: New Arithmetization-Oriented tools for Plonk-based applications – Clémence Bouvier (Sorbonne University and Inria, France) **Domain Specific Language** * ZK-SecreC: a Domain-Specific Language for Zero-Knowledge Proofs – Raul-Martin Rebane (Cybernetica AS) * A Zero-Knowledge Circuit for the Lurk language – Eduardo Morais (Protocol Labs) * cirgen: MLIR based compiler for zk-STARK circuit generation – Frank Laub (RISC Zero, Inc) **Concrete Schemes** * aPlonK: Aggregated PlonK from Multi-Polynomial Commitment Schemes – Marc Beunardeau and Miguel Ambrona (Nomadic Labs) * Groth16 still Lives: Exploring the Tradeoffs of Modern ZKProof Systems – François Garillot (Mysten Labs) * Simulation-extractability of zkSNARKs – Michał Zajac (Nethermind) * Counting Vampires: From Univariate Sumcheck to Updatable ZK-SNARK – Janno Siim (Simula UiB), Michal Zajac (Nethermind) **Standardization Discussions** * PLONK: IOP, Polynomial Commitment and Arithemtization Language – Jack Grigg (Electric Coin Company) * Composition of Proof Systems – Ying Tong (Electric Coin Company, 0xPARC) * A Draft Standard Specification for Σ-Protocols – Michele Orrù (UC Berkeley), Stephan Krenn (AIT) **Submissions are no longer being accepted.** [Call for Contributed Talks](https://zkproof.org/events/zkproof-7-sofia/call-for-papers-7th-zkproof-workshop/ "Call for Contributed Talks: 5th ZKProof Workshop") #### The event will be held in Tel Aviv, Israel ![](https://zkproof.org/wp-content/uploads/2022/10/Tel_Aviv_Stock_Exchange_logo_2021.png) ![](https://zkproof.org/wp-content/uploads/2022/10/Screen_Shot_2022-10-26_at_0.01.42-removebg-preview-300x81.png) We thank our Location Partners Tel Aviv Stock Exchange: Ahuzat Bayit St 2, Tel Aviv-Yafo Bits of Gold and the Bitcoin Embassy: Ahuzat Bayit St 1, Tel Aviv-Yafo Our Sponsors ---------------- To learn more about becoming a sponsor, email us at [\[email protected\]](/cdn-cgi/l/email-protection) ### Platinum Sponsors [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/qedit-padding.png?fit=1920%2C722&ssl=1)](https://qed-it.com) ### Gold Sponsors ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/11/ethereum-foundation-logo-B01D3C8BAD-seeklogo.com_.png?fit=300%2C93&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/09/ingonyama-full-logo-yellow.png?fit=8001%2C4501&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/risc0.png?fit=200%2C200&ssl=1)](https://www.risczero.com/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/zcashfoundation-1.png?fit=2102%2C1663&ssl=1) ### Silver Sponsors ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/03/Aleo_Logo.png?fit=1981%2C577&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/casper_smaller.png?fit=2560%2C1440&ssl=1)](https://casper.network/) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/Chainlink-Combo-Logo.png?fit=1907%2C728&ssl=1)](https://chain.link) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/Geometry-Logo-05.png?fit=3751%2C1085&ssl=1) [![](https://i0.wp.com/zkproof.org/wp-content/uploads/2022/10/mystenlabs2.png?fit=1766%2C225&ssl=1)](https://mystenlabs.com/) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/02/protocol-labs-logo-horizontal-alt-black.png?fit=354%2C170&ssl=1) ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/VMware-e1576545210774.jpg?fit=972%2C425&ssl=1) [](#) --- # Zebra: Zcash Zero-Knowledge Proofs at Scale - ZKProof Standards Zebra: Zcash Zero-Knowledge Proofs at Scale =========================================== June 3, 2021 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Teor](https://zkproof.org/author/teor/) Zcash - A Privacy Cryptocurrency -------------------------------- Zcash is a privacy-respecting cryptocurrency that provides shielded transactions. It uses zero-knowledge proofs to give users the option of protecting their financial privacy. Zcash can validate shielded transactions in zero-knowledge, while keeping the details encrypted between sender and receiver, with optional revealing of data as needed. Zcash uses these proofs to verify that values match, that spent money has been produced in the past, that the prover was authorized, and that this money hasn’t been spent before, all in zero-knowledge. The Zcash Foundation -------------------- The Zcash Foundation supports development of the Zcash protocol and privacy-preserving technologies. We work with cryptographers and developers from all around the world. A major part of our work is Zebra, a parallel Zcash validating cryptocurrency node with proof batching. The Foundation also hosts an annual conference, [**Zcon**](https://www.zfnd.org/zcon/2/) , which is coming up on the **8-9 June 2021** and is free (gratis) for all. Zero-Knowledge Proofs in Zcash ------------------------------ The Zcash protocol has used a number of different zk-SNARK proof systems since its initial deployment in 2016, including BCTV14 for the first shielded pool, Sprout (which is now in the process of being deprecated). The current version, dubbed Sapling, uses parallel batched pairing-based Groth16 proofs. We are currently integrating the new Halo2 proof system for the upcoming Orchard shielded transactions. Halo2 introduces a recursive-capable zk-SNARK with an UltraPLONK arithmetization. Our first integration of Halo2 will be parallel, un-batched verification, with batched proof verification coming after NU5 activation. Zero-Knowledge Proof Batch Verification in Zebra ------------------------------------------------ Zebra implements global batch verification of proofs and signatures across Zcash transactions. Zebra’s verification pipeline is fed by concurrent block verification tasks. It verifies proofs and signatures in parallel, including Groth16 proofs, Ed25519 signatures, and RedJubjub signatures. This maximizes the utilization of any available processor cores. Zebra uses [Rust futures](https://www.zfnd.org/blog/futures-batch-verification/) via [Tower services](https://github.com/tower-rs/tower) to implement composable batch verification. Zebra concurrently downloads and verifies transactions, which can each contain multiple proofs and signatures. Each different kind of proof / signature is sent to its global batch verifier, an instance of a Tower service for that type of batch verification , which has a configurable batch size limit and timeout. When the limit or timeout is reached, the entire batch is verified. If batch verification succeeds, each proof in the batch returns a successful result. If the batch fails, each proof is re-verified individually, in parallel, to correctly throw an error and log which item failed to verify. Using Tower services allows us to take advantage of batch verification, but return an accurate verification status for each individual item. When queuing up an item to be verified in a batch, the caller of the service gets a future for that item. This future resolves when the entire batch is verified successfully. If the batch fails, the future resolves to the fallback individual verification result. That way, we can keep track of particular signatures or proofs in the context of the verification service call, while getting the amortization benefits of batching. Rust futures use cooperative multitasking. Each future is translated into a state machine by the compiler. This minimises the memory and CPU cost of pending futures, and allows for rapid scheduling of ready futures on the current thread. Rust’s memory safety provides assurance that the data for each proof remains intact, even if the batch verifies transactions submitted by malicious users. As part of Zebra’s parallel verification pipeline, we [split verification into 3 stages](https://github.com/ZcashFoundation/zebra/blob/main/book/src/dev/rfcs/0002-parallel-verification.md#definitions) , based on the amount of context required. Structural verification (parsing) is based on data that has recently been read. Semantic verification is based on data from the current block. And contextual verification uses data from the entire historical blockchain. This design allows us to defer data dependencies until later in the pipeline. Zebra can semantically verify the proofs and signatures from many blocks in parallel, increasing the efficiency of our batch verifiers. Zebra’s parallel batch verification provides a significant speedup over serial verification, approximately 3x for a full Zcash chain sync. Distributed Signing with FROST ------------------------------ The Foundation has recently [finished an audit](https://www.zfnd.org/blog/frost-audit/) of an implementation of the Flexible Round-Optimized Schnorr Threshold (FROST) protocol. [FROST](https://eprint.iacr.org/2020/852) is a multi-party threshold signature protocol, which aims to be performant, secure, and compatible with transactions signed by only a single party. The initial commitment round can be batched, so each new threshold signature only requires a single interactive request and response. We currently support key generation by a trusted dealer, with support coming for distributed key generation. FROST has been implemented for multiple signature schemes. Our audited implementation generates [RedJubjub](https://github.com/ZcashFoundation/redjubjub/blob/main/src/frost.rs) signatures for the Zcash sapling shielded pool. A previous implementation was based on the [Ristretto](https://git.uwaterloo.ca/ckomlo/frost) prime order group. We feel confident that FROST will work well with re-randomized signing keys as supported in Zcash, as well. Based on feedback from the auditors, we are currently working on a serialization format for FROST RedJubjub messages. This binary format will help make FROST RedJubjub interoperable across different languages and implementations. It will also provide a basis for FROST messages using other signature schemes. Other Privacy Work ------------------ Network-level privacy is also an important part of fully private Zcash transactions. We recently performed a [technical assessment of different network privacy protocols](https://www.zfnd.org/blog/zf-network-privacy-assessment/) . We analyzed their resistance to various attacks, including on-path correlation and block access pattern detection. These attacks are relevant for Zcash light clients, which don’t download the full blockchain. Both Tor and a generic mixnet provide good protection, but Tor currently has a significantly larger anonymity set. We are also looking forward to [scaling the Zcash network](https://www.zfnd.org/blog/can-zcash-scale-to-a-million-users/) . We want to continue to improve the performance of the Zcash network and consensus protocols, to keep up with improvements in proof verification times. We also want to improve the user experience of node and wallet software, so that adoption and deployment become easier. A larger network will expand the anonymity set for all users. Future Zero-Knowledge Proof Work -------------------------------- The Zebra team is looking forward to implementing Halo2 batching, and deploying recursive proofs. These optimizations will keep verification time down, and decrease proof size, allowing wide deployment of privacy protocols with tighter space and resource constraints. Zcon 2 Lite Conference ---------------------- From 8-9 June 2021, the Zcash Foundation is hosting [**Zcon2 Lite**](https://www.zfnd.org/zcon/2/) , an online conference on Zcash and Zero-Knowledge Proofs. Zcon 2 Lite sessions are scheduled from: * Tuesday 8 June, 14:00 – 23:00 UTC * Wednesday 9 June, 14:00 – 21:10 UTC The following sessions will be of particular interest to Zero-Knowledge Proof practitioners: * [**Halo2 & Orchard – Tuesday 8 June, 1940 UTC**](https://www.zfnd.org/zcon/2/schedule#halo2) * _Sean Bowe, Daira Hopwood & Deirdre Connolly_ * [**Recent Advances in Zero-Knowledge – Wednesday 9 June, 1400 UTC**](https://www.zfnd.org/zcon/2/schedule#zkresearch) * _Mary Maller_ * [**Evaluating New Zero Knowledge Proof Research Before Implementation – Wednesday 9 June, 1455 UTC**](https://www.zfnd.org/zcon/2/schedule#evaluating) * _Panel discussion with Eran Tromer, Pratyush Mishra and Mary Maller, chaired by Daniel Benarroch_ * [**Snarks on Other (non-Zcash) Ecosystems – Wednesday 9 June, 1550 UTC**](https://www.zfnd.org/zcon/2/schedule#other-snarks) * _Panel discussion with Marco Stronati, Ariel Gabizon, Barry Whitehat, and Kobi Gurkan, chaired by Anna Rose_ [Credentials](https://zkproof.org/tag/credentials/) [Education](https://zkproof.org/tag/education/) [Tech](https://zkproof.org/tag/tech/) [Zero-knowledge proofs](https://zkproof.org/tag/zero-knowledge-proofs/) * * * ![](https://secure.gravatar.com/avatar/b0a4d5878b49d2ddc7d783b4fa35105e?s=240&d=identicon&r=g) ##### [Teor](https://zkproof.org/author/teor/ "Teor post page") [All author posts](https://zkproof.org/author/teor/ "Teor post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # HashWires: Range Proofs from Hash Functions - ZKProof Standards HashWires: Range Proofs from Hash Functions =========================================== May 5, 2021 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Kostas Chalkias](https://zkproof.org/author/kostascrypto/) _– by Kostas Chalkias, Shir Cohen, Kevin Lewi, Fredric Moezinia, and Yolan Romailler._ Introduction ------------ This post presents one of the easiest-to-implement protocols for proving that a secret integer lies within an interval, without revealing anything else about the number itself. Those familiar with applications of zero-knowledge proofs (ZKP) have probably encountered the concept of _range proofs_ in protocols such as Bulletproofs, MimbleWimble and generic zkSNARK constructions. But if you ask non-experts to enlist the most important applications of such a mechanism, two common applications mentioned include proof-of-age and proof-of-income to relevant third-parties, such as landlords. Apart from the inconvenience of exposing personal data in these scenarios, some may have privacy and security concerns about how this information is stored once collected. By looking closer into the requirements, we realized that there exist two substantial differences between applying range proofs for confidential amounts in blockchains and showing your age or income data in real world activities and purchases. Briefly, in the second scenario a) we have a trusted authority that issues credentials and b) typically we don’t perform operations between encrypted values, thus commitment homomorphism is not required. The latter is because we’re interested in proving that some issued credential satisfies a threshold and nothing else. These observations motivated research in the field of credential-based range proofs (CBRP), which differ from regular zero-knowledge range proof solutions in two ways: * the soundness requirement is relaxed to a weaker notion which we refer to as commitment-conditional soundness (because we already trust issuers, i.e., the identity and passport authorities) * the zero-knowledge property is relaxed to witness indistinguishability (we just need to hide the exact amount of the issued value) By taking advantage of these relaxed properties, we describe a new lightweight scheme called HashWires, whose security is based solely upon the security of cryptographically secure hash functions. As we will show, the fact that no advanced math is required (no factorization, no elliptic curves, no pairings, no polynomials) makes this solution surprisingly easy to implement, even in restricted environments, while it compares favorably against Bulletproofs for both 32 and 64 bit numeric values. To begin with expectations, a HashWires one-time range proof can be just 177 bytes for 32-bit ranges (Vs. 608 bytes in Bulletproofs), while for 64-bit numbers a HashWires proof is 369 bytes (Vs. 692 bytes in Bulletproofs). Performance-wise, carefully selected settings for HashWires allow for 60 times faster proof generation, while verification can be up to 30 times more efficient than a Bulletproofs equivalent range proof. Range Proofs from Hashchains ---------------------------- HashWires is inspired by the PayWord protocol, a hash-chain based micro-payments protocol proposed by Rivest and Shamir in 1996. The original idea is very simple and completely based on hash-chain computations. Briefly, the naive PayWord approach works as follows for our age example: It’s the year 2021 and Alice wants to prove to Carol that she is at least 21 years old without showing her ID or driver license. As every cryptographer might know, Alice was born in 1978 when the RSA paper authors mentioned for the first time “For our scenarios we suppose that A and B (also known as Alice and Bob) are two users of a public-key cryptosystem”. But let’s assume for a while that Carol is not a cryptographer and really needs a proof of over-21 for Alice; also they both trust the government for issued credentials. Additionally, let’s suppose that we want to use this proof system until 2100. So Alice’s local government (issuer) will provide a signed cryptographic commitment using two collision resistant hash functions $H\_0, H\_1$ (a single salted hash or HMAC function with different salt/key per $H\_0$ and $H\_1$ would also work) as follows: * pick a random $seed$, typically at least 128 bits long * compute $s = H\_{0}(seed)$ and assign this to year 1978 (Alice’s birth year) * compute $k = 2100 – 1978 = 122$ as the distance from 1978 to the maximum year supported (2100) * compute the commitment $c = H\_{1}^{k}(s)$, which represents $k$ repeated iterations of the function $H\_{1}$ * return to Alice $s$ and the signature $sig\_c$ over $c$ and Alice’s $photo$. Thus, Alice is provided with a signed hash-chain commitment and a secret $s$. As we’re in the year 2021, to prove that she was born (at least) 21 years ago, thus at or before 2000, the following protocol is executed: * Alice computes $d\_0 = 2000 – 1978 = 22$ * Alice outputs the proof $p = H\_{1}^{d\_0}(s)$ * Alice shows $(p, sig\_c, photo)$ to Carol * Carol computes $d\_1 = 2100 – 2000 = 100$ * Carol computes the commitment $c = p^{d\_1}$, which will hold because $d\_0 + d\_1 = 122 = k$ * Carol verifies $sig\_c$ against the issuer’s known public key (and crosschecks Alice’s photo). The above works because Carol gets convinced that Alice has some issued secret which is at least 100 hash-chain nodes long, which in turn implies that Alice was born at or before the year 2000 (otherwise the issuer would have never provided Alice with such a long chain). Also, the proof $p$ is literally a single hash value, just 32 bytes as shown below. ![](https://zkproof.org/wp-content/uploads/2021/05/over21_proof-uai-258x206.png) Over-21 single-chain range proof. Despite its simplicity, the above solution suffers from a significant drawback: the cost of commitment, proof generation and eventually proof verification is linear to $k$ in the worst case. Note that if the granularity of time in the above over-21 example was minutes and not years, we would expect a $k$ at the range of millions, which would inherently require millions of hash invocations. Thus, using PayWord for range proofs is really only suitable for small domains, and its performance for large ranges, i.e., 32 or 64 bit numbers, is not practical. Generalizing Hashchains ----------------------- Before we describe the full solution, let’s consider the case where the issued value is the number 03999 in a system that accepts integers up to 99999. Can we split the single chain somehow, per decimal digit maybe? Indeed, it would work as follows: The issuer will create 5 chains, one per digit in base10. For the three less significant digits the chain will have a full length of 10 nodes; for the second most important digit the length is 4; and for the most significant digit the length is 1. Then the issuer will put the top node of each hashchain in an accumulator (i.e., a simple concatenation-then-hash will do the trick of committing to all 5 chains). The values $s\_1,..,s\_5$ are provided to Alice (prover) who can now also produce the commitment. Obviously, all of $s$ values could be computed via some key derivation function, so that only one seed value would be provided to Alice (that’s her secret). ![](https://zkproof.org/wp-content/uploads/2021/05/3999-uai-258x284.png) Hash multichains prove greater-than-or-equal-to 1492 when the issued value is 3999. Now, for Alice to prove that she holds a commitment $\\geq 1492$, she will provide the yellow (bright) colored nodes as shown in the above figure. Briefly, she starts counting from the top node of each chain and, depending on the digit that she needs to prove, she returns the corresponding node. Thus for 0 1 4 9 2, she will output: * $s\_5$ to represent the first digit (0) – there is no other node for the most significant digit anyway * ${H\_1}^2(s\_4)$ to represent the second most significant digit (1) * ${H\_1}^5(s\_3)$ for third digit (4) – note that starting from the top, ${H\_1}^9(s\_3)$ corresponds to number zero, ${H\_1}^8(s\_3)$ to number one and so on until we reach number four * $s\_2$ for the fourth digit (9) * ${H\_1}^7(s\_1)$ for the last digit (2). Now, after Carol receives the above five values, she will apply as many $H\_1$ iterated invocations as the value 0 1 4 9 2 shows. Thus zero times for the first digit, one time for the second digit, four times for the third digit etc. Eventually Carol can compute all the top nodes for each chain and thus be convinced that Alice was issued an integer with a value of at least 01492. But is this the full story? It seems too easy, right? Let’s try another issued value, 03997 (we just changed the last digit), and now try to prove greater-than-or-equal-to 1599. Hm, but we don’t have a chain of length ten for the last digit. We can prove up to 1597, but not for 1598 and 1599 and in general we cannot prove any number whose last digit is 8 or 9. Unfortunately a single hash multichain cannot work. ![](https://zkproof.org/wp-content/uploads/2021/05/3997-uai-258x285.png) A naive hash multichain cannot prove >= 1599 when the issued value is 3997. Minimum Dominating Partitions ----------------------------- What if we had many hash multichains but somehow ensure that any integer up to 3997 is _proof-encodable_ and at the same time Alice is not able to cheat by proving numbers greater than 3997? Indeed, imagine that the issuer created a separate multi hash-chain commitment for each of the numbers in the following set: $\[3997, 3989, 3899, 2999\]$. Then, based on the requested number to prove, Alice would pick one of these commitments: the one that has a long enough hash multichain to encode the number in question. If you understood the logic of hash multichain splitting, then you can easily realize that the commitment to: * 2999 can prove any number up to 2999 * 3899 can prove any number from 3000 to 3899 * 3989 can prove any number from 3900 to 3989 * 3997 can prove any number from 3990 to 3997 In practice, some commitments can encode other values too, e.g., the commitment to 3989 could be used to prove the number 2350 as well, because its hashchains are long enough for the requirements of 2350. But we can just ignore this property, and always pick the closest greater-than-or-equal commitment to the requested integer, i.e., if we want to prove $\\geq 1700$, we would pick the commitment to 2999, but if the requested integer was the number 3950, we would select the commitment to 3989. It is also obvious that at the same time Alice cannot cheat; she does not own any commitment for a number greater than 3997. The above numbers in the set are not randomly chosen, they are produced via an algorithm that we call “minimum dominating partition” (MDP), which produces the smallest set-size that satisfies the above properties of being able to prove any range up to the issued value. The algorithm is very efficient and can work for any base (not only base10); here is an example Rust implementation that supports up to 32-bit integers. ![](https://zkproof.org/wp-content/uploads/2021/05/mdp-uai-258x164.png) Rust function: compute MDP. Some output examples for base10 include \[17352, 17349, 17299, 16999, 9999\] for 17352, \[1399, 999\] for 1399 and \[8733432, 8733429, 8733399, 8732999, 8729999, 8699999, 7999999\] for 8733432. Similarly, \[312, 303, 233\] is the MDP-list for the number 312 in base4 as shown below: ![](https://zkproof.org/wp-content/uploads/2021/05/multi_chain-uai-258x83.png) The MDP commitments for the number 312 in base 4. Colored nodes denote the proof elements needed for proving >= 123. Reusing Chains -------------- An interesting optimization trick is to share the chains between MDP commitments. Actually this is straightforward via wiring as shown below in the 312 base4 example. Briefly, we create 3 full chains, one per digit. Then, each MDP commitment is wired to its corresponding indices as shown below: ![](https://zkproof.org/wp-content/uploads/2021/05/reuse_chains-uai-258x163.png) MDP commitment hashchain sharing via wiring. This wiring technique was the inspiration for naming this protocol “HashWires”, which allows for significant optimizations on proof generation, especially for large domains that would typically require dozens of MDP commitments. Hiding the MDP Population ------------------------- It’s important to highlight that the size of the MDP-list can go up to the maximum number of digits supported in each application. For instance, if the maximum acceptable number consists of 20 decimal digits, the size of MDP-list can reach up to 20 elements in base10. Similarly, for numbers up to to $2^{64}-1$ using base16 we would expect a maximum of 16 MDP values in the worst case. However, the size of the MDP-list and potentially the index of the selected MDP commitment might leak information about the issued number. Why? Imagine that the number 02999 was issued (out of the maximum possible 99999). This number however requires only one element in the MDP-list, the \[2999\], as it can be used to prove any number $\\leq 2999$. If Alice however revealed this information (that there exists only one MDP commitment), a verifier learns that the issued number cannot be 2998 or any other integer that would require more than one MDP values. Thus, we always need to pad the MDP-list (+ shuffle it), so verifiers have no information about the MDP-list size when they see a HashWires proof. Although an RSA accumulator could work, that would not be post-quantum secure and the idea is to avoid factorization or elliptic curves anyway. Similarly, a plain Merkle tree where we add random leaves would be an option, but the padded sparse Merkle tree accumulator is recommended to reduce the number of padding nodes required and still rely on hash functions only. A Rust implementation of the padded sparse tree is available in the [_smtree_](https://crates.io/crates/smtree) crate (library). ![](https://zkproof.org/wp-content/uploads/2021/05/sparsetree-uai-258x176.png) Padded sparse Merkle tree of height=4 with 3 leaves (at random indices) and 6 padding nodes. The Final HashWires Protocol ---------------------------- There are more optimization tricks and extensions that we could apply on top of the described protocol, for example related to how we can truncate the prefix zero digits of small issued values and add malleability protection. One can learn more from the “HashWires: Hyperefficient Credential-Based Range Proofs” paper available on ePrint. An interesting analogy is to see HashWires as an extended variant of Winternitz one-time post-quantum signatures (WOTS). As in WOTS, the basic HashWires protocol is an one-time range proof system and can be extended to stateful many-times using a Merkle tree of one time proofs. Making HashWires many-time stateless is still an open research problem. Moreover, the bigger the selected base, the longer the hashchains, but the shorter the proof. Typically, base16 or base256 are considered practical for today’s requirements of usually proving ranges to values up to 64 bits that work for most real world applications. Applications of HashWires include range proofs for KYC credentials, location (you can easily combine two proofs, one per coordinate, to create a range in the 2D or 3D space), timestamp ranges (i.e., in digital certificates we’re only interested in cert validation, but not necessarily when it was issued) and finally micro-payments, auctions and gradually redeemable bank checks. ![](https://zkproof.org/wp-content/uploads/2021/05/full_hw-uai-258x305.png) Full one-time HashWires commitment for number 312 (base4). As for the concrete results, we provide some comparison tables taken by comparing Hashwires for different bases against Bulletproofs and Groth16. ![](https://zkproof.org/wp-content/uploads/2021/05/Screen-Shot-2021-05-06-at-0.57.47-uai-258x89.png) ![](https://zkproof.org/wp-content/uploads/2021/05/Screen-Shot-2021-05-06-at-0.58.03-uai-258x111.png) [Credentials](https://zkproof.org/tag/credentials/) [Education](https://zkproof.org/tag/education/) [Tech](https://zkproof.org/tag/tech/) [Zero-knowledge proofs](https://zkproof.org/tag/zero-knowledge-proofs/) * * * ![](https://secure.gravatar.com/avatar/651414b06e6324585def2c030b35590a?s=240&d=identicon&r=g) ##### [Kostas Chalkias](https://zkproof.org/author/kostascrypto/ "Kostas Chalkias post page") [All author posts](https://zkproof.org/author/kostascrypto/ "Kostas Chalkias post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2021/05/05/hashwires-range-proofs-from-hash-functions/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Page not found - ZKProof Standards 404 === ##### Page Not Found * * * [Return Home](https://zkprooforg.wpcomstaging.com/ "Homepage") [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Playing with Randomness and Interactions to Prove Theorems - ZKProof Standards Playing with Randomness and Interactions to Prove Theorems ========================================================== October 15, 2020 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Antoine Rondelet](https://zkproof.org/author/antoinerondelet/) In this blog post, I will go back to some of the early results that pioneered the notion of “zero-knowledge proof” as we know it today. To that end, I will provide an introduction to the notion of Interactive Proofs (IP) as well as intuition as to what makes interactive protocols so powerful. The goal is to identify the pillars that make interactive zero-knowledge proofs possible, and then study how one can “play with” and substitute these essential ingredients in order to obtain Non-Interactive Zero-Knowledge (NIZK). Such non-interactive protocols have gained tremendous traction over the past few years, and are now used in cloud-computing settings, as well as on blockchain systems to only name a few of their numerous applications. While the past decades have seen a surge of new constructions (all offering different trade-offs) I propose – through this article – to take a step back and look at what makes all these beautiful protocols work and so appealing. ### Important Note This post will explore some (of the many) remarkable results in theoretical computer science and in the field of probabilistic proof systems in particular. While many essential results won’t unfortunately be mentioned, and most details omitted, I will rather focus on providing intuition for concepts and invite the interested reader to explore and study the various resources linked throughout this article for precise definitions and proofs. ### Prerequisites Basic knowledge of complexity theory (P, NP classes) (see e.g. [this book](https://theory.cs.princeton.edu/complexity/) or [this book](http://www.wisdom.weizmann.ac.il/~oded/cc-book.html)  for great resources on the matter), as well as basic concepts of abstract algebra (groups, rings, fields). First things first: What is a proof? ------------------------------------ Informally a _proof system_ $\\mathcal{S}$ is the composition of an axiomatic system (a finite set of statements taken to be true – called _axioms_) along with a set of _inference rules_. These rules determine the set of transformations that can be carried out on the information within the system, with axioms as a staring point (see [here](https://www3.cs.stonybrook.edu/~cse541/chapter7.pdf)  for more details). On input a set of _premises_, an inference rule outputs a _consequence_ that is then added to the set of information (“expressions”) in the system. We call a proof $\\pi$ for a theorem $\\mathcal{T}$ in the proof system $\\mathcal{S}$, a sequence of expressions such that: * the first expression is an axiom, * the last expression is the theorem $\\mathcal{T}$, and * all intermediate expressions are either axioms or expressions obtained by sequential application of inferences rules from an axiom. Intuitively, a proof system may be modeled as a set of initial states (the axioms), and a set of state transitions (the inference rules), in which all provable theorems are the final states of the set of all finite-state automaton obtained by sequentially applying state transitions from the initial states. The proof of a theorem can be represented as the sequence of state transitions from the initial state (axiom) to the final state (theorem). While all the above may sound trivial to most readers, several observations are worth highlighting: * **Proofs are hard to find.** On a given set of axioms and inference rules, finding a suitable sequence of expressions leading to the theorem is a non-trivial task. For most of us (at least for me!) rigorously proving mathematical theorems requires a lot of work. * **Proofs are interesting.** A _proof contains a lot of information about the theorem itself_. In fact, the proof not only shows that the theorem is true, but it also shows _why_, which is a very valuable thing to know. * **Proofs are “static”.** When a theorem is proven, it is proven. The proof can be written on paper, peer-reviewed and shared. Proofs (in the mathematical sense) are inherently “static”. * **Verifying a proof is “easy”.** To verify a proof it is necessary to check that _all expressions_ in the sequence are compliant with the inference rules of the proof system. Hence, verifying a proof is _at least as long as reading the proof_, which can be long if the proof is long, but remains orders of magnitude simpler than _finding the proof_ in the first place. A few notations --------------- In the following, we denote by $\\mathbf{R} \\subset \\{0,1\\}^\* \\times \\{0,1\\}^\*$ a polynomial-time decidable binary relation, and denote by $\\mathbf{L} = \\{x\\ |\\ \\exists w\\ \\text{s.t.}\\ \\mathbf{R}(x, w)\\}$ the language defined by the relation $\\mathbf{R}$. Further we will refer to $x$ as the “instance” (or “public input”) and to $w$ as the “witness” (or “private input”). (Looking back to the section above, the language $\\mathbf{L}$ can be seen as the set of provable theorems in a proof system, while $w$ is their associated proofs. We see that this definition is natural, since, informally, for $x$ to be in $\\mathbf{L}$ – i.e. for $x$ to be a provable/valid theorem – there need to exist a proof for it!) Finally, we use the symbol $\\leftarrow$ to represent assignment (e.g. $y \\leftarrow 2$ assigns the value $2$ to the variable $y$), while $y \\stackrel{\\$}{\\leftarrow} S$ denotes the action to assign to $y$ a value taken uniformly at random from the set $S$. With this minimal set of notations we are now ready to enter the realm of probabilistic proof systems. The power of randomness and interactions ---------------------------------------- In their [seminal work](https://epubs.siam.org/doi/abs/10.1137/0218012) Goldwasser, Micali and Rackoff (GMR) introduced the notion of _Interactive Proof Systems_, in which a prover $\\mathsf{P}$ and a verifier $\\mathsf{V}$ – both modeled as Interactive probabilistic Turing Machines – communicate by means of their input and output tapes and exchange a sequence of messages. In the protocol, $\\mathsf{P}$ wants to prove to $\\mathsf{V}$ that $x \\in \\mathbf{L}$ (i.e. that a theorem is true). $\\mathsf{V}$, on the other hand, wants to make sure that $x$ is a valid instance and so, wants to check that $\\exists w\\ \\text{s.t.}\\ \\mathbf{R}(x,w)$ (i.e. there exists a correct proof for the theorem). To that end, the verifier is allowed to flip coins (i.e. has access to a source of truly random bits), and uses these coin flips to ask questions (i.e. “send challenges”) to the prover. The prover answers the verifier’s questions, and after several interactions, the verifier decides to either accept or reject the prover’s statement. Importantly, proofs are not “static” anymore in this model, but are now “built on the fly” by the prover _via his interactions with the verifier_. Informally, the complexity class admitting interactive proofs (IP) is defined as the class of languages $\\mathbf{L}$ with the following properties: * **Completeness:** “Valid instances are accepted most of time” \\begin{equation} \\mathrm{Pr}\\left\[ \\mathsf{V}\\ \\text{accepts}\\ (\\pi, x)\\ |\\ x \\in \\mathbf{L},\\ \\pi \\leftarrow \\mathsf{Transcript}(\\mathsf{P}, \\mathsf{V}) \\right\] \\geq \\frac{2}{3} \\end{equation} * **Soundness:** “Invalid instances are rarely accepted” \\begin{equation} \\mathrm{Pr}\\left\[ \\mathsf{V}\\ \\text{accepts}\\ (\\pi, x)\\ |\\ x \\not\\in \\mathbf{L},\\ \\pi \\leftarrow \\mathsf{Transcript}(\\mathsf{P}, \\mathsf{V}) \\right\] \\leq \\frac{1}{3} \\end{equation} where $\\mathsf{Transcript}(\\mathsf{P}, \\mathsf{V})$ represents the sequences of messages exchanged between the prover and the verifier during the protocol (i.e. the set of verifier’s challenges and the associated answers by the prover). Interestingly, we clearly see that running this probabilistic protocol – for communicating a proof – $N$ times can be used to “amplify soundness”. In short, if after running the protocol $N$ times (sequentially or concurrently) the verifier accepts an invalid instance, this means that during _all_ executions of the protocol the verifier accepted $x$. The probability of this event is $\\mathrm{Pr}\\left\[ A\_1\\ \\land\\ \\ldots\\ \\land\\ A\_N \\right\]$ (where $A\_i$’s are independent and represent acceptance of $x$ by $\\mathsf{V}$ in protocol execution $i$). As per the definition of _soundness_ above, this is bounded by $\\frac{1}{3^N}$ which converges _exponentially_ fast to $0$ (e.g. if $N = 10$, the probability for $\\mathsf{V}$ to be duped already falls to $\\frac{1}{59049} \\approx 0.000017$!). Importantly, in the GMR protocol, no assumptions are made on the prover. As such, it is modeled as all powerful/computationally unbounded. The verifier, however, is considered “weak”/computationally bounded. ### Why does this all work? At this stage, it is legitimate to wonder: How by flipping fair coins and interacting with the prover can the verifier almost always accept valid statements and almost always reject false ones? The key aspect of this method is that the prover does not know in advance the challenges he will receive from the verifier. As such, it is very hard for him to cheat. More than that, it is actually impossible for the prover to derive any sensible cheating strategy, since the verifier’s challenges are derived from random bits (“the verifier’s coin flips”). As such, and strikingly, communication (i.e. interactions) and randomness seem _very powerful_. While interactions allow to convey information and exchange knowledge, randomness is a fundamental tool to build sound protocols at is defeats lying provers’ strategies. ### The verifier's hidden superpower: Arithmetization A key method used to design efficient and sound interactive protocols is called: [arithmetization](https://link.springer.com/article/10.1007/BF01200057) . In short, this method consists in encoding computation so that its correctness can easily be verified via few probabilistic algebraic checks. Informally, such encoding can be done by converting a boolean formula into a polynomial defined over a large prime field and checking the formula’s satisfiability by evaluating the polynomial. A key insight behind the power of this method to represent (and check) computation is that polynomials are great error-correcting codes (e.g. Reed-Solomon codes or Reed-Muller codes. See e.g. [here](https://ieeexplore.ieee.org/abstract/document/1054226) for more information). As such, any error in the initial boolean formula (representing the prover’s computation) “gets propagated all over the resulting polynomial”! What this means is that, when the verifier queries this resulting polynomial, the probability for him to spot a mistake/error in the prover’s computation is very high! All in all, moving the prover’s computation to the realm of a polynomials defined over large prime fields gives great power to the verifier. Even if modeled as a weak device, the verifier has a lot of chances to discover a “lie in the prover’s statement”. (An illustration of the usefulness of polynomials – especially low-degree extensions – can be found in Justin Thaler’s [blog post about the Sum-Check protocol](https://zkproof.org/2020/03/16/sum-checkprotocol/) in this series). ##### **Example.** Assume that the prover claims that he knows the first $10$ elements of the Fibonacci sequence. We know that these elements are: $\\{0,1,1,2,3,5,8,13,21,34\\}$. However, let’s assume that the prover did a mistake when computing the last element and instead has the sequence $\\{0,1,1,2,3,5,8,13,21,33\\}$. For the sake of this example we assume that we work in the prime field $\\mathbb{F}\_{101}$, and so, would like to manipulate polynomials in the ring $\\mathbb{F}\_{101}\[x\]$. To get a sense of “the power of polynomials”, we will treat both of these sets as evaluation points of two polynomials. These sets of evaluation points will serve as interpolation domain to recover two polynomials in the coefficient form. As such, interpolating both $$\\{(0,0), (1,1), (2,1), (3,2), (4,3), (5,5), (6,8), (7,13), (8,21), (9,34)\\}$$ $$\\{(0,0), (1,1), (2,1), (3,2), (4,3), (5,5), (6,8), (7,13), (8,21), (9,33)\\}$$ respectively gives $$f(x) = 44x^9 + 31x^8 + 43x^7 + 16x^6 + 38x^5 + 52x^4 + 12x^3 + 9x^2 + 59x$$ $$g(x) = 13x^9 + 36x^8 + 85x^7 + 40x^6 + 9x^5 + 4x^4 + 24x^3 + 79x^2 + 14x$$ and we know that these two univariate polynomials can coincide on at most $9$ points (see the [DeMillo-Lipton](https://www.sciencedirect.com/science/article/abs/pii/0020019078900674) –[Schwartz](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.391.1254&rep=rep1&type=pdf) –[Zippel](https://rjlipton.files.wordpress.com/2009/11/zippel.pdf) lemma for more information). Strikingly, a simple representation shift (i.e. interpolation) of seemingly “similar” polynomials reveals a lot of disparities (their coefficient representations are indeed completely different). This in turn, is confirmed when we look at the set of evaluations of these polynomials in the field (see picture), where we see that a simple “tiny error” (blue circle on the figure) made by the prover, ends up being propagated all over the evaluation domain, making it easy for the verifier to check whether the prover’s statement actually holds. ![](https://zkproof.org/wp-content/uploads/2020/10/edited-arithmetization-example-uai-258x193.png) ### Defining "knowledge'' In addition to the interactive method for proving theorems, Goldwasser, Micali and Rackoff also studied the amount of “knowledge” that needed to be communicated between the prover (willing to prove a theorem) and the verifier (willing to accept only valid theorems) in the protocol. In their work, the authors informally define “communications conveying knowledge” as _those that transmit the output of an unfeasible computation, a computation that the verifier cannot perform herself_. In fact, does the teacher learn something new when her student gives her a proof of the Pythagorean theorem? She certainly learns that her student is capable to come up with a proof for the theorem; but beyond that, the teacher does not learn anything new (she already was able to come up with a proof for the theorem herself). However, does the teacher learn something if her student sends her a proof of the [Riemann hypothesis](https://mathworld.wolfram.com/RiemannHypothesis.html) ? Certainly yes! Not only she will learn that the Riemann hypothesis is true, but she will also learn how to prove it! What’s more, if she is malicious, the teacher can try to claim the [prize](https://en.wikipedia.org/wiki/Millennium_Prize_Problems)  associated to proving this hypothesis. The, now famous, notion of _“zero-knowledge”_ proof introduced in the same seminal work allows to remedy to the (“malicious teacher”) problem aforementioned. In short, these proofs allow a prover to prove a theorem $\\mathcal{T}$ to a verifier without exposing any additional details on “why” the theorem is valid. Formally, _knowledge_ (resp. _zero-knowledge_) is captured by using the (theoretical) concept of an _extractor_ (resp. _simulator_). These theoretical concepts are embodied by very strong and idealized algorithms. Intuitively, the extractor represents the idea that if you “know” something, I can surely – with some extra powers – extract this knowledge from you. For instance, if I can read your mind, I can surely extract your “knowledge” (alternatively, and less poetically, it is feasible to extract knowledge from a prisoner by using non-conventional and forbidden methods like torture). Either way, if you didn’t “know” something, it would be impossible – not matter how – to extract this thing from you. The notion of _zero-knowledge_, however, captures the idea that if a verifier does not learn anything other than the fact that the theorem is true, then he surely cannot distinguish between a legitimate prover, and a _simulator_ which does not know a witness for the instance (i.e. does not know a proof for the theorem), but which is given the possibility to cheat (i.e. a “trapdoor”). If the verifier could distinguish, then he must have learned something beyond the fact that the theorem is valid. (If that helps, think about a [sort of Turing test](https://en.wikipedia.org/wiki/Turing_test)  where a verifier needs to distinguish between a prover having a valid proof and a simulator having a trapdoor that allows him to derive a perfect cheating strategy). ##### **Example: Schnorr protocol.** Let’s illustrate these seemingly mind-boggling notions by looking at a very simple yet extremely powerful example. In fact, let’s build the extractor and simulator for the [Schnorr protocol](https://d-nb.info/1156214580/34) . This protocol is an example of [sigma protocol](https://www.cs.au.dk/~ivan/Sigma.pdf) that can be used to prove knowledge of a [discrete logarithm](https://mathworld.wolfram.com/DiscreteLogarithm.html) . Let $\\mathbb{G}$ be a [cyclic group](https://mathworld.wolfram.com/CyclicGroup.html) of prime order $q$ with generator $\\mathtt{g}$. We denote by $\*$ the group operator, and use the “exponentiation” notation to denote its successive application, e.g. $\\mathtt{g}^k = \\mathtt{g} \* \\ldots \* \\mathtt{g}$ ($k$ times). Assuming that $h (= \\mathtt{g}^w) \\in \\mathbb{G}$ and $(\\mathbb{G}, q, \\mathtt{g})$ are publicly available, the Schnorr protocol allows to prove knowledge of $w$, and goes as follows: 1. The prover computes $a \\leftarrow \\mathtt{g}^r$, where $r \\stackrel{\\$}{\\leftarrow} \\mathbb{Z}\_q$; and sends $a$ to the verifier. 2. After reception of $a$, the verifier “flips a coin” and sends a challenge $c \\stackrel{\\$}{\\leftarrow} \\mathbb{Z}\_q$ to the prover. 3. Upon reception of the challenge, the prover answers with $z \\leftarrow c \\cdot w + r$. 4. Finally, the verifier accepts (that the prover knows the discrete logarithm of $h$ in base $\\mathtt{g}$) if $\\mathtt{g}^z$ equals $a \* h^c$, and rejects otherwise. The extractor for this protocol, has _the power to control space and time_. In fact, to build the extractor, we assume that this algorithm can “rewind” and re-run the prover on the same input while preserving the prover’s random tape. This means that, after rewinding the prover, the same random element $r$ will be selected from $\\mathbb{Z}\_q$, and so the prover’s first message will be the same. Now, however, the extractor sends a different challenge $c’$ to the prover who will continue its normal execution of the protocol. This powerful ability to rewind the prover allows to generate two accepting transcripts $(a, c, z)$ and $(a, c’, z’)$ from which it becomes possible to recover the prover’s witness $w$ by observing that $\\frac{z-z’}{c-c’} = \\frac{(c \\cdot w + r) – (c’ \\cdot w + r)}{c-c’} = \\frac{(c-c’)w}{c-c’} = w$. To build the simulator for this protocol, we equip this algorithm with _the power to see the verifier’s random tape/foresee the verifier’s challenge_. As such, with this extra power, it is possible for the simulator to come up with an effective cheating strategy. In fact, knowing the challenge $c$, the simulator’s first message is set to $\\mathtt{g}^z \* h^{(-c)}$, where $z$ is an arbitrary element of $\\mathbb{Z}\_q$, also sent in the simulator’s last message. As such, it is clear that the final check $\\mathtt{g}^z = \\mathtt{g}^z \* h^{(-c)} \* h^c$ is satisfied (it is a tautology) while the simulator did not know $w$. Importantly, we note that in order to be able to simulate in this protocol, it is necessary that the verifier is honest, and sends truly random challenges. In fact, since the simulator’s “power” consists in reading the random tape of $\\mathsf{V}$, this power is rendered useless if the verifier does not use his tape to create the challenge. This is why we say that the Schnorr protocol is Honest Verifier Zero-Knowledge (HVZK). We have illustrated in this example the notions of an _extractor_ – used in proofs of knowledge (in which the prover not only shows that $\\exists w\\ \\text{s.t.}\\ \\mathbf{R}(x,w)$ but that he _knows_ such $w$) – and the notion of a _simulator_ – used to prove the zero-knowledge property. Surely, these algorithms do not describe realistic scenarios. They do however, allow to formally argue about properties and prove security of protocols. ### The verifier's random tape In GMR’s formulation of an interactive protocol, the verifier’s coin flips were used by the verifier to _derive_ challenges, but were _kept secret to the prover_ (i.e. “private coin”). However, [in his concurrent work](https://pdfs.semanticscholar.org/15f8/41e403dc1706df05bd24447d1be51c9f8785.pdf) , Laszlo Babai (see also, [this paper, with S. Moran](http://crypto.cs.mcgill.ca/~crepeau/COMP647/2007/TOPIC01/AMgames-Babai-Moran.pdf) ) introduced the notion of _Arthur-Merlin_ games (AM) in which the verifier’s coin flips were public. In this model, while Merlin (the famous magician – i.e. “all powerful” prover) _cannot predict_ the coins that Arthur (verifier) will toss in the future, Arthur has _no way of hiding from Merlin the results of the coins he tossed in the past_. Interestingly, AM protocols can be framed as interactive protocols between a prover and verifier having access to a shared randomness beacon, and in which all the verifier’s messages are substituted by the output of the beacon. While AM seems to relax IP, and hence appears weaker, [Goldwasser and Sipser](http://crypto.cs.mcgill.ca/~crepeau/COMP647/2007/TOPIC01/goldwasser-Sipser.pdf) showed (somewhat surprisingly) that this intuition was wrong, in that, private coins are _no stronger_ than public coins. As such $IP = AM$. ### On the size of IP While the Schnorr protocol illustrated above is very simple and elegant, it is “just” an interactive protocol that can be used to prove knowledge of a discrete logarithm in zero-knowledge (assuming the verifier is honest). Two natural questions follow from this. First, what languages lie in IP? Second, what are the requirements to get zero-knowledge? (surely Schnorr assumes that the discrete logarithm problem is hard) Furthermore, we know that NP has a 1-round interactive proof. In fact, the prover can send the entire witness to the verifier who then decides to either accept or reject. Hence, why would we ever want “more” interactions? Well, first, we may be interested in proving something that is _not_ in NP (say something in co-NP). Second, this “one-round” communication protocol defining NP requires to send the _full witness_ which in many cases will represent a lot of data to be read (and checked) by the verifier. Likewise, as mentioned above, sending all the witness to the verifier does not allow to obtain “zero-knowledge”. Hence, it is legitimate to search for the relation between IP and ZK (the languages admitting zero-knowledge proofs), as well as their relationship with other complexity classes. We know that the set of languages covered by interactive protocols with a deterministic verifier (dIP) is NP. As such, _interactions alone are not enough to “go beyond” NP_ (i.e. get one level up in the [complexity class hierarchy](https://en.wikipedia.org/wiki/Complexity_class) ). As such, it is interesting to understand if coupling interactions with randomness can allow to break the “NP bound”, and under which circumstances these two “ingredients” can provide zero-knowledge. Some of these questions started to be answered in Goldreich, Micali and Wigderson’s [foundational work](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Zero%20Knowledge/Proofs_That_Yield_Nothing_But_Their_Validity_or_All_Languages_in_NP_Have_Zero-Knowledge_Proof_Systems.pdf) , in which they showed that IP contained languages believed not to be in NP, and that _under existence of secure encryption functions_, all languages in NP admitted a zero-knowledge interactive proof system (i.e. under this assumption NP $\\subseteq$ ZK). Their result was established by designing an interactive proof system for the graph $3$-coloring problem which is a representative of the NP class (i.e. is NP-complete). (An excellent overview of this protocol is provided by Youval Ishai [in another post of this series](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) .) Later, Adi Shamir (and later, Shen, see [here](https://users.cs.fiu.edu/~giri/teach/5420/f01/IP_Pspace2.pdf) ) [proved that IP was equal to PSPACE](https://www.math.ucsd.edu/~sbuss/CourseWeb/Math268_2012F/Shamir92.pdf) , which implied from preceding results (e.g. [this one](https://link.springer.com/chapter/10.1007/3-540-48184-2_4) ), that under the existence of one way functions, all languages in PSPACE had a zero-knowledge interactive proof system. Finally, while previous results showed that one-way functions were _sufficient_ for zero-knowledge [Ostrovsky and Wigderson](https://www.math.ias.edu/~avi/PUBLICATIONS/MYPAPERS/OW93/paper.pdf) showed that they were also _necessary_ for non-trivial languages. All in all, these breakthrough results have shown that randomness and interactions captured very wide complexity classes. Moreover, and remarkably, relying on some lightweight computational assumptions (i.e. existence of one-way functions) allowed to obtain zero-knowledge for languages in PSPACE. #### **On the _true_ power of IP.** Now, while IP = PSPACE provides additional evidence about the power of using interaction and randomness, too little is known about the complexity class hierarchy to reach a conclusion on the actual power of these two “ingredients”. While it is known that P $\\subseteq$ NP $\\subseteq$ PSPACE, it is still unknown (i.e. unproven) whether these inclusions really are equalities (in which case we talk about a “collapse” in the complexity class hierarchy) or whether all (or some) of them are strict inclusions. For now, it is widely conjectured that all these inclusions are strict, and as such, widely assumed that interactions and randomness are very powerful tools for language recognition. ### Interacting with multiple provers As we have seen, in IP, a verifier sends random challenges to an all powerful prover in order to decide whether the prover’s statement ($x \\in \\mathbf{L}$) is valid or not. A natural generalization of this model – coined “multi-prover interactive proofs” (MIP) – was introduced by [Ben-Or, Goldwasser, Kilian and Wigderson](https://www.math.ias.edu/~avi/PUBLICATIONS/MYPAPERS/GKBW88/GKBW88.pdf) . In this model, the verifier does not interact with a single prover, but rather with two computationally unbounded (and untrusted) provers who can agree on a strategy to fool the verifier but who cannot communicate with each other during the course of the protocol (i.e. as soon as the verifier starts to send challenges). Initially introduced as a way to obtain zero-knowledge proof systems for NP without intractability assumptions, this model was further shown to be remarkably powerful. In fact, the possibility to “cross-examine” the two provers during the protocol allows to enforce _non-adaptivity_ without requiring any computational assumptions! (Imagine two criminals interrogated by a policeman in two different rooms (i.e. they can’t talk during the interrogation). While the two criminals may have agreed – before hand – on a strategy to fool the policeman, the policeman may ask very detailed questions to both criminals to see if their stories align. Hence, even if one criminal lies, the chances that the second criminal will answer the same question with the exact same lie are small, and the policeman will be able to detect whether they said the truth or not). While we trivially know that IP $\\subseteq$ MIP (i.e. just ignore the answers from the second prover in the protocol), a later result, by [Babai, Fortnow and Lund](https://people.cs.uchicago.edu/~fortnow/papers/mip2.pdf)  concluded that MIP = NEXP, providing more insight about the power of interacting with multiple parties. Proofs vs Arguments ------------------- As mentioned above, Goldwasser, Micali and Rackoff’s notion of _soundness_ was designed to hold against all powerful provers. Nevertheless, it is reasonable to assume that no real life adversary is all powerful (even quantum adversaries have their limitations!). As such, the notion of _argument_ has been introduced as a way to denote “computationally sound proofs” (i.e. soundness is relaxed to hold against provers having limited storage and computing capabilities). Shifting from _proofs_ to _arguments_ allows to leverage “strong” cryptographic assumptions in order to design succinct proofs systems (with very low communication complexity). Moreover, and interestingly, the “eagle-eyed” reader may have realized that the notion of _“proof of knowledge’_‘ really takes all its meaning when moving to arguments. In fact, an all powerful prover can always find the witness if it exists – which does not apply anymore in the context of _arguments (of knowledge)_. (In the following, I will use proofs and arguments interchangeably.) #### **Isn’t it bad to weaken the prover?** While IP is defined in the plain model (no assumptions are made), moving from proofs to arguments and relying on additional (number theoretic or complexity) assumptions enables to achieve various desirable things that aren’t doable in the plain model (e.g. design one-step zero-knowledge proof protocols for non-trivial languages). Thus, making new assumptions allows to break some known “barriers” and explore a new set of possibilities! Removing interactions --------------------- So far, we studied interactive proofs and their relation with known complexity classes. We were interested in understanding what made GMR’s probabilistic method for checking proofs so powerful. We saw that “randomness” and “interactions” appeared as essential ingredients, and that under existence of one-way functions, all languages recognizable with GMR’s method could be so in “zero-knowledge”. Brilliant. Now… we live in the blockchain era, so how can we remove the need to generate long transcripts, and rather prove NP-statements with a single blockchain transaction? This notion of non-interactive zero-knowledge (NIZK) was studied much before “blockchain” was even a thing, by [Blum, De Santis, Feldman, Micali and Persiano](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Zero%20Knowledge/Noninteractive_Zero-Knowkedge.pdf) . In order to prevent a collapse to BPP, the authors proposed to replace interactions between the prover and the verifier by a _shared common random string_, moving away from the plain model. In this setting, both prover and verifier are given read access to a shared random string $\\sigma$. To prove his statement, the prover generates a proof (that $x \\in \\mathbf{L}$) using the string $\\sigma$ and his witness $w$. This proof is then sent to the verifier who will check the prover’s statement validity against $\\sigma$. Informally, in their work, the authors start by observing that using a public random string to build a non-interactive zero-knowledge protocol for language recognition seems related to the notion of Arthur-Merlin protocols (where the verifier can be substituted by the output of a random beacon). Nevertheless, two major distinctions remain. First, the _common random string_ in the non-interactive setting contains _all_ the coin flips for the _whole_ protocol. This contrasts with AM in which the prover receives coin flips at each round (and cannot predict the next challenges). Second, every time the prover and verifier engage in an interactive protocol, new challenges are generated. As such, the coin flips will not be the same from one execution to another. That again, raises several questions about the nature of the _common random string_. For instance, one may wonder if is it even possible to re-use the same random string to prove various statements (will soundness hold if the prover chooses the statement after being given the common random string – i.e. are NIZKs secure against adaptive adversaries? Will zero-knowledge hold if the same random string is used to prove multiple statements? etc.) Some of these questions were answered by [Feige, Lapidot and Shamir](https://ieeexplore.ieee.org/document/89549)  who showed how to construct a NIZK proof system for NP under general cryptographic assumptions where multiple independent provers could re-use the same reference string to prove NP-statements. A key observation to make here is that: to prevent a “complexity collapse” when moving to the non-interactive setting, one _MUST_ resort to use additional (stronger) assumptions. That being said, relying on such assumptions to design non-interactive protocols allows to achieve very nice things such as “publicly verifiability”, where anyone (having access to the reference string $\\sigma$) who is given a proof can verify it (most applications of zero-knowledge in the blockchain space leverage this property, in order the encode the verifier directly in the distributed protocol, see [here](https://github.com/clearmatics/zeth)  for instance). In a way, the reference string “encodes the verifier’s challenges in the transcript”. As such, we almost go back to where we started this blog post. In NIZKs, zero-knowledge proofs “become static objects” (again), in that, a proof can be written, shared and verified by multiple verifiers provided they all have access to the reference string used by the prover (soundness holds for a given $\\sigma$). This raised new challenges for the use of NIZKs in real life applications (e.g. Man-In-The-Middle/replay attacks) which begged for additional security guarantees, later formalized as non-malleability and simulation(-knowledge)-soundness (see [this paper](https://www.iacr.org/archive/crypto2001/21390566.pdf) or [this paper](http://web.cs.ucla.edu/~sahai/work/web/1999%20Publications/S99.pdf)  for instance). Over the past decades, the “common reference string” model has been derived into various “flavors”. In fact, the broad set of cryptographic assumptions used to build NIZKs for NP languages, naturally translated in various “shapes” for the common reference string. NIZKs secure in the Random Oracle model will have a reference string instantiated with a secure cryptographic hash function. However, reference strings of NIZKs relying on discrete-logarithm and pairing-based hardness assumptions can have a given “structure” for instance (see e.g. [this](https://eprint.iacr.org/2012/215) or [this](https://eprint.iacr.org/2016/260.pdf) ). What’s more, such structured reference strings (SRS) can also further be classified as “universal SRS” and/or “updatable SRS” (see [here](https://eprint.iacr.org/2018/280) ). While a myriad of NIZKs have already been designed (we would need much more than a blog post to provide a fairly “comprehensive” list) this plethora of work illustrate that understanding which assumptions are required to build NIZKs for NP is a very active area of research. Interestingly, some constructions based on number-theoretic assumptions could now be broken in the presence of a powerful quantum adversary. As such, new pieces of work have recently emerged in the hope to build quantum-secure NIZKs for NP languages. Conclusion ---------- In this blog post I tried to go back in time in order to provide intuition on some of the foundational results of the space of probabilistic proof systems (and complexity theory). Hopefully, you should now have an feeling for the notions of "proofs of knowledge'" and "zero-knowledge proofs". The only take away - if any - from this blog post is that randomness and interactions is a powerful combination - especially when coupled with a clever method to encode computation. If you look at most modern probabilistic proof systems (SNARKs, STARKs, etc.), you should see that they all share similarities that can be dated back to some of the early works exposed here. Last but not least, many (many) foundational pieces of research are missing in this blog post. Designing efficient probabilistic proof systems touches many sub-areas of computer science and mathematics, so I couldn't provide an extensive view in this post. I would highly encourage you to read these early works, since, as we say "the past explains the present''. [Education](https://zkproof.org/tag/education/) [Tech](https://zkproof.org/tag/tech/) [Zero-knowledge proofs](https://zkproof.org/tag/zero-knowledge-proofs/) * * * ![](https://secure.gravatar.com/avatar/dc3f0db7d6834d4f4d8308e5e309d092?s=240&d=identicon&r=g) ##### [Antoine Rondelet](https://zkproof.org/author/antoinerondelet/ "Antoine Rondelet post page") [All author posts](https://zkproof.org/author/antoinerondelet/ "Antoine Rondelet post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2020/10/15/randomness-and-interactions/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Standards Archives - ZKProof Standards Standards ========= [![](https://zkproof.org/wp-content/uploads/2023/10/DALL·E-2023-10-19-13.53.26-Illustration-of-a-balance-scale.-On-one-side-theres-a-microchip-representing-ZK-Hardware-and-on-the-other-a-lightning-symbol-representing-energy-J-uai-258x172.png)](https://zkproof.org/2023/10/23/zk-score-blog/) October 23, 2023 ### [ZK Score – ZK hardware ranking standard](https://zkproof.org/2023/10/23/zk-score-blog/)   * * * [![](https://secure.gravatar.com/avatar/e295b0529c3b8e216566a972f6dd3182?s=40&d=identicon&r=g)by Omer Shlomovits](https://zkproof.org/author/omershlomovits/) [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # ZKProof 5.5 - A day in Barcelona - ZKProof Standards ZKProof 5.5 - A day in Barcelona ================================ Barcelona, Spain ================ [Join the ZKProof Telegram!](https://t.me/+xZBYZx6FrtBkZjI0 "ZKProof Telegram") **Join us in Barcelona on August 2nd to the ZKProof 5.5 gathering** A must-attend intimate event for cryptographers and developers interested in the cutting-edge field of zero-knowledge proofs. Don’t miss out on the opportunity to connect with other experts in the field and help shape the future of zero-knowledge proofs. See you there! This is event was made possible thanks to the generous sponsorship of Zcash Foundation, and organized by the QEDIT team. #### Important Information **Dates:** August 2nd **Registration: Closed!** **Location:** Barcelona Invited Speakers -------------------- [![Peter Scholl](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/07/Peter-4-small.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/peter-scholl-2/) ### [Peter Scholl](https://zkproof.org/team/peter-scholl-2/ "Peter Scholl") [Associate professor at Aarhus University.](https://zkproof.org/team/peter-scholl-2/ "Peter Scholl") [![Daniel Kang](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/bio-photo.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/daniel-kang/) ### [Daniel Kang](https://zkproof.org/team/daniel-kang/ "Daniel Kang") [Professor, UIUC](https://zkproof.org/team/daniel-kang/ "Daniel Kang") [![Kimberlee Model](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/kimee.jpg.webp?resize=150%2C150&ssl=1)](https://zkproof.org/team/kimberlee-model/) ### [Kimberlee Model](https://zkproof.org/team/kimberlee-model/ "Kimberlee Model") [Research Software Engineer, Stealth Software Technologies](https://zkproof.org/team/kimberlee-model/ "Kimberlee Model") [![James Parker](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/JamesP.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/james-parker/) ### [James Parker](https://zkproof.org/team/james-parker/ "James Parker") [Research Engineer, Galois](https://zkproof.org/team/james-parker/ "James Parker") [![Ying Tong Lai](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/2023-04-28-12.45.09-1.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ying-tong-lai/) ### [Ying Tong Lai](https://zkproof.org/team/ying-tong-lai/ "Ying Tong Lai") [Research Associate, Geometry](https://zkproof.org/team/ying-tong-lai/ "Ying Tong Lai") [![Mary Maller](https://i0.wp.com/zkproof.org/wp-content/uploads/2021/02/marymaller-e1614114950795.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/mary-maller/) ### [Mary Maller](https://zkproof.org/team/mary-maller/ "Mary Maller") [Cryptography Researcher, Ethereum Foundation](https://zkproof.org/team/mary-maller/ "Mary Maller") [](http://marymaller.com/ "globe") [![Jonathan Rouach](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/05/Jon-e1576579828908.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/jonathan-rouach/) ### [Jonathan Rouach](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [Executive Director for ZKProof, CEO and Founder, QEDIT](https://zkproof.org/team/jonathan-rouach/ "Jonathan Rouach") [![Daniel Benarroch](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/77A5005-1-e1580068464804.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/daniel-benarroch/) ### [Daniel Benarroch](https://zkproof.org/team/daniel-benarroch/ "Daniel Benarroch") [](https://twitter.com/benarrochdaniel "twitter") [](/cdn-cgi/l/email-protection#3357525d5a565f73495843415c5c551d5c4154 "envelope-o") **Agenda** ========== **PLONK Standardization** ------------------------- ### **Which level of abstraction, what’s already out there, who’s the consumer of the standard ** 09.00-10.30 ### **Session Lead: Mary Maller** In this session, we are going to discuss a current effort to write standards for the Plonk zero-knowledge proof.  This is one of the most popular SNARKs to be used in deployment today and seems a natural candidate for standardization.  However, it is not as if anybody has ever succeeded in standardizing such advanced cryptography before, and we are, to a degree determining style that will be used not only now but in future standards.  Thus we want as much feedback and help as the community is willing to give us.  Please come to our session, listen to what we have already been working on, and tell us honestly (and if necessary brutally) how we can improve to make this standard more fit for your purposes. Coffee Break ------------ 10.30-11.00 **Recursive Proof Composition** ------------------------------- 11.00-12.30 ### **Session Lead: Ying Tong Lai**  Recent advances in folding schemes and FRI-based full recursion have significantly reduced the overhead of recursive proof composition, making large computations (e.g., virtual machines, neural networks) efficiently provable. * In this session, we will compare existing constructions of recursive proof composition, discussing criteria such as: zero knowledgeness of the recursive step. * support for non-uniform predicates. * instantiation of incrementally verifiable computation.   and/or proof-carrying data. * support for lookup arguments. * recursion threshold/overhead. * concrete prover/verifier efficiency (accounting for  implementation details like field size, curve cycles). * security and cryptographic assumptions. We also suggest directions for further work, including: * overlap between CCS and PlonKish standardisation efforts. * desired tooling / interfaces for proof composition. * benchmarking efforts. * include SNARKS and Recursion, not only ZK. * update the reference document of ZKProof to bless Recursion as more important concept. **Lunch Break (outside of the event)** -------------------------------------- 12.30-14.15 Enjoy a personal lunch break among the many exceptional eateries encircling the conference hotel. Capitalize on this wonderful opportunity to catch up with colleagues and explore the captivating flavors of Barcelona.  **ZKML- Where are we now? Where do we go from here?** ------------------------------------------------------ 14.15-15.15 ### **Session Lead:** Daniel Kang ZKML has received a lot of attention recently, but what can it actually do? And what can ZKML frameworks do today? We’ll discuss what’s feasible today and next steps. There will be time for open-ended discussion. SIEVE Circuit IR Specification ------------------------------ 15.15-15.45 ### **Session Lead: James Parker & Kimberlee Model** During the DARPA SIEVE program, teams have been collaboratively defining an intermediate representation (IR) specification language for encoding zero-knowledge proof statements. In this talk, we will present the SIEVE IR language, giving an overview of the features of the language and the ecosystem built around it. In addition, we will discuss lessons learned through the process of designing the standard by committee, and how the language might live on after SIEVE to be useful for the larger ZK community. **Coffee break**  ----------------- 15.45-16.15 ZKPs and Post-Quantum Signatures From VOLE-in-the-Head. ------------------------------------------------------- 16.15-16.45 ### **Session Lead: Peter Scholl** Recent years have seen the development of new techniques for ZKPs based on VOLE, a tool from multi-party computation. VOLE-based proofs are typically interactive and not succinct, but have a very low computational overhead for the prover. In this talk, I will give an overview of VOLE-based ZK, including a recent work that allows these proofs to be non-interactive using VOLE-in-the-head. I will discuss the advantages of this approach and an application to FAEST, a candidate post-quantum signature scheme based on AES. **ZKP & Regulation Panel: Finding the Balance between Privacy, Security, and Law** ---------------------------------------------------------------------------------- 16.45-17.30 ### **Session Lead: Jonathan Rouach** Wrapping up our day-long discussion on ZKP standardization, this down-to-earth panel will address the crucial regulatory aspects of implementing zero-knowledge proof (ZKP) technology in the real world. We’ll explore the delicate balance between its privacy-enhancing features, security, and the demands of law enforcement. Anonymous by nature, ZKP applications in blockchain raise questions about how to handle bad actors while leveraging its potential for GDPR compliance. As we work on standardizing this powerful tech, we must ensure the tools remain compatible with legal requirements and clear up any misconceptions. Our diverse panel representing the Zcash Foundation,  academia, and hands-on practitioners (hackers), will guide us through the interplay of ZKP technology, regulations, and law enforcement needs. Join us for this engaging conversation to better understand how we can harness the potential of ZKP while navigating the challenges of privacy, security, and regulation. #### The event will be held in Barcelona, Spain Hotel [Hilton Diagonal Mar](https://www.hilton.com/en/hotels/bcndmhi-hilton-diagonal-mar-barcelona/?SEO_id=GMB-EMEA-HI-BCNDMHI) [](#) --- # Zero-Knowledge Proofs from Information-Theoretic Proof Systems - Part II - ZKProof Standards Zero-Knowledge Proofs from Information-Theoretic Proof Systems - Part II ======================================================================== October 15, 2020 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Yuval Ishai](https://zkproof.org/author/yuvalishai/) This is the second (and final) part of an extended blog post discussing the design of efficient zero-knowledge proof systems by maximizing the separation between the “information-theoretic” and the “cryptographic” ingredients. In the [first part](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) we gave some general background on different kinds of zero-knowledge proofs and discussed the advantages of decomposing them into an _information-theoretic proof system_ and a _cryptographic compiler_. We considered a simple kind of information-theoretic proof system called “zero-knowledge PCP” and matching cryptographic compilers. These give rise to theoretical feasibility results, as well as practical zero-knowledge proofs that are either non-succinct or “semi-succinct.” In this second part, we will discuss different routes to better succinctness. Fully succinct proof systems via generalized PCPs ------------------------------------------------- From here on, we will mainly focus on _fully succinct_ zero-knowledge proofs, in which the communication scales polylogarithmically with the instance size. As discussed in the [background part](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) , succinctness typically comes with fast verification and is meaningful even without the zero knowledge property. To simplify the exposition, we will focus mainly on communication costs and ignore verification time. We will also occasionally consider succinctness alone without zero knowledge, with the understanding that the extra zero knowledge property can be added at a small additional cost. **Full succinctness: the classical way.** The first route for obtaining fully succinct proof systems is via the celebrated _PCP theorem_. First proved in the works of [Arora and Safra](https://dl.acm.org/doi/10.1145/273865.273901) and [Arora, Lund, Motwani, Sudan, and Szegedy](https://dl.acm.org/doi/10.1145/278298.278306) , and later simplified by [Dinur](https://eccc.weizmann.ac.il//eccc-reports/2005/TR05-046/index.html) , the PCP theorem establishes the following amazing fact: every NP statement can be probabilistically verified, with a small constant soundness error, by reading just a _constant_ number of bits from the proof. Framed in the language of zk-PCP, the PCP theorem gives a zk-PCP _without zero knowledge_ for every NP-relation $R$, where the proof $\\pi$ is over the binary alphabet and the size of a query set $Q$ is constant. Zero knowledge can be added to any such PCP with a small overhead using [this](https://doi.org/10.1007/3-540-48071-4_15) or [this](https://eprint.iacr.org/2017/176.pdf) information-theoretic compiler, yielding a zk-PCP with similar parameters. The constant soundness error can be made exponentially small either by generating multiple independent query sets or by using alternative methods that rely on [parallel repetition theorems](http://www.wisdom.weizmann.ac.il/~ranraz/publications/Pparal1.ps) . As discussed in the [first part](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) , there are cryptographic compilers that use a collision-resistant hash function (respectively, a random oracle) to convert such zk-PCPs into constant-round (respectively, non-interactive and transparent) fully succinct zero-knowledge arguments for NP. These compilers rely on a hash tree, known as a [Merkle tree](https://link.springer.com/chapter/10.1007%5C%2F3-540-48184-2_32%7D%7BMerkle) , to implement a succinct commitment to the proof $\\pi$ that supports efficient local opening by revealing the hash values along a path on the tree. This induces a communication overhead that grows logarithmically with the PCP length. The logarithmic overhead can be avoided by using alternative realizations of the commitment primitive that rely on [cryptographic accumulator techniques](https://eprint.iacr.org/2011/495) , as first proposed [here](https://eprint.iacr.org/2018/705) and [here](https://eprint.iacr.org/2018/1188) . However, this comes at the cost of requiring stronger “public-key” assumptions and making the concrete prover complexity even worse. **Relaxing the PCP model.** Using [efficient PCP constructions](https://ieeexplore.ieee.org/document/1443079) , the above approach yields zk-PCPs and zero-knowledge arguments in which all main efficiency parameters (communication, prover computation, verifier computation) are optimal up to polylogarithmic factors. However, despite [substantial optimization efforts](https://eprint.iacr.org/2016/646) , the best known classical PCP constructions are quite complex and have a big concrete overhead on the prover side. The key idea that underlies most of the practical fully succinct proof systems is that two natural relaxations of the PCP model can make PCP design much easier. The first, already mentioned in the passing in the first part of this post, is to make the PCP model _interactive_. The second is to replace the point queries made to the proof $\\pi$ by more powerful _linear_ queries. We discuss these two relaxations, as well as their combination, below. ### Interactive PCP and IOP The idea of making the PCP model more powerful by allowing additional interaction between the prover and the verifier was first proposed by [Kalai and Raz](https://eccc.weizmann.ac.il//eccc-reports/2007/TR07-031/index.html) . Their notion of _interactive PCP_ is similar to the notion of (zk)-PCP discussed above, except that in addition to making queries to the proof $\\pi$, the verifier can interact with the prover. We will start by describing some of the earlier applications of interactive PCPs, and then discuss an extension that underlies recent practical and fully succinct proof systems. Kalai and Raz showed that, for NP-relations $R$ computed by constant-depth circuits, interactive PCPs can have surprisingly good parameters. Concretely, whereas for low-communication classical PCPs the proof size is bigger than the circuit size of $R$ (which is [likely to be inherent](https://eccc.weizmann.ac.il//eccc-reports/2007/TR07-096/index.html) ), in the interactive case the proof size can be reduced to roughly the witness length while still maintaining low communication. This was subsequently generalized from constant-depth $R$ to low-depth $R$ (e.g., computable by polylogarithmic-depth NC circuits) by [Goldwasser, Kalai, and Rothblum](https://eccc.weizmann.ac.il/report/2017/108/) . A _constant-round_ variant for space-bounded computations was given by [Reingold, Rothblum, and Rothblum](https://eccc.weizmann.ac.il/report/2016/061/) . We will revisit these results later when we cast them in a different PCP model. Using a [cryptographic compiler](https://link.springer.com/chapter/10.1007\%2F0-387-34799-2_4) based on one-way functions, these interactive PCPs yield statistically-sound zero-knowledge proof protocols for low-depth (or space-bounded) NP relations in which the communication complexity is comparable to the witness length. In the [first part](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) , we discussed the MPC-in-the-head paradigm for compiling simple kinds of MPC protocols with perfect correctness guarantees into zk-PCPs. Interactive zk-PCPs can be obtained by applying a similar approach to MPC protocols that have _statistical_ correctness guarantees. Interaction is needed because in the non-interactive compilers from MPC to zk-PCP, a malicious prover can choose the randomness of MPC parties in a way that violates MPC correctness and hence zk-PCP soundness. An interactive random challenge from the verifier can be used to effectively force the prover to use unbiased randomness. This interaction turns out to be crucial for some efficient MPC-based zk-PCPs, such as the one that underlies the [Ligero](https://doi.org/10.1145/3133956.3134104)  proof system. The interactive PCP model discussed up to this point has a single proof $\\pi$, whose symbols can be queried by the verifier, and additional (low-communication) interaction between the verifier and the prover. Taking interaction in PCPs to its full level of generality, [Ben-Sasson, Chiesa, and Spooner](https://eprint.iacr.org/2016/116) , and independently [Reingold, Rothblum, and Rothblum](https://eccc.weizmann.ac.il/report/2016/061/) , introduced the _Interactive Oracle Proof_ (IOP) model, which allows multiple proofs $\\pi\_i$ to be sequentially generated by the prover and queried by the verifier. More concretely, in (the public-coin variant of) the IOP model, each $\\pi\_i$ comes in response to an unpredictable random challenge $r\_i$. Without loss of generality, the verifier’s queries to the proofs $\\pi\_i$ are made in the end of the interaction. We refer to an IOP as _fully succinct_ if the total number of bits from all proofs $\\pi\_i$ that are read by the verifier is polylogarithmic in the instance size. The additional interaction allowed by the IOP model makes the design of fully succinct proofs in this model simpler than in the classical PCP model or even in the interactive PCP model discussed above. This simplicity also leads to remarkable efficiency improvements. As in the case of classical PCPs, there are cryptographic compilers that use a collision-resistant hash function (respectively, a classical or even [quantum](https://eprint.iacr.org/2019/834.pdf) random oracle) to convert fully succinct IOPs into interactive (respectively, non-interactive and transparent) fully succinct arguments for NP. These compilers naturally extend the ones for classical PCPs. In the interactive variant, the prover uses a Merkle tree to succinctly commit to each proof, following which the verifier generates and sends the random challenge for the next proof. In the end, the verifier challenges the prover to open the subset of proof symbols that the IOP verifier wants to query, to which the prover responds by revealing the small amount of relevant information on the Merkle trees. The non-interactive variant is obtained from the interactive one via the Fiat-Shamir heuristic, though the analysis in the random oracle model is considerably more challenging in the interactive case and requires some extra assumptions on the underlying IOP. On the practical side, transparent SNARKs such as [STARK](https://eprint.iacr.org/2018/046) , [Aurora](https://eprint.iacr.org/2018/828) , and [Fractal](https://eprint.iacr.org/2019/1076) , all rely on concretely efficient IOPs. While not quite as succinct as the group-based SNARKs we will discuss next (with typical proof size in the range of 100-200 kB in the former vs. 1-2 kB in the latter), they have the advantages of being transparent, plausibly post-quantum, and avoiding altogether the use of public-key cryptography. The latter can be useful for making provers run faster. A key technical ingredient in these practical IOPs is the [FRI protocol](https://eccc.weizmann.ac.il/report/2017/134/)  of Ben-Sasson, Bentov, Horesh, and Riabzev: an interactive test for proximity of an oracle to a Reed-Solomon code. A useful feature of the FRI protocol is that it can be realized using a strictly linear number of arithmetic operations. However, the IOPs that build on top of it still require quasilinear time on the prover side. On the theoretical side, the IOP model gives rise to asymptotic efficiency features that are not known to be achievable with classical PCPs. See [here](https://eprint.iacr.org/2019/1230) and [here](https://eprint.iacr.org/2019/1062) for recent progress on minimizing the _proof size_ of IOPs. While proof size is not the main parameter of interest in cryptographic applications of IOPs, as it only serves as a lower bound on the prover’s running time, new techniques for constructing IOPs are likely to lead to progress on the concrete efficiency of IOP-based proof systems. More directly relevant to the concrete efficiency of IOPs are works on improving the analysis of their _soundness error_. See [here](https://eccc.weizmann.ac.il/report/2018/090/) , [here](https://drops.dagstuhl.de/opus/volltexte/2020/11690) , and [here](https://eprint.iacr.org/2020/654)  for progress on this front. ### Linear PCP Up to this point, we discussed relaxations of the classical PCP model that allow additional interaction. A very different kind of relaxation is to allow the verifier to use a _richer set of queries_. A simple and useful instance of this is the _linear PCP_ (LPCP) model. Whereas in a standard PCP the verifier is allowed to make a bounded number of _point queries_, which read individual symbols of the proof $\\pi$, a _linear PCP_ allows each query to take an arbitrary linear combination of the entries of $\\pi$. More concretely, in a linear PCP over a finite field $\\mathbb{F}$ the proof is a vector $\\pi\\in\\mathbb{F}^m$ and each query $q\_i\\in\\mathbb{F}^m$ returns the inner product $\\langle \\pi,q\_i\\rangle$. We require by default that the queries $q\_i$ be _input-oblivious_, in the sense that they can be picked independently of $x$. As we will soon see, it is quite easy to construct such an LPCP for any NP-relation $R$ with polynomial proof size $m$, soundness error $O(1/|\\mathbb{F}|)$, and a constant number of queries; in fact, substantially easier than in any of the previous PCP models we discussed. The main price we pay for the more powerful PCP model is that the corresponding cryptographic compilers typically need to rely on stronger primitives that live in the “public-key cryptography” world, and moreover require strong forms of setup to fully respect the efficiency features of the underlying LPCP. The idea of using LPCPs to construct low-communication proof systems for NP was first suggested in a [joint work](https://ieeexplore.ieee.org/document/4262770) with Kushilevitz and Ostrovsky. The primary initial motivation was simplicity: demonstrating that complex PCP machinery can be replaced by much simpler one, at the cost of using stronger cryptography. However, it was already observed back then that beyond simplicity, this new approach can lead to an efficiency feature that was not possible via the traditional PCP-based approach: prover-to-verifier communication that includes only a constant number of “ciphertexts,” or group elements, independently of the complexity of $R$. Before discussing the type of cryptographic compilers that apply to the LPCP model, I will illustrate the power of the model by giving a self-contained description of an LPCP for NP with constant query complexity. ### The Hadamard LPCP The pioneering work of [Arora et al.](https://dl.acm.org/doi/10.1145/278298.278306) on classical PCPs presented a relatively simple PCP for NP based on the Hadamard code. Viewed as a classical PCP, this so-called “Hadamard PCP” is very inefficient, having exponential proof size. However, when applied to short statements, it was still efficient enough to serve as the simpler of two main building blocks in the proof of the PCP Theorem. The construction and analysis were somewhat complicated by the need to rely on [_linearity testing_](https://www.sciencedirect.com/science/article/pii/002200009390044W?via\%3Dihub) , a nontrivial test of proximity to the Hadamard code. In the LPCP model described above, where even a malicious prover is bound to a linear function of the verifier’s queries, this extra complication can be avoided. To present the Hadamard-based LPCP, it is convenient to write the NP-relation $R(x,w)$, restricted to a fixed statement length, as an arithmetic circuit over a finite field $\\mathbb{F}$, whose gates perform field additions and multiplications. Concretely, the prover wants to convince the verifier that there is a witness $w\\in\\mathbb{F}^m$ such that $C(x,w)=0$, where $C$ is a publicly known arithmetic circuit and $x\\in\\mathbb{F}^n$ is the public statement. The first step is to convert $C$ and $x$ to a system of $s$ _quadratic_ equations of the form $Q\_i(Y)=0$, where each $Q\_i$ is a multivariate polynomial of degree (at most) 2 in $s$ variables $Y\_1,\\ldots,Y\_s$. This should be done so that there is $w\\in\\mathbb{F}^m$ such that $C(x,w)=0$ if and only if there is $y\\in\\mathbb{F}^s$ such that $Q\_i(y)=0$ for all $i$. The natural way of doing it is by assigning a variable $Y\_j$ to each gate of $C$, where $Y\_1,\\ldots,Y\_n$ correspond to the input gates and $Y\_s$ to the output gate. We can now express the question “does there exist $w$ such that $C(x,w)=0$?” as the existence of $y\\in\\mathbb{F}^s$ that satisfies $Q\_i(Y)=0$ for the following polynomials: * for each input gate $i= 1,\\ldots,n$, let $Q\_i = Y\_i-x\_i$ (where $x\_i$ is a fixed field element taken from the public statement $x$) * for each multiplication gate of the form “gate $i$ equals gate $j$ times gate $k$,” let $Q\_i = Y\_i-Y\_jY\_k$ * for each addition gate of the form “gate $i$ equals gate $j$ plus gate $k$,” let $Q\_i = Y\_i-(Y\_j+Y\_k)$ * for the output gate, let $Q\_s = Y\_s$ It is not hard to see that $Q\_i(y)=0$ for all $1\\le i\\le s$ if and only if $y$ contains the values of all $s$ gates of $C$ on some input $(x,w)$ such that $C(x,w)=0$. (If $C$ is an arithmetic extension of a Boolean circuit, one can add the additional polynomials $Q’\_i=Y\_i(1-Y\_i)$ for $n+1\\le i\\le n+m$ to ensure that all $w$ values are from $\\{0,1\\}$.) The Hadamard LPCP for proving the satisfiability of $Q\_i(Y)$ now proceeds as follows. The LPCP prover, on input $(x,w)$, first computes the values $y\\in\\mathbb{F}^s$ of all $s$ gates of $C$ on input $(x,w)$. It then computes the tensor product $\\hat y=(y \\otimes y)$, where $\\hat y:\[s\]\\times\[s\]\\to \\mathbb{F}$ is defined by $\\hat y\_{j,k}=y\_jy\_k$. The proof can now be defined as $\\pi=(y, \\hat y)$, where $\\hat y$ is parsed as a vector in $\\mathbb{F}^{s^2}$. Note that, assuming $\\pi$ is well-formed, every degree-2 polynomial in $y$ can be obtained by the verifier by making a single linear query to $\\pi$. The verifier’s queries achieve two goals: (1) check consistency of the two parts of $\\pi$ with the tensoring relation; (2) check satisfiability of all $Q\_i$ relations assuming (1). Goal (1) is realized by comparing two different ways of computing the _square_ of a _random_ linear combination $\\Sigma\_{j=1}^s r\_jy\_j$ of the entries of $y$: first directly, and second by taking a suitable linear combination (with coefficients of the form $r\_jr\_k$) of $\\hat y$. Using tensor notation, the verifier makes two linear queries: (1) $\\langle \\pi, q\_1\\rangle =\\langle y,r\\rangle$, for a uniformly random $r\\in\\mathbb{F}^s$, and (2) $\\langle \\pi, q\_2\\rangle=\\langle \\hat y, r\\otimes r\\rangle$. The verifier checks that the two inner products, $a\_1$ and $a\_2$ respectively, satisfy $a\_2=a\_1^2$. It follows from the [Schwartz-Zippel Lemma](https://eccc.weizmann.ac.il/report/2010/096/) that if $\\hat y\\neq y\\otimes y$ then the latter check fails except with at most $2/|\\mathbb{F}|$ probability. Finally, the verifier makes a third query that checks all equations $Q\_i(y)=0$ simultaneously via a random linear combination: (3) $\\sum\_{i=1}^s r\_i\\cdot Q\_i(y)=0$. Note that (3) can be written as \\begin{equation} \\langle \\pi, q\_3\\rangle=\\sum\_{i=1}^n r\_ix\_i \\end{equation} for a linear query $q\_3\\in\\mathbb{F}^{s+s^2}$ defined by the $r\_i$’s. Assuming that indeed $\\hat y=y\\otimes y$, if there is $i$ such that $Q\_i(y)\\neq 0$ then this check fails except with $1/|\\mathbb{F}|$ probability. Overall, we have an LPCP over $\\mathbb{F}$ with 3 queries, proof size $|\\pi|=O(s^2)$ (where $s$ is the size of the verification circuit), and soundness error $O(1/|\\mathbb{F}|)$. It is easy to convert this LPCP into a zk-LPCP, namely an LPCP in which the view of an honest verifier can be simulated given $x$. This can be achieved by augmenting $R$ so that $w$ has an additional dummy entry $w\_0$. The prover picks $w\_0$ at random, which makes $a\_1=\\langle \\pi,q\_1\\rangle$ random and all 3 answers jointly simulatable. **Fast verification and reusable soundness.** Before discussing cryptographic compilers and more efficient LPCPs, it is instructive to highlight two extra features of the simple Hadamard LPCP that will be useful in the following. While these features are simpler to discuss in the cleaner context of information-theoretic proof systems, they will be inherited by the SNARGs obtained from them via cryptographic compilers. The first feature is _fast verification_ given input-independent preprocessing. Whereas the cost of generating the queries $q\_i$ grows with the size of the verification circuit $C$, the verifier can generate the queries before the input $x$ is known and only keep $r\_1,\\ldots,r\_n$ for later use. Once $x$ is known, the verifier can compute $\\alpha=\\sum\_{i=1}^n r\_i x\_i$, using only $O(n)$ arithmetic operations. Finally, once the LPCP answers $a\_1,a\_2,a\_3$ are available, the verifier can decide whether to accept by checking that $a\_2=a\_1^2$ and $a\_3=\\alpha$, which only takes $O(1)$ field operations. This fast verification feature is particularly useful when the same queries are reused for proving multiple statements. We discuss this setting next. A second useful feature of the Hadamard LPCP is a strong form of soundness that holds even when the same queries are reused for verifying multiple proofs: for any $x$ and proof $\\pi^\*$, the prover can predict based on $x,\\pi^\*$ alone whether the verifier will accept, except with $O(1/|\\mathbb{F}|)$ error probability (over the verifier’s unknown random queries). This means that when $\\mathbb{F}$ is sufficiently big (say, $|\\mathbb{F}|\\ge 2^{80}$), learning whether the verifier accepted $\\pi^\*$ reveals only a negligible amount of information about the queries $q\_j$. The latter strong soundness property is useful for making the SRS in LPCP-based SNARGs reusable even when the prover can learn whether the verifier accepted each instance. This is contrasted with classical (zk-)PCPs, which are [inherently](https://eprint.iacr.org/2018/940) susceptible to a “selective failure” attack in which a malicious prover can gradually learn the secret set of queries when it is reused for multiple proofs. This can be done by slightly perturbing honestly generated proofs and learning whether the verifier accepted each perturbed proof instance. **Cryptographic compilers for LPCP: First generation.** Before discussing more efficient alternatives to the Hadamard LPCP, we turn to discuss suitable cryptographic compilers. Unlike cryptographic compilers for classical PCPs and IOPs, which only rely on “symmetric” (private-key) cryptography, here the compilers accommodate the richer type of queries by employing homomorphic cryptographic computations that require “asymmetric” (public-key) cryptography. At a high level, by extending PCP to LPCP, we obtain better efficiency and simplicity for the information-theoretic proof system, at the cost of slower and more structured cryptography. The [first generation](https://ieeexplore.ieee.org/document/4262770) of such compilers relied on the existence of a linearly homomorphic encryption scheme (sometimes referred to as _additively_ homomorphic encryption). Such an encryption scheme over a field (or ring) enables efficient computation of linear functions with publicly known coefficients on encrypted field elements without knowing the secret decryption key. Instances of linearly homomorphic encryption can be based on a variety of standard cryptographic assumptions, including ones related to the intractability of discrete logarithm, factoring, or lattice problems. The compiler uses such an encryption scheme to implement a special kind of interactive commitment scheme, which allows the prover to succinctly commit to a vector $\\pi$ in a way that allows the prover to subsequently open inner products of the form $\\langle \\pi,q\\rangle$ with a small amount of prover-to-verifier communication. This [“commitment with linear opening”](https://ieeexplore.ieee.org/document/4262770) primitive can be seen a simple instance of a more general notion of [_functional commitment_](https://eprint.iacr.org/2016/766) . The enhanced commitment primitive gives rise to a natural cryptographic compiler in which the prover commits to the LPCP proof $\\pi$ and the verifier challenges the prover to open the the inner products $\\langle \\pi,q\_i\\rangle$ corresponding to the linear queries $q\_i$. While this compiler can be based on a variety of standard cryptographic assumptions, it has several disadvantages. First, it only gives rise to interactive protocols in which the verifier has secret coins, and thus cannot be made non-interactive via the Fiat-Shamir heuristic. Second, succinctness is only in one direction: small prover-to-verifier communication, but high communication, comparable to the size of $\\pi$, from the verifier to the prover. (The latter can be [partially mitigated](https://ieeexplore.ieee.org/document/4262770) via communication balancing and recursion.) Finally, an additional price one pays for only relying on standard cryptographic assumptions is that a malicious prover can potentially commit to a _nonlinear_ function $\\pi^\*$ of the queries. This requires an additional information-theoretic compiler that uses [_linearity testing_](https://www.sciencedirect.com/science/article/pii/002200009390044W?via\%3Dihub) to protect against such a stronger malicious prover, which takes an additional toll on efficiency. Despite these limitations, refinements of the above approach were efficient enough to serve as the basis for [Pepper](https://cs.nyu.edu/~mwalfish/papers/pepper-ndss12.pdf) and [Ginger](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final26_0.pdf) , two of the first implementations of proof systems with fast verification. See this [article](https://dl.acm.org/doi/10.1145/2641562)  by Walfish and Blumberg for a survey of this early line of work. **Cryptographic compilers for LPCP: Second generation.** The next generation of cryptographic compilers eliminate most of the disadvantages of the first generation at the cost of an expensive (but reusable) trusted setup, stronger and “[not efficiently falsifiable](https://link.springer.com/content/pdf/10.1007/978-3-540-45146-4_6.pdf) ” cryptographic assumptions, and (in the case of public verification) stronger forms of public-key cryptography. These compilers can yield zk-SNARKs with very short proofs (roughly 1000 bits, or even less in some settings). They were first implicitly used in the pioneering work of [Groth](https://link.springer.com/chapter/10.1007\%2F978-3-642-17373-8_19) , with subsequent improvements by [Lipmaa](https://eprint.iacr.org/2011/009) . An explicit treatment of such compilers was first given in a [joint work with Bitansky, Chiesa, Ostrovsky, and Paneth](https://eprint.iacr.org/2012/718) , and (in a more restricted form) in the work of [Gennaro, Gentry, Parno, and Raykova](https://eprint.iacr.org/2012/215)  that will be further discussed in the context of LPCP constructions. Let us start by considering the following natural attempt for compiling an LPCP into a _designated verifier_ SNARG with a reusable structured reference string (SRS). The verifier generates LPCP queries $q\_1,\\ldots,q\_d$ (e.g., $d=3$ in the case of the Hadamard LPCP), and lets the SRS $\\sigma$ include a linearly homomorphic encryption of (each entry of) the verifier’s queries, denoted by $\\sigma = (E(q\_1),\\ldots,E(q\_d))$. The verifier keeps the secret key $k\_V$ that can be used for decryption. Now, given an input $(x,w)$ and $\\sigma$, the prover computes an LPCP proof vector $\\pi$, and uses the linear homomorphism of $E$ to compute a short SNARG proof $\\hat\\pi$ consisting of the $d$ ciphertexts $\\hat\\pi=(E(\\langle \\pi,q\_1\\rangle),\\ldots,E(\\langle \\pi,q\_d\\rangle))$ that it sends as a SNARG proof to the verifier. The verifier uses the secret key $k\_V$ to decrypt the LPCP answers $a\_1=\\langle \\pi,q\_1\\rangle,\\ldots,a\_d=\\langle \\pi,q\_d\\rangle$, and applies the LPCP decision predicate to decide whether to accept or reject. The above attempt to implement LPCP under the hood of homomorphic encryption clearly satisfies the completeness requirement. Moreover, it is tempting to believe that since the encryption hides the queries, the proof $\\pi$ must be independent of the queries and thus soundness holds as well. However, this simplistic soundness argument is flawed for two reasons. First, while a standard linearly homomorphic encryption scheme $E$ supports computing linear functions on encrypted inputs, it provides no guarantee that _only_ linear functions can be computed. In fact, linearly homomorphic encryption can be [fully homomorphic](https://crypto.stanford.edu/craig/craig-thesis.pdf) , in which case soundness completely breaks down. The solution to this problem is essentially to “assume it away” by relying on an encryption scheme $E$ that is conjectured to support _only_ linear computations on encrypted inputs. (Alternatively, this can be extended to _affine_ computations that include a constant term.) This strong notion of [“linear-only encryption”](https://eprint.iacr.org/2012/718)  will be discussed in more detail below. A second problem is that there is nothing in the above solution that prevents a malicious prover from using a different proof vector $\\pi^\*\_i$ for each encrypted query $E(q\_i)$. This is beyond the capability of a malicious prover in the LPCP model and may thus violate soundness. A solution to this problem is to have the verifier add to the LPCP an additional query which is a random linear combination of of the original queries, namely $q\_{d+1}=\\rho\_1q\_1+\\ldots+\\rho\_d q\_d$, and check that the answer to this query satisfies $a\_{d+1}=\\rho\_1a\_1+\\ldots+\\rho\_da\_d$. This can be viewed as a simple information-theoretic compiler from LPCP to a 1-round [_linear interactive proof_](https://eprint.iacr.org/2012/718)  (LIP), a stronger information-theoretic proof system that can be viewed as restricting a standard interactive proof by allowing provers (both honest and malicious) to only compute linear functions of the verifier’s messages. To sum up: the modified compiler proceeds in two steps. First, an information-theoretic compiler is applied to convert the LPCP into a LIP. If the LPCP has proof size $m$ and $d$ queries, the LIP resulting from the simple compiler described above has verifier message consisting of $(d+1)\\cdot m$ field elements and prover message consisting of $d+1$ field elements. Then, linear-only encryption is used to compile the LIP into a designated-verifier SNARG with SRS that consists of $(d+1)\\cdot m$ ciphertexts and proof that consists of $d+1$ ciphertexts. This transformation respects all of the additional features of LPCPs we discussed in the context of the Hadamard LPCP: zero knowledge, fast verification, and reusable soundness. The latter means that the SRS of the resulting SNARG can be safely reused for multiple proofs. Finally, when the LPCP is also a “proof of knowledge” (which is the case for all natural constructions), and when the linear-only encryption is “extractable” (a plausible assumption for concrete instantiations), the resulting (zk)-SNARG is also a proof of knowledge, namely it is a (zk)-SNARK. There is still one remaining issue: The above approach seems inherently restricted to the {\\em designated verifier} setting, since only the verifier is able to decrypt the encrypted LIP answers. While this is good enough for some applications, many current applications of SNARGs require public verification. The solution, first (implicitly) used in the work of [Groth](https://link.springer.com/chapter/10.1007\%2F978-3-642-17373-8_19) , is to rely once again on a special property of the LPCP which is respected by the transformation to LIP. Suppose that the LIP verifier’s decision predicate is _quadratic_ in the following sense: to decide whether to accept, the verifier tests equalities of the form $p\_x({\\bf u}, {\\bf a})=0$, where $p\_x$ is a _degree-2_ polynomial determined by the input statement $x$, the vector ${\\bf u}$ contains state information determined by the LIP query, and the vector ${\\bf a}$ contains the LIP answers. Indeed, this is the case for the Hadamard-based LIP. Then, public verification can be achieved by using an encryption scheme that allows such quadratic tests to be performed on an encrypted input without knowing the decryption key. Fortunately, this kind of functionality is supported by pairing-based cryptography. If the SRS $\\sigma$ includes a “pairing-friendly encryption” of the LIP query along with the state information ${\\bf u}$, which can be implemented using _bilinear groups_, the prover on input $(x,w)$ can compute an encryption of the LIP answers $\\bf a$, and then {\\em everyone} can check that the encrypted $\\bf u,a$ satisfy the quadratic relation defined by $x$. ![](https://zkproof.org/wp-content/uploads/2020/09/Screenshot-from-2020-10-13-15-51-43-uai-258x145.png) **On “linear-only” type assumptions.** Recall that a [linear-only encryption](https://eprint.iacr.org/2012/718) is an encryption scheme that _only_ enables computing linear functions on encrypted inputs. This requirement is closely related to a more general notion of [_targeted malleability_](https://eprint.iacr.org/2011/311) . There are several variations of linear-only encryption that are tailored to the type of verification (public vs. designated) and the security requirements (whether the input is adaptively chosen and whether the “proof of knowledge” property is required). Moreover, in some cases it is useful to relax “linear-only encryption,” which guarantees indistinguishability of any pair of messages, to “linear-only one-way encoding,” which only requires security for certain distributions of messages, and may impose additional security requirements. While linear-only security is a very strong assumption that requires care in formalizing, it seems reasonable to conjecture that most standard public-key encryption schemes satisfy it. This includes variants of the encryption schemes of [Goldwasser and Micali](https://www.sciencedirect.com/science/article/pii/0022000084900709?via\%3Dihub) , [ElGamal](https://link.springer.com/chapter/10.1007\%2F3-540-39568-7_2) , [Paillier](https://link.springer.com/chapter/10.1007\%2F3-540-48910-X_16) , and [Regev](https://dl.acm.org/doi/10.1145/1060590.1060603) . The latter can be used as a basis for concretely efficient and _plausibly post-quantum_ [lattice-based designated-verifier SNARGs](https://eprint.iacr.org/2017/240) . It is an interesting open question to construct practical _publicly verifiable_ SNARGs with post-quantum security and a similar level of succinctness, under any assumptions. The closest contenders are IOP-based SNARGs, whose concrete proof length is significantly bigger. Finally, the type of linear-only assumption required for aforementioned publicly verifiable SNARGs is even more involved; however, when instantiated with pairing-friendly groups, it can be proved to hold unconditionally in [suitable generic models](https://link.springer.com/chapter/10.1007\%2F978-3-319-96881-0_2) , which provides further heuristic evidence for security. I would like to conclude this discussion by arguing that even if the current formulations of the linear-only assumptions turn out not to hold for their proposed instantiations, there is still a wide safety margin. Indeed, to violate the soundness of an LPCP-based SNARG one would need to maul ciphertexts in a very specialized way that corresponds to the verification predicate of the LPCP. This takes much more than merely refuting current formulations of linear-only security, and would likely imply unexpected structural properties of existing encryption schemes that have other major consequences. Studying the security of different flavors of linear-only assumptions as well as their relations with other forms of targeted malleability and with [extractability assumptions](https://eprint.iacr.org/2014/402)  is an interesting direction for further research. **More efficient LPCPs.** Recall that in the simple Hadamard LPCP, the proof length $m$ grows quadratically with the size of circuit verifying $R(x,w)$. This implies a similar quadratic overhead for the SRS size and prover complexity of the corresponding SNARGs. The quadratic overhead was eliminated in the influential work of [Gennaro, Gentry, Parno, and Raykova](https://eprint.iacr.org/2012/215) (GGPR). Using an abstract computation model called Quadratic Arithmetic Program, they obtained an LPCP for NP in which the proof length is linear in the verification circuit size and the prover’s running time in this LPCP is quasilinear in the circuit size, and moreover it has the same number of queries, verification degree, and other useful features of the Hadamard LPCP discussed above. At a high level, the improvement stems from replacing the tensoring in the Hadamard LPCP by polynomial multiplication. See tutorials by [Tromer](https://cyber.biu.ac.il/wp-content/uploads/2017/01/3-2.pdf\) and [Buterin](https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649) for simplified explanations. The GGPR construction was followed by many refinements and implementations, including [Zaatar](https://eprint.iacr.org/2012/622) , [Pinocchio](https://eprint.iacr.org/2013/279) , [Geppetto](https://eprint.iacr.org/2014/976.pdf) , and [libsnark](https://github.com/scipr-lab/libsnark) , and served as a basis for the [Zcash](https://eprint.iacr.org/2014/349) cryptocurrency. A zk-SNARK based on an optimized variant of GGPR, due to [Groth](https://eprint.iacr.org/2016/260) , improves the proof size to only 3 group elements ($\\approx 1000$ bits in the best concrete instantiations). Despite evidence for optimality in restricted settings, it is open whether one can get a better level of succinctness with a reasonable running time. A route for better succinctness was given by [Bitansky et al.](https://eprint.iacr.org/2012/718) , who presented an information-theoretic compiler that converts any _classical PCP_ with $d$ queries and $2^{-\\Omega(d)}$ soundness error into a _single-query_ LPCP/LIP with similar soundness error over a field of size $2^{O(d)}$. Combined with known constructions of classical PCPs and candidates for linear-only encryption schemes, this gives rise to designated-verifier SNARGs in which the proof consists of a single ciphertext, or two elements in a pairing-free group ($\\approx 500$ bits in concrete instantiations) if one settles for inverse-polynomial soundness. However, this approach leaves much to be desired. Other than being only applicable in the designated verifier setting (due to the high verification degree), it does not offer fully reusable soundness and is currently impractical since it relies on classical PCPs with low query complexity. Partial progress on the practical efficiency front was obtained in [this recent work](https://link.springer.com/chapter/10.1007\%2F978-3-030-56784-2_26)  by relying on the Hadamard-based LPCP instead of classical PCPs. Bypassing the LPCP-based approach, interactive arguments and SNARGs with _optimal succinctness_ ($d\\ge 1$ bits of prover-to-verifier communication with $\\approx 2^{-d}$ soundness error) can be based on strong cryptographic primitives such as [obfuscation](https://eprint.iacr.org/2013/454) or even [witness encryption](https://eprint.iacr.org/2015/740) . In fact, succinct proof systems may be a [promising route](https://link.springer.com/chapter/10.1007\%2F978-3-030-56784-2_26)  towards the construction of witness encryption schemes. However, current candidate constructions of these high-end primitives are not yet efficient enough for practical purposes. Future developments in the area of cryptographic obfuscation may change this state of affairs. On the prover computation front, it is open whether there is an LPCP with constant (or even sublinear) query complexity in which the prover’s computation is _linear_ (rather than quasilinear) in the verification circuit size. For the zero-knowledge variant of LPCP, this question is meaningful even without any restriction on the number of queries. It turns out that existing constant-query LPCPs such as the Hadamard-based LPCP described above [can be converted](https://eprint.iacr.org/2018/940) into a zk-LPCP (implying a similar zk-LIP) that answers the latter question affirmatively in the arithmetic setting. Concretely, if $R(x,w)$ is computed by an arithmetic circuit over $\\mathbb{F}$ of size $s$, the zk-LPCP prover can be implemented by an arithmetic circuit of size $O(s)$, where the number of queries is $O(s)$ and the soundness error is $O(1/|\\mathbb{F}|)$. This in turn implies (non-succinct) NIZK for arithmetic circuits with constant computational overhead using a correlated randomness setup, where the latter [can be efficiently realized](https://eprint.iacr.org/2019/273)  under arithmetic variants of the Learning Parity with Noise assumption. This approach can have attractive concrete efficiency features over fast networks or for small verification circuits. It was [recently optimized](https://eprint.iacr.org/2020/925)  to yield practical zero-knowledge proof systems with fast and memory-efficient provers. ### Linear and Polynomial IOP Up to this point we discussed two orthogonal relaxations of the classical PCP model: adding interaction and using linear queries instead of point queries. The [_linear IOP_](https://eprint.iacr.org/2019/188.pdf) (LIOP) model combines these two relaxations in a natural way. As in the IOP model, the prover generates a sequence of proof vectors $\\pi\_i\\in\\mathbb{F}^{m\_i}$ in multiple rounds, where each $\\pi\_i$ is a response to a random challenge $r\_i$. In the end of this interaction, the verifier can make linear queries to each $\\pi\_i$, as in the LPCP model. (The LIOP model is closely related to an earlier [Interactive Linear Commitment](https://eprint.iacr.org/2017/872)  model; see discussion below.) **The GKR protocol.** The “doubly efficient” interactive proof protocol of [Goldwasser, Kalai, and Rothblum](https://eccc.weizmann.ac.il/report/2017/108/) (GKR), which builds on the classical _sum-check_ protocol of [Lund, Fortnow, Karloff and Nisan](https://dl.acm.org/doi/pdf/10.1145/146585.146605) , can be cast as an LIOP for NP with the following features. If $R(x,w)$ is computed by a layered arithmetic circuit of size $s$ and depth $d$ over $\\mathbb{F}$ with $m$ inputs, then there are $\\approx d$ rounds in which the proofs $\\pi\_i$ are vectors over $\\mathbb{F}$ of size $\\approx \\log s$ each, and a single round in which the proof vector of size $\\approx m$. (We use $\\approx$ to hide multiplicative factors that are at most polylogarithmic in $s$.) The verifier makes a constant number of linear queries to each proof and applies a decision predicate of degree 2. The soundness error is $\\approx d/|\\mathbb{F}|$. Furthermore, the verifier’s running time can be made $\\approx d+m$ if the circuit has a _succinct description_ of an appropriate kind. Concretely, the circuit should be _log-space uniform_ in the sense that relevant local information about a gate can be computed in logarithmic space given the gate label. The latter uniformity feature was crucial in the original context of the GKR protocol, namely fast verification of shallow polynomial-size _deterministic_ circuits, with no witness $w$. However, in the context of proof systems for NP (with or without zero knowledge), an LIOP as above is meaningful even for general verification circuits that do not have a succinct description. (Using statement-independent preprocessing, one can still achieve fast online verification even in the non-uniform case.) See [_this blog post_](https://zkproof.org/2020/03/16/sum-checkprotocol/) by Thaler for an exposition of the sum-check protocol and a simplified variant of the GKR protocol based on matrix powering. A more sophisticated related protocol due to [Reingold, Rothblum and Rothblum](https://eccc.weizmann.ac.il/report/2016/061/)  (RRR), which applies to space-bounded computations, can also be cast as a (constant-round) LIOP for NP. See this [high-level overview](http://www.wisdom.weizmann.ac.il/~oded/VO/rrr.pdf)  by Goldreich. The GKR protocol can be optimized to have good concrete efficiency, and as such had a big impact not only on theory-oriented research but also on applied research in the area of verifiable computation. The first step in this direction was taken by [Cormode, Mitzenmacher, and Thaler](https://arxiv.org/abs/1105.2003) , with several subsequent refinements and improvements: see [here](https://ieeexplore.ieee.org/document/6547112) , [here](https://arxiv.org/abs/1304.3812) , and [here](https://eprint.iacr.org/2019/317.pdf) . In particular, for _layered_ arithmetic circuits of depth $d\\ll s$ and witness length $m\\ll s$ over large fields, [Libra](https://eprint.iacr.org/2019/317.pdf) (building on earlier [zero-knowledge sum-check](http://arxiv.org/abs/1704.02086) techniques) obtained a _zero-knowledge variant_ and additionally obtained _constant computational overhead_ on the prover side in the arithmetic setting. This can be compared to the simpler constant-overhead zk-LPCP for NP discussed above, which applies to arbitrary verification circuits (of arbitrary structure, depth, and witness length) but offers no form of succinctness. In the context of efficiently verifying _deterministic_ low-depth computations, variants of the GKR protocol can be used “out of the box” as interactive proofs, without a cryptographic compiler. This was proposed as a practical approach to [verifiable programmable hardware](https://eprint.iacr.org/2017/242) . Alternatively, one can use the Fiat-Shamir heuristic for making such protocols non-interactive. In the context of zero-knowledge proofs for NP, the GKR paper showed how to leverage efficient verification towards “witness-succinct” zero-knowledge proofs for relations $R(x,w)$ with low-depth circuits, namely proofs in which the communication is comparable to the witness length rather than the circuit size. Their transformation from an interactive proof with fast verification to a zero-knowledge proof with low communication relies on a [classical cryptographic compiler](https://link.springer.com/chapter/10.1007\%2F0-387-34799-2_4)  that makes a non-black-box use of a one-way function. It was only much later, sparked by the growing practical interest in succinct proof systems, that the GKR protocol was used to obtain proof systems that break the witness size barrier and have competitive concrete efficiency features for NP-relations. **Cryptographic compilers and Polynomial IOP.** Can we compile an LIOP for NP into a proof system whose communication complexity is comparable to the query complexity of the LIOP? Before answering this question, let us discuss the motivation. For now, consider the GKR-based LIOP. Assume we are in a “GKR-friendly” scenario where $R(x,w)$ is implemented by a layered arithmetic circuit over a large field $\\mathbb{F}$, where $d,m\\ll s$. Compared to both IOP-based and LPCP-based succinct proof systems, we can hope to get better prover computation (linear vs.\\ quasilinear). Compared to IOP-based systems, we can hope to further gain a concrete efficiency advantage by exploiting the “algebraic” nature of the LIOP, which makes the soundness error vanish when $\\mathbb{F}$ grows while the other parameters are fixed. Compared to LPCP-based systems, we can hope to further gain the advantage of being transparent (i.e., not requiring a trusted setup), or at the very least use an SRS whose size is comparable to $m$ rather than $s$. The latter is based on the fact that the total _proof length_ in the GKR-based LIOP is comparable to $m$, as opposed to $s$ in LPCPs. A straightforward compiler that makes a non-black-box use of symmetric cryptography is to have the prover succinctly commit to each proof string using a hash function, and emulate linear queries by using (say, IOP-based) SNARK to prove the consistency of the answers with the commitment. (This approach is non-black-box with respect to the underlying hash function since the NP-statement being argued depends on this hash function.) Note that in the GKR-based LIOP, the short proofs can be sent in the clear, and the expensive non-black-box approach only applies to the longer proof (of size $\\approx m$). This approach can support two of the three potential advantages discussed above: it is transparent, and can have a linear-time prover when $d,m\\ll s$. However, if we use a generic IOP, we cannot hope to gain a succinctness advantage over IOP. Moreover, the non-black-box use of the hash function would lead to a big concrete computational overhead unless the ratio $s/m$ is huge. The key to better cryptographic compilers is the following additional feature of the GKR-based LIOP: Each of the proof vectors $\\pi\_i$ can be viewed as defining the coefficients of a _polynomial_ in a small number of variables, where each linear query to $\\pi\_i$ evaluates the polynomial at a single point. More concretely, the long proof vector in the GKR-based LIOP defines a multilinear polynomial in $\\log m$ variables that encodes $(x,w)$. This can be captured by a more refined notion of LIOP in which a proof is interpreted as the coefficient vector of a polynomial of bounded degree, typically in a small (at most logarithmic) number of variables, and a query is interpreted as an evaluation point. This refinement of LIOP, referred to as [_polynomial IOP_](https://eprint.iacr.org/2019/1229.pdf) (PIOP), is motivated by possibility of cryptographic compilers that take advantage of the extra structure. (Another name for a closely related model is [Algebraic Holographic Proof.](https://eprint.iacr.org/2019/1047) ) Cryptographic compilers for PIOP rely on efficient realizations of _polynomial commitment_, a functional commitment scheme that allows the prover to commit to a polynomial in a way that supports an efficient proof of evaluation on a given point. The first systems that combined the GKR protocol with polynomial commitments were [Hyrax](https://eprint.iacr.org/2017/1132) and [(zk)-vSQL](https://eprint.iacr.org/2017/1145) . Hyrax used a transparent implementation of polynomial commitment based on discrete logarithm at the cost of proof size $\\approx d+\\sqrt{m}$. The vSQL system could eliminate the $\\sqrt{m}$ additive term by using a variant of a widely used polynomial commitment scheme due to [Kate, Zaverucha, and Goldberg](https://link.springer.com/chapter/10.1007\%2F978-3-642-17373-8_11) that relies on a pairing-friendly group and requires a trusted setup. The subsequent [Libra](https://eprint.iacr.org/2019/317.pdf) system combined a similar polynomial commitment with an improved zero-knowledge variant of the GKR-based PIOP. [Virgo](https://eprint.iacr.org/2019/1482.pdf) is a variant of Libra that uses an efficient transparent polynomial commitment based only on symmetric cryptography, combining an IOP based on the FRI protocol with a GKR-based LIOP with $m=O(\\log s)$. A similar kind of polynomial commitment was proposed in [RedShift](https://eprint.iacr.org/2019/1400) . Finally, [Bünz, Fisch, and Szepieniec](https://eprint.iacr.org/2019/1229.pdf)  presented a transparent polynomial commitment scheme with much better succinctness using groups of an unknown order. This comes at the cost of high concrete prover complexity and no post-quantum security. **Fully succinct PIOPs.** Back from cryptographic compilers to information-theoretic proof systems, the GKR-based PIOP has the disadvantage of having query complexity that grows with the circuit depth. (While the circuit depth of $R$ can be generically reduced by adding intermediate computation values to the witness, this would make the GKR protocol inefficient.) A variety of recent proof systems can be cast as being based on PIOPs that have constant or logarithmic round complexity and query complexity. This includes [STARK](https://eprint.iacr.org/2018/046) , [Sonic](https://eprint.iacr.org/2019/099) , [Plonk](https://eprint.iacr.org/2019/953) , [Marlin](https://eprint.iacr.org/2019/1047.pdf) , [Supersonic](https://eprint.iacr.org/2019/1229.pdf) , and [Spartan](https://eprint.iacr.org/2019/550) (building on [Clover](https://eprint.iacr.org/2014/846) , a multi-prover variant of GKR). See Section 5 in the paper of [Bünz et al.](https://eprint.iacr.org/2019/1229.pdf) for a unified overview of these proof system in the language of PIOPs, along with an information-theoretic compiler transforming any “algebraic” LIOP to PIOP. While the resulting proof systems are typically less succinct than the LPCP-based ones described above (either by constant or logarithmic factors), they have weaker setup requirements. Concretely, they are either completely transparent, have a shorter SRS, or have additional desirable features such as a [_universal and updatable_](https://eprint.iacr.org/2018/280)  SRS. **Ideal Linear Commitment.** Polynomial IOP can be viewed as a refinement of Linear IOP, which provides an additional algebraic structure that can be exploited by cryptographic compilers. A different kind of refinement was considered by [Bootle, Cerulli, Ghadafi, Groth, Hajiabadi and Jakobsen](https://eprint.iacr.org/2017/872) under the name _ideal linear commitment_ (ILC) model. A proof in the ILC model can be viewed as an LIOP where each proof vector $\\pi\_i$ is parsed as a _matrix_ $\\Pi\\in\\mathbb{F}^{n\_i\\times m\_i}$, and each query to $\\pi\_i$ is specified by a _vector_ $q\\in\\mathbb{F}^{m\_i}$, returning the matrix-vector product $\\Pi q$. (Alternatively, an ILC can be viewed as a standard LIOP if the underlying field is replaced by a vector space.) Bootle et al. show how to use a collision-resistant hash function to compile an ILC proof system into a public-coin argument in the plain model in which the communication complexity is roughly $\\sum\_i (n\_i+m\_i)$. Instantiated with [linear-time encodable error-correcting codes](https://ieeexplore.ieee.org/document/556668) and with [linear-time computable hash functions](https://eprint.iacr.org/2017/036) , the compiler respects the asymptotic computational complexity of the underlying ILC proof. They also show a construction of constant-overhead “square-root succinct” zk-ILC for the satisfiability of arithmetic circuits. Concretely, for an NP-relation $R(x,w)$ computed by an arithmetic circuit over $\\mathbb{F}$ of size $s$, the communication is $\\approx \\sqrt{s}$, the round complexity is $O(\\log\\log s)$, and both parties can be implemented a RAM program whose running time is dominated by $O(s)$ field operations, where the soundness error is negligible in $\\log|\\mathbb{F}|$. Combining this ILC with a linear-time instantiation of the cryptographic compiler yields (under plausible cryptographic assumptions) a square-root succinct zero-knowledge argument for arithmetic circuit satisfiability with constant computational overhead. This is the third approach we have seen for obtaining a zero-knowledge proof system with constant computational overhead. It has better asymptotic succinctness than the simple LPCP-based approach. It is incomparable to the GKR-based approach: its succinctness is typically worse (unless the circuit is relatively deep), but it achieves constant overhead for arbitrary circuits and witness length. Unlike the other two approaches, the hidden multiplicative constants of the ILC-based system seem quite large, and it is open whether it can be optimized to have competitive concrete efficiency features. Note that all three approaches for zero knowledge with constant computational overhead can only achieve negligible soundness error for _arithmetic_ computations over fields of super-polynomial size. In the parallel RAM model, an approach for amortizing away the (parallel) prover computational overhead, at the cost of a minor increase in the number of processors, was proposed in [this recent work](https://eprint.iacr.org/2020/994.pdf) . However, when considering the standard metric of Boolean circuit size or (sequential) running time on a RAM machine, constant-overhead zero knowledge is still wide open, and there are no candidate constructions under any cryptographic assumption. ### Fully linear proof systems and distributed zero-knowledge proofs All proof systems considered so far assume that the verifier has full access to the input statement $x$. But there are situations in which this is not the case. For instance, the input can be partitioned between two or more parties (e.g., banks or hospitals), or secret-shared using a linear secret-sharing scheme. In these distributed settings, it is still possible to efficiently make a linear query to the input by _locally_ applying a linear query to each part of the input. Linear queries to the input are also possible when the input is hidden using a linearly-homomorphic encryption or commitment scheme. The above settings naturally call for a stronger variant of the LPCP and LIOP models in which linear queries apply _jointly_ to an input $x\\in \\mathbb{F}^n$ and a proof $\\pi\\in\\mathbb{F}^m$, where the verifier has no direct access to the input except via such queries. Information-theoretic proof systems of this kind were studied in a recent joint work with [Boneh, Boyle, Corrigan-Gibbs, and Gilboa](https://eprint.iacr.org/2019/188) under the name _fully linear_ proof systems, but are implicit in many previous works. In the zero-knowledge version, the simulator does not get access to the input $x$, capturing the requirement that the verifier learn _nothing about $x$ and $w$_ except for the fact that $x\\in L$ (compared to only hiding $w$ in the usual definition). The limited access to the input makes fully linear proof system with low query complexity meaningful even for polynomial-time languages, and even if P $=$ NP. This is akin to [_proofs of proximity_](https://eccc.weizmann.ac.il//eccc-reports/2004/TR04-021/index.html) , except that the latter only give the weaker guarantee that the input is _close_ to being in $L$, and is also closely related to [_holographic proofs_](https://lance.fortnow.com/papers/files/check.pdf)  in which the verifier can query a suitable encoding of the input. Fully linear proof systems are motivated by the goal of efficient _distributed zero-knowledge_ proofs, namely ones in which the input statement $x$ is known to the prover but is distributed between two or more verifiers. (This should not be confused with other kinds of distributed zero-knowledge proofs, such as [this](https://eprint.iacr.org/2018/691.pdf) one.) Indeed, by having the prover secret-share each proof vector, a fully linear proof system [can be compiled](https://eprint.iacr.org/2019/188) into a distributed zero-knowledge proof in which the communication complexity is dominated by the total length of the _proofs_ and the _answers_ to the linear queries. This is contrasted with previous cryptographic compilers in which the proof length did not influence communication, since proofs could be “compressed” by hashing or homomorphic encryption. Moreover, the compilers for distributed zero knowledge can be information-theoretic, and do not take advantage of the additional structure offered by polynomial IOPs or the low algebraic degree of the verifier’s decision predicate. Given the above, a natural goal is to design fully linear PCPs and IOPs (abbreviated as FLPCPs and FLIOPs) in which the proof length and query complexity are both _sublinear in the input length_. This goal is well-motivated even for simple languages $L\\subseteq \\mathbb{F}^n$. To give two concrete examples, consider the the inner-product language $L\_1$ consisting of concatenations of pairs of vectors in $\\mathbb{F}^{n/2}$ whose inner product is 0, or the language of binary vectors $L\_2=\\{0,1\\}^n$. It turns out that the concrete LPCP and LIOP discussed above can be made fully linear with the same number of queries. However, whereas the proof length of the Hadamard LPCP and the LPCP of GGPR is at least linear in $n$, the [GKR protocol](https://eccc.weizmann.ac.il/report/2017/108/) yields an FLIOP whose total proof and answer length is comparable to the circuit _depth_, or $O(\\log^2n)$ for the above examples, with a similar number of rounds. Similarly, the [RRR protocol](https://eccc.weizmann.ac.il/report/2016/061/)  implies constant-round sublinear FLIOPs for low-space computations. For languages that are recognized by low-degree polynomials, as in the above examples, there are [simpler and more efficient](https://eprint.iacr.org/2019/188) fully linear proof systems. For instance, there is a (non-interactive) zk-FLPCP for proving that $x$ satisfies a single degree-2 equation (as in $L\_1$ above) with a proof of size $O(\\sqrt{n})$ and a similar number of queries, which [can be shown](https://arxiv.org/abs/cs/0208006) to be optimal. This protocol is a zero-knowledge variant of a communication complexity upper bound of [Aaronson and Wigderson](https://eccc.weizmann.ac.il//eccc-reports/2008/TR08-005/index.html) . For languages recognized by systems of constant-degree equations (including both of the above examples), the proof size and query complexity can be reduced to $O(\\log n)$ at the cost of settling for zk-FLIOP with $O(\\log n)$ rounds of interaction. These constructions start with a generalization of a GGPR-style zk-LPCP that takes advantage of repeated structures, and then improve its efficiency via balancing and recursion. As already mentioned, fully linear proof systems are motivated by the goal of distributed zero-knowledge proofs. Such proofs were implicitly used for verifiable private data aggregation in the [Prio](https://www.usenix.org/system/files/conference/nsdi17/nsdi17-corrigan-gibbs.pdf) system and also for [verifiable function secret sharing](https://eprint.iacr.org/2018/707) . In the context of efficient interactive proofs (without zero knowledge) for distributed graph problems, fully linear IOPs were implicitly used in the work of [Naor, Parter, and Yogev](https://eccc.weizmann.ac.il/report/2018/213/)  to improve on previous results along this line. **A distributed GMW-style compiler.** I would like to conclude this section by revisiting a powerful and beautiful application of zero-knowledge proofs: enforcing honest behavior in general cryptographic protocols. A paper of [Goldreich, Micali, and Wigderson](https://dl.acm.org/doi/10.1145/28395.28420) established the feasibility of general secure computation protocols via the following two-step approach: (1) design a protocol that offers security against _honest-but-curious_ parties, who send messages as prescribed by the protocol but try to obtain additional information from messages they receive; (2) apply a _general compiler_ based on zero-knowledge proofs to enforce an honest behavior. The compiler, commonly referred to as the _GMW compiler_, requires parties to prove that they “stick to the protocol,” namely send out the correct messages given messages they already received. Zero knowledge is necessary here because the correctness of messages is an NP-statement involving the secret input and randomness that cannot be revealed. A limitation of the GMW compiler is that it only applies to protocols over a _public_ broadcast channel, since otherwise the NP-statement (which includes the messages) is not fully known to the verifiers. Distributed zero-knowledge proofs allow for GMW-style compilers that apply to protocols over _secure point-to-point_ channels. Such channels are necessary for secure computation protocols with _information-theoretic security_ in the _honest majority_ setting. Alternatively, protocols in this setting can use symmetric cryptography for better concrete efficiency. It turns out that in natural protocols of this type, it suffices to prove in zero knowledge distributed statements that can be verified by degree-2 polynomials. In particular, one can apply the efficient zk-FLIOP discussed above to protect such protocols against malicious parties with sublinear additive communication cost over the best “baseline” protocols that have security against honest-but-curious parties. See [here](https://eprint.iacr.org/2019/188) , [here](https://eprint.iacr.org/2019/1390) , and [here](https://link.springer.com/chapter/10.1007\%2F978-3-030-56880-1_22)  for applications of distributed zero-knowledge proofs to efficient honest-majority secure computation. Conclusion ---------- We discussed a modular approach for constructing zero-knowledge or succinct proof systems by combining an idealized _information-theoretic proof system_, such as the different kinds of PCPs and IOPs discussed above, with a _cryptographic compiler_. Information-theoretic proof systems can be crudely divided into four categories depending on whether interaction and linear queries are allowed. Linear queries help simplify proof systems and make them more succinct, but their cryptographic compilers typically result in strong setup requirements, heavy use of “public-key” cryptography, and no post-quantum security. Allowing interaction contributes to simplicity and lower prover complexity, typically at the cost of suboptimal succinctness. We demonstrated that a large portion of the work on efficient proof systems can be cast in this modular framework. Are PCPs necessary? [Rothblum and Vadhan](https://eccc.weizmann.ac.il/report/2009/089/) gave evidence in this direction, showing that computationally sound proof systems which make a “black-box” use of certain cryptographic primitives imply PCPs with related efficiency. But regardless of the extent to which such a converse direction holds, there are other potential approaches to the design of efficient proof systems that do not naturally fit into the current taxonomy. We list below some of the approaches to efficient proof systems we did not cover in this survey. **Zero knowledge from garbling.** [Jawurek, Kerschbaum, and Orlandi](https://eprint.iacr.org/2013/073) showed how to build concretely efficient zero-knowledge proofs from Yao’s garbled circuit construction. In fact, relaxed forms of garbling schemes (known as [_privacy-free_](https://eprint.iacr.org/2014/598) or [_partial_](https://eprint.iacr.org/2014/995) garbling, which are closely related to [_conditional disclosure of secrets_](https://www.sciencedirect.com/science/article/pii/S0022000099916896?via\%3Dihub) ) suffice for this purpose. While this approach has several limitations, [recent advances](https://eprint.iacr.org/2020/136)  in garbling techniques make it competitive for some use cases. More applications may be found in the future. **Discrete-log based proof systems.** We did not cover many proof systems from the literature that are based on discrete-log type assumptions. This includes a wide array of well-known protocols, originating from classical ones due to [Schnorr](https://link.springer.com/content/pdf/10.1007/BF00196725.pdf) , [Guillou-Quisquater](https://doi.org/10.1007/3-540-45961-8_11) , and [Cramer-Damgård](https://link.springer.com/chapter/10.1007\%2FBFb0055745) , via the pairing-based NIZK protocols of [Groth-Ostrovsky-Sahai](https://eprint.iacr.org/2005/290) and [Groth-Sahai](https://eprint.iacr.org/2007/155) , to popular recent zk-SNARKs such as [Bulletproofs](https://eprint.iacr.org/2017/1066) . See [here](https://discovery.ucl.ac.uk/id/eprint/10079416/1/Bootle_000_Thesis.pdf) and [here](https://eprint.iacr.org/2020/152) for progress on a unified treatment of such protocols and [here](https://eprint.iacr.org/2020/737) for a recent lattice-based analogue. It remains to be seen if these protocols can be _naturally_ cast as applying a general compiler to a suitable kind of PCP. **Multi-prover proof systems.** The pioneering work of [Ben-Or, Goldwasser, Kilian, and Wigderson](https://dl.acm.org/doi/10.1145/3335741.3335758) showed that information-theoretic zero-knowledge proofs are possible in a model where there are two or more potentially malicious but _non-colluding_ provers. This work has led to a systematic study of the power of multi-prover proof systems and PCPs, which culminated in the PCP theorem and gave rise to other influential results such as the [parallel repetition theorem](http://www.wisdom.weizmann.ac.il/~ranraz/publications/Pparal1.ps) . Multi-prover proof systems are closely related to the kinds of information-theoretic proof systems discussed in this survey. In particular, [practical](https://eprint.iacr.org/2014/846) proof systems in this model were [later](https://eprint.iacr.org/2019/550) cast as polynomial IOPs. A 2-prover zero-knowledge proof protocol in which one of the provers is _stateless_ can be viewed as an interactive zk-PCP in which the proof oracle $\\pi$ is succinctly represented by a circuit. This model gives rise to information-theoretic zero-knowledge proofs for NP using [untrusted tamper-proof hardware](https://eprint.iacr.org/2010/089.pdf) (with efficient provers), or [even for NEXP](https://eprint.iacr.org/2017/305) (with inefficient provers). An [alternative multi-prover model](https://dl.acm.org/doi/10.1145/258533.258644) is one both soundness and completeness hold as long as at least one prover is honest. [Canetti, Riva, and Rothblum](https://www.sciencedirect.com/science/article/pii/S0890540113000217?via\%3Dihub) showed that this type of “refereed” proof systems enable lightweight verification of computations using collision-resistant hash functions without any kind of nontrivial PCP machinery. **Proof composition.** It is sometimes useful to apply one proof system for “proving the knowledge of a proof” in another. This can be used to enhance efficiency via [bootstrapping](https://eprint.iacr.org/2012/095) , as in Valiant’s notion of [incrementally verifiable computation](https://link.springer.com/chapter/10.1007\%2F978-3-540-78524-8_1) or its extension to [proof-carrying data](https://conference.iiis.tsinghua.edu.cn/ICS2010/content/papers/25.html) . It can also be used for “best-of-both-worlds” combinations of different proof systems, say one with a fast prover but only partial succinctness and one with a slower prover but better succinctness. The overhead of proof composition can be reduced via [new instances](https://eprint.iacr.org/2019/458.pdf) of cryptographic hash functions that optimize relevant complexity measures. A [different kind](https://eprint.iacr.org/2019/142.pdf) of proof composition makes a black-box use of succinct commitments as a common interface between different proof systems. It is likely that in the future we will see more hybrid proof systems that combine the advantages of the different approaches presented here. To conclude, we discussed many different techniques for constructing zero-knowledge and succinct proof systems. These give rise to an enormous design space in which different instances often have incomparable features. The modular approach we survey here can help navigate this space in a systematic way, helping identify efficiency bottlenecks and opportunities for further improvement. ### Acknowledgements I would like to thank Daniel Benarroch and Yau Benor for inviting this blog post and waiting patiently for its arrival, Daniel for a lot of help along the way, Oded Goldreich for his encouragement to write a different but related survey, and Ron Rothblum for many helpful discussions and comments. [Education](https://zkproof.org/tag/education/) [Tech](https://zkproof.org/tag/tech/) [Zero-knowledge proofs](https://zkproof.org/tag/zero-knowledge-proofs/) * * * ![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=240&d=identicon&r=g) ##### [Yuval Ishai](https://zkproof.org/author/yuvalishai/ "Yuval Ishai post page") [All author posts](https://zkproof.org/author/yuvalishai/ "Yuval Ishai post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2020/10/15/information-theoretic-proof-systems-part-ii/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Zero-Knowledge Proofs from Information-Theoretic Proof Systems - Part I - ZKProof Standards Zero-Knowledge Proofs from Information-Theoretic Proof Systems - Part I ======================================================================= August 12, 2020 |In [The Art of Zero Knowledge](https://zkproof.org/category/the-art-of-zero-knowledge/ "View all posts in The Art of Zero Knowledge") |By [Yuval Ishai](https://zkproof.org/author/yuvalishai/) In this two-part extended blog post I will discuss a modular approach to the design of efficient zero-knowledge proof systems that aims at maximizing the separation between the “information-theoretic” and the “cryptographic” ingredients. While this approach is already practiced, it could arguably be applied more often and more systematically. The post is loosely based on recent talks I gave, including one at the [2nd ZKProof Workshop](https://www.youtube.com/watch?v=fqlrJUOT8Po&list=PLOEty2U8Y69VKX0THZvO_liqwV3Ngf1wt&index=20&t=0s) . Shorter expositions of this kind can be found in Section 2 of the [ZKProof Community Reference document](https://docs.zkproof.org/assets/docs/reference-v0.2.pdf) , Section 2 of the [BBCGI19 paper](https://eprint.iacr.org/2019/188.pdf) and Section 5 of the [BunzFS20 paper](https://eprint.iacr.org/2019/1229.pdf) . Motivation ---------- The growing number of competing proposals for practical zero-knowledge and/or succinct proof systems makes it easy to get confused about how these different systems compare to each other. One reason such comparisons are difficult is the multitude of application scenarios, implementation details, efficiency desiderata, cryptographic assumptions, and trust models. To make things worse, such systems are typically offered as a “package deal” that makes it difficult to apply a mix-and-match approach for finding the best combination of the underlying ideas in the context of a given application. This calls for a modular approach that allows for an easier navigation in the huge design space. A higher level of modularity and abstraction is useful for capturing technical ideas in a way that makes them more broadly applicable, beyond the setting in which they were originally introduced. This can help us avoid reinvention of the same ideas in related contexts. **Guide to readers.** The current post will survey a specific modular approach, which covers many of the techniques that underlie modern proof systems. It does not intend to fully cover the current state of the art, which is a rapidly moving target. Instead, it mainly aims to suggest common principles and clean abstractions that can apply to a wide variety of proof systems, including ones that are not mainstream today but may become more popular in the future. This post is meant for readers with diverse backgrounds. Those who already have a good familiarity with the theory of zero-knowledge proofs may be better off skipping the next background section. Then, in this first part of the post, I will discuss the simplest kind of information-theoretic zero-knowledge proof systems, how to use cryptography to compile such systems into zero-knowledge proof protocols, and how to construct such systems from protocols for secure multiparty computation. Relaxed kinds of information-theoretic proof systems that lead to better succinctness will be discussed in the forthcoming second part of this post. Background ---------- To make the post relatively self-contained, I would like to give some background on the kinds of zero-knowledge proof systems we will be interested in. I will also give a high-level overview of theoretical research in this area that provides the foundations, as well as a useful toolbox, for the recent practice-oriented research. ### Definition The goal of a zero-knowledge proof is specified by an NP-relation $R(x,w)$, where $x$ is referred to as a _statement_ (or sometimes an _input_) and $w$ as a _witness_. A zero-knowledge proof for $R$ is a protocol that specifies the rules for an interaction between a prover and a verifier, both of which run in polynomial time and can toss coins. The prover and the verifier share a statement $x$ as common input, and the prover additionally knows a witness $w$ such that $(x,w)\\in R$. One can think of $w$ as a “classical proof” that the statement $x$ is in the language $L=\\{ x\\,:\\, \\exists w \\, (x,w)\\in R\\}$. However, instead of simply sending $w$ to the verifier, the prover would like to convince the verifier that $x\\in L$ without revealing information about $w$. A zero-knowledge proof protocol for $R$ should satisfy the following, loosely stated, requirements: * **Completeness:** If $(x,w)\\in R$, then in the end of the interaction the verifier always accepts. * **Soundness:** If $x\\not\\in L$ (namely, there is no $w$ such that $(x,w)\\in R$), then the verifier rejects except for a small probability, called the _soundness error_. This holds even when the prover is malicious and can deviate arbitrarily from the protocol. * **Zero knowledge:** The view of a verifier interacting with the honest prover on input $(x,w)\\in R$ can be efficiently simulated based on $x$ alone. By default, this is required to hold for any efficient malicious verifier. An _honest-verifier_ zero-knowledge proof is one where this is only required to hold for the honest verifier. This informal definition leaves some details unspecified, such as the allowable running times of a malicious prover and the quality of the simulation. It also ignores composition-related issues. See Chapter 4 of [Goldreich’s textbook](http://www.wisdom.weizmann.ac.il/~oded/foc-vol1.html) for a more rigorous treatment. ### Variants There are several important variations and extra features that will play a role in the following. **Proofs vs. arguments.** The [original notion](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.419.8132&rep=rep1&type=pdf) of zero-knowledge proofs requires soundness to hold against _computationally unbounded_ malicious provers. However, it is often useful to consider proof systems whose soundness is restricted to hold only against _efficient_ (e.g., polynomial-time) provers. Such [computationally sound proof systems](https://www.researchgate.net/publication/2451591_All-or_Nothing_Disclosure_of_Secrets) are often referred to as _arguments_. Here I will typically ignore this distinction and use the term “proof” even in the case of computational soundness. **Proofs of knowledge.** The soundness requirement is often replaced by a stronger _proof of knowledge_ requirement, which captures the intuitive property that any prover who can convince the verifier of the truth of a statement $x$ (with better probability than the soundness error) must “know” a valid witness $w$ such that $R(x,w)$ holds. Here we will mainly focus on the simpler soundness requirement, though the concrete proof systems discussed below will in fact be proofs of knowledge. **Non-interactive proofs.** A particularly appealing type of proof system is a _non-interactive_ zero-knowledge (NIZK) proof, in which the protocol involves a single message from the prover to the verifier. This message may depend on a _common reference string_ (CRS) that can either be _uniformly random_ (URS) or _structured_ (SRS). Here a long CRS can be generated together with a short verification key to speed up verification, and the zero-knowledge simulator is allowed to generate the reference string together with the simulated proof. Whereas there are simple (but unproven) heuristics for generating a URS without a trusted setup and without compromising security, there are no similar heuristics for generating an SRS. Instead, the SRS is typically generated using a large-scale secure multiparty computation protocol, a process sometimes referred to as an “[MPC ceremony](https://z.cash/technology/paramgen/) .” A powerful technique for converting interactive proof systems into non-interactive ones is the [_Fiat-Shamir transform_](https://link.springer.com/chapter/10.1007\%2F3-540-47721-7_12) . This technique applies to the class of _public-coin_ protocols, where the verifier’s role is restricted to generating and sending random messages, and essentially amounts to having the prover generate each verifier’s message by applying a hash function to the protocol’s transcript up to this message. While the security of the transformation can be proved in the [random oracle model](https://dl.acm.org/doi/10.1145/168588.168596) , which models the hash function as a perfectly random function, when instantiated with real hash functions the security becomes heuristic. An advantage of such non-interactive proof systems is that they are _transparent_ in the sense that they avoid the need for a trusted setup by only requiring a URS, which can be eliminated in practice. See “state of the art” below for further discussion. **Designated-verifier proofs.** The NIZK protocols discussed above have the appealing feature of being _publicly verifiable_, as the verifier has no secret state. An alternative setting is that of a [_designated-verifier_](https://ieeexplore.ieee.org/document/63521) NIZK, in which the CRS is a public key that corresponds to a secret verification key owned by the designated verifier, and can typically be securely generated by the verifier alone. Proofs generated using this public key can only be verified by the designated verifier. An even more liberal setting is that of NIZK with a correlated randomness setup (sometimes referred to as _preprocessing NIZK_). In this setting, a designated verifier and a designated prover share a pair $(k\_P,k\_V)$ of correlated secret keys. Proofs can be generated using $k\_P$ and verified using $k\_V$. **Succinct proofs.** A final and very important goal in the design of proof systems is optimizing their _efficiency_. Here the main focus is on two efficiency measures that are typically (but [not always](https://eprint.iacr.org/2017/1066.pdf) ) correlated: _communication_ and _verifier’s computation_. Optimizing these measures is meaningful even for proof systems _without_ the zero knowledge property. The baseline is the simple “classical” proof system in which the prover sends $w$ to the verifier, who checks that $R(x,w)$ indeed holds. This may be unsatisfactory in terms of both communication complexity and verifier’s running time. A _succinct_ proof system is one that has better communication complexity. The term “succinct” is typically also associated with fast verification, requiring that the verifier’s running time be smaller than the time required for computing $R$, possibly given preprocessing that may depend on $R$ but not on the statement $x$. Here we will use this term to refer only to low communication complexity by default. The term _succinct non-interactive argument_, commonly abbreviated as [SNARG](https://eprint.iacr.org/2010/610.pdf) , refers to a non-interactive, computationally sound proof system that satisfies the succinctness requirement. A zk-SNARG additionally satisfies _zero knowledge_, and a [_(zk-)SNARK_](https://eprint.iacr.org/2014/580) additionally has the _proof of knowledge_ property. As most succinct proof systems can be modified to realize the extra zero knowledge requirement with little extra cost, we will assume by default that all proof systems are zero knowledge even when we do not say it explicitly. However, most of this post is relevant also to succinct proof systems without zero knowledge. Finally, while we will mostly ignore here the proof of knowledge property, it is satisfied by almost all known proof systems, sometimes under stronger assumptions, and is important for many applications. ### State of the art What do we know about the _existence_ of zero-knowledge proofs for general NP-relations? Let me briefly summarize where we stand from a crude “feasibility” standpoint. More refined efficiency issues will be discussed later. Shortly after the introduction of zero-knowledge proofs by [Goldwasser, Micali, and Rackoff](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.419.8132&rep=rep1&type=pdf) in the mid-1980s, the first general construction was given by [Goldreich, Micali, and Wigderson](https://www.researchgate.net/publication/220431215_Proofs_that_Yield_Nothing_But_Their_Validity_for_All_Languages_in_NP_Have_Zero-Knowledge_Proof_Systems) (see also Chapter 4 of [Goldreich’s texbook](http://www.wisdom.weizmann.ac.il/~oded/foc-vol1.html) ). This construction, which will be described below, can use any cryptographic commitment scheme, which in turn can be based on one-way functions. On the other hand, [Ostrovsky and Wigderson](https://www.math.ias.edu/~avi/PUBLICATIONS/MYPAPERS/OW93/paper.pdf) showed that a weak flavor of one-way functions is also necessary for non-trivial zero-knowledge. This means that a (very mild) cryptographic assumption is necessary and sufficient for the existence of general zero-knowledge proofs. In the non-interactive setting, all current protocols require much stronger cryptographic assumptions. Originating from the work of [Blum, Feldman, and Micali](https://dl.acm.org/doi/10.1145/62212.62222) that introduced NIZK proofs, there has been a large body of work on diversifying these assumptions. This is an active area of research with some exciting recent results: see [here](https://dl.acm.org/doi/10.1145/3313276.3316380) , and [here](https://eprint.iacr.org/2019/158) , and [here](https://eprint.iacr.org/2020/258) . At this point in time, NIZK proofs for NP can be based on most of the standard cryptographic assumptions that are known to imply _public-key_ encryption. Notable exceptions are assumptions related to the discrete logarithm problem. The above state of the art is good, since it gives us a high degree of confidence that general NIZK protocols do exist. But it also leaves a gap between the current “provable” constructions and ones that rely on instantiating the Fiat-Shamir transform. It is commonly believed that this heuristic is good enough for practical proof systems and hash functions that were not designed to defeat it. This holds even with hash functions that are not known to imply public-key cryptography. However, we do not have good evidence in this direction, and there are [negative results](https://eprint.iacr.org/1998/011) that rule out a generic approach for instantiating a random oracle with a concrete hash function, even in the [specific context](https://eprint.iacr.org/2003/034) of the Fiat-Shamir transform (when applied to _arguments_ rather than proofs). See [this](https://dl.acm.org/doi/10.1145/3313276.3316380) and [this](https://eprint.iacr.org/2019/997) recent works for a survey of this direction. Understanding the minimal cryptographic assumptions that suffice for NIZK is an intriguing question that will surely generate a lot of interesting future research. For _succinct_ proof systems, the state of provable constructions is considerably worse. Things are not too bad in the interactive setting, where collision-resistant hash functions [suffice](https://doi.org/10.1145/129712.129782) for obtaining succinct proof systems for NP. (This is considered a standard and mild cryptographic assumption, albeit [stronger](https://link.springer.com/chapter/10.1007\%2FBFb0054137) than one-way functions that suffice for non-succinct zero-knowledge proofs.) In the non-interactive setting, all known constructions are either cast in idealized models (such as the [_random oracle model_](https://epubs.siam.org/doi/10.1137/S0097539795284959) or the [_generic group model_](https://link.springer.com/chapter/10.1007\%2F978-3-642-17373-8_19) ) or alternatively are based on strong [“extractability”](https://eprint.iacr.org/2014/580) assumptions such as [knowledge-of-exponent](https://www.degruyter.com/view/j/jmc.2008.2.issue-4/jmc.2008.016/jmc.2008.016.xml) assumptions. The latter seem [hard to validate](https://link.springer.com/content/pdf/10.1007/978-3-540-45146-4_6.pdf) and are in [some cases](https://eprint.iacr.org/2014/402) likely to be false. The [_algebraic group model_](https://eprint.iacr.org/2017/620.pdf) is a weaker version of the generic group model that can [potentially be instantiated](https://eprint.iacr.org/2020/070) and may serve as a cleaner substitute to concrete extractability assumptions. Can SNARGs be based on standard cryptographic assumptions? [Gentry and Wichs](https://eprint.iacr.org/2010/610) gave negative evidence that effectively serves as a barrier. They showed that, in some well-defined sense, “standard” assumptions and proof techniques cannot imply SNARGs with _adaptive soundness_, namely soundness that holds even when the statement can depend on the CRS. The goal of basing different flavors of SNARGs on standard cryptographic assumptions remains an important challenge in the theory of cryptography. Progress on this question is likely to require new techniques that have benefits beyond the goal of provable security. See [here](https://eccc.weizmann.ac.il/report/2013/183/) , [here](https://eprint.iacr.org/2017/903) , [here](https://doi.org/10.1145/3188745.3188924) , and [here](https://eprint.iacr.org/2019/603) for a very partial sample of results along this line. Factoring out cryptography -------------------------- This post is about separating the “cryptographic” part of a proof system from the “information-theoretic” part. Before switching to a more abstract level, let me put this in the context of practical zero-knowledge proof systems. Such systems are often divided into two parts: (1) a “front-end” compiler converting a specification of an NP-relation $R$ (e.g., using a C program) into a “zero-knowledge friendly” representation $\\hat R$ (such as an [arithmetic circuit or a rank-1 constraint system — R1CS](https://docs.zkproof.org/pages/reference/reference.pdf) ); (2) a “back-end” compiler converting $\\hat R$ to a zero-knowledge proof protocol for $R$. The two components are related in that the zero-knowledge friendly representation is tailored to the back-end compiler. Here we will not consider front-end compilers. Instead, we are interested in further breaking the back-end compiler into two parts: (2a) converting $\\hat R$ into a (zero-knowledge) _information-theoretic proof system_ for $R$, and (2b) using a _cryptographic compiler_ for converting the information-theoretic proof system into a usable zero-knowledge proof protocol for $R$. Let me explain what each part means. **Information-theoretic proof system.** Such a proof system, sometimes referred to as a _probabilistically checkable proof_ (PCP), is information-theoretic in the sense that it provides soundness and zero knowledge guarantees even when the prover and the verifier are _computationally unbounded_. To make this possible, the proof system can make idealized assumptions that are difficult to enforce via direct interaction. For instance, it may allow the prover to generate a long proof vector and then only grant the verifier _restricted access_ to this vector, where the access pattern is _independent_ of the proof. Enforcing this restricted access via direct interaction is outside the scope of an information-theoretic proof system. (The classical notion of [interactive proofs](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.419.8132&rep=rep1&type=pdf) does not make any idealized assumptions; however such proofs are much weaker than the information-theoretic proof systems considered in this work.) The idealized assumptions typically make information-theoretic proof systems useless as standalone objects. On the other hand, they allow us to construct them _unconditionally_, without relying on cryptographic assumptions. We will discuss several kinds of information-theoretic proof systems with incomparable features. The different kinds of proof systems vary in the restrictions they impose on the verifier’s access to the proof and the amount of interaction. We will also discuss _information-theoretic compilers_ that convert one type of information-theoretic proof system into another. **Cryptographic compiler.** The cryptographic compiler removes the idealized assumptions that underly the information-theoretic proof system by transforming it into a protocol that involves direct interaction between the prover and the verifier. This is done by using cryptographic primitives, such as a collision-resistant hash function, or alternatively idealized primitives that replace them, such as a random oracle or a generic bilinear group. Both types of primitives may come with some (possibly heuristic) concrete instantiation, such as a concrete hash function or pairing-friendly elliptic curve. Unlike the underlying information-theoretic proof system, the protocol obtained by the cryptographic compiler is only secure with respect to a _computationally bounded_ prover and/or verifier. This security will typically be based on a cryptographic assumption. A possible exception is when using idealized primitives. In this case, security can be unconditional, but it is still computational in the sense that it bounds the number of queries (or “oracle calls”) made to the primitive. The cryptographic compiler may also provide extra desirable properties, such as eliminating interaction, shrinking the size of some of the messages, or even adding a zero knowledge feature to an information-theoretic proof system that doesn’t have it. **Advantages of the separation.** Separating information-theoretic proof systems from cryptographic compilers can serve multiple purposes. It makes protocol design conceptually simpler by breaking it into two modular parts, where each part can be analyzed, optimized, and implemented separately. This facilitates a systematic exploration of the design space in search of the best solution for the task at hand. It enables useful mixing and matching of different instantiations of the two components. For instance, the same information-theoretic proof system can be paired with different cryptographic compilers to give useful tradeoffs between efficiency, security, and setup assumptions. This makes it easier to port technical insights and optimization ideas between different types of proof systems. Finally, information-theoretic proof systems serve as cleaner objects of study than their computationally secure counterparts. In particular, they are better targets for lower bound efforts, which can lead to new insights that often result in better upper bounds. Example: Zero-knowledge proof for Graph 3-Coloring -------------------------------------------------------- To illustrate the above modular approach, let’s revisit the [first construction](https://www.researchgate.net/publication/220431215_Proofs_that_Yield_Nothing_But_Their_Validity_for_All_Languages_in_NP_Have_Zero-Knowledge_Proof_Systems) of a zero-knowledge proof system for NP. **The 3-coloring problem.** The proof system is described for the specific 3-coloring relation $R\_{\\sf 3COL}$, where the statement is an undirected graph $G=(V,E)$, the witness is a mapping $c:V\\to\\{1,2,3\\}$ specifying a coloring of each node by one of three colors, and $R$ tests whether the coloring is valid. Concretely, $(G,c)\\in R\_{\\sf 3COL}$ if $c(u)\\neq c(v)$ whenever $(u,v)\\in E$. The relation $R\_{\\sf 3COL}$ corresponds to the _NP-complete_ problem of deciding whether a graph $G$ is 3-colorable. This implies that a zero-knowledge proof for any NP-relation $R$ can be obtained from a zero-knowledge proof for $R\_{\\sf 3COL}$ by having the prover and the verifier locally apply a polynomial-time reduction to convert their inputs for $R$ into inputs for $R\_{\\sf 3COL}$. **The protocol.** The zero-knowledge proof for $R\_{\\sf 3COL}$ proceeds as follows. * The prover, on input $(G,c)$, picks a random permutation $\\phi:\\{1,2,3\\}\\to\\{1,2,3\\}$ defining a random shuffle of the colors, and lets $c'(v)=\\phi(c(v))$ be the shuffled coloring. * The prover and the verifier engage in $|V|$ instances of a cryptographic commitment protocol, in which the prover commits to the shuffled color $c'(v)$ of each node $v$. Such a commitment protocol is a digital analogue of a locked box: it hides the committed value from a computationally bounded verifier (even a malicious one) and it binds the prover to at most one value $c^\*(v)$ that can be later opened and accepted by the verifier. (A malicious prover can choose the $|V|$ values $c^\*(v)$ arbitrarily.) A 2-message commitment protocol can be [based](https://doi.org/10.1007/BF00196774) on any one-way function, and a non-interactive one on any _injective_ one-way function. * The verifier picks a uniformly random edge $(u,v)\\in E$ and sends $(u,v)$ as a challenge to the prover. * The prover opens the commitments to $c'(u)$ and $c'(v)$. * The verifier accepts $G$ if the prover successfully opens the two commitments and they contain different values in $\\{1,2,3\\}$. **Analysis.** The above protocol satisfies the completeness property, since if the coloring $c$ is valid then so is its permuted version $c’$, and so an honest prover will always successfully open two distinct colors in $c’$. It intuitively satisfies the zero knowledge requirement because the only colors not hidden by the commitments are the opened colors $(c'(u),c'(v))$, which can be simulated by choosing two _distinct but otherwise random_ colors. Note that this holds even for a malicious verifier, who can choose $u$ and $v$ arbitrarily, assuming that the prover checks that the pair $(u,v)$ sent by the verifier is indeed a valid edge; this check is necessary, since otherwise the verifier can learn whether the two (disconnected) nodes $u$ and $v$ have the same color in $c$. The simulation is easy to formalize if commitments are implemented by a physical locked box, but is considerably more subtle when using a computationally hiding cryptographic commitment scheme. Finally, soundness can be argued as follows. if $G$ does not admit a valid coloring, then no matter which colors $c^\*$ are committed to by a malicious prover, there is at least one edge $(u,v)\\in E$ that will satisfy $c^\*(u)=c^\*(v)$. It follows that the verifier will reject the proof with at least $1/|E|$ probability. This poor level of soundness can be amplified, while preserving zero knowledge, by running the protocol many times independently. Concretely, with $k\\cdot |E|$ repetitions, the probability of the prover getting lucky in all instances drops to roughly $e^{-k}$ for $e\\approx 2.7$. **An abstraction?** The above protocol, while simple and elegant, leaves much to be desired in terms of efficiency. There are two sources of overhead. The first is a Cook-Levin reduction from a “useful” NP-relation $R$ (say, the satisfiability of a Boolean or arithmetic circuit) to $R\_{\\sf 3COL}$. The second is the overhead of amplifying soundness, which grows linearly with $|E|$. Even in terms of simplicity, while the analysis of the protocol is quite straightforward when using ideal commitments, this is not the case when using their cryptographic implementation. Should this analysis be redone from scratch for a similar protocol based on a different NP-complete problem, say [graph Hamiltonicity](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.469.9048&rep=rep1&type=pdf) ? Abstraction can be helpful towards addressing both issues. Zero-knowledge PCPs and their cryptographic compilers ----------------------------------------------------------- The combinatorial core of the above protocol can be abstracted by a simple kind of information-theoretic proof system that I will refer to as a _zero-knowledge probabilistically checkable proof_ (zk-PCP). (Here I am using this term to refer to a specific, arguably the simplest, flavor; other flavors of zk-PCP will be discussed later.) In a zk-PCP for an NP-relation $R$, the prover computes a probabilistic polynomial time mapping from a statement-witness pair $(x,w)$ to a proof string $\\pi\\in\\Sigma^m$. In the above example, $\\pi$ is a string of length $m=|V|$ over $\\Sigma=\\{1,2,3\\}$ comprised of the values $c'(v)$ for $v\\in V$, where the randomness is over the permutation $\\phi$ used to convert $c$ into $c’$. The verifier decides whether to accept or reject by querying a randomly chosen subset of the symbols of $\\pi$. More concretely, the verifier’s algorithm is specified by a randomized mapping from an instance $x$ to a subset $Q\\subset\[m\]$ of queried symbols, and a decision predicate $D(x,Q,\\pi\_Q)$ deciding whether to accept or reject based on the contents of the queried symbols. In the above example, $Q$ is uniformly distributed over sets of size 2 corresponding to edges in $E$, and $D$ accepts if the two queried symbols are distinct. We assume that one can efficiently recognize whether a set $Q$ can be generated by an honest verifier on a given input $x$. The completeness, soundness, and zero knowledge properties of a zk-PCP are defined as expected, where the zero-knowledge simulator is required by default to _perfectly_ sample the view $(Q,\\pi\_Q)$ of an _honest_ verifier given $x$ alone. The basic version of the zk-PCP for $R\_{\\sf 3COL}$ has a high soundness error of $1-1/|E|$. Soundness can be amplified, while respecting zero knowledge, by concatenating independently generated proofs $\\pi^{(i)}$ and querying them independently. Note that making multiple queries to the _same_ $\\pi$ would compromise zero knowledge. **The need for a cryptographic compiler.** The above notion of zk-PCP is information-theoretic in the sense that both soundness and (honest-verifier) zero knowledge hold with respect to computationally unbounded parties. The reason it cannot be _directly_ used as a zero-knowledge proof protocol, without additional cryptographic machinery, is that it is not clear how to only allow the verifier a restricted access to $\\pi$, which is necessary for zero knowledge, without allowing a malicious prover to violate the independence assumption between $\\pi$ and $Q$ on which soundness relies. Put differently, if $Q$ is sent to the prover first, then a malicious prover can violate soundness, and if $\\pi$ is sent to the verifier in its entirety, then zero knowledge is compromised even when the verifier is honest. The role of a cryptographic compiler is to convert an arbitrary zk-PCP (possibly with some syntactic restrictions) into a zero-knowledge proof protocol. ### Cryptographic compilers for zk-PCP The cryptographic compiler implicit in the above protocol for $R\_{\\sf 3COL}$ relies on a cryptographic commitment scheme and proceeds as follows. Given $(x,w)$, the prover uses the zk-PCP prover to generate a proof $\\pi\\in\\Sigma^m$ and uses the underlying commitment scheme to independently commits to each of the $m$ symbols. The verifier uses the zk-PCP verifier to pick a subset $Q$ of the symbols, which it sends as a challenge to the prover. The prover opens the symbols $\\pi\_Q$ after checking that $Q$ is valid (in the sense that it can be generated by an honest verifier). The verifier uses the decision predicate $D$ of the zk-PCP to decide whether to accept. **Using standard cryptographic assumptions.** While simple and natural, the analysis of the above compiler when using a standard [_computationally-hiding_ commitment scheme](http://www.wisdom.weizmann.ac.il/~oded/foc-vol1.html) is more subtle than it may seem. In particular, efficient simulation requires that the distribution of $Q$ have polynomial-size support. This indeed applies to the basic version of the zk-PCP for $R\_{\\sf 3COL}$, but not to the one with amplified soundness. As a result, the compiler yields a (constant-round) zero-knowledge protocol with poor soundness, which can be amplified via sequential repetition. An alternative cryptographic compiler, which avoids the polynomial-size support restriction by using a _statistically-hiding_ commitment scheme (and an even more subtle analysis), is implicit in the [work](http://www.wisdom.weizmann.ac.il/~oded/PSX/zkAK.pdf) on constant-round zero-knowledge proofs for NP. Both of the above compilers yield zero-knowledge proof protocols in which the communication complexity is bigger than that of communicating $\\pi$; ideally, we would like to make it comparable to only communicating $\\pi\_Q$. As we will see, this can make a big difference. When instantiated with statistically-binding (and computationally-hiding) commitments, the above compilers yield statistically-sound _proofs_ rather than computationally-sound arguments. In this case, their high communication cost seems inherent, as there is a strong complexity-theoretic evidence (see [here](https://eccc.weizmann.ac.il//eccc-reports/1996/TR96-018/index.html) and [here](https://eccc.weizmann.ac.il//eccc-reports/2001/TR01-046/index.html) ) that the prover-to-verifier communication in proof systems for hard NP-relations cannot be much smaller than the witness size. On the other hand, a [different cryptographic compiler](https://www.cs.virginia.edu/~mohammad/files/papers/ZKPCPs-Full.pdf) can use any _collision resistant hash function_ to obtain a zero-knowledge _argument_ whose communication complexity is close to just the size of $\\pi\_Q$, which for some zk-PCPs (that will be discussed in the second part of this post) can be much smaller than the witness size. The first compiler of this kind, implicit in the work of [Kilian](https://people.csail.mit.edu/vinodv/6892-Fall2013/efficientargs.pdf) , can obtain a similar zero-knowledge argument from any PCP, namely zk-PCP without the zero knowledge requirement. However, in contrast to compilers based on zk-PCP, Kilian’s compiler uses the underlying cryptographic primitive in a [non-black-box](https://people.seas.harvard.edu/~salil/research/blackbox.pdf) way, which makes it inefficient in practice. **Practical NIZK compiler in the random oracle model.** All of the previous black-box compilers can be analyzed unconditionally if the underlying “symmetric” cryptographic primitive is abstracted as a random oracle. But one can actually go further and make these interactive public-coin protocols _non-interactive_ via the [_Fiat-Shamir transform_](https://link.springer.com/chapter/10.1007\%2F3-540-47721-7_12) . Combining the two steps, we get concretely efficient compilers from any zk-PCP to NIZK in the random oracle model. The latter is then heuristically instantiated with a practical hash function based on, say, SHA-256 or AES. See the background part for more discussion of this methodology. Interestingly, even in the random oracle model, the NIZK does not entirely dominate the interactive protocol on which it is based, since removing interaction can come at a price. For instance, consider an interactive protocol with soundness error of $2^{-30}$, which is often reasonable in practice. In the NIZK obtained via the Fiat-Shamir transform, the prover can convince the verifier of a false statement with certainty by generating roughly $2^{30}$ random transcripts until finding one that would lead the verifier to accept. This type of attack effectively means that the non-interactive variant should rely on a zk-PCP with a considerably smaller soundness error, which increases the concrete communication and computation costs (though fortunately by a small factor). **NIZK from standard cryptographic assumptions.** As mentioned in the background part, a recent line of work shows how to instantiate the random oracle in NIZK proofs obtained via the Fiat-Shamir transform under standard cryptographic assumptions. These works rely on a special type of [correlation-intractable](https://eprint.iacr.org/1998/011) hash functions together with a special kind of [$\\Sigma$-protocols](https://www.cs.au.dk/~ivan/Sigma.pdf) , namely 3-message honest-verifier (computational) zero-knowledge proof systems that satisfy some additional properties. The latter in turn implicitly rely on a special kind of zk-PCP that can be instantiated with [Blum’s graph Hamiltonicity protocol](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.469.9048&rep=rep1&type=pdf) but remains to be more systematically explored. In contrast to these recent NIZK protocols, the [classical approach](https://epubs.siam.org/doi/abs/10.1137/S0097539792230010?journalCode=smjcat) for basing NIZK for NP on standard cryptographic assumptions uses a very different kind of information-theoretic proof systems referred to as zero-knowledge proofs in the _hidden bits model_. Known proofs of this type are more involved and less efficient than their zk-PCP counterparts. However, the cryptographic compiler from the hidden bits model to NIZK can rely on the intractability of factoring or, more generally, a ([suitable kind of](https://eprint.iacr.org/2017/631.pdf) ) _trapdoor permutation_. An interesting question is whether one can obtain a similar cryptographic compiler from zk-PCP. **Back to zk-PCP.** The usefulness of zk-PCPs makes them an independently interesting object of study. The original notion from the literature, due to [Kilian, Petrank, and Tardos](https://dl.acm.org/doi/10.1145/258533.258643) , is stronger than the one defined above in that it requires zero knowledge to hold even against a _malicious_ verifier who can make a bounded number of queries $t$. Here the prover is given $t$ as an additional input, and the proof size can grow polynomially with $t$. The main challenge is to make the number of queries of the honest verifier smaller than $t$, say growing at most polylogarithmically with $t$ and the statement length. Interestingly, in all known constructions the verifier needs to make two rounds of adaptive queries to the proof $\\pi$, in contrast to the single round of queries in the honest-verifier case. Whether this limitation can be removed is open; see [here](https://eprint.iacr.org/2016/021) and [here](https://eprint.iacr.org/2015/1055) for progress in this direction. Apart from the theoretical interest in this stronger notion of malicious-verifier zk-PCP, it has also found [cryptographic applications](https://eprint.iacr.org/2017/176) . However, for most applications of zk-PCPs, including all of the cryptographic compilers mentioned above, our default honest-verifier notion suffices. From here on, we will only consider zk-PCPs with an honest verifier. ### Information-theoretic compilers: zk-PCP from MPC A general paradigm for constructing zk-PCPs, originating from a [joint work](https://epubs.siam.org/doi/10.1137/080725398) with Kushilevitz, Ostrovsky, and Sahai, is via protocols for _[secure multiparty computation](https://eprint.iacr.org/2020/300.pdf) _ (MPC). This paradigm, commonly referred to as “MPC in the head,” gives a variety of _information-theoretic compilers_ from (different kinds of) MPC protocols to (different kinds of) zk-PCPs. An MPC protocol allows $n$ parties to compute a given _functionality_ $f$, mapping $n$ local inputs to $n$ local outputs, while hiding (in a sense that will be specified later) all information about the inputs except the outputs. The simplest instance of an information-theoretic compiler from MPC protocol to zk-PCP proceeds as follows. Given an NP-relation $R(x,w)$, define an $n$-party MPC functionality $f(x;w\_1,\\ldots,w\_n)=R(x,w\_1\\oplus w\_2\\oplus\\ldots\\oplus w\_n)$, where the input of each party $P\_i$ consists of the public statement $x$ and a secret input $w\_i$, and where $R(x,w)=1$ if $(x,w)\\in R$ and $R(x,w)=0$ otherwise. Intuitively, $w\_i$ can be thought of as a share of $w$. The output of $f$ should be delivered to all parties. The zk-PCP can be based on any MPC protocol $\\Pi\_f$ for $f$, over secure point-to-point channels, that offers security against two “semi-honest” parties. The latter is a weak security requirement asserting that if _all parties_ follow the protocol, then each pair of parties cannot learn more information from messages they receive than what follows from their inputs and the output. That is, the joint view of any pair of parties can be simulated given their inputs and outputs of $f$ alone, independently of the inputs of the other parties. Simple protocols of this kind exist unconditionally for $n\\ge 5$ parties: see [here](https://dl.acm.org/doi/10.1145/62212.62213) , [here](https://doi.org/10.1145/62212.62214) , and [here](https://www.sciencedirect.com/science/article/pii/S0166218X05002428?via\%3Dihub) . Given a protocol $\\Pi\_f$ as above, the zk-PCP prover, on input $(x,w)$, generates a proof $\\pi$ as follows. First, it randomly splits $w$ into $n$ _additive shares_ $w\_i$. Concretely, $w\_1,\\ldots,w\_{n-1}$ are picked uniformly at random, and $w\_n$ is computed as $w\_n=w\\oplus w\_1\\oplus w\_2\\oplus\\ldots\\oplus w\_{n-1}$. Next, the prover runs “in its head” a virtual execution of $\\Pi\_f$ on the common input $x$ and the secret inputs $(w\_1,\\ldots,w\_n)$. This involves picking a secret random input $r\_i$ for each $P\_i$, and computing the messages sent from each party to each other party round by round, until all parties terminate with an output. Without loss of generality, each message sent by $P\_i$ as well as the output of $P\_i$ are fully determined by $w\_i, r\_i$, and the messages received by $P\_i$ in previous rounds. Finally, the prover lets $\\pi=(V\_1,\\ldots, V\_n)$, where $V\_i$ is the entire view of $P\_i$ in the virtual execution of $\\Pi\_f$. We can assume $V\_i$ consists of $w\_i,r\_i$ and all messages _received_ by $P\_i$. The zk-PCP verifier queries a pair of random symbols $V\_i,V\_j$ and checks that: (1) the two views are _consistent_ in the sense that the incoming messages in each view coincide with the outgoing messages implicit in the other view; (2) the outputs of $P\_i$ and $P\_j$ implicit in the views are both 1. The verifier accepts if both conditions hold and otherwise rejects. The above zk-PCP construction is quite easy to analyze: * _Completeness_ follows from the definition of $f$ and the (perfect) correctness of $\\Pi\_f$. * _Zero knowledge_ follows from the fact that the pair of witness shares $w\_i,w\_j$ reveal no information about $w$ and by the security of $\\Pi\_f$; more formally, to simulate the symbols in positions $Q=\\{i,j\\}$, the zk-PCP simulator picks the inputs $w\_i,w\_j$ at random and then invokes the MPC simulator to simulate the views $V\_i,V\_j$ given the inputs $w\_i,w\_j$ and the output $f=1$. (Note that we could in fact use a leaner version of $f$ in which only the first 3 parties hold witness shares.) * Finally, to analyze the _soundness error_, suppose $x$ is such that there is no $w$ for which $R(x,w)=1$. We have the following two cases. (1) The views $V\_i$ correspond to some valid execution of $\\Pi\_f$ on inputs $(w^\*\_1,\\ldots,w^\*\_n)$; in this case, the output in all views must be $R(x,w^\*\_1\\oplus\\ldots\\oplus w^\*\_n)=0$ and the verifier will always reject. (2) The views are not consistent with any valid execution of $\\Pi\_f$; in this case, there must be a pair of inconsistent views, which the verifier will open and reject with $1/{n\\choose 2}$ probability. Note that unlike the previous $R\_{\\sf 3COL}$ example, the verifier rejects a false statement with constant probability when $n$ is constant. This soundness error can be reduced to $2^{-k}$ via $O(k)$ repetitions. The above construction can be [modified and extended](https://epubs.siam.org/doi/10.1137/080725398) in many useful ways. For instance, MPC with security against _one_ (semi-honest) party can be used by letting $\\pi$ include the $n$ views along with the ${n \\choose 2}$ transcripts between pairs of parties, and letting the verifier check consistency between a random view and a random transcript involving this view. The point-to-point channels can be replaced by oblivious transfer channels or even by [more general channels](https://eprint.iacr.org/2016/163) , which in turn can be used for applying MPC protocols with fewer parties and better efficiency. The perfect correctness of the MPC protocol can be relaxed at the expense of making the zk-PCP interactive. (We will discuss the interactive model in more depth below.) The MPC model can be augmented to [take advantage](https://eprint.iacr.org/2018/475) of input-independent preprocessing. Finally, one can use MPC protocols with a large number of parties while simultaneously achieving negligible soundness error by using MPC protocols with security against _malicious_ (as opposed to semi-honest) parties. This will be further discussed below. **Applications.** MPC-based zk-PCPs have several attractive features. Their simplicity typically makes the concrete computational overhead on the prover side smaller than in competing approaches. While the communication and verifier computation are asymptotically dominated by the alternative proof systems I will describe next, MPC-based constructions are still competitive for small problem sizes, or alternatively in settings where the prover’s computation cost is the main bottleneck. Optimized zero-knowledge proof systems of this kind include [ZKBoo](https://eprint.iacr.org/2016/163) as well as [this](https://eprint.iacr.org/2017/279) and [this](https://eprint.iacr.org/2018/475) improved variants. Interestingly, the latter serve as the basis for practical post-quantum digital signature schemes such as [Picnic](https://www.microsoft.com/en-us/research/project/picnic/) . In all of the above proof systems, the satisfiability of a Boolean or arithmetic circuit $C$ is proved with communication complexity that scales linearly with the number of gates $|C|$ (excluding parity or addition gates). When using information-theoretic MPC protocols, this linear communication barrier may seem inherent, but it turns out that it is not. The [Ligero](https://doi.org/10.1145/3133956.3134104) system gets around the circuit size barrier by using information-theoretic MPC protocols (with security against a constant fraction of malicious parties) in which the total communication complexity is comparable to $|C|$, but where the _per-party_ communication is comparable to $\\sqrt{|C|}$. In the corresponding (interactive) zk-PCP, the proof $\\pi$ consists of (roughly) $\\sqrt{|C|}$ symbols of length $\\sqrt{|C|}$ each, and the number of symbols queried by the verifier is $O(k)$ for soundness error $2^{-k}$. Using the cryptographic compilers discussed above, this can be compiled into lightweight zero-knowledge arguments in which the communication complexity grows linearly with $\\sqrt{|C|}$. More broadly, information-theoretic compilers from MPC protocols to zk-PCPs can be used to port the big array of techniques found in the literature on efficient MPC to the domain of zero-knowledge proofs. For instance, [MPC protocols based on algebraic geometric codes](https://link.springer.com/chapter/10.1007\%2F11818175_31) [can be converted](https://epubs.siam.org/doi/10.1137/080725398) into (statistically sound) zero-knowledge proof protocols for Boolean circuit satisfiability in which the ratio between the communication complexity and the circuit size is constant, while the soundness error is negligible in the circuit size. Similarly, one can exploit MPC protocols that make a black-box use of general [rings](https://eprint.iacr.org/2003/030) or [other algebraic structures](https://eprint.iacr.org/2013/480) , MPC protocols for [linear algebra](https://link.springer.com/chapter/10.1007\%2F3-540-44647-8_7) problems, and many more. One should keep in mind, however, that MPC protocols are designed for a distributed setting in which no single entity has full information. This is contrasted with the setting of proof systems, where the full information is available to the prover, and explains why MPC-based zk-PCPs cannot reach the asymptotic level of succinctness we will consider in the second part of this blog post. ### The computational overhead of zk-PCP An intriguing open question about the efficiency of zero-knowledge proof systems is whether their _computational_ overhead, namely the asymptotic ratio between the computation performed by the parties in the protocol and computing $R$ in the clear, can be made constant, namely independent of the level of security. The same question is open for zk-PCPs. In fact, under [suitable cryptographic assumptions](https://dl.acm.org/doi/10.1145/1374376.1374438) , the cryptographic compilers discussed above would be able to transform a zk-PCP with constant computational overhead into zero-knowledge proof protocols with the same property. What do we know about the computational overhead of zk-PCPs? To make the question concrete, consider an NP-relation $R$ computed by a family of Boolean circuits $C\_n$ of size $s=s(n)$, where $C\_n(x,w)$ computes $R$ on statements $x$ of length $n$. Suppose the required soundness error is $2^{-k}$ for $k=k(n)$ (to ignore lower order additive terms, assume that $s\\gg k$, say $s>k^2$). Let $s’=s'(n)$ denote the size of a Boolean circuit implementing the prover, mapping $(x,w)$ and secret randomness to a proof $\\pi$. (We ignore here the verifier’s complexity, since in known constructions it is smaller than the prover’s complexity.) How small can $s’$ be? In zk-PCPs obtained from simple MPC protocols with a constant number of parties, we have $s’=O(ks)$. This can be [improved](https://eprint.iacr.org/2010/106) to $s’=\\mathrm{polylog}(k)\\cdot s$ by using MPC protocols with security against a constant fraction of malicious parties. Whether this can be further improved to $s’=O(s)$ is an open question whose resolution is likely to require new technical insights. This question is open not only for zk-PCPs but also for any other kind of (computational or information-theoretic) zero-knowledge proof system from the literature. Jumping ahead, we will see that an _arithmetic_ version of the question, where Boolean circuits are replaced by arithmetic circuits over a field $\\mathbb{F}$ of size $2^{\\Omega(k)}$, can be answered affirmatively by using more liberal variants of zk-PCP. To conclude, in the first part of this blog post we discussed the advantages of decomposing a zero-knowledge proof into an information-theoretic proof system and a cryptographic compiler. We considered a simple kind of information-theoretic proof system called “zero-knowledge PCP” and matching cryptographic compilers. These give rise to theoretical feasibility results, as well as practical zero-knowledge proofs that are either non-succinct or “semi-succinct.” In the second part, we will discuss different routes to full succinctness. [Education](https://zkproof.org/tag/education/) [Tech](https://zkproof.org/tag/tech/) [Zero-knowledge proofs](https://zkproof.org/tag/zero-knowledge-proofs/) * * * ![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=240&d=identicon&r=g) ##### [Yuval Ishai](https://zkproof.org/author/yuvalishai/ "Yuval Ishai post page") [All author posts](https://zkproof.org/author/yuvalishai/ "Yuval Ishai post page") ##### Related Posts [![](https://zkproof.org/wp-content/uploads/2023/02/Sangria-Square-1-uai-258x129.png)](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) February 21, 2023 ### [Sangria: a Folding Scheme for PLONK](https://zkproof.org/2023/02/21/sangria-a-folding-scheme-for-plonk/) In this technical note we present… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [![](https://zkproof.org/wp-content/uploads/2021/11/VDF-blogpost-NOV21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) November 24, 2021 ### [Practical SNARK-based VDF](https://zkproof.org/2021/11/24/practical-snark-based-vdf/) Protocol Labs, the Ethereum Foundation,… * * * [![](https://secure.gravatar.com/avatar/f3c7fd882f467d07c55a0c90a7e728ad?s=40&d=identicon&r=g)by Jonathan Gross](https://zkproof.org/author/jpgross3/) [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x129.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin,… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) ### Leave a Reply[Cancel reply](/2020/08/12/information-theoretic-proof-systems/#respond) This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # ZK Score - ZK hardware ranking standard  - ZKProof Standards October 23, 2023|In [Standards](https://zkproof.org/category/standards/ "View all posts in Standards") |30 Minutes ZK Score - ZK hardware ranking standard  ======================================== [![Omer Shlomovits](https://secure.gravatar.com/avatar/e295b0529c3b8e216566a972f6dd3182?s=40&d=identicon&r=g)](https://zkproof.org/author/omershlomovits/) By [Omer Shlomovits](https://zkproof.org/author/omershlomovits/) Written by: Omer Shlomovits, Lucy Williams (_Disclosure: the first author is affiliated with a ZK hardware company_) **Intro** Zero Knowledge Proofs (ZKPs) are on the verge of going mainstream. Amid these growing pains, and with an eye on more mature technologies that have undergone this transition, we recognize the importance of having a clear framework for comparing different ZK tech stacks. As we demonstrate below, this remains a complex open question. We argue that a good first step would be to use _ZK Score_: _upper-bounding the proofs-per-Joule at the hardware level._ ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/DALL%C2%B7E-2023-10-19-13.53.26-Illustration-of-a-balance-scale.-On-one-side-theres-a-microchip-representing-ZK-Hardware-and-on-the-other-a-lightning-symbol-representing-energy-J.png?resize=336%2C336&ssl=1) **The Big Sister: How We Benchmark AI** Some inspiration can be taken from how things have been done in AI. In 2023, AI is a much more mature technology compared to ZK. Because AI training is outpacing Moore’s Law, AI advances as computing advances. Therefore, the performance of AI systems is entirely dependent on hardware acceleration. The contenders in the AI benchmarking race are hardware appliances, and the accompanying software to run them. Often, the same chips (e.g. Nvidia H100) are used in multiple distinct appliances and end up competing with one another.  The most widely known benchmarking tool is a suite of tests called MLPerf developed by [MLCommons](https://mlcommons.org/en/) (a consortium of AI leaders from academia, research labs, and industry). MLPerf is a well-maintained project which has evolved over time. The most recent 2023 edition, started to measure Large Language Models (LLM) performance, for the first time ever.  We assume that the challenge of coming up with a fair, easily reproducible, and fast, suite of benchmarking tests, would be at least as hard to do for ZK, as it was for AI. Let’s consider LLM training benchmarks for a moment. To reproduce them might cost millions of dollars, so techniques were invented for clever ways to measure them.  Check out this awesome quote from the MLCommons [philosophy](https://mlcommons.org/en/philosophy/) page, > “_ML and artificial intelligence have been around for decades, but even today the technology is fragmented, bespoke, and poorly understood. We believe that we can unlock the next stage of AI/ML adoption by creating useful measures of quality and performance_.” Sound familiar? MLPerf is a competition composed of multiple tests, with a few tracks allowing for full coverage and various ways to compare ML systems.  1. The basic unit of measurement is throughput: how many samples or queries can be processed per unit of time (second). The choice of samples vs. queries depends on two scenarios: offline vs. querying a server.  2. There is a power measurement which is a wrapper around the throughput. 3. Submitters can also submit for a network track. 4. The most popular track is for an apples-to-apples comparison (called “closed”), in which the same model and optimizations must be used. There is also an “open” track that allows teams to run whatever they want as long as they get the correct (above threshold or defined otherwise) result.  A few takeaways. First, for MLPerf to have become an industry standard, required support from dozens of organizations: small to large startups, universities and giant corporations; as well as a large diversity of stakeholders: cloud computing platforms, semiconductor companies, researchers, and app developers. Second, MLPerf started in 2018 and only recently introduced its eighth edition, [version 3.1](https://mlcommons.org/en/news/mlperf-inference-storage-q323/) . Remember that AI in scaled products is barely 10 years old. [MLPerf](https://mlcommons.org/en/news/mlperf-inference-storage-q323/) reminds us that continuous effort and dedication are needed to maintain “industry standard Machine Learning (ML) system performance benchmarking in an architecture-neutral, representative, and reproducible manner”. The field keeps moving forward and so do its benchmarking tools.  One difference to note when making an analogy to ZK is that in ZK the output is a verifiable computation. It is a binary outcome; either we achieve the required properties (eg. soundness) for some security parameter, or we don’t. With AI, we build intelligence. We can measure how good a system is, based on how well it performs a certain task. For instance, depending on the goal, the task may be a classification or a specialized [holistic evaluation of language models](https://crfm.stanford.edu/helm/latest/) . In a way, this makes our job easier, assuming we can normalize security strength.  **Intro to ZK Hardware Performance** Today, most ZK provers are running on CPUs. GPUs, FPGAs, and ASICs, are all legitimate targets for ZK proof-computation. We recommend watching this [excellent talk](https://www.youtube.com/watch?v=yC5VN6l5kXM) to learn more about the differences between these devices. Unfortunately, the hardware community within our own industry continues to struggle to align with established norms and standards.  [SuperScalar](https://medium.com/@SuperScalar_io/superscalar-launches-the-worlds-first-zkp-fpga-miner-k10-and-k11-for-aleo-1b987512e7f2) , a recent blog post about Aleo Provers, illustrates this point. Aleo is a blockchain that incorporates privacy by design using ZKPs. It also employs ZKPs at the consensus level in a mining-like fashion. Simply put, if you have a high throughput of proofs, you have a higher probability of mining success and subsequently reaping the rewards.  In the aforementioned blog post, the new K10 miner based on FPGA technology (referred to as a K10 miner going forward), is compared to the Nvidia RTX 3090 GPU (referred to as a 3090 GPU going forward): ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/Screenshot-2023-10-22-at-13.43.47.png?resize=653%2C246&ssl=1) Source: SuperScalar. PPS stands for proofs per second. The first question that comes to mind is, what is so special about the 3090 GPU? Why not compare the new K10 miner to the Nvidia RTX 4090 GPU, which is a newer and better GPU? The second question is, does it actually make sense to compare throughput alone? If throughput is the comparison metric, why not take a CPU host, connect it to 4×3090 GPUs for a total throughput of 28K PPS, and call it K12? A real-world FPGA ZK prover will look similar to GPU provers, with multiple PCIe cards plugged into a host CPU. Before proceeding further, we’d like to briefly introduce an important term in hardware: total cost of ownership (TCO). Defined loosely, we can say that TCO is the cost of buying the device (CAPEX), plus the cost of operating the device through its lifetime (OPEX), minus the revenue of selling the device at the end of its lifetime.  _TCO = CAPEX + OPEX – resale\_price_ Returning to our example of the GPU-based vs. FPGA-based Aleo miners, we initially aim to equate the TCO of both appliances before comparing their performance. The cost of a single K10 miner is USD 4500 (based on a query to the supplier), and the cost of buying a single 3090 GPU is between USD 700 (new) to USD 500 (used), according to [howmuch.one](https://howmuch.one/product/average-nvidia-geforce-rtx-3090-24gb/price-history) .  So, one can buy seven to nine 3090 GPUs for the price of one K10 miner.  With respect to operational expenditure, we can assume electricity cost is fixed and the same for both. The SuperScalar post states that the K10 miner’s power consumption is 1200 Watts. Note that this number is application-dependent. The 3090 GPU’s total dissipated power (TDP) is 350 Watts according to its [technical specifications](https://www.nvidia.com/en-us/geforce/graphics-cards/30-series/rtx-3090-3090ti/) . That doesn’t mean that this is going to be the power consumed if we implement the same application, but for the sake of this analysis let’s assume the worst-case scenario, i.e. max power is needed.  Now, we can normalize by power:  how many Joules (a Watt \[W\] is defined as one Joule per second) does it take to generate one proof? ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/Screenshot-2023-10-22-at-13.51.26.png?resize=430%2C111&ssl=1) Source: SuperScalar. K10 prover’s power consumption. For a K10 miner, we calculate: 24000 PPS/1200W = 20 proofs/Joule For a 3090 GPU, we calculate:  7000 PPS/350W = 20 proofs/Joule These calculations show that the K10 miner has no advantage over the 3090 GPU. In other words, since the power consumption is the same for both, we pay the same amount to generate proof. It doesn’t matter how many K10 miners or 3090 GPUs we have.  Fun fact: for the newer Nvidia RTX 4090 GPU, which [costs USD 1500](https://howmuch.one/product/average-nvidia-geforce-rtx-4090-24gb) (at the time this was written), we calculate 16000 PPS/450W > 35 proofs/Joule. So many more proofs for your dollar!  Finally, we take the resale price into consideration. Here, we can assume that the 3090 GPU will retain more of its value. We have [concrete data](https://howmuch.one/product/average-nvidia-geforce-rtx-3090-24gb/price-history) that a used, 1-year-old 3090 GPU, has almost no depreciation in value (a comparison of the October 2022 price to the October 2023 price), and we know that a 3090 GPU can be repurposed easily for gaming, science, and so on. The K10 miner, on the other hand, is a dedicated mining machine and unfortunately, we don’t have any data on the resale price. For this reason, it is untenable to compare resale values. Of course, relying on historical data is nothing like projecting a price in the future, which is what is needed when computing TCO. Does this mean that the 3090 GPU is better or worse than the K10 miner? Hard to tell, because TCO is involved and difficult to normalize. For example, what if the physical size of one appliance is much bigger than the other? That is, the real estate on a rack in a data center is different and thus, has an impact on cost and TCO. It doesn’t end there either, there are several other factors that need to be taken into consideration. Included, but not limited to: power infrastructure, maintenance, and reliability. Referring to the information presented above, our point is that we are still a long way from the golden standard when it comes to ZK performance measurement in hardware products. Enter _Z_K Score. **Part 1: ZK Score**  The primary value of the ZK Score lies in its simplicity. Currently, the ZK space is deeply involved in middleware and infrastructure R&D. We have very little happening at the application layer. Continuing our Aleo example, the foundation develops a prover to run applications, but we don’t know yet which applications are going to be killer applications. The same is true for ZKML. We know which ML we want to use, and infrastructure is getting better and better, but no real use cases are running at scale yet. This is why we think that for the time being and as a first step, we should focus on infrastructure benchmarks, starting with hardware. Already at this early stage, we can talk in terms of setups and systems that are designed to run ZK provers efficiently for a variety of use cases. Case in point, the K10 miner is an FPGA-based system that can support a limited set of ZK protocols. The [Nvidia DGX](https://www.nvidia.com/en-us/data-center/dgx-platform/)  is an off-the-shelf appliance with 8xH100 cards, that can be programmed to run any ZK protocol but produces varied results with respect to efficiency. And, we can take an AWS F1 instance (FPGA), connect it via a local area network (LAN) to another instance with an Nvidia T4 GPU, and call it a third system. Obviously, we can expect each system to perform differently, but how do we rank them against one another?  It’s important to understand which system is more efficient so that it can direct our efforts in the years to come and improve ZK infrastructure. For instance, if a K10 miner has the best ZK Score, we would hope to see more work focused on maximizing the potential of FPGAs, more middleware for this device, experimentation with K10 miner variants, and integration with more applications. The most straightforward ZK Score is throughput/power. It is also best practice according to AI benchmarking. The difference is, with AI we measure the throughput of end-to-end samples. The ZK equivalent would be to measure throughput in proofs-per-second. However, as we will show later, this adds complexity which makes ranking more troublesome.  As long as we don’t have a standardized suite of tests, the best we can achieve while introducing minimal bias is directly measuring ZK-related operations on the hardware itself. Even then, we must distinguish between high-level and low-level primitives and lean towards lower-level primitives, to reduce complexity. What we lose in this tradeoff is accuracy and we are left with an approximation of the upper bound on the throughput achieved by the system.  Low-level Primitives for ZK Hardware We now take a more concrete approach for ZK Score candidates. The arithmetic used for ZKPs (as in many other places in cryptography) is modular arithmetic, and modular multiplication is used more frequently than modular addition. Arithmetic operations on more complex primitives, specifically elliptic curves which are used in some popular ZK protocols, can be broken down into several modular multiplications and additions. In fact, just like with any arithmetic, addition, and multiplication form a complete functional language that we can use to express any ZK protocol. There are two popular algorithms for modular multiplications: Barret and Montgomery.  Together, they cover the majority of existing implementations. These algorithms have existed since the 1980s and have had years of battle testing. Some [active research](https://github.com/ingonyama-zk/papers/blob/main/multi_precision_fast_mod_mul.pdf) is still happening in the area of modular multipliers, but they usually end up as extensions or variants of Barret or Montgomery. Because these algorithms are in such a mature state, it is safe to assume that further optimization for this layer is unlikely.  One layer above, we have elliptic curve (EC) arithmetic, going from basic point addition to vector operations such as multiscalar multiplication (MSM). EC cryptography entered into wide use in the early 2000s and has received growing attention ever since, including in blockchain cryptography. It is a broader domain than that of modular arithmetic. An EC group can belong to one of several families that share common properties. There are multiple formulations for EC point addition, and even representing an EC point can be done in various ways. EC cryptography acceleration is also a newer field. Algorithms in hardware for MSM are still being explored (see [ZPRIZE](https://zprize.hardcaml.com/msm-overview.html) ). From here on, higher layers are newer and leave an extensive design space for optimizations.  Our suggestion for making the most accurate apples-to-apples comparison is to rely on modular multiplications (mod mults) as the unit we measure for throughput. Note that this behaves as a kind of an upper bound. If a system being tested is able to produce X mod mults per second, and for an EC addition we need, say, 5 mod mults, then the ideal EC addition throughput will be upper-bounded by X divided by 5. We can use the same rule as we go up the stack. Fields, Not a Field  Although we zoomed in on modular multiplication operations per second (MMOPS), a finer resolution is still needed. ZK systems can be implemented using different fields, depending on several factors and protocol requirements. If we benchmark MMOPS of a 31-bit or 64-bit field, we might end up with different results compared to MMOPS with 256-bit or 384-bit fields. There is likely no middle ground here, so the best approach would be to run benchmarks for all bit sizes of interest. Maybe in the future, there will be some clever way to put weights on these fields, in order to get an accumulated ZK Score. Normalizing by Power As we saw in the TCO discussion, there are several elements to scrutinize in order to enable viewing diverse systems as equals. Out of the three main elements that comprise the TCO, only the OPEX is measurable. CAPEX and resale prices can differ significantly for the same device and are hard to quantify or compare. The closest approximation of OPEX would be the electricity bill of the system when it runs the workload it is designed to run. That is to say, we need to measure power consumption over the same unit of time. That unit of measurement is Watts. As a result, we end up with a ZK Score definition of:  **MMOPS/Watt == MMOP/Joule** **Summary**  As the ZK landscape continues to grow, the call for reliable benchmarking standards is clear. The evolution of ZKPs is a moving target full of intricacies, which makes apples-to-apples measurements challenging. Luckily, we can draw inspiration from how the AI community addressed this problem. With that in mind, we recommend ZK Score as a first step, in tackling the problem of comparing apples-to-apples. Driven by simplicity and determinism, ZK Score would allow us to evaluate and compare different ZK systems by using an upper-bound that is based on the throughput of the modular multiplications these systems can run, over a given time frame, and would be normalized by power consumption. In Part 2, we discuss existing alternatives to ZK Score. **Part 2: ZKP Comparison Method Pitfalls** To demonstrate the challenges in quantitatively analyzing & measuring ZKP performance, we will cite some popular methods used in the literature, and discuss some disadvantages of each. Complexity Theory. Some ZK papers limit the comparison to the theoretical level. The motivations are clear. Complexity theory provides asymptotic performance, typically using the big O notation to indicate how metrics, such as prover runtime, grow based on the input size. This form of comparison is very clean and allows for immediate conclusions: if one prover takes O(N) and the other prover takes O(NlogN), it is obvious that the O(N) prover is better. There are a couple of issues with relying strictly on this approach. The root cause for both is that complexity theory does not reflect the real world well: 1. 1. When we compare two protocols with the same complexity, there is no accounting for the constants that determine which one is better. For example, let’s say that for group element operation we need three field element operations, which means that the ratio of the first and second rows in the figure below is 3. But, what if the actual performance of the first row, removing the big O notation, is N group operations, or 3N field operations, while the actual performance of the second row, is 50N field operations? There is no way for us to tell which one is better in practice, without this information.  2. ZK engineering is messy. The complexity theory view avoids relevant implementation details. Sometimes it’s something big, like memory requirements (not to be confused with proof size, here we are referring to how much memory a proof uses during computation).  Other times it is some other hidden missing cost. Let’s look at a figure from [Lasso](https://people.cs.georgetown.edu/jthaler/Lasso-paper.pdf) . Note the sentence, “In addition to the reported O(N) field operations, Hyrax and Dory require roughly O(N^½) cryptographic work to compute evaluation proofs.” Engineering is the art of trade-offs. When we implement a protocol we are forced to make multiple decisions, based on system requirements, hardware available, programming language, and so on. These things need to be taken into account. ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/lasso.png?resize=840%2C301&ssl=1) Source: Lasso Adding PoC Implementation. A few papers take the additional step of implementing their ZK protocol. The system setup is described in the paper, and most times targets available hardware. There are two issues with this approach. First, there is the question of which system or protocol we want to compare against. Ideally, we’d want to compare one implementation to all other implementations.  But in practice, the design space today for proof generation is so diverse, that it is almost never an apples-to-apples comparison. Let’s examine the table from the [Hyperplonk](https://eprint.iacr.org/2022/1355.pdf) paper below, we see that Hyperplonk is juxtaposed with Ark-Spartan. Yet, the two systems use entirely dissimilar arithmetization techniques, namely R1CS and Plonk+. Taking the one-before-last application (rollup), the size in number of constraints for the R1CS system is 32X the size of Plonk+ constraints. Hence, the meaning of the prover run-time measurement is unclear, because the input test vectors vary in size. The second problem is the selection of applications. Looking at the last line, the zkEVM application was never expressed in R1CS format, and therefore cannot be measured. Making an analogy to AI, it would be like comparing a model for classification with an LLM. In theory, they can both run a classification application, but one was not specifically designed for it, while the other is optimized for it. We expect various protocols to be optimized/suitable for different applications, but it makes the reasoning behind comparing two protocols that are built for different applications difficult to understand.  ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/Screenshot-2023-10-22-at-16.00.21.png?resize=840%2C419&ssl=1) Source: Hyperplonk End-to-End Benchmarking Tools. Recent efforts like [EF zkalc](https://crypto.ethereum.org/blog/zkalc) , [The Pantheon of ZKP](https://blog.celer.network/2023/08/04/the-pantheon-of-zero-knowledge-proof-development-frameworks/) , and [ZK bench](https://zkbench.dev/) , are looking at the problem from the exact opposite way described in the complexity theory approach. Meaning, they try to run all existing ZK frameworks against each other and implement any missing pieces. Through this engineering-oriented approach, we aim to understand the performance of various protocols, considering the input size as a variable. There are a couple of issues with this approach. First, the implemented circuits might not be fully optimized, primarily because ZK DSLs are still in their infancy. Second, similar to what we saw in the previous case, it is hard to deduce meaningful conclusions by looking at the results. The graphs below make it seem as if all of the frameworks result in roughly the same performance. ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/10/zk-bench.png?resize=840%2C445&ssl=1) Source: zk-bench, Fig. 8 – SHA 256 execution time **Conclusion** Although using complexity theory, comparing implementation data, and using end-to-end benchmarking tools, have attempted to codify a way to compare ZKPs, they all have pitfalls. Our motivation for writing this post isn’t to cast aspersions, but to catalyze the ZK community to formulate methods and standards, possibly resembling AI, that reflect ZKP performance more accurately. The end goal is a fair, reproducible, and fast way, to conduct real-world comparative analyses. We submit ZK Score for your deliberation and as a potential first step toward that goal. * * * ![](https://secure.gravatar.com/avatar/e295b0529c3b8e216566a972f6dd3182?s=240&d=identicon&r=g) ##### [Omer Shlomovits](https://zkproof.org/author/omershlomovits/ "Omer Shlomovits post page") [All author posts](https://zkproof.org/author/omershlomovits/ "Omer Shlomovits post page") [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Call For Papers: 7th ZKProof Workshop - ZKProof Standards THE 7TH [ZKPROOF](https://zkproof.org/events/zkproof-6-berlin/) WORKSHOP ========================================================================= CALL FOR PAPERS =============== ----------------------------------- **The ZKProof Standardization effort is now accepting submissions to the 7th ZKProof Workshop, which will be held in Sofia between March 23-25, 2025. The workshop addresses the security, implementation and applications of zero-knowledge proofs. The workshop does not have proceedings and hence, the submission can be based on either work in progress, papers in submission, or papers already published at a conference, workshop or journal. The program committee will select talks with the aim of constructing a balanced program that will be of high interest to the audience and community.** **Submissions on any topic related to zero-knowledge proofs are welcome. Please review the current ZKProof documents for examples. This includes, but is not limited to, the following:** * **Terminology, definitions and models** * **ZK proof-system constructions and their building blocks** * **Implementation of ZK proof system** * **Applications of ZK proof systems, in blockchain and beyond** * **Interoperability and integration between proof-system implementation, or components thereof (e.g. APIs and file formats)** * **Benchmarking** * **Domain-specific languages for expressing statements to be proven in zero knowledge** * **Security analysis and formal verification** Submissions can consist of novel constructions or analysis; or systemization of knowledge of existing state of the art. **Submission Details:** **Submissions must be prepared in LaTeX, 11-point font, single-column. There is no page limit but the submissions are expected to be intelligible for the reviewers within the first 5 pages. The structure is up to the authors’ discretion, but should include all of the following:** * **Title** * **Author names and affiliations** * **Background and motivation: contextualize the problem being addressed, and motivate its importance and the potential impact of the submission. Include references.** * **Terminology: It is encouraged to use terminology consistent with the existing ZKProof Standardization documents, and in particular the Community Reference document, whenever possible.** * **Security: Including formal security guarantees is highly encouraged (if any).** * **Implementation: if relevant, submit an open source prototype/prototype implementation, by including a reference to the code repository with the code.** #### Deadlines and Info * **Deadline for Proposals: **January 15th, 2025 * **Deliberations:** January 15th – February 3rd, 2025 * **Final Responses: February 3rd, 2025 (moved from January 25th)** * Reminder: The ZKProof 7 Event will happen on **March 23rd-25th, 2025** Submit your papers to: [https://zkproof25.hotcrp.com/](https://zkproof25.hotcrp.com/) Program Chairs ------------------ [![Eran Tromer](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/CA5_0227_edt2_sqr.jpg?resize=150%2C150&ssl=1)](http://www.tau.ac.il/~tromer/) ### [Eran Tromer](http://www.tau.ac.il/~tromer/ "Eran Tromer") [Professor, Boston University founder, Sealance](http://www.tau.ac.il/~tromer/ "Eran Tromer") [![Ran Canetti](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/ran_canetti-e1576008389650.jpg?resize=150%2C150&ssl=1)](https://www.cs.tau.ac.il/~canetti/) ### [Ran Canetti](https://www.cs.tau.ac.il/~canetti/ "Ran Canetti") [Boston University, Tel Aviv University](https://www.cs.tau.ac.il/~canetti/ "Ran Canetti") Program Committee --------------------- [![Michel Abdalla](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/01/2022-07-Michel.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/michel-abdalla/) ### [Michel Abdalla](https://zkproof.org/team/michel-abdalla/ "Michel Abdalla") [Nexus](https://zkproof.org/team/michel-abdalla/ "Michel Abdalla") [![Dahlia Malkhi](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/11/dahliabest.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/dahlia-malkhi/) ### [Dahlia Malkhi](https://zkproof.org/team/dahlia-malkhi/ "Dahlia Malkhi") [Professor of Computer Science, UC Santa Barbara, and Distinguished Scientist, Chainlink Labs](https://zkproof.org/team/dahlia-malkhi/ "Dahlia Malkhi") [![Ruihan Wang](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/03/WhatsApp-Image-2024-02-29-at-20.16.13.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ruihan-wang/) ### [Ruihan Wang](https://zkproof.org/team/ruihan-wang/ "Ruihan Wang") [Ligero, Inc.](https://zkproof.org/team/ruihan-wang/ "Ruihan Wang") [![Eylon Yogev](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/ey.jpeg?resize=150%2C150&ssl=1)](https://zkproof.org/team/eylon-yogev/) ### [Eylon Yogev](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [Professor, Bar-Ilan University](https://zkproof.org/team/eylon-yogev/ "Eylon Yogev") [![Ariel Gabizon](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/Ariel-Gabilzon.jpg?resize=150%2C150&ssl=1)](https://zkproof.org/team/ariel-gabilzon/) ### [Ariel Gabizon](https://zkproof.org/team/ariel-gabilzon/ "Ariel Gabizon") [Aztec Labs](https://zkproof.org/team/ariel-gabilzon/ "Ariel Gabizon") [![Pablo Kogan](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/11/Pablo-pic.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/pablo-kogan/) ### [Pablo Kogan](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [Director of Engineering, QEDIT](https://zkproof.org/team/pablo-kogan/ "Pablo Kogan") [![James Parker](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/JamesP.png?resize=150%2C150&ssl=1)](https://zkproof.org/team/james-parker/) ### [James Parker](https://zkproof.org/team/james-parker/ "James Parker") [Research Engineer, Galois](https://zkproof.org/team/james-parker/ "James Parker") [![Carmit Hazay](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/carmitHazay-e1579981003254.jpg?resize=150%2C150&ssl=1)](https://www.eng.biu.ac.il/hazay/) ### [Carmit Hazay](https://www.eng.biu.ac.il/hazay/ "Carmit Hazay") [Professor, Bar-Ilan University; Co-founder, Ligero](https://www.eng.biu.ac.il/hazay/ "Carmit Hazay") [](https://twitter.com/CarmitHazay "twitter") [](https://www.eng.biu.ac.il/hazay/ "globe") [![Muthu Venkitasubramaniam](https://i0.wp.com/zkproof.org/wp-content/uploads/2019/12/Copy-of-GBP_20190412_1086-e1576450323148.jpg?resize=150%2C150&ssl=1)](https://www.cs.rochester.edu/u/muthuv/) ### [Muthu Venkitasubramaniam](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [Associate Professor, Georgetown University  CTO and co-founder, Ligero Inc.](https://www.cs.rochester.edu/u/muthuv/ "Muthu Venkitasubramaniam") [![Dan Boneh](https://i0.wp.com/zkproof.org/wp-content/uploads/2020/01/danboneh_a16zcrypto.jpg?resize=150%2C150&ssl=1)](http://crypto.stanford.edu/~dabo/) ### [Dan Boneh](http://crypto.stanford.edu/~dabo/ "Dan Boneh") [Stanford University](http://crypto.stanford.edu/~dabo/ "Dan Boneh") [](#) --- # Albert Garreta - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/03/Albert-Garreta.jpeg?fit=840%2C688&ssl=1) Albert Garreta -------------- [](#) --- # Teor, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/b0a4d5878b49d2ddc7d783b4fa35105e?s=200&d=identicon&r=g) Teor ==== June 3, 2021 ### [Zebra: Zcash Zero-Knowledge Proofs at Scale](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) The Zcash protocol has used a number of different zk-SNARK proof systems since its initial deployment in 2016, including BCTV14 for the first shielded pool, Sprout (which is now… * * * [0 Comments](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/#respond "title") 9 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Webinar Archives - ZKProof Standards Webinar ======= [![](https://zkproof.org/wp-content/uploads/2017/03/Webinar-Template-uai-258x172.png)](https://zkproof.org/2020/01/01/fundamentals-of-zero-knowledge/) January 1, 2020 ### [Announcing the Expert Series Webinar on Zero-Knowledge Proofs](https://zkproof.org/2020/01/01/fundamentals-of-zero-knowledge/) ZKProof has joined forces with leading organizations in our… * * * [![](https://secure.gravatar.com/avatar/3dff3f44c2dbac565e398483ddb5a318?s=40&d=identicon&r=g)by ZKProof Standards](https://zkproof.org/author/contact70d66e844e/) [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Daniele Cozzo - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Daniele-Cozzo.jpeg?fit=840%2C876&ssl=1) Daniele Cozzo ------------- IMDEA Software Institute [](#) --- # Antoine Rondelet, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/dc3f0db7d6834d4f4d8308e5e309d092?s=200&d=identicon&r=g) Antoine Rondelet ================ October 15, 2020 ### [Playing with Randomness and Interactions to Prove Theorems](https://zkproof.org/2020/10/15/randomness-and-interactions/) In this blog post, I will go back to some of the early results that pioneered the notion of "zero-knowledge proof'' as we know it today. To that end, I will provide an… * * * [0 Comments](https://zkproof.org/2020/10/15/randomness-and-interactions/#respond "title") 45 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Education Archives - ZKProof Standards Education ========= [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x172.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin, a recursive zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) [![](https://zkproof.org/wp-content/uploads/2021/06/cover_img_setup-uai-258x172.jpg)](https://zkproof.org/2021/06/30/setup-ceremonies/) June 30, 2021 ### [Setup Ceremonies](https://zkproof.org/2021/06/30/setup-ceremonies/) We often refer to zero-knowledge proofs monolithically, but… * * * [![](https://secure.gravatar.com/avatar/269929faf63fc4a46e78e3414a9e5e91?s=40&d=identicon&r=g)by Anthony Mpho Matlala](https://zkproof.org/author/tony007matlala/) [![](https://zkproof.org/wp-content/uploads/2021/06/Zeal-Twitter-banner-2-uai-258x172.png)](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) June 3, 2021 ### [Zebra: Zcash Zero-Knowledge Proofs at Scale](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) The Zcash protocol has used a number of different zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/b0a4d5878b49d2ddc7d783b4fa35105e?s=40&d=identicon&r=g)by Teor](https://zkproof.org/author/teor/) [![](https://zkproof.org/wp-content/uploads/2021/05/fiber-4814456_1920-uai-258x172.jpg)](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) May 5, 2021 ### [HashWires: Range Proofs from Hash Functions](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/651414b06e6324585def2c030b35590a?s=40&d=identicon&r=g)by Kostas Chalkias](https://zkproof.org/author/kostascrypto/) [![](https://zkproof.org/wp-content/uploads/2020/10/mitchell-luo-cuOKT4AI5Ro-unsplash-uai-258x172.jpg)](https://zkproof.org/2020/10/15/randomness-and-interactions/) October 15, 2020 ### [Playing with Randomness and Interactions to Prove Theorems](https://zkproof.org/2020/10/15/randomness-and-interactions/) In this blog post, I will go back to some of the early… * * * [![](https://secure.gravatar.com/avatar/dc3f0db7d6834d4f4d8308e5e309d092?s=40&d=identicon&r=g)by Antoine Rondelet](https://zkproof.org/author/antoinerondelet/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) October 15, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part II](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) August 12, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part I](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Announcing the Expert Series Webinar on Zero-Knowledge Proofs - ZKProof Standards ### ZKProof, The Ethereum Foundation and ZK Global Present: **Expert Series:** **Fundamentals of Zero-Knowledge** ----------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **[Register Here](https://zoom.us/meeting/register/uZQtdeGsqzItCIEmsgClziKUxW6Be0lfMA) ** ZKProof has joined forces with leading organizations in our ecosystem to launch a new webinar series. With the aim of making Zero-Knowledge Proof technology more accessible to new audiences, ‘the Fundamentals of Zero-Knowledge’ will commence on February 17th, 2020. Over the past three years, we have focused on building a strong community. We have defined best practices for the field through standardization workshops that have attracted the world’s top researchers, developers and practitioners. The results of our efforts have culminated in four standardization proposals that are currently under review and the first [ZKP Community Reference Document.](https://docs.zkproof.org/assets/docs/reference-v0.2.pdf) Along with this, we have achieved endorsements from a long list of leading institutions, such as: NIST, IBM, ING, JP Morgan, BBVA, Microsoft, Calibra, Vmware, Deloitte, Accenture, R3, Zcash Foundation, Berkeley U., Stanford, MIT, Columbia and many more. The ZKProof workshops attract a high level of technical expertise. They are effective in advancing the standardization effort, and incentivizing top academics and developers to return ([event agendas from previous workshops can be found here](https://zkproof.org/events/) ). ### **Why are we starting this webinar series?** The technical depth of ZKProof workshops presents a challenge for people who are less experienced in the field. While it can provide an outstanding opportunity for young researchers and developers to engage with experts, this forum cannot be fully harnessed without a shared foundation and a sound understanding of the workshop’s focus – Zero-Knowledge Proofs. The challenge for newcomers is exacerbated by a lack of introductory-level online resources about ZKP cryptography. For these reasons, and in parallel to our work with seasoned professionals, we have decided to make Zero-Knowledge Proof cryptography more accessible to non-experts. In order to accomplish this, we are partnering with experts from industry and academia who volunteered to lead a series of webinars focused on the fundamentals of Zero-Knowledge in the lead up to this year’s workshop. Registration is free and each one-hour session will be followed by a live discussion and Q&A. #### _This webinar series is suitable for anyone with:_ * An undergrad-level background in mathematics and/or computer science. * A basic understanding of ZKP cryptography and some experience with Zero-Knowledge Proofs libraries * Interest in understanding how proofs are constructed and the most common ZKP schemes * A genuine desire to learn and start developing * Interest in getting the most out of the next [ZKProof Workshop](https://zkproof.org/events/workshop3/) This Webinar series is brought to you as a lead up to the [3rd ZKProof Workshop](https://zkproof.org/events/workshop3/) ------------------------------------------------------------------------------------------------------------------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [![](https://zkproof.org/wp-content/uploads/2020/01/Eventbrite-cover-image-3RD-ZKProof-uai-258x129.jpg)](https://zkproof.org/events/workshop3/) #### **Our first webinar in the series will be held on February 17. The session, titled ‘zk-SNARKs from Bilinear Pairings’, will be led by Dr. Mary Maller.** Mary Maller is a researcher at the Ethereum Foundation (EF) who is primarily focused on theoretical cryptography and zero-knowledge proofs. In particular, her work has centered around designing proving systems with universal setups. Before joining EF she completed her PhD at the University College London (UCL) under the supervision of Sarah Meiklejohn and Jens Groth. In this session, Mary will explain how elliptic curves are used in zero-knowledge proof systems and provide an overview of some constructions based on bilinear pairings. **Participation is free, but requires registration.** [Register Here](https://zoom.us/meeting/register/uZQtdeGsqzItCIEmsgClziKUxW6Be0lfMA) We would love to receive feedback on the [ZKProof Community Forum](https://community.zkproof.org/) regarding topics that you would like to see addressed in future sessions and we encourage anyone interested in leading a session to reach out to us. See you at the webinar! The ZKProof Team [](#) Discover more from ZKProof Standards ------------------------------------ Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe [Continue reading](#) --- # Yuval Ishai, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=200&d=identicon&r=g) Yuval Ishai =========== October 15, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part II](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) In this two-part extended blog post I will discuss a modular approach to the design of efficient zero-knowledge proof systems that aims at maximizing the separation between the… * * * [0 Comments](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/#respond "title") 84 Minutes August 12, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part I](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) In this two-part extended blog post I will discuss a modular approach to the design of efficient zero-knowledge proof systems that aims at maximizing the separation between the… * * * [0 Comments](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/#respond "title") 60 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Tech Archives - ZKProof Standards Tech ==== This is a custom tag page for Tech. ----------------------------------- [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x172.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin, a recursive zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) [![](https://zkproof.org/wp-content/uploads/2021/06/cover_img_setup-uai-258x172.jpg)](https://zkproof.org/2021/06/30/setup-ceremonies/) June 30, 2021 ### [Setup Ceremonies](https://zkproof.org/2021/06/30/setup-ceremonies/) We often refer to zero-knowledge proofs monolithically, but… * * * [![](https://secure.gravatar.com/avatar/269929faf63fc4a46e78e3414a9e5e91?s=40&d=identicon&r=g)by Anthony Mpho Matlala](https://zkproof.org/author/tony007matlala/) [![](https://zkproof.org/wp-content/uploads/2021/06/Zeal-Twitter-banner-2-uai-258x172.png)](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) June 3, 2021 ### [Zebra: Zcash Zero-Knowledge Proofs at Scale](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) The Zcash protocol has used a number of different zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/b0a4d5878b49d2ddc7d783b4fa35105e?s=40&d=identicon&r=g)by Teor](https://zkproof.org/author/teor/) [![](https://zkproof.org/wp-content/uploads/2021/05/fiber-4814456_1920-uai-258x172.jpg)](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) May 5, 2021 ### [HashWires: Range Proofs from Hash Functions](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/651414b06e6324585def2c030b35590a?s=40&d=identicon&r=g)by Kostas Chalkias](https://zkproof.org/author/kostascrypto/) [![](https://zkproof.org/wp-content/uploads/2020/10/mitchell-luo-cuOKT4AI5Ro-unsplash-uai-258x172.jpg)](https://zkproof.org/2020/10/15/randomness-and-interactions/) October 15, 2020 ### [Playing with Randomness and Interactions to Prove Theorems](https://zkproof.org/2020/10/15/randomness-and-interactions/) In this blog post, I will go back to some of the early… * * * [![](https://secure.gravatar.com/avatar/dc3f0db7d6834d4f4d8308e5e309d092?s=40&d=identicon&r=g)by Antoine Rondelet](https://zkproof.org/author/antoinerondelet/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) October 15, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part II](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) August 12, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part I](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Eylon Yogev - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/02/ey.jpeg?fit=840%2C895&ssl=1) Eylon Yogev ----------- [](#) --- # Giacomo Fenzi - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2024/04/Giacomo-Fenzi.jpeg?fit=480%2C480&ssl=1) Giacomo Fenzi ------------- [](#) --- # Zero-knowledge proofs Archives - ZKProof Standards Zero-knowledge proofs ===================== [![](https://zkproof.org/wp-content/uploads/2021/09/ZBF-darlin-blogpost-SEP21_imageonly-uai-258x172.jpg)](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) September 29, 2021 ### [Darlin: Proof-carrying data based on Marlin](https://zkproof.org/2021/09/29/darlin-recursive-proofs/) In this blog post, we describe Darlin, a recursive zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/8319ce509f324b2a61563a7c8ea21031?s=40&d=identicon&r=g)by Ulrich Haböck](https://zkproof.org/author/ulrichhorizenlabsio/) [![](https://zkproof.org/wp-content/uploads/2021/06/cover_img_setup-uai-258x172.jpg)](https://zkproof.org/2021/06/30/setup-ceremonies/) June 30, 2021 ### [Setup Ceremonies](https://zkproof.org/2021/06/30/setup-ceremonies/) We often refer to zero-knowledge proofs monolithically, but… * * * [![](https://secure.gravatar.com/avatar/269929faf63fc4a46e78e3414a9e5e91?s=40&d=identicon&r=g)by Anthony Mpho Matlala](https://zkproof.org/author/tony007matlala/) [![](https://zkproof.org/wp-content/uploads/2021/06/Zeal-Twitter-banner-2-uai-258x172.png)](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) June 3, 2021 ### [Zebra: Zcash Zero-Knowledge Proofs at Scale](https://zkproof.org/2021/06/03/zebra-zcash-zero-knowledge-proofs-at-scale/) The Zcash protocol has used a number of different zk-SNARK… * * * [![](https://secure.gravatar.com/avatar/b0a4d5878b49d2ddc7d783b4fa35105e?s=40&d=identicon&r=g)by Teor](https://zkproof.org/author/teor/) [![](https://zkproof.org/wp-content/uploads/2021/05/fiber-4814456_1920-uai-258x172.jpg)](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) May 5, 2021 ### [HashWires: Range Proofs from Hash Functions](https://zkproof.org/2021/05/05/hashwires-range-proofs-from-hash-functions/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/651414b06e6324585def2c030b35590a?s=40&d=identicon&r=g)by Kostas Chalkias](https://zkproof.org/author/kostascrypto/) [![](https://zkproof.org/wp-content/uploads/2020/10/mitchell-luo-cuOKT4AI5Ro-unsplash-uai-258x172.jpg)](https://zkproof.org/2020/10/15/randomness-and-interactions/) October 15, 2020 ### [Playing with Randomness and Interactions to Prove Theorems](https://zkproof.org/2020/10/15/randomness-and-interactions/) In this blog post, I will go back to some of the early… * * * [![](https://secure.gravatar.com/avatar/dc3f0db7d6834d4f4d8308e5e309d092?s=40&d=identicon&r=g)by Antoine Rondelet](https://zkproof.org/author/antoinerondelet/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) October 15, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part II](https://zkproof.org/2020/10/15/information-theoretic-proof-systems-part-ii/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [![](https://zkproof.org/wp-content/uploads/2020/07/lego-3388163_1920-uai-258x172.png)](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) August 12, 2020 ### [Zero-Knowledge Proofs from Information-Theoretic Proof Systems – Part I](https://zkproof.org/2020/08/12/information-theoretic-proof-systems/) In this two-part extended blog post I will discuss a… * * * [![](https://secure.gravatar.com/avatar/bc6f168d839b4859172e94b2bb7902e9?s=40&d=identicon&r=g)by Yuval Ishai](https://zkproof.org/author/yuvalishai/) [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Izaak Meckler, Author at ZKProof Standards ![](https://secure.gravatar.com/avatar/77741d2b0efc0c5077e3938b8f9c8c71?s=200&d=identicon&r=g) Izaak Meckler ============= June 8, 2020 ### [Inductive Proof Systems and Recursive SNARKs](https://zkproof.org/2020/06/08/recursive-snarks/) This blog post describes a powerful technique for defining systems that allows for scalable, verifiable computation on partially private data. * * * [0 Comments](https://zkproof.org/2020/06/08/recursive-snarks/#respond "title") 13 Minutes [](#) [](#) [](#) Loading Comments...   Write a Comment... Email (Required) Name (Required) Website [](#) --- # Helger Lipmaa - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Helger-Lipmaa.jpg?fit=340%2C340&ssl=1) Helger Lipmaa ------------- University of Tartu, Estonia [](#) --- # Antonio Faonio - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/FAONIO-Antonio_00.jpeg?fit=457%2C640&ssl=1) Antonio Faonio -------------- [](#) --- # Alexander Hicks - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2025/02/Alexander-Hicks.jpeg?fit=200%2C200&ssl=1) Alexander Hicks --------------- [](#) --- # James Parker - ZKProof Standards ![](https://i0.wp.com/zkproof.org/wp-content/uploads/2023/06/JamesP.png?fit=350%2C350&ssl=1) James Parker ------------ **Research Engineer, Galois** James Parker is a Research Engineer at Galois with a background in programming languages and formal methods. His research spans guaranteeing the security and correctness of distributed systems, advancing secure computation, verifying information flow control mechanisms, and studying secure development practices. James earned his PhD in Computer Science at the University of Maryland. [](#) ---