Empowering Web3 Developers: A Comprehensive Guide to Leveraging Zero-Knowledge Proofs (ZKPs)

Zero-knowledge proofs (ZKPs) are poised to be a game-changing technology in the coming decade, with applications both within and outside the realm of Web3. Within Web3, ZKPs are already addressing critical challenges related to scalability and privacy, two major pain points for blockchain technology. On the scalability front, numerous ZK rollups, often referred to as validity rollups, are emerging to enhance Ethereum's scalability by 10-100x while simultaneously improving user experience by reducing transaction costs. In terms of privacy, ZKPs are evolving beyond private transactions and transaction mixing, branching into more intricate and valuable domains such as private on-chain trading, identity verification, and credential authentication.

Despite the wealth of information available on ZKPs, including our own vision of their future and the startups needed to realize this vision, there remains a gap in educating builders on how to leverage ZKPs and where to begin. This article aims to bridge that gap by aggregating essential resources to guide developers in understanding how ZKPs function in practice and how to incorporate them into their applications.

At Alliance, we are particularly enthusiastic about the new possibilities unlocked by ZKPs. We encourage builders in this space to reach out to discuss their ideas and apply to our Alliance program.

Understanding ZKPs in Practice The conventional definition of ZKPs involves a process where one party, known as the prover, convinces another party, the verifier, that they possess specific knowledge without disclosing that knowledge. However, in the context of Web3, ZKPs are often employed differently. Most applications don't use ZKPs to prove ownership of proprietary data. Instead, they utilize ZKPs to enhance trust through verifiability. We anticipate that ZKPs will become the standard trust model between entities in the future. The primary reason for this is the separation of the two main components of ZKPs: proof generation and proof verification. This separation facilitates a unique interaction between a trust-seeking entity and its users.

Running a ZKP involves two main components: proof generation and proof verification. Proof generation entails performing complex computations to create a proof of executing a process. This proof eliminates the need for trust in the prover, allowing anyone to run a straightforward process on the proof to validate the integrity of the process carried out by the prover. This concept enables a business to execute a process, often a complex one, while enabling customers to trust the execution of that process without having to duplicate it. For example, imagine if OpenAI could provide a small amount of data as proof that it ran the specific model you requested, ensuring transparency and trust. This trust minimization is the promise of ZKPs. In Web2, ZKPs can guarantee fair creditworthiness evaluations or equitable insurance claims processing by ensuring the use of the same algorithm for all customers. While ZK technology is not yet cost-effective, we see companies like Modulus Labs pioneering the use of ZKPs to prove AI inference.

Technical Requirements for Efficient ZKPs Efficient ZKP systems need to achieve several goals simultaneously:

1. Reduce the computational complexity and latency of the proving system, enabling efficient proof generation and minimal communication delay with verifiers.
2. Achieve a small proof size.
3. Achieve efficient verification with minimal verification costs.

In addition to these primary goals, secondary goals may be necessary depending on the use case, such as:

• Privacy of data in privacy-focused applications, ensuring that the proving system can handle private inputs without leaking them in the generated proof.
• Avoiding trusted setups whenever possible to simplify security assumptions.
• Achieving proof recursion to further reduce verification costs, allowing a single verification to validate multiple proofs and amortize the cost across different proofs.

Simultaneously achieving all these goals can be challenging. Depending on the use case, ZKP systems prioritize certain goals. For instance, SNARK proving systems can produce succinct proofs but increase proving complexity. In contrast, STARKs have efficient provers but can result in proofs 100x larger than SNARKs. ZK researchers are continually pushing the boundaries of the technology, seeking to improve all three metrics through the development of new proving mechanisms.

Comparing Different Proving Systems A crucial consideration for developers building ZKP-related products is selecting the underlying proving system. Several ZKP prover implementations exist, with more in the research and development phase. The choice of ZKP backend depends not only on technical aspects but also on the target product. For example, when selecting a proving system for rollups, the key features of the rollup, such as withdrawal time, transaction costs, and decentralization, are largely determined by the chosen ZKP proving architecture.

In rollups, the proving process typically occurs on the business side, meaning the rollup operator is responsible for generating proofs. Existing zk rollups (zkRUs), such as Starknet and zksync, currently use centralized provers. This allows them to delegate proof generation to specialized provers, often referred to as "proving-as-a-service" companies, to improve prover performance. Specialization and optimized software/hardware can reduce proving times to a few minutes for Ethereum-compatible zkEVMs. For example, Polygon zkEVM currently has a proving time of around 2 minutes. A few minutes of proving time, or withdrawal delay, is generally acceptable for a rollup.

