TL;DR

• ZK technology is primarily applied for enhancing scalability, privacy, and credibility in various projects like Starkware, zkSync, Scroll, Mina, Risc0, Giza, EZKL.

• ZK technology requires significant computational power, leading to 10^4 to 10^6 computation overhead, posing challenges for infrastructure teams.

• The main approaches to generating ZK proofs are Proof Markets and Proof Networks. Proof Markets operate as open markets for trading ZK proofs, while Proof Networks have internal servers, offering a cloud service-like experience for generating proofs.

• The Proof Market approach allows for flexibility and cost-effectiveness, as it facilitates an open market for ZK proof trading without the need for high-end server management.

• The Proof Network approach provides a streamlined and developer-friendly experience, offering a hassle-free solution with less focus on market mechanisms, ideal for quick and reliable proof generation. Theoretically, it provides fast proof generation since order matching in proof market also takes time.

• Challenges include testing and debugging difficulties, new security concerns, potential vendor lock-in, higher costs for certain usage patterns and loss of token utility.

• Leading players are likely to be those with the most internal ZK proof demands, as they can leverage existing infrastructure and specialized teams, maximizing hardware utilization.

• Emerging applications include ZK Coprocessors, ZK Attestation, ZKML (Machine Learning), and ZK bridges, all contributing to an increased demand for ZK proof generation.

• Decentralized proof networks in the ZK space are driven by the blockchain industry's preference for security, censorship resistance, and privacy, although ZK's inherent security means decentralization is not a prerequisite for these benefits. Performance is the major concern for ZK.

Introduction

Growing ZK Demand

After years of research in ZK area, and vast improvement in performance, ZK is finally applied in real-world applications. Talented engineers apply ZK for

• Scalability

• Privacy

• Credible Compute

There are lots of interesting projects relying on ZK, like Starkware, zkSync, Scroll, Mina, Risc0, =nil;Foundation, EZKL, Giza, Polygon, Manta. These projects steadily and continuously generate ZK proof every day. The most popular ZK use case today is ZKRU to solve the Ethereum scalability problems. In the last month, ZK verification costs millions of dollars on Ethereum/Ethereum L2s.

This chart built by Near team illustrates the zkSN(T)ARK gas spending on Ethereum and L2s. It includes popular ZK projects like zkSync, Polygon, Aztec, Tornado Cash, Loopring, Worldcoin, Tailgun, Sismo, StarkNet, ImmutableX and dydx.

zkSnark takes 80% of the total costs on verification, compared to zkStark. Among all these projects, Worldcoin has the highest verification cost, followed by zkSync. Each worldcoin verification cost around $2. Each zkSync verification cost around $30.

Burden on Proof Infra

ZK can solve the Scalability problems but with some tradeoffs. It requires tons of computation power. ZK brings lots of computation overhead which Rollup teams need to take care of. @_weidai estimated 10^4 to 10^6 computation overhead with today’s ZK technology. Theoretically, we can achieve 10x computation overhead with dedicated circuits. With the abstraction of VMs, there would be 100x computation overhead.

The following graph illustrates the computation power growth based on Koomey's law. The efficiency of chips improves 10x every 10 years after the year 2000. If we treat computation power in the Year 2000 as the base, we reach 784 in the Year 2025. This also indicates that the ZK computation is still not comparable to Year 2000.

https://visualize.graphy.app/view/04f82b27-3654-47eb-83e8-3981f6e258be

Think about that for a while. We are trying to bring 10-100x transactions to ZKRU. With more transactions, we also will have 10^4 - 10^6 computation overhead. These numbers give the ZKRU infra team lots of pressure. Leading ZKRU teams are using really high-end machines with at least 200GB RAM. They have talented operations to take these infra complexities.

What does this mean to a small team that would launch a ZKRU or ZK layer3 with ZK stack? What if an indie developer would like to build a ZK Dapps? How do they buy these high-end servers and correctly operate them?

Nowadays, starting a ZKRU is not hard. You can use the ZK stack and deploy a new ZKRU following the instructions in the documentation. The hardest part is to get the high-end infra work. Taking care of a cluster of servers is much harder than taking care of our daily laptop.

Plus hardware acceleration is not out-of-box, Depending on the ZK proof system they are using, teams will need different configurations for their server setup.

