私は @Dusk を今年の「クロスチェーン・ブリッジ再検証」としてもう一度通して見直しました。いちばん注目すべきなのは「盗まれた」という2文字ではなく、障害が“どの層”で起きたのかです。1月16日に問題が起きたのは、ブリッジサービスが使う署名ウォレットでした。攻撃者は貸出権限を手に入れると、Dusk側から資産を移し、その一部をBSCへ送ったのです。公式には、これは合意の無効化(共識失効)ではなく、L1プロトコルが突き破られた(打ち穿)わけでもないとはっきり言われています。
しかし、だからといって基盤のチェーン自体が無事だという意味ではありません。ユーザーがブリッジのリスクを無視していい、ということにはなりません。旧アーキテクチャでは、イベントの受信、署名、そして資金の解放が一つの経路に押し込まれていました。速いのは速いのですが、署名側が破られると権限の集中が強すぎるのです。後からの作り直しでは、この3つを分離しました。イベントはまずタスクとして記録し、workerがステートマシンに従って処理します。署名済みの元トランザクションは先に保存し、失敗した場合は同じ1件をリプレイします。ホットウォレットには直近に必要な残高だけを残し、しきい値を下回れば停止。コールドウォレットは人手で補充します。
以前の私も、「ブリッジはプロトコルではない」という免責句をつい言い訳として受け取りがちでした。でも今は逆にこう捉えるほうが納得できます。ユーザーがそれを流動性の入口として扱う時点で、ブリッジはすでに $DUSK の“現実の安全境界”に入っています。オンチェーンの合意安全と、資産の出入口の安全——この2つは、どちらも同時に合格しなければならない試験用紙なんです。
今回の是正方針は正しいし、リスクが消えたわけでもありません。鍵の分離が長期的に実行されるのか、しきい値は妥当か、停止や補款が監査可能(ア审査可能)か、これらは引き続き見張る必要があります。#dusk のコミュニティが本来もっと問うべきなのは「チェーンがハッキングされたかどうか」ではなく、「必要以上の権限をまだ持っている“どの鍵”なのか」です。皆さん、クロスチェーン・ブリッジを見るとき、まずコード監査ですか?それとも運用上の権限がどう切り分けられているかから見ますか?
$TREE $ETH
しかし、だからといって基盤のチェーン自体が無事だという意味ではありません。ユーザーがブリッジのリスクを無視していい、ということにはなりません。旧アーキテクチャでは、イベントの受信、署名、そして資金の解放が一つの経路に押し込まれていました。速いのは速いのですが、署名側が破られると権限の集中が強すぎるのです。後からの作り直しでは、この3つを分離しました。イベントはまずタスクとして記録し、workerがステートマシンに従って処理します。署名済みの元トランザクションは先に保存し、失敗した場合は同じ1件をリプレイします。ホットウォレットには直近に必要な残高だけを残し、しきい値を下回れば停止。コールドウォレットは人手で補充します。
以前の私も、「ブリッジはプロトコルではない」という免責句をつい言い訳として受け取りがちでした。でも今は逆にこう捉えるほうが納得できます。ユーザーがそれを流動性の入口として扱う時点で、ブリッジはすでに $DUSK の“現実の安全境界”に入っています。オンチェーンの合意安全と、資産の出入口の安全——この2つは、どちらも同時に合格しなければならない試験用紙なんです。
今回の是正方針は正しいし、リスクが消えたわけでもありません。鍵の分離が長期的に実行されるのか、しきい値は妥当か、停止や補款が監査可能(ア审査可能)か、これらは引き続き見張る必要があります。#dusk のコミュニティが本来もっと問うべきなのは「チェーンがハッキングされたかどうか」ではなく、「必要以上の権限をまだ持っている“どの鍵”なのか」です。皆さん、クロスチェーン・ブリッジを見るとき、まずコード監査ですか?それとも運用上の権限がどう切り分けられているかから見ますか?
$TREE $ETH

