Slow Fog: Overview of the Technical Features of Mainstream ZKP Implementation Solutions

Source: Slow Fog

Overview

When studying how blockchain systems work, we need to understand various cryptographic concepts, such as secp256k1, which is a curve and asymmetric signature algorithm used for signing and verifying accounts in Bitcoin and Ethereum systems. For example, sha256, which is a hash algorithm used to compress variable-length information into fixed-length encoding. For example, base58, which can convert information encoding into a string representation of printable characters. For example, ECDH, which is a Diffie-Hellman key exchange algorithm used for securely exchanging communication keys between P2P nodes.

Zero-knowledge proof (ZKP) is also a cryptographic algorithm, abbreviated as ZKP or ZK. Its characteristic is that it can prove the correctness of a proposition without revealing any other information (many people have raised objections to the name "zero-knowledge proof," arguing that "zero-disclosure proof" better represents its essential capability).

ZKP was first proposed in 1985, but for a long time, no large-scale application scenarios were found, so the development of the technology was very slow. It wasn't until the birth of Bitcoin in 2009 that people discovered it was very suitable for solving privacy and scalability issues in blockchain, leading to a significant influx of capital and talent into the development and engineering application of this technology. There are many implementations of ZKP, such as Groth16, PlonK, STARK, etc., and no true industry standard has emerged to date. This article will summarize the technical characteristics of various ZKP implementations, hoping to assist in your learning, research, and engineering development.

ZKP Application Areas

1. Privacy Proof

Zcash may be the first widely used application of ZKP. It applies ZKP to the transfer of tokens based on the Bitcoin source code, making transaction information completely confidential while still verifiable by nodes on the blockchain.

Tornado Cash is a mixer running on Ethereum that uses ZKP to prove nodes on a Merkle Tree. Users can deposit a fixed amount of tokens into a liquidity pool and then use the proof generated by ZKP to prove that they have previously deposited funds without exposing their transaction information at the time of deposit.

2. Computation Outsourcing

In blockchain, each node has limited computing power, but with ZKP technology, nodes can outsource a large amount of computation to off-chain nodes. In this case, it is only necessary to verify the results of the outsourced computation and the proof of computation to determine whether the computation is correct.

zksync1.0 is a good example, as it performs Ethereum token transfers and transactions off-chain and then submits the results to nodes, which can verify whether the computation was performed as declared by validating the ZKP proof.

3. Data Compression

Filecoin uses ZKP to construct a proof of space-time system, which can prove that users have stored specific files locally. It has already proven that the stored files have reached 18 EiB.

Mina is another example. In many high-speed blockchain systems, the transaction data is enormous, and the system needs to retain all blocks for consensus protocol verification. This imposes extremely high hardware requirements, as permanent storage means that blockchain nodes will need to continuously increase disk space and data indexing capabilities. At this point, ZKP can be used to compress verification data. Mina compresses the ledger to 11 KB through recursive zero-knowledge proofs while still being able to verify the correctness of the blocks.

ZKP Proof Systems

Proof systems are the underlying algorithm implementations of ZKP and can be divided into interactive and non-interactive types:

1. Interactive Proof Systems

Interactive proof systems involve two parties, referred to as the Prover (P) and the Verifier (V). P knows a secret (such as the secret key of a public-key cryptosystem or a square root of a quadratic residue x) and wants to convince V that they indeed possess this secret. The interactive proof consists of several rounds, where in each round, P and V may need to send messages to each other based on the messages received from the other party and some results computed by themselves. A typical approach is for V to issue a query to P in each round, and P responds to V. After all rounds are completed, V decides whether to accept P's proof based on whether P can correctly respond to V's queries in each round.

2. Non-Interactive Proof Systems

In the aforementioned interactive proof systems, P and V do not interact; the proof is generated by P and directly given to V, who verifies the proof directly. This type of proof system is called a non-interactive proof system (NIZK).

The proof systems we generally use in blockchain are usually NIZK, where the nodes in the blockchain act as Verifiers (V), and the end users or Layer 2 networks act as Provers (P).

The reference link at the end of this article [1] describes the NIZK schemes published in the past decade and their characteristics.

In practical engineering applications, we mainly focus on performance and versatility, so we will conduct a more detailed classification and comparison of some common proof systems, as seen in the reference link at the end of this article [2]:

• Bulletproofs

  Characteristics: Compact proof size, no trusted setup required, but proof generation and verification take relatively longer.

  Representative projects: Bulletproofs, Halo, Halo2.

• SNARKs (Succinct Non-interactive ARguments of Knowledge)

  Characteristics: Compact proof size, proof verification takes relatively shorter, but requires a trusted setup for each circuit.

  Representative project: Groth16.

• SNORKs (Succinct Non-interactive Oecumenical (Universal) aRguments of Knowledge)

  Characteristics: Compact proof size, requires only one trusted setup for all circuits.

  Representative projects: Sonic, PlonK, Marlin, Plonky2.

