Dulu saya pikir, jika sebuah public chain menyediakan beberapa lingkungan eksekusi, paling-paling itu hanya memberi pengembang lebih banyak opsi. Namun setelah arsitektur @Dusk diurai, saya menyadari hubungan DuskVM dan DuskEVM ternyata tidak sesederhana itu—mereka lebih mirip dua pintu masuk yang ditujukan untuk kebutuhan yang berbeda.$DUSK
DuskVM berjalan langsung di Dusk L1, menggunakan Rust/WASM; cocok untuk memanggil aset asli (native), privasi, serta kemampuan ZK. DuskEVM lebih seperti jembatan migrasi, sehingga pengembang Solidity bisa terus memakai dompet, framework, dan alat pengujian yang sudah familiar. Pada akhirnya, hasil dari kedua sisi diserahkan kepada DuskDS untuk settlement.#dusk
Artinya, peran DuskEVM tidak hanya untuk menurunkan hambatan migrasi. Misalnya, sebuah aplikasi keuangan biasa ingin terlebih dahulu terhubung dengan toolchain EVM yang sudah matang—ia bisa mulai dari DuskEVM. Tetapi jika yang dikerjakan adalah sekuritas privat, transfer aset terkontrol, atau perlu memanggil kemampuan rahasia native Dusk, maka tidak bisa berhenti di lapisan EVM saja; banyak logika tetap perlu mengandalkan DuskVM.
Muncul pertanyaannya. Misalkan sebuah aplikasi harus mengintegrasikan kontrak Solidity sekaligus menangani aset privat native Dusk—di mana state inti seharusnya disimpan? Bagaimana sinkronisasi dilakukan di antara dua lingkungan tersebut? Untuk pemanggilan lintas-lapisan, siapa yang memverifikasi? Jika terjadi kesalahan, pengembang harus menelusuri apakah itu masalah kontrak, masalah lingkungan eksekusi, atau masalah settlement layer?$BTC
Karena itu, saat ini saya melihat multi-lingkungan eksekusi Dusk bukan sekadar sebagai keunggulan kompatibilitas. Di satu sisi, ini membuat lebih banyak pengembang bisa masuk. Di sisi lain, ia juga menyerahkan tantangan besar dalam desain sistem kepada tim pengembang. Yang benar-benar patut diperhatikan bukan berapa banyak cara eksekusi yang disediakan Dusk, melainkan apakah antar-lingkungan tersebut bisa membentuk batas yang jelas—agar pengembang lebih sedikit melakukan keputusan yang tidak perlu, bukan karena ingin memanggil kemampuan yang berbeda sekaligus lalu arsitektur aplikasi makin ditumpuk dan menjadi makin kompleks.$ETH
DuskVM berjalan langsung di Dusk L1, menggunakan Rust/WASM; cocok untuk memanggil aset asli (native), privasi, serta kemampuan ZK. DuskEVM lebih seperti jembatan migrasi, sehingga pengembang Solidity bisa terus memakai dompet, framework, dan alat pengujian yang sudah familiar. Pada akhirnya, hasil dari kedua sisi diserahkan kepada DuskDS untuk settlement.#dusk
Artinya, peran DuskEVM tidak hanya untuk menurunkan hambatan migrasi. Misalnya, sebuah aplikasi keuangan biasa ingin terlebih dahulu terhubung dengan toolchain EVM yang sudah matang—ia bisa mulai dari DuskEVM. Tetapi jika yang dikerjakan adalah sekuritas privat, transfer aset terkontrol, atau perlu memanggil kemampuan rahasia native Dusk, maka tidak bisa berhenti di lapisan EVM saja; banyak logika tetap perlu mengandalkan DuskVM.
Muncul pertanyaannya. Misalkan sebuah aplikasi harus mengintegrasikan kontrak Solidity sekaligus menangani aset privat native Dusk—di mana state inti seharusnya disimpan? Bagaimana sinkronisasi dilakukan di antara dua lingkungan tersebut? Untuk pemanggilan lintas-lapisan, siapa yang memverifikasi? Jika terjadi kesalahan, pengembang harus menelusuri apakah itu masalah kontrak, masalah lingkungan eksekusi, atau masalah settlement layer?$BTC
Karena itu, saat ini saya melihat multi-lingkungan eksekusi Dusk bukan sekadar sebagai keunggulan kompatibilitas. Di satu sisi, ini membuat lebih banyak pengembang bisa masuk. Di sisi lain, ia juga menyerahkan tantangan besar dalam desain sistem kepada tim pengembang. Yang benar-benar patut diperhatikan bukan berapa banyak cara eksekusi yang disediakan Dusk, melainkan apakah antar-lingkungan tersebut bisa membentuk batas yang jelas—agar pengembang lebih sedikit melakukan keputusan yang tidak perlu, bukan karena ingin memanggil kemampuan yang berbeda sekaligus lalu arsitektur aplikasi makin ditumpuk dan menjadi makin kompleks.$ETH