1. Deep Roots: Built on Belief

Our conviction in ZKP (Zero-knowledge Proof) and FHE (Fully Homomorphic Encryption) as the bedrock of trust has never wavered. Since entering the space in 2022, we have been builders, not just participants.

Our track record reflects a dedication to cryptography compute acceleration:

Hardware Acceleration: Accelerated GPU solution for Halo2/Aleo/RiscZero, FPGA ZPrize & ASIC acceleration solutions exploration.

Node Operations: Operated Prover Nodes for top-tier ZK-Rollups like Taiko, ensuring early network stability.

Technical Excellence: Research on various ZKVM solutions, like RiscZero ZKVM/SP1 ZKVM/Aleo ZKVM...

Scale Contribution: Contributed massive compute resources to the Boundless prover network and supported the SP1 ecosystem as an early partner.

Continuous Expansion: We are currently actively testing and deploying infrastructure for frontier protocols like Zisk, Aztec, Brevis, Nockchain, and Psy.

Crucially, we have established a strategic partnership with Intchains (Nasdaq: ICG) to co-develop ZK ASIC products and research next-generation algorithms. This DNA of "Software-Hardware Co-design" is what distinguishes us from generic providers.

2. Industry Insight: ZK is the Backbone of the Crypto World

Standing here in 2026, we see a qualitative shift in the ZK landscape:

From Theory to Production: ZKVM technology has matured. Networks like Boundless now orchestrate hundreds of trillions of proved cycles. ZK-Rollup mainnets like Taiko and Scroll have demonstrated resilience over long operational periods.

The Ethereum Endgame: The Ethproofs initiative from Ethereum Foundation is pushing Layer 1 towards a ZK future. This is a milestone event—it means ZK is no longer an optional patch, but the necessary path to achieving decentralization, security, and performance simultaneously.

We believe Verifiable Computing will become the core infrastructure of the decentralized web, just as electricity is to modern industry.

However, there is a gap in the supply side: General cloud providers (like AWS) are too expensive for continuous cryptographic workloads, while hobbyist operators lack the stability required by institutional protocols. The industry demands an "Industrial Compute Grid"—massive, performant, stable, and cost-effective.

3. FidCore: Two Business Directions

To bridge this gap, we built FidCore—a trusted infrastructure platform for verifiable computing. Our services are structured into two complementary offerings:

Genesis Compute Provider

High performance and cost-effective computing capacity for ZK and FHE networks.

• Hybrid GPU & ASIC Acceleration: We orchestrate GPUs and custom ASICs to deliver optimal performance for diverse cryptographic workloads.

• Elastic Scale: Dynamically scale compute resources to match protocol demands, from testnet to mainnet and beyond.

We are not transient operators. We provide compute support from the Genesis Block, guaranteeing Liveness and Finality for the networks we serve.

Verifiable Computing Cloud Platform (Coming Soon)

A unified acceleration API for developers. Submit requests easily and get proofs fast.

• Zero-DevOps: No infrastructure management required. Focus on your application, not your servers.

• Smart Orchestration: Intelligent routing and load balancing across our compute fleet for optimal cost and performance.

4. Our Core Advantages

What sets FidCore apart from generic cloud providers:

High Performance GPU Capacity Thousands of GPU machines with RTX 5090/4090, delivering high performance and cost-effective computing power.

ZPrize Award-Winning Team ZK-optimized computing capabilities from a team recognized with ZPrize awards for cryptographic acceleration.

ASIC Customization Capability Custom ASIC computing power through strategic partnership with advanced ASIC vendors for specialized workloads.

Proven Operations Experience Professional and extensive experience in operating large-scale computing clusters at production level.

5. Building the Future of "Math Trust"

From ZKPool to FidCore, the name changes, but our pursuit of Math Trust via verifiable computing remains constant. We believe a Math Trust supported world will be more transparent, more individual-sovereign, and more efficient, and it will be a more civilized world, especially in the coming AI & Robots time.

We look forward to deepening our collaboration with global ZK protocols, Layer 2 networks, and AI privacy projects. Whether you need bootstrap compute support or customized hardware acceleration, FidCore is ready.

Let us build the physical foundation of the decentralized world together.

Connect with FidCore:

🌐 Website: fidcore.xyz

Background

Increasingly, projects such as RISC Zero are building zkVM, while others like Taiko and Optimism are utilizing zkVM to develop applications for Ethereum Layer 2.

The zkVM solution is gaining more recognition. Previously, there were concerns about its performance. However, teams have continually optimized it from both the ZKP protocol and hardware perspectives. It's getting faster and faster.

In particular, zkVM's continuation technology provides significant advantages, enabling parallel proving and compatibility with consumer-level devices.

Additionally, continuation technology aids in the use of proof recursion, which can help preserve privacy.

What’s zkVM’s continuation?

In the context of our zkVM, continuations are a mechanism for splitting a large program into several smaller segments that can be computed and proven independently.

Consider RISC Zero's zkVM as an example. A Rust program can be compiled into a RISC-V image. This image can be executed in the zkVM environment, generating a large execution session.

This session can be split into smaller segments, each of which can be proved in parallel.

If we delve deeper, we can see that the whole session may contain numerous cycles. We can define the limit of cycles for each segment. This approach allows us to handle large tasks by breaking them into smaller ones. These smaller tasks can run on lower-end devices, such as consumer-level GPUs.

Note that to obtain the final proof of the entire session, we need to join the proof of each segment through proof recursion.

For instance, if a program is divided into four segments, we must prove each of these four segments and then perform proof recursion three times.

The value of continuation technology

In the Zero-Knowledge Proof (ZKP) proving system, without continuation technology, the circuit could be quite large, necessitating the manual division of big circuits into smaller ones.

For zkVM, since we can divide large proving tasks into smaller ones, we can execute these tasks in parallel. This could potentially reduce the latency of proving, even when taking the cost of proof recursion into account.

In fact, a parallel computing system has several requirements:

1. The parallel tasks are relatively independent with minimal interaction between them.

2. There is a low amount of data transfer between the scheduler and parallel tasks.

3. The total latency can be reduced.

4. The overall computational load doesn't increase linearly with the number of parallel tasks.

Fortunately, the zkVM's continuation technology meets the above requirements.

In addition, the zkVM's continuation has these other advantages:

1. This can reduce the memory requirements for parallel tasks, enabling more individuals with consumer-level devices to participate, thereby promoting decentralization among provers.

2. It supports pausing and resuming a zkVM.

3. It can preserve privacy through proof recursion.

The applications of zkVM with continuation