• STARKs (Succinct (Scalable) Transparent ARguments of Knowledge)

  Characteristics: Proofs are very large, do not require a trusted setup, and have good scalability.

  Representative project: STARK.

This classification is not absolute; for example, the Halo/Halo2 projects have also borrowed many ideas from Plonk during their design. Additionally, SNORKs are often classified under SNARKs because they both require a trusted setup.

3. Performance Comparison

(See reference link at the end of this article [3])

Circuit Programming

Circuits implement the business logic of ZKP systems, and developing ZKP applications requires circuit programming. Why is ZKP logic code referred to as "circuits"? There are several reasons:

• The code for ZKP proofs is converted into a series of simple constraint expressions R1CS, which are then transformed into a huge polynomial QAP using Lagrange interpolation, ultimately constrained in the form of gate circuits.

• Similar to hardware circuits, all branches of the code will be executed together.

• Similar to hardware circuits, there are no recursions or complex loops in the ZKP proof circuit; the number of loops can only be constant.

We do not need to implement ZKP applications from scratch using cryptography; many development libraries have already implemented these underlying proof systems, and we only need to focus on the implementation of business logic. Of course, each library has different levels of abstraction; some require learning to describe circuit expressions, while others only need to define the code according to the process for easy implementation.

1. Common Development Libraries

• libsnark

Implemented in C++, it provides a general proof system, basic circuit library, and application examples.

Proof systems: BBFR15, BCCT12, BCCT13, BCGTV13, BCIOP13, BCTV14a, BCTV14b, CTV15, DFGK14, Groth16, GM17, GGPR13, PGHR13.

Link: https://github.com/scipr-lab/libsnark.

• gnark

A proof system implemented in Go, providing a high-level API for circuit design.

Proof systems: Groth16, PlonK.

Link: https://github.com/consensys/gnark.

• bellman

A proof system implemented in Rust, providing circuit interfaces, infrastructure, and some basic circuit implementations, such as Boolean and numeric abstractions.

Proof systems: Groth16.

Link: https://github.com/zkcrypto/bellman.

• snarkjs

A proof system implemented in Javascript and WASM, used for trusted setups, generating proofs, and verifying proofs. snarkjs compiles circuits defined by DSL using iden3's own circom compiler.

Proof systems: Groth16, PlonK.

Link: https://github.com/iden3/snarkjs.

• ethsnarks

Implemented in Python, it can generate proofs in the user's browser, using Ethereum smart contracts as verifiers. The project is currently not very active, and using Circom in similar scenarios may be a better choice.

Proof systems: Groth16.

Link: https://github.com/HarryR/ethsnarks.

• bulletproofs

A proof system implemented in Rust, featuring single and aggregated range proofs, strong typed multi-party computation, and is under development for a programmable constraint system API for proving arbitrary statements.

Proof systems: bulletproofs.

Link: https://github.com/dalek-cryptography/bulletproofs.

• halo2

A proof system implemented in Rust, maintained by the ZCash team. Halo2 is specific to PLONKish and allows very direct control over how circuits are represented in arithmetic operations, making it suitable for writing highly optimized circuits.

Proof systems: Halo2.

Link: https://github.com/zcash/halo2.

2. Development Process

Taking gnark as an example, a typical workflow is shown in the diagram below:

1) Describe the problem to be solved with code.

2) Compile into an R1CS constraint system.

3) Perform a trusted setup on R1CS to obtain the Proving key and Verify key.

4) The Prover uses R1CS and the Proving key to compute private data and generate a proof.

5) The Verifier uses the Verify key to verify the proof.

Circuit Programming Languages

1. Based on Ethereum Platform

• Cairo

Cairo is a programming language for writing provable programs, where one party can prove to another that a computation has been correctly executed. Cairo and similar proof systems can be used to provide scalability for blockchains. StarkNet uses the Cairo programming language for its infrastructure and to write StarkNet contracts.

Proof systems: STARK.

Link: https://www.cairo-lang.org/docs/.

• Zokrates

ZoKrates describes circuits using DSL and provides some commonly used circuit libraries. It can help you use verifiable computations in DApps, from specifying your program in a high-level language to generating computation proofs and verifying those proofs in Solidity.

Proof systems: GM17, Groth16, Marlin.

Link: https://zokrates.github.io/.

• Circom

The Circom language describes circuits using DSL and can work with snarkjs to generate proofs in the user's browser, using Ethereum smart contracts as verifiers.

Proof systems: Groth16, PlonK.

Link: https://iden3.io/circom.

• Noir

Aztec's privacy programming language based on Rust, which describes circuits using DSL, allowing for secure and seamless construction of privacy-preserving zero-knowledge circuits.

Proof systems: PlonK.

Link: https://noir-lang.org/index.html.

• zkEVM

Like EVM, zkEVM is a virtual machine that transitions between states as a result of program operations, but zkEVM proves the correctness of each part of the computation by generating proofs. Essentially, zkEVM uses a mechanism to prove that execution steps follow the rules.