Ensuring high availability is also a hard topic. What if tons of people start to mint ordinals in your ZKRU and you got 1000x throughput? Even an experienced team like Arbitrum has been down for several hours because of surging ordinal transactions.

Generating tons of ZK proof needs high-end servers. Setting up and taking care of clusters of high-end servers would be a heavy burden for small and medium teams. To better help teams adopt ZK smoothly and quickly, emerging projects try to help these teams take care of all computation infra complexity.

Proof Market

Proof markets and proof networks are two main approaches. The proof market is like an open marketplace. To generate a proof, users need to find the counterparty who is willing to sell the proofs at a certain price. The proof network is like traditional could service. Developers submit their circuits and input. The centralized load balance assigns internal servers in the proof network to generate proofs for users.

The proof market is one of the popular approaches for ZK proof infra. The proof market is an open market where buyers and sellers trade ZK Proof. The ZK proof market team does not need to take care of ZK proof hardware or own high-end servers. The ZK proof market teams focus on ZK proof trade and validation mechanisms to onboard third-party hardware providers.

The proof market is a more open approach. It welcomes third-party hardware providers. Buyers buy ZK proof at USD price as long as there is a seller for this kind of proof. When validating the proof, everyone in the market does not need to reach a consensus. Only the market operator takes the responsibility to perform the validation. In the proof market, zkDapp developers submit a ZK proof orders including price, generation time, timeout, and public input. Then third-party hardware providers will take the order and generate the proof.

The economic structure for the proof market is straightforward. Proof producers need some stake. If they produce wrong proof or do not provide proof before DDL, their stake will be slashed. With more stake, proof producers would be able to generate several proofs at the same time.

The main players in the proof market industry are =nil and marlin.

=nil Foundation

The proof market has sellers and buyers. Buyers are dApp developers. They pay sellers to generate proof. There are lots of factors affecting the proof price. The main factors would be circuit sizes, proof system, generation time, and input size.

Here is the workflow for =nil proof market :

1. A proof requester sends a request with a desired price c_r to the market.

2. Proof Market locks c_r tokens from the buyer's account.

3. Proof producers send proposals to the market with a price c_p <= c_r.

4. Proof Market matches the request with the proposal of the proof producer.

5. The proof producer generates a proof and sends it to the market.

6. Proof Market verifies proof and pays c_r - commission tokens to the producer.

7. The proof requester takes their proof and uses it.

The market design provides a trading-like experience. The proof generation price changes in real-time.

Here is a product screenshot for =nil proof market.

Currently, Proof Market supports a limited number of statements, with Mina statement proof being the most active one. Specifically, Proof Market accepts circuits based on their zkLLVM compiler and Placeholder proof system.

Gevulot

Gevulot tries to bring decentralization into the Proof marketplace. Gevulot operates as a permissionless and programmable layer 1 blockchain designed for the proof marketplace. The layer1 blockchain handles the proof request distribution, proof validation, and incentive distribution. The network of provers leverages lightweight unikernels for high performance. Gevulot uses a Verifiable Random Function (VRF) to distribute proof workloads among a small group of provers, ensuring liveness.

Users can deploy programs seamlessly, and fees are predictable, with users setting a maximum fee based on the number of cycles needed for program execution.

Provers are rewarded both by the Gevulot network and user fees, encouraging efficient and competitive proof generation. The fastest prover will get the most network rewards. User fees will be shared equally with all nodes finishing the proofs.

Gevulot supports a variety of programming languages, including C, C++, Go, Java, Node.js, Python, Rust, Ruby, PHP, and more, for program deployment because Gevulot’s underlying VM Nanos supports x86_64 Linux ELF binaries.

Gevulot is a general-purpose computation platform supporting different languages and proof systems. Gevulots relies on Nanos unikernel to make sure provers can easily run on different machines. All provers need to be compiled into a single unikernel image.

Proof Network

The proof network is a more developer experience-friendly approach. It operates like a Web2 cloud service provider. Developers send the payload through REST API and the proof network will return the proof to you. Developers don't need to care about fluctuating prices and the counterparty who will generate the proof.

Risc0

Risc Zero leveraging their zkVM launches Bonsai. With the power of zkVM, users can let Bonsai generate all kinds of statements. For example, based on Bonsai and Risc0 VM, Zeth generates the proof for Ethereum blocks.

Succinct

Recently Succinct also launched their new products. Instead of giving circuits to REST API, Succinct offers a more cloud-function approach.

