#dusk $DUSK @Dusk
Hal yang menarik perhatian saya saat menelusuri dokumentasi Dusk: hanya ada dua kontrak. Pada genesis hanya ada kontrak stake dan kontrak transfer. Semua yang lain—termasuk DuskVM dan DuskEVM—dibangun di atas keduanya.
Itu jumlah konsentrasi yang aneh untuk sebuah chain yang dibangun untuk menyelesaikan aset yang teregulasi. Jadi saya ingin memeriksa apa yang benar-benar dilakukan kedua kontrak ini dan apakah keduanya bisa diubah nanti.
Kontrak stake melacak provisioner: berapa yang distake, kapan reward matang, dan kapan slashing diterapkan. Kontrak transfer menangani saldo publik (Moonlight) dan saldo terselubung (Phoenix), dan ini satu-satunya tempat terjadinya perpindahan dana antarkontrak. Setiap environment eksekusi mengarah ke kontrak ini untuk penyelesaian dan ketersediaan data sesuai dokumentasi yang ada.
Mengapa ini penting: jika Anda membangun di atas DuskEVM atau menerbitkan aset melalui Dusk Trade, Anda tidak hanya mempercayai logika kontrak Anda sendiri. Anda mempercayai bahwa kedua kontrak genesis ini berperilaku dengan benar untuk jangka waktu yang tak terbatas, karena merekalah fondasi penyelesaian (settlement substrate) di bawah semuanya.
Berikut yang tidak bisa saya pastikan. Dokumentasi menjelaskan bahwa kontrak-kontrak ini direfaktorkan dari waktu ke waktu: kontrak staking dibangun ulang untuk memperbaiki masalah storage, dan kemudian pembaruan rekayasa mengubah struktur Event-nya. Jadi jelas keduanya tidak “beku” secara immutable sejak genesis.
Yang masih membingungkan bagi saya adalah jalur upgrade yang sebenarnya: apakah itu diskresioner (tim protokol merilis upgrade jaringan) atau ada langkah tata kelola on-chain yang formal yang dipilih oleh provisioner sebelum logika kontrak genesis diubah? Dokumentasi yang saya temukan menjelaskan apa yang dilakukan kontrak-kontrak tersebut, bukan bagaimana modifikasi terhadap kontrak-kontrak itu diberi wewenang.
Untuk sebuah chain yang memposisikan dirinya bagi penyelesaian institusional, pembedaan antara upgrade yang diotorisasi oleh tim vs upgrade yang disahkan oleh provisioner seharusnya terdokumentasi secara eksplisit di suatu tempat.
Apakah ada yang pernah melihat di mana <@Dusk > menetapkan proses Authorization yang sebenarnya untuk perubahan kontrak genesis?
$DUSK #dusk
Hal yang menarik perhatian saya saat menelusuri dokumentasi Dusk: hanya ada dua kontrak. Pada genesis hanya ada kontrak stake dan kontrak transfer. Semua yang lain—termasuk DuskVM dan DuskEVM—dibangun di atas keduanya.
Itu jumlah konsentrasi yang aneh untuk sebuah chain yang dibangun untuk menyelesaikan aset yang teregulasi. Jadi saya ingin memeriksa apa yang benar-benar dilakukan kedua kontrak ini dan apakah keduanya bisa diubah nanti.
Kontrak stake melacak provisioner: berapa yang distake, kapan reward matang, dan kapan slashing diterapkan. Kontrak transfer menangani saldo publik (Moonlight) dan saldo terselubung (Phoenix), dan ini satu-satunya tempat terjadinya perpindahan dana antarkontrak. Setiap environment eksekusi mengarah ke kontrak ini untuk penyelesaian dan ketersediaan data sesuai dokumentasi yang ada.
Mengapa ini penting: jika Anda membangun di atas DuskEVM atau menerbitkan aset melalui Dusk Trade, Anda tidak hanya mempercayai logika kontrak Anda sendiri. Anda mempercayai bahwa kedua kontrak genesis ini berperilaku dengan benar untuk jangka waktu yang tak terbatas, karena merekalah fondasi penyelesaian (settlement substrate) di bawah semuanya.
Berikut yang tidak bisa saya pastikan. Dokumentasi menjelaskan bahwa kontrak-kontrak ini direfaktorkan dari waktu ke waktu: kontrak staking dibangun ulang untuk memperbaiki masalah storage, dan kemudian pembaruan rekayasa mengubah struktur Event-nya. Jadi jelas keduanya tidak “beku” secara immutable sejak genesis.
Yang masih membingungkan bagi saya adalah jalur upgrade yang sebenarnya: apakah itu diskresioner (tim protokol merilis upgrade jaringan) atau ada langkah tata kelola on-chain yang formal yang dipilih oleh provisioner sebelum logika kontrak genesis diubah? Dokumentasi yang saya temukan menjelaskan apa yang dilakukan kontrak-kontrak tersebut, bukan bagaimana modifikasi terhadap kontrak-kontrak itu diberi wewenang.
Untuk sebuah chain yang memposisikan dirinya bagi penyelesaian institusional, pembedaan antara upgrade yang diotorisasi oleh tim vs upgrade yang disahkan oleh provisioner seharusnya terdokumentasi secara eksplisit di suatu tempat.
Apakah ada yang pernah melihat di mana <@Dusk > menetapkan proses Authorization yang sebenarnya untuk perubahan kontrak genesis?
$DUSK #dusk