zkVM can simplify the proving of all Rust programs without the need to write circuits. Its continuation technology can also reduce latency through parallel proving.

This is why teams developing zkEVM, including Taiko and Scroll, are also exploring zkVM solutions.

While zkML requires a large amount of computation with zkVM, continuation technology ensures that any large models such as LLM can use zkVM for proving. This is particularly useful as proving performance continues to improve.

Finally, its application in a privacy preservation scenario will be highly anticipated.

Best practice of zkVM solutions

One challenge for zkVM is identifying the optimal solution for parallel proving, particularly determining the number of segments.

If we split the tasks into segments (assuming n=2^i). Then we will need n segment proving tasks and (n-1) recursion proving tasks.

Thus, the total proving computation loading is:

$$L=nL_{seg}+(n-1)L_{rec}$$

In which:

L: Total computation loading

Lseg: The computation of one segment

Lrec: The computation loading of proof recursion

Thus, compared to not splitting, the overall computational load will increase.

On the other hand, if more than n devices can participate in parallel proving, which will complete both the segment's proof and recursive proof, then the latency will be:

$$T=T_{seg}+iT_{rec}$$

In which:

T: Total computation latency

Tseg: The computation latency of one segment

Trec: The computation latency of proof recursion

As evident, when i is large, the proving latency might be significantly reduced. However, it's important to balance this with the increased total computational load due to more segments.

The future of zkVM

We believe that zkVM will become increasingly advantageous as performance improves, given its significant benefits for general-purpose usage.

Reference:

1. Using Continuations to Prove Any EVM Transaction

2. 
   

3. Proof Composition: Unlocking Recursion and Modularity for ZK Developers

ZKPool aims to build a decentralized prover pool that supports various zero knowledge proof (ZKP) projects, including ZK-rollup projects like Taiko, Scroll, ZK-bridge projects like Orbiter Finance and other ZKP projects. In this document, we present a demo that demonstrates how to send ZKML proof tasks based on RiscZero's ZKVM to ZKPool and generate the proof correctly. Additionally, ZKPool has the capability to split proof tasks into smaller ones using RiscZero's continuation technology and distribute them to multiple provers to be processed in parallel. This allows for faster proof generation and enables lower-performance devices, including consumer devices like MacBooks, to participate.

This flow serves as an example for other ZKP requesters who need to access ZKPool's prover resources.

ZKPool Proving Flow

We use a ZKML demo to explain the proving flow.

The proving flow can be described by the following diagram:

The flow involves the following participants:

1. User: The person who initiates proof tasks through the user interface (UI).

2. ZKP requesters: Those who generate ZKML proof tasks and request proofs.

3. ZKPool, which consists of several components:

   - Aoraki node: Receives, splits, and aggregates proof tasks, and submits the proofs. It will be open-source and decentralized.

   - Aoraki ZKP provers: Receive proof tasks from the Aoraki node, and generate proofs.

   - Aoraki contract: Publishes proof tasks and receives proofs.

The overall proving flow is as follows:

1. The user triggers a proof task from the UI.

2. The ZKP requester receives the user's input, generates a ZKML proof task, and inquires about the price with ZKPool's Aoraki node.

3. The Aoraki node provides the price quote for the proof, along with its signature and address.

4. The ZKP requester submits the tasks and proof bond to the Aoraki contract.

5. The Aoraki contract publishes the proof tasks, indicating which prover will handle each task.

6. The Aoraki node retrieves the proof tasks from the contract.

7. If the proof tasks are related to ZKVM, the Aoraki node splits them and dispatches smaller tasks to connected ZKP provers.

8. The ZKP provers generate the proofs and send them back to the Aoraki nodes.

