#dusk $DUSK @Dusk Pada awalnya saya mengira blockchain privasi seharusnya menyembunyikan semuanya. Saat mempelajari Dusk, saya menyadari bahwa mungkin pertanyaannya justru desain yang keliru.
Pertanyaan yang lebih tepat adalah: bagian mana dari sebuah transaksi keuangan yang harus tetap terlihat?
Dusk memisahkan kebutuhan-kebutuhan tersebut. Moonlight mendukung transaksi berbasis akun yang transparan, sementara Phoenix menggunakan catatan yang disamarkan (shielded notes) dan bukti zero-knowledge untuk menyembunyikan detail transaksi sekaligus membuktikan validitasnya. Kedua model tersebut diselesaikan melalui DuskDS.
Itu menciptakan ketergantungan yang menarik.
Aplikasi keuangan mungkin memerlukan kerahasiaan untuk posisi-posisi yang sensitif, tetapi regulator atau pihak lawan tetap dapat meminta informasi tertentu. Karena itu, Dusk memandang privasi sebagai pengungkapan yang dikendalikan, bukan sebagai kerahasiaan permanen.
Saya pikir di sinilah arsitekturnya menjadi menarik.
Kriptografi bisa melindungi data yang disamarkan, tetapi ia tidak dapat memutuskan apakah sebuah aplikasi memilih model transaksi yang tepat, atau justru secara tidak sengaja mengungkap informasi melalui logika di sekelilingnya.
Jadi keterbatasannya tidak selalu terletak pada primitive privasinya sendiri. Masalahnya adalah kompleksitas dalam mengelola visibilitas dengan benar.
Dusk menangkap sesuatu yang penting dengan tepat: privasi tidak harus bersifat serba-semua atau tidak sama sekali.
Pertanyaan yang sedang saya perhatikan sekarang lebih sederhana:
Bisakah para pengembang secara konsisten mengendalikan apa yang menjadi terlihat, untuk siapa, dan dalam kondisi apa? $DUSK
Pertanyaan yang lebih tepat adalah: bagian mana dari sebuah transaksi keuangan yang harus tetap terlihat?
Dusk memisahkan kebutuhan-kebutuhan tersebut. Moonlight mendukung transaksi berbasis akun yang transparan, sementara Phoenix menggunakan catatan yang disamarkan (shielded notes) dan bukti zero-knowledge untuk menyembunyikan detail transaksi sekaligus membuktikan validitasnya. Kedua model tersebut diselesaikan melalui DuskDS.
Itu menciptakan ketergantungan yang menarik.
Aplikasi keuangan mungkin memerlukan kerahasiaan untuk posisi-posisi yang sensitif, tetapi regulator atau pihak lawan tetap dapat meminta informasi tertentu. Karena itu, Dusk memandang privasi sebagai pengungkapan yang dikendalikan, bukan sebagai kerahasiaan permanen.
Saya pikir di sinilah arsitekturnya menjadi menarik.
Kriptografi bisa melindungi data yang disamarkan, tetapi ia tidak dapat memutuskan apakah sebuah aplikasi memilih model transaksi yang tepat, atau justru secara tidak sengaja mengungkap informasi melalui logika di sekelilingnya.
Jadi keterbatasannya tidak selalu terletak pada primitive privasinya sendiri. Masalahnya adalah kompleksitas dalam mengelola visibilitas dengan benar.
Dusk menangkap sesuatu yang penting dengan tepat: privasi tidak harus bersifat serba-semua atau tidak sama sekali.
Pertanyaan yang sedang saya perhatikan sekarang lebih sederhana:
Bisakah para pengembang secara konsisten mengendalikan apa yang menjadi terlihat, untuk siapa, dan dalam kondisi apa? $DUSK
