#dusk $DUSK @Dusk Saya memperhatikan sesuatu yang pada awalnya tidak terlalu masuk akal.
Jika DUSK ingin para developer membangun aplikasi keuangan, mengapa membangun lingkungan eksekusi miliknya sendiri sementara EVM sudah ada?
Bayangkan membuka sebuah bengkel khusus di samping sebuah pabrik besar serba guna.
Pabrik itu bisa membuat hampir apa saja.
Tapi bengkel Anda dirancang untuk satu jenis pekerjaan tertentu.
Di situlah perbedaan yang saya temukan antara DuskVM dan DuskEVM.
DuskEVM memberi developer lingkungan Ethereum yang sudah familiar: Solidity, Vyper, alat bantu standar EVM, serta dompet.
Namun DuskVM mengambil jalur yang berbeda.
Ia menjalankan smart contract Rust/WASM secara langsung di Dusk L1, sehingga kontrak mendapat akses langsung ke model transaksi native Dusk, aset, privasi, dan kemampuan zero-knowledge.
Itulah yang membuat arsitekturnya terasa “nyambung” bagi saya.
DUSK tidak memaksa setiap aplikasi masuk ke satu model eksekusi.
Ia mempertahankan lingkungan yang familiar untuk kompatibilitas...
...sambil tetap menyediakan lingkungan native untuk aplikasi yang membutuhkan akses lebih dalam ke L1.
Dan ini penting karena aplikasi keuangan yang teregulasi tidak selalu berupa kontrak DeFi biasa.
Beberapa di antaranya membutuhkan primitive penyelesaian (settlement) dan privasi yang mendasarinya sendiri.
Jadi, mungkin pertanyaan yang menarik bukanlah:
“Kenapa DUSK punya dua VM?”
Melainkan:
“Bagaimana jika kompatibilitas dan spesialisasi diperlakukan sebagai dua masalah rekayasa yang berbeda?”
Trade-off itu memberi tahu saya banyak tentang apa sebenarnya yang DUSK sedang coba bangun.
#dusk $DUSK @Dusk
Jika DUSK ingin para developer membangun aplikasi keuangan, mengapa membangun lingkungan eksekusi miliknya sendiri sementara EVM sudah ada?
Bayangkan membuka sebuah bengkel khusus di samping sebuah pabrik besar serba guna.
Pabrik itu bisa membuat hampir apa saja.
Tapi bengkel Anda dirancang untuk satu jenis pekerjaan tertentu.
Di situlah perbedaan yang saya temukan antara DuskVM dan DuskEVM.
DuskEVM memberi developer lingkungan Ethereum yang sudah familiar: Solidity, Vyper, alat bantu standar EVM, serta dompet.
Namun DuskVM mengambil jalur yang berbeda.
Ia menjalankan smart contract Rust/WASM secara langsung di Dusk L1, sehingga kontrak mendapat akses langsung ke model transaksi native Dusk, aset, privasi, dan kemampuan zero-knowledge.
Itulah yang membuat arsitekturnya terasa “nyambung” bagi saya.
DUSK tidak memaksa setiap aplikasi masuk ke satu model eksekusi.
Ia mempertahankan lingkungan yang familiar untuk kompatibilitas...
...sambil tetap menyediakan lingkungan native untuk aplikasi yang membutuhkan akses lebih dalam ke L1.
Dan ini penting karena aplikasi keuangan yang teregulasi tidak selalu berupa kontrak DeFi biasa.
Beberapa di antaranya membutuhkan primitive penyelesaian (settlement) dan privasi yang mendasarinya sendiri.
Jadi, mungkin pertanyaan yang menarik bukanlah:
“Kenapa DUSK punya dua VM?”
Melainkan:
“Bagaimana jika kompatibilitas dan spesialisasi diperlakukan sebagai dua masalah rekayasa yang berbeda?”
Trade-off itu memberi tahu saya banyak tentang apa sebenarnya yang DUSK sedang coba bangun.
#dusk $DUSK @Dusk
