もう一度Duskのアーキテクチャを読んでいて、「なぜ決済（セトルメント）が実行（エグゼキューション）とは別の仕事として扱われるのか」という点に引っかかりました。

DuskDSはL1の決済およびデータ可用性の基盤です。コンセンサスと最終性を扱い、DuskVMはL1上でRust/WASMのコントラクトを直接実行します。一方でDuskEVMは別ルートを取り、SolidityとEVMツール群を提供しつつ、決済とデータ可用性にはDuskDSを使います。

その分離は、「実行」をトランザクション全体だと思うのをやめたときに、より理にかなって見えてきます。

コントラクトは、どうなるべきかを計算できます。それでも、その結果の状態が共有チェーンの一部になり、最終性に到達したことを誰かが確立しなければなりません。Duskは、責務をそれぞれ別に保ちながら、それらが独立した“宙に浮く”システムにならないようにしています。

これは特に金融インフラに関して重要に思えます。アプリケーションは馴染みのあるEVM実行が必要になるかもしれませんが、その土台となる決済レイヤーは、ワークフローが依存するコンセンサスと最終性をやはり提供しなければなりません。DuskEVMは、決済がどこから来るかを変えずに、実行環境だけを変更できます。

ただ、まだ完全には納得しきれていない部分もあります。アーキテクチャ上は分離がきれいに見える一方で、実行パスとDuskDSは結局“ひとつのシステム”として動く必要があります。モジュール性が上がるからといって、協調（コーディネーション）が減るわけではありません。

そして、持続的な負荷の下で実務上の制約が最初にどこに現れるのかを判断するには、まだ十分な公開ベンチマークデータが見えていません。

大きな主張をする前に、まず一つ測ってみたいです。DuskEVMの実行が強く押し込まれたとき、そのワークロードはDuskDSにおける決済と最終性のレイテンシに実際どのように影響するのでしょうか。

#dusk $DUSK @Dusk $PORTAL $GPS