Written by: Mohamed Fouda, Qiao Wang, Alliance Dao
Compiled by: TechFlow
Zero-knowledge proof (ZKP) is becoming a fundamentally transformative technology for the next decade. ZKP has applications both within and outside of Web 3.
In Web 3, this technology is solving two major pain points: scalability and privacy, which are two major bottlenecks facing exciting blockchains:
On the scalability front, several ZK Rollups, aka Validity Rollups, are being launched to scale Ethereum 10-100x while improving the 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, identities, and verified credentials.
There is a lot of content out there about ZKPs, including our own vision for the future of the ZKP space and the startups needed to make that future a reality. However, there is still a bit of an education gap on how builders can benefit from ZKPs and where to get started.
This article aims to fill this gap by bringing together important resources to guide developers through how ZKPs work in practice and how to use them in their applications.
How do ZKPs work in practice?
How ZKP actually works is that one party, called the prover, proves to another party, the verifier, that they know specific information, without revealing that information.
In practice, at least in Web 3, ZKPs are often used differently. Most applications do not use ZKPs to show ownership of proprietary data. Instead, ZKPs are used to increase 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 — attestation and verification — are being separated in a way that enables unique interaction scenarios between trust-seeking entities and their users.
The main components of a ZKP are proof generation and proof verification. Proof generation involves running a large amount of computation to generate a proof of an executed process. This proof is used to eliminate the need to trust the prover. Instead, anyone can run a simple process on the proof to verify the integrity of the process run by the prover. This mental model allows an enterprise to run a process (usually a complex one) and allow customers to trust the execution of said process without having to repeat the process.
Let's take an example:
Let's say you subscribe to OpenAI's paid plan and use one of their Large Language Models (LLMs), such as chatGPT. You have to trust that OpenAI actually ran the specific model you requested, and didn't replace it with a simpler, less efficient model. What if OpenAI could send you a small amount of data proving that it actually ran the specific model you requested? Furthermore, imagine what would happen if every proprietary SaaS product could provide such a guarantee to its consumers?
This trust minimization is the promise of ZKPs. For example, in Web 2, ZKPs could guarantee fair credit assessments or fair insurance claims processing by ensuring that all customers use the same algorithm. ZK technology is not there yet because running a ZKP process is still relatively expensive. However, we are seeing companies like Modulus Labs building a technology that uses ZKPs to prove AI inferences.
Technical Requirements for ZKP
On a technical level, an efficient ZKP system needs to achieve the following goals simultaneously:
Reduce the computational complexity and latency of the proof system, that is, allow the prover to efficiently generate proofs and pass them to the verifier in the shortest possible time.
Achieve small proof size.
Achieve efficient verification, that is, minimize verification costs.
In addition to these primary goals, some secondary goals may be required depending on the use case, such as:
Preserving the privacy of data in privacy-focused applications means that the proof system can process private inputs that are not revealed in the generated proofs.
Avoid trusted setups whenever possible to simplify security assumptions.
Proof recursion is implemented to further reduce verification cost, i.e. a single verifier can verify multiple proofs and amortize the cost among different proofs.
Achieving all of these goals simultaneously is challenging. Depending on the use case, a ZKP system prioritizes some of these goals over others. For example, a SNARK proof system can produce concise proofs, but the proof complexity increases. On the other hand, STRAK has an efficient prover, but the proof size can be 100 times larger than SNARK. ZK researchers are constantly working to push the frontier of technology, improving all three metrics simultaneously by inventing new proof mechanisms.
Comparison of different proof systems
For developers building ZKP-related products, an important question to consider is how to choose the underlying proof system. There are several ZKP proof implementations, and many more are in the R&D stage. The ZKP backend selection depends not only on technical aspects, but also on the target product. Take the choice of proof system for Rollup as an example. The key characteristics of Rollup, such as withdrawal time, transaction cost, and even the degree of decentralization, will be mainly determined by the ZKP proof architecture, as shown in the table below.
In a Rollup, proof happens on the business side, i.e. by the Rollup operator. 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 improve prover performance. Through specialization and leveraging optimized software/hardware, proof times can be reduced to minutes for Ethereum-compatible zkEVMs. For example, proof times for Polygon zkEVM are currently around 2 minutes. Proof times of a few minutes, i.e. withdrawal latency, are acceptable for Rollups.
On the other hand, some use cases require that proofs happen on the user side, generating private transactions, such as Tornado Cash transactions. To ensure a reasonable user experience, proofs cannot take more than a few seconds. Furthermore, since users are performing these computations in a browser using a wallet or on a resource-constrained device, it is important to choose a proof system with fast provers. A good example is Zcash changing its proof system to Groth16 in the 2018 Sapling upgrade, which was a major factor in increasing the speed of shielded transactions.
Comparative Proof Systems
In general, it is difficult to get an accurate comparison of the performance of different proof systems, especially for proving and verification speeds, as they depend on the library implementation, the chosen cryptographic curve, and the hardware used. The Mina team provides a nice high-level comparison in this post. There are also some efforts to create benchmarking tools for different ZK systems.
This table provides a good comparison of SNARK implementations and describes their progress in speed from Groth16 to Plonk to Halo. Despite the progress, STARKs still win in proof speed, but at the expense of larger proof size. The table also discusses two important characteristics of proof systems: trustlessness of setup and circuit programmability.
The section on setting up trustlessness discusses the preprocessing phase of circuit creation. Some proof techniques require the participation of multi-party computations to generate secret random numbers in the preprocessing phase. If the individual participants are honest, the generated random numbers are indeed secret and the preprocessing part is secure. This process is called a "trusted setup" because it trusts that at least one participant in the preprocessing phase is honest. The need for a trusted setup is considered a weakness. In this sense, STARKs and new SNARK systems such as Halo 2 have an advantage. However, some projects use trusted setup as a tool to attract community participation, such as Aztec and Manta.
The programmability section discusses whether the proof system can prove arbitrary computations. SNARKs can generally program any computation. However, the efficiency of the proof depends on the type of computation being performed. For some types of STARK systems, this is not an easy case to adapt to different types of computations.
How to leverage ZKP for your product?
Building a product that can benefit from ZKP technology is not an easy task and requires building the right mental model. This section attempts to provide a framework for developers to choose the best approach to integrate ZKP into their products. Depending on product needs, ecosystem alignment, and performance requirements, there will be several tools for developers to choose from. Some developers will be able to reuse their existing code, while others will have to learn a new domain-specific language (DSL) to create their applications.
Performance-focused zk applications
Developers can use ZKP to achieve higher throughput (TPS) or lower fees by moving most of the application computation off-chain and only publishing 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 validator code for the target ecosystem. We can divide these frameworks into two main categories: EVM-centric and non-EVM.
EVM-based ZK framework
This set of ZK frameworks is consistent with Ethereum, as Rollup is built on top of it. Transactions and applications are executed on the ZK Virtual Machine (zkVM) of Rollup. Proofs are generated by dedicated provers and published to L1 to be verified by smart contracts.
The first subset of this group implements zkVMs that are compatible with the EVM, hence the name zkEVM. These aim 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 that work with the EVM. Polygon zkEVM and Scroll are both included in this bucket.
The second subset of this group is zkVMs that are not natively EVM compatible. This group reduces friction by creating an intermediary layer to allow developers to use Solidity despite the incompatibility. Vitalik calls this type type-4 zkEVM. zkSync Era and Starknet are good examples of this group. The advantage of using Type-4 zkEVM is that it can provide higher throughput and lower fees than compatible EVM types. This makes them suitable for building high-throughput applications such as on-chain games or high-performance financial products such as order book DEXs.
Building applications for type-4 zkEVM requires more developer effort due to restrictions on what Solidity code can be used. Alternatively, developers may decide to learn another language, such as Cairo, to develop native applications for these frameworks.
Non-EVM zk framework
Another type of frameworks are those that do not target the EVM architecture, as they target competing L1 or general purpose computation. Nonetheless, they can still be used to build application specific zkRUs on Ethereum through specialized SDKs such as Sovereign.
There are two ways to do this:
Developers write code in a high-level language, which is targeted to a specific VM architecture and later compiled into a ZK circuit.
Developers generate ZK circuits directly using a domain-specific language (DSL) such as Circom.
The former approach is more developer-friendly but typically results in larger circuits that take longer to prove.
Privacy-focused ZK applications
Developing privacy-focused applications using ZKPs is generally a more challenging task for developers. There is less work to develop privacy-focused solutions using ZKPs compared to scalability-focused solutions, making the learning curve steeper. Existing privacy applications focus primarily on payment privacy and do not allow much programmability. Combining privacy and programmability is a challenging task. Privacy-focused applications follow one of the following two implementation options:
1. Building on top of common L1
To enable private payment applications on L1, ZKP logic needs to be built as smart contracts. This application often uses ZKP to create private pools of capital. Users use these private pools as mixers to fund new wallets that are not associated with their original wallets. A famous example of this is Tornado Cash. For these applications, proofs are performed by users and verification happens on-chain. Therefore, it is critical to use a ZKP system with fast proofs, simple verification computations, and that does not leak any user information.
Since general-purpose chains are not optimized for expensive cryptographic computations, verification costs are often prohibitive for mainstream users, limiting the adoption of these applications. The intuitive solution of moving private transaction applications to Rollup to reduce gas fees can be challenging. In this case, private transaction proofs need to be included in the Rollup proof, i.e. proof recursion, which is not currently possible with general-purpose zk Rollup on Ethereum.
2. Building a new L1/L2 with a focus on privacy
To bring down costs for private transactions and applications, developers have had to build a new privacy-focused L1 (e.g. Manta Network and Penumbra) or a specialized Rollup (e.g. Aztec). Most privacy-focused chains are still unable to support general-purpose computing and focus on specialized uses. 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 a high-level language to generate the corresponding ZK circuits. The application's interactions are done off-chain, with only proofs published to the chain as private transactions. 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
After developers have chosen the right ZK development framework for their application and selected the underlying proof system, the next step is to optimize the performance of the application and look for ways to improve the user experience. This usually comes down to improving the performance and latency of the prover. As discussed earlier, for Rollups, faster proof times mean lower latency to submit proofs to L1 and therefore lower withdrawal latency. For user-generated proofs, i.e. privacy applications, faster proofs mean shorter transaction generation times and a better user experience.
As we discussed in previous posts, speeding up the proof process often requires software optimizations and specialized hardware. In the past few months, the competition for specialized 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.
Attestation as a Service
Until now, the standard model for performing ZK proof work has been to use powerful servers with multi-core CPUs and/or GPUs and leverage optimized open source libraries (e.g., Filecoin’s Bellperson) to improve proof performance. This model adds operational complexity to developers who need to maintain proof infrastructure. A better model that addresses this complexity and allows for greater specialization is the Proof-as-a-Service model. In this model, entities that need to generate proofs for a certain ZK circuit or a certain use case connect to providers who run proprietary software to perform proof computations. Some companies can specialize in generating proofs for specific use cases. For example, Axiom built a system for generating historical data for Halo 2 proofs on Ethereum. Other players can focus on specific ZKP backends, such as Plonk or Halo 2, and build proprietary optimizations to enable faster and more efficient proof computations. The =nil Foundation is taking this concept a step further by building a ZKP computation marketplace. In this Proof Market, proof buyers submit bids for ZKPs to be generated, which are matched and fulfilled by proof generators. Mina has a similar concept called Snarketplace, but it is limited to SNARK proofs required by the Mina network.
Hardware Acceleration
With the launch of several L1 and Rollups that require efficient generation of zk proofs, competition to generate these proofs and earn corresponding rewards will become increasingly fierce. If these chains and L2 succeed in attracting a large number of users, proof generation may develop into an arms race similar to the competition for Bitcoin mining. There are different methods of ZKP acceleration i.e. GPU vs FPGA vs ASIC. This article from Amber Group provides a good discussion of these different options and the challenges faced with each implementation option. However, in the long run, the company that produces the most efficient ASICs for proof generation will have a significant economic advantage on a zk-focused chain.
It is worth noting that there is an important distinction between the ZK proof competition and Bitcoin mining that is worth highlighting. In Bitcoin, the mining process is based on a simple calculation, the SHA256 hash. This calculation is fixed and cannot be easily changed, so the focus is on chip design innovation and access to state-of-the-art semiconductor nodes. In the ZKP space, there is a significant split between different proof protocols. Even when 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 can lead to multiple winners, each specializing in a different ZK backend.
There are multiple players entering the ZK-specific chip space. Each player focuses on improving one of the two main operations for proof generation: multi-scalar multiplications (MSMs) and number theoretic transforms (NTTs). The last player to come out of stealth was Cysic, which announced its $6 million seed round during ETH Denver. Cysic is focused on accelerating MSMs through the use of FPGAs. The flexibility of FPGAs could allow them to support different ZK systems. This approach is similar to that of Ulventanna, which announced a $15 million seed round in January. Other players in the ZK chip development space include Ingonyama, which released a library called Icicle that accelerates computations for MSM and NTT calculations on GPUs, as well as Accseal, Snarkify, and Supranational. In addition to this list, there are other stealth companies and research efforts among the well-known players in the Web 3 space. Examples of the latter include Jump Crypto’s CycloneMSM implementation for accelerating MSM computations using FPGAs, and Jane Street’s FPGA implementations for accelerating MSM and NTT.
As ZKP acceleration grows in importance, competitions that require fair evaluation of different implementations, such as the ZPrize, are becoming an important venue for advancing the field. The 2022 competition offers over $4 million in prize money.
With the launch of several L1 and Rollups required to efficiently generate ZK proofs, the competition to generate these proofs and earn corresponding rewards will become increasingly fierce. If these chains and L2 succeed in attracting a large number of users, proof generation may develop into an arms race similar to the competition for Bitcoin mining. There are different methods of ZKP acceleration i.e. GPU vs FPGA vs ASIC. This article from Amber Group provides a good discussion of these different options and the challenges faced with each implementation option. However, in the long run, the company that produces 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 the ZK proof competition and Bitcoin mining that is worth highlighting. In Bitcoin, the mining process is based on a simple calculation, the SHA256 hash. This calculation is fixed and cannot be easily changed, so the focus is on chip design innovation and access to state-of-the-art semiconductor nodes. In the ZKP space, there is a significant split between different proof protocols. Even when 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 can lead to multiple winners, each specializing in a different ZK backend.
There are multiple players entering the ZK-specific chip space. Each player focuses on improving one of the two main operations for proof generation: multi-scalar multiplications (MSMs) and number theoretic transforms (NTTs). The last player to come out of stealth was Cysic, which announced its $6 million seed round during ETH Denver. Cysic is focused on accelerating MSMs through the use of FPGAs. The flexibility of FPGAs could allow them to support different ZK systems. This approach is similar to that of Ulventanna, which announced a $15 million seed round in January. Other players in the ZK chip development space include Ingonyama, which released a library called Icicle that accelerates computations for MSM and NTT calculations on GPUs, as well as Accseal, Snarkify, and Supranational. In addition to this list, there are other stealth companies and research efforts among the well-known players in the Web 3 space. Examples of the latter include Jump Crypto’s CycloneMSM implementation for accelerating MSM computations using FPGAs, and Jane Street’s FPGA implementations for accelerating MSM and NTT.
As ZKP acceleration grows in importance, competitions that require fair evaluation of different implementations, such as the ZPrize, are becoming an important venue for advancing the field. The 2022 competition offers over $4 million in prize money.
Useful educational resources
In this section, we have compiled some educational resources to help developers learn about the ZKP space. This is by no means an exhaustive list as there is a lot of excellent content on this topic. Comprehensive lists of all ZK resources can be found here and here. This is to establish a friendly way for developers to learn about the efforts in this space.
For those interested in learning about the basics of ZKPs and how they work, one of the first resources to check out is ZK Hack’s ZK Whiteboard Sessions. In particular, Dan Boneh’s three introductory sessions are high-level for anyone with some mathematical understanding. The rest of the series covers specific topics in the field.
For developers who want to jump right into using ZK tools, this excellent beginner's guide is very useful. Since then, Poseidon Labs has created an Applied ZK workshop that walks developers through building ZK applications using Circom and Hardhat. Other workshops for other ZK languages and frameworks include this one with Noir and this one with Risc Zero.
in conclusion
As believers in the potential of ZKPs, Alliance strives to help more builders enter the space and provide them with funding and mentorship support. In Web 3, ZKPs have solved the scalability and privacy pain points that have hindered mainstream adoption. In Web 2, ZKPs can bring the ethos of trust minimization to a wide range of businesses including SaaS, insurance, and credit scoring. This article is designed to help builders integrate ZKPs into their products. This article guides builders through the different stages of planning a ZKP integration, covering implementation options as well as performance improvements after deployment.
Original link