Dalam beberapa hari terakhir saya mengupas lagi struktur transaksi Phoenix. Kali ini saya bahkan membaginya jadi satu transaksi terpisah-pisah untuk melihat mana yang benar-benar bisa terlihat di chain dan mana yang tidak terlihat
━━━━━━━━━━━━━━
▎note—apa yang sebenarnya disembunyikan di dalamnya
Phoenix memakai model UTXO, jadi setiap aset di blockchain disebut sebagai sebuah note. Di dalam satu note ada tiga hal: sebuah komitmen untuk jumlah (bukan angka plaintext, melainkan nilai komitmen yang terenkripsi), sebuah faktor pengaburan (secara sederhana ini adalah garam acak yang ditambahkan ke komitmen agar orang tidak bisa menebak jumlah lewat collision), dan sebuah angka acak sekali pakai untuk memastikan setiap note unik sehingga tidak bertabrakan dengan note lain
Ketiga hal ini digabung. Di chain, yang terlihat hanyalah tumpukan data terenkripsi—berapa jumlah yang ditransfer, dan note itu nilainya berapa, sama sekali tidak bisa diketahui oleh pihak luar. Namun jaringan tetap bisa memverifikasi bahwa komitmen-komitmen tersebut seimbang untuk pemasukan dan pengeluaran, tanpa perlu mendekripsi angka spesifik mana pun
━━━━━━━━━━━━━━
▎Anti double-spend dengan nullifier
Hal yang menurut saya menarik dari desain ini: ia tidak mencegah pengeluaran ganda dengan cara "menghapus note lama", melainkan dengan mempublikasikan bukti konsumsi yang tidak bisa dilacak kembali ke note aslinya
Saat sebuah note dibelanjakan, akan dihasilkan nullifier yang sesuai. Nilai ini dihitung secara deterministik, tapi bagi pihak eksternal, sama sekali tidak bisa dipastikan note mana yang menjadi sumbernya. Jaringan cukup memantau: "apakah nullifier ini pernah muncul sebelumnya?" Jika pernah, berarti note yang bersangkutan sudah pernah dibelanjakan. Jika mencoba membelanjakan note yang sama untuk kedua kalinya, nullifier yang dihasilkan akan sama, sehingga berbenturan dengan catatan yang sudah ada—sistem langsung menolak
Seluruh proses tidak mengungkap "siapa yang membelanjakan apa"; semuanya diselesaikan lewat deteksi collision
━━━━━━━━━━━━━━
▎Hash Poseidon—fondasi yang menyangga seluruh status privasi
Status privasi perlu disimpan di dalam sebuah pohon Merkle, yang digunakan untuk membuat bukti keteranggotaan (membuktikan bahwa "note ini memang ada di dalam state tree")
Jika fungsi hash biasa dimasukkan ke dalam sirkuit zk, biayanya sangat besar. Poseidon adalah algoritma hash yang memang didesain agar ramah untuk zk. Struktur algoritmanya lebih selaras dengan sistem pembuktian, sehingga biaya melakukan operasi hash di dalam sirkuit bisa ditekan secara signifikan. Tanpa hash yang ramah zk seperti ini, pembuatan bukti untuk privacy state tree akan jadi terlalu lambat untuk digunakan
@Dusk_Foundation $DUSK #dusk
Dalam transaksi Phoenix, mekanisme apa yang mencegah aset tersembunyi agar tidak bisa dibelanjakan dua kali?