#dusk $DUSK @Dusk
私は、DuskVMとDuskEVMが実際にDusk上でどのように役割分担しているかを追跡した。どちらもコントラクトを実行するが、明らかに互換ではない。
DuskVMはRust/WASMのコントラクトを、Wasmtimeを基盤としてDuskのL1上で直接実行する。これは、Dusk自身のトランザクションモデルへの直接アクセス、プライバシー機能、またはゼロ知識機能が必要なコントラクトのために作られた道筋だ。PiecrustのZKに親和的なホスト関数（PLONK、Groth16、BLS）はここに特化して配置されている。
DuskEVMは、まったく別の場所で動作する。OP Stackベースの、EVM相当の環境であり、Dusk自身のドキュメントではテストネットのチェーンIDが745であることが確認できる。これにより、MetaMask、Hardhat、Foundryを使って標準のSolidityコントラクトをデプロイできる一方で、データの決済と公開はDuskDSを介してブロブとして行う。ここでは、Dusk上で個別に動作するのではなく、シーケンサーとバッチャーを通じて処理される。
私は、それらを言語だけではない“別物”として隔てているものを切り分けた。DuskVMのコントラクトは、実行層でネイティブにプライバシーとZKプリミティブを得る。DuskEVMのコントラクトは、完全なツール互換性があり、ユーザーはそこでもDUSKでガスを支払うが、Dusk自身のトランザクションモデルと並行してネイティブに走るのではなく、別の場所で決済するレイヤー経由でルーティングされる。
どちらも同じベースで決済する──DuskDS。そして最終的にどちらもDUSKでガスを支払う。どちらかがもう一方を置き換えるわけではない。各々は、もう一方がその固有の役割をきちんとカバーできないからこそ存在する。
つまり、ビルダーにとって本当の選択は「どちらが優れているか」ではない。コントラクトに、プライバシーにネイティブな実行が必要なのか、それとも馴染みのある、チェーンIDで検証可能なEVMツールが必要なのかだ。そしてDuskは、一つの環境に両方を無理にやらせるのではなく、2つの別レーンを分けて用意した。
2つの実行環境を本当に別々に維持することは、1つを選んでそれを最大限最適化するよりもビルダーにとって有益なのだろうか？
私は、DuskVMとDuskEVMが実際にDusk上でどのように役割分担しているかを追跡した。どちらもコントラクトを実行するが、明らかに互換ではない。
DuskVMはRust/WASMのコントラクトを、Wasmtimeを基盤としてDuskのL1上で直接実行する。これは、Dusk自身のトランザクションモデルへの直接アクセス、プライバシー機能、またはゼロ知識機能が必要なコントラクトのために作られた道筋だ。PiecrustのZKに親和的なホスト関数（PLONK、Groth16、BLS）はここに特化して配置されている。
DuskEVMは、まったく別の場所で動作する。OP Stackベースの、EVM相当の環境であり、Dusk自身のドキュメントではテストネットのチェーンIDが745であることが確認できる。これにより、MetaMask、Hardhat、Foundryを使って標準のSolidityコントラクトをデプロイできる一方で、データの決済と公開はDuskDSを介してブロブとして行う。ここでは、Dusk上で個別に動作するのではなく、シーケンサーとバッチャーを通じて処理される。
私は、それらを言語だけではない“別物”として隔てているものを切り分けた。DuskVMのコントラクトは、実行層でネイティブにプライバシーとZKプリミティブを得る。DuskEVMのコントラクトは、完全なツール互換性があり、ユーザーはそこでもDUSKでガスを支払うが、Dusk自身のトランザクションモデルと並行してネイティブに走るのではなく、別の場所で決済するレイヤー経由でルーティングされる。
どちらも同じベースで決済する──DuskDS。そして最終的にどちらもDUSKでガスを支払う。どちらかがもう一方を置き換えるわけではない。各々は、もう一方がその固有の役割をきちんとカバーできないからこそ存在する。
つまり、ビルダーにとって本当の選択は「どちらが優れているか」ではない。コントラクトに、プライバシーにネイティブな実行が必要なのか、それとも馴染みのある、チェーンIDで検証可能なEVMツールが必要なのかだ。そしてDuskは、一つの環境に両方を無理にやらせるのではなく、2つの別レーンを分けて用意した。
2つの実行環境を本当に別々に維持することは、1つを選んでそれを最大限最適化するよりもビルダーにとって有益なのだろうか？
