Programlanabilir Gizlilik: Aztec ve Garbled Circuits

Gizlilik Mimarisinin Evrimi: Mikserlerden Programlanabilir Protokollere

Tornado Cash veya Sinbad gibi klasik mikserler; düzenleyicilerin baskısı, OFAC (Yabancı Varlıklar Kontrol Ofisi) yaptırımları ve sezgisel kümeleme tabanlı işlem grafiği analizi altında tarih oluyor. Likidite havuzları düzeyindeki yerel anonimleştirme, önde gelen sağlayıcıların (Infura, Alchemy) RPC düğümlerine entegre edilmiş yüksek riskli adres listeleri (Chainalysis, Elliptic) aracılığıyla akıllı sözleşme katmanında engelleniyor.

Endüstri, programlanabilir gizlilik (Programmable Privacy) konseptine geçiş yapıyor. İşlem olgusunu bir havuzdaki mevduatları harmanlayarak gizlemek yerine yeni protokol düzeyindeki çözümler; şifrelenmiş veriler üzerinde isteğe bağlı iş mantığının ve akıllı sözleşmelerin çalıştırılmasına olanak tanıyor. Bu geçişin liderliğini, Aztec (Noir) gibi Programmable Privacy desteğine sahip zk-rollup tabanlı ağlar ve COTI 2.0 gibi yeni nesil donanım ile kriptografik ilkelere (primitives) dayanan özel gizli L1 ağları üstleniyor.

Blokzincirde Karıştırılmış Devreler (Garbled Circuits)

COTI 2.0 gibi platformların temelinde, merkeziyetsiz blokzincir ortamına uyarlanmış klasik bir kriptografik ilke olan Yao Protokolü (Yao's Garbled Circuits) yatar. Verileri açık etmeden bir ifadenin geçerliliğini kanıtlayan zk-SNARK'ların aksine Garbled Circuits; birbirine güvenmeyen iki veya daha fazla tarafın, taraflardan hiçbiri diğerinin verilerini görmeden gizli girdiler üzerinde rastgele bir mantıksal fonksiyonu (boolean function) hesaplamasına imkan tanır.

Karıştırılmış Devre Mekaniği

• 1. Mantığın Boolean Devre Olarak Temsili: Herhangi bir hesaplama (token transferi, bakiye kontrolü, kredi skoru); mantıksal kapılardan (AND, XOR, NOT) oluşan yönlendirilmiş döngüsüz bir grafa (DAG) derlenir.
• 2. Karıştırma (Garbling): Devreyi oluşturan taraf (Garbler), her kapının her girdisi ve çıktısı için rastgele 128 bitlik anahtarlar üretir. Kapıların doğruluk tabloları (truth tables) bu anahtarlarla rastgele bir sırada şifrelenir.
• 3. Habersiz Aktarım (Oblivious Transfer, OT): Devreyi değerlendiren taraf (Evaluator), OT kriptografik protokolü aracılığıyla Garbler'dan kendi girdi anahtarlarını alır. Evaluator, girdisini Garbler'a ifşa etmeden yalnızca kendi gerçek girdisine karşılık gelen anahtarları öğrenir ve diğer anahtarlara erişemez.
• 4. Bileşen Bazlı Hesaplama: Evaluator, şifrelenmiş doğruluk tablolarını devreden aşağıdan yukarıya doğru çözer (decrypt) ve ara değişken değerlerini bilmeden sonucu hesaplar.

Blokzincir İçin Mühendislik Optimizasyonları

Ham Garbled Circuits devasa hacimde ağ iletişimi gerektirir. Geliştiriciler bunları blokzincir ortamına entegre etmek için iki temel optimizasyon uygular:

• Free-XOR Tekniği: XOR kapılarının şifreleme ve veri aktarımı olmaksızın yürütülmesine izin vererek bellek yükünü ve veri yolu bant genişliğini katbekat azaltır.
• Point-and-permute: Evaluator'ın tüm şifre çözme seçeneklerini kaba kuvvetle (brute-force) denemesine gerek kalmadan, şifrelenmiş doğruluk tablosundaki doğru satırı anında bulmasını sağlayan bir bit maskeleme yöntemi.

Gizlilik Kriptografi Yığınlarının Karşılaştırılması

Veri korumalı merkeziyetsiz uygulamalar tasarlanırken doğru teknoloji yığınını seçmek amacıyla modern protokollerin temel metrikleri karşılaştırılır.

Pratik: Seçmeli İfşa (Selective Disclosure) ve Stablecoinler

Modern uyumluluk (compliance) anlayışı, "mutlak karanlık" konseptinden uzaklaşarak seçmeli ifşa (Selective Disclosure) ilkesine geçiş yapılmasını zorunlu kılar. Kullanıcı sermaye geçmişinin kontrolünü tamamen elinde tutar, ancak gerektiğinde cüzdan bakiyesinin tamamını ve diğer adreslerle olan ilişki matrisini açık etmeden bir karşı tarafa, regülatöre veya vergi dairesine fonların yasallığını kanıtlayabilir.

Aztec mimarisinde bu durum, ayrı anahtar sistemleri ve Private Execution Environment (PXE) içinde gerçekleştirilen istemci tarafı (client-side) yürütme yoluyla hayata geçirilir.

Aztec'te Anahtar Mimarisi

Her kullanıcı, hesap akıllı sözleşmesine bağlı deterministik bir anahtar kümesini yönetir:

• Nullifier Keys ($nhk$): Hangi spesifik bakiyenin veya notun (note) harcandığına dair bilgi sızdırmadan harcama kanıtları (nullifier) üretmek için kullanılır.
• Incoming Viewing Keys ($ivsk$): Belirli gelen işlemler için denetim (audit) erişimi sağlamaya olanak tanır. Şifrelenmiş bir izleme anahtarını (viewing key) bir karşı tarafa veya regülatöre ileterek diğer tüm varlıklarınızı gizli tutarken yalnızca hedef stablecoin işleminin (örneğin L2 sarmalındaki USDT/USDC) görünür olmasını sağlayabilirsiniz.

Uygulama Örneği: Noir Üzerinden Özel (Private) Stablecoin Transferi

Aşağıda, Aztec'te devre (circuit) yazmak için temel DSL olan Noir dilinde yazılmış ve tutarları herkese açık defterde (public ledger) yayınlamadan özel bakiye doğrulaması ile token transfer taahhüdü (commitment) üretmeyi sağlayan production-ready bir kod parçacığı yer almaktadır.

Kod Parçacığı

// Nargo.toml içindeki bağımlılık: 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(
    // Herkese açık girdiler (Public inputs): Tutarlar ve adresler hakkında hiçbir bilgi içermez
    merkle_root_pub: pub Field,
    nullifier: pub Field,
    recipient_commitment: pub Field,
    change_commitment: pub Field,
    // Özel girdiler (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. Not sahipliği (domain etiketiyle)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. Herkese açık köke (public root) göre ağaç üyelik kontrolü
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. Yeterli bakiye kontrolü (yetersiz bakiye durumunda u64 çıkarma işlemi de hata verecektir)
    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. Her iki yeni not da herkese açık commitment'lara bağlıdır
    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);
}

Devrenin (circuit) dışında kalanlar: Alıcı için notların şifrelenmesi, sözleşme üzerinde ağacın saklanması ve güncellenmesi, nullifier benzersizlik kontrolü ve merkle_root_pub değerinin bilinen kök ile karşılaştırılması.

Geliştiriciler İçin Entegrasyon Önerileri

• 1. Sunucu Tarafında Kanıt Üretiminden Kaçının: ZK-proof üretim süreçlerini asla üçüncü taraf uzak API sunucularına emanet etmeyin. Hesaplama döngüsünün tamamı (Aztec'teki PXE veya istemci betikleri) kullanıcının cihazında veya izole bir düğümde (node) yerel olarak çalıştırılmalıdır.
• 2. Uygulama Bazlı İzole Anahtar Yönetimi (App-Siloed Keys): Her bir merkeziyetsiz uygulama (dApp) için izole türetilmiş anahtarlar kullanın. Bu, bir protokoldeki anahtar sızıntısının, kullanıcının diğer akıllı sözleşmelerdeki işlem geçmişinin de anonimliğini yitirmesine yol açmasını engeller.
• 3. View Keys Kanallarının Denetimi: Programlanabilir gizlilik üzerine kurulu kurumsal ağ geçitleri veya ödeme sistemleri tasarlarken, yaşam süresi sınırlı (time-to-live) geçici izleme anahtarları üretme mantığını sisteme dahil edin. Bu sayede cüzdanın kalıcı ana anahtarlarını (master keys) ifşa etmeden bankacılık ve regülasyon uyumluluk süreçleri (AML/KYT) aşılabilir.