私が初めてDUSKのアーキテクチャ図を見たときに抱いた疑問があります。なぜ仮想マシンが2つ必要なのでしょうか？DuskVMはネイティブ合約を実行し、DuskEVMはイーサリアム互換の合約を実行する。これって複雑さを増やしているだけではないでしょうか？しかし深掘りしてみると、この設計は実際には「安全性と性能のトレードオフ」という非常に現実的な課題を解決するためのものだと分かりました。
DuskVMはDUSKのネイティブ仮想マシンで、コンセンサス層の上で直接動作し、ゼロ知識証明、プライバシートランザクション、Phoenixプロトコルなどのあらゆる基盤機能にアクセスできます。一方、DuskEVMはOP Stackに基づいており、イーサリアムのスマートコントラクトを実行しますが、最終的な決済はDuskDSが行います。重要な違いは、DuskVMの合約はDUSKのコンセンサスのセキュリティと結び付いているのに対し、DuskEVMの合約は周辺のブリッジ層に依存している点です。
これにより、面白い役割分担が生まれます。機微な資産（例：RWAトークン、コンプライアンス資産）はDuskVMに置くべきです。これらはDUSKのプライバシーとコンプライアンス特性を直接活用する必要があるからです。逆に、一般的なDeFiアプリ（例：分散型取引所、貸借プロトコル）はDuskEVMに置くことができます。開発者は既存のイーサリアムコードを移植するだけでよく、合約を作り直す手間が省けます。
開発者のフィードバックを調べてみると、DuskEVM上でUniswap V2のクローンをデプロイするには、コードを約20行ほど修正するだけ（主にネットワークパラメータの調整）で済むそうです。一方、DuskVM上でゼロから開発するには数百行のコードが必要になります。それでも、DuskVM上の取引速度はより速く（平均1.5秒でブロック生成）、ブリッジの費用も不要です。つまり、これは「開発効率 vs 性能」という選択なのです。
もう一つ注目すべき点はセキュリティの分離です。DuskVMとDuskEVMのデータは物理的に分離されており、DuskEVMの合約はDuskVMのプライバシー状態に直接アクセスできません。これにより、「フラッシュローン攻撃」のような手法で、層をまたぐアクセス経由の脆弱性が悪用されるのを防げます。DUSK公式は2025年9月のセキュリティ監査で、VM間の呼び出し（クロスVM呼び出し）を重点的にテストし、すべての呼び出しが「サンドボックス・ゲートウェイ」を経由する必要があることを確認しました。このゲートウェイは、呼び出し元の権限と種類をチェックし、悪意のあるコードが侵入できないようにします。$BTC
ただ、こうした二重アーキテクチャにも潜在的なリスクはあります。2つのVM間のブリッジロジックに脆弱性があれば、悪用される可能性があります。たとえば、攻撃者がDuskEVMの合約呼び出しを偽造して、DuskVMのリソースを消費させることが考えられます。
#dusk @Dusk $DUSK