A Survey on the Applications of Zero-Knowledge Proofs (2024)

II-B1 Frontends: From High-level code to circuits

This section explores the transition from high-level programming constructs to the more abstract representation as circuits, which are instrumental to the construction of a SNARK.

Consider the following Python function²²2A Practical Caveat: While the transition from Python code to an arithmetic circuit illustrates the conceptual process underlying the construction of SNARKs, it’s important to note that, in practice, directly translating high-level programming languages to circuit representations may not be computationally efficient. To address this, developers often utilize zero-knowledge domain-specific languages (often referred to as zk-DSLs) or similar frameworks specifically designed for creating zero-knowledge proofs. These will be explored later in section III-B.:

def function(a, b, c): square_a = a * a square_b = b * b square_c = c * c multiply_a2b2 = square_a * square_b multiply_b2c2 = square_b * square_c sum_terms = multiply_a2b2 + multiply_b2c2 return sum_terms

This function calculates the evaluation of a three-variate polynomial $f(a,b,c)=a^{2}b^{2}+b^{2}c^{2}$. Next, we represent this function as an arithmetic circuit. Arithmetic circuits are structured mathematical representations that decompose more-complex computations (such as the Python function above) into simple arithmetic operations (like addition and multiplication). This transformation, when coupled with the later transformations described below, will enable the properties of privacy and succinctness that enable the practicality of SNARKs.

II-B2 Arithmetization: From circuits to matrices

Arithmetization is the process of encoding the wiring and gate operations of a digital circuit or model of computation into a mathematical representation. In the context of zero-knowledge proofs, this often involves translating the circuit into a format that is suitable for the generation of a proof that the circuit’s execution satisfies certain conditions without revealing the specifics of the inputs or internal states. For brevity, we will focus on Rank-1 Constraint Systems (R1CS), which serve as a common arithmetization strategy for many zk-SNARKs. Some alternative arithmetization methods, namely Plonk-ish arithmetization, algebraic intermediate representations (AIR), and circuit constraint systems (CCS) have gained popularity in recent years as well [15, 16].

As a mental model, one can think of R1CS as a system that verifies all parts of a program by checking individual, linear parts of its computation, ensuring that all constraints are satisfied for the program to be considered correct.

The operations performed by our example circuit can be encoded into an R1CS by expressing each operation as a set of linear constraints. In R1CS, the constraints take the form of equations where the left and right sides must multiply to give the output. For our circuit, we introduce variables and intermediate ’witness’ variables to represent the computation steps. Here is how each operation in the circuit translates into constraints:

To encode these constraints into matrices $\mathbf{A}$, $\mathbf{B}$, and $\mathbf{C}$, we introduce the following variables: $w_{1}=a$, $w_{2}=b$, $w_{3}=c$, $w_{4}=a^{2}$, $w_{5}=b^{2}$, $w_{6}=c^{2}$, $w_{7}=a^{2}b^{2}$, $w_{8}=b^{2}c^{2}$, and $w_{9}=result$. Each matrix will have rows corresponding to constraints and columns corresponding to these variables, which can be further compressed as an array $\mathbf{w}=[1,a,b,c,a^{2},b^{2},c^{2},ab^{2},bc^{2},\text{result}]$.

The vector $\mathbf{w}$, often referred to as the ‘witness’, captures an execution transcript of the circuit. The witness contains the values of all variables and intermediate steps that satisfy all the R1CS constraints for the given inputs. Given that anyone with a witness $\mathbf{w}$ can execute the circuit to verify if $\mathbf{w}$ is valid, a correct execution transcript $\mathbf{w}$ can be viewed as a proof that the computation was carried out correctly and that all of the R1CS’s constraints are satisfied. If, at any point, an attacker obtained access to the R1CS or witness vector, access to the inputs, intermediate values, and outputs of the computation would be leaked.

Up to this point, there is no way to prove, in a publicly-verifiable way, that the computation was performed correctly without allowing others to re-run the computation themselves. The next section, however, converts the R1CS into a form that allows for maintaining privacy while allowing for public-verifiability and a sublinear verifier runtime.

II-B3 Backends: From matrices to polynomials

The backend phase of the SNARK lifecycle involves transforming the Rank-1 Constraint System (R1CS) matrices into a set of polynomial equations that form a Quadratic Arithmetic Program (QAP). This transformation is key to creating a SNARK, as it allows for the efficient verification of the computations represented by the R1CS. Succinctness, a property of SNARKs integral to a sub-linear verifier runtime, is achieved by encoding the matrix operations from the R1CS into polynomial equations. This more succinctly represents the original circuit’s execution trace without sacrificing the soundness guarantees of the underlying argument.

Mathematically, a QAP is defined as a set of polynomial equations derived from the R1CS [17]. For matrices $\mathbf{A},\mathbf{B},\mathbf{C}$ of size $m\times n$, where $m$ is the number of constraints and $n$ is the number of variables, we define the QAP as follows: Let $\{A_{i}(x)\}_{i=1}^{m}$, $\{B_{i}(x)\}_{i=1}^{m}$, and $\{C_{i}(x)\}_{i=1}^{m}$ be sets of polynomials where each $A_{i}(x),B_{i}(x),C_{i}(x)$ is a polynomial corresponding to the $i^{th}$ row of $\mathbf{A},\mathbf{B},\mathbf{C}$ respectively. Then, the QAP consists of the set of equations $\{A_{i}(x)\cdot B_{i}(x)-C_{i}(x)=h(x)\cdot Z(x)\}_{i=1}^{m}$, where $h(x)$ is the polynomial that represents a solution to the R1CS, and $Z(x)$ is a verifier-chosen, fixed polynomial that evaluates to zero at $\{x_{1},x_{2},\ldots,x_{m}\}$, the set of distinct points associated with each constraint.

The QAP allows for the succinct representation of the R1CS and enables the prover to compute a single proof, which is a small set of polynomial evaluations. This proof attests that there exists a polynomial $h(x)$ that satisfies the QAP equation, implying that the prover knows a witness $\mathbf{w}$ that satisfies the R1CS.

The verifier, given the proof and the public polynomials $A(x)$, $B(x)$, and $C(x)$, can efficiently check the QAP verification equation without having to perform the full set of R1CS computations. This results in a verification process with a significant speedup over computing the function represented by the circuit directly.

In summary, the conversion from matrices to polynomials and the creation of a QAP forms the bridge between the arithmetic circuit and the final SNARK. This process ensures that a valid execution of the circuit, one that satisfies all the constraints, is encoded into a format that supports the creation of a compact, easily verifiable proof. The integrity of this transformation is fundamental to the trustworthiness and security of the SNARK.

III-A1 Motivation and Definition

With the increased dependency on distributed computing in industries such as blockchain and cloud computing, the importance of private computing at a large scale grew exponentially. ZKPs offer a solution for providing an environment that performs computations in a trustworthy manner through a zero-knowledge virtual machine (zkVM). A zkVM is a virtual machine (VM) designed to generate an efficiently verifiable proof for executing an arbitrary computation while preserving the privacy of the program and its data in zero knowledge. The zkVM acts as a programmable ZK circuit that implements a VM, receives public and private inputs, and creates a certificate of valid execution. Similar to a generalized virtual machine, a zkVM maintains its own virtualized components, such as memory management, instruction scheduling, error handling, and others, using a privacy-focused approach with the help of a ZKP.

The motivation for building zkVMs stems from the desire to reduce the complexity of creating a ZKP. Previously, to produce a ZKP, a developer needed to have a strong background in cryptography, develop a circuit representation of their program, set up a backend for each proof, and have a large amount of computing power. To abstract away these steps from the developer, zero-knowledge virtual machines were developed with these features in mind.

III-A2 Methodology

The first step of most zkVMs is to receive an input program from a higher-level language such as C++, Circom [23], Rust, or others. The program is then compiled to bytecode that the VM can translate to an instruction set architecture (ISA) that is generalized, like RISCV, or specialized, such as Miden Assembly [24]. These ISAs are minimal and optimized for cryptographic operations such as hashing to optimize the performance of the zkVM.

Depending on the proving system, the setup phase begins after the program has been interpreted and translated to bytecode. This step involves tasks such as concealing private inputs, initializing a polynomial commitment scheme, key generation, and others. A set of constraints is placed on the program and the witness to enforce computational integrity in the computation trace. Building on what was mentioned in Section 2, constraints ensure the zkVM execution trace follows the guidelines outlined in the ISA. Every constraint is a polynomial for each statement inside the execution trace.

To check the validity of each instruction in the execution trace, a verifier can open any instruction in the zkVM to verify it was computed correctly. The prover defines a polynomial for each statement that the verifier can use the polynomial commitment scheme to verify. The verifier receives this polynomial and responds with a random value for evaluating the prover’s polynomial. If the verifier concludes that the output is correct, then the statement in question is also considered correct.

The zkVM distinguishes itself from writing a specialized circuit for computations due to its high optimization level and reduction of complexity from designing a circuit. In a ZK computation, three common overheads must be taken into account:

By prioritizing efficiency in cryptographic protocols that leverage zero-knowledge proofs, zkVM enhances the performance of applications involved in secure data exchange, anonymous transactions, and confidential smart contracts. This optimization ensures that cryptographic operations, integral to privacy-preserving technologies, are executed with heightened speed and effectiveness.

The projects in the timeline are an overview of the prominent zkVMs over the last decade such as TinyRAM [25], Hawk [26], Zinc [27] , RISC Zero [28], CarioVM [29], Leo [30], Miden [24], Triton [31], OlaVM [32] , Powdr [33], and Jolt [34]. Some other zkVMs that are on the rise as of writing this paper are SP1 [35], Nexus [36], and Valida [37].

A project in the space is RISC Zero’s [28] zkVM which allows users to demonstrate the accurate execution of arbitrary Rust and C++ code. This enables the construction of zero-knowledge applications that leverage the variety of existing Rust packages. Functioning as a verifiable computer, the zkVM mimics the operations of a genuine embedded RISC-V micro-processor, thus allowing any program that can compile down to the RISC-V instruction set to run on the zkVM. This emulation not only facilitates the development process for developers but also simplifies the creation of powerful zero-knowledge applications. RISC Zero also mains a ZK Validity Proof System that empowers users to substantiate the validity of Ethereum blocks. The zkVM is equipped to function on different computer systems, program sizes, hardware targets, and runtime/memory requirements.

Starkware [29], the company behind zk-STARKs (Zero Knowledge Scalable Transparent Argument of Knowledge) applications, created CairoVM. CairoVM is an efficient and practical architecture specifically compatible with the STARK proof system. It instantiates a STARK based von-Neumann architecture known for its instruction set that allows support for traditional language features such as conditional branching, function calls, recursion, and its ability to have a deterministic or a nondeterministic nature in aspects like its restrictive memory model. The bytecode of the Cairo zkVM, which are generated by the Cairo assembler, represents the input program from a given user. From there, the Cairo Runner is used to obtain the execution trace of the program. The Cairo Runner is a computer program designed for the execution of a compiled Cairo program that operates in a distinctive manner compared to running a typical computer program. The key disparity arises from Cairo’s support for nondeterministic code. Finally, a STARK prover for the Cairo AIR mentioned in Section 2 is employed to generate a proof for the assertion from the program.

Polygon’s Miden VM [24] is another zkVM built to contribute to a zero-knowledge rollup, which is a modular second layer blockchain built on top of another blockchain such as Ethereum. Miden extends the capabilities of Ethereum by introducing features such as parallel transaction execution and client-side proving. This empowers developers to craft high-throughput and privacy-preserving decentralized applications (dApps) for sectors like DeFi, RWA, and the Metaverse. Popular programming languages like Rust are supported by Miden, which gives developers flexibility and familiarity. Another feature of Miden VM lies in its automatic generation of a STARK-based proof of execution for any program that runs on it. Miden VM operates by consuming programs in the form of a Merkelized Abstract Syntax Tree (MAST), where each node represents a code block in a binary tree structure. Execution begins at the tree’s root, recursively processing each required block based on its semantics. If the execution of any code block encounters failure, the VM halts, preventing the execution of further blocks. The program structure involves a binary tree arrangement, with leaves containing linear instruction sequences and internal nodes determining control flow. As a stack machine, Miden VM utilizes a push-down stack of practically unlimited depth, aligning with the architecture of a STARK. The Miden standard library enhances functionality by providing optimized implementations of commonly-used primitives. This library facilitates the reduction of shared code between parties involved in proving and verifying program execution, achieved by serializing calls to standard library procedures as a fixed 32 bytes, irrespective of the procedure’s size. These design goals collectively contribute to Miden VM’s efficiency, flexibility, and security.

In conclusion, zkVMs offer a broader spectrum of applicability through its support for general and specialized computation. A zkVM is designed to accommodate a wide range of computations unlike some zero-knowledge proof systems. This flexibility permits developers to implement complex algorithms and diverse computations while benefiting from the privacy and security guarantees inherent in zero-knowledge proofs.

III-B1 Motivation and Definition

A zkDSL (zero-knowledge domain specific language) is a programming language written specifically to provide the programmer a connection between a high-level representation of a program and the low-level intricacies of a ZKP such as writing circuits.

III-B2 Methodology

Some zkDSLs that are listed are O1JS [38], Circom [23], Cairo [29], Noir [39], Juvix [40], and Lurk [41],.

The goal of a zkDSL is to translate a high-level language into an arithmetic circuit that can be passed into a proving system to output a proof on execution of a given program. Some of the most common circuits targeted are R1CS, Plonk, and AIR, as shown in the Arithmetization Schemes table 5. Each language has a niche that it is trying to fulfill. For example, Circom is a language that is focused on writing arithmetic circuits whereas Lurk is meant to be a generalized programming language.

While zkDSLs achieve the goal of abstraction, some drawbacks must be considered. First, zkDSLs encounter challenges in memory management complexity, primarily due to the inherent intricacies associated with zero-knowledge proofs and cryptographic computations. The nature of zkDSLs, which often involve complex mathematical transformations and intricate circuit representations, demands efficient memory management strategies. The need to handle cryptographic primitives, large-scale boolean circuits, and data structures introduces complexities that traditional memory management systems may find challenging to navigate. Languages like Cairo implement optimization techniques in their compiler or VM to reduce this overhead through constraint reduction and cycle elimination.

Second, for some time, zkDSLs have a history of problems with the developer paradigms of recursion, conventional conditionals (excluding ternaries), mutable variables, and user-defined structures, causing unique coding challenges. Recursion, a staple in conventional programming, faces challenges due to the absence of a direct stack and the deterministic path required by circuit-based computation. The representation of if-else statements becomes intricate within algebraic circuits, favoring ternary expressions but sacrificing the straightforwardness of traditional conditionals. The immutability inherent in algebraic circuits complicates the emulation of mutable variables that change state during computation. Furthermore, the structured and hierarchical nature of user-defined structures, commonplace in languages like C++, presents a unique set of challenges. Developers navigating the ZKP circuit structure must consider these drawbacks, as the departure from traditional programming paradigms necessitates a reevaluation and adaptation of coding practices.

III-B3 Applications

A classic example of a zkDSL is the circuit writing language Circom [23], which has been used in applications such as TornadoCash [42] or DarkForest [43]. Circom represents both a programming language and a compiler designed for the creation of arithmetic circuits that are subsequently compiled into Rank-1 Constraint Systems (R1CS). This intricate process allows programmers using Circom to articulate arithmetic circuits at a constraint level, with the compiler generating a file containing the R1CS description, as well as WebAssembly and C++ programs. These output programs facilitate the computation of all circuit values. Additionally, an open-source library, Circomlib [44], features circuit templates to be used in to support writing other circuits. On top of that, O1JS [38] is a library proficient in generating and validating Zero-Knowledge (ZK) proofs derived from R1CS. Collectively, this suite of software tools serves to abstract the intricacies of ZK proving mechanisms, providing an interface for modeling low-level descriptions of arithmetic circuits.

Lurk [41] is a Turing complete LISP-based programming language that autonomously generates zk-SNARKs for arbitrary programs. It presents programs as data to the universal Lurk interpreter circuit to achieve Turing completeness without compromising the size of the proof artifacts generated. This departure from traditional approaches aims to enhance the scalability and capabilities of a ZKP. Further, the need for ad-hoc compilation of programs into flat circuits, a conventional process that imposes significant constraints on the size and complexity of achievable computations, is eliminated.

Leo [45] is a programming language designed for the development of formally verified zero-knowledge applications on the blockchain. Leo establishes a execution environment devoid of restrictions on running time, stack size, or instruction sets, offering flexibility. Beyond the intrinsic benefits of ensuring application privacy and mitigating maximal-extractable value (MEV), Leo has two other helpful properties. Firstly, applications undergo formal verification concerning their high-level specifications. Secondly, the succinct verification of applications is made accessible to anyone, irrespective of the application’s size. Leo maintains a set of tools, including a testing framework, package registry, import resolver, remote compiler, formally defined language, and theorem prover, specifically tailored for general-purpose zero-knowledge applications.

To summarize, zkDSLs emerge as versatile tools with a broad spectrum of applications, ranging from smart contract programming to general computation. These specialized languages are instrumental in the development of privacy-preserving features within smart contracts, facilitating secure and confidential transactions on blockchain networks. Beyond blockchain, zkDSLs find utility in general computation scenarios, where their application extends to fields such as data privacy, machine learning, secure distributed computations, and confidential data analysis. In cryptographic applications and security protocols, zkDSLs play a pivotal role by enabling the creation of proofs for statements related to cryptographic properties, thereby enhancing the security and privacy of digital transactions and communication. This versatility positions zkDSLs as valuable tools for developers working on various applications, providing a user-friendly interface to harness the power of zero-knowledge proofs in diverse domains.

III-C1 Motivation and Definition

In the domain of zero-knowledge proofs (ZKP), the development process often entails numerous operations characterized by a high barrier to entry, necessitating a profound understanding of computational strategies, cryptographic primitives, elliptic curves, and the intricacies of ZKP mechanisms. For developers, the hardship lies in crafting reusable code and mitigating redundancy, particularly within ZK proofs, where constraints such as circuit size and gas usage can impose significant limitations. To address these challenges, a multitude of libraries have emerged, offering implementations for cryptographic “gadgets” that facilitate the construction of Rank-1 Constraint Systems (R1CS) instances from modular “gadget” classes as listed in TableIII. To faciliate the proving and verification process, elliptic curves as utilized, as mentioned in the previous section. Operations on these curves is relatively standardized and does not always need to be recreated, so libraries avoid the issue of duplicated code in this area. The combination of circuit gadgets and elliptic curves allow for the modular composition of an application in conjunction with a compatible proving system such as Groth16 [21] or Bulletproofs [22]. These libraries play a crucial role in abstracting the complexities of preprocessing in a modular manner, enabling developers to focus on higher-level design aspects and promoting code reusability across ZKP applications. This emphasis on modularization and abstraction enhances development efficiency and advances innovation within the ZKP domain by fostering collaboration and knowledge sharing among developers.

III-C2 Methodology

In the design of ZKP frameworks and libraries, several fundamental principles are leveraged to optimize performance and efficiency. One crucial aspect is the operation over small fields, as demonstrated by systems like ethSTARK [46] and Plonky2 [47]. Unlike traditional elliptic curve groups, which require large field sizes (e.g., 256 bits) for standard security levels, these systems utilize smaller prime fields (e.g., 64 bits). This approach capitalizes on the efficiency of small-field arithmetic, resulting in state-of-the-art proving performance. Additionally, using small-field elements reduces storage requirements, improving CPUs’ cache efficiency. Another critical consideration is the flexibility in field selection. These schemes often use computationally structured fields, providing additional optimization opportunities. Finally, these frameworks and libraries prioritize using cheaper cryptographic primitives, ensuring cost-effective and efficient ZKP implementations [48].

Abstracting away finite field operations holds paramount importance in zero-knowledge proofs (ZKPs).This endeavor necessitates the implementation of fundamental arithmetic operations, including addition, subtraction, multiplication, (modular) exponentiation, and inverse exponentiation, over finite fields. Considering these operations are used so heavily in constructing a ZKP, their modularity and efficiency must be implemented to suffice for any use case. [49]

