Pertama kali melihat diagram arsitektur DUSK, saya punya pertanyaan: mengapa perlu dua mesin virtual? DuskVM menjalankan smart contract native, sementara DuskEVM menjalankan kontrak yang kompatibel dengan Ethereum—bukankah ini menambah kompleksitas? Namun setelah saya meneliti lebih dalam, saya menemukan bahwa desain ini sebenarnya dibuat untuk memecahkan masalah yang sangat nyata: trade-off antara keamanan dan performa.
DuskVM adalah mesin virtual native DUSK; ia berjalan langsung di atas lapisan konsensus, sehingga dapat mengakses semua fungsi dasar, seperti proof nol pengetahuan, transaksi privat, protokol Phoenix, dan lainnya. Sementara itu, DuskEVM dibangun berdasarkan OP Stack. Ia mengeksekusi smart contract ala Ethereum, tetapi akhirnya penyelesaian (settlement) dilakukan oleh DuskDS. Perbedaan kunci yang perlu dipahami adalah: kontrak di DuskVM terikat erat dengan keamanan konsensus DUSK, sedangkan kontrak di DuskEVM bergantung pada lapisan penghubung (bridging) di luar.
Dari sini muncul pembagian peran yang menarik: aset sensitif (misalnya token RWA, aset yang memerlukan kepatuhan) sebaiknya ditempatkan di DuskVM, karena mereka perlu memanfaatkan langsung fitur privasi dan kepatuhan milik DUSK. Sedangkan aplikasi DeFi biasa (misalnya exchange terdesentralisasi, protokol pinjam-meminjam) dapat ditempatkan di DuskEVM, karena pengembang hanya perlu memindahkan kode Ethereum yang sudah ada—menghindari kerumitan untuk menulis ulang kontrak.
Saya juga mencari umpan balik dari pengembang: saat deploy Uniswap V2 clone di DuskEVM, cukup memodifikasi sekitar 20 baris kode (terutama untuk menyesuaikan parameter jaringan). Namun jika ingin mengembangkan dari nol di DuskVM, dibutuhkan ratusan baris kode. Meski begitu, transaksi di DuskVM lebih cepat (rata-rata 1,5 detik per blok) dan tidak perlu membayar biaya bridging. Jadi, pada dasarnya ini adalah pilihan antara efisiensi pengembangan vs performa.
Poin lain yang patut diperhatikan adalah isolasi keamanan. Data DuskVM dan DuskEVM dipisahkan secara fisik, sehingga kontrak di DuskEVM tidak dapat mengakses status privasi yang ada di DuskVM. Ini mencegah skenario seperti “flash loan attack” yang memanfaatkan celah lintas-lapisan.
Dalam audit keamanan resmi DUSK pada September 2025, mereka memfokuskan pengujian pada panggilan lintas-VM. Hasilnya, semua panggilan harus melewati sebuah “sandbox gateway”. Gateway ini memeriksa hak akses dan tipe pemanggil, sehingga mencegah penetrasi kode berbahaya. $BTC
Namun saya rasa arsitektur ganda seperti ini tetap memiliki potensi risiko: jika logika bridging di antara dua VM mengalami celah, ia bisa dieksploitasi. Misalnya, penyerang bisa memalsukan pemanggilan kontrak DuskEVM untuk menghabiskan sumber daya di DuskVM.
#dusk @Dusk $DUSK