#dusk $DUSK @Dusk Menatap dokumen milik Dusk hampir empat puluh menit, aku terus memikirkan satu pertanyaan: pada akhirnya, dua perangkat—Moonlight dan Phoenix—ini akan berakhir seperti apa?
Moonlight memilih jalur akun publik. Saldo, pengirim transfer, penerima, dan jumlahnya semuanya tertulis di rantai; siapa pun bisa melihat. Ini cocok untuk skenario seperti top up bursa atau rekonsiliasi institusi yang menuntut transparansi.
Phoenix sepenuhnya logika yang berbeda: aset berubah menjadi catatan terenkripsi (note) dan disembunyikan di dalam pohon Merkle. Saat kamu membelanjakan sejumlah uang, kamu tidak mengekspos note spesifik yang kamu pakai, melainkan melempar nullifier beserta bukti ZKP. Jaringan dapat memverifikasi bahwa kamu punya saldo dan tidak melakukan double-spend, tetapi tidak bisa melihat jumlah maupun pengirimnya. Saat perlu audit, kamu bisa melakukan disclosure selektif melalui viewing key.
Aku sempat bersinggungan dengan masalah serupa ketika menulis catatan tentang transfer SEPA di awal bulan: rekonsiliasi antar dua sistem bank, kalau statusnya tidak sinkron itu betapa menyebalkannya—aku sampai diganggu sampai tengah malam jam dua.
Kalau blockchain juga mengotak-atik dengan dua buku besar yang terisolasi, mendingan sekalian pakai keuangan tradisional.
Saat itu aku agak kesal dan merasa penjelasan di dokumen kurang jelas tentang masalah ini. Aku membuka bagian arsitektur kontrak modul Rusk—dua paragraf pertama biasa saja, hanya menjelaskan struktur data Moonlight dan Phoenix masing-masing. Sampai aku membaca paragraf keempat: ketika melihat definisi antarmuka Transfer Contract yang memakai tipe enum untuk payload, baru aku paham maksud desainnya.
Transfer Contract adalah gerbang koordinasi. Ia menerima payload dengan format berbeda—ada yang format Moonlight, ada yang format Phoenix. Kontrak tidak peduli kamu datang dari mana; yang penting adalah field apa saja yang dibawa oleh payload, lalu dia merutekannya ke logika verifikasi yang sesuai. Verifikasi Moonlight langsung membaca status akun publik, sedangkan verifikasi Phoenix menjalankan ZK proof. Setelah kedua verifikasi berhasil, hasilnya ditulis ke dalam satu pohon status global yang sama.
Aku baru benar-benar mengerti bagian kuncinya setelah memikirkannya cukup lama: jika dua pohon status digabung menjadi satu, maka ketika kamu mentransfer dana dari akun publik ke privasi note, pada dasarnya itu hanya konversi format payload—tidak perlu jembatan lintas-chain, tidak perlu protokol sinkronisasi yang rumit. Pembaruan status bersifat atomik: semuanya berhasil atau semuanya gagal dan di-rollback.
Moonlight memilih jalur akun publik. Saldo, pengirim transfer, penerima, dan jumlahnya semuanya tertulis di rantai; siapa pun bisa melihat. Ini cocok untuk skenario seperti top up bursa atau rekonsiliasi institusi yang menuntut transparansi.
Phoenix sepenuhnya logika yang berbeda: aset berubah menjadi catatan terenkripsi (note) dan disembunyikan di dalam pohon Merkle. Saat kamu membelanjakan sejumlah uang, kamu tidak mengekspos note spesifik yang kamu pakai, melainkan melempar nullifier beserta bukti ZKP. Jaringan dapat memverifikasi bahwa kamu punya saldo dan tidak melakukan double-spend, tetapi tidak bisa melihat jumlah maupun pengirimnya. Saat perlu audit, kamu bisa melakukan disclosure selektif melalui viewing key.
Aku sempat bersinggungan dengan masalah serupa ketika menulis catatan tentang transfer SEPA di awal bulan: rekonsiliasi antar dua sistem bank, kalau statusnya tidak sinkron itu betapa menyebalkannya—aku sampai diganggu sampai tengah malam jam dua.
Kalau blockchain juga mengotak-atik dengan dua buku besar yang terisolasi, mendingan sekalian pakai keuangan tradisional.
Saat itu aku agak kesal dan merasa penjelasan di dokumen kurang jelas tentang masalah ini. Aku membuka bagian arsitektur kontrak modul Rusk—dua paragraf pertama biasa saja, hanya menjelaskan struktur data Moonlight dan Phoenix masing-masing. Sampai aku membaca paragraf keempat: ketika melihat definisi antarmuka Transfer Contract yang memakai tipe enum untuk payload, baru aku paham maksud desainnya.
Transfer Contract adalah gerbang koordinasi. Ia menerima payload dengan format berbeda—ada yang format Moonlight, ada yang format Phoenix. Kontrak tidak peduli kamu datang dari mana; yang penting adalah field apa saja yang dibawa oleh payload, lalu dia merutekannya ke logika verifikasi yang sesuai. Verifikasi Moonlight langsung membaca status akun publik, sedangkan verifikasi Phoenix menjalankan ZK proof. Setelah kedua verifikasi berhasil, hasilnya ditulis ke dalam satu pohon status global yang sama.
Aku baru benar-benar mengerti bagian kuncinya setelah memikirkannya cukup lama: jika dua pohon status digabung menjadi satu, maka ketika kamu mentransfer dana dari akun publik ke privasi note, pada dasarnya itu hanya konversi format payload—tidak perlu jembatan lintas-chain, tidak perlu protokol sinkronisasi yang rumit. Pembaruan status bersifat atomik: semuanya berhasil atau semuanya gagal dan di-rollback.