In elliptic curve cryptography, an elliptic curve is typically defined over a prime field of a specific order denoted as $F_{q}$. The elliptic curve group ($E(F_{q})$) comprises the subgroup of points within the field that lie on the curve, including a distinguished point at infinity. While some SNARKs function over elliptic curves without necessitating pairings, others rely on pairings and thus necessitate pairing-friendly elliptic curves. Pairings, a fundamental operation in cryptographic protocols, involve taking an element from the first group ($G_{1}$) and another element from the second group ($G_{2}$) to compute an element in the target group ($G_{T}$), typically denoted as $e(P,Q)$, where $P$ belongs to $G_{1}$ and $Q$ belongs to $G_{2}$. Efficient implementation of pairings, scalar multiplication, and multi-scalar multiplication (MSM) over pairing-friendly elliptic curves is essential for achieving computational efficiency. Therefore, prioritizing the efficient implementation of these operations is crucial for optimizing the performance of cryptographic protocols relying on pairing-friendly elliptic curves.[49]

To facilitate proof verification, ZKP frameworks often include the specification of cryptographic primitives within their design at the cost of the core SNARK implementation’s efficiency, as mentioned above. However, not all computations conform to arithmetic modulo $p$, necessitating the development of circuits for non-native field operations. For instance, verifying elliptic-curve-based cryptographic primitives, such as ECDSA signatures, requires computations over a different field, such as $\mathbb{Z}_{q}$, which SNARKs do not natively support. Additionally, SNARKs often exhibit inefficiencies when dealing with traditional hash algorithms and signature schemes, like SHA-2 and ECDSA. To address this, the community has proposed SNARK-friendly alternatives, such as Poseidon Hash, Keccak Hash, Pedersen Hash, MIMC Hash, and Ed25519 (EdDSA signature), which are specifically optimized for use within SNARKs. Despite the benefits of utilizing SNARK-optimized primitives, practical applications often necessitate CPU-optimized primitives due to constraints in non-native field arithmetic. For example, some applications require the verification of ECDSA signatures, which involves non-native field arithmetic, leading to numerous constraints that increase the complexity and verification time of the proof. [49]

By writing these building blocks piece by piece, researchers and developers can create SNARKs across diverse settings, thus facilitating informed decision-making and enhancing the practical utility of SNARK-based cryptographic protocols.

III-C3 Applications

Arkworks [50] is a Rust ecosystem tailored for zkSNARK programming, offering a set of libraries to streamline zkSNARK application development. These libraries implement essential components, including generic finite fields and R1CS constraints, enabling developers to integrate zkSNARK functionalities into their applications seamlessly. Arkworks also provides interfaces for various purposes, such as defining interfaces for SNARKs and relations (e.g., R1CS, AIR) and offering SNARK proving systems like Groth16 and Marlin. Further, the ecosystem includes tools for circuit building and algebraic operations for finite fields and elliptic curves, empowering developers to implement zkSNARKs in their projects efficiently.

Gnark [51] is a library that enables developers to design circuits using the programming language Go. It employs a versatile API and command line interface to accomplish the ZKP process in a familar way to developers. The two proving schemes that Gnark supports are Groth16 and Plonk, along with a variety of elliptic curves for developers to choose ranging such as BN254, BLS12-381, and BLS12-377. A core focus of the Gnark library is speed of the prover and verifier, since it offers an API for both the frontend and the backend of the proving process. The standard library of Gnark implements common functions such as the MiMC hash function, EdDSA signature verification, Merkle proof verification, and a generalized zk-SNARK verifier. The performance of circuits written in Gnark can be analyzed using the in suite profiling tools available within the library.

