Aztec Network Architecture: Private Smart Contracts, UTXO-Private State Trees, Noir zkSNARKs, and L1 Rollup Settlement

Overview: Solving the Public Blockchain Privacy Dilemma

Public blockchains operate under an unforgiving transparency model: every transaction, account balance, internal contract invocation, and liquidity position is broadcast permanently to global network observers. While radical transparency enables decentralized trust and permissionless state verification, it imposes catastrophic constraints on commercial adoption, institutional asset settlement, and personal financial autonomy. Enterprises cannot expose proprietary supply chain pricing or corporate treasury movements to on-chain competitors, while decentralized finance users routinely suffer from malicious maximal extractable value (MEV) exploitation, sandwich attacks, and persistent identity deanonymization.

Aztec Network was architected from foundational mathematical research to resolve this dilemma by constructing the first privacy-first, zero-knowledge layer 2 rollup on Ethereum capable of executing both private and public smart contracts. Developed by the cryptographic team that invented PLONK (Permutations over Lagrange-bases for Oecumenical Non-interactive arguments of Knowledge), UltraPLONK, and the Honk proving system, Aztec fundamentally rethinks smart contract execution.

Unlike privacy mixers or shielded transfer protocols that merely conceal token transfers, Aztec enables fully programmable privacy. Developers can write composable, stateful applications where contract state can be strictly private to an individual user, shared privately among designated participants, or held publicly in a transparent global state tree, seamlessly bridging confidential execution with public decentralized finance liquidity.

The Dual-State Model: Private UTXO Trees and Public State Trees

At the center of Aztec's architecture is a hybrid state paradigm that reconciles client-side confidential state transitions with sequencer-driven public contract execution.

Private State: Encrypted UTXOs, Note Hash Trees, and Nullifiers

Private data in Aztec is represented using an Unspent Transaction Output (UTXO) model, conceptually extending the privacy mechanisms of Zcash into arbitrary smart contract execution:

• Encrypted Notes: Private state variables (such as token balances, nonces, or voting weights) are stored as encrypted cryptographic structures termed "Notes". Each note contains arbitrary user-defined data and is bound to a specific owner public key. Notes are encrypted using the recipient's public encryption key and broadcast as ephemeral logs, allowing owners to decrypt their state while external observers see only random bytes.
• Append-Only Note Hash Tree: When a private note is created, its cryptographic commitment (the note hash) is inserted into a global, append-only Merkle tree known as the Note Hash Tree. The protocol never reveals what the note contains or who owns it; only the commitment hash is appended to the tree.
• The Nullifier Tree and Double-Spend Prevention: In a confidential system, a spent note cannot simply be deleted or modified in place, as doing so would leak which note was accessed. Instead, when a note is spent, the transaction generates and emits a deterministic cryptographic value called a "Nullifier". The nullifier is computed via a zero-knowledge circuit that combines the note's secret salt with the owner's private spending key. The nullifier is inserted into a dedicated Nullifier Tree. If a transaction attempts to emit a nullifier that already exists in the Nullifier Tree, the protocol rejects the transaction as a double-spend attempt.

Public State: The Shared Sparse Merkle Tree

Certain decentralized finance operations (such as automated market maker liquidity pools, collective governance votes, and shared lending markets) require transparent, globally synchronized state that cannot be locked inside an individual user's private UTXO. Aztec accommodates these operations through a traditional public state model:

• Public state is stored in a Sparse Merkle Tree (SMT) managed and updated sequentially by rollup sequencers.
• Public smart contract functions operate on this public tree identically to standard Ethereum Virtual Machine (EVM) executions, maintaining shared balances and protocol-level global configurations.

Client-Side Proving and the Private Execution Environment (PXE)

The defining operational divergence between Aztec and conventional rollups lies in where code execution occurs. In standard optimistic or zero-knowledge rollups, the centralized sequencer executes user transactions and calculates the resulting state root. In Aztec, private computations never touch a remote sequencer.

Local Private Execution via the PXE

Every user runs a client-side daemon known as the Private Execution Environment (PXE), embedded locally within their browser extension, mobile wallet, or local node:

• Private Note Decryption and Historical Sync: The PXE scans the historical note logs published on Ethereum, using the user's private viewing keys to decrypt and index all notes belonging to the user's account.
• Local Smart Contract Execution: When a user initiates a private contract interaction (such as transferring confidential tokens or submitting a private bid), the PXE downloads the contract bytecode and executes the private functions locally against the user's decrypted notes.
• Client-Side zk-SNARK Generation: Using Aztec's high-performance Honk proving system, the PXE compiles the execution trace into an arithmetic circuit and generates a zero-knowledge validity proof directly on the user's hardware. This proof certifies: "I know the private keys and note secrets satisfying this state transition, the consumed notes exist in the Note Hash Tree, and these emitted nullifiers are mathematically valid."

Crucially, the user's private inputs, secret keys, and note values never leave their local device. Only the cryptographic proof, the resulting note hashes, and the emitted nullifiers are transmitted across the network.

Noir: The Native Zero-Knowledge Smart Contract Language

Writing zero-knowledge circuits has historically required specialized cryptographic expertise, requiring developers to write complex R1CS constraints or low-level circuit assembly. Aztec developed Noir to democratize zero-knowledge application engineering.

High-Level Syntax with Circuit-Level Optimization

Noir is an open-source, Rust-inspired domain-specific programming language designed for writing readable, type-safe zero-knowledge smart contracts:

• Standard Programming Constructs: Developers write familiar loops, conditionals, structs, and modular libraries without manually calculating polynomial constraints or gate wiring.
• Native Aztec Abstractions: Noir provides built-in protocol primitives for interacting with Aztec's state trees, including context.create_note, context.push_nullifier, and context.call_public_function.
• ACIR Intermediate Representation: Noir compiles code into Abstract Circuit Intermediate Representation (ACIR). This intermediate format can be executed by multiple cryptographic backends, ensuring that applications written in Noir can target Aztec's Honk proving system as well as external zero-knowledge architectures.

The Aztec Virtual Machine (AVM) and Public-Private Function Composition

Complex decentralized applications require seamless transitions between confidential user actions and shared public liquidity. Aztec achieves this through function composability across execution boundaries.

Private-to-Public Hand-off Lifecycle

A classic decentralized finance interaction demonstrates this composability, such as a user swapping private tokens on a public decentralized exchange:

• Step 1 (Client-Side Private Phase): The user's PXE executes a private function that consumes private notes (e.g. 100 private USDC notes) and emits their nullifiers. The function generates an on-chain public call request payload enqueueing a public trade, while keeping the user's identity and remaining balance completely confidential.
• Step 2 (Sequencer-Side Public Phase): The transaction is submitted to the Aztec network mempool. The sequencer executes the public portion of the transaction inside the Aztec Virtual Machine (AVM). The AVM modifies the public liquidity pool, executes the trade on the shared automated market maker, and mints an encrypted note claim for the recipient.
• Step 3 (Client-Side Claim Settlement): The user's PXE detects the newly created note claim, proves ownership using a zero-knowledge proof, and claims the purchased tokens as fresh private notes in their local wallet.

Decentralized Sequencing and the Fernet Consensus Protocol

To eliminate centralized sequencer vulnerabilities, censorship risks, and single points of failure, Aztec has specified the Fernet (Fair Election of Rollup Nodes using Ephemeral Tickets) consensus mechanism.

Fair Election via Ephemeral Proofs

Fernet provides a decentralized, permissionless sequencer selection protocol tailored specifically for zero-knowledge rollups:

• Sequencer candidates submit ephemeral ticket commitments backed by protocol stake.
• A verifiable random function (VRF) selects winning sequencers for upcoming proposal slots in a deterministic, unbiasable manner.
• Sequencers bundle client-generated private proofs, execute pending public AVM calls, construct new rollup blocks, and broadcast them to peer validation nodes.

Recursive Prover Networks and Ethereum Layer 1 Rollup Settlement

Individual user transactions contain small zero-knowledge proofs. If every individual proof were verified directly on Ethereum Layer 1, gas costs would be economically unsustainable. Aztec relies on a multi-tier recursive proof aggregation architecture.

