昨晩 Dusk のドキュメントを読んで初めて、自分がずっと「EVM対応」をあまりに雑に理解していたと気づきました。Dusk は契約をすべて 1 台の仮想マシンに詰め込んでいるわけではありません。Solidity と Foundry に慣れた開発は DuskEVM を使えます。<c-1/> @Dusk DUSK で Gas を支払い、バッチデータと状態のコミットは DuskDS に任せて決済します。ネイティブなプライバシーやゼロ知識の機能、またはプロトコルレベルの資産管理を扱う契約なら、Rust/WASM を使って DuskVM 上で直接実行します。

私はそれを、同じ取引機関が開設した 2 つのオペレーションデスクだと捉えました。1 つは馴染みのあるボタンがそのまま使え、移行が速い。もう 1 つは基盤に近い「金庫」のようなもので、よりネイティブなルールを呼び出せる。最後には、どちらも同じ決済基盤が台帳を確認します。「EVM 互換」という 4 つの言葉よりも、この選択のほうが重要です。開発効率とネイティブ機能を分けて考えられるからです。

ただし、双方向のルートはブリッジングやレイヤーをまたぐ連携の複雑さも増やし、状態の正確な判断も必要になります。公式ドキュメントは明確に、DuskEVM の高速なパッケージングは DuskDS での決済が完了したことを意味しない、と注意しています。ページ上の表示が成功になっただけで「最終的に完了した」とは判断しません。以後は、レイヤー間の体験がスムーズか、ツールが成熟しているか、実際の契約量が増えているかを見ます。アーキテクチャは選択肢を与えてくれますが、採用することで答えが出るのです。

#dusk $DUSK