Saya mengira DuskVM dan DuskEVM pada dasarnya adalah dua cara untuk membangun hal yang sama.
Lalu saya meluangkan sedikit waktu untuk melihat jalur pengembangan yang sebenarnya dan ternyata tidak.
Kalau Anda membangun melalui DuskVM, Anda jauh lebih dekat dengan sisi native @Dusk side. Kontrak ditulis dalam Rust, dikompilasi ke WASM, dan dieksekusi langsung di L1. Itu memberi Anda akses ke model transaksi milik Dusk sendiri serta fitur privasi/ZK tingkat lebih rendah.
DuskEVM terasa seperti kebalikan dari pertukarannya.
Anda mendapatkan Solidity, Foundry, Hardhat, dan wallet EVM normal—pada dasarnya alat yang sudah dikenal oleh developer Ethereum. Tetapi eksekusinya tetap diselesaikan kembali melalui DuskDS.
Hal yang membuat saya paham adalah ini sebenarnya bukan meminta para pembangun memilih VM yang lebih baik.
Ini menanyakan apa kebutuhan aplikasi itu sebenarnya.
Kalau saya perlu kontrol langsung L1, logika privasi native, atau eksekusi level protokol, DuskVM lebih masuk akal.
Kalau saya sudah punya aplikasi EVM dan hanya ingin cara yang familiar untuk masuk ke stack Dusk, memaksa penulisan ulang ke Rust akan menjadi hambatan yang tidak perlu.
Jadi ya, dua lingkungan eksekusi terasa redundant bagi saya pada awalnya.
Sekarang rasanya seperti Dusk mencoba agar kompatibilitas developer dan kontrol native tidak saling bersaing.
Ekosistem yang sama, tetapi titik masuk yang sangat berbeda.
Saya penasaran sisi mana yang benar-benar akan dipilih para pembangun ketika lebih banyak aplikasi mulai bergerak.
$DUSK #dusk
Lalu saya meluangkan sedikit waktu untuk melihat jalur pengembangan yang sebenarnya dan ternyata tidak.
Kalau Anda membangun melalui DuskVM, Anda jauh lebih dekat dengan sisi native @Dusk side. Kontrak ditulis dalam Rust, dikompilasi ke WASM, dan dieksekusi langsung di L1. Itu memberi Anda akses ke model transaksi milik Dusk sendiri serta fitur privasi/ZK tingkat lebih rendah.
DuskEVM terasa seperti kebalikan dari pertukarannya.
Anda mendapatkan Solidity, Foundry, Hardhat, dan wallet EVM normal—pada dasarnya alat yang sudah dikenal oleh developer Ethereum. Tetapi eksekusinya tetap diselesaikan kembali melalui DuskDS.
Hal yang membuat saya paham adalah ini sebenarnya bukan meminta para pembangun memilih VM yang lebih baik.
Ini menanyakan apa kebutuhan aplikasi itu sebenarnya.
Kalau saya perlu kontrol langsung L1, logika privasi native, atau eksekusi level protokol, DuskVM lebih masuk akal.
Kalau saya sudah punya aplikasi EVM dan hanya ingin cara yang familiar untuk masuk ke stack Dusk, memaksa penulisan ulang ke Rust akan menjadi hambatan yang tidak perlu.
Jadi ya, dua lingkungan eksekusi terasa redundant bagi saya pada awalnya.
Sekarang rasanya seperti Dusk mencoba agar kompatibilitas developer dan kontrol native tidak saling bersaing.
Ekosistem yang sama, tetapi titik masuk yang sangat berbeda.
Saya penasaran sisi mana yang benar-benar akan dipilih para pembangun ketika lebih banyak aplikasi mulai bergerak.
$DUSK #dusk