ウォレットに「成功」と表示されても、必ずしもそのお金があなたのものになるとは限りません。

昨日 DuskEVM の取引フローを見ていて、直感に反する細部に引っかかりました：
取引がブロックに取り込まれたからといって、それで「確定」したわけではないのです。

チェーン上の多くの人は、この2つを同じことだと思っています。
ウォレットが「成功」と跳ねると、すぐにお金は自分のものになった気がする。
でも DuskEVM の取引には、実は人生が2段階あります。

第一段階は「包含（inclusion）」です。取引は sequencer に送られ、L2 のブロックにパッケージされます。
速い。数秒で終わる。ただしこの段階は、あくまで「順番待ちに並んだ」だけ。

第二段階は「結算（settlement）」です。batcher が取引データを DuskDS に送信し、
状態コミットメントとフォールト・プルーフがコンセンサス層にアンカーされます。
こここそが“鉄板”の確定です。

公式ドキュメントの原文は今でも印象に残っています：
取引の包含は速いが、包含と結算は別の段階だ、と。

速いのと確かなのがあり、そのあいだに「入金したように見えるけど、まだそうじゃない」時間が挟まります。

この設計のいちばん直感に反する点は、「どれくらい待てば確定とみなすか」という判断権をユーザーから奪い取っているところです。
ビットコインの世界でよく語られる雑なやり方はこうです：
「1 回確認されたらコーヒーを買う」「6 回確認されたら代金を受け取る」。
これは商人が確率で経験的に編み出したもので、チェーン自体は何も約束しません。

Dusk はこの“雑さ”をプロトコルに取り込みました。
包含は包含、結算は結算――段階がはっきり分かれています。

代償として、少しだけ「なめらかさ（シームレス感）」を犠牲にします。その代わりに手に入るのは確実性です。
金融アプリが最も恐れるのは、遅いことではなく「入金したと思ってしまう」こと。
大口の機関レベルの送金で、アプリ側が「何秒経ったか」で最終性を推測してしまい、
事故が起きたら問題は手数料ではなく、清算責任の問題になります。

だから公式ドキュメントは、開発者向けに明確に注意しています：
層をまたいで資産を転送する場合は、プロトコルの状態、またはウォレットの状態を見て、時間で結算を推測してはいけない。

この設計は全くセクシーではなく、むしろ少しややこしいです。
ですが規制対象の資金が求めるのはスピード感ではなく、
1つ1つが確実に「読み終わり（処理完了）」になっていくこと。

機関がチェーンに載せるとき、本当に恐いのは結局のところ、
結算が遅いことなのか、それとも結算が「完了したように見えて」しまうことなのか。
#dusk $DUSK @Dusk