昨晚翻完@Dusk 的架构文档，一个矛盾始终绕不过去：二つの実行経路が併存するのは、「両頭をなだめる」形なのか、それとも役割分担が明確なのか？

公式ドキュメントの位置づけはとても明確だ。DuskDSは決済とデータ可用性レイヤーとして機能し、その上にDuskが2つのスマートコントラクト経路を提供する。DuskVM（旧名Piecrust）はRust/WASMコントラクトを実行し、Dusk L1上で直接処理する。DuskEVMはOP Stackに基づくEVMの同等実行環境で、DuskDSによって決済とデータ可用性を担保する。

この2つのシステムの分工は、重複するための作り直しではない。

DuskVMはプロトコルレベルの業務を対象としている。Phoenix/Moonlightの2つの取引モデルにおけるプライバシー決済ロジックを担い、EVMバイトコードではなくWASMにコンパイルされたコントラクトを扱うため、ゼロ知識証明システムに自然に適合する。基盤となるプライバシー機能を呼び出す必要がある場合は、DuskVMを使う。

DuskEVMは「互換レイヤー」だ。Solidityに慣れた開発者はコードを再構築する必要がなく、HardhatやFoundryといった馴染みのツールをそのまま使える。MetaMaskウォレットもシームレスに接続できる。実行が完了すると、取引データはbatcherによってblob形式でDuskDSに送られ、最終的に記録（証跡化）される。

この分工自体は合理的だ。底層のプライバシーとコンプライアンスのロジックはネイティブ環境で動き、上層のEVM互換が流入（フローの入口）として機能する。役割はそれぞれきちんとある。しかし合理的であることと、検証済みであることは別だ。

肝心な問題はこうだ。2種類の環境にはそれぞれどれくらいのアプリケーションがデプロイされているのか？ 公開情報によれば、DuskEVMのテストネット上では17のDeFiプロジェクトがデプロイされている。しかし、DuskVMのネイティブ環境におけるアプリ数、比率、タイプについては、現時点で明確な集計データが見当たらない。アプリの分布データがない以上、「分工合理」はアーキテクチャ設計のレベルにとどまっている。アーキテクチャのロジックは推論できるが、生態系の成果はデータでしか答えられない。
#dusk $DUSK