CirC [52] is a project dedicated to compiler infrastructure for cryptosystems and verification. It focuses on cryptographic tools such as proof systems, multi-party computation, and fully hom*omorphic encryption, typically applied to computations expressed as systems of arithmetic constraints. These applications require compilers that can translate high-level programming languages (e.g., C) into such constraints. CirC aims to provide a shared infrastructure for building constraint compilers, offering a valuable resource across various applications. These compilers can translate code into a Rank-1 Constraint System (R1CS), enabling efficient implementation of cryptographic protocols and verification mechanisms. Circify simplifies certain aspects of supporting a new language by transforming stateful programs with complex control flow into flat circuits. However, it does not address language-specific features like type-checking and namespacing. Circify supports various frontends, including C, ZoKrates [53] (Z#) and Circom. This flexibility allows developers to choose or build the frontend that best suits their needs while benefiting from Circify’s capabilities in managing program transformations for cryptographic applications.

The TypeScript library O1JS [38] is designed to cater to users with a web development background, offering a user-friendly approach to writing ZK programs and smart contracts for the Mina [54] blockchain. It is described as “an embedded DSL” and is executed as normal Typescript. This library permits developers to write arbitrary ZK programs utilizing many built-in provable operations, including basic arithmetic, hashing, signatures, boolean operations, and comparators. With o1js, developers can create zkApps on Mina, smart contracts that execute client-side and handle private inputs. The entire o1js framework is packaged as a single TypeScript library, making it accessible in web browsers and Node.js environments, thus allowing developers to integrate their ZK programs into existing web applications.

Various implementations of Zcash’s Halo2 [55] proving system, such as those by Axiom and the Ethereum Foundation, provide fundamental primitives for writing zero-knowledge proof circuits. The proving system involves several stages, from committing to polynomials that encode the main components of the circuit, including cell assignments, permuted values, products for lookup arguments, and equality constraint permutations. The next step is constructing the vanishing argument, which constrains all circuit relations to zero, including standard and custom gates, lookup argument rules, and equality constraint permutation rules. The polynomials are then evaluated at all necessary points, including relative rotations used by custom gates and vanishing argument pieces. Finally, the multipoint opening argument is constructed to ensure the consistency of evaluations with their commitments, and the inner product argument is run to create a polynomial commitment opening proof for the multipoint opening argument polynomial. Halo2 is known as a relatively low-level library with high customizability.

Nova [56] is a recursive SNARK that enables incrementally verifiable computation (IVC), a cryptographic primitive that allows a prover to produce a proof of correct execution of a “long-running” sequential computation in an incremental fashion. IVC allows for proofs to build on top of each other in an efficient fashion that speeds up the entire proving and verification process. Nova is implemented in Rust and supports three curve cycles: Pallas/Vesta, BN254/Grumpkin, and secp/secq. It supports frontends such as Bellpepper [57], and its native APIs accept circuits expressed with Bellpepper, Circom, and Lurk.

III-D1 Motivation and Definition

Historically, the speed and memory requirements of ZK proof generation have limited their applicability. The required computations inside of a ZKP, such as hashing, multi-scalar multiplications, and fast-fourier transforms, create a burden for each use case. To reduce the overhead required by ZKPs, various projects have emerged to enhance the performance of ZKPs and their potential implementations.

III-D2 Methodology

Hardware acceleration is defined as the use of optimizing or creating dedicated computer components to improve the performance and efficiency of a specific operation. The main instruments used for this acceleration such as field programmable gate arrays (FPGAs), graphics processing units (GPUs), and application-specific integrated circuits (ASICs) in the ZK world. The limiting factors of hardware acceleration projects are the memory capacity, speed of memory access, speed of data transfer, and speed of arithmetic units. In proof systems where both number theoretic transforms (NTTs) and multi-scalar multiplications (MSMs) are used, the majority of the proof generation time is spent on MSMs, with NTTs accounting for the remainder. Both MSMs and NTTs present performance challenges that can be addressed in several ways. MSMs can be executed on multiple threads, allowing for parallel processing. However, when dealing with large vectors of elements, the multiplications may still be slow and demand considerable memory resources. Additionally, MSMs face scalability issues and can remain sluggish even when extensively parallelized. On the other hand, NTTs involve frequent data shuffling during the algorithm, making them difficult to distribute across a computing cluster. They also require significant bandwidth when run on hardware due to the need to load and unload elements from large datasets. For instance, if a hardware chip has 16GB of memory or less, running NTTs on a dataset larger than 100GB would necessitate data transfers over the network, significantly slowing down the operations [58].

Both MSM and NTT can be accelerated on GPUs, particularly MSM through an algorithm called ‘Pippenger’. This process involves rewriting the computationally intensive tasks from the CPU to the GPU using CUDA or OpenCL, allowing the code to be compiled and executed directly on the GPU. For finer-grained acceleration, developers can optimize memory usage by maximizing the use of fast memory and minimizing slow-access memory to reduce costly data transfers, especially between the CPU and GPU. Additionally, optimizing execution configuration by balancing work across multiprocessors, building concurrent kernels, and allocating resources judiciously can maximize hardware utilization. The goal is to parallelize the entire workflow, minimizing sequential execution where different parts depend on each other’s results. Open-source implementations allow developers to quickly start their modifications [59].

FPGAs, or field-programmable gate arrays, offer programmable hardware fabric that can be reconfigured multiple times, cutting manufacturing costs compared to ASICs and providing greater flexibility in hardware resource usage than GPUs. Although optimizing NTTs on GPUs is achievable, frequent data shuffling can lead to significant communication overhead between the GPU and CPU. By implementing the logic directly into the circuit design, FPGAs can potentially perform the task faster. Most open-source implementations for zero-knowledge proofs are written in Rust due to its memory safety and cross-platform compatibility. However, FPGA development tools are typically adapted to C/C++, requiring teams to translate these implementations [60].

GPUs offer fast development times with well-documented frameworks like CUDA and OpenCL and are readily available and cost-effective. However, GPUs are power-hungry, even when exploiting data and thread-level parallelism. In contrast, FPGAs have a more complex development cycle, requiring specialized engineers but allowing for low-level optimizations and providing lower latency, especially for large data streams. FPGAs are more expensive and less readily available than GPUs [58].

ASICs, or application-specific integrated circuits, are customized for particular uses and are permanently etched into silicon, making the design and manufacturing process much more complex and time-consuming compared to FPGAs. Despite this, advancements such as Leo’s new integrated chip for accelerated proof generation demonstrate ongoing developments in this area. ASICs are believed to be the most promising hardware acceleration; however, they still have major barriers to entry. Programmability and logic modifications are difficult on ASICS as they possess write-once business logic, necessitating a complete rebuild of the system for any modifications. Conversely, FPGAs and GPUs can be reprogrammed multiple times, allowing the same hardware to be used across various projects with different proof systems or updates. This reprogrammability makes FPGAs a more versatile alternative compared to ASICs. Additionally, the time required for ASIC design, production, and deployment usually spans 12 to 18 months or more [58].

III-D3 Applications

Ingonyama [61] is a hardware acceleration company that integrates chip design with mathematics and advanced algorithms to enhance the performance of compute-intensive cryptography. They maintain a library called ICICLE, a cryptography library for ZKPs using GPUs. ICICLE implements various cryptographic primitives such as elliptic curve (EC) operations, multi-scalar multiplication (MSM), number theoretic transform (NTT), and the Poseidon hash on GPUs. The Polynomial API offers a framework for polynomial operations for developer convenience. Additionally, ICICLE has bindings for Rust and Golang and integrates with projects like Gnark and EZKL. It can also be run in Google Colab. Ingonyama is advancing for a zero-knowledge processing unit (ZPU) defined as “a versatile and programmable hardware accelerator, designed to address the emerging needs of ZKP processing.”

Cysic [62] is a ZK accelerator focused on developing ASICs and their accelerated zkVM. The system architecture features an executor responsible for executing programs, hardware for controlling and distributing segments, and a configurable number of specialized chips to generate ZK proofs for each segment program. Leveraging its expertise in ASIC design and GPU engineering, Cysic aims to overcome challenges by offering ZK compute-as-a-service to various ZK projects. They aim to produce ASICs that specifically target MSMs, NTTs, and other general operations, while maintaining flexibility to adapt to many proving systems. Cysic’s ongoing efforts concentrate on specialized ASIC design for real-time ZK proof generation.

Fabric Cryptography [63] introduces The Fabric Verifiable Processing Unit (VPU), a processor designed for cryptography applications ranging from ZKP to FHE. The VPU features a custom instruction set architecture tailored for next-generation cryptography, including ZKP, FHE, MPC, and other algorithms. It offers acceleration for MSM, NTT, polynomial evaluation, as well as Poseidon (1, 2), Blake, and other hash functions. The VPU supports multiprecision vector lanes up to 384-bit and includes a RISC-V core for enhanced programmability. It supports PCIe 4.0 x16 lanes, providing up to 256 Gbps per chip, and is equipped with high-bandwidth DRAM. In addition, Fabric Cryptography offers a PCIe card featuring 3x FC1000 chips for parallel ZK proof generation, a PCIe interface for comprehensive on-chip proving and encryption, and DRAM for recursive ZK proof generation and mining workloads. They also provide server systems and data centers to support larger workloads.

Irreducible [64] offers proving as a service designed for scalability, powered by FPGA-accelerated server clusters. Irreducible supports popular proof systems such as Plonky2 and Polygon zkEVM, with plans to support next-generation systems like Binius and Plonky3. Their FPGA-accelerated server clusters are specifically designed for cryptographic computation at scale. By connecting their FPGAs directly using AMD’s high-speed Aurora protocol, they minimize unnecessary data transfers between the CPU and FPGAs. Operating independently of public cloud infrastructure providers like Amazon Web Services and Google Cloud Platform provides redundancy essential for the decentralized networks they support. Irreducible also features a fully-pipelined FPGA architecture for ZKP-friendly Merkle trees using the Poseidon hash and NTT.

Supranational [65] offers hardware-accelerated cryptography for verifiable and confidential computing. They provide BLST, an IETF-compliant BLS12-381 signature library focused on security and performance. They also implement a simple API for generating VDF and SNARK proofs, powered by fast, open-source implementations running on a high-availability cloud. Additionally, Supranational is developing Sppark, an arbitrary-precision arithmetic accelerator for cryptographic operations, including VDFs, SNARKs, polynomial commitments, and accumulators.

IV-A1 Motivation and Definition

Layer 1 blockchains, such as Ethereum and Bitcoin, are foundational blockchain networks that provide a transparent and immutable ledger for data storage. However, these platforms face challenges in privacy and scalability. The emergence of zero-knowledge proofs (ZKPs) has induced the development of novel Layer 1 solutions that prioritize privacy and data efficiency. These blockchains integrate ZKPs directly into their base layers, offering a dual advantage: enhanced privacy through transaction concealment and improved scalability via data compression, as illustrated in Figure 8. The primary motivation for ZKP-based Layer 1 blockchain is to bridge the gap between the inherent transparency of conventional blockchains with the increasing demand for data privacy and efficient on-chain data management.

IV-A2 Methodology

Layer-1 blockchains utilize ZKPs to obscure critical transaction details, such as the identities of parties involved and the transaction amounts. This concealment is achieved through advanced cryptographic techniques, including zk-SNARKs or zk-STARKs, that validate transactions without revealing their underlying data. To address scalability challenges, ZKP-based Layer-1 blockchains employ state compression. This technique utilizes ZKPs to create compact proofs that validate large sets of transactions or state transitions, thereby reducing the data volume required on-chain. In these networks, participating nodes are responsible for generating and verifying ZKPs. This ensures transaction integrity while maintaining privacy. The consensus mechanisms of these blockchains are uniquely designed to incorporate ZKP validation. This integration ensures that only transactions authenticated through ZKPs are confirmed and appended to the blockchain.

IV-A3 Applications

As a pioneering Layer 1 blockchain, ZCash [66] utilizes zk-SNARKs to offer private transactions, where the details of the sender, receiver, and transaction amounts are encrypted. In ZCash, zk-SNARKs enable the encryption of transaction data, ensuring the anonymity of both the sender and receiver, as well as the confidentiality of the transaction amount. This mechanism allows the network to validate transactions without disclosing the underlying data, thereby preserving the privacy of users. ZCash’s implementation of zk-SNARKs is notable for its efficiency, allowing for the verification of transactions in a matter of milliseconds, which is a significant advancement over other cryptographic techniques that were more computationally intensive. The ZCash blockchain leverages a novel cryptographic method known as a “shielded transaction,” where the transaction metadata is encrypted, and zk-SNARKs are used to prove that the transaction does not violate the network’s consensus rules. This approach enables a high degree of privacy while maintaining the integrity and security of the blockchain. ZCash offers optional privacy features allowing users to choose between shielded and transparent transactions, unlike Aleo and Monero, where privacy is mandatory for all transactions as depicted in Table VI.

Aleo [30] is a distinctive Layer 1 blockchain platform that employs zero-knowledge proofs to enhance privacy and scalability in decentralized applications (dApps). It is designed to facilitate the development and deployment of private applications on the blockchain. Aleo achieves this with the help of a unique framework for constructing dApps that can perform computations in a private and verifiable manner. Its adoption of zk-SNARKs based systems allows developers to create applications where users can interact and transact without revealing sensitive information. This system empowers users to maintain control over their data, ensuring privacy and security in their interactions on the blockchain. Aleo’s approach to blockchain architecture is focused on providing a scalable solution that addresses the common limitations associated with public blockchains, such as privacy concerns and throughput bottlenecks.

The Mina Protocol [54] is an innovative Layer 1 blockchain that introduces a unique approach to scalability and privacy through the use of recursive zk-SNARKs. This innovative protocol is designed to maintain the succinctness of a blockchain by keeping the network size constant (22kB) regardless of the total number of transactions processed. This is achieved through the recursive composition of zk-SNARKs, which allows each new block to contain proof of the validity of the entire blockchain history. As a result, the Mina Protocol maintains a drastically reduced blockchain size compared to traditional blockchains, enhancing scalability and usability.

IV-B1 Motivation and Definition

As aforementioned, ZKP can be used for the property of data succinctness, especially when it comes to blockchain validity proofs. A significant pain point of blockchains is the scarcity and cost of block space, which can be solved using Layer 2 scaling solutions such as rollups. The most prominent types of rollups are optimistic rollups and ZK rollups, but the latter will be our main focus. In ZK rollups, zero-knowledge proofs are used to succinctly prove the validity of state changes to a Layer 1 blockchain without requiring validator nodes on a Layer 1 chain to execute those transactions. In essence, the Layer 2 rollup becomes a cheap modular execution layer that benefits from the security and decentralization of Layer 1, and this enables blockchains to scale by significantly reducing usage costs. Some ZK rollups can also provide privacy-preserving properties using zero-knowledge proofs.

IV-B2 Methodology

In Layer 2 rollups [67] (all of which achieve finality on Ethereum), computation is handled outside of Layer 1, and only state changes, deposits, and withdrawals are posted to Layer 1 through the rollup smart contract. This Layer 1 smart contract contains and maintains a state root, which is the Merkle tree root of the state of the rollup, including accounts and balances. A rollup sequencer is an entity, which could range from a single server to a decentralized network of nodes, which orders transactions, produces L2 blocks, and adds rollup transactions to the ZK-rollup contract with a ZK validity proof. The sequencer publishes a batch of highly compressed transactions as well as the previous state root and the new state root after processing all transactions in the batch. Using the ZK validity proof provided by the sequencer, the rollup contract checks that the new state root is valid, then swaps the old root for the new one. The transaction batches published by sequencers are written to Ethereum in the form of encoded function calls, stored either in the calldata of the EVM, which is a data area used to pass arguments to a function and does not modify the blockchain’s state, or in temporary data storage locations called blobs (post-EIP-4844). This serves as a cheap way to store data on-chain, making it possible for individuals to re-construct the state of the rollup using such compressed transactions. Since the Layer 1 rollup contract can quickly verify a zk-SNARK or zk-STARK proof on any amount of large computation, computation is almost fully offloaded to the Layer 2. Through these methodologies, ZK rollups minimize the space and computation restraints of Layer 1 Ethereum, which simply validates state changes and provides inherent decentralization and security [67].

Because Layer 2 scaling solutions are built on top of smart contract-based blockchains, specifically Ethereum, rollups need to provide proofs for state transitions on the Ethereum Virtual Machine (EVM), which is Ethereum’s Turing-complete computation engine. Since ZK-rollups must attest to the correctness of computations with ZKP before posting batches to Layer 1, they must go through extra steps in code execution which the EVM does not do. Rather than loading smart contract bytecode into the execution layer and simply posting the result of those computations, ZK-rollups must generate validity proofs for each transaction’s state transition.

Because EVM opcodes are designed for general-purpose computations, proving EVM computations in ZK circuits is too resource intensive and complex. Consequently, it is very difficult to ensure EVM-compatibility in ZK rollups, resulting in varying architectural designs:

zkEVMs allow easier execution of Solidity smart contracts, while custom VMs may require developers to write smart contracts in some other smart contract language or modify their existing EVM-based implementations due to ZK limitations.

IV-B3 Applications

zkSync Era [69] is a zkEVM rollup developed by Matter Labs. Identical to the previously mentioned methodology, zkSync Era utilizes ZK-SNARKs to provide validity proofs of off-chain computation. Smart contracts can be written in Solidity or Vyper and called using the same clients as other EVM-compatible chains, thus making zkSync EVM-compatible. The zksolc compiler used on Era generates bytecode with optimizations in order to make operations more amenable to proof generation, using LLVM as an intermediate representation before executing zkEVM assembly code. Consequently, there are multiple differences from Ethereum, with many EVM opcodes having modified implementation rules. zkSync Era is the first EVM-compatible chain to implement native account abstraction, which is a system of smart-contract-based accounts with arbitrary logic, first introduced in EIP-4337. Thus, every user account on zkSync Era can utilize smart accounts with their existing externally owned account (EOA).

Matter labs also provides an open framework for deploying additional modular chains similar to zkSync Era called the ZK stack [69]. A modular chain from the ZK stack, called a hyperchain, runs a separate instance of the zkSync zkEVM and settles transactions on Ethereum’s Layer 1. Hyperchains are linked via Hyperbridges, ensuring asset transfer capabilities. While anyone can deploy Hyperchains, ensuring trust and full interoperability requires using the zkEVM engine from the ZK Stack, which powers zkSync Era. This uniformity in ZKP circuits across Hyperchains guarantees inherited security from Layer 1 without additional trust assumptions. Hyperchains implement a modular approach, allowing developers to choose or create their own blockchain components, except for the zkEVM core. Various options for sequencing transactions are available, ranging from centralized to decentralized sequencers, and even external protocols for customizing Hyperchain sequencing. Each Hyperchain can also manage its data availability (DA) policy, for example a “Validium” architecture which stores state data off-chain rather than posting the calldata to L1, providing flexibility tailored to specific needs.

Polygon zkEVM [70], built by Polygon Labs, aims to offer full EVM-equivalency, with no separate compiler. Thus, ZK proving circuits verify most EVM opcodes as they are, with a few carrying minor differences that do not impact the developer experience. Because of this inherent equivalency and support of EVM opcodes, developers can deploy their existing L1 smart contracts directly to the Polygon zkEVM rollup, with no necessary tweaks. Much like the zkSync stack, Polygon has the Chain Development Kit (CDK) [71], which allows developers to deploy application-specific chains as validiums using the Polygon zkEVM.

Scroll [72] represents another approach within the zkEVM landscape, focusing on EVM compatibility with necessary adaptations for zero-knowledge proofs. Scroll’s zkEVM modifies certain EVM opcode behaviors to fit the ZK-proof framework while maintaining the ability for developers to write and deploy Solidity contracts, with no custom compiler. Although these modifications alter how some operations are handled compared to Ethereum, they are clearly documented, ensuring that developers can account for these changes during smart contract development. The tailored modifications aim to preserve the core experience of Ethereum smart contract interaction within the constraints of a ZK rollup environment.

Linea’s zkEVM [73], developed by ConsenSys for the Linea L2, closely mirrors the Polygon zkEVM, providing an EVM-equivalent experience without requiring a custom compiler. Supporting Solidity compilers, Linea enables developers to use well-known Ethereum tools like Hardhat and Foundry seamlessly. This compatibility eases the developer transition to Linea, with minor considerations for Solidity version compatibility. Additionally, Linea integrates the Canonical Message Service, a system allowing arbitrary data transfer between Linea and other networks, enhancing cross-chain communication and utility.

StarkNet [29], built by StarkWare, stands out as a unique ZK-rollup, fundamentally distinguished by its use of STARKs (Scalable Transparent ARguments of Knowledge), which offer quantum resistance and do not require a trusted setup, over SNARKs. Unlike other ZK-rollups, StarkNet utilizes Cairo – a specialized programming language – instead of Solidity. Cairo programs are compiled into Sierra, a safe intermediate representation, and subsequently into Cairo assembly (Casm) for execution by the StarkNet OS virtual machine. Use of the Cairo programming language and this two-step compilation process is necessary to bridge the gap between smart contract execution and the polynomial constraints of STARK proofs, which in turn validate StarkNet’s block execution. Like zkSync, StarkNet’s native account abstraction (AA) sets it apart by making all accounts ERC-4337 smart accounts with no externally owned accounts (EOAs) [74].

StarkEx [75], also developed by StarkWare, is a specialized Layer 2 scalability service utilizing STARK proofs for high-throughput, low-latency applications on Ethereum. Unlike StarkNet, StarkEx is not a standalone blockchain, but a service specifically tailored for certain use cases like decentralized exchanges (DEXs) and NFT platforms. It allows these applications to define their own logic off-chain and post transactions to the service, which then generates STARK proofs attesting to the validity of transaction batches. These proofs are submitted and verified on L1. StarkEx also offers various data availability modes - ZK-Rollup, Validium, and Volition. This flexibility allows applications to optimize with any mix of on-chain and off-chain components.

Aztec Network [76] is a Layer 2 rollup which focuses on privacy preservation through the Noir programming language. Noir, a Rust-based DSL for building ZK applications, simplifies the creation of ZKPs by abstracting the cryptographic process while retaining the robustness of circuit-building languages [77]. Smart contracts in Aztec, utilizing Noir, can have both public and private elements. These contracts are defined as sets of functions, both public and private, written as Noir circuits. Each function, representing a zk-SNARK verification key, operates on the contract’s public and private state. Noir’s compilation process is unique: it doesn’t compile directly to circuits but to an Abstract Circuit Intermediate Representation (ACIR), which can then be compiled into an arithmetic circuit or R1CS, depending on the proving system being targeted [39]. In Aztec, the sequencer aggregates transactions into a block, generates state update proofs, and posts them to the Ethereum rollup contract. This architecture, while similar to other Layer 2 networks, differs notably in its handling of private state. The private execution environment within Aztec safeguards sensitive operations and data, ensuring that private information remains confidential [76]. This architecture is outlined in Figure 10.

IV-C1 Motivation and Definition

With a highly fragmented landscape of different blockchain technologies, including Layer 1 chains and additional modular layers built atop them, there has arisen the need for seamless composability among blockchains. For example, a significant pain point in blockchain user experience is the struggle of trying to bridge tokenized assets from one blockchain to another. This problem extends past cross-chain transactions and financial asset liquidity, as it also concerns general message passing and data storage across fragmented blockchain networks. Even for Layer 2 rollups built atop the same Layer 1, each rollup’s state is a separate data moat, which results in the same fragmentation problem even in the case of shared transaction finality and consensus security. Cross-chain composability, also known as blockchain interoperability, has many innovative solutions, including those that utilize ZKP for succinct verifiable computation.

IV-C2 Methodology

Zero-knowledge proofs are used to verify the occurrence of a state change or block execution on one chain to another chain. This property allows protocol developers to coordinate application logic across multiple blockchains, letting users instantly transact and pass data between different networks. Typically, there is some middleware that generates the validity proofs to be verified on the receiving blockchain, where a smart contract will verify the proof and execute corresponding application logic, according to the application’s specification. For example, asset bridges lock up tokens on one chain and mint them on another, allowing users to transfer liquidity between chains. Further use cases enable cross-chain DAO voting, Non-Fungible-Tokens (NFTs), and more.

IV-C3 Applications

The zkBridge protocol [78], originally published as academic research and later implemented by Polyhedra[79], operates through a modular design that separates application-specific logic from the core functionality of relaying block headers. This core functionality is provided by a block header relay network, which is trusted only for liveness. This network relays block headers of one blockchain along with zk-SNARK correctness proofs to an updater contract on another blockchain. The updater contract is responsible for maintaining a list of recent block headers from the sender chain, verifying proofs submitted by relay nodes, and updating the list accordingly. On the receiver blockchain, the updater contract provides an application-agnostic API that enables application smart contracts to obtain the latest block headers of the sender blockchain. This enables them to build application-specific logic on top of this information. Applications utilizing zkBridge generally deploy a pair of contracts: a sender contract on blockchain 1 and a receiver contract on blockchain 2. The receiver contract can call the updater contract to access block headers of blockchain 1, which it can then use to execute application-specific tasks.

Telepathy[80] is an interoperability protocol that allows arbitrary message passing between Ethereum and other chains. For developers that want to send a cross-chain transaction, they call the Telepathy router contract on Ethereum and must wait until the transaction reaches finality. To verify that a block has been finalized, an off-chain component called the Telepathy operator utilizes a zk-SNARK that proves the block header has signatures from a large percentage Ethereum validators. This proof is passed to the Telepathy light client contract on the destination chain, which verifies proofs and provides access to Ethereum’s block headers. The Telepathy relayer accesses that light client data and generates a Merkle proof on the block to verify that the transaction exists and reached finality on Ethereum. This Merkle proof is passed to the Telepathy receiver contract, which verifies it and relays the smart contract call to the receiving contract on the destination chain, which executes the corresponding application logic as specified by the developer.

IV-D1 Motivation and Definition

Blockchain storage is essentially a way to save data in a decentralized network using the properties of the blockchain. In order to protect the saved data, blockchain uses data structures such as Merkel trees and Merkel Patricia trees. What is special about these data structures is that specific proofs can be constructed to show that a particular piece of data is contained in the structure and that once a single piece of data is changed, the entire structure changes drastically as well. This essential property of blockchain ensures data integrity and invariance. However, as the quantity of data contained in a proof rises, so does the size of the proof. As a result, the cost of validating such proofs on the chain rises, rendering ordinary inclusion proofs economically unsustainable in most circ*mstances. A more scalable option is now preferred, whereby the blockchain does not have to store large amounts of data but only smaller references to data stored in off-chain platforms. Zero-knowledge proofs make this possible: data and computations can be stored off-chain, and ZK Proofs can be used to communicate a summary of these operations to the main chain concisely, efficiently, and without trust.

IV-D2 Methodology

Zero-knowledge proofs could be used to minimize the cost of activities associated with verifying the inclusion of data in massive datasets and to validate that the procedure was completed correctly. The prover carries out the necessary calculation and generates proof that proves its correctness. The verifier’s job is to validate the proof’s validity without redoing the whole analysis. Because of this feature, the prover only requires access to a subset of the data, such as some nodes of a Merkle tree, rather than the entire dataset. This paradigm shift is crucial because it offers a practical solution to lower the costs of employing proofs of inclusion in smart contracts, particularly when massive datasets are involved.

IV-D3 Applications

To prove the data is indeed stored in the blockchain, Herodotus [81] gives a new method called Storage Proofs to enable on-chain data access. It is essentially an on-chain accumulator that uses cryptographic means to improve access and verification of historical data on the Ether blockchain. The solution utilizes StarkWare’s STARK proofs [82]. This allows users to validate data from any point on the Ethernet blockchain without the need for a third party. It combines proofs of inclusion (for verifying the existence of data) and proofs of computation (for proving the execution of multi-step workflows). These proofs are essential for verifying the integrity and correctness of one or more components of a large data set, thus ensuring that the data has not only been stored, but also remains untampered with and accurate over time.

Filecoin [83] has deployed a considerable zk-SNARK network, which uses the unused hard drive space of users around the world to store files. Using zk-SNARKs to generate the proofs, the resulting proofs are small, and the verification process is swift (and thus, cheap). For example, proofs that typically would require hundreds of kilobytes to verify can instead be compressed to just 192 bytes with zk-SNARKs. This significant reduction in proof size not only accelerates the verification process but also reduces the computational and financial costs associated with it, making blockchain storage both more scalable and accessible.

IV-E1 Motivation and Definition

While creating entirely new blockchain networks or rollups serves as a solution for privacy demands, there are also ZKP-based approaches which offer selective privacy for certain decentralized applications (dApps) and transactions on existing, transparent blockchains such as Ethereum. These applications could be utilized in cases where users want to make certain actions or information private, but continue to use an existing blockchain network. These applications exist on the smart contract execution layer of a blockchain, where dApps are designed to utilize ZKP to enable private transactions in certain contexts, such as transaction mixing, for example. This application domain can be defined as Smart Contract/Transaction Privacy, which mostly benefits from the privacy prong of ZK.

IV-E2 Methodology

The core methodology in ZKP smart contract privacy centers around on-chain proof verification within a smart contract framework. Proof generation typically occurs off-chain due to its computationally intensive nature and the need for privacy in computation or the processing of sensitive data. Once a proof is generated, it is submitted to the blockchain. The contract assesses the proof against the protocol’s predefined rules, and then acts accordingly if deemed valid, which could involve updating the blockchain’s state, executing transactions, or any other protocol-specific actions.

IV-E3 Applications

Tornado Cash [42] employs zero-knowledge proofs for enabling transaction privacy and mixing on Ethereum. Its core mechanism revolves around depositing Ether into a smart contract and withdrawing it in a manner that severs the link between the source and destination. The protocol utilizes zk-SNARKs to prove the legitimacy of withdrawals without revealing the original deposit’s details. Users deposit Ether, generating a cryptographic commitment added to a Merkle tree within the contract. For withdrawal, a user generates a zk-SNARK proof that they own a leaf in this tree without revealing which one. This proof, once verified by the smart contract, allows the withdrawal of Ether to a new address, ensuring that the transaction’s privacy is maintained by obscuring the link between the deposit and withdrawal addresses. This method effectively creates a privacy layer, allowing users to transact anonymously within the public Ethereum blockchain.

Due to its rampant use for illicit financial transactions such as money laundering, Tornado Cash has been heavily sanctioned and banned in countries like the US. This has given rise to the research problem of regulatory-compliant privacy solutions, which has been implemented in the Privacy Pools project, as delineated in [84]. Privacy Pools extends the usage of zk-SNARKs in other privacy solutions like Zcash and Tornado Cash. Rather than simply generating a ZKP to prove that a withdrawal attempt is linked to a specific deposit, users prove membership in a specific association set, which is a collection of transaction references, represented as a Merkle tree, from which a user’s funds could have originated. Users define their set by providing the Merkle root as a public input. When withdrawing funds, the user does not directly prove a link to a specific transaction. Instead, they utilize zk-SNARKs to generate proofs that validate their funds’ origin from within this predefined, public set of transactions. This approach allows users to demonstrate a connection to a pool of transactions without revealing the exact source, maintaining privacy while introducing an element of transparency.

The use of association sets in Privacy Pools addresses the challenge of aligning transaction privacy with regulatory compliance. By proving membership in a specific association set, users demonstrate that their funds originate from a group of transactions that are not flagged as high-risk or associated with illicit activities.

Penumbra [85] is a fully private proof-of-stake network and decentralized exchange within the Cosmos ecosystem, offering a unique approach to transaction privacy and cross-blockchain interoperability using zero-knowledge proofs. Penumbra connects to the Cosmos blockchain ecosystem through IBC (the inter-blockchain communication protocol) and maintains all value in a multi-asset shielded pool, inspired by the Zcash Sapling design. This allows for private transactions in any IBC-compatible asset. All transactions on Penumbra are private by default, enabled by zk-SNARKS which validate the correctness and legitimacy of transactions but shield the sender, receiver, and amount. Penumbra’s decentralized exchange, called ZSwap, supports sealed-bid batch auctions and concentrated liquidity similar to Uniswap v3. This architecture prevents frontrunning and ensures that only the net flow across a pair of assets is revealed in each block. For cryptographic primitives, Penumbra utilizes BLS12-377 as the proving curve, which is compatible with the Groth16 proving system used. Penumbra may change to PLONK in the future.

A novel privacy problem exists within the space of on-chain decentralized autonomous organizations (DAOs), which are blockchain-based governance systems powered by smart contracts. Because of the transparent nature of public blockchains, DAO treasuries are completely public, which is a big issue for certain types of auctions. In a blog and research project by Griffin Dunaif and Dan Boneh, the authors design a system for a private DAO protocol utilizing ZKP [86]. The protocol utilizes a master contract deployed on the Ethereum network to manage multiple DAOs. This contract allows anyone to send funds to a DAO, but only the DAO manager can withdraw them.

The life cycle of a DAO in this system comprises three steps: creation, deposit, and withdrawal. During DAO creation, the manager establishes the DAO without any on-chain transactions, and posts a Schnorr public key on the DAO website. To contribute funds to the DAO, users compute the Merkle tree leaf using the DAO public key, in which the deposit is recorded in the master contract. The DAO manager is able to privately monitor deposits and keep track of the DAO treasury using their secret key. When withdrawing funds, the DAO manager again uses this secret key within a SNARK proof to show that a specific batch of deposit leaves in the Merkle tree belong to the DAO, without publicly revealing the secret key. After verifying the proof, the master contract releases the withdrawal amount to the DAO manager.

We have seen niche-specific privacy dApps, but there also exist entirely private smart contract frameworks for private blockchain applications. One example is Hawk [26], which uses off-chain computation to conceal private portions of a smart contract. In Hawk, the programmer writes a smart contract with defined public and private components. The Hawk compiler will subsequently split the computation into pieces, where the private portion of the contract $\phi$-priv is executed off-chain and handles sensitive data and computations. This off-chain execution is managed by a trusted party, known as the manager, who can see the users’ inputs and is expected to not disclose them. The manager’s role is to perform the private computations and generate a ZK-SNARK attesting to the correctness of these computations without revealing any sensitive data inputs. The proofs are then verified on-chain, ensuring the integrity of the private computations while keeping them hidden from the public blockchain. The public portion of the contract $\phi$-pub, which executes on the blockchain, handles non-sensitive operations and provides transparency where necessary, but it does not deal directly with private data or currency transactions.

Mina, the previously mentioned Layer-1 blockchain, also provides a privacy-preserving smart contract framework called zkApps [87]. Mina zkApps are developed using the o1js TypeScript library and the Mina zkApp CLI, and comprise of two main components: a smart contract written with o1js, and a user interface (UI) for interaction. Upon zkApp interaction, the smart contract’s code is executed locally in the user’s web browser, where it generates a ZK-SNARK proof. This setup allows users to input data into the zkApp, which could be either private or public. Private data remains unseen by the blockchain, while public data may be stored on-chain or off-chain, depending on the zkApp’s design. The prover function within the smart contract generates the SNARK proofs, maintaining user privacy by ensuring that sensitive data is processed locally and not disclosed on the blockchain. Once a user decides to submit a transaction to the chain, the transaction, containing the ZKP and associated state updates, is sent to the Mina network. The network verifies that the proof meets all constraints defined in the prover function. The state of a zkApp can be either on-chain or off-chain. On-chain state is stored directly on the Mina blockchain and offers limited storage space, while off-chain state refers to larger data stored elsewhere, like in external storage systems such as IPFS. In scenarios where off-chain storage is used, the zkApp updates an on-chain Merkle tree root of some fully off-chain Merkle tree. This method ensures that the integrity of both the proof and the associated account updates is maintained, allowing the Mina network to confirm the validity of the zkApp transactions and state changes.

IV-F1 Motivation and Definition

Because of the aforementioned qualities of ZKP, there exists the unique use-case of a user proving group membership or identity without revealing any sensitive information about their identity, thus marrying the imperatives of authentication and privacy. While this can be implemented outside of the blockchain context (as will be covered in the “Proof of Identity” section below), there exist many identity-proving applications using blockchain smart contracts and execution layers. This application domain can be defined as Blockchain-Based Proof of Identity, which takes advantage of privacy-preserving ZKP.

IV-F2 Methodology

The core methodology behind blockchain-based proof of identity systems is the use of zero-knowledge proofs to enable users to prove membership in certain identity groups or ownership of credentials without revealing the actual identity information. This is achieved through cryptographic commitments to a user’s information while keeping it secret. A privacy-preserving ZK identity proof can be easily verified by an on-chain smart contract, and this can act as a private credential system secured by the blockchain and open doors to a multitude of decentralized applications, without sensitive information compromise.

IV-F3 Applications

Semaphore can serve as a verifiable credential protocol at the base level, as it allows developers to create identities, identity groups, and use identity commitments to prove group membership. An example of a prominent project that utilizes Semaphore for verifiable credentials on Ethereum is World ID, which is the proof-of-personhood verification system for the WorldCoin protocol [89]. When a user creates a unique World ID from their biometric data, their ID is enrolled in a group of verified World ID users. World ID’s can then be safely verified without revealing the World ID public key.

The Galxe protocol is a self-sovereign identity service centered around verifiable credentials [90]. It addresses the digital identity multiplicity problem by embedding numerous identity commitments into a single user credential, enabling holders to connect identities across platforms privately. Credential holders can use ZKP to selectively prove requisite information of their identity, while maintaining a pseudonym. Like Semaphore, Galxe constructs identity commitments by computing the Poseidon hash of the private secret identity and a private internal nullifier. This can then be distinguished in a zero-knowledge proof, which is verified by an on-chain smart contract and attests to the user’s identity. The internal and external nullifiers generate deterministic nullifiers per verification to prevent double-spending. The current verification stack of the Galxe protocol is BabyZK, which uses the BN254 curve, Groth16 proofs and Poseidon commitments. Use cases of the Galxe protocol could include sybil-resistant reputation systems, access control, achievement aggregation, and personal data markets with privacy.

Aleo, a Layer 1 privacy blockchain mentioned in this paper above, boasts its own ZK identity verification protocol called zPass [91]. zPass is a straightforward implementation due to the nature of enshrined zero-knowledge proofs and private execution available in Aleo. However, zPass also enables users to obtain anonymous credentials from existing identity documents, facilitating real-world adoption without necessitating changes to the protocol. Like Galxe protocol, it allows for selective attribute disclosure, enabling users to prove identity assertions across multiple credentials.

IV-G1 Motivation and Definition

Supply chains and global enterprises are increasingly recognizing the transformative potential of blockchain technology for enhancing transparency, provenance, immutability, and accountability. However, this shift towards blockchain adoption in supply chain comes with significant privacy concerns. In a typical supply chain, stakeholders, including suppliers, manufacturers, distributors, and retailers, share sensitive data such as pricing, inventory levels, and production schedules. The public and immutable nature of open blockchains could expose proprietary or sensitive information to competitors or the public. This trade-off between the need for transparency and privacy requirements has led to the exploration of privacy-enhancing technologies within blockchain frameworks for supply chain and enterprise applications.

IV-G2 Methodology

There are several strategic approaches for implementing privacy in supply chain and enterprise blockchains. Firstly, the adoption of permissioned blockchain architectures enables the creation of a controlled ecosystem where access is granted only to verified participants. This selective visibility is crucial for maintaining a competitive edge and for ensuring that relevant data is shared only among trusted stakeholders.Furthermore, the integration of ZKPs addresses the necessity for privacy by allowing participants to verify the authenticity and compliance of products without revealing detailed process histories or proprietary information. This technology is instrumental in convincing end consumers of product safety and quality, even in the absence of full process transparency.To tackle the intricate and global nature of modern supply chains, data segmentation and encryption techniques are employed to protect business-sensitive information. By only storing cryptographic hashes of the actual data on-chain and keeping the detailed records off-chain or encrypted, these methodologies significantly reduce the risk of exposing trade secrets and sensitive business strategies.Moreover, the use of smart contracts for privacy enforcement plays a pivotal role in automating compliance and access control based on pre-defined rules. This approach not only streamlines operations but also ensures that data disclosure is strictly governed by necessity and consent in the supply chain scenario.Therefore, incorporating these enhanced privacy measures can achieve the goal of protecting end consumer interests and maintaining mutual trust among supply chain participants, as depicted in Figure 12.

IV-G3 Applications

qedit [92] provides privacy-enhancing technology for enterprise blockchains, enabling secure collaboration and data sharing among parties without revealing sensitive information. It utilizes ZKPs to ensure that transactions are valid while keeping the transaction content private. It’s designed for enterprises looking to monetize data assets safely, enhance business analytics, and derive actionable insights in a secure manner. The platform is cloud-hosted, highly scalable, and integrates easily with existing database systems for quick deployment. qedit features a configurable dashboard, advanced reporting, and real-time notifications to provide businesses with critical intelligence efficiently. It is aimed at transforming the way companies collaborate on sensitive data, ensuring privacy while enabling data-driven decisions.

zk-BeSC [93] introduces a blockchain-based framework for supply chain management that utilizes polynomial ZKPs to ensure privacy during transactions. The framework is designed to enable confidential transactions among supply chain participants, preserving the privacy of sensitive data while maintaining the traceability and immutability features of blockchain technology. It leverages advanced cryptographic techniques, including hom*omorphic encryption and elliptic curve pairings, to prove knowledge of polynomials without disclosing them. Implemented on the Ethereum testnet with a web3 application, zk-BeSC demonstrates efficient proof performance and reduced gas consumption for verification, addressing key privacy concerns in supply chain management.

Sahai et al. [94] present a blockchain-based solution for improving privacy and traceability in supply chains. This approach leverages Hyperledger Fabric and employs cryptographic tools like ZKPs to protect sensitive business data while ensuring the ability to trace product provenance and contamination. The model supports operations such as product entry, exit, transfer, merge, split, and processing within the supply chain, enabling efficient and private tracing of products from origin to consumer.

IV-H1 Motivation and Definition

It has always been important in financial markets for companies to demonstrate their reserve assets to prove their solvency to savers. The global financial system often operates in an undercollateralized and highly opaque manner, relying heavily on trust in a central entity (either the system itself or a third-party certifier), but this can create fraud risks, mismanagement, and privacy breaches. Zero-knowledge proof of Reserves (ZK-PoR) (such as [95]) provides a trustless mechanism to verify reserves, enhancing trust and security in decentralized financial systems without sacrificing privacy. This innovation is particularly important for cryptocurrency exchanges and wallets, as users need verifiable assurance that their assets are being held securely without exposing those assets to potential threats. Specific to the scenario of a virtual currency exchange, the proof generated by this method can ensure that the verifier obtains proof of the exchange’s repayment ability without knowing the specific amount of the exchange’s reserves, the identity of the individual account holder, or any transaction details. Proof, thereby ensuring transparency on reserve adequacy while maintaining privacy and security.

IV-H2 Methodology

The methodology behind ZK-PoR involves several key steps to ensure secure and private verification of assets. Initially, the entity holding the reserve constructs a commitment to the asset without revealing its details, using cryptography to generate proof of possession. The proof is rooted in a zero-knowledge proof algorithm and is then transmitted to the verifier. Validators use the same cryptographic algorithm to verify proofs without knowing the actual reserves, the identities of asset holders, or transaction details. The process often employs complex mathematical structures such as hom*omorphic encryption, elliptic curve encryption, and Merkle trees to ensure the integrity and confidentiality of the proof. The trust established by this approach stems from mathematical proof rather than the reputation or authority of the entity.

IV-H3 Applications

ZK-PoR has numerous applications in the fields of blockchain and financial technology, especially in enhancing privacy and trust. In the financial domain, particularly within cryptocurrency exchanges, proving solvency without compromising sensitive information confidentiality is a critical concern.

Provisions [96] offers a groundbreaking solution to this challenge by employing ZK-PoR. This technology enables a Bitcoin exchange, or any cryptocurrency platform, to transparently demonstrate that it possesses sufficient funds to cover all its obligations to users without disclosing the exact amounts held or the identities of the account holders. Allowing an exchange to prove its liquidity addresses the common concern of potential insolvency. Furthermore, this approach minimizes the risk of sensitive financial data being exposed, which could be detrimental in terms of privacy breaches or malicious exploitation.

Another application, Proven[97], leverages ZK-PoR to provide a decentralized platform that enables companies and financial institutions to verifiably prove their liquidity or asset reserves without revealing specific asset values or compromising the confidentiality of their operations. These applications highlight ZK-PoR’s versatility in solving the twin challenges of transparency and privacy in digital finance, providing exchanges and institutions with a powerful solution to build trust with users and regulators while protecting sensitive financial data.

V-A1 Motivation and Definition

Although we have seen many blockchain-based proof of identity protocols, identity proving as a practical application of ZKP extends past the blockchain domain as well. Fundamentally, this methodology is derived from the ability to prove a statement about identity, specifically membership in a set or credential verification, without revealing any sensitive information about the identity. As we saw in the blockchain domain, the space of privacy-preserving verifiable credentials is a popular result of these properties. This also extends to non-decentralized technologies, as we will see in the following section. This application domain can be defined as Proof of Identity, utilizing the privacy properties of zero-knowledge verifiable computation.

V-A2 Methodology

These identity proving techniques utilize ZKP to validate a user’s identity or membership in a group without revealing any specific, sensitive details about the identity itself. Compared to other application domains, this methodology is far more pure in the sense that the only unifying factor among applications is the ZKP itself; a proof is generated by a prover on some identity credential and given to an identity verifier, who does not get any identity information other than the proof itself.

V-A3 Applications

One of the earliest papers on ZKP, first published in 1988, presents a novel identification scheme based on zero-knowledge proofs, providing a more efficient alternative to RSA-based schemes. [98]. In identification schemes, entity A proves their identity to entity B using some constant S in the form of a value or physical card, without enabling entity B to then falsify themselves as A afterwards. Traditional identification schemes utilize encryption and/or hashing along with credentials such as digital passwords, PINs, credit card chips, etc. This paper proposes a practical scheme where no sophisticated adversary is capable of cooperating with a dishonest verifier B to produce a falsified credential and pretend to be A. The methodology involves interactive proofs where an entity can demonstrate their identity by proving they know a secret key of their credentials without having to reveal the secret; simply submitting a proof of their knowledge of the secret is sufficient, with the secret acting as a digital signature unique to each individual. The paper outlines a directory-less scheme, meaning there is no need for a central repository of public keys or identities. The paper also proposes that such a scheme could be implemented in hypothetical “smart cards”, which could act as physical credentials that generate zero-knowledge identity proofs using microprocessors to facilitate everyday identity verification.

The zk-creds protocol leverages zero-knowledge proofs (specifically zk-SNARKs) to convert existing identity documents into anonymous credentials, thereby eliminating the need for credential issuers to hold signing keys [99]. This system contrasts with traditional methods where issuers sign credentials and identity documents for validation. By integrating with existing identity infrastructures like government-issued IDs or university diplomas, zk-creds transforms these traditional credentials into digital, anonymous, yet verifiable formats.

V-B1 Motivation and Definition

In a world where AI-generated material increasingly mimics human-created information, the potential use of zero-knowledge cryptography could assist us in determining that a specific piece of content was produced by applying a specific model to a given input. If a zero-knowledge circuit representation is built for them, this could give a technique for verifying outputs from large language models like GPT-4 [100], text-to-image models, or any other models. The zero-knowledge quality of these proofs allows us to hide sections of the input or the model if necessary. A good example is enabling users to view the model’s inference results without knowing the details of the model and prove that this result really comes from a specific model and input.

Zero-knowledge machine learning (ZKML) is a means to protect data privacy during model training and inference. They enable a data owner or a model owner to demonstrate the accuracy of a computation (such as the prediction of a machine learning model) without exposing any information about the data or the computation itself. This is especially effective in circ*mstances involving sensitive data.

V-B2 Methodology

In a typical machine learning situation, an application service provider (the prover) wants to provide a machine learning model it owns to the user (the verifier) while keeping the model private. Provers can use zero-knowledge proofs to show that they have indeed performed a computation using a particular model without exposing the model or the computation process itself.

V-B3 Applications

ZKPs are commonly employed in machine learning, notably privacy-preserving and federated learning. service providers (provers) can use ZKP to prove the correctness of their model predictions without revealing the model itself to prevent model theft. The current state of the art in zero-knowledge systems coupled with performant hardware is still a few orders of magnitude shy of proving something as massive as currently available large language models (LLMs), but there has been considerable progress in establishing proofs of smaller models.

In verifying machine learning model predictions, vCNN [101] uses commit-and-prove to combine the typical quadratic arithmetic program (QAP) with the polynomial QAP in pairing-based zero-knowledge proofs. It supports convolutional neural networks and validates them using polynomial multiplications.

However, by presenting a novel sumcheck technique, zkCNN [102] could prove fast Fourier transformations and convolutions in a linear prover time. It is verified that the convolutions directly using the sumcheck protocol and zkCNN are 34×faster than vCNN.

zkDL[103] is an innovative approach to meet the need for zero-knowledge proofs in deep learning training. The main challenge it addresses is verifying the nonlinear computations inherent in neural networks, especially the ReLU activation function and its backpropagation. By introducing zkReLU, zkDL can efficiently handle these non-arithmetic operations without resorting to polynomial approximations, which are usually computationally expensive and less accurate. The FAC4DNN utilized by zkDL is an arithmetic circuit that aggregates proofs from different layers and training steps. This design bypasses traditional sequential proof generation and greatly reduces computational and communication overheads. zkDL also achieves full compatibility with tensor structures and supports large-scale neural networks, with proofs generated in less than a second for each batch update for networks with up to 10 million parameters.

The research by Sanjam Garg et al.[104] explores the practical application of zero-knowledge proofs in verifying the training of machine learning models. It focuses on experimental settings to verify the feasibility of such proofs, taking into account computational complexity and scalability issues. Their work emphasizes the need to balance strong security guarantees with practical overhead, ensuring that the proofs are concise and the prover’s workload is manageable. By experimenting with various configurations and optimization techniques, it provides insights into making zero-knowledge proofs applicable to real-world deep learning applications, which is very suitable as a reference.

Another recent study, Kaizen[105], proposed a zero-knowledge proof system designed for deep neural networks (DNNs). It ensures that the submitted model is correctly trained on the submitted dataset without leaking any other information. Kaizen adopts a sum-check-based proof system optimized for the gradient descent algorithm and recursively combines these proofs in multiple iterations. This recursive combination ensures that the proof size and verifier time are independent of the number of iterations, making it highly scalable. Kaizen has the ability to handle large models such as VGG-11, and is more practical than general recursive proofs, significantly reducing prover runtime and memory overhead.

In the study of the reasoning process, zkLLM[106] focuses on providing zero-knowledge proofs for large language models, ensuring that the reasoning results are verifiable without revealing the underlying model or data. This is especially important for applications that require strong privacy protection, such as medical or financial fields where data confidentiality is critical. zkLLM uses advanced encryption technology to efficiently generate and verify proofs, and maintains the privacy of model parameters and input data through cryptographic means, enhancing trust in deployed AI systems.

In addition to the issue of the trustworthiness of its predictions, the model’s reliance on opaque data sources has become a new challenge. People frequently desire to keep the inputs and parameters of machine learning models private and unknown to the general public. Because the input data may contain sensitive information such as personal finances or biometrics, and the model parameters may also hold critical secrets. To specify provers and verifiers, many ZKML tools represented by the ezkl library [107] can implement higher-level descriptions of machine learning models or other computational graph programs. A prover can demonstrate that a particular output is produced by running a specific neural network on a specific data set.

Modulus Labs [108] is also developing a zero-knowledge machine learning solution, enabling trustful integration of AI outputs into blockchain systems without revealing sensitive data or model details. This allows developers to retain ownership and control over their AI models rather than relying on centralized platforms to host and manage their models. And their new zero-knowledge prover, Remainder[109], is a fast AI prover for AI inference. It is based on a verifiable decision forest inference circuit using GKR protocol[110].

Giza [111] is a machine learning platform built on StarkNet that can be used to deploy and extend machine learning models, as well as solve the interoperability issues faced in the use of cloud-based machine learning models, performance, and transparency issues. It uses the ONNX open format to improve interoperability. Through a series of common operators and file formats it defines, developers can freely use TensorFlow, PyTorch, Scikit-Learn, and other frameworks and tools. Since StarkNet runs on the Layer2 network, it can enable any decentralized application to achieve unlimited computing scale without affecting the composability and security of Ethereum. Therefore, you don’t have to worry about load and architecture issues when using Giza, and can concentrate on model development and iterate. Another benefit of being based on StarkNet is that most functions are managed by the blockchain, which makes it easier to monitor, track, and manage the model, greatly improving transparency.

V-C1 Motivation and Definition

Zero-knowledge proofs (ZKPs) have a broad range of applications extending beyond blockchain technology. Their unique ability to verify the accuracy of information without revealing the data itself makes them valuable in various technological fields. This section further progresses into other diverse applications of ZKPs that may not necessarily fit into our predefined categorization. These applications leverage ZKPs to address challenges in other significant areas, including image authentication, decentralized voting systems, and secure multi-party processes by ensuring data privacy and computational integrity.

V-C2 Methodology

In particular, we focus on four different applications: 1) Image Authentication, 2) Secure Electronic Voting Systems, 3) Randomness Generation and Timelocks, and 4) Collaborative Computations. ZKPs can be used to authenticate images without revealing the original content while allowing certain transformations like cropping or rotation. This is achieved by attaching a zero-knowledge proof to each image, certifying its integrity through any permissible transformations.Secure voting systems can employ ZKPs to validate encrypted votes while simultaneously ensuring voter privacy and integrity. This allows the verification of the correctness of each vote while maintaining the confidentiality of the voter’s choice.In applications such as randomness generation and timelocks, ZKPs can provide proof of computational integrity and delay in a verifiable delay function (VDF). These systems combine a delay function with the zkSTARK protocol in order to create a VDF that is slow to compute but fast to verify.Other applications extend the use of zk-SNARKs to collaborative environments where multiple parties jointly produce a single proof over a distributed witness. It addresses the challenge of maintaining data privacy in multi-party computations. The approach involves adapting zk-SNARKs for multi-prover protocols using secret-sharing techniques. This allows the generation of a single proof that validates a computation over data distributed among several parties without revealing individual inputs.

