#dusk $DUSK

ここ数日、@Dusk の DuskEVM ドキュメントを読んでいて、以前自分が見落としていた細部に気づきました：

DuskEVM でトランザクションがパッケージング（ブロックに含まれる）されても、その取引がすでに完了したことを意味しません。

このアーキテクチャでは、DuskEVM と DuskDS は別の仕事をしています。

Solidity コントラクトはまず DuskEVM で実行され、トランザクションは sequencer に送られて L2 ブロックに組み込まれます。その後、batcher がトランザクションデータを DuskDS に提出し、状態は commitment や fault proof といった仕組みによってさらに下流で確認されます。

最終的に settlement（決済）や data availability（データ可用性）を担うのは DuskDS です。

そのため、今の理解では、私は DuskEVM を単純に「Dusk に EVM を足したもの」とは捉えないようになりました。

より正確にはこうです：

DuskEVM が実行を担当し、DuskDS が最終的に“有効かどうか”を決める。

これが、公式ドキュメントで transaction inclusion（取引の包含）と settlement をわざわざ区別している理由にもつながります。

さらに、現在のテストネットの withdrawal（出金）プロセスでも、この設計思想を確認できます：まず DuskEVM で initiate し、次に Dusk L1 で prove し、最後に finalize する。L2 側で成功が表示された時点で完全に終了ではありません。

この違いは一般的な送金だとそれほど“魅力的”に感じないかもしれませんが、金融のシーンに置くと、むしろ重要だと思います。

証券や投信などを本当にオンチェーンにするなら、皆が最後に気にするのは「取引が速いかどうか」だけではなく、もっと実務的な問題として：

この状態の最終性は、いったいどのレイヤーで得られるのか？

なので次は DuskEVM mainnet を見ていきます。性能や Solidity 互換性だけでなく、execution から DuskDS settlement までのこのチェーンの流れが、実際にどんな挙動になるのかを確かめたいです。

少なくとも、アーキテクチャ上の役割分担については、今は理解できた気がしています。