DuskEVMで私が想定していなかったのはSolidity対応そのものではなく、DUSKがネイティブ層へ戻るときに何が起きるかです。

Dusk自身のテストネットガイドによると、DuskEVMからの出金には3つの別々のオンチェーン操作が必要です。DuskEVMで開始し、Dusk L1で証明を行い、その後Dusk L1で確定します。さらに、証明トランザクションと確定トランザクションの両方の支払いに足りるだけの、L1上の非シールドDUSKもユーザー側で用意する必要があります。出金の準備が整っているかは、単純なタイマーではなく、公開されているネットワーク状態、証明の成熟度、そしてディスピュート・ゲームのチェックによって決まります。

それで二度見しました。というのも「EVM互換」と聞くと、デフォルトで体験全体が馴染みあるものになるように聞こえるからです。しかし実際には、ブリッジがより深いアーキテクチャを露わにしています。DuskEVMは、DuskDSを通じて決済し、データを公開するEVM実行環境であり、DuskのネイティブなRust/WASMコントラクトと同じ実行レイヤーではありません。

だからといって、その追加ステップを自動的に悪いものだとは捉えていません。ドキュメントでは、準備完了を証明の成熟度とディスピュート・ゲームのチェックに紐づけているので、摩擦は少なくともセキュリティモデルと結びついています。とはいえ、これは$DUSK にとって本当のプロダクト上の問いを生みます。つまり、生産環境のアプリは、この「証明/確定」のフローをうまく抽象化し、ユーザーがクロスレイヤーの複雑さを意識することなくセキュリティ上のメリットを得られるのでしょうか？

別のデプロイのデモを見て終わりよりも、こっちを注視するほうが重要に思えます。

@Dusk_Foundation $DUSK #dusk