Here is the user workflow:

1. Connect to GitHub account and deploy circuits

2. Call the API with circuit input via REST or smart contracts

3. Query the result through REST API or smart contracts

Compared to BONSAI, Succinct has the following advantages in developer experience

• Easier to manage the circuit codebase

• No need to send circuits every time

• One-click to deploy smart contracts for on-chain proof generation and validation

• Explore trending ZK proof

• Dashboard to view proof generation status

• Support rustx, gnark, circom, plonky2

Proof Network or Proof Market?

The proof market offers greater pricing flexibility for both buyers and sellers of proofs. It invites all hardware providers to participate, which helps to reduce costs for buyers. However, it's worth noting that the savings may vary between individuals and enterprises. Typically, centralized services such as a proof network may offer free services to individuals while charging enterprises a premium, but offering access to VIP customer support. For example, enterprises can reserve some computation power in advance on proof network if enterprises plan to launch new events or features. A decentralized marketplace might present more balanced and competitive pricing across the board.

In today’s market, products based on proof networks seem to provide a much smoother experience to developers. It takes care of all proof generation work and supports major proof systems without introducing any new complex concepts. It offers a consistent user experience. Theoretically, it provides fast proof generation since order matching in the proof market also takes time. If you are familiar with cloud computation, the proof network is more like a stateless cloud function.

We have =nil foundation and Gevulot working on the proof market. Succinct and Risc0 on the proof network. Hardware companies like Ulvetanna and Cystic also make great contributions to increased ZK proof performance on GPU and developed next-generation ZK dedicated chips.

The proof market is relatively easy to bootstrap. For ZK infra projects, proof market design can onboard more hardware providers. With its decentralization design, they can easily scale the network to meet the computation requirements in the future.

In the future, we envision a blend of a proof network and proof market design. The goal is to offer developers a seamless experience, while also integrating a proof market as the backend to facilitate the onboarding of additional computation resources. This is the direction Succinct plans to pursue in the near future. We also see similar transitions in other markets, like Infura. Infura has their own servers but it also plans to onboard permissioned parties infra provider.

Problems of these ZK Infra

Using cloud ZK Infra brings lots of advantages for ZK dApps developers:

• No server management is necessary

• Developers are only charged for the computation resources they use, reducing cost

• Serverless architectures are inherently scalable

• Quick deployments and updates are possible

• Code can run closer to the end user, decreasing latency

Besides these advantages, there are some common drawbacks when moving to a cloud zk infra:

• Testing and debugging become more challenging

• Cloud computing introduces new security concerns

• Cloud architectures are not built for consistent usage, storage-heavy processes

• Performance may be affected

• Vendor lock-in is a risk

• Expensive. We see lots of medium-sized companies moving away from the cloud to save costs.

Aside from these common issues, there are also specific problems in ZK and Web3 areas.

Privacy apps would find it hard to use these cloud ZK Infra since apps would also need to send private input to the cloud ZK Infra. This would destroy the data confidentiality. For privacy applications, generating proof locally or using FHE would be a better solution.

Also, it would be hard for cloud ZK infra to support all kinds of proving systems. Currently, both the proving market from =nil; foundation and Bonsei proof network only support their own ZK stacks. Succinct supports more proving systems. It is also hard for these cloud ZK infra to support interactive ZK-proof schemes.

Using cloud ZK infra weakens the token utility of ZK Dapps. Infra is one of the main utilities of dApps. Users pay fees with native tokens to computation providers in the dApps. Users can also stake tokens to participate in consensus and get some incentivizations. The dApps have the absolute power to design these rules. Relying on cloud zk infra, zk dApps need to pay real money, not tokens to their computation providers.

Who really needs cloud ZK infra?

We believe developers who want to decrease their go-to-market time and build lightweight, flexible applications that can be expanded or updated quickly may benefit greatly from these cloud ZK infra.

Cloud ZK infra will reduce costs for applications that see inconsistent usage, with peak periods alternating with times of little to no traffic. For such applications, purchasing a server or a block of servers that are constantly running and always available, even when unused, maybe a waste of resources. A cloud setup will respond instantly when needed and will not incur costs when at rest.

Who will be the leading players?

From learning Web2 cloud industry, we found that companies that have the greatest computation needs can have the leading cloud infra business. They can take advantage of scalability, cost, teams, and innovative products.

