Ketika sebuah public chain menambahkan kompatibilitas EVM, biasanya saya mengasumsikan lingkungan eksekusi aslinya perlahan kehilangan prioritas. Peralatan (tooling) EVM menarik lebih banyak pengembang, Solidity menjadi default, dan runtime native yang terpisah mulai terlihat seperti beban pemeliharaan yang diam-diam dinomorduakan.
Namun arsitektur terbaru @Dusk dengan sengaja menghindari pola itu.
Sekarang DuskDS menangani settlement dan ketersediaan data di level dasar (base), DuskEVM menjalankan aplikasi yang kompatibel dengan EVM, dan DuskVM tetap berada di L1 khusus untuk kontrak Rust dan WASM yang memerlukan akses langsung ke privasi native dan fungsionalitas ZK.
Awalnya saya membacanya sebagai duplikasi yang tidak perlu, tetapi menurut saya justru sebaliknya: ini memperlakukan onboarding pengembang dan kapabilitas protokol sebagai dua masalah yang berbeda, yang tidak seharusnya dipaksa ditempatkan di satu tempat yang sama.
DuskEVM menangani sisi onboarding. Kontrak Solidity, wallet yang sudah ada, dan tooling Ethereum semuanya bekerja di sini tanpa modifikasi. DuskVM menangani sesuatu yang berbeda: ketika sebuah aplikasi membutuhkan model transaksi native Dusk, fitur kerahasiaan, atau bukti ZK, ia tidak perlu menerjemahkan semuanya melalui kode yang kompatibel dengan EVM. Dokumentasi resmi memposisikan DuskVM sebagai lingkungan eksekusi WASM yang berjalan secara native di Dusk L1.
Ini membantu saya memikirkan ulang apa yang sebenarnya sedang dibangun #dusk .
Ini bukan sekadar memecah chain menjadi lapisan-lapisan. Ini mengakui sesuatu yang lebih spesifik: EVM adalah titik masuk yang efektif untuk adopsi pengembang, tetapi mungkin bukan tempat yang tepat untuk membawa kapabilitas yang seharusnya bersifat native bagi protokol itu sendiri.
Yang benar-benar layak disimak bukan apakah $DUSK bisa mengoperasikan dua lingkungan eksekusi sekaligus, melainkan apakah pengembang benar-benar akan memilih jalur yang berbeda berdasarkan kebutuhan mereka.
Jika sebagian besar pengembangan tetap berada di EVM, DuskVM menjadi kapabilitas yang ada tetapi minim digunakan. Jika aplikasi native-privasi dan protokol keuangan mulai merutekan jalurnya melalui jalur eksekusi native karena EVM tidak mampu memenuhi persyaratan tersebut, kompleksitas untuk memelihara dua lingkungan akan memiliki nilai (worth) tertentu.
Namun arsitektur terbaru @Dusk dengan sengaja menghindari pola itu.
Sekarang DuskDS menangani settlement dan ketersediaan data di level dasar (base), DuskEVM menjalankan aplikasi yang kompatibel dengan EVM, dan DuskVM tetap berada di L1 khusus untuk kontrak Rust dan WASM yang memerlukan akses langsung ke privasi native dan fungsionalitas ZK.
Awalnya saya membacanya sebagai duplikasi yang tidak perlu, tetapi menurut saya justru sebaliknya: ini memperlakukan onboarding pengembang dan kapabilitas protokol sebagai dua masalah yang berbeda, yang tidak seharusnya dipaksa ditempatkan di satu tempat yang sama.
DuskEVM menangani sisi onboarding. Kontrak Solidity, wallet yang sudah ada, dan tooling Ethereum semuanya bekerja di sini tanpa modifikasi. DuskVM menangani sesuatu yang berbeda: ketika sebuah aplikasi membutuhkan model transaksi native Dusk, fitur kerahasiaan, atau bukti ZK, ia tidak perlu menerjemahkan semuanya melalui kode yang kompatibel dengan EVM. Dokumentasi resmi memposisikan DuskVM sebagai lingkungan eksekusi WASM yang berjalan secara native di Dusk L1.
Ini membantu saya memikirkan ulang apa yang sebenarnya sedang dibangun #dusk .
Ini bukan sekadar memecah chain menjadi lapisan-lapisan. Ini mengakui sesuatu yang lebih spesifik: EVM adalah titik masuk yang efektif untuk adopsi pengembang, tetapi mungkin bukan tempat yang tepat untuk membawa kapabilitas yang seharusnya bersifat native bagi protokol itu sendiri.
Yang benar-benar layak disimak bukan apakah $DUSK bisa mengoperasikan dua lingkungan eksekusi sekaligus, melainkan apakah pengembang benar-benar akan memilih jalur yang berbeda berdasarkan kebutuhan mereka.
Jika sebagian besar pengembangan tetap berada di EVM, DuskVM menjadi kapabilitas yang ada tetapi minim digunakan. Jika aplikasi native-privasi dan protokol keuangan mulai merutekan jalurnya melalui jalur eksekusi native karena EVM tidak mampu memenuhi persyaratan tersebut, kompleksitas untuk memelihara dua lingkungan akan memiliki nilai (worth) tertentu.
