Skip to main content

Aztec Network: Zero to One!


Shout-out to contributor Rajesh Kanna for this article! He is an independent developer in the Aztec ecosystem and has been building cryptographic primitives such as ECDH Verifier and KZG Commitment Verifier using Noir. He has also been contributing to Halo2 backend for Noir and chose Aztec because of their emphasis on bringing privacy to the blockchain.

Welcome to our exploration of Aztec Network, a unique entry in the Ethereum ecosystem's Layer 2 solutions. Unlike most solutions focused on scalability, a prevailing trend that is particularly pronounced in the case of most of the Zero-Knowledge Rollups (ZK-Rollups) and Optimistic Rollups, Aztec is different. Say hello to this rollup that focuses on another most important, yet often overlooked, facet: PRIVACY.

While the majority of L2 solutions predominantly concentrate on optimizing transaction throughput and reducing fees, a notable alternative arises in the form of a privacy-centric rollup. This seeks to address privacy concerns associated with on-chain transactions. In contrast to scalability-centric solutions, where the primary goal is to process a higher volume of transactions efficiently, privacy-oriented rollups prioritize the confidentiality and anonymity of user activities on the blockchain.

Aztec is the privacy-preserving zk-rollup which aims at privatizing the user interactions using some amazing components which are in tandem help achieve the objectives of Aztec Network. We will see those components in a sufficiently detailed manner to help devs develop/build on top of Aztec Network.

Why Aztec?

Public blockchains were primarily invented to transact (whether financial or non-financial) in permissionless, trustless, decentralised, and most importantly in transparent manner. But, the transparent nature of public blockchains seems to navigating back to the cruel world from which the Bitcoin, as invented by Satoshi Nakamoto, and other blockchains followed by it are primarily intended to free us.

Many blockchain analytics companies are there today to surveil the user interactions. In fact, it is absolutely possible to trace back the user’s real world identity because every user gets onboarded to crypto using a centralized exchange. These analytics companies make use of this and do massive analysis of the open blockchain data and provide services to governments, and other interested parties.

As most user interactions are happening on Ethereum ($2.5 Trillions in volume as of March 2024), it becomes the choke point for surveilling the mass amount of people. This is what Aztec tries to solve with its rollup technology.

Architectural deep dive

Aztec in and itself has several groundbreaking stuffs that are worth exploring to stamp the principle of anonymity (not just pseudonomity) in the blockchain world.

Lets just take a look at the big picture of Aztec Network before looking into them individually.

Hybrid State Model

Lets talk about functions in a nutshell. A function takes in some arguments and updates the state.

For eg., when a transfer function is invoked, it takes in inputs (from, to, value) and updates the state by incrementing recepient.balance and decrementing sender.balance.

When these state transition functions are public, there is no way to anonymously update the state. Aztec solves this by decoupling the private and public function calls, making a hybrid state model.

Private functions are called by users whereas public functions are called by sequencers.

What does this mean?

It means now we can separate the private and the public state. Users account details are usually the private state.

UTXO and Nullifiers

Lets think ourselves as to how we can proceed about building a privacy preserving zk-rollup. We will start from account. Ethereum uses account based model which is EOA.

Whenever a user transfers ETH, the user balance is decremented and the the recepient balance is incremented. Both of their balances are public. In order to achieve privacy, how can we do this increment/decrement operation in an anonymous manner?

Well, you just can’t. If the user and the recipient perform these operations locally, there is no way to verify it. If they are performed onchain, then it is open to everyone as Ethereum maintains the public state trie.

Enter Nullifiers!

Nullifier is a value used to nullify a certain other value. Not a good definition but it just explains its purpose. In technical terms, nullifier is a hash that invalidates a Note. That note cannot be used once the nullifier is added to the Nullifier Tree.

Lets say you have a Note which can be used to spend upto 1ETH. Now, you are transferring 1ETH to a Defi protocol. And you have a Note Commitment (Hash(Note)) in the Note commitment tree. You store the note commitment in the tree and not the plain note for maintaining privacy. To invalidate the note that you have spent in the Defi protocol, you add Nullifier in the Nullifier tree which is:

Private Execution Environment (PXE)

Now we have ascertained a way to update the state in an anonymous manner. Next question is where does that happen? Like, you cannot request a node or a sequencer to update the private state by giving out your account data. That is just where we were before. You can’t reap the benefits of the UTXO and Nullifiers duo in that case. We need a local user environment to do the private state transition.

