Alliance Dao: How to Build Web3 Products with ZKP?
TechFlow Selected TechFlow Selected
Alliance Dao: How to Build Web3 Products with ZKP?
Zero-knowledge proofs (ZKP) are emerging as a foundational technology for transformative change in the coming decade.
Navigating Web3 tides with focused insights
Authors: Mohamed Fouda, Qiao Wang, Alliance Dao
Translation: TechFlow
Zero-knowledge proofs (ZKPs) are emerging as a foundational technology for transformative change over the next decade. ZKPs have applications both within and beyond Web3.
In Web3, ZKPs are addressing two major bottlenecks—scalability and privacy:
-
On scalability, several ZK Rollups, also known as Validity Rollups, are launching to scale Ethereum by 10–100x while improving user experience through lower transaction costs.
-
On privacy, ZKPs are expanding beyond private transactions and transaction mixing into more complex and useful domains such as private on-chain trading, identity, and verified credentials.
There is much to cover about ZKPs, including our own vision for the future development of the ZKP space and the startups needed to realize this future. However, there remains an educational gap regarding how builders can benefit from ZKPs and where to begin.
This article aims to bridge that gap by gathering key resources to guide developers on how ZKPs work in practice and how they can use them in their applications.
How Do ZKPs Work in Practice?
ZKPs are technically a method by which a prover demonstrates to a verifier that they know specific information without revealing it.
In practice—at least in Web3—the way ZKPs are used often differs. Most applications do not use ZKPs to demonstrate ownership of proprietary data. Instead, ZKPs are used to enhance trust through verifiability. We expect ZKPs to become the standard trust model between entities in the future. The reason is that the two main components of ZKPs—proof and verification—are being decoupled in a way that creates unique interaction models between trust-seeking entities and their users.
The core components of ZKPs are proof generation and proof verification.
-
Proof generation involves running intensive computations to generate a proof of a process execution, which eliminates the need to trust the prover.
-
Conversely, anyone can run a simple procedure on the proof to verify the integrity of the prover's executed process.
This mental model allows businesses to run a process (often a complex one) and enable customers to trust its execution without having to re-execute the entire process themselves.
Let’s take an example:
Suppose you subscribe to OpenAI’s paid plan and use one of their large language models (LLMs), such as ChatGPT. You must trust that OpenAI actually ran the specific model you requested, rather than substituting a simpler, less efficient model. What if OpenAI could send you a small amount of data proving that they indeed ran the exact model you requested? Moreover, imagine what would happen if every proprietary SaaS product could provide such guarantees to its consumers?
This trust minimization is the promise of ZKPs. For instance, in Web2, ZKPs could ensure fair credit assessments or fair insurance claims processing by guaranteeing all clients use the same algorithm. ZK technology has not yet reached that level because running ZKP processes remains relatively expensive. However, we see companies like Modulus Labs building technologies that use ZKPs to prove AI inference.
Technical Requirements of ZKPs
At a technical level, an efficient ZKP system needs to simultaneously achieve the following goals:
-
Reduce computational complexity and latency of the proof system—that is, allow provers to efficiently generate proofs and transmit them to verifiers in minimal time.
-
Achieve small proof size.
-
Enable efficient verification—that is, minimize verification cost.
Beyond these primary goals, some secondary objectives may be required depending on the use case, such as:
-
Preserving data privacy in privacy-focused applications, meaning the proof system can handle private inputs that are not leaked in the generated proof.
-
Avoiding trusted setup whenever possible to simplify security assumptions.
-
Achieving proof recursion to further reduce verification costs—that is, a single verification can validate multiple proofs, spreading the cost across different proofs.
Achieving all these goals simultaneously is challenging. Depending on the use case, ZKP systems will prioritize certain goals. For example, SNARK proof systems can produce succinct proofs, but at the cost of increased proof complexity. On the other hand, STARKs have efficient provers, but proof sizes can be up to 100 times larger than SNARKs. Researchers continuously push the frontier by inventing new proof mechanisms that improve all three metrics simultaneously.
Comparison of Different Proof Systems
An important consideration for developers building ZKP-related products is how to choose the underlying proof system. There are several ZKP implementations already available, with many more in research and development.
The choice of ZKP backend depends not only on technical aspects but also on the target product. Take choosing a proof system for rollups as an example. Key characteristics of rollups—such as withdrawal times, transaction costs, and even decentralization levels—are primarily determined by the ZKP proof architecture, as shown in the table below.
In rollups, proof generation occurs on the operator side. Existing ZK rollups (zkRUs), such as Starknet and zkSync, currently use centralized provers. Therefore, they can delegate proof generation to specialized proof-as-a-service providers to improve performance. Through specialization and optimized software/hardware, proof times for Ethereum-compatible zkEVMs can be reduced to minutes. For example, Polygon zkEVM currently achieves proof times of around 2 minutes. A few-minute proof time—and thus withdrawal delay—is acceptable for rollups.
On the other hand, some use cases require proof generation on the user side—for example, generating private transactions like those in Tornado Cash. To ensure a reasonable user experience, proof time must not exceed a few seconds. Additionally, since users perform these computations via wallets or browsers on resource-constrained devices, selecting a proof system with fast prover performance is critical. A good example is Zcash switching its proof system to Groth16 during the 2018 Sapling upgrade, a major factor in speeding up shielded transactions.
Comparing Proof Systems
It is generally difficult to obtain accurate performance comparisons across different proof systems, especially for proof and verification speeds, as they depend on library implementations, chosen cryptographic curves, and hardware used.
The Mina team provides a solid high-level comparison in this article. There are also ongoing efforts to create benchmarking tools for different ZK systems.
This table offers a good comparison of SNARK implementations and shows progress in speed from Groth16 to Plonk to Halo. Despite this progress, STARKs still outperform in proof speed, albeit at the cost of larger proof sizes. The table also discusses two important features of proof systems: trustless setup and circuit programmability.
The trustless setup section discusses the preprocessing phase of circuit creation. Some proof techniques require secret random numbers to be generated via multi-party computation during this phase. If at least one participant is honest, the generated randomness remains secure. This process is called a “trusted setup” because it relies on the assumption that at least one participant in the setup phase was honest. Requiring a trusted setup is considered a weakness. In this regard, STARKs and newer SNARK systems like Halo 2 have an advantage. However, some projects use trusted setups as a mechanism to engage community participation, such as Aztec and Manta.
The programmability section discusses whether a proof system can prove arbitrary computations. SNARKs are generally programmable for any computation. However, proof efficiency depends on the type of computation performed. This is less flexible for certain types of STARK systems when adapting to different computation types.
How Can You Leverage ZKPs for Your Product?
Building a product that benefits from ZKP technology is not straightforward and requires establishing the right mental model.
This section attempts to provide developers with a framework for choosing the best approach to integrate ZKPs into their products. Based on product requirements, ecosystem alignment, and performance needs, several tools will be available. Some developers will be able to reuse existing code, while others will need to learn new domain-specific languages (DSLs) to build their applications.
Performance-Focused ZK Applications
Developers can use ZKPs to achieve higher throughput (TPS) or lower fees by offloading most application computation off-chain and publishing only proofs on-chain. In this scenario, multiple frameworks are available. Each provides a set of tools to compile application code, generate ZK circuits, implement ZK provers, and generate verifier code for the target ecosystem. We can categorize these frameworks into two main groups: EVM-centric and non-EVM.
EVM-Centric ZK Frameworks
This group of ZK frameworks aligns with Ethereum and serves as the foundation for rollups. Transactions and applications execute on the rollup’s ZK virtual machine (zkVM). Proofs are generated by dedicated provers and published to L1, where they are verified by smart contracts.
The first subset implements zkVMs compatible with the EVM, hence called zkEVMs. Their goal is to minimize friction by allowing Ethereum developers to use Solidity and familiar tools like Hardhat and Foundry. They abstract ZK complexity by creating circuits and provers tailored for the EVM. Polygon zkEVM and Scroll fall into this category.
The second subset consists of zkVMs that are not natively EVM-compatible. Although incompatible, this group reduces friction by introducing intermediate layers that allow developers to use Solidity. Vitalik refers to this type as Type-4 zkEVM. zkSync Era and Starknet are good examples of this group. A key advantage of Type-4 zkEVMs is that they can offer higher throughput and lower fees compared to EVM-compatible versions, making them suitable for high-throughput applications such as on-chain gaming or high-performance financial products like order-book DEXs.
Building applications for Type-4 zkEVMs requires more developer effort due to limitations on usable Solidity code. Alternatively, developers can choose to learn another language, such as Cairo, to develop native applications for these frameworks.
Non-EVM ZK Frameworks
Another category includes frameworks not targeting the EVM architecture, either because they aim at competing L1s or general-purpose computation. Nonetheless, they can still be used via specialized SDKs (e.g., Sovereign) to build application-specific zkRUs on Ethereum.
There are two approaches here:
-
Developers write code in a high-level language, which is then compiled for a specific VM architecture and later converted into a ZK circuit.
-
Developers use a domain-specific language (DSL), such as Circom, to directly generate ZK circuits.
The former approach is more developer-friendly but typically results in larger circuits and longer proof times.
Privacy-Focused ZK Applications
Developing privacy-focused applications using ZKPs is generally a more challenging task for developers. Compared to scalability-focused solutions, fewer tools exist for privacy-focused ZKP development, resulting in a steeper learning curve. Existing privacy applications mainly focus on payment privacy and offer limited programmability. Combining privacy with programmability remains a significant challenge. Privacy-focused applications follow one of two implementation paths:
1. Building on top of a general-purpose L1
To enable private payment applications on an L1, ZKP logic must be implemented as smart contracts. These applications often use ZKPs to create private capital pools. Users utilize these private pools as mixers to fund new wallets unlinked to their original addresses. A notable example is Tornado Cash. For such applications, proof generation is done by users, and verification occurs on-chain. Therefore, using a ZKP system with fast proof generation, simple verification, and no leakage of user information is crucial.
Since general-purpose chains are not optimized for expensive cryptographic computations, verification costs are typically too high for mainstream adoption. An intuitive solution—moving private transaction apps to rollups to reduce gas fees—can introduce challenges. In this case, private transaction proofs must be included within the rollup proof itself (i.e., proof recursion), which current general-purpose zk rollups on Ethereum do not support.
2. Building privacy-focused new L1/L2
To reduce costs for private transactions and applications, developers must build a new privacy-centric L1 (e.g., Manta Network, Penumbra) or a dedicated rollup (e.g., Aztec). Most privacy-focused chains still lack support for general computation and focus on specialized use cases. For example, Penumbra and Renegade focus on private trading. Aleo is building a framework for private applications by creating a dedicated language, Leo, which compiles high-level programs into corresponding ZK circuits. Application interactions occur off-chain, with only proofs submitted as private transactions on-chain. Aztec is moving in a similar direction but as an Ethereum L2. They recently announced a focus on building a general-purpose private rollup using Noir as the default smart contract language.
ZK Acceleration
After developers select the appropriate ZK development framework for their application and choose the underlying proof system, the next step is optimizing performance and improving user experience. This usually comes down to enhancing prover performance and reducing latency. As previously discussed, for rollups, shorter proof times mean faster submission to L1 and thus shorter withdrawal delays. For user-generated proofs—such as in privacy applications—faster proofs mean shorter transaction generation times and better UX.
As discussed in our previous articles, accelerating proof generation typically requires both software optimization and dedicated hardware. Over recent months, competition in dedicated hardware has intensified, with multiple companies entering the race. In this section, we discuss the current state of ZK acceleration and how developers can benefit from this competition.
Proof-as-a-Service
The standard model so far for executing ZK proof work involves using powerful servers equipped with multi-core CPUs and/or GPUs, leveraging optimized open-source libraries (e.g., Filecoin’s Bellperson) to boost proof performance. This model increases operational complexity for developers who must maintain proof infrastructure. A better model that reduces this complexity and enables greater specialization is the proof-as-a-service model. In this model, entities needing to generate proofs for a specific ZK circuit or use case connect to providers running proprietary software to perform proof computation. Some companies can specialize in generating proofs for specific use cases. For example, Axiom builds a system for generating Halo 2 proofs of Ethereum historical data. Other players may focus on specific ZKP backends, such as Plonk or Halo 2, and build proprietary optimizations for faster and more efficient proof computation. =nil Foundation is pushing this concept further by building a ZKP computation marketplace. In this Proof Market, proof buyers submit bids for ZKPs to be generated, matched and fulfilled by proof generators. Mina has a similar concept called Snarketplace, limited to SNARK proofs required by the Mina network.
Hardware Acceleration
With the launch of several L1s and rollups requiring efficient ZK proof generation, competition to generate these proofs and earn associated rewards will intensify. If these chains and L2s successfully attract large user bases, proof generation could evolve into an arms race similar to Bitcoin mining. Different ZKP acceleration methods exist—GPU vs FPGA vs ASIC. This article from Amber Group offers a great discussion of these options and the challenges each faces. In the long term, companies producing the most efficient ASICs for proof generation will gain significant economic advantages on ZK-focused chains.
A key distinction between ZK proof competition and Bitcoin mining deserves emphasis. In Bitcoin, mining relies on a fixed, simple computation—SHA256 hashing—which rarely changes, placing focus on chip design innovation and access to advanced semiconductor nodes. In contrast, the ZKP landscape features significant fragmentation across different proof protocols. Even with the same backend (e.g., Plonk), differences in target circuit sizes can lead to varying ASIC performance. This divergence between Bitcoin mining and ZKP generation may result in multiple winners, each specializing in different ZK backends.
Multiple players are entering the ZK-specific chip space. Each focuses on accelerating one of the two core operations in proof generation: multi-scalar multiplication (MSMs) and number-theoretic transform (NTT). The latest entrant to emerge from stealth is Cysic, which announced a $6 million seed round during ETH Denver. Cysic focuses on accelerating MSMs using FPGAs. FPGA flexibility allows support for various ZK systems. This approach resembles Ulventanna, which announced a $15 million seed round in January. Other participants in ZK chip development include Ingonyama, which released Icicle—a library accelerating MSM and NTT computations on GPUs—as well as Accseal, Snarkify, and Supranational. Beyond this list, prominent Web3 players harbor other stealth companies and research initiatives. Examples include Jump Crypto’s CycloneMSM implementation for FPGA-accelerated MSM computation and Jane Street’s FPGA implementations for accelerating both MSM and NTT.
Given the growing importance of ZKP acceleration, competitive benchmarks designed to fairly evaluate different implementations (e.g., ZPrize) are becoming key drivers of progress in the field. The 2022 competition offered over $4 million in prizes.
With the launch of several L1s and rollups requiring efficient ZK proof generation, competition to generate these proofs and earn associated rewards will intensify. If these chains and L2s successfully attract large user bases, proof generation could evolve into an arms race similar to Bitcoin mining. Different ZKP acceleration methods exist—GPU vs FPGA vs ASIC. This article from Amber Group offers a great discussion of these options and the challenges each faces. In the long term, companies producing the most efficient ASICs for proof generation will gain significant economic advantages on ZK-focused chains.
A key distinction between ZK proof competition and Bitcoin mining deserves emphasis. In Bitcoin, mining relies on a fixed, simple computation—SHA256 hashing—which rarely changes, placing focus on chip design innovation and access to advanced semiconductor nodes. In contrast, the ZKP landscape features significant fragmentation across different proof protocols. Even with the same backend (e.g., Plonk), differences in target circuit sizes can lead to varying ASIC performance. This divergence between Bitcoin mining and ZKP generation may result in multiple winners, each specializing in different ZK backends.
Multiple players are entering the ZK-specific chip space. Each focuses on accelerating one of the two core operations in proof generation: multi-scalar multiplication (MSMs) and number-theoretic transform (NTT). The latest entrant to emerge from stealth is Cysic, which announced a $6 million seed round during ETH Denver. Cysic focuses on accelerating MSMs using FPGAs. FPGA flexibility allows support for various ZK systems. This approach resembles Ulventanna, which announced a $15 million seed round in January. Other participants in ZK chip development include Ingonyama, which released Icicle—a library accelerating MSM and NTT computations on GPUs—as well as Accseal, Snarkify, and Supranational. Beyond this list, prominent Web3 players harbor other stealth companies and research initiatives. Examples include Jump Crypto’s CycloneMSM implementation for FPGA-accelerated MSM computation and Jane Street’s FPGA implementations for accelerating both MSM and NTT.
Given the growing importance of ZKP acceleration, competitive benchmarks designed to fairly evaluate different implementations (e.g., ZPrize) are becoming key drivers of progress in the field. The 2022 competition offered over $4 million in prizes.
Useful Educational Resources
In this section, we compile educational resources to help developers understand the ZKP space. This is by no means exhaustive, as there is excellent content across this domain. Comprehensive lists of all ZK resources can be found here and here. These efforts make it easier for developers to get started in this field.
For those interested in understanding ZKP fundamentals and how they work, one of the first resources to explore is ZK Hack’s ZK Whiteboard Sessions. In particular, Dan Boneh’s three introductory lectures offer a high-level overview accessible to anyone with basic mathematical understanding. The rest of the series covers specific topics in the field.
For developers eager to start using ZK tools directly, this excellent beginner’s guide is highly practical. Following that, Poseidon Labs created an applied ZK workshop guiding developers through building ZK applications using Circom and Hardhat. Additional workshops targeting other ZK languages and frameworks include this one using Noir and this one using Risc Zero.
Conclusion
As believers in the potential of ZKPs, Alliance strives to help more builders enter this space and provides them with funding and mentorship support. In Web3, ZKPs have already addressed scalability and privacy pain points hindering mainstream adoption. In Web2, ZKPs can bring the ethos of trust minimization to a broad range of industries including SaaS, insurance, and credit scoring. This article aims to help builders integrate ZKPs into their products. It guides builders through different stages of planning ZKP integration, covering implementation options and post-deployment performance improvements.
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
Alliance
