#dusk $DUSK @Dusk
Saya menelusuri bagaimana DuskVM dan DuskEVM benar-benar membagi tugas di Dusk, karena keduanya menjalankan kontrak tetapi jelas tidak bisa saling menggantikan.
DuskVM menjalankan kontrak Rust/WASM, yang dibangun di atas Wasmtime, langsung di L1 Dusk. ini adalah jalur yang dibangun untuk kontrak yang memerlukan akses langsung ke model transaksi Dusk sendiri, fitur privasi, atau kemampuan zero-knowledge — fungsi host yang ramah ZK dari Piecrust (PLONK, Groth16, BLS) ada di sini secara khusus.
DuskEVM berjalan di tempat yang sama sekali berbeda. ini adalah lingkungan ekuivalen EVM berbasis OP Stack — ID chain testnet dikonfirmasi sebagai 745 di dokumentasi resmi Dusk — yang memungkinkan pengembang menerapkan kontrak Solidity standar menggunakan MetaMask, Hardhat, atau Foundry, sambil menyelesaikan dan mempublikasikan data kembali melalui DuskDS sebagai blob, melalui sequencer dan batcher, bukan menjalankan semuanya secara independen.
Saya mengisolasi apa yang membedakan keduanya, bukan sekadar bahasa. kontrak DuskVM memperoleh privasi dan primitif ZK secara native, di lapisan eksekusi. kontrak DuskEVM memperoleh kompatibilitas penuh dengan alat (tooling) dan pengguna membayar gas dengan DUSK di sana juga, tetapi dialurkan melalui lapisan yang menyelesaikan di tempat lain, bukan berjalan native berdampingan dengan model transaksi bawaan Dusk.
keduanya diselesaikan melalui basis yang sama — DuskDS — dan pada akhirnya keduanya membayar gas dalam DUSK. tidak ada yang menggantikan yang lain; masing-masing ada karena yang satu memang tidak bisa mengerjakan tugas spesifiknya dengan baik.
jadi pilihan nyata bagi seorang pembangun bukanlah "yang mana lebih baik". melainkan apakah kontraknya membutuhkan eksekusi yang privasi-native atau tooling EVM yang familiar dan bisa diverifikasi berdasarkan chain ID — dan Dusk membangun dua jalur terpisah, bukan memaksa satu lingkungan untuk melakukan keduanya.
apakah pemeliharaan dua lingkungan eksekusi yang benar-benar terpisah lebih baik bagi para builder daripada memilih satu dan mengoptimalkannya sepenuhnya?
Saya menelusuri bagaimana DuskVM dan DuskEVM benar-benar membagi tugas di Dusk, karena keduanya menjalankan kontrak tetapi jelas tidak bisa saling menggantikan.
DuskVM menjalankan kontrak Rust/WASM, yang dibangun di atas Wasmtime, langsung di L1 Dusk. ini adalah jalur yang dibangun untuk kontrak yang memerlukan akses langsung ke model transaksi Dusk sendiri, fitur privasi, atau kemampuan zero-knowledge — fungsi host yang ramah ZK dari Piecrust (PLONK, Groth16, BLS) ada di sini secara khusus.
DuskEVM berjalan di tempat yang sama sekali berbeda. ini adalah lingkungan ekuivalen EVM berbasis OP Stack — ID chain testnet dikonfirmasi sebagai 745 di dokumentasi resmi Dusk — yang memungkinkan pengembang menerapkan kontrak Solidity standar menggunakan MetaMask, Hardhat, atau Foundry, sambil menyelesaikan dan mempublikasikan data kembali melalui DuskDS sebagai blob, melalui sequencer dan batcher, bukan menjalankan semuanya secara independen.
Saya mengisolasi apa yang membedakan keduanya, bukan sekadar bahasa. kontrak DuskVM memperoleh privasi dan primitif ZK secara native, di lapisan eksekusi. kontrak DuskEVM memperoleh kompatibilitas penuh dengan alat (tooling) dan pengguna membayar gas dengan DUSK di sana juga, tetapi dialurkan melalui lapisan yang menyelesaikan di tempat lain, bukan berjalan native berdampingan dengan model transaksi bawaan Dusk.
keduanya diselesaikan melalui basis yang sama — DuskDS — dan pada akhirnya keduanya membayar gas dalam DUSK. tidak ada yang menggantikan yang lain; masing-masing ada karena yang satu memang tidak bisa mengerjakan tugas spesifiknya dengan baik.
jadi pilihan nyata bagi seorang pembangun bukanlah "yang mana lebih baik". melainkan apakah kontraknya membutuhkan eksekusi yang privasi-native atau tooling EVM yang familiar dan bisa diverifikasi berdasarkan chain ID — dan Dusk membangun dua jalur terpisah, bukan memaksa satu lingkungan untuk melakukan keduanya.
apakah pemeliharaan dua lingkungan eksekusi yang benar-benar terpisah lebih baik bagi para builder daripada memilih satu dan mengoptimalkannya sepenuhnya?
