#dusk $DUSK @Dusk
Saat membaca melalui komponen inti Dusk, saya melihat sesuatu yang mudah terlewat: ada dua protokol terpisah untuk menerbitkan dan mengelola aset teregulasi, bukan satu. Zedger berjalan secara native di DuskDS, lapisan penyelesaian dasar. Hedger berjalan di DuskEVM, lingkungan eksekusi yang kompatibel dengan Ethereum yang berada di atasnya. Keduanya dibangun di sekitar gagasan yang sama — batasan kepatuhan dan privasi tertanam dalam cara aset itu diterbitkan dan dikelola — hanya saja diterapkan dalam dua lingkungan yang berbeda.
Reaksi pertama saya adalah bertanya-tanya mengapa harus mempertahankan dua versi dari logika regulasi yang pada dasarnya sama, alih-alih memilih satu dan membuat semua orang membangunnya. Namun memikirkan siapa sebenarnya yang menerbitkan sekuritas teregulasi, itu mulai masuk akal. Perangkat kerja yang sudah ada, proses audit, dan tim pengembang sebuah institusi tidak otomatis berubah hanya karena ada lapisan penyelesaian yang lebih efisien di tempat lain. Sebagian penerbit dan tumpukan legal/kepatuhan mereka sudah sangat terintegrasi dengan tooling EVM; sementara yang lain memulai dari kondisi yang lebih bersih dan dapat membangun secara native. Menyediakan himpunan batasan yang sama melalui dua titik masuk memenuhi kedua kelompok kira-kira di tempat mereka sudah berada, alih-alih memaksa satu jalur migrasi tunggal ke semua orang.
Namun fleksibilitas itu tidak gratis. Dua implementasi protokol yang sensitif terhadap kepatuhan berarti dua hal yang harus diaudit secara independen, dijaga tetap sinkron secara independen saat kebutuhan regulasi berkembang, dan juga dipercayai secara independen agar tidak menyimpang satu sama lain dengan cara-cara yang halus dari waktu ke waktu. Ada kategori risiko nyata ketika sebuah bug atau inkonsistensi muncul di satu sisi tetapi tidak di sisi lain—sesuatu yang tidak perlu dikelola oleh satu implementasi terpadu.
Jadi pertanyaan praktisnya bukan apakah opsi native-vs-EVM merupakan ide yang baik secara prinsip—jelas itu menurunkan hambatan bagi berbagai jenis penerbit. Pertanyaannya adalah apakah Dusk dapat memastikan kedua protokol tetap berperilaku identik pada tingkat jaminan yang benar-benar dibutuhkan untuk penerbitan aset teregulasi, terutama saat masing-masing protokol berkembang di lingkungan eksekusi mereka sendiri dari waktu ke waktu.
$DUSK
Saat membaca melalui komponen inti Dusk, saya melihat sesuatu yang mudah terlewat: ada dua protokol terpisah untuk menerbitkan dan mengelola aset teregulasi, bukan satu. Zedger berjalan secara native di DuskDS, lapisan penyelesaian dasar. Hedger berjalan di DuskEVM, lingkungan eksekusi yang kompatibel dengan Ethereum yang berada di atasnya. Keduanya dibangun di sekitar gagasan yang sama — batasan kepatuhan dan privasi tertanam dalam cara aset itu diterbitkan dan dikelola — hanya saja diterapkan dalam dua lingkungan yang berbeda.
Reaksi pertama saya adalah bertanya-tanya mengapa harus mempertahankan dua versi dari logika regulasi yang pada dasarnya sama, alih-alih memilih satu dan membuat semua orang membangunnya. Namun memikirkan siapa sebenarnya yang menerbitkan sekuritas teregulasi, itu mulai masuk akal. Perangkat kerja yang sudah ada, proses audit, dan tim pengembang sebuah institusi tidak otomatis berubah hanya karena ada lapisan penyelesaian yang lebih efisien di tempat lain. Sebagian penerbit dan tumpukan legal/kepatuhan mereka sudah sangat terintegrasi dengan tooling EVM; sementara yang lain memulai dari kondisi yang lebih bersih dan dapat membangun secara native. Menyediakan himpunan batasan yang sama melalui dua titik masuk memenuhi kedua kelompok kira-kira di tempat mereka sudah berada, alih-alih memaksa satu jalur migrasi tunggal ke semua orang.
Namun fleksibilitas itu tidak gratis. Dua implementasi protokol yang sensitif terhadap kepatuhan berarti dua hal yang harus diaudit secara independen, dijaga tetap sinkron secara independen saat kebutuhan regulasi berkembang, dan juga dipercayai secara independen agar tidak menyimpang satu sama lain dengan cara-cara yang halus dari waktu ke waktu. Ada kategori risiko nyata ketika sebuah bug atau inkonsistensi muncul di satu sisi tetapi tidak di sisi lain—sesuatu yang tidak perlu dikelola oleh satu implementasi terpadu.
Jadi pertanyaan praktisnya bukan apakah opsi native-vs-EVM merupakan ide yang baik secara prinsip—jelas itu menurunkan hambatan bagi berbagai jenis penerbit. Pertanyaannya adalah apakah Dusk dapat memastikan kedua protokol tetap berperilaku identik pada tingkat jaminan yang benar-benar dibutuhkan untuk penerbitan aset teregulasi, terutama saat masing-masing protokol berkembang di lingkungan eksekusi mereka sendiri dari waktu ke waktu.
$DUSK