This is why we have Private Execution Environment(PXE). PXE is where the private functions, and private state changes are executed. PXE can be either on server side or on client side. Aztec Network wallets will have an instance of PXE to perform client side operations on behalf. You can find the functionalities of PXE here. Now, we will deconstruct the PXE to understand it more.

  • ACIR Simulator: This is responsible for simulating the transaction (private part of it) and generating partial witness (private inputs) and public inputs for private kernel circuits. It spins up an ACVM (Abstract Circuit Virtual Machine) for each function.
  • Private Kernel Circuit: This is responsible for generating the proof of execution of each private function recursively i.e., it verifies the previous function execution and generates proof for current function execution. This will end up with a single proof of whole private execution. This final proof is sent to the sequencer as you can see in the diagram above.

Here is the flow of how private kernel works:

ECDSA signature, in the top of the flow, is when the user signs the transaction. First step of private kernel circuit is to verify that signature.

  • Database: When user initiates a transaction, the user’s (private) state is loaded from user’s local PXE.
  • Oracle: PXE also provides oracle functions for quering public data from a sequencer. Some oracle functions can be found here.
  • Synchroniser: Once the block (associated with the user transaction) is finalzied on L1, then the synchroniser updates the user’s PXE Database based on that new block.
  • KeyStore: This is responsible for managing the user private keys.


As we all have seen, once the user locally runs and generates the proof of execution for private functions and are verified by kernel private circuit, a single proof of whole execution, public function requests, and public inputs (New note commitments, nullifiers) are forwaded to sequencer for creating a transaction.

Then public functions are executed as requested by the PXE and the proofs of their execution are generated and verified by kernel public circuit recursively as similar to kernel private circuit. Optionally, sequencer can delegate proof generation to prover network.

Generated proofs for each transaction are merged by Rollup circuits. It takes each transaction proof and generates a single proof in a ‘binary tree of proofs’ topology while performing state updates, commitments and nullifier insertions, and membership checks for every transaction. You can read more about this here.

Finally, the single proof (block proof) got submitted to L1 and is verified by the verifier contract in L1. In short, sequencers are just nodes with the capacity to create block proofs along with the block.

Here is the flow chart of a transaction lifecycle:

Interesting ideas to build on Aztec!

So now that we looked at the technical deep dive of Aztec and how Aztec makes it possible to be privacy-centric, let’s take a look at what can be built on Aztec.

It’s worth to note that while Aztec is currently still in testnet, there are no much projects that are built on top of it. Only Aztec infra projects (like Noir Halo2 backend that can be found on OnlyDust) and Noir projects are more visible. Noir Halo 2 backend aims to enhance the Noir by adding the support to generate Halo2 proofs.

Nevertheless, even though Aztec is still in testnet, it can be leveraged to build deep anonymous (a.k.a complete privacy) protocols onchain. Some ideas are listed below:

Private DEX: A decentralized exchange which lets users exchange their assets in anonymous manner. Some existing projects: Shieldswap, AztecGravix.

Private Oracle: An oracle service which lets users anonymously query onchain/offchain data onchain. Look at Wonderland’s private oracle for example.

Wallet Infrastructure: Build a wallet that lets users make private function calls. Look at Aztec Snap for example. Build transaction simulation that will let an user identify the flow of transaction execution and the estimated gas.

Web2↔Web3 Bridge: Bring web2 accounts and credentials in anonymous manner enabling web2 identity onchain. Example: Wagmi lab’s proof of secret.

Verifiable location: Anonymously verify that a user is located within the authorized location to provide access(to some service) using Wagmi lab’s proof of proximity.

Anonymous reputation system: Build a reputation platform that maintains a set of parameters that determine the reputation score and calculate users’ score using Wagmi lab’s proof of intersection.

Anonymous tracking: Privately track the individual users’ action and verify onchain. Example: Green Zktricity.

Anonymous voting: Build zk voting applications that will let users anonymously create and vote on proposals/polls. Example: Melo Cafe.

And, there are many more ideas and toolings available that you can look at here.

To conclude

Aztec sets a new standard for privacy within the blockchain space. In a world headed towards pure surveillance, Aztec has joined among the very few to fight against it by promoting privacy. And arguably, the first to bring programmable privacy onchain. Its commitment to anonymity and privacy, coupled with its innovative use of zk-rollup technology, presents a solid foundation for developers to create applications that truly preserve user privacy.

Most of the ideas were inspired from ZCash protocol and Aztec is pretty happy to accept it. In the end, it’s not only about who invents useful things. It’s about who takes that and brings to the masses. Aztec is taking a hard path and looking to succeed in its mission. Huge applauds and respect to those who are willing to build on top of Aztec.

Hail Aztec Devs!!