This would also work on shared ZK infra. We believe projects that have the most proof generation demands have the potential to own one of the most successful ZK cloud infra businesses.

For these projects generating lots of ZK proof internally, they have already got lots of infra, optimizers and specialized teams ready. By sharing provers across applications, they also maximize hardware utilization; provers can be repurposed whenever one application does not immediately need proof to be generated.

These big projects all somehow have their own proof system. Third-party proof infrastructure often struggles to optimize the various proof systems that different large projects employ. Providing fast and easy-to-use cloud provers, big projects can effectively expand their proving systems ecosystem.

For ZKRU, cloud ZK infra can boost the usage of its forks. Spin up a new layer2 or layer3 based on these ZKRU is not that hard, taking care of the ZK infra would be costly. Providing out-of-box and flexible cloud provers can help onboard more developers. Currently, most developers use OPRU SDKs to build new layer2 or layer3 since the corresponding infra is easy to manage.

If not building their own ZK infra, these giant ZK projects need to pay a lot to third-party computation providers. They also will be limited on development speed since they cannot always customize their infra to further increase performance and reduce proof cost.

Who has the most ZK proof demands?

Besides ZKRU and Layer1, we have seen more emerging ZK applications recently. These all have vast demands on proof generations.

ZK Coprocessors enables smart contract developers to get past blockchain state trustlessly. ZK coprocessors generate ZK proof for these past blockchain states. It may be the more secure and trustless alternative for the graph.

ZK Attestation helps users bring off-chain data or identity to the blockchain. After verifying the data off-chain, attesters will generate a ZK proof for it and put it on the blockchain.

ZKML makes on-chain inference possible. Computation providers do the ML off-chain, generate a ZK proof for it, and put the proof on the blockchain.

ZK bridge is a more secure version of cross-chain bridges. It generates storage proof or even consensus proof for the source chain and puts it on the destination chain. It may substitute current cross-chain bridges.

What about the decentralized proof network?

Decentralization is the most popular narrative in the blockchain industry. Decentralization brings lots of benefits:

• Security

• Censorship-resistant

• Privacy

ZK is different from other general computations. ZK has security in nature. Anyone can easily and quickly verify the proof to make sure provers is honest. Decentralization is not the prerequisite for security in ZK space.

ZK proofs focus on intricate, low-level details and are structured as circuits. While the content within these circuits is notably difficult to censor, censorship can still be effectively implemented by targeting the requestors.

Privacy would be a problem for proof networks because users send private input to the proof network. The ideal solution would be to generate proof locally to prevent any data leakage. This would pose challenges to local performance. Other solutions would be a new ZK-MPC protocol or generating proofs in TEE. A decentralized proof network can’t bring more privacy.

Besides the narrative, censorship resistance would be the major reason to build a decentralized proof network. ZK technology is still in its infancy, and so far, we haven't observed any censorship in this field. However, the main challenge hindering ZK development is performance. Introducing a decentralized proof network might lead to increased computational demands for generating proofs.

Conclusion

ZK applications are growing rapidly and are applied everywhere. We anticipate seeing ZK integrated into different tech stacks. We have already seen ZK layer1, ZK layer2, ZKML, ZKVM, ZK-Email. Developers are also building ZK Oracle, ZK data feed, and ZK database. We are on the road of ZK everything. The computation overhead brought by ZK forces developers to deploy their circuits on high-end servers. Thus we expected growing demand for cloud ZK proof infra to take developers outside these infra operation complexities. Our insights in this area are:

• Proof markets and proof networks are two main approaches to get ZK dApp developers outside of infra complexities.

• We anticipated a hybrid approach that combines both proof network and proof market mechanisms

• Not all ZK Dapp developers are suitable for cloud ZK infra. Medium-sized projects with consistent traffic can self-host servers to cut costs.

• The leaders of cloud ZK infra would be projects that have tons of ZK-proof generation demands, like leading ZKRU. They got economic incentives to do this business.

• Decentralization is the main narrative in the crypto space because decentralization brings characteristics like privacy, censorship resistance, and security. ZK Proof already has some of these characteristics. The current selling point for a decentralized proof marketplace is censorship resistance.

• The popularity of cloud ZK proof infra is closely tied to the quantity of ZK dApps currently in the market. While some projects initially highlight their cloud ZK proof infra as a key feature, many eventually shift their focus to different new narratives.