#dusk $DUSK
Dalam beberapa hari ini, saya membaca ulang dokumen arsitektur @Dusk , dan ada satu hal yang ternyata sebelumnya saya anggap terlalu sederhana.
Pada akhirnya, DuskEVM juga akan kembali ke settlement DuskDS. Lalu, kenapa tetap perlu mempertahankan DuskVM secara terpisah?
Awalnya saya mengira ini hanya karena bahasa pengembangnya berbeda: yang satu Solidity, yang satu Rust/WASM.
Tapi setelah dibaca lebih lanjut, ternyata perbedaannya ada pada execution path.
DuskVM dijalankan langsung di L1.
Sedangkan DuskEVM tidak. Transaksinya dulu melewati sequencer, lalu dieksekusi di layer EVM. Setelah itu masih ada batch, state commitment, kemudian baru disambungkan kembali ke DuskDS.
Jadi meskipun pada akhirnya keduanya bermuara ke layer settlement yang sama, rangkaian yang dilalui di tengah benar-benar berbeda.
Menurut saya perbedaan ini penting.
Kalau sudah ada produk berbasis Solidity dan ingin meminimalkan perubahan kode saat pindah, maka DuskEVM sangat masuk akal—tooling dan kebiasaan pengembangan pada dasarnya sudah familiar.
Tapi jika aplikasi memang harus bersentuhan langsung dengan L1, atau perlu memakai kemampuan eksekusi native Dusk serta logika tingkat protokol, maka memaksa melewati layer EVM belum tentu perlu.
Jadi sekarang saya sudah tidak terlalu memikirkan mana yang “lebih tinggi” antara DuskEVM dan DuskVM.
Lebih mirip dua jalur.
Satu jalur untuk memudahkan developer EVM yang sudah ada agar masuk.
Jalur lainnya disediakan bagi mereka yang memang sejak awal ingin langsung menggunakan kemampuan Dusk-native.
Pada akhirnya keduanya bisa terhubung ke DuskDS, tapi execution path-nya bukan hal yang sama.
Ini juga bagian yang menurut saya membuat arsitektur Dusk lebih layak diteliti dibanding sekadar “L1 lain yang kompatibel dengan EVM”.
Dalam beberapa hari ini, saya membaca ulang dokumen arsitektur @Dusk , dan ada satu hal yang ternyata sebelumnya saya anggap terlalu sederhana.
Pada akhirnya, DuskEVM juga akan kembali ke settlement DuskDS. Lalu, kenapa tetap perlu mempertahankan DuskVM secara terpisah?
Awalnya saya mengira ini hanya karena bahasa pengembangnya berbeda: yang satu Solidity, yang satu Rust/WASM.
Tapi setelah dibaca lebih lanjut, ternyata perbedaannya ada pada execution path.
DuskVM dijalankan langsung di L1.
Sedangkan DuskEVM tidak. Transaksinya dulu melewati sequencer, lalu dieksekusi di layer EVM. Setelah itu masih ada batch, state commitment, kemudian baru disambungkan kembali ke DuskDS.
Jadi meskipun pada akhirnya keduanya bermuara ke layer settlement yang sama, rangkaian yang dilalui di tengah benar-benar berbeda.
Menurut saya perbedaan ini penting.
Kalau sudah ada produk berbasis Solidity dan ingin meminimalkan perubahan kode saat pindah, maka DuskEVM sangat masuk akal—tooling dan kebiasaan pengembangan pada dasarnya sudah familiar.
Tapi jika aplikasi memang harus bersentuhan langsung dengan L1, atau perlu memakai kemampuan eksekusi native Dusk serta logika tingkat protokol, maka memaksa melewati layer EVM belum tentu perlu.
Jadi sekarang saya sudah tidak terlalu memikirkan mana yang “lebih tinggi” antara DuskEVM dan DuskVM.
Lebih mirip dua jalur.
Satu jalur untuk memudahkan developer EVM yang sudah ada agar masuk.
Jalur lainnya disediakan bagi mereka yang memang sejak awal ingin langsung menggunakan kemampuan Dusk-native.
Pada akhirnya keduanya bisa terhubung ke DuskDS, tapi execution path-nya bukan hal yang sama.
Ini juga bagian yang menurut saya membuat arsitektur Dusk lebih layak diteliti dibanding sekadar “L1 lain yang kompatibel dengan EVM”.