Zero-Knowledge Proof Beginner's Guide: Development History, Applications, and Fundamentals
TechFlow Selected TechFlow Selected
Zero-Knowledge Proof Beginner's Guide: Development History, Applications, and Fundamentals
Reviewing some changes in ZKP theory and applications from the ground up.
Navigating Web3 tides with focused insightsAuthor: HashKey Capital
The blockchain industry is currently witnessing an astonishing surge in zero-knowledge proof (ZKP) projects, particularly driven by the rise of ZKP applications in scaling and privacy protection. This has exposed us to a wide variety of zero-knowledge proof projects. Due to the highly mathematical nature of ZKPs, it has become significantly more challenging for crypto enthusiasts to deeply understand them. Therefore, we aim to systematically review recent developments in ZKP theory and applications, exploring their impact and value within the crypto industry—through a series of research reports that also serve as reflections from the HashKey Capital research team. This article is the first in the series, primarily introducing the history, applications, and fundamental principles of ZKPs.
I. The History of Zero-Knowledge Proofs
The modern framework of zero-knowledge proofs originated from the seminal paper by Goldwasser, Micali, and Rackoff titled "The Knowledge Complexity of Interactive Proof Systems" (GMR85), presented in 1985 and published in 1989. This paper explored how much knowledge must be exchanged over K rounds of interaction in an interactive system to prove the correctness of a statement. If this exchanged knowledge can be reduced to zero, it is called a zero-knowledge proof. In this model, the prover is assumed to have unlimited computational resources, while the verifier operates with limited resources. A key limitation of interactive systems is that proofs are not mathematically deterministic but probabilistically correct—with a negligible error probability (e.g., 1/2^n).
Thus, interactive systems are imperfect, possessing only approximate completeness. In contrast, non-interactive systems based on NP problems offer full completeness and have therefore become the preferred foundation for practical zero-knowledge proof systems.
Early zero-knowledge proof systems were inefficient and impractical, remaining largely theoretical until the past decade, when rapid advancements—fueled by cryptography’s growing prominence in crypto—brought ZKPs into the spotlight as a critical technological direction. One of the most important goals has been developing a universal, non-interactive zero-knowledge proof protocol with succinct proof size.
In general, zero-knowledge proofs involve trade-offs between proof generation speed, verification speed, and proof size. The ideal protocol achieves fast proving, fast verification, and small proof size.
A pivotal breakthrough came in 2010 with Groth’s paper “Short Pairing-based Non-interactive Zero-Knowledge Arguments,” which laid the theoretical groundwork for zk-SNARKs—one of the most influential ZKP constructions.
The most significant application milestone was in 2015 with Zcash, which implemented a zero-knowledge proof system to protect transaction details and amounts. This later evolved into combining zk-SNARKs with smart contracts, expanding zk-SNARKs into broader application scenarios.
Key academic advances during this period include:
-
2013 – Pinocchio (PGHR13): "Pinocchio: Nearly Practical Verifiable Computation," which brought proof and verification times into practical ranges and served as the foundational protocol for Zcash.
-
2016 – Groth16: "On the Size of Pairing-based Non-interactive Arguments," which minimized proof size and improved verification efficiency, becoming the most widely used ZK base algorithm today.
-
2017 – Bulletproofs (BBBPWM17): "Bulletproofs: Short Proofs for Confidential Transactions and More," introduced the Bulletproofs algorithm—a short, non-interactive zero-knowledge proof that requires no trusted setup. It was adopted by Monero just six months later, marking one of the fastest transitions from theory to real-world deployment.
-
2018 – zk-STARKs (BBHR18): "Scalable, transparent, and post-quantum secure computational integrity," introduced the zk-STARK protocol, which eliminates the need for a trusted setup. This became another major direction in ZK development and led to the creation of StarkWare, one of the most prominent ZK projects.
Other notable developments such as PLONK and Halo2 represent significant improvements to zk-SNARKs in various aspects.
II. Overview of Zero-Knowledge Proof Applications
The two most widespread applications of zero-knowledge proofs are privacy protection and scaling. Early on, privacy-focused transactions gained attention through high-profile projects like Zcash and Monero. However, since the necessity of privacy transactions did not meet initial expectations across the industry, these representative projects gradually moved into secondary or tertiary status (though they remain active). Meanwhile, the demand for scaling solutions has surged. With Ethereum 2.0 (now called the consensus layer) shifting in 2020 toward a rollup-centric roadmap, ZK-based technologies re-entered the mainstream spotlight and became a focal point of innovation.
Privacy Transactions: Several privacy transaction implementations exist, including Zcash (using SNARKs), Tornado Cash (also using SNARKs), Monero (using Bulletproofs), and Dash. Dash does not strictly use ZKPs; instead, it employs a simple coin-mixing mechanism that hides addresses but not transaction amounts, so it will not be discussed further here.
The zk-SNARK transaction process in Zcash proceeds as follows:
Source: Demystifying the Role of zk-SNARKs in Zcash
-
System Setup Phase: Generates proving key (for encrypting proof polynomials) and verification key using the KeyGen function.
-
CPA Phase: Uses ECIES (Elliptic Curve Integrated Encryption Scheme) to generate public and private keys.
-
Minting Coins Phase: Specifies the number of new coins, public address, and coin commitment.
-
Pouring Phase: Generates a zk-SNARK proof, which is added to the pour transaction ledger.
-
Verification Phase: Verifier checks whether mint and pour transaction quantities are correct.
-
Receiving Phase: Recipient receives coins. To spend received coins, the user calls the Pouring function again, generating another zk-SNARK proof and repeating steps 4–6 to complete the transaction.
However, Zcash’s use of zero-knowledge proofs has limitations. Being UTXO-based, it only shields certain transaction data rather than fully concealing it. Additionally, its design inherits from Bitcoin’s separate network architecture, making integration with other applications difficult. Less than 10% of users actually utilize shielding (i.e., private transactions), indicating limited adoption and scalability of privacy features. (from 2202)
Tornado Cash uses a single large mixing pool, which is more versatile and built atop Ethereum—a battle-tested network. Essentially, Tornado is a mixing pool enhanced with zk-SNARKs, relying on a trusted setup derived from Groth16. Features provided by Tornado Cash include:
-
Only deposited coins can be withdrawn.
-
No coin can be withdrawn twice.
-
Proof generation and nullifiers are bound together; duplicate proofs with different nullifier hashes cannot trigger withdrawals.
-
Security level is 126-bit and does not degrade under composition.
Vitalik has noted that compared to scaling, privacy is relatively easier to achieve—if scaling protocols can succeed, privacy will likely follow without major hurdles.
Scaling: ZK-based scaling can occur at Layer 1 (e.g., Mina) or Layer 2 via zk-rollups. The concept of ZK rollups may trace back to Vitalik’s 2018 blog post, “On-chain scaling to potentially ~500 tx/sec through mass tx validation.”
In a ZK rollup, there are two main roles: the Sequencer and the Aggregator. The Sequencer batches transactions, while the Aggregator consolidates many transactions into a rollup and generates a SNARK proof (or another type of zero-knowledge proof). This proof is then compared against the previous state on Layer 1 to update Ethereum’s Merkle tree and compute the new state root.
Source: Polygon
Advantages and Disadvantages of ZK Rollups:
-
Advantages: Low fees, immune to economic attacks unlike optimistic rollups, no withdrawal delays, privacy-preserving, fast finality
-
Disadvantages: High computational cost for generating ZK proofs, security concerns (SNARKs require a trusted setup), vulnerable to quantum attacks (SNARKs are, though STARKs are post-quantum secure), potential for transaction reordering
Source: Ethereum Research
Based on data availability and proof methodology, Starkware provides a classic classification diagram for Layer 2 solutions (with Volition allowing data availability to be chosen on-chain or off-chain):
Source: Starkware
Currently, the most competitive ZK rollup projects include Starkware’s StarkNet, Matterlabs’ zkSync, Aztec’s Aztec Connect, Polygon’s Hermez and Miden, Loopring, Scroll, and others.
Technological differentiation mainly lies in choosing between SNARK (and its variants) and STARK, along with varying degrees of EVM support (compatibility vs equivalence).
-
Aztec developed the generalized SNARK protocol Plonk. Aztec3 may support EVM, but prioritizes privacy over EVM compatibility.
-
StarkNet uses zk-STARK, a ZKP that does not require a trusted setup, but currently lacks EVM support and uses its own compiler and programming language.
-
zkSync uses Plonk and supports EVM. zkSync 2.0 is EVM-compatible and features its own zkEVM.
-
Scroll is an EVM-compatible ZK rollup and a major contributor to the Ethereum Foundation's zkEVM project.
A brief discussion on EVM compatibility:
Compatibility between ZK systems and EVM has long been a challenge, forcing most projects to make trade-offs. Projects emphasizing ZK often build custom virtual machines with proprietary ZK languages and compilers, increasing developer learning curves and creating black-box systems due to lack of open-source transparency. Currently, the industry generally adopts one of two approaches: full opcode-level compatibility with Solidity, or designing a new ZK-friendly VM that remains compatible with Solidity. Initially, few expected such rapid convergence, but recent technical iterations have elevated EVM compatibility to new heights, enabling near-seamless migration from Ethereum mainnet to ZK rollups—an exciting advancement that will shape ZK developer ecosystems and competitive dynamics. We will explore this topic in greater depth in future reports.
III. Fundamental Principles of zk-SNARK Implementation
Goldwasser, Micali, and Rackoff defined three essential properties of zero-knowledge proofs:
-
Completeness: Every valid statement with a proper witness can be verified by the verifier.
-
Soundness: No invalid statement with an improper witness should be accepted by the verifier.
-
Zero-Knowledgeness: The verification process reveals no additional information beyond the truth of the statement.
To understand ZKPs, we begin with zk-SNARKs, as many current blockchain applications are built upon them. First, let’s examine what zk-SNARK means.
zk-SNARK stands for zero-knowledge Succinct Non-Interactive Argument of Knowledge.
-
Zero-Knowledge: The proof reveals nothing beyond the validity of the statement.
-
Succinct: Proofs are small in size and quick to verify.
-
Non-Interactive: No back-and-forth communication is required between prover and verifier.
-
Arguments: Computationally sound—proofs cannot be forged by provers with bounded computing power, although those with unbounded power could.
-
of Knowledge: The prover cannot construct a valid proof without knowing the underlying witness data.
-
For the prover, it is impossible to construct valid parameters and proofs without knowledge of the witness (e.g., input to a hash function or path to a specific Merkle tree node).
The proof mechanism of Groth16’s zk-SNARK works as follows:
Source: https://learnblockchain.cn/article/3220
Steps involved:
-
Convert the problem into a circuit representation.
-
Flatten the circuit into Rank-1 Constraint System (R1CS) form.
-
Transform R1CS into Quadratic Arithmetic Programs (QAP).
-
Establish a trusted setup to generate random parameters, including PK (proving key) and VK (verification key).
-
Generate and verify the zk-SNARK proof.
In the next report, we will delve deeper into the principles and applications of zk-SNARKs, analyze several case studies to illuminate their evolution, and explore the relationship between zk-SNARKs and zk-STARKs.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
