Programmierbare Privatsphäre: Aztec & Garbled Circuits

Die Evolution der Privacy-Architektur: Von Mixern zu programmierbaren Protokollen

Klassische Mixer wie Tornado Cash oder Sinbad werden unter dem Druck von Regulierungsbehörden, OFAC-Sanktionen und der Analyse von Transaktionsgraphen via heuristischem Cluster-Tracking obsolet. Native Anonymisierung auf Ebene von Liquiditätspools wird auf Smart-Contract-Ebene über Risikoadressen-Listen (Chainalysis, Elliptic) blockiert, die in die RPC-Nodes führender Provider (Infura, Alchemy) integriert sind.

Die Industrie bewegt sich hin zum Konzept der programmierbaren Privatsphäre (Programmable Privacy). Anstatt den Transaktionssachverhalt lediglich durch das Verwischen von Einzahlungen in einem Pool zu verschleiern, erlauben neuartige Protokoll-Layer-Lösungen die Ausführung beliebiger Business-Logik und von Smart Contracts direkt auf verschlüsselten Daten. Angeführt wird dieser Wandel von Netzwerken auf Basis von zk-Rollup-Architekturen mit Programmable Privacy wie Aztec (Noir) sowie spezialisierten, vertraulichen L1-Netzwerken wie COTI 2.0, die Hardware- und kryptografische Primitiva der nächsten Generation nutzen.

Garbled Circuits in der Blockchain

Das Fundament von Plattformen wie COTI 2.0 bildet ein klassisches kryptografisches Primitiv: Yaos Protokoll (Yao's Garbled Circuits), adaptiert für eine dezentrale Blockchain-Umgebung. Im Gegensatz zu zk-SNARKs, die die Gültigkeit einer Aussage ohne Offenlegung der Daten beweisen, ermöglichen Garbled Circuits zwei oder mehr einander nicht vertrauenden Parteien die Berechnung einer beliebigen Booleschen Funktion über vertrauliche Inputs, ohne dass eine der Parteien Einblick in die Daten der anderen erhält.

Mechanik eines Garbled Circuit

• 1. Repräsentation der Logik als Boolescher Schaltkreis: Jede Berechnung (Token-Transfer, Saldenprüfung, Credit Scoring) wird in einen gerichteten azyklischen Graphen kompiliert, der aus Logikgattern (AND, XOR, NOT) besteht.
• 2. Garbling (Verschleierung): Der Ersteller des Schaltkreises (Garbler) generiert zufällige 128-Bit-Schlüssel für jeden Input und Output jedes Gatters. Die Wahrheitstabellen der Gatter werden mit diesen Schlüsseln in zufälliger Reihenfolge verschlüsselt.
• 3. Oblivious Transfer (OT): Der Auswerter des Schaltkreises (Evaluator) erhält seine Input-Schlüssel vom Garbler über ein kryptografisches OT-Protokoll. Der Evaluator erfährt dabei ausschließlich die Schlüssel für seinen echten Input, ohne diesen dem Garbler offenzulegen, und erhält keinen Zugriff auf die übrigen Schlüssel.
• 4. Elementweise Berechnung: Der Evaluator entschlüsselt die verschlüsselten Wahrheitstabellen von unten nach oben im Schaltkreis und ermittelt das Ergebnis, ohne Zwischenwerte der Variablen aufdecken zu müssen.

Engineering-Optimierungen für die Blockchain

Rohe Garbled Circuits erfordern ein massives Volumen an Netzwerkkommunikation. Um sie in eine Blockchain-Umgebung zu integrieren, wenden Entwickler zwei zentrale Optimierungen an:

• Free-XOR-Technik: Ermöglicht die Ausführung von XOR-Gattern ohne Verschlüsselung und Datenübertragung, wodurch die Speicherlast und die Bus-Bandbreite drastisch reduziert werden.
• Point-and-permute: Eine Bit-Maskierungsmethode, die es dem Evaluator erlaubt, die korrekte Zeile in der verschlüsselten Wahrheitstabelle direkt zu finden, ohne sämtliche Entschlüsselungsoptionen per Brute-Force durchprobieren zu müssen.

Vergleich kryptografischer Confidentiality-Stacks

Bei der Konzeption datengeschützter dezentraler Anwendungen dient die Gegenüberstellung zentraler Metriken moderner Protokolle als Basis für die Auswahl des richtigen Technologie-Stacks.

Praxis: Selektive Offenlegung (Selective Disclosure) und Stablecoins

Moderner Compliance-Ansatz erfordert den Abkehr vom Konzept der „absoluten Intransparenz“ hin zum Prinzip der selektiven Offenlegung (Selective Disclosure). Der Nutzer behält die vollständige Kontrolle über seine Kapitalhistorie, kann jedoch bei Bedarf gegenüber Kontrahenten, Regulierungsbehörden oder Finanzämtern die Legalität von Mitteln nachweisen, ohne den vollständigen Wallet-Saldo oder die gesamte Matrix von Verknüpfungen zu anderen Adressen offenzulegen.

In der Aztec-Architektur wird dies über ein System separater Schlüssel und die clientseitige Ausführung innerhalb der Private Execution Environment (PXE) realisiert.

Schlüsselarchitektur in Aztec

Jeder Nutzer verwaltet einen deterministischen Satz von Schlüsseln, die an den Smart Contract des Accounts gebunden sind:

• Nullifier Keys ($nhk$): Werden zur Generierung von Ausgabebeweisen (Nullifier) verwendet, ohne Informationen darüber preiszugeben, welcher spezifische Saldo oder welche Note gerade ausgegeben wird.
• Incoming Viewing Keys ($ivsk$): Ermöglichen die Bereitstellung von Audit-Zugriffen auf bestimmte eingehende Transaktionen. Sie können einen verschlüsselten Viewing Key an einen Kontrahenten oder eine Regulierungsbehörde weitergeben, um diesen ausschließlich Einblick in die jeweilige Stablecoin-Transaktion (z. B. L2-gewrapptes USDT/USDC) zu gewähren, während alle anderen Assets verborgen bleiben.

Implementierungsbeispiel: Private Stablecoin-Transfers in Noir

Nachfolgend ist ein Ausschnitt von production-ready Code in Noir (dem Basis-DSL zum Schreiben von Circuits in Aztec) dargestellt, der eine private Saldenprüfung sowie die Generierung einer Token-Transferverpflichtung implementiert, ohne Beträge im öffentlichen Ledger zu veröffentlichen.

Code-Snippet

// Abhängigkeit 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(
    // Öffentliche Inputs: keine Informationen über Beträge und Adressen
    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. Noten-Eigentum (mit Domänentag)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. Baum-Zugehörigkeit relativ zur öffentlichen Wurzel
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. Ausreichende Deckung (bei Unterdeckung schlägt auch die u64-Subtraktion fehl)
    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. Beide neuen Noten sind an öffentliche Commitments gebunden
    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);
}

Außerhalb des Circuits verbleiben: die Verschlüsselung der Noten für den Empfänger, die Speicherung und Aktualisierung des Baums im Contract, die Prüfung der Nullifier-Einzigartigkeit sowie der Abgleich von merkle_root_pub mit der bekannten Wurzel.

Integrationsempfehlungen für Entwickler

• 1. Verzicht auf serverseitige Beweisgenerierung: Vertrauen Sie die Generierung von ZK-Proofs niemals externen Remote-API-Servern von Drittanbietern an. Der gesamte Berechnungszyklus (PXE in Aztec oder Clientskripte) muss lokal auf dem Endgerät des Nutzers oder in einer isolierten Node ausgeführt werden.
• 2. Verwaltung app-siloierter Schlüssel (App-Siloed Keys): Verwenden Sie isolierte abgeleitete Schlüssel für jede dezentrale App. Dies stellt sicher, dass eine Kompromittierung des Schlüssels in einem Protokoll nicht zur Deanonymisierung der Transaktionshistorie des Nutzers in anderen Smart Contracts führt.
• 3. Audit von View-Key-Kanälen: Planen Sie beim Entwurf von Unternehmens- oder Zahlungs-Gateways auf Basis programmierbarer Privatsphäre Logik zur Generierung temporärer Viewing Keys mit begrenzter Lebensdauer ein. Dies ermöglicht die Erfüllung banken- und aufsichtsrechtlicher Compliance-Vorgaben (AML/KYT), ohne permanente Master-Schlüssel des Wallets veröffentlichen zu müssen.