今朝、duskevm のトランザクションが実際にどのようにシステムを通っていくのかを詳しく見てたんだけど、正直さ。ブロックに入ってきたら見届けたことになると思ってたのに、どうやらそれはちょっと違った。

つまり、duskevm は dusk 上の EVM 互換レイヤーで、solidity を書いて、普通の EVM ウォレットや foundry / hardhat みたいな標準ツールを使い、ガスは dusk で支払います。けど、トランザクションは duskevm の中だけで生まれて死ぬわけじゃない。ロールアップ方式のライフサイクルを経るんだ。まず duskevm の sequencer に提出され、次に比較的早めに L2 ブロックに取り込まれる。さらにバッチャーがトランザクションデータを duskds に公開する。duskds は実際の決済とデータ可用性レイヤー。そこで、状態コミットメントやフォールトプルーフが、結果として得られた状態を duskds にちゃんと接続する。だから「L2 ブロックのどこかに置かれたまま」ではなく、実際に決済される。

ずっと引っかかってるのは、ドキュメントの中に「取り込み（inclusion）と決済（settlement）は本当に別の段階だ」と明確に示されている一文なんだ。duskevm と dusk の L1 の間で価値を動かすアプリは、時間が経ったから最終でしょ、って決め打ちするんじゃなくて、プロトコルやウォレットのステータスを確認すべき、って。これは技術的な言い回しの話じゃなくて、ちゃんとした違い。

ただ、そのギャップが実務でどれくらいの長さになるのかをはっきり書いてある場所は見つけられてない。速い取り込みが即時決済を意味するわけではないのは分かる。でも、実際にどれくらい待てばいいのか—そのウィンドウは分からない。

それでも、設計の判断自体は納得できる。完全に別の EVM チェーンを独立して浮かせるんじゃなくて、duskevm は決済とデータ可用性のために duskds にアンカーされたままだから、ソリディティのフルな開発体験が得られる一方で、最終性（finality）に関する基盤レイヤーの保証は失わない。

正直、その取り込み〜決済のギャップが日常運用で無視できるほど小さいのか、それともビルダー側がちゃんと能動的に考慮する必要があるのか、分からない？
🤔

#dusk @Dusk $DUSK