Tekan ESC untuk menutup

Privasi Terprogram: Garbled Circuits & Aztec Kripto

Evolusi Arsitektur Privasi: Dari Mixer ke Protokol Terprogram

Mixer klasik seperti Tornado Cash atau Sinbad mulai ditinggalkan di bawah tekanan regulator, sanksi Office of Foreign Assets Control (OFAC), dan analisis grafik transaksi menggunakan pelacakan klaster heuristik. Anonimisasi natif pada tingkat liquidity pool diblokir di layer smart contract melalui daftar alamat berisiko tinggi (Chainalysis, Elliptic) yang terintegrasi ke dalam RPC node dari penyedia terkemuka (Infura, Alchemy).

Industri saat ini beralih ke konsep Programmable Privacy. Alih-alih menyembunyikan fakta transaksi itu sendiri melalui pengaburan deposit dalam pool, solusi berbasis protokol baru memungkinkan eksekusi business logic arbitrer dan smart contract di atas data terenkripsi. Pemimpin dalam transisi ini adalah jaringan berbasis arsitektur zk-rollup yang mendukung Programmable Privacy seperti Aztec (Noir), serta jaringan L1 konfidensial khusus seperti COTI 2.0, dengan memanfaatkan primitif perangkat keras dan kriptografi generasi terbaru.

Garbled Circuits dalam Blockchain

Inti dari platform seperti COTI 2.0 didasarkan pada primitif kriptografi klasik Protokol Yao (Yao's Garbled Circuits), yang diadaptasi untuk lingkungan blockchain yang terdesentralisasi. Berbeda dengan zk-SNARK yang membuktikan validitas pernyataan tanpa mengungkapkan data dasar, Garbled Circuits memungkinkan dua pihak atau lebih yang tidak saling percaya untuk menghitung fungsi boolean arbitrer dari input konfidensial sehingga tidak ada pihak yang dapat melihat data pihak lain.

Mekanisme Garbled Circuit

  • 1. Representasi Logika sebagai Sirkuit Boolean: Setiap komputasi (transfer token, pemeriksaan saldo, credit scoring) dikompilasi menjadi directed acyclic graph yang terdiri dari gerbang logika (AND, XOR, NOT).
  • 2. Garbling (Pengaburan): Pembuat sirkuit (Garbler) menghasilkan kunci 128-bit acak untuk setiap input dan output dari setiap gerbang. Kebenaran tabel (truth table) dari gerbang dienkripsi menggunakan kunci ini dalam urutan acak.
  • 3. Oblivious Transfer (OT): Evaluator sirkuit (Evaluator) menerima kunci input mereka dari Garbler melalui protokol kriptografi OT. Evaluator hanya mengetahui kunci untuk input aktual mereka tanpa mengungkapkannya kepada Garbler, serta tidak mendapatkan akses ke kunci lainnya.
  • 4. Penghitungan Elemen demi Elemen: Evaluator mendekripsi tabel kebenaran terenkripsi dari bawah ke atas melalui sirkuit, menghitung hasilnya tanpa memiliki kemampuan untuk mengetahui nilai variabel perantara.

Optimasi Teknikal untuk Blockchain

Garbled Circuits mentah menuntut volume komunikasi jaringan yang sangat besar. Untuk mengintegrasikannya ke dalam lingkungan blockchain, para developer menerapkan dua optimasi utama:

  • Teknik Free-XOR: Memungkinkan eksekusi gerbang XOR tanpa enkripsi dan transmisi data, sehingga mengurangi beban memori dan bandwidth bus secara drastis.
  • Point-and-permute: Metode masking bit yang memungkinkan Evaluator untuk langsung menemukan baris yang benar dalam tabel kebenaran terenkripsi tanpa harus melakukan brute force pada semua opsi dekripsi.

Perbandingan Stack Kriptografi Konfidensialitas

Untuk memilih tech stack yang tepat saat merancang aplikasi terdesentralisasi yang terlindungi datanya, dilakukan pemetaan metrik utama dari protokol-protokol modern.

Protokol / TeknologiBasis KriptografiDukungan Smart ContractOverhead KomputasiModel Kepatuhan (Compliance)
Tornado Cash (Mixer Historis)zk-SNARK (Groth16)Tidak ada (denominasi tetap)Rendah (hanya verifikasi proof)Tidak ada (ketahanan sensor penuh)
Aztec Networkzk-SNARKs + Bahasa NoirTuring Complete (smart contract privat)Sedang (pembuatan proof di sisi client)View Keys, catatan audit terprogram
COTI 2.0Garbled Circuits + MPCDukungan natif untuk contract yang kompatibel dengan EVMTinggi (membutuhkan sirkuit teroptimasi)Pengungkapan Selektif (Selective Disclosure)
Zcash (Shielded Pool)zk-SNARKs (Halo 2 / Sapling)Terbatas (pool transparan vs shielded)MenengahViewing keys

Praktik: Pengungkapan Selektif (Selective Disclosure) dan Stablecoin

Kepatuhan (compliance) modern menuntut pergeseran dari konsep "bayangan mutlak" menuju prinsip pengungkapan selektif (Selective Disclosure). Pengguna tetap memegang kendali penuh atas riwayat aset mereka, namun saat dibutuhkan dapat membuktikan legalitas dana kepada pihak counterparty, regulator, atau otoritas pajak tanpa harus mengekspos total saldo dompet maupun seluruh matriks tautan dengan alamat lain.

Dalam arsitektur Aztec, hal ini diimplementasikan melalui sistem kunci terpisah dan eksekusi sisi klien di dalam Private Execution Environment (PXE).

Arsitektur Kunci di Aztec

Setiap pengguna mengelola serangkaian kunci deterministik yang terikat pada smart contract akun:

  • Nullifier Keys ($nhk$): Digunakan untuk menghasilkan bukti pembelanjaan dana (nullifier) tanpa membocorkan informasi mengenai saldo spesifik atau note mana yang sedang dibelanjakan.
  • Incoming Viewing Keys ($ivsk$): Memungkinkan pemberian akses audit untuk transaksi masuk tertentu. Anda dapat meneruskan kunci peninjau terenkripsi kepada counterparty atau regulator, sehingga mereka hanya bisa melihat transaksi stablecoin target (misalnya USDT/USDC terbungkus di L2) sementara aset lainnya tetap tersembunyi.

Contoh Implementasi: Transfer Stablecoin Privat Menggunakan Noir

Berikut adalah cuplikan kode siap produksi (production-ready) dalam bahasa Noir (DSL dasar untuk menulis sirkuit di Aztec), yang mengimplementasikan verifikasi saldo privat dan pembuatan komitmen transfer token tanpa mempublikasikan nominal ke dalam public ledger.

Cuplikan Kode

// Dependensi di 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(
    // Input publik: tidak ada informasi tentang nominal dan alamat
    merkle_root_pub: pub Field,
    nullifier: pub Field,
    recipient_commitment: pub Field,
    change_commitment: pub Field,
    // Input privat
    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. Kepemilikan note (dengan domain tag)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. Keanggotaan dalam tree relatif terhadap root publik
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. Kecukupan dana (pengurangan u64 juga akan gagal jika dana tidak cukup)
    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. Kedua note baru terikat pada komitmen publik
    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);
}

Hal-hal yang berada di luar sirkuit meliputi: enkripsi note untuk penerima, penyimpanan serta pembaruan tree pada kontrak, pengecekan keunikan nullifier, dan pencocokan merkle_root_pub dengan root yang diketahui.

Rekomendasi Integrasi untuk Developer

  • 1. Hindari Pembuatan Bukti Berbasis Server: Jangan pernah mempercayakan pembuatan ZK-proof kepada server API pihak ketiga jarak jauh. Seluruh siklus komputasi (PXE di Aztec atau skrip klien) harus dijalankan secara lokal di perangkat pengguna atau node terisolasi.
  • 2. Pengelolaan Kunci Terisolasi Aplikasi (App-Siloed Keys): Gunakan kunci turunan yang terisolasi untuk setiap aplikasi desentralisasi (dApp). Ini memastikan bahwa kompromi kunci pada satu protokol tidak akan menyebabkan de-anonimisasi riwayat transaksi pengguna di smart contract lainnya.
  • 3. Audit Kanal View Keys: Saat merancang gateway korporat atau jalur pembayaran berbasis privasi terprogram, terapkan logika pembuatan kunci peninjau sementara dengan batas masa berlaku (time-to-live). Hal ini memungkinkan Anda melewati regulasi dan kepatuhan perbankan (AML/KYT) tanpa harus mempublikasikan master key dompet secara permanen.
Rangkum postingan blog ini dengan:

FAQ

Garbled Circuits menggunakan protokol Secure Multi-Party Computation untuk mengevaluasi fungsi logika terenkripsi di antara beberapa pihak tanpa membagikan data mentah. Pendekatan ini memungkinkan eksekusi smart contract rahasia secara terdistribusi di jaringan L1 seperti COTI 2.0.

Selective Disclosure memanfaatkan Incoming Viewing Keys terisolasi yang memungkinkan pengguna membuktikan legalitas transfer stablecoin kepada regulator secara spesifik. Mekanisme ini membagikan akses audit pada transaksi tertarget tanpa membuka sisa saldo dompet atau riwayat transfer lainnya.

Mixer berbasis kolam likuiditas rentan terhadap pembatasan node RPC dan pelacakan alamat berbasis heuristik dari lembaga kepatuhan. Privasi terprogram menyelesaikan masalah ini dengan menjalankan logika bisnis terenkripsi langsung di dalam smart contract yang dapat diaudit secara selektivo.
Astra EXMON

Astra is the official voice of EXMON and the editorial collective dedicated to bringing you the most timely and accurate information from the crypto market. Astra represents the combined expertise of our internal analysts, product managers, and blockchain engineers.

...

Sampaikan pemikiran Anda

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *