Introduction
Building a protocol that delivers programmable and composable privacy without a central operator is extremely complex. However, the team behind Aztec managed to pull this off. In the current L2 landscape, this makes Aztec one of the most interesting and long-awaited projects.
Our history with Aztec
ZkCloud has been working with Aztec and has been involved in proof generation through multiple network iterations:
In August 2024, Aztec launched Provernet 1.0, the industry’s very first live test of permissionless proof outsourcing. At ZkCloud, we have put our foot in the door by coming out on top.
From November 2024, as part of the Sequencer & Prover Testnet, a series of networks followed, which tested decentralized sequencer selection, block building, governance, and proof generation.
Finally, in early May 2025, Aztec’s Public Testnet was released. It went through multiple upgrades/phases, and with the most recent upgrade to v2.0.3, the protocol transitioned into a feature-complete and long-standing testnet that implemented all the mechanisms needed for Aztec to launch its mainnet as a fully decentralized network from day 1.
The way to Ignition mainnet has been paved…
Types of proofs and the proving flow on Aztec
On a high level, there are two kinds of proofs on Aztec:
Client-side proofs use the Client-IVC proving system and are generated on user devices such as mobile phones when users initiate transactions. Aztec’s Private Execution Environment (PXE) simulates the transaction logic (for private methods) locally and generates a zero-knowledge proof that the private logic executed correctly. (For more details on the transaction flow, please see the Aztec docs.)
Server-side proofs are generated by third-party provers such as ZkCloud. This consists of three main parts:
Transaction proving: If transactions include public functions, the Aztec Virtual Machine and Public Kernel circuits are run to prove their correct execution. Also, the client-side proofs, mentioned above, are verified and converted into a Honk proof by running the Tube circuit.
Rollup proving: The side effects from individual transactions are then used as the input to the rollup circuits, and aggregated through a tree-like structure, via the Block Root, as well as the Base (both private and public), Merge, and Root Rollup circuits, with the final root rollup proof being verified on L1.
Parity circuits: These circuits are used for cross-chain messaging only, and their output is fed into the Block Root circuit.
Together, these layers ensure that every private and public function and state transition on Aztec is cryptographically verified end-to-end, creating a trustless proving pipeline.
Proving the Public Testnet
Main actors in Aztec’s proving architecture
There are three main actors in Aztec’s proving architecture:
The prover node acts as the central coordinator: it monitors the network for new proving jobs, breaks them into tasks, and manages the overall proof assembly process.
The prover broker serves as the communication layer between the node and the worker network, distributing proving tasks to available agents and collecting their results.
The prover agents are the actual workers that do the heavy lifting and execute the circuits, running heavy computation to generate proofs and return them to the broker for aggregation.
What are we proving?
On Aztec, provers generate proofs for epochs instead of blocks. An epoch on the public testnet consists of 32 consecutive blocks, each with a slot time of 36 seconds. An epoch (epoch n) must be proven before the subsequent epoch (epoch n+1) is completed.
Considering the 36-second slot time and 32 blocks per epoch, this leaves provers with 19.2 minutes of proving time window. Depending on the network’s TPS, i.e., the number of transactions included in an epoch, this may require tens, hundreds, or even thousands of prover agents.
Memory requirements and multi-threading
As mentioned earlier, several circuits are run during the server-side proving process. In the past year, we have observed a very significant improvement in the amount of memory required for the different circuits.
All circuits require less than 16 GB RAM, except for the root rollup circuit, where we have observed a maximum usage of ~ 60 GB RAM.
Aztec also implemented efficient multi-threading, and significant improvements can be reached in proving speed up to 32 cores per prover agent.
ZkCloud’s infrastructure
At ZkCloud, we’ve been involved in proving all phases of the Public Testnet and submitted more than 7,600 epoch proofs so far.
Currently, the testnet is capped at ~0.2 TPS, which means that every epoch can include a maximum of ~230-240 transactions (~7-8 txs per block), which puts a limit on the proving hardware needed.
To ensure timely proving of testnet epoch, even the ones fully-loaded, at ZkCloud, we assigned a cluster of three servers with a total of 72 prover agents to Aztec.
Each server has the below specs and is hosting 24 prover agents:
384 CPUs (physical cores), and
768 GB RAM
In theory, this amounts to 32 vCPUs per agent, however, this is not configured explicitly: all agents share the total available CPUs and memory, and are free to use them as needed. Our prover node and prover broker are run separately, on the same machine.
With this cluster, we are able to prove fully-loaded epochs in ~6-7 minutes on average, leaving enough redundancy for the unexpected.
Mechanism for mainnet proving: simple, fair, and open to everyone
Earlier this year, Aztec’s mechanism for proving the upcoming mainnet has been redesigned for simplicity and robustness, allowing for fairer and equally permissionless participation.
The new model removes prover coordination and allows anyone to submit proofs directly to the rollup contract, without pre-registration, bonds, or selection/assignment by the sequencer. Multiple provers can submit valid proofs per epoch, with rewards split among those who deliver on time.
Rewards are governance-defined: sequencers vote to set both the percentage of block inflation allocated to provers and the per-transaction proving fee. This lets governance tune network costs while signaling demand for proving capacity.
The removal of bonds reduces the risk for monopolies, since proofing is open to all, relying on incentives to ensure at least one honest prover per epoch.
A key upgrade is partial epoch proving, allowing provers to finalize any contiguous set of blocks and progress the chain tip (e.g., k + 1 → k + 2), instead of waiting for a full epoch to be completed. This enables faster finality and immediate bridging. However, only the longest valid proof per epoch earns rewards.
Another really nice mechanism introduced is the consistency-based reward curve, which gives higher payouts to provers who participate reliably across epochs.
For more details, read the full proposal on the Aztec forum here: Update on Proving Coordination.
Closing thoughts
Aztec’s privacy-preserving L2 is unique and very much awaited in the Ethereum ecosystem. At ZkCloud, we are committed to supporting Aztec’s path to mainnet. We believe that decentralization must be foundational, not optional, and we’re proud to support Aztec and the broader ecosystem in making that real.
Additional resources:
How to run an Aztec Prover: https://docs.aztec.network/the_aztec_network/guides/run_nodes/how_to_run_prover
Advanced guide for provers: https://github.com/mztacat/Advanced-Guide-Prover-Set-up-on-Aztec
___
About ZkCloud:
ZkCloud is the first universal proving infrastructure for ZK. Generate ZK proofs for any proof system at a fraction of the cost. Fast, cheap, and scalable.
Learn more about ZkCloud:
Website | Docs | GitHub | Blog | X (Twitter) | Galxe Campaign | Telegram | Discord