Hardcore Explained: Why Zero-Knowledge Proofs (ZK) Matter
TechFlow Selected TechFlow Selected
Hardcore Explained: Why Zero-Knowledge Proofs (ZK) Matter
The future of ZK is bright, as it can turn some previously impossible things into reality.
Navigating Web3 tides with focused insightsAuthor:Glaze & Fundamental Labs Research Team
If you enjoyed this research report, feel free to like, save, and share it with friends who might be interested. It helps us a lot.
TL;DR
The future of ZK is bright—it enables things that were previously impossible. In recent years, the ZK field has seen many breakthroughs, such as improved performance, upgradability, and trustless setup. These advancements have pushed ZK into the application phase. Therefore, when evaluating a new ZK proof system, we can assess it across the following dimensions:
Proof time for one transaction and ten transactions
Verification time for one transaction and ten transactions
Proof size after batching one transaction and ten transactions
Trusted setup
Reference string length
CRS support
SRS support
Recursive proof support
Quantum resistance
Security based on cryptographic assumptions
ZKEVM is the next milestone for ZKRU, with three stages:
Consensus-level
Bytecode-level
Language-level
ZKRU has just entered the application stage, and its ecosystem remains incomplete. Developers have yet to fully unlock ZK's potential. People continue to draw inspiration from these cutting-edge theories. The following directions are worth watching:
Applications that fully leverage high TPS and low fees
Cross-Layer2 communication protocols/applications
Liquidity aggregation
Development tools/frameworks
Cloud-based development tools
Unique cross-Layer2 and Layer1 applications
Different ZKVMs
ZK bridges
Applying ZK on other chains
Layer2s with recursion capabilities
ZK applications in DAO and community governance
Commercialized ZK algorithms
Chips and cloud computing
ZK applications focus on two main areas: Rollup and privacy. Rollup has better prospects than privacy. Privacy somewhat contradicts the open spirit of blockchain. Additionally, privacy may face compliance issues. In the Web2 era, we haven't seen privacy-focused apps reach top-tier status. While all applications are improving privacy protection, leading apps are rarely those emphasizing privacy—they're typically the most user-friendly ones. Privacy comes at a cost, often sacrificing usability, which users care about most.
When evaluating ZK privacy projects, the following points are important:
ZK is just a technology—focus on product strength and team
ZK is complex and can slow down development
ZK benefits DAO governance and identity verification
ZK is essential for institutional blockchain adoption
Intuition
One-sentence introduction to ZK (Zero-Knowledge Proof): The prover convinces the verifier that certain statements are true, but the verifier learns nothing beyond the truth of the statement itself.
ZK was designed for anonymity. Imagine proving your ID number is valid without revealing the actual number. This is highly significant in today’s world of excessive data collection.
Let’s consider a more vivid example. Xiao Ming and Xiao Hong are playing Sudoku. Xiao Hong wants to prove she knows the solution without revealing it because Xiao Ming hasn’t solved it yet. How would you design such a proof?
Write the Sudoku solution on cards, one digit per card, arranged correctly but face down. Xiao Ming randomly picks a row, column, or block. Xiao Hong takes the selected cards, shuffles them, flips them over, and shows they contain digits 1–9 with no duplicates. If correct, Xiao Ming knows Xiao Hong solved part of the puzzle—but maybe it was luck. Repeat multiple times. If always correct, it’s nearly impossible to be lucky—Xiao Hong must genuinely know the answer. Although Xiao Ming confirms the solution exists, he still doesn’t know what it is.
If you’re still confused, watch this video. A UCLA computer science professor explains ZK in five difficulty levels.
Common ZK Proof Paradigms
Before discussing ZK paradigms, note that ZK-SNARK isn’t a single algorithm—it’s a category. ZK-STARK is the name of a specific zero-knowledge algorithm.
The most familiar might be ZK-SNARK. SNARK stands for succinct non-interactive arguments of knowledge. Its most distinctive feature lies in the "N"—non-interactivity.
Succinctness: Verification requires far fewer computational resources than re-executing the program being proven.
Non-interactivity: The prover and verifier don’t need to communicate every round. They only require an initial trusted setup; others can join verification afterward.
Argument: If the prover has immense computational power, they could generate false proofs. But if so, standard public-key cryptography would also be broken.
Knowledge: The prover must know some secret unknown to others to generate the proof.
The biggest issue with ZK-SNARK is the requirement for trusted setup. Trusted setup generates a reference string (RS). If RS is leaked, anyone could forge proofs. Designing multi-party trusted setup is challenging. Also, RS is tied to a specific program—different programs require separate setups. Thus, ZK-SNARK cannot support general-purpose computation. Moreover, RS cannot be upgraded—if the program changes, the setup must restart.
To solve these problems, scientists explored two directions:
Transparent Setup: Generates a common reference string (CRS), which is public and needs no secrecy. Fractal, Halo, ZK-STARK, and SuperSonic follow this path. However, proofs tend to be large—reaching kB scale. On blockchains, storage is expensive.
Universal Setup: Generates a structured reference string (SRS), which must remain secret. SRS allows one setup to serve multiple programs, enabling universal computation. Marlink, SuperSonic-RSA, and Plonk take this approach.
The industry widely adopts several algorithms:
Groth16: Originally used by Zcash. It's the benchmark for ZK due to fast proving and small proof size. Downsides include trusted setup and program-specific setup. It has the most mature toolchain.
Sonic: Supports universal setup. SRS size scales linearly with program size. Proofs are fixed size, but verification is computationally heavy. Sonic enables general-purpose ZK proofs.
Fractal: Supports recursion. Proofs are relatively large.
Halo: Supports recursion but lacks succinctness (proving time is nonlinear). Halo2 is currently the mainstream proof system.
SuperSonic: The first practical, applicable transparent ZK-SNARK.
Marlin: Programs can be upgraded. Performance sits between Sonic and Groth16.
Plonk: Programs can be upgraded; participants join trusted setup sequentially, simplifying large-scale participation. Plonk uses Kate commitments instead of polynomial commitments (the first step in ZK-SNARKs converts computations to polynomials). Many modern ZK systems build upon Plonk. Plonk has excellent tooling.
If you want to study a few algorithms in depth, Groth16, Halo, and Plonk are the best choices.
CRS is the public reference string generated via Transparent Setup. SRS is the structured reference string from Universal Setup. Proof size determines Layer1 storage usage. Proof and verification times determine computational costs.
Source: Comparing General Purpose zk-SNARKs
Below is a benchmark of ZK proof algorithms, based on this experiment.
Source: Comparing General Purpose zk-SNARKs
More benchmarks and algorithm comparisons:
Benchmarking Zero-Knowledge proofs with isekai | by Guillaume Drevon | Sikoba Network | Medium
Community Proposal: A Benchmarking Framework for (Zero-Knowledge) Proof Systems (zkproof.org)
In summary, when encountering a new ZK algorithm, the following metrics matter:
Proof time for one and ten transactions
Verification time for one and ten transactions
Proof size after batching one and ten transactions
Trusted setup
Reference string length
CRS support
SRS support
Recursive proof support
Quantum resistance
Security based on cryptographic assumptions
ZK has recently moved out of labs and into real-world use. The two main application areas are Rollup and privacy. ZK’s impact on privacy products is clear, thanks to its ability to let verifiers learn nothing extra. Rollups rely on two key ZK features: succinctness and recursion. Succinctness saves verifiers massive computation—they don’t need to re-run entire programs. Recursion saves storage. With recursion, blockchains can maintain a fixed size, aiding decentralization since nodes can run on any hardware.
ZK Application Development Workflow
Developing a standalone ZK application is highly complex, requiring mastery of the following skills:
Algorithms, low-level arithmetic, optimization. Developers need these to handle finite field arithmetic, polynomial commitments, and elliptic curve issues.
ZK proof systems, e.g., ZK-SNARKs, Plonkish, and trusted setup. Developers must select and customize appropriate ZK proof systems.
Circuit programming. Developers must convert common cryptographic algorithms (like Merkle Trees and Hashes) into circuits.
Application and cryptographic protocol development.
Effective development tools can accelerate progress and reduce complexity. Tools like Circom handle low-level algebra and proof systems, letting developers focus on circuit programming and app development.
Rollup Mechanism
The idea behind Rollup is simple. Since on-chain computation is expensive, Rollup aims to securely move computation off-chain while storing only results on-chain.
The Merkle tree state root is stored in the Rollup contract. The Rollup smart contract updates the state root using data submitted from Layer2.
Source: An Incomplete Guide to Rollups (vitalik.ca)
Source: An Incomplete Guide to Rollups (vitalik.ca)
ZK Rollup (ZKRU) uses zero-knowledge proofs to ensure the new state root submitted from Layer2 is correct. Verifiers only need to validate the proof to confirm correctness, without re-executing each Layer2 transaction. This greatly reduces verification workload and boosts TPS—demonstrating ZK’s succinctness property. Leveraging ZK’s succinctness, completeness, and soundness, ZKRU securely increases TPS. (Completeness: if the proof is valid, the verifier will accept it—truth prevails. Soundness: invalid statements cannot produce valid proofs—falsehoods fail.)
Overall, ZKRU outperforms Optimistic Rollup (OPRU). OPRU has slightly lower TPS and longer withdrawal periods due to reliance on fraud proofs. So once ZKRU fully rolls out, won’t it dominate OPRU? And OPRU isn’t leading much in ecosystem maturity. But OPRU isn’t passive—they’re integrating ZK into their solutions to boost TPS and shorten native withdrawal times. For example, applying ZK to state transitions shortens fraud proof challenge windows.
Roles
In a Rollup system, there are three roles:
Users: Submit transactions on Layer2 and deposit assets from Layer1 to Layer2
Rollup Nodes: Maintain Layer2 network operations, generate proofs, execute and batch transactions, participate in fraud proofs
Layer1: Ensures Layer2 security and achieves consensus. Most current Layer1s are Ethereum.
Source: Understanding rollup economics from first principles
Economic Model
The most critical aspects of the economic model are costs and revenues. For Layer2, expenses generally include:
Cost of generating proofs
Cost of state transitions
Layer1 transaction fees
Layer1 data storage costs
Among these, Layer1 data storage is the most expensive. This diagram shows data flow: users submit transactions to Rollup nodes, which batch multiple transactions and generate proofs stored on Layer1.
Source: Understanding rollup economics from first principles
This chart shows Rollup's Layer1 expenses and revenues:
Source: L2Fees.info on 3/28/2022
Layer2’s most common revenue sources are transaction fees and MEV. Fees depend on network conditions, while MEV depends on user trades. Layer2s may also issue their own tokens and reward Rollup node operators.
Common ZKRU
This chart shows major Layer2s and their market shares. Currently, Arbitrum dominates the market.
Source: https://l2beat.com/ on 3/28/2022
The next chart shows different Layer2 technologies:
State Validation
Fraud Proofs: Allow whitelisted actors to monitor on-chain transactions and flag incorrect states.
ZK Proofs (ST): Use ZK-STARKs to prove state correctness.
SN: ZK-SNARKs
Exits Only: States are validated only during withdrawals. Intermediate states aren’t checked.
Interactive Proofs (INT): Require multiple transactions to resolve disputes.
One Round (1R): Resolve state disputes with just one round of proof.
Data Availability (DA)
On-chain: All data needed to build proofs is stored on-chain.
External DAC: All required data is off-chain. A data availability committee protects and provides the data.
External: All required data is off-chain.
Upgradability
Yes: Can upgrade anytime without notice.
21-day or no delay: Requires 21-day delay unless overridden by multisig from security council.
Sequencer Failure
L1 Transactions: Users can force inclusion of their transaction by submitting directly on L1.
Force Trade/Exit to L1: Users can submit requests on L1 to force inclusion of trades or withdrawals, but must find counterparties off-system.
Force Exit to L1: Users can submit requests on L1 to force inclusion of withdrawal requests.
Propose Blocks (ZK): Users must run their own nodes to create blocks containing desired transactions, including generating ZK proofs—a high compute demand.
Exit to L1: Users can only submit withdrawal requests on L1.
Validation Failure
Escape Hatch (MP): Users can withdraw deposits trustlessly by submitting Merkle tree proofs. Withdrawals occur at average prices from last known state.
Propose Blocks: Users must run their own nodes to create blocks.
Source: https://l2beat.com/ on 3/28/2022
Source: https://l2beat.com/ on 3/28/2022
Ethhub lists several key advantages and disadvantages of ZKRU:
Advantages
Lower user fees
Better performance, fees, and withdrawal times than OPRU
Blocks can be computed in parallel, aiding decentralization
Higher TPS
Shorter withdrawal periods, superior to fraud proofs
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
Add to FavoritesShare to Social Media
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
