Mari kita lakukan eksperimen arsitektur dulu: dalam satu transaksi transfer sekuritas, kita harus memeriksa kelayakan investor, menyelesaikan penyerahan aset, dan tetap tidak boleh menyiarkan identitas, saldo, serta syarat transaksi semuanya ke semua orang. Jika privasi hanya ditambahkan sebagai fitur oleh aplikasi tertentu, aplikasi lain belum tentu mengenali rangkaian bukti yang sama, dan aturan kepatuhan pun mudah ditulis versi-versi yang berbeda.
Yang lebih merepotkan: saat aset yang sama berpindah antar-kontak (kontrak), kelayakan yang telah dibuktikan oleh aplikasi sebelumnya mungkin tidak bisa langsung dipakai ulang oleh aplikasi berikutnya; pada akhirnya tetap perlu lapisan tengah tambahan untuk menjelaskan ulang.
Saat melihat arsitektur Dusk, hal yang paling saya perhatikan justru di titik ini: Dusk tidak menempatkan privasi secara terpisah di dalam wallet atau mixer, melainkan memecahkannya ke dalam komponen-komponen berbeda di L1. Dokumentasi resmi mendefinisikan DuskDS sebagai layer penyelesaian (settlement) yang bertanggung jawab atas konsensus, finalitas, dan ketersediaan data; Moonlight menangani akun-akun yang transparan, sementara Phoenix menangani transfer shielded yang bersifat rahasia. Keduanya bisa mentransfer DUSK, membayar gas, dan berfungsi sebagai pintu masuk eksekusi kontrak.
Namun, Dusk juga tidak memaksa semua aset dimasukkan ke satu mode privasi saja. DuskVM langsung menjalankan kontrak Rust/WASM di L1, cocok untuk aplikasi yang membutuhkan aset native, privasi, atau kemampuan zero-knowledge; sementara DuskEVM menyediakan lingkungan EVM yang kompatibel dengan OP Stack, dengan penyelesaian dan ketersediaan data dilakukan melalui DuskDS.
Ini adalah sebuah kompromi: semakin aturan privasi mendekati lapisan konversi status (state transition), semakin mudah konsistensinya dipertahankan lintas aplikasi, tetapi kompleksitas protokol dan biaya verifikasi juga akan meningkat. Node tidak hanya perlu memproses tanda tangan biasa, tetapi juga memverifikasi bukti, memperbarui status yang disembunyikan, dan memastikan agar aplikasi berbeda tidak dapat mengakali aturan aset yang sama. Dengan kata lain, lapisan dasar tidak menjalankan “saklar privasi”, melainkan serangkaian batasan yang terus berjalan.
@Dusk_Foundation $DUSK #dusk
Karena itu, jika memahami jalur Dusk, intinya begini: invarian privasi dijaga oleh infrastruktur, sementara cakupan yang spesifik diserahkan kepada aplikasi dan lapisan identitas untuk mengendalikannya. Situs resmi menekankan confidential by default, bukti zero-knowledge, dan controlled visibility; whitepaper juga menempatkan akun transparan dan privasi UTXO secara paralel. Ini jauh lebih akurat daripada sekadar mengatakan “privasi di-chain”.
Yang lebih merepotkan: saat aset yang sama berpindah antar-kontak (kontrak), kelayakan yang telah dibuktikan oleh aplikasi sebelumnya mungkin tidak bisa langsung dipakai ulang oleh aplikasi berikutnya; pada akhirnya tetap perlu lapisan tengah tambahan untuk menjelaskan ulang.
Saat melihat arsitektur Dusk, hal yang paling saya perhatikan justru di titik ini: Dusk tidak menempatkan privasi secara terpisah di dalam wallet atau mixer, melainkan memecahkannya ke dalam komponen-komponen berbeda di L1. Dokumentasi resmi mendefinisikan DuskDS sebagai layer penyelesaian (settlement) yang bertanggung jawab atas konsensus, finalitas, dan ketersediaan data; Moonlight menangani akun-akun yang transparan, sementara Phoenix menangani transfer shielded yang bersifat rahasia. Keduanya bisa mentransfer DUSK, membayar gas, dan berfungsi sebagai pintu masuk eksekusi kontrak.
Namun, Dusk juga tidak memaksa semua aset dimasukkan ke satu mode privasi saja. DuskVM langsung menjalankan kontrak Rust/WASM di L1, cocok untuk aplikasi yang membutuhkan aset native, privasi, atau kemampuan zero-knowledge; sementara DuskEVM menyediakan lingkungan EVM yang kompatibel dengan OP Stack, dengan penyelesaian dan ketersediaan data dilakukan melalui DuskDS.
Ini adalah sebuah kompromi: semakin aturan privasi mendekati lapisan konversi status (state transition), semakin mudah konsistensinya dipertahankan lintas aplikasi, tetapi kompleksitas protokol dan biaya verifikasi juga akan meningkat. Node tidak hanya perlu memproses tanda tangan biasa, tetapi juga memverifikasi bukti, memperbarui status yang disembunyikan, dan memastikan agar aplikasi berbeda tidak dapat mengakali aturan aset yang sama. Dengan kata lain, lapisan dasar tidak menjalankan “saklar privasi”, melainkan serangkaian batasan yang terus berjalan.
@Dusk_Foundation $DUSK #dusk
Karena itu, jika memahami jalur Dusk, intinya begini: invarian privasi dijaga oleh infrastruktur, sementara cakupan yang spesifik diserahkan kepada aplikasi dan lapisan identitas untuk mengendalikannya. Situs resmi menekankan confidential by default, bukti zero-knowledge, dan controlled visibility; whitepaper juga menempatkan akun transparan dan privasi UTXO secara paralel. Ini jauh lebih akurat daripada sekadar mengatakan “privasi di-chain”.