#dusk $DUSK
Saat saya mempelajari model transaksi dari Phoenix @Dusk , saya selalu punya satu pertanyaan:
Kalau Phoenix bisa menyembunyikan sender, receiver, dan amount, kenapa masih mempertahankan Moonlight yang sepenuhnya terbuka?
Setelah membaca lebih lanjut di dokumentasi integrasinya, jawabannya ternyata cukup realistis.
Ada beberapa skenario yang memang membutuhkan keterbukaan.
Misalnya, bursa yang menerima DUSK.
Mereka harus memindai catatan deposit yang sudah final, mengetahui berapa banyak yang masuk dari akun mana, lalu mencocokkan catatan di blockchain dengan custody ledger mereka.
Dalam kasus seperti ini, model account pada Moonlight justru jauh lebih sederhana.
Phoenix memakai logika yang berbeda.
Dana disimpan dalam shielded notes, dan validitas input dibuktikan menggunakan ZK proof, sekaligus memastikan tidak terjadi double spend. Tidak perlu menampilkan pihak-pihak transaksi maupun nominalnya di browser agar bisa dilihat semua orang.
Dua model ini sama-sama diproses di DuskDS pada akhirnya, tetapi mereka tidak menyelesaikan kebutuhan yang sama.
Detail ini membuat saya memandang desain privasi Dusk dengan jauh berbeda.
Dulu saya merasa:
Semakin kuat privasi, semakin baik.
Sekarang saya tidak lagi berpikir begitu.
Dalam sistem keuangan, keterbukaan punya kegunaannya sendiri, dan privasi juga punya kegunaannya sendiri. Untuk pencatatan masuk (accounting) bursa, keterlacakan dan keterindeksan memang perlu. Sementara untuk transfer biasa atau arus dana yang sensitif, belum tentu ada alasan untuk dipublikasikan selamanya.
Yang lebih menarik, Dusk Wallet sendiri juga mendukung konversi antara Moonlight dan Phoenix.
Jadi, bukan berarti ia mengharuskan pengguna memilih kubu.
Saat perlu yang terbuka, gunakan Moonlight; saat perlu alur shielded, masuk ke Phoenix.
Sekarang saya justru merasa bahwa mempertahankan kedua model sekaligus adalah lebih praktis daripada memaksa semua transaksi dimasukkan ke dalam dua kata “privasi”.
“Keterbukaan” di sini bukan berarti privasinya tidak dibuat dengan baik, melainkan sebuah fitur yang secara sadar tetap dipertahankan.
Saat saya mempelajari model transaksi dari Phoenix @Dusk , saya selalu punya satu pertanyaan:
Kalau Phoenix bisa menyembunyikan sender, receiver, dan amount, kenapa masih mempertahankan Moonlight yang sepenuhnya terbuka?
Setelah membaca lebih lanjut di dokumentasi integrasinya, jawabannya ternyata cukup realistis.
Ada beberapa skenario yang memang membutuhkan keterbukaan.
Misalnya, bursa yang menerima DUSK.
Mereka harus memindai catatan deposit yang sudah final, mengetahui berapa banyak yang masuk dari akun mana, lalu mencocokkan catatan di blockchain dengan custody ledger mereka.
Dalam kasus seperti ini, model account pada Moonlight justru jauh lebih sederhana.
Phoenix memakai logika yang berbeda.
Dana disimpan dalam shielded notes, dan validitas input dibuktikan menggunakan ZK proof, sekaligus memastikan tidak terjadi double spend. Tidak perlu menampilkan pihak-pihak transaksi maupun nominalnya di browser agar bisa dilihat semua orang.
Dua model ini sama-sama diproses di DuskDS pada akhirnya, tetapi mereka tidak menyelesaikan kebutuhan yang sama.
Detail ini membuat saya memandang desain privasi Dusk dengan jauh berbeda.
Dulu saya merasa:
Semakin kuat privasi, semakin baik.
Sekarang saya tidak lagi berpikir begitu.
Dalam sistem keuangan, keterbukaan punya kegunaannya sendiri, dan privasi juga punya kegunaannya sendiri. Untuk pencatatan masuk (accounting) bursa, keterlacakan dan keterindeksan memang perlu. Sementara untuk transfer biasa atau arus dana yang sensitif, belum tentu ada alasan untuk dipublikasikan selamanya.
Yang lebih menarik, Dusk Wallet sendiri juga mendukung konversi antara Moonlight dan Phoenix.
Jadi, bukan berarti ia mengharuskan pengguna memilih kubu.
Saat perlu yang terbuka, gunakan Moonlight; saat perlu alur shielded, masuk ke Phoenix.
Sekarang saya justru merasa bahwa mempertahankan kedua model sekaligus adalah lebih praktis daripada memaksa semua transaksi dimasukkan ke dalam dua kata “privasi”.
“Keterbukaan” di sini bukan berarti privasinya tidak dibuat dengan baik, melainkan sebuah fitur yang secara sadar tetap dipertahankan.