Kebanyakan orang fokus pada apakah sebuah chain bersifat privat atau tidak. Biasanya saya memperhatikan siapa yang diberi wewenang untuk memilih.
Saat membaca @Dusk documentation tentang Phoenix dan Moonlight, yang paling menonjol bukanlah adanya dua model transaksi—banyak chain mengklaim privasi opsional—melainkan cara kerangkanya. Phoenix menangani transfer yang di- shielded (disembunyikan) dan bersifat confidential. Moonlight menangani yang transparan, lebih dekat ke model akun berbasis standar. Pilihan model mana yang digunakan ada pada partisipan, bukan pada protokol. Itu keputusan desain kecil dengan implikasi besar: privasi menjadi sebuah pengaturan, bukan posisi bawaan yang seluruh jaringan harus pertahankan atau minta maaf.
Poin lain yang baru saya pikirkan setelah duduk dengan topik ini: entitas yang teregulasi sebenarnya tidak menginginkan anonimitas menyeluruh. Ia ingin membuktikan kepatuhan tanpa mengekspos pihak lawan atau saldo ke buku besar publik. Jika sebuah transaksi perlu menunjukkan bahwa dana bersih atau bahwa ambang batas tidak dilanggar, tanpa mengungkap jumlah yang mendasarinya, sistem akan bertumpu pada selective disclosure melalui zero-knowledge proofs, bukan pada menyembunyikan semuanya atau menampilkan semuanya. Klaim ini lebih sempit daripada "privat", dan lebih berguna bagi audiens yang justru sedang dibangun oleh DUSK.
Catatan penting yang pantas dinyatakan secara gamblang: ini adalah desain pada lapisan transaksi, bukan persetujuan regulasi. Memiliki kapasitas teknis untuk kerahasiaan yang bisa diaudit tidak berarti setiap yurisdiksi mengakuinya, dan itu tidak menggantikan lapisan kepatuhan yang dibangun di atasnya. Ini adalah infrastruktur untuk percakapan itu, bukan kesimpulannya.
Dilihat secara lebih luas, inilah menurut saya taruhan sebenarnya DUSK: DeFi teregulasi tidak dibangun dengan memilih di antara permissioned dan permissionless, atau antara privat dan transparan, melainkan dengan membuat keduanya bisa dipilih di tingkat transaksi. Sekuritas ter-tokenisasi dan RWA membutuhkan fleksibilitas seperti ini: beberapa data harus terlihat oleh regulator, sebagian harus tetap rahasia antara para pihak, dan hampir semuanya tidak boleh terlihat oleh seluruh internet secara default.
$DUSK #dusk
Saat membaca @Dusk documentation tentang Phoenix dan Moonlight, yang paling menonjol bukanlah adanya dua model transaksi—banyak chain mengklaim privasi opsional—melainkan cara kerangkanya. Phoenix menangani transfer yang di- shielded (disembunyikan) dan bersifat confidential. Moonlight menangani yang transparan, lebih dekat ke model akun berbasis standar. Pilihan model mana yang digunakan ada pada partisipan, bukan pada protokol. Itu keputusan desain kecil dengan implikasi besar: privasi menjadi sebuah pengaturan, bukan posisi bawaan yang seluruh jaringan harus pertahankan atau minta maaf.
Poin lain yang baru saya pikirkan setelah duduk dengan topik ini: entitas yang teregulasi sebenarnya tidak menginginkan anonimitas menyeluruh. Ia ingin membuktikan kepatuhan tanpa mengekspos pihak lawan atau saldo ke buku besar publik. Jika sebuah transaksi perlu menunjukkan bahwa dana bersih atau bahwa ambang batas tidak dilanggar, tanpa mengungkap jumlah yang mendasarinya, sistem akan bertumpu pada selective disclosure melalui zero-knowledge proofs, bukan pada menyembunyikan semuanya atau menampilkan semuanya. Klaim ini lebih sempit daripada "privat", dan lebih berguna bagi audiens yang justru sedang dibangun oleh DUSK.
Catatan penting yang pantas dinyatakan secara gamblang: ini adalah desain pada lapisan transaksi, bukan persetujuan regulasi. Memiliki kapasitas teknis untuk kerahasiaan yang bisa diaudit tidak berarti setiap yurisdiksi mengakuinya, dan itu tidak menggantikan lapisan kepatuhan yang dibangun di atasnya. Ini adalah infrastruktur untuk percakapan itu, bukan kesimpulannya.
Dilihat secara lebih luas, inilah menurut saya taruhan sebenarnya DUSK: DeFi teregulasi tidak dibangun dengan memilih di antara permissioned dan permissionless, atau antara privat dan transparan, melainkan dengan membuat keduanya bisa dipilih di tingkat transaksi. Sekuritas ter-tokenisasi dan RWA membutuhkan fleksibilitas seperti ini: beberapa data harus terlihat oleh regulator, sebagian harus tetap rahasia antara para pihak, dan hampir semuanya tidak boleh terlihat oleh seluruh internet secara default.
$DUSK #dusk