Hal yang menangkap perhatian saya saat menggali DuskEVM bukanlah bagian EVM itu sendiri. Melainkan di mana eksekusi sebenarnya berada.
Saya menelusuri @DuskNetwork; dokumentasi yang ada saat ini menunjukkan DuskEVM memakai chain ID 744, dengan DUSK sebagai token gas native, sementara DuskDS menangani settlement dan ketersediaan data. Pemisahan itu terdengar rapi di atas kertas, tetapi mengubah cara saya memandang jaringan: lingkungan EVM tidak menggantikan lapisan dasar Dusk; ia justru berada di atasnya.
Yang membuat saya berhenti sejenak adalah aktivitas tata kelola OpenDusk yang baru-baru ini terjadi.
Pemungutan suara Agustus berkaitan dengan apakah reward blok yang dibakar harus mengalir ke perbendaharaan komunitas, sementara DuskEVM diposisikan sebagai lapisan aplikasi. Jadi ada kontras yang menarik di sini: tata kelola dan settlement tetap terikat pada DuskDS, sementara para pengembang mendapatkan lingkungan Solidity/EVM yang familiar di atasnya.
Awalnya saya mengira EVM di Dusk terutama berarti deployment yang lebih mudah. Setelah menelusuri arsitekturnya, saya jadi kurang yakin bahwa itu bagian yang paling penting.
Pertanyaan sebenarnya bagi saya adalah apakah pengembang benar-benar memanfaatkan pemisahan itu dalam praktik, atau apakah DuskEVM sebagian besar tetap menjadi lapisan kompatibilitas sementara aktivitas yang lebih mendalam tetap berada di DuskDS…
@Dusk $DUSK #dusk
Saya menelusuri @DuskNetwork; dokumentasi yang ada saat ini menunjukkan DuskEVM memakai chain ID 744, dengan DUSK sebagai token gas native, sementara DuskDS menangani settlement dan ketersediaan data. Pemisahan itu terdengar rapi di atas kertas, tetapi mengubah cara saya memandang jaringan: lingkungan EVM tidak menggantikan lapisan dasar Dusk; ia justru berada di atasnya.
Yang membuat saya berhenti sejenak adalah aktivitas tata kelola OpenDusk yang baru-baru ini terjadi.
Pemungutan suara Agustus berkaitan dengan apakah reward blok yang dibakar harus mengalir ke perbendaharaan komunitas, sementara DuskEVM diposisikan sebagai lapisan aplikasi. Jadi ada kontras yang menarik di sini: tata kelola dan settlement tetap terikat pada DuskDS, sementara para pengembang mendapatkan lingkungan Solidity/EVM yang familiar di atasnya.
Awalnya saya mengira EVM di Dusk terutama berarti deployment yang lebih mudah. Setelah menelusuri arsitekturnya, saya jadi kurang yakin bahwa itu bagian yang paling penting.
Pertanyaan sebenarnya bagi saya adalah apakah pengembang benar-benar memanfaatkan pemisahan itu dalam praktik, atau apakah DuskEVM sebagian besar tetap menjadi lapisan kompatibilitas sementara aktivitas yang lebih mendalam tetap berada di DuskDS…
@Dusk $DUSK #dusk
