How to build Web3 products using ZKP?
Zero-knowledge proof (ZKP) is becoming a transformative technology for the next decade.Source: “How to Leverage ZKPs as a Web3 Builder”
Authors: Mohamed Fouda, Qiao Wang
Compiled by: Deep Tide TechFlow
Zero-Knowledge Proofs (ZKP) are becoming a transformative technology for the next decade. ZKPs have applications both within and outside of Web3.
In Web3, ZKPs are addressing two main bottlenecks—scalability and privacy:
In terms of scalability, several ZK Rollups, also known as Validity Rollups, are being launched to scale Ethereum by 10-100 times while improving user experience by reducing transaction costs.
In terms of privacy, ZKPs are expanding from the era of private transactions and transaction mixing to more complex and useful areas, such as private on-chain transactions, identity, and verified credentials.
There is a lot to discuss about ZKPs, including our own vision for the future development of the ZKP space and the startups needed to realize that future. However, there remains a certain educational gap regarding how builders can benefit from ZKPs and where to start.
This article aims to bridge that gap by gathering important resources to guide developers in understanding how ZKPs work in practice and how to use ZKPs in their applications.
How do ZKPs work in practice?
ZKPs are essentially a technique where a prover demonstrates to a verifier that they know specific information without revealing that information.
In practice, at least in Web3, the way ZKPs are used is often different. Most applications do not use ZKPs to show 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 separated in a way that allows entities seeking trust to have unique interaction schemes with their users.
The main components of ZKPs are proof generation and proof verification.
Proof generation involves running a large amount of computation to generate a proof of the execution process, which is used to eliminate the trust requirement on the prover.
Conversely, anyone can run a simple process on the proof to verify the integrity of the process run by the prover.
This mental model allows businesses to run a process (often a complex one) and enables customers to trust the execution of that process without needing to repeat it.
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 is indeed running the specific model you requested, rather than substituting it with a simpler, less efficient model. What if OpenAI could send you a small amount of data proving that it is indeed running the specific model you requested? Furthermore, imagine what would happen if every proprietary SaaS product could provide such guarantees to its consumers?
This minimization of trust is the promise of ZKPs. For instance, in Web 2, ZKPs can ensure fair credit assessments or fair insurance claim processing by ensuring that all customers use the same algorithm. ZK technology has not yet reached that level, as running ZKP processes is still relatively expensive. However, we see companies like Modulus Labs building technology that uses ZKPs to prove AI inferences.
Technical Requirements of ZKPs
At a technical level, an efficient ZKP system needs to achieve the following goals simultaneously:
Reduce the computational complexity and latency of the proof system, allowing provers to efficiently generate proofs and pass them to verifiers in the shortest time possible.
Achieve small proof sizes.
Achieve efficient verification, i.e., minimize verification costs.
In addition to these primary goals, some secondary goals may be required depending on the use case, such as:
Protecting the privacy of data in privacy-focused applications, meaning the proof system can handle private inputs that are not leaked in the generated proof.
Avoiding trust setups whenever possible to simplify security assumptions.
Achieving proof recursion to further reduce verification costs, i.e., a single verification can validate multiple proofs and share costs between different proofs.
Simultaneously achieving all these goals is challenging. Depending on the use case, ZKP systems may prioritize some of these goals. For example, SNARK proof systems can produce succinct proofs, but the complexity of the proofs may increase. On the other hand, STRAK has efficient provers, but proof sizes may be 100 times larger than SNARKs. Researchers in the zk space are continuously working to push the technological frontier by inventing new proof mechanisms that improve all three metrics simultaneously.
Comparison of Different Proof Systems
An important question for developers building ZKP-related products is how to choose the underlying proof system. There are several ZKP proof implementations, with more in the research and development stage.
The choice of ZKP backend depends not only on technical aspects but also on the target product. Taking the choice of proof system for Rollups as an example. Key features of Rollups, such as withdrawal times, transaction costs, and even the degree of decentralization, will primarily be determined by the ZKP proof architecture, as shown in the table below.
In Rollups, proofs occur on the business side, i.e., through Rollup operators. Existing ZK Rollups (zkRUs), such as Starknet and Zksync, currently use centralized provers. Therefore, they can delegate proofs to specialized provers, i.e., proof-as-a-service companies, to enhance prover performance. Through specialization and leveraging optimized software/hardware, proof times for Ethereum-compatible zkEVMs can be reduced to a few minutes. For example, the proof time for Polygon zkEVM is currently about 2 minutes. A few minutes of proof time, i.e., withdrawal latency, is acceptable for Rollups.
On the other hand, some use cases require proofs to occur on the user side, generating private transactions, such as Tornado Cash transactions. To ensure a reasonable user experience, proof times cannot exceed a few seconds. Additionally, since users perform these computations on wallets or resource-constrained devices in browsers, it is crucial to choose proof systems with fast provers. A good example is Zcash, which changed its proof system to Groth16 in the 2018 Sapling upgrade, a major factor in improving the speed of shielded transactions.
Comparing Proof Systems
Generally, it is difficult to obtain an accurate comparison of the performance of different proof systems, especially regarding proof and verification speeds, as they depend on library implementations, chosen cryptographic curves, and the hardware used.
The Mina team provides a good high-level comparison in this article. There are also efforts to create benchmarking tools for different ZK systems.
This table provides a good comparison of SNARK implementations and outlines their progress in speed from Groth16 to Plonk to Halo. Despite advancements, STARKs still outperform in proof speed, but at the cost of larger proof sizes. The table also discusses two important features of proof systems: trustlessness in setup and circuit programmability.
The trustless setup portion discusses the preprocessing phase of circuit creation. Some proof techniques require participation through multiparty computation to generate secret random numbers during the preprocessing phase. If a single participant is honest, the generated random numbers are indeed secret, and the preprocessing part is secure. This process is called "trusted setup" because it relies on at least one participant in the preprocessing phase being honest. The need for a trusted setup is considered a weakness. In this sense, STARKs and new SNARK systems (like Halo 2) have advantages. However, some projects use trusted setups as a tool to attract community participation, such as Aztec and Manta.
The programmability portion discusses whether the proof system can prove arbitrary computations. SNARKs can generally be programmed for any computation. However, proof efficiency depends on the type of computation being performed. For certain types of STARK systems, this is not an easy case for adapting to different types of computations.
How to Leverage ZKPs for Your Product?
Building a product that can benefit from ZKP technology is not easy 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. Depending on product requirements, ecosystem alignment, and performance needs, there will be several tools available for developers to choose from. Some developers will be able to reuse their existing code, while others will need to learn new domain-specific languages (DSLs) to create their applications.
Performance-Focused zk Applications
Developers can use ZKPs to achieve higher throughput (TPS) or lower fees by offloading most of the application computation off-chain and only posting proofs on-chain. In this case, there are multiple frameworks to choose from. Each framework provides a set of tools for compiling application code, generating ZK circuits, implementing ZK provers, and generating verifier code for the target ecosystem. We can categorize these frameworks into two main categories: EVM-centric and non-EVM.
EVM-Centric ZK Frameworks
This set of ZK frameworks aligns with Ethereum, building Rollups on top of it. Transactions and applications are executed on the Rollup's ZK virtual machine (zkVM). Proofs are generated by specialized provers and published to L1, where they are verified by smart contracts.
The first subset of this group implements EVM-compatible zkVMs, hence referred to as zkEVMs. The goal of these 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 suitable for EVM. Polygon zkEVM and Scroll fall into this bucket.
The second subset of this group consists of zkVMs that are not natively EVM-compatible. Despite the incompatibility, this group allows developers to use Solidity by creating an intermediate layer, thus reducing friction. Vitalik refers to this type as type-4 zkEVM. zkSync Era and Starknet are good examples of this group. The advantage of using type-4 zkEVMs is that they can provide higher throughput and lower fees than EVM-compatible types. This makes them suitable for building high-throughput applications, such as on-chain games or high-performance financial products like order book DEXs.
Building applications for type-4 zkEVMs requires more developer effort due to limitations on the Solidity code that can be used. Alternatively, developers may choose to learn another language, such as Cairo, to develop native applications for these frameworks.
Non-EVM zk Frameworks
Another type of framework is those that do not target the EVM architecture, as they are aimed at competing L1s or general-purpose computing. Nevertheless, they can still be used to build application-specific zkRUs on Ethereum through specialized SDKs (like Sovereign).
There are two approaches here:
Developers write code in a high-level language targeting a specific VM architecture, which is later compiled into ZK circuits.
Developers use a domain-specific language (DSL), such as Circom, to directly generate ZK circuits.
The first approach is more suitable for developers but often results in larger circuits that require longer proof times.
Privacy-Focused ZK Applications
Developing privacy-focused applications using ZKPs is often a more challenging task for developers. Compared to scalability-focused solutions, there is less work involved in developing privacy-focused solutions using ZKPs, making the learning curve steeper. Existing privacy applications mainly focus on payment privacy and do not allow much programmability. Combining privacy and programmability is a challenging task. Privacy-focused applications follow one of the two implementation options:
1. Build on a General-Purpose L1
To enable privacy payment applications on L1, ZKP logic needs to be built as smart contracts. These applications often use ZKPs to create private capital pools. Users use these private pools as mixers to fund new wallets that are not associated with their original wallets. A well-known example is Tornado Cash. For these applications, proofs are executed by users, and verification occurs on-chain. Therefore, it is crucial to use ZKP systems with fast proofs, simple verification computations, and that do not leak any user information.
Since general-purpose chains are not optimized for expensive cryptographic computations, verification costs are often prohibitively expensive for mainstream users, limiting the adoption of these applications. The intuitive solution of moving private transaction applications to Rollups to reduce gas fees may pose challenges. In this case, private transaction proofs need to be included in the Rollup proof, i.e., proof recursion, which current general-purpose zk Rollups on Ethereum cannot achieve.
2. Build a New L1/L2 Focused on Privacy
To reduce costs for private transactions and applications, developers have to build a new privacy-centric L1 (e.g., Manta Network and Penumbra) or a specialized Rollup (e.g., Aztec). Most privacy-focused chains still cannot support general-purpose computing and focus on specialized use cases. For example, Penumbra and Renegade focus on private transactions. Aleo is building a framework for private applications by creating a dedicated language, Leo, to compile programs written in high-level languages to generate corresponding ZK circuits. Interactions of applications are done off-chain, with only the proofs of private transactions published on-chain. Aztec is moving in a similar direction but as an Ethereum L2. They recently announced a focus on creating a generalized private Rollup using Noir as the default smart contract language.
ZK Acceleration
Once developers have chosen the right ZK development framework suitable for their applications and selected the underlying proof system, the next step is to optimize the performance of the application and look for ways to improve user experience. This often boils down to enhancing prover performance and reducing latency. As discussed earlier, for Rollups, shortening proof times means shorter delays in submitting proofs to L1, thus shorter withdrawal delays. For user-generated proofs, i.e., privacy applications, faster proofs mean shorter transaction generation times and better user experiences.
As we discussed in previous articles, accelerating the proof process often requires software optimizations and dedicated hardware. In recent months, competition for dedicated hardware has intensified, with multiple companies entering the race. In this section, we will discuss the current state of ZK acceleration and how developers can benefit from this competition.
Proof as a Service
So far, the standard model for executing ZK proof work is to use powerful servers with multi-core CPUs and/or GPUs, leveraging optimized open-source libraries (such as Filecoin's Bellperson) to enhance proof performance. This model increases the operational complexity for developers who need to maintain proof infrastructure. A better model that addresses this complexity and allows for better 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 execute proof computations. Some companies can specialize in generating proofs for specific use cases. For example, Axiom has built a system for generating Halo 2 proofs on Ethereum's historical data. Other participants can focus on specific ZKP backends, such as Plonk or Halo 2, and build proprietary optimizations for faster and more efficient proof computations. The =nil Foundation is further promoting this concept by building a ZKP computing marketplace. In this Proof Market, proof buyers submit bids for ZKPs to be generated, which are matched and fulfilled by proof generators. Mina also has a similar concept called Snarketplace, but limited to the SNARK proofs required for the Mina network.
Hardware Acceleration
With the emergence of several L1s and Rollups that require efficient generation of zk proofs, the competition to generate these proofs and earn corresponding rewards will become increasingly fierce. If these chains and L2s successfully attract a large number of users, proof generation could evolve into an arms race similar to Bitcoin mining competition. There are different ZKP acceleration methods, namely GPU vs FPGA vs ASIC. This article from Amber Group provides a good discussion of these different options and the challenges faced by each implementation option. However, in the long run, companies that produce the most efficient ASICs for proof generation will have a significant economic advantage on zk-focused chains.
It is worth noting that there is an important distinction between ZK proof competition and Bitcoin mining that deserves emphasis. In Bitcoin, the mining process is based on simple computations, namely SHA256 hashes. This computation is fixed and not easily changed, so the focus is on chip design innovation and opportunities to enter advanced semiconductor nodes. In the ZKP space, there is a significant divide between different proof protocols. Even using the same proof backend, such as Plonk, the target circuit size can lead to differences in ASIC performance. This distinction between Bitcoin mining and ZKP generation may lead to multiple winners, each specializing in different ZK backends.
Multiple participants are entering the ZK-specific chip space. Each participant focuses on improving one of the two main operations for proof generation: multi-scalar multiplication (MSMs) and number-theoretic transforms (NTTs). The latest participant to emerge from stealth is Cysic, which announced its $6 million seed round during ETH Denver. Cysic focuses on accelerating MSMs using FPGAs. The flexibility of FPGAs allows them to support different ZK systems. This approach is similar to Ulventanna, which announced a $15 million seed round in January. Other participants in the ZK chip development space include Ingonyama, which released a library called Icicle to accelerate MSM and NTT computations on GPUs, as well as Accseal, Snarkify, and Supranational. In addition to this list, there are other notable participants in the Web3 space, including other stealth companies and research efforts. Examples of the latter include Jump Crypto's CycloneMSM implementation for accelerating MSM computations using FPGAs and Jane Street's FPGA implementation for accelerating MSM and NTT.
As the importance of ZKP acceleration grows, competitions to fairly evaluate different implementations (such as ZPrize) are becoming important venues for advancing the field. The prize pool for the 2022 competition exceeded $4 million.
Useful Educational Resources
In this section, we have compiled some educational resources to help developers understand the ZKP space. This is by no means an exhaustive list, as there is a wealth of excellent content on this topic. Comprehensive lists of all zk resources can be found here and here. This is an effort to create a friendly way for developers to learn about the field.
For those interested in understanding the basics of ZKPs and how they work, one of the first resources to check out is the ZK Hack's ZK Whiteboard Sessions. In particular, Dan Boneh's three introductory sessions are high-level for anyone with a certain mathematical understanding. The remainder of the series covers specific topics in the field.
For developers looking to directly use ZK tools, this excellent beginner's guide is very practical. Following that, Poseidon Labs created an application ZK workshop to guide developers in building ZK applications using Circom and Hardhat. Other workshops for different ZK languages and frameworks include this workshop using Noir and this workshop using Risc Zero.
Conclusion
As believers in the potential of ZKPs, Alliance strives to help more builders enter this space and provide them with funding and guidance support. In Web3, ZKPs have already addressed the scalability and privacy pain points that hinder mainstream adoption. In Web 2, ZKPs can bring the spirit of trust minimization to a wide range of businesses, 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.
