ここ数日で @Dusk の Core Components を描き直して、DuskVM、DuskEVM、DuskDS という 3 つの名前をようやく分けられました。最初は「1つのチェーンで2種類の仮想マシンに対応しているだけ」だと思っていましたが、実際の分担はもっと三層に近いです。DuskDS がコンセンサス、最終性、データの可用性を担当し、DuskVM は Rust/WASM のコントラクトを L1 上でそのまま動かします。DuskEVM は OP Stack に基づく EVM と同等の実行環境で、決済とデータの公開は DuskDS に任せます。

つまり、開発者は無条件に二択を迫られるわけではありません。既存の Solidity コントラクトがあり、EVM ウォレットやツールチェーンに依存しているなら、DuskEVM を選ぶほうがコストが低く済みます。一方で L1 資産に直接触れることや、Phoenix のプライバシーモデル、ゼロ知識の能力、あるいはより低レイヤのプロトコル制御が必要なら、DuskVM がネイティブな入口です。2 つのルートは決済の基盤を共有していますが、機能やセキュリティの前提が完全に同じというわけではありません。

私は「EVM compatible＝エコシステムが自動的に丸ごと移ってくる」という主張にやや警戒的です。互換性はデプロイのハードルを下げるだけで、ウォレット接続、安定した RPC、インデクサ、流動性、そして実際のユーザーを置き換えることはできません。逆に、ネイティブな Rust/ZK だけを強調しても十分ではありません。ツールが硬すぎて、開発者は技術的な純度のためにプロダクト全体を書き換えようとはしないでしょう。

だから私は $DUSK の技術進展を、指標を分解して見ています。DuskEVM にサードパーティの Solidity アプリはあるのか、DuskVM に非公式のコントラクトはあるのか。両者が DuskDS へ決済する経路は安定しているのか。#dusk の堀が成立しているなら、それは「使い慣れたツールで入ってこられ、プライバシーが必要なときには下へ進める」ということであって、3 つの新しい名前を同時に積み上げる話ではないはずです。あなたたちはまず互換性を選びますか、それともネイティブ能力を選びますか？