9. The Aoraki nodes verify the proofs and submit them to the contract (verification will be based on verifiers' consensus in the future).

10. The Aoraki contract calls the requester's contract for verification or publishes proof information that can be fetched by the ZKP requester's off-chain module for verification.

ZKML

When ZK technology is applied to generate proofs for machine learning computations, it is referred to as ZKML. For more information, you can refer to this article: link

Several teams, such as Modulus Labs and EZKL, are working in this area. Machine learning encompasses traditional algorithms (classification, regression), CNN image recognition, and LLM models, which have gained popularity in recent years.

Generating proofs for machine learning computations is challenging due to their complexity. In this ZKML demo, we use the decision tree classifier as an example, referring to the smartcore-ml repository.

The prover needs to generate a proof demonstrating the correct classifier result and the correct usage of the machine learning model.

We will provide a more detailed technical document soon, including the API, and the open-source code will be available on our Github.

ZKVM & Continuation

Several ZKVM (Zero-Knowledge Virtual Machine) solutions are currently under development, such as Risc Zero, Powdr, zkWasm, and more.

ZKVM compiles target code into a specific instruction set and uses ZKP to prove the execution trace. It differs from ZKEVM, which proves the execution of the Ethereum Virtual Machine (EVM).

RiscZero has developed a proving system that compiles any computation code written in Rust, C/C++, or other languages using the popular RISC-V instruction set. It runs the RISC-V image in its virtual machine, generates traces, and uses zero-knowledge proof technology to prove the execution of these traces.

Notably, RiscZero utilizes continuation technology to split proving sessions into segments. Each segment can be independently proved and verified. By using recursion technology to prove the transition between segments, a single succinct proof can be generated for the entire session.

Running a ZKP prover is a challenging task that typically requires high-performance devices. Here are some examples:

Currently, most ZKP provers use GPUs for acceleration. However, these algorithms require large DDR memory to store proving keys, witness data, point values, etc. This makes it difficult to run the proving system on low-end GPU devices or consumer devices, which hinders decentralization.

Additionally, some ZKP tasks are integral and cannot be easily split. For example, the Halo2 plonk backend needs to generate proofs for each circuit, and when the circuit is large, the proving time and memory requirements are high.

However, ZKVM-based solutions show potential for splitting proof tasks into smaller segments and running them on lower-performance devices, such as RiscZero, Powdr, and Delphinus Labs' zkWasm.

This feature has significant advantages for decentralization, as it allows for the splitting of large proof tasks into smaller ones. These smaller tasks can be executed in parallel, and each task has lower device requirements. This means that more low-end devices can participate, and the proving process can be completed in a shorter time.

ZKPool is committed to decentralizing ZKP provers, and the zkVM solution is an ideal approach to split, dispatch, and aggregate proof tasks, ultimately improving overall proving performance and decentralizing ZKP provers.

For more details about RiscZero's continuation technology, please refer to RiscZero News.

In this demo, we split the proof tasks into four segments, with each segment's tasks being executed on MacBook GPUs, NVIDIA 3080 GPUs, etc.

By having more than four provers participating in parallel, the proof can be generated within a few seconds.

This demonstrates the potential of using continuation technology to complete more complex ZKML tasks for machine learning models.

Conclusion

In summary:

1. We illustrate a flow for accessing ZKPool's proving resources.

2. A ZKML demo is used as an example of how to utilize ZKPool's proving resources.

3. RiscZero's continuation technology is employed to split proof tasks through ZKPool's Aoraki nodes, achieving faster proving finality and compatibility with consumer devices.

With great excitement, we, ZKPool, announce our partnership with Loopring Tech, a prominent application-specific zk-Rollup project. With its battle-tested zk-Rollup technology, Loopring builds scalable payment apps, non-custodial exchanges, and NFT marketplaces on Ethereum.

This collaboration marks a significant milestone in our journey towards building the best Zero Knowledge Proof (ZKP) infrastructure and making ZKP flow in the digital world.

Enhancing Performance and Reducing Proving Costs

At ZKPool, our mission is to connect ZKP applications and ZKP provers, providing high-performance and low-cost proving through shared proving resources. Our platform is highly reliable and redundant, ensuring partners can trust our infrastructure for their ZKP needs.

By joining forces, Loopring can further reduce the proving costs associated with their zk-Rollup project. Our shared proving resources will enable Loopring to optimize its operations and enhance the efficiency of its ZKP processes.

Building a Reliable Proving System

In the field of ZKP infrastructure, reliability is of utmost importance. By leveraging our expertise and resources, we aim to create a robust infrastructure that can support the increasing demand for ZKP applications.

Loopring's expertise in zk-Rollup technology and ZKPool's proven track record in providing high-performance and robust ZKP solutions create a strong foundation for developing a reliable proving system with high liveness. Together, we will work towards developing cutting-edge technologies and innovations that push the boundaries of what is possible in the ZKP space.

Conclusion

The partnership between ZKPool and Loopring is a testament to our vision of building the best ZKP infrastructure.

We are excited to embark on this journey together and look forward to having our solution benefit the whole ZKP ecosystem.

In a significant development for the world of blockchain and decentralized computation, ZKPool and MinerDAO have announced a partnership. ZKPool is a platform that aims to connect ZKP (Zero Knowledge Proof) projects and ZKP provers, facilitating the flow of Zero Knowledge Proof in the digital world. On the other hand, MinerDAO is a leading open-source community that focuses on building blockchain infrastructure for decentralized computation, decentralized storage, P2P CDN, and staking.

Studying ZKP Provers Opensource Status and Benchmarking Performance

As part of the collaboration, both ZKPool and MinerDAO will undertake a joint effort to study the opensource status of ZKP provers. This research will involve a comprehensive analysis of the existing ZKP provers and their performance. By benchmarking the performance of various ZKP provers, the partnership aims to identify the compatibility between ZKP projects and hardware resources.

Sharing Research Results with ZKP Accelerator Operators

The research conducted by ZKPool and MinerDAO will not be confined to their partnership alone. Both parties are committed to sharing all the research results with the operators of ZKP accelerators. This collaborative approach ensures that the knowledge gained from the research is disseminated widely, benefiting the broader community of ZKP accelerator operators. By sharing insights and findings, the aim is to foster innovation and collaboration in the field of ZKP proving.

Conclusion

The partnership between ZKPool and MinerDAO marks an important step forward in the advancement of Zero Knowledge Proof and blockchain infrastructure.

Ultimately, the partnership between ZKPool and MinerDAO seeks to build the best ZKP proving infrastructure by uniting ZKP accelerators from all over the world.

Get the latest from ZKPool:

• Website: https://zkpool.io/

• Discord: discord.gg/PUkc9BhfcT

• GitHub: https://github.com/aoraki-labs

• Twitter: https://twitter.com/zk_pool

Get the latest from MinerDAO:

• Website: https://minerdao.in/

• GitHub: https://github.com/minerdao

• Twitter: https://twitter.com/minerdao_in

Centralized Proving System vs Decentralized Proving System

Currently, many ZKP applications still use a centralized proving system. However, decentralizing the proving system has significant advantages for ZKP projects.

In particular, it is challenging for small ZKP projects to maintain their prover clusters. Additionally, we can achieve a higher utilization rate for the provers by sharing a prover pool among various ZKP projects via ZKPool.

Migration from a Centralized Proving System to a Decentralized Proving System

To migrate from a centralized proving system to a decentralized proving system for a ZKP project, the ZKPool proposes the following steps:

1. Design an interface to separate ZKP requesters and ZKP provers. The ZKP Requester-Prover-Separation (RPS) model is a framework that we use.

2. Design prove tokenomics, which involves the following components:

   (1) Define a proving task distribution strategy. Here are several strategies to consider:

   * POW (not recommended).

   * Multiple provers competing based on certain metrics.

   * Single prover assigned to a single task (recommended for overall cost savings).

   (2) Define a reward mechanism. Once the prover submits the correct proof, they should be rewarded.

   (3) Define a penalty mechanism. The prover will be penalized if it fails to generate the correct proof.

Designing such proving tokenomics is not an easy task. In this case, ZKPool provides a common contract to implement this type of proving tokenomics, while the ZKP project's contract only needs to provide its verification interface to the ZKPool contract.

Architecture

The architecture consists of the following modules:

• ZKP Requester: This module represents the ZKP project or ZKP applications from the partner who sends the ZKP proving tasks to ZKPool.

• ZKP Requester Contract: This module represents the contract of the ZKP Requester.

• ZKPool Service: This module represents ZKPool's service, which provides price quotations, resource scheduling, and other functionalities.

• ZKPool Contract: This module represents ZKPool's contract.

• Prover: This module represents the prover, which connects to the ZKPool service and generates the proof for the ZKP requester.

Design Principle

The ZKPool contract is located outside the ZKP requester contract and serves as an optional entry point for the partner. It does not interfere with the ZKP requester contract.

When submitting a proof using the ZKPool contract, no verification is performed (or optional verification), instead, the contract directly calls the functions of the ZKP requester contract. If the function execution is successful, it indicates that the proof has been successful.

Because it involves economic responsibility (e.g., ZKP requester must submit within 24 hours or face penalties), the ZKPool and ZKP requester need to agree on liability and assume certain responsibilities through liability. If the proof is submitted within a specific time frame, the liability will be returned. The requester can claim the liability if the proof is not submitted within the specified time frame.

On the ZKPool side, when a task is confirmed, it will schedule a prover to handle this task.

Flow

1. The ZKPool service stakes liability into the ZKPool contract.

2. The requester that needs to generate proof communicates with ZKPool Service off-chain to negotiate tasks and obtain the corresponding information like a reward, completion time, and a signature of the task fulfillment responsibility.

3. The requester publishes the task to the ZKPool contract. The contract returns an identifier for the task (e.g., task1) to easily retrieve information about the task. The ZKPool service immediately receives the proof task's reward in advance.

4. The ZKPool service schedules a prover to do such a proving task.

5. The prover submits the proof to the ZKPool service.

6. The ZKPool service submits the proof to the ZKPool contract within the specified time (less than LiabilityWindow).

7. The ZKPool contract performs a simple check and calls the corresponding function of the ZKP requester contract. If the function runs successfully, the task status is changed to "done".

8. The ZKPool contract transfers liability to the ZKPool service and provides it with a reward based on the negotiated price.

9. The ZKPool shares rewards with the prover.

10. The ZKP requester monitors the ZKPool contract and is aware when the proof is successfully verified.

Note: If the proof is not submitted after the LiabilityWindow, the requester can claim all the liability through the ZKPool contract.

Summary

This document introduces the interface and flow for ZKP projects to access ZKPool prover resources. It is particularly helpful for the centralized proving system.

Thanks to the ZKPool contract, modifications to ZKP projects are minimal.

In the future, we will provide more details on managing the ZKPool Service's prover using a contract to achieve the internal reward-penalty mechanism and transparent revenue allocation. We will also explain how to run the ZKPool service in a decentralized manner. With these design considerations, the entire proving system can operate purely decentralized.

Zero Knowledge Proof (ZKP) has many application scenarios, including rollup, bridge, and oracle. This leads to the development of projects like ZK-rollup, ZK-bridge, and ZK-oracle.

Hybrid and optimistic designs have been recently applied to ZKP technology. For example, Orbiter Finance proposes an optimistic ZK bridge protocol, while Taiko presents a progressive hybrid rollup solution.

Optimistic ZK operates under the presumption that all state transitions are correct, without requiring an immediate validity proof. However, it establishes a predetermined challenge window, during which any participant can dispute a fraudulent activity by submitting either a validity proof or a fraud proof.

This design reduces the overall proving cost for ZKP projects while still ensuring safety by incentivizing decentralized challengers to monitor the systems and challenge fraud behavior.

Optimistic ZK Bridge Protocol

Orbiter Finance is a prominent cross-rollup project. It proposes the "Orbiter Cross Rollup Protocol: Optimistic For The Obedient Majority And Severe Arbitration For Malicious Minority".

It defines a decentralized, secure, and cost-effective cross-rollup bridge design, supported by ZKP technology.

There are several important factors to consider for such a design.

Firstly, historic bridge projects have experienced multiple security issues, resulting in significant losses for users. Centralization also poses security concerns. Therefore, decentralization is crucial for bridges.

Secondly, there needs to be a mechanism to ensure accurate transactional processes between the source chain/rollup and the destination chain/rollup.

Furthermore, it is essential to find a cost-effective way to generate such proof. ZKP is a viable option with less gas fee, compared with on-chain Merkle proofs.

In particular, for a cross-rollup bridge, the cost is a primary consideration, and the entire design aims to minimize expenses. This means reducing on-chain transactions and minimizing gas usage for each on-chain transaction are of utmost importance.

In Orbiter's design, apart from the bridge payment scenario, there is another scenario that requires ZKP. In this scenario, a role called "submitter" aggregates the cross-rollup transaction information and sends it to L1 to ensure accurate rewards for decentralized dealer roles.

Orbiter's protocol assumes that the majority of actors are not faulty and handles cross-rollup events optimistically to ensure timely execution. If each cross-rollup transaction requires proof, the execution of the entire bridge transaction will be slow. Therefore, when there is no malicious behavior, there is no need to generate proof, saving the cost of proving. However, if malicious behavior is detected in the maker or submitter, the challenger can generate proof and the challenged submitter should also submit proof.

ZKPool’s Requestor-Prover Separation Model

When it comes to using ZKP technology, there are different modes available:

1. Full zk: In this mode, each transition requires a ZKP. This can be achieved through projects like ZK-bridge, such as Polyhedra, or ZK-rollup such as Scroll.

2. Optimistic zk: In this mode, ZKP is only required when a transition is challenged. An example of this mode is Taiko and Orbiter.

When defining an abstract model, it becomes apparent that both ZK-bridge and ZK-rollup can share some similarities. Specifically, this can be seen in the relationship between ZKP requestors and ZKP provers, as illustrated in the picture below. Here the ZKP requestors refer to the module that has requirements to generate a ZKP.

The scenarios are as follows:

1. In the ZK-rollup project:

   • In full zk mode, the sequencer works as the ZKP requestor.

   • In optimistic zk mode, the challenger works as the ZKP requestor.

2. In the ZK-bridge project:

   1. In full zk mode, the maker works as the ZKP requestor.

   2. In optimistic zk mode, the challenger works as the ZKP requestor.

As mentioned before, in optimistic zk, there may not always be a proving task. Therefore, if we combine the ZKP requestors and ZKP provers in the same module, the provers may be idle, and their computation power may not be fully utilized.

However, if we design a requestor-prover separation model and make the prover a shared pool, we can improve the prover's utilization rate. When there are no challenges for the optimistic scenario, the prover can take on proving tasks from other ZKP projects. That means ZKPool plays a significant role in zk-bridge projects, particularly in hybrid and optimistic scenarios.

The ZKP requester-prover separation model applies not only to rollup and bridge but also to oracle and all other ZKP projects.

Conclusion

Based on the information presented, we can draw the following conclusions:

1. ZKP (Zero-Knowledge Proof) technology is essential for ZKP projects, including rollup, bridge, oracle, and other related projects.

2. ZKPool allows us to consider the maker/submitter of ZK-bridge and the sequencers of ZK-rollup as the same role, known as the ZKP requestor.

3. By using ZKPool's ZKP requestor-prover separation model, the utilization rate of provers can be increased. This model also promotes decentralization in all ZKP projects.

In a ZKP (Zero Knowledge Proof) system, multiple types of proofs can be generated for the same proving task. The verifier can only verify a state transition when all the generated proofs are verified. The types of proofs include ZK-SNARK, ZK-STARK, SGX, and so on.

Vitalik proposed the multi-prover design in a speech.

Especially, SGX proof is a type of proof guaranteed by hardware. It eliminates the need for complex proving computations using special hardware to execute code and ensure honest computation securely.

To run SGX, the prover must have a dedicated machine with SGX support.

Why is multi-prover necessary for ZKP projects?

It's because ZK-EVM or ZK-VM won't be bug-free for a long time. The multi-prover system can avoid the error state being mistakenly verified by error-proof. Requiring and verifying all different proofs guarantees a much safer condition.

Here is a picture to illustrate the meaning of multi-prover.

How can ZKPool benefit the multi-prover scenario?

Prover operators then face a significant challenge. The ZKP project needs provers to generate multiple proofs simultaneously (to save gas fees) or at different times (like Taiko’s progressive hybrid rollup design) for the same block. It becomes difficult for individual or institutional operators to have ZK and SGX prover capability.

ZKPool can act as a super-prover by aggregating proofs from independent SGX and ZK provers and then sending the aggregated proofs to the verifier.

Therefore, each individual can use either ZK provers or SGX provers exclusively.

Furthermore, in a multi-prover system, by comparing different proofs off-chain before submitting, we can save on-chain costs. The decentralization of off-chain multi-prover benefits such honest comparison.

ZKPool aims to support different Zero-Knowledge Proof (ZKP) projects. It enables using different kinds of provers to generate proofs for various projects, thereby maximizing hardware utilization.

This is how ZKPool benefits the multi-prover based ZK-rollup.

We are firmly convinced that a multi-prover approach is crucial for the development and success of the ZK-rollup ecosystem and other ZK-related applications, such as ZK-bridge and ZK-oracles.

Reference

1. Taiko's progressive hybrid rollup design: https://github.com/taikoxyz/taiko-mono/pull/14705

2. Multi-prover introduction from Taiko: https://taiko.mirror.xyz/Kx1Mp4WJjd83K1KDEwp1pM7xi9QmpSahxJg3S_N7NE4

3. Vitalik's proposal on "Multi-Prover for Rollup Security,": https://www.youtube.com/watch?v=6hfVzCWT6YI

1. Open to ZKP Requesters

For the first time, ZKPool is opening the prover market to ZKP (Zero-Knowledge Proof) projects. The prover market points to Taiko at the following URLs:

HTTP: http://taiko-a5-prover-simple.zkpool.io

HTTPS: https://taiko-a5-prover.zkpool.io

This means that any sequencers of Taiko can access ZKPool's prover resources. Our goal is to open the prover resources to all ZKP projects, which we refer to as ZKP requesters. We plan to release a guide soon on how ZKP requesters can access ZKPool's prover resources permissionlessly.

2. Open to Provers

On the other side, provers can still join ZKPool permissionlessly. We guarantee that provers can seamlessly join and receive proof rewards in a few minutes. Provers do not need to pay for gas or a bond to join.

We are also collaborating with other ZKP projects to ensure that provers can achieve high utilization rates and receive more rewards.

3. ZKPool Ecosystem

The diagram below illustrates the ZKPool ecosystem:

In addition to ZKP requesters and ZKP provers, there is also a role for ZKP accelerators, who can provide accelerated binaries for certain ZKP projects. ZKP requesters and ZKP provers can also act as ZKP accelerators.

4. Taiko A5 Dashboard

Lastly, we have published the Taiko A5 Dashboard, where you can view detailed on-chain status updates of Taiko A5. Visit here and enjoy it.

5. Conclusion

For more details on ZKPool A1, click here.

ZKPool A1 is just the beginning, and we have a lot more work to do to reach our target of an open and decentralized system to make the zero-knowledge proof flow in the digital world.

Thank you to all ZKP requesters and ZKP provers for your participation.

Follow us:

Get the latest from ZKPool:

• Website: https://zkpool.io/

• Discord: discord.gg/PUkc9BhfcT

• GitHub: https://github.com/aoraki-labs

• Twitter: https://twitter.com/zk_pool

ZK-rollup or Layer 2 (L2) has some differences. It has provers, and each block must be proved and have a proof.

Here is a landscape of the ecosystem based on our understanding, using the Taiko project as an example. The Taiko project defines itself as a based rollup. The user experience is no different from L1, including using ETH as gas fee.

In L2, MEV follows a similar flow. MEV searchers can visit the mempool of L2 and extract value. However, for the MEV capturer of L2, it's not enough to just build a transaction bundle of L2. The transaction proposing an L2 block needs to be guaranteed to be included in an L1 block, or the value of L2 MEV cannot be captured. Therefore, an L2 MEV searcher should also be an L1 MEV searcher. (Reference 2)

Another difference is that each block needs to be proved. In Taiko's design, before a block is proposed, it should be bound with a prover. Here, ZKPool plays the role of a prover pool. ZKPool can provide the price of a block, and the sequencer can choose and then the contract in L1 can confirm the assigned prover. Finally, ZKPool captures the event and starts scheduling a prover to do the work.

To summarize, L2 has an infrastructure ecosystem consisting of MEV searchers, ZKPool, and provers. Within this framework, MEV captures the value and may become the sequencers of L2. Provers contribute proof and get rewards from sequencers. ZKPool collects prover resources and selects the most efficient ones with a favorable performance-price ratio.

References

1. Taiko MEV article

2. Flashbots introduction

TL;DR

1. A two-tier zero-knowledge proof (ZKP) proving tokenomics is proposed, with a shared ZKP prover pool and universal modular prover being critical components of the ZKP ecosystem.

2. ZKP provers represent the next generation of blockchain computation power

3. There is a fundamental difference between proof-of-work (PoW) miners and ZKP provers.

4. The design of the ZK-rollup proving tokenomics poses a challenge known as the “impossible trinity”: balancing performance, cost, and decentralization.

5. An analysis is presented here of several ZKP proving tokenomics, using Taiko’s solutions as an example.

1. Introduction

In recent years, Zero-Knowledge Proof (ZKP) technology has made significant progress. It has become increasingly popular in projects that require computation scaling or privacy preservation.

ZKP, specifically the SNARK (Succinct Non-interactive Argument of Knowledge) protocol, has gained widespread recognition in Ethereum’s scaling direction. Ethereum’s roadmap includes a target of “Snark Everything,” and Vitalik Buterin has claimed that “zK-SNARKs are going to be as important as blockchain in the next 10 years.”

However, generating a zero-knowledge proof is a much more complex computation than an existing computation.

For example, in Ethereum, the computation of a block with 10M Gas takes less than 1 second, as shown in the picture below.

However, generating a proof for a block in a 128-core CPU for a circuit in ZKEVM may take more than 1700 seconds. Please refer to the benchmark result from the PSE team.

Even with a GPU, a ZKEVM requires hundreds of seconds to generate a proof. This means that verifying EVM computations with ZKP costs more than 1000 times the original computation.

There will be huge requirements for ZKP computation power, as there will be many ZKP projects, including L2 projects like zkSync, Scroll, Taiko, Polygon, Linea, and Aztec, as well as L1 projects like Aleo, Mina, and Risc Zero. There will also be other privacy, identity, and gaming-related projects that require ZKP computation power.

Verifiable computation will be as important as computation itself in the future’s digital world, and ZKP acceleration will be the core of the next generation of blockchain’s computation power.

2. ZKP requires different tokenomics with POW

Proof of Work (PoW) is an algorithm used for distributed consensus. In PoW systems, participants (miners) must perform computationally intensive work to prove that they have invested a certain amount of computational resources. The goal of these algorithms is to ensure network security. Miners compete to find a hash value that meets specific conditions to gain block rewards and transaction fees.

However, ZKPs serve very different purposes and have distinct characteristics.

Here is the comparison between POW miners and ZKP provers.

Some ZKP projects, like Aleo, still use a POW-like mechanism, but they are not mainstream. Ethereum’s success with POS demonstrates that POW is not the only feasible solution for achieving blockchain decentralization. As a result, more projects might choose a non-POW proving system to decrease energy consumption and overall costs.

In the ZKP computation paradigm, it is necessary to design not only different provers but also different tokenomics.

3. The challenge of the impossible trinity of ZKP proving tokenomics

In this context, “proving tokenomics” refers to an incentive mechanism for a decentralized ZKP proving system. The three essential metrics for a ZKP proving network are cost, performance, and decentralization. A well-designed proving tokenomics should meet these three requirements.

First and foremost, cost is a critical factor in a ZKP project, particularly for ZK-rollups. Their mission is to scale Ethereum and reduce users’ transaction costs. The proving cost is a part of the overall cost of ZK-rollups and other ZKP projects. The cost includes both the cost of a single proof and the overall cost of the proving system.

To provide a better user experience for verifying layer two transactions and achieving finality, high-performance machines are required for ZK provers. GPUs, FPGAs, or ASICs using parallelized computation can help alleviate such bottlenecks. That’s why we use a GPU to prove zkEVM in 10 minutes instead of a CPU, which could take hours.

Another critical requirement for ZKP provers is decentralization. Decentralization means that many providers can join the proving work without requiring permission, and there is redundancy and geographical dispersion to make the entire system robust and resistant to censorship.

However, meeting all three aspects in the same design, high performance, low cost, and decentralization is an impossible trinity.

Firstly, there is a conflict between cost and performance. If high performance is desired, a high price for the provers, such as GPU, FPGA, or even a cluster of GPU/FPGA, is necessary.

As the usage of ZKP becomes more prevalent in the long term, there will be a market for millions of ZK provers. At that point, a low-cost ZK ASIC chip can meet both low-cost and high-performance requirements. However, since we are in the early stages of ZKP and have not yet reached such a vast market, the unit cost for a ZK ASIC chip is relatively high. Therefore, achieving both cost-effectiveness and performance remains a challenge at this stage.

Secondly, decentralization often necessitates the redundancy of provers, resulting in higher costs for the overall proving system.

For instance, if a ZK-rollup project creates an L2 block in 1 second, and generating proof for it using a high-performance GPU takes about 10 minutes, it would require about 600 provers to fulfill the demand.

n=T_prove​/T_block​

Here:

n : The number of provers

T_prove​ : Proof generation time for a block

T_block​ : Average block generation period

If we deploy 600 GPU provers for the ZK-rollup project, the computation capacity will be sufficient to meet its throughput. However, if some provers fail to finish their tasks on time due to network failures or occasional turn-offs, additional provers must generate a proof. Increasing the number of backup provers and decentralization of ZK provers increases the total cost of the proving system. This is also why POW is not popular in ZKP projects.

Thirdly, vigorously promoting the performance of provers may lead to the domination of the proving network by the fastest prover. This conflicts with the goal of decentralization.

Establishing a tokenomic system that ensures profitability and liveness for the prover in ZKP systems is a challenging task from an economic perspective. This is the challenge of proving tokenomics.

4. The evolution of ZKP proving economics

Taiko is a decentralized ZK-rollup project that is equivalent to Ethereum, and uses Type 1 zkEVM technology. At the beginning of the Taiko project, there was a focus on designing decentralized sequencers and provers. This is the first ZK-rollup project to promote decentralized sequencers and provers actively.

Taiko introduces its principle of tokenomic design in its documentation, which mentions similar metrics:

1. Efficient use of proving resources

2. Cheaper proofs over faster proofs

3. Prover redundancy/decentralization

Taiko project has explored various solutions to resolve the impossible trinity of proof ZKP proving tokenomics, and it is still evolving. Here is the history of Taiko Testnet and its proving tokenomics:

1. Dec 28th, 2022, Alpha-1: Prover is not open.

2. Mar 23rd, 2023, Alpha-2: Provers are permissionless and the fastest provers win, without an economic protocol.

3. Jun 7th, 2023, Alpha-3: Provers are permissionless with a dynamic-reward economic protocol.

4. Jun 2023: The batch auction-based tokenomics were proposed and discussed.

5. Jul 18th, 2023, Alpha-4: Provers are permissionless with staking-based economics.

6. The new proposal is on the way.

4.1 Dynamic-reward proving tokenomics (Taiko A3)

The tokenomics of A3 includes a dynamic reward mechanism designed to encourage provers to be low-cost and high-performance. It includes the following rules:

• The prover that submits the proof the fastest wins the block.

• The reward decreases as the prover submits proof faster.

Therefore, once a prover becomes the fastest, its best strategy is to submit proofs just slightly faster than their competitors and wait for a while to obtain a higher reward and keep a more significant profit.

Next, let’s take a look at some observed phenomena in Taiko A3.

The gas war

Currently, the number of active provers is gradually decreasing in A3, indicating a trend towards centralization.

The reason for the above trend is that some high-performance provers can submit their proof in as little as 24 seconds, which is very fast. According to the Ethereum design, if multiple provers submit their proof within the same window, the prover with the higher gas fee will be accepted. In the Sepolia Testnet, gas fees are not in real ETH and are very cheap.

As a result, there is a gas war among these high-performance provers. They submit proof with very high gas prices, sometimes reaching up to 2000 Gwei. Some provers with very high gas fees dominate the proving tasks.

Another strategy is to optimize performance by submitting proof in 12 seconds. However, it is difficult to submit all proofs within 12 seconds and doing so results in less reward due to the faster speed according to the A3 design.

The Computation Competition

Another phenomenon in A3 is the high number of failed submissions in competitions. This is because, for each block, only one winner is allowed to submit proof, and all other submissions, even if they generate a valid proof, will be rejected.

4.2 Staking-based proving tokenomics (Taiko A4)

In A4, Taiko employs a stake-based proving tokenomics, which provides several advantages:

1. Excessive computation is eliminated as only one prover is selected to generate a proof. The other provers do not need to work if they are not selected.

2. Encouraging low cost by giving higher weight and high-performance provers cannot guarantee a win.

3. The design is relatively simple compared to an auction-based solution.

Why do we need staking? The reason is that once a prover is selected, it needs to submit proof honestly and on time. A penalty is executed if the selected prover fails to complete this task.

One crucial phenomenon in A4 is that the ZKP prover has a high probability of being slashed, especially when there is network traffic jam. Here is an example.

Next, we can discuss possible solutions for this issue.

5. Further expected improvements in proving tokenomics

Based on our analysis, the expected ZKP proving tokenomics should meet the following requirements:

1. Each task should have one prover with no wasted computation.

2. Mechanisms should be put in place to prevent a monopoly scenario and promote decentralization.

3. The selected prover should provide a stake and receive a penalty if they fail to generate proof within a specified time window.

4. An incentive mechanism should encourage faster proof submission and lower costs.

5. Provers should be compensated for high gas fees.

6. Proof windows should be extended during traffic jams.

Let’s further expand the discussion.

This ZKP prover’s staking mechanism is similar to Ethereum’s, as it encourages the validator to be honest. However, there are differences between them.

As shown in the table, ZKP provers have higher costs and a higher risk of slashing compared with Ethereum validator. Meanwhile, regarding the reward, the ZKP prover’s only compensation comes from ZKP projects, but it has to cover gas fees, computation costs, and the cost of staking asset.

Here are some proposals to reduce the slash penalty, considering that ZKP provers need to pay the cost of gas fees and relatively high computation power:

1. If a prover submits proof within a relatively long window, no penalty should be imposed. This is because others can submit the proof according to the design, and the prover has already incurred gas fees and computation power as costs.

2. If the prover never submits the proof, a lower slash amount should be imposed. In such cases, it may be challenging to differentiate between network/technology issues or dishonesty issues. Thus, a penalty is reasonable, but it should be less severe, as in most cases, the failure might be caused by network traffic jams.

When there is a network traffic jam or very high gas fees, it is challenging for the prover to submit proof, even with reasonable gas fees. Here are some solutions that can be considered:

1. Extend the proof window when the base fee is high.

2. A more economically rational solution is to increase the reward when the base fee is high.

The staking mechanism brings some fund costs. It is true that there is no formal POS reward, as there is no formal POS mechanism, and we use POS as part of proving tokenomics. However, all the funds have interest costs. Thus, in a staking-based mechanism, the reward amount should be increased to cover staking costs, although it might be included in overall prover rewards.

In addition, the following improvements would be desirable:

1. To encourage faster provers, after the prover is selected, their rewards can be increased if they submit proof earlier than the target proof window.

2. Using batch proof for a group of blocks helps reduce the overall gas fee.

6. Two-tier ZKP proving tokenomics

Currently, many ZKP projects are using their own proving systems and tokenomics. However, this approach is not beneficial for sharing computation power across ZKP projects, which results in higher costs for the overall ZKP ecosystem.

As we analyzed in the previous section, ZKP projects require a complex mechanism to manage slash, reward, proof window, and other related aspects.

Furthermore, there is a high barrier for provers to join various ZKP projects and stake various assets.

To achieve a healthier and more cost-effective ZKP proving ecosystem, a two-tier proving tokenomics can be a good solution. Taiko proposed a solution after several rounds of iteration of proving tokenomics. We have further extended this solution to a two-tier framework.

Under this approach, each ZKP project operates as tier 1, defining its own tokenomics. However, the selection, scheduling, penalty, reward, and rating of provers are delegated to tier 2, which is a shared prover pool.

A prover pool, such as ZKPool, can aggregate the requirements of multiple ZKP projects and assign tasks to provers, enabling them to have a higher utilization rate and earn more profit. Additionally, it reduces the barrier to participation and minimizes the possible penalties.

To provide the best performance and low-cost provers to ZKP projects, ZKPool can implement a proof market with a standardized rate system to evaluate prover performance and create a competitive mechanism among provers. This system can return the best provers to ZKP projects, and ZKPool can provide extra platform incentives based on the rating system. This approach can significantly benefit ZKP projects and ZKP provers.

Here, we also propose a UMP (Universal Modular Prover) conception. A Universal Modular Prover can run on the same hardware platform while supporting the proving work of various ZKP projects.

The entire ZKPool will be directed towards decentralization and promoting an economically healthy ZKP ecosystem.

The design principle of ZKPool:

• Minimizing cost for ZKP projects while maximizing revenue for provers.

• Easy: Easy access to ZKP computation power for ZKP projects and easy join for ZKP provers.

• Transparency: Keep revenue distribution with transparency

The deployment of not only ZKP but also artificial intelligence and space computation will require significant computational power in web3. ZKPool can finally share all computation power across the entire web3, which we can call an acceleration layer for web3.

7. Conclusion

Exploring ZKP proving tokenomics has been a long journey. From our research, we have identified cost, performance, and decentralization as key metrics for ZKP proving tokenomics. Implementing a two-tier ZKP proving tokenomics system can benefit the entire system. Additionally, a shared common prover pool is critical in the ZKP ecosystem.

However, there are still challenges that must be addressed to complete this ecosystem fully. Important work includes building standard inputs for ZKP provers, reducing hardware requirements, and more. These are areas that require our attention and effort.

Reference

1. https://www.semanticscholar.org/paper/EVM-Perf%3A-High-Precision-EVM-Performance-Analysis-Busse-Eberhardt/f1e7e58eca4802356feca48e1a13a6fdec444288

2. https://grafana.zkevm-testnet.org/d/vofy8DAVz/circuit-benchmarks?orgId=1

ZKPool is dedicated to building the infrastructure for Ethereum zkEVM projects. One important zkEVM project is ZKSync Era.

ZKSync Era has published the source code on GitHub. Below is the diagram of how ZKSync Era's proving system works.

1. The "Metadata calculator" fetches the current blocked numbers and their storage logs, stores the metadata as witness inputs in the Postgres DB, and stores the witness input data as Merkel treepath data in Google Cloud Storage, which are the inputs to the witness generator.

2. The “Witness Generator” component generates prover jobs and stores artifacts needed for the next round of proof aggregation. It can skip blocks if there are too many for the system to handle. This step itself is pretty complex. On closer inspection, there are four steps: Basic Circuits, Leaf Aggregation, Node Aggregation, and Scheduler.

3. The "Circuit Synthesizer" takes the prover jobs from the Postgres DB, synthesizes them into assemblies, and then distributes them to the prover to generate proof. Assembly here is a concept in Bellman Plonk.

4. "Prover" takes the assembly as input via a TCP connection from Circuit Synthesizer, generates the zero-knowledge proof, and stores it in the Postgres DB.

5. "EthTxAggregator" is a standalone program that scans proofs in the Postgres DB and forwards them to the chain.

The path to decentralization

From the above flow at a high level, we can see:

1. The database plays a central role in the system: most components interact with the database.

2. The "Assembly" file sent by the "Circuit Synthesizer" to the prover is large. It contains all the witness data that the proof needs.

3. ZKSync has made many efforts to develop its proof generation system, from GPU groups, well-defined basic circuits, and proof aggregation mechanisms to circuit generation.

We appreciate and look forward to zkSync's vision for decentralization, especially the ZK-Prover part, as in this Twitter post:

Decentralization = Freedom

Our vision for decentralization is clear: The sequencer, ZK prover, zkPorter, community governance – and all other critical pieces of the zkSync Era network – will be decentralized once the core virtual machine and prover are solidified and stable.

zkSync Era + ZKPool

zkEVM projects need a lot of computational power to generate ZK proofs. ZKPool has a vision to accumulate ZK provers for Ethereum Layer2 zkRollup projects and mainly focuses on an optimized Prover task scheduling system and a Layer 2 fee/reward sharing mechanism. Eventually, the accumulated computing power and competition will reduce the proof cost. Meanwhile, the zkEVM projects achieve the decentralization of prover and high performance of proving.

ZKPool is looking forward to supporting the decentralization of zkSync Era and also the entire Ethereum Scaling world.

zkEVM is part of Ethereum zk-Rollup. It's an EVM-compatible virtual machine that supports generating Zero-Knowledge Proofs (ZKP).

Let's review what happened in the past two weeks:

• 3-22: Taiko Alpha-2 Testnet launched

• 3-24: zkSync Era Mainnet Alpha launched

• 3-27: Polygon zkEVM Mainnet Beta launched

• 3-28: Consensys zkEVM (Linea) Testnet launched

Additionally, on 2-27, Scroll Alpha Testnet was launched.

These projects share the goal of scaling Ethereum with general-purpose zk-Rollup based on zkEVM technology.

zk Prover Progress

Proof generation is required in zkEVM, and it can be time-consuming. Optimizing algorithms, GPU acceleration, or the design of FPGA/ASICs are needed to speed up the process. The machines that run zkEVM and generate proofs are called zk provers.

Below is a zkEVM diagram.

zk Provers play a crucial role in the success of zk-Rollup projects.

Let's review the latest zk prover status in these zk-Rollup projects.

Scroll

• Testnet Alpha is live.

• The ZK proof system is halo2/plonk based and is customized based on the PSE team’s solution of the Ethereum Foundation.

• The user can't join as a prover yet.

• It had planned to open source GPU-based prover before the Mainnet, and other users can join permissionlessly.

• Github: https://github.com/scroll-tech/scroll-zkevm/

Taiko

• Testnet Alpha 2 is live.

• The ZKP system is halo2/plonk based and is customized based on the PSE team’s solution of the Ethereum Foundation.

• It supports running a permissionless prover for an example circuit with the entire proof generation and verification flow. And it targets decentralized sequencers and provers.

• Github: https://github.com/taikoxyz/zkevm-circuits

zkSync Era

• Mainnet Alpha is live.

• The ZKP system is plonk based.

• Centralized sequencers and provers right now, while zkSync has the vision to have decentralized sequencers, provers, and so on.

• Its current internal prover uses GPU to accelerate, which was rewarded in ZPrize 2022.

• Github: https://github.com/matter-labs/era-heavy-ops-service

Polygon zkEVM

• Mainnet beta is live.

• The ZKP system is STARK & SNARK based.

• It runs with a trusted prover internally.

• Github: https://github.com/0xPolygonHermez/zkevm-prover

Consensys Linea

• Testnet is live

• The ZKP system uses an innovative lattice-based prover.

• Its prover is not open to users yet.

• Github: https://github.com/ConsenSys/gnark

Challenges of zk Prover

As we can see, zk provers provide computation power, but some key differences with POW miners bring challenges for the zk-Rollup Ecosystem.

One challenge is balancing the trade-off between hardware costs and proof generation speed. While faster hardware can generate proofs faster, it can also be costly. Thus, projects need to find a balance to ensure the economic feasibility of the solution.

The second challenge is to incentivize provers to generate proofs. In zk-Rollup, provers are required to generate proofs for batches of transactions, which requires significant costs. To incentivize provers, zk projects must design an economic mechanism that rewards them.

For zk provers, there are the following challenges:

1. Layer 2 projects may have different algorithms that are still being improved.

2. Currently, zk proving is still a long-tail market.

3. There is also a risk of losing money if they have to pay transaction fees.

ZKPool’s Mission

To address these challenges, a specialized miner pool for zk provers could be beneficial. This would:

1. Aggregate the computing power of zk provers to meet the needs of zk projects;

2. Reduce the risk of provers losing money;

3. Lowering the barrier to entry for provers.

Aoraki Labs, founded in 2022, has recently announced its project ZKPool, aiming to become the best ZKP infrastructure that connects applications and accelerators, promoting the development of the whole zk-Rollup and helping the Ethereum ecosystem.

To achieve this goal, ZKPool will provide a platform for developers to access a pool of optimized accelerators for proof generation. This will allow developers to focus on designing and deploying their applications without worrying about the cost and complexity of proof generation.

In addition to providing a pool of accelerators, ZKPool will also optimize the schedule of these accelerators, ensuring that they are used efficiently.

Finally, the ZKPool will pay the transaction fees and share rewards with the provers, reducing the financial risk of the provers.

Overall, ZKPool aims to become the go-to infrastructure for zk-Rollup, especially the aggregation of ZKP computation power.

Currently, we are working with zk-Rollup projects like Taiko (See the Dashboard of Taiko) and Scroll and some other ZKP projects like Aleo.

We look forward to cooperating with more partners and promoting the development of the ZKP Ecosystem.