私はDuskVMとDuskEVMは、基本的に同じものを作るための2つの方法だと思っていました。
でも実際の開発者向けの道筋を少し調べてみると、そうでもないようです。
DuskVMを通して構築するなら、ネイティブの@Dusk sideにかなり近づきます。コントラクトはRustで書かれ、WASMにコンパイルされて、L1上で直接実行されます。そうすることで、Dusk自身のトランザクションモデルや、より低レベルのプライバシー／ZK機能にアクセスできます。
DuskEVMは、まさにその反対のトレードオフに感じます。
Solidity、Foundry、Hardhat、通常のEVMウォレットが使えます。つまり、すでにEthereum開発者が知っているツール一式です。ですが、実行の最終的な決済はDuskDS経由に戻ります。
私の中で腑に落ちたのは、より良いVMを選ばせようとしているわけではないことです。
「アプリが実際に何を必要としているのか」を問うているんだと。
もしL1を直接コントロールしたい、ネイティブなプライバシーのロジックが必要、あるいはプロトコルレベルの実行が必要なら、DuskVMのほうが理にかなっています。
一方で、すでにEVMアプリがあって、Duskスタックに馴染みのある形で入りたいだけなら、Rustへの書き換えを強制するのは不必要な摩擦になります。
なので最初は、2つの実行環境が重複しているように見えました。
でも今は、Duskが「開発者の互換性」と「ネイティブなコントロール」が互いに競合しないようにしようとしているように感じます。
同じエコシステムで、エントリポイントがまったく違う。
興味があるのは、アプリが増えて移行が始まったとき、どちらの側を開発者が実際に選ぶのかです。

$DUSK #dusk