EVMサポートを追加することは、通常「互換性の勝利」として語られます。つまり、より多くのウォレット、より多くのツール、より多くのSolidity開発者です。しかし、その見方はより大きな建築上の問いを見えにくくします――開発者の馴染み具合が、金融システムの決済（どこで決済されるか）を左右すべきなのでしょうか？

Duskの現在のスタックは、これらの選択肢を分離しています。DuskEVMは、DuskDSによって決済されるEVM互換の実行を提供し、DuskVMはL1上でRust/WASMのコントラクトを直接実行します。DuskDSは、決済とデータ可用性の基盤として維持されます。つまり、EVM互換性はベースレイヤーの定義ではなく、実行オプションの位置づけなのです。

「Duskは2つのVMをサポートしている」というよりも、その示唆はもっと面白いものです。規制対象のアプリケーションは、決済レイヤーそのものをEVMの形に寄せる必要なく、馴染みのあるEVMツールチェーンを選べます。

一方で、Duskのトランザクションモデルに対する直接的なL1アクセス、プライバシーやゼロ知識機能を必要とするワークフローは、ネイティブのまま維持できます。

トレードオフは協調（コーディネーション）です。2つの実行経路は能力が同一にはならず、ビルダーは、どの保証を実行側に置くべきか、どれを決済にアンカー（固定）すべきかを引き続き判断しなければなりません。

つまり、真のモジュール性の試金石は「Duskがいくつの環境をサポートしているか」ではありません。基盤となる決済の前提が分断されることなく、実行を変えられるかどうか――そこにあります。

@Dusk_Foundation $DUSK #dusk $BTW $ROBO