あるものがあるシステムから出ていけば、そのまま次のシステムに現れて、記録はその後に自動的に整っていくはずだと思い込んでしまうことがあります。たぶん多くのソフトウェアはそんなふうに動きます。転送をログに残して、必要なら後で残高を更新する。ところが、DUSKが実際にL1とDuskEVMの間をどう移動するのかを見ると、その経路は別の前提に基づいて組み立てられています。

入金側は一見すると普通です。決済レイヤーから送ると、しばらくして同じトークンがEVM側のネイティブガスとして現れます。ラップはありません。最初は、戻りもその逆のプロセスになるだけだと思いました。違います。DuskEVMで開始するものの、L1に戻ってからは別々のトランザクションで、改めて証明し最終化する必要があります。資産が別の請求（クレーム）になることはありません。最終的に完全に「ホーム」扱いにする前に、決済レイヤーが最終的な所有権を再度再主張する必要があるだけです。

その一連の流れこそが、モジュラー設計が抽象として止まらなくなるポイントです。実行は、それ自身のルールのもとで動かせます。決済が最後の判断を担います。3つ目の表現をでっち上げることを拒むことで、ブリッジの失敗の一種類を取り除いています。代償は、退出（エグジット）が長くなることと、追加のL1手数料です。最終的な請求が二つの環境の間で浮遊するのを許すより、不便さの方が望ましいと判断したようです。

とはいえ、難しい問題が「レイヤーをまたいで単一のネイティブ資産を維持すること」なのか、それとも「値が戻ってきそうなたびに、EVMステートの正しさを決済レイヤーがどれだけ再検証すべきかを決めること」なのか、まだ確信がありません。

#dusk $DUSK @Dusk $BTC