V-C3 Applications

In the realm of digital media, journalism, and legal documentation, the authenticity of images is a critical concern. PhotoProof [112] addresses this by allowing images to be authenticated even after undergoing permissible transformations such as cropping or color adjustments. This application is particularly significant in legal scenarios where image evidence must remain untampered and in journalism, where the integrity of photographic evidence can be crucial in forming public opinion. PhotoProof utilizes ZKPs to ensure that any changes made to an image do not compromise its original authenticity, thereby maintaining the credibility of digital media.

Moreover, ZKPs can address the limitations of electronic voting systems, such as tampering or breaches in voter privacy. The integrity of the voting process in elections is of utmost importance in maintaining democratic principles. The proposed system for electronic voting using non-interactive zero-knowledge arguments [113] presents a secure method to validate votes while preserving voter anonymity. This application is significant in preventing electoral fraud and ensuring a fair and transparent voting process.

Generating unbiased randomness and implementing secure timelocks is essential in blockchain systems and cryptographic protocols. VeeDo [114] leverages ZKPs in VDFs to provide a reliable source of randomness that is resistant to manipulation, enhancing unpredictability and fairness in blockchain applications. In cryptographic protocols, VeeDo’s timelock feature can be utilized to secure information for a predetermined period by adding an extra layer of security to sensitive transactions or processes.

In fields like scientific research, business analytics, and healthcare, there is often a need to perform multi-party computations over shared data without revealing individual inputs. Collaborative zk-SNARKs [115] enables multiple parties to compute a joint result while ensuring that the privacy of individual institutions’ data is preserved.

For instance, hospitals and research institutions might collaborate on patient data for medical research while adhering to privacy laws set up by the government. Using collaborative zk-SNARKs, they can analyze aggregate data, such as treatment effectiveness or disease trends, without revealing individual patient details. This has profound implications for collaborative research, where data privacy is paramount, and for businesses that require secure multi-party computations for joint ventures or partnerships.

Next, ZKP2P [116] emerges as an innovative bridge that integrates traditional finance with decentralized finance through a trustless and privacy-centric framework. At its core, ZKP2P employs ZKPs to verify DomainKeys Identified Mail (DKIM) signatures in payment confirmation emails. This use of ZKPs is instrumental in ensuring the authenticity of transactions while maintaining the privacy of sensitive information. The architecture of ZKP2P is characterized by its incorporation of several key components: circuits for the secure verification of transaction details, smart contracts for managing trustless interactions, and ZK-Email Libraries essential for the generation of private proofs relating to email contents.The ZKP2P protocol is designed to be interoperable with prevalent Web2 payment systems, thereby bridging a significant gap between fiat and cryptocurrencies. By eliminating intermediaries and reducing transaction fees, ZKP2P aims to offer a more inclusive and efficient platform for crypto-fiat conversions with the potential to evolve into a global, on-chain, trustless payment network compatible with diverse financial applications in DeFi, NFTs, and gaming.