Programmable Privacy: How Aztec & Garbled Circuits Work

The Evolution of Privacy Architecture: From Mixers to Programmable Protocols

Legacy mixers like Tornado Cash or Sinbad are becoming obsolete under pressure from regulators, OFAC sanctions, and heuristic clustered transaction graph analysis. Native anonymity at the liquidity pool level is blocked at the smart contract layer via high-risk address lists (Chainalysis, Elliptic) integrated into the RPC nodes of top-tier providers (Infura, Alchemy).

The industry is shifting toward the concept of Programmable Privacy. Instead of hiding the transaction fact itself by blurring deposits within a pool, newer protocol-level solutions allow developers to execute arbitrary business logic and smart contracts on top of encrypted data. Leading this transition are zk-rollup-based networks supporting Programmable Privacy, such as Aztec (Noir), and specialized confidential L1 networks like COTI 2.0, leveraging next-generation hardware and cryptographic primitives.

Garbled Circuits in Blockchain

At the core of platforms like COTI 2.0 lies the classical cryptographic primitive Yao's Garbled Circuits, adapted for a decentralized blockchain environment. Unlike zk-SNARKs, which prove statement validity without revealing underlying data, Garbled Circuits allow two or more untrusting parties to compute an arbitrary boolean function over confidential inputs such that neither party learns anything except the final output.

Garbled Circuit Mechanics

• 1. Boolean Logic Representation: Any computation (token transfer, balance check, credit scoring) is compiled into a directed acyclic graph composed of logic gates (AND, XOR, NOT).
• 2. Garbling: The circuit creator (the Garbler) generates random 128-bit keys for each input and output of every gate. The truth tables of the gates are encrypted using these keys in a randomized order.
• 3. Oblivious Transfer (OT): The circuit evaluator (the Evaluator) obtains their input keys from the Garbler via an OT cryptographic protocol. The Evaluator learns only the keys corresponding to their actual input without revealing it to the Garbler, and gains no access to the remaining keys.
• 4. Evaluated Computation: The Evaluator decrypts the encrypted truth tables bottom-up through the circuit, computing the result without learning intermediate variable values.

Engineering Optimizations for Blockchain

Raw Garbled Circuits demand massive network communication overhead. To integrate them into a blockchain environment, developers apply two key optimizations:

• Free-XOR Technique: Enables XOR gates to be evaluated without encryption or data transmission, significantly reducing memory overhead and bus bandwidth.
• Point-and-Permute: A bit-masking method allowing the Evaluator to directly locate the correct row in the encrypted truth table without brute-forcing all decryption options.

Comparison of Confidentiality Cryptographic Stacks

Selecting the right technology stack when designing data-protected decentralized applications requires comparing key metrics of modern protocols.

In Practice: Selective Disclosure and Stablecoins

Modern compliance demands a shift away from the concept of total opacity toward selective disclosure. Users retain full control over their capital history while gaining the ability to prove the legitimacy of funds to a counterparty, regulator, or tax authority on demand—all without exposing their entire wallet balance or the full graph of transaction links.

In the Aztec architecture, this is implemented via a multi-key scheme and client-side execution within the Private Execution Environment (PXE).

Aztec Key Architecture

Every user manages a deterministic set of keys tied to their account smart contract:

• Nullifier Keys ($nhk$): Used to generate spend proofs (nullifiers) without leaking information about which specific balance or note is being spent.
• Incoming Viewing Keys ($ivsk$): Enable granting audit access to specific incoming transactions. You can pass an encrypted viewing key to a counterparty or regulator, exposing visibility strictly for the target stablecoin transfer (e.g., L2-wrapped USDT/USDC) while keeping all other assets completely shielded.

Implementation Example: Private Stablecoin Transfers in Noir

Below is a snippet of production-ready code in Noir (the base DSL for writing circuits in Aztec) that implements private balance verification and transfer commitment generation without publishing amounts to a public ledger.

Code Snippet

// Dependency in Nargo.toml: poseidon = { tag = "...", git = "https://github.com/noir-lang/poseidon" }
use poseidon::poseidon::bn254::{hash_2, hash_3};
global TREE_DEPTH: u32 = 32;
struct Note {
    owner: Field,
    amount: u64,
    randomness: Field,
}
fn commit(note: Note) -> Field {
    hash_3([note.owner, note.amount as Field, note.randomness])
}
fn merkle_root(leaf: Field, index: u32, path: [Field; TREE_DEPTH]) -> Field {
    let bits: [u1; TREE_DEPTH] = (index as Field).to_le_bits();
    let mut node = leaf;
    for i in 0..TREE_DEPTH {
        node = if bits[i] == 0 {
            hash_2([node, path[i]])
        } else {
            hash_2([path[i], node])
        };
    }
    node
}
fn main(
    // Public inputs: zero knowledge of amounts and addresses
    merkle_root_pub: pub Field,
    nullifier: pub Field,
    recipient_commitment: pub Field,
    change_commitment: pub Field,
    // Private inputs
    sender_sk: Field,
    sender_note: Note,
    path: [Field; TREE_DEPTH],
    leaf_index: u32,
    transfer_amount: u64,
    recipient_owner: Field,
    recipient_randomness: Field,
    change_randomness: Field,
) {
    // 1. Note ownership (with domain separator)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. Merkle tree membership relative to public root
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. Balance sufficiency (underflow check naturally traps insufficient funds)
    assert(sender_note.amount >= transfer_amount);
    let change_amount = sender_note.amount - transfer_amount;
    // 4. Nullifier
    assert(hash_3([sender_commitment, sender_sk, 2]) == nullifier);
    // 5. Both new notes bound to public commitments
    assert(commit(Note {
        owner: recipient_owner,
        amount: transfer_amount,
        randomness: recipient_randomness,
    }) == recipient_commitment);
    assert(commit(Note {
        owner: sender_note.owner,
        amount: change_amount,
        randomness: change_randomness,
    }) == change_commitment);
}

Handled outside the circuit: note encryption for recipients, contract-level tree storage and state updates, nullifier uniqueness checks, and matching merkle_root_pub against the known root.

Integration Guidelines for Developers

• 1. Eliminate Server-Side Proof Generation: Never trust ZK proof generation to third-party remote APIs. The entire computation cycle (PXE in Aztec or client scripts) must run locally on the user's device or within an isolated node.
• 2. App-Siloed Key Management: Use isolated derived keys for every individual dApp. This ensures that compromising a key in one protocol won't leak or deanonymize a user's transaction history across other smart contracts.
• 3. View Key Auditing Pipelines: When architecting enterprise gateways or payment rails built on programmable privacy, bake in logic for issuing time-bound temporary viewing keys. This lets you clear banking and regulatory compliance (AML/KYT) without ever exposing permanent master wallet keys.