Currently, teams such as zkSync, Polygon, Scroll, and Starkware are working on the implementation of zkEVM and have made significant progress.

2. Based on Public Chain Platforms

• zkApp (Mina)

zkApps are smart contracts of the Mina Protocol, supported by zero-knowledge proofs. zkApps can execute arbitrarily complex computations off-chain while only charging a fixed fee to send the generated zero-knowledge proofs to the chain for verification, contrasting with other models that run computations on-chain and use variable gas fees. zkApps are written in Typescript.

Proof systems: PlonK.

Link: https://docs.minaprotocol.com/zkapps.

• LEO (Aleo)

Leo is a functional statically typed programming language built for writing private applications. It is designed for developers to intuitively build on the Aleo blockchain, providing a foundation for a private, decentralized ecosystem.

Proof systems: Marlin.

Link: https://leo-lang.org/.

Common Security Issues in ZKP

In recent years, the Slow Fog security team has conducted circuit and application security audits for several well-known ZKP products, including ZKSwap, Zkdex, Zksafe, etc., discovering multiple medium to high-risk vulnerabilities and gaining a deeper understanding of applications developed based on popular frameworks like Circom and libsnark. The Slow Fog security team has identified common security issues in ZKP application audits:

• Trusted Parameter Risks

To use zk-SNARKs, a set of public parameters, known as the Common Reference String (CRS), is required. However, the creation of these parameters can also generate some private parameters. If one party obtains these private parameters, they can forge proofs.

Additionally, the process of generating CRS needs to be audited to ensure that there are no random number backdoors or that private parameters are not intentionally retained. When using zk-SNORKs, it is also necessary to ensure that the Structured Reference String (SRS) is trustworthy.

The security risks during the trusted configuration phase can be addressed using Secure Multi-Party Computation (MPC), which ensures that as long as any participant can honestly participate, the final computed result obtained through this multi-party computation system is trustworthy.

• Static Code Security

This part mainly involves security issues caused by non-standard coding practices, such as unvalidated parameters, unhandled return values, numerical overflows, and unchecked boundaries. If the language used to write circuits is C/C++, there may also be risks of memory overflow.

• Supply Chain Attack Risks

Supply chain risks mainly arise from using code libraries with vulnerabilities, such as outdated versions of repositories. Typically, ZKP applications also need to work with clients or web front ends, which are also susceptible to various forms of hacking attacks.

• Logical Errors

Logical errors are the most common mistakes in circuit implementations and need to be checked against the requirements document to ensure that the circuit design meets the requirements.

• Double Spending Attacks

Poor design may lead to double spending attacks. For example, some ZKP libraries have extensibility risks, allowing attackers to generate different proofs using known proofs, which could lead to double spending if not designed properly.

• Proof Forgery

Valid proofs are the primary issue that ZKP aims to solve, ensuring completeness and reliability, i.e., "false cannot be true, and true cannot be false." Therefore, if a circuit can create false proofs, it is usually due to vulnerabilities in the underlying library. We typically recommend that project parties use publicly audited ZKP libraries and stable releases.

• Side Channel Attacks

If the circuit is poorly designed, different privacy information may exhibit different computational characteristics, allowing attackers to infer private input data through public inputs or proofs.

• Circuit Constraint Failures

Improper circuit expressions may lead to variables not being constrained.

• Special Value Attacks

Certain special input values may bypass the system's verification logic, such as 0, null, etc.

• Privacy Input Inference

For applications like Tornado Cash, if the input information can be inferred, it can lead to severe privacy leakage issues. In this case, strict auditing of input data is required to ensure it cannot be inferred.

• Rug Pull Risks

Some projects may have special administrative privileges, and if these privileges are misused, it could lead to the theft of project funds and user assets.

• Smart Contract Risks

Some ZKP proofs use smart contracts for verification, such as Circom and ZoKrates. Smart contracts may face risks such as reentrancy, replay, and logical errors. For details, please refer to the Slow Fog security team's smart contract security audit services.

In response to the ZKP security issues listed above, the Slow Fog security team has summarized a set of security solutions through offensive and defensive practices, combining black-box, gray-box, and white-box testing methods, and launched ZKP circuit audit services for the blockchain industry.

Conclusion

Zero-knowledge proofs are an effective method for solving privacy, computational scalability, and data compression issues in blockchain. Currently, there are many implementation schemes, each with different performance parameters and security benchmarks. Developers need to pay attention to selecting the appropriate framework based on requirements when developing zero-knowledge proof circuits and ensure that a comprehensive security audit of the application is conducted before the project goes live.

Finally, thanks to Safeheron, a leading one-stop digital asset self-custody service provider, for their professional technical advice.

Reference Links:

[1]. https://en.wikipedia.org/wiki/Zero-knowledge_proof

[2]. https://github.com/matter-labs/awesome-zero-knowledge-proofs

[3]. https://docs.google.com/presentation/d/1gfB6WZMvM9mmDKofFibIgsyYShdf0RV_Y8TLz3k1Ls0/edit