#dusk Saat pertama kali saya melihat arsitektur pengembang Dusk, jujur saja saya bertanya-tanya mengapa arsitektur itu perlu memiliki dua lingkungan smart contract. Pikiran pertama saya sederhana: bukankah satu saja sudah cukup?
Setelah melihat lebih dekat, saya menyadari bahwa keduanya memecahkan dua masalah pengembang yang berbeda.
DuskEVM adalah jalur yang sudah familiar. Solidity dan tooling yang kompatibel dengan EVM memudahkan pengembang yang sudah memahami ekosistem Ethereum.
DuskVM adalah tempat arsitekturnya mulai terasa lebih masuk akal bagi saya. Kontrak Rust/WASM berjalan langsung di Dusk L1, memberi pengembang cara yang lebih alami untuk bekerja dengan kapabilitas spesifik Dusk, termasuk model transaksinya, privasi, dan fungsionalitas zero knowledge.
Jadi saya tidak melihat DuskEVM dan DuskVM sebagai lingkungan yang saling bersaing.
Saya memandangnya sebagai dua pintu masuk yang berbeda.
Jika saya ingin kompatibilitas dan tooling yang familiar, EVM adalah pilihan yang masuk akal. Jika sebuah aplikasi membutuhkan akses yang lebih dalam terhadap apa yang bisa disediakan oleh L1 milik Dusk sendiri, DuskVM tampaknya menjadi pilihan yang lebih alami.
Itu mengubah cara saya memandang arsitekturnya.
Dusk tidak sekadar berkata, “kami mendukung EVM.” Dusk memberikan fleksibilitas di lapisan eksekusi, sementara DuskDS tetap berada di bawahnya sebagai fondasi untuk settlement dan ketersediaan data.
Bagi saya, bagian desain yang lebih menarik adalah: cara yang berbeda untuk membangun, tanpa memaksa setiap aplikasi masuk ke model eksekusi yang sama.
$DUSK @Dusk
Setelah melihat lebih dekat, saya menyadari bahwa keduanya memecahkan dua masalah pengembang yang berbeda.
DuskEVM adalah jalur yang sudah familiar. Solidity dan tooling yang kompatibel dengan EVM memudahkan pengembang yang sudah memahami ekosistem Ethereum.
DuskVM adalah tempat arsitekturnya mulai terasa lebih masuk akal bagi saya. Kontrak Rust/WASM berjalan langsung di Dusk L1, memberi pengembang cara yang lebih alami untuk bekerja dengan kapabilitas spesifik Dusk, termasuk model transaksinya, privasi, dan fungsionalitas zero knowledge.
Jadi saya tidak melihat DuskEVM dan DuskVM sebagai lingkungan yang saling bersaing.
Saya memandangnya sebagai dua pintu masuk yang berbeda.
Jika saya ingin kompatibilitas dan tooling yang familiar, EVM adalah pilihan yang masuk akal. Jika sebuah aplikasi membutuhkan akses yang lebih dalam terhadap apa yang bisa disediakan oleh L1 milik Dusk sendiri, DuskVM tampaknya menjadi pilihan yang lebih alami.
Itu mengubah cara saya memandang arsitekturnya.
Dusk tidak sekadar berkata, “kami mendukung EVM.” Dusk memberikan fleksibilitas di lapisan eksekusi, sementara DuskDS tetap berada di bawahnya sebagai fondasi untuk settlement dan ketersediaan data.
Bagi saya, bagian desain yang lebih menarik adalah: cara yang berbeda untuk membangun, tanpa memaksa setiap aplikasi masuk ke model eksekusi yang sama.
$DUSK @Dusk