The Rollup Prover Pipeline

Aztec structures block verification through hierarchical circuits:

• Base Rollup Circuits: Specialized prover nodes assemble pairs of user transactions, executing recursive verification circuits that combine individual transaction proofs into intermediate rollup proofs.
• Merge and Root Rollup Circuits: Intermediate proofs are recursively folded together into a single master validity proof representing the entire block of hundreds or thousands of transactions.
• L1 Smart Contract Verification: The sequencer or prover submits the aggregated master Honk/PLONK proof to the AztecRollup smart contract on Ethereum mainnet. The L1 contract verifies the mathematical validity of the proof in a single cryptographic check, confirms that data availability blobs have been recorded via EIP-4844, updates the on-chain roots of the Note Hash Tree and Nullifier Tree, and finalizes the state transition.

Tokenomics, Fee Abstraction, and Privacy-Preserving Gas Payments

Paying gas fees in a privacy-preserving network introduces a critical cryptographic paradox: if an account must publicly spend tokens to pay a sequencer for block inclusion, the fee payment transaction leaks the identity of the account, destroying privacy.

Fee Abstraction and Fee Payers

Aztec resolves fee leakage through flexible fee abstraction mechanisms:

• Private Fee Settlement: A user can pay transaction fees using confidential notes. The private execution circuit creates a designated fee note payable to the sequencer's public address, burning the user's private funds without revealing their identity or account balance.
• Sponsored Transactions (Paymasters): Third-party relayers or decentralized applications can sponsor gas fees on behalf of users, facilitating seamless onboarding where users interact with applications without holding native gas assets.
• Gas Token Flexibility: Rather than forcing gas payments in a single mandatory native token, Aztec enables sequencers to accept multiple approved ERC-20 assets, settling conversion rates on-chain.

Critical Engineering Bottlenecks, Attack Vectors, and Trade-Offs

A rigorous architectural assessment reveals significant engineering trade-offs and operational challenges inherent in Aztec's zero-knowledge design.

Client-Side Proving Latency and Mobile Device Constraints

Generating zero-knowledge proofs on end-user hardware demands substantial computational resources. While the Honk proving system has reduced proving times by orders of magnitude compared to legacy SNARKs, generating proofs on resource-constrained mobile devices or low-spec laptop browsers still consumes noticeable CPU cycles and battery power. Complex smart contracts with large constraint counts can take several seconds to generate proofs, introducing user experience friction.

Note Synchronization Latency and Scanning Overhead

In transparent blockchains, a light client can instantly query account balances by checking a single state storage slot. In Aztec, because all private state is encrypted, a user's wallet must download and trial-decrypt historical note logs to discover which notes belong to them. If a user has been offline for months, wallet synchronization requires processing thousands of encrypted records, creating initial loading delays.

Information Leakage at Private-to-Public Boundaries

While Aztec's private circuits provide mathematical confidentiality, composability with public contracts creates potential side-channel leaks. If a user burns a specific, unusual amount of private tokens (e.g. exactly 14,291.82 USDC) and an identical public automated market maker trade executes immediately in the subsequent block, on-chain chain analysis heuristics can correlate the private user with the public swap. Developers must carefully implement standardized note denominations or batching mechanisms to preserve anonymity sets.

Regulatory Compliance and Selective Disclosure

Purely anonymous networks face intense regulatory headwinds and potential delisting from centralized gateways. Aztec addresses this challenge not through protocol backdoors, but through cryptographic viewing keys and selective disclosure proofs. Users can generate cryptographically verifiable viewing keys to disclose their transaction history to auditors, tax authorities, or compliance counterparties without compromising their privacy to the broader public.

Conclusion

Aztec Network represents a transformative architectural breakthrough for decentralized applications, demonstrating that stateful smart contracts and uncompromising zero-knowledge privacy are not mutually exclusive. By establishing a dual-state model separating encrypted UTXO note trees from shared public state, empowering users with local client-side proving via the PXE and Noir, and settling aggregated validity proofs to Ethereum Layer 1, Aztec lays the groundwork for the next era of confidential institutional finance and private Web3 computing.