However, some use cases require proof generation to occur on the user side, such as generating private transactions like those in Tornado Cash. To ensure a reasonable user experience, proving time cannot exceed a few seconds. Additionally, when users perform these computations in web browsers or wallets on resource-constrained devices, selecting a proving system with a fast prover is essential. For instance, Zcash switched to Groth16 as its proving system in the Sapling upgrade in 2018, resulting in a significant speed improvement for shielded transactions.

Choosing the right proving system involves assessing trade-offs and aligning with the specific use case. SNARKs, for instance, are generally programmable for any computation, but proving efficiency depends on the type of computations. This is not the case for some STARK systems, which are less adaptable to different computation types.

Utilizing ZKPs for Your Product Leveraging ZKPs for your product requires careful planning and selection of the appropriate approach based on your product's needs, ecosystem alignment, and performance requirements. Developers have several tools and frameworks to choose from, depending on their specific use case:

1. Performance-Focused zk Applications:Developers can use ZKPs to achieve higher throughput (transactions per second) or lower fees by conducting most of the application's computing off-chain and only posting the proof on-chain. There are multiple frameworks available for this purpose, each providing tools to compile high-level application code into a suitable zk circuit, generate the zk proof, implement the zk prover, and generate the verifier code for the target ecosystem.EVM-focused zk Frameworks:These frameworks align with Ethereum by building on top of it as rollups. Transactions and applications are executed on the rollup's zk virtual machine (zkVM), and the proof is generated by a dedicated prover and posted to the Layer 1 (L1) chain for verification. There are two subsets within this category: zkVMs compatible with the Ethereum Virtual Machine (EVM) and those that are not natively EVM-compatible.Non-EVM zk Frameworks:These frameworks do not target the EVM architecture but may be used to build application-specific zk rollups on Ethereum through specialized SDKs.
2. Privacy-Focused zk Applications:Developing privacy-focused applications with ZKPs can be more challenging for developers, as there has been less focus on privacy solutions compared to scalability-focused ones. Privacy applications often follow one of two implementation options:Building on top of a general-purpose Layer 1 (L1) chain.Building a new L1/L2 focused on privacy.

ZK Acceleration After selecting the appropriate ZK development framework and proving system for your application, the next step is optimizing performance to enhance the user experience. This optimization typically involves improving the performance and latency of the prover. In the case of rollups, reducing prover time translates to shorter submission delays for proofs to the L1 chain, resulting in a shorter withdrawal delay. For user-generated proofs, particularly in privacy applications, faster proof generation means shorter transaction generation times and a better user experience.

Accelerating the proving process often requires a combination of software optimizations and dedicated hardware. Recent months have seen increased competition in the field of dedicated hardware for ZK acceleration, with multiple companies entering the race. Some approaches include proof-as-a-service models, where entities that need to generate proofs connect to providers running proprietary software for proving computations. Others are focusing on hardware acceleration, with various players aiming to produce efficient ASICs for proof generation.

Notably, the ZKP space differs from Bitcoin mining in a fundamental way. In Bitcoin mining, the competition revolves around a fixed computation (SHA256 hashing), focusing on chip design innovation and access to advanced semiconductor nodes. In contrast, the ZKP space exhibits significant fragmentation among different proving protocols, leading to differences in ASIC performance even within the same proving backend.

Several players are entering the field of ZK-specific chips, each focusing on improving one of the two major operations of proof generation: Multi-scalar multiplications (MSMs) and Number Theoretic Transform (NTT). Competition in this space is expected to intensify, and the companies producing the most efficient ASICs for proof generation will gain a significant economic advantage in ZK-focused chains.

Useful Educational Resources For developers looking to delve into the world of ZKPs, there are numerous educational resources available. Here are some valuable starting points:

• zk Whiteboard Sessions from zk Hack, featuring introductory sessions by Dan Boneh.
• A beginner's guide to zk tools for developers.
• Applied zk workshops, such as those using Circom and Hardhat, Noir, Risc Zero, and others, which provide hands-on experience in building zk applications.

In Conclusion As proponents of the potential of ZKPs, Alliance is committed to helping more builders enter this space and supporting them with funding and mentorship. In Web3, ZKPs are already addressing scalability and privacy challenges, paving the way for mainstream adoption. In Web2, ZKPs have the potential to bring trust minimization to a wide range of businesses, including SaaS, insurance, and credit scoring. This article serves as a guide for builders looking to integrate ZKPs into their products, covering various phases of ZKP integration, implementation options, and post-deployment performance enhancements.