昨晚 Dusk のドキュメントを読んで初めて、自分がずっと「EVM 対応」をあまりにも雑に理解していたことに気づきました。Dusk は契約を 1 台の仮想マシンに全部押し込んでいるわけではありません。Solidity と Foundry に馴染みのある開発なら DuskEVM で動かせます。Gas は DUSK で支払い、バッチデータと状態のコミットメントは DuskDS に渡して決済します。一方で、ネイティブなプライバシーやゼロ知識の機能、あるいはプロトコルレベルでの資産コントロールが必要な契約は、Rust/WASM を使って DuskVM 上で直接実行します。

私はこれを、同じ取引機関が開いた 2 つのオペレーションデスクのように理解しました。1 つは馴染みのあるボタンを残していて移行が速い。もう 1 つはより底層の金庫に近く、よりネイティブなルールを呼び出せて、最終的には同じ清算ベースが台帳を確認します。この取捨選択は「EVM 互換」という 4 文字よりもずっと重要です。開発効率とネイティブ機能を切り分けるからです。

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

@Dusk $DUSK #dusk