ブリッジのページは処理を1本の進捗ラインに押し込めがちですが、いざ問題が起きると十分ではありません。裏では2組の役割がリレーしていて、SDKはプロトコル動作を正しいデータにします。ウォレットは現在の段階を判断し、取引を送り出します。誰がどの区間を管理しているのかを切り分けてはじめて、どこで不具合を追跡すべきか分かります。

公式のweb-wallet PR #947は2026年8月7日にマージされました。中でSDKの責任範囲には、受取人のエンコード、MessagePassedの解析とハッシュ、withdrawal hashing、L1のprove/finalizeのシリアライズ、そしてプロトコル定数が含まれます。つまり「この資料がプロトコルに適合するにはどうすればよいか」を扱います。一方ウォレット側は、proof取得、dispute-gameの選択、W3sperの送信、finality gating、そしてUIのオーケストレーションを担当し、「今この段階から次へ進めるか」を扱います。

@Dusk のDuskEVMブリッジのトラブルシューティングは「成功 or 失敗」だけでは足りません。エンコードが不適切ならSDKを確認し、証明の発見や成熟状態が不正ならウォレットを確認し、資料は揃っているのにL1送信が未完了なら、トランザクションの再送と画面の編成を確認します。同じ進捗ラインが止まっていても、対処法はまったく違う可能性があります。

PRではDuskネイティブのトランザクションIDと、adapter変換後のEthereum hashもそれぞれ保存します。トラブルシュートのときにどちらか一方のhashだけを残してしまうと、反対側に跨った際にインデックスを失うおそれがあります。ユーザーにとって最も実用的な行動は、開始時点から両タイプの取引IDを保存しておくことです。

メンテナ本体でのローカル演習では、0.1 DUSKの最終口座純増が0.097716912、finalization gasが0.002283088 DUSKでした。これは私の個人的な検証でもなく、またパブリックテストネットやメインネットでの手数料・遅延・安定性についての結論でもありません。$DUSK の今回の更新は、責任分層と追跡用フィールドをどう設計するかを示すものにはなりますが、外部環境を保証するものではありません。コンポーネント、段階、そして2種類のhashを揃えることで、動けなくなった状況を「特定可能な問題」へ変えるチャンスが生まれます。#dusk