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 / Teknologi | Basis Kriptografi | Dukungan Smart Contract | Overhead Komputasi | Model Kepatuhan (Compliance) |
|---|---|---|---|---|
| Tornado Cash (Mixer Historis) | zk-SNARK (Groth16) | Tidak ada (denominasi tetap) | Rendah (hanya verifikasi proof) | Tidak ada (ketahanan sensor penuh) |
| Aztec Network | zk-SNARKs + Bahasa Noir | Turing Complete (smart contract privat) | Sedang (pembuatan proof di sisi client) | View Keys, catatan audit terprogram |
| COTI 2.0 | Garbled Circuits + MPC | Dukungan natif untuk contract yang kompatibel dengan EVM | Tinggi (membutuhkan sirkuit teroptimasi) | Pengungkapan Selektif (Selective Disclosure) |
| Zcash (Shielded Pool) | zk-SNARKs (Halo 2 / Sapling) | Terbatas (pool transparan vs shielded) | Menengah | Viewing 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.