Signal
📡 Signal｜Liquidの3,996BTC流出、原因は鍵の漏洩ではなく範囲証明のキャッシュだった
Liquid の連合ウォレットから3,996 BTC が1回のペグアウトで出た。署名鍵は漏れていない。範囲証明の検証キャッシュの索引に資産と出力条件が入っておらず、裏付けなしに L-BTC を作れた。下流の部品はすべて仕様どおりに動いている。
9月6日、ビットコインのサイドチェーン Liquid の連合ウォレットから3,996 BTC が1回のペグアウトで出ていった。当時の価格でおよそ3億2,000万ドルにあたる。翌7日、そのうち3,400 BTC が返却された。
Bitquery(2026年9月) — 攻撃準備の68証明、キャッシュ索引の欠陥と修正内容、ペグアウトの経路と時刻、チェーン上メッセージBitquery
事故の性質を取り違えやすい事案である。連合の署名鍵が漏れたわけでも、相場が動いたわけでもない。壊れていたのは、取引を検証した結果を再利用するためのキャッシュの索引だった。そして流出の局面では、下流のすべての部品が仕様どおりに正しく動いている。
68個の同じ証明を、14時間かけて置いた
Liquid は取引金額を隠す設計を持ち、金額を明かさないまま「その額が正当な範囲にある」ことを示す範囲証明という暗号的な証明を使う。この検証は重いので、ノードは一度確認した証明の結果をキャッシュして使い回す。
Bitquery の調査によれば、攻撃側は14時間かけて68個の同一の範囲証明をチェーン上に置いた。ノードのキャッシュを目的の状態に満たすための準備とみられている。暗号を解いたのではなく、検証を省く仕組みのほうに材料を積んだ形になる。
索引に、資産と条件が入っていなかった
修正前のノードは、範囲証明を「証明そのもの」と「隠された金額」だけを手がかりにキャッシュしていた。つまり、どの資産についての証明なのか、どの出力条件に紐づく証明なのかが、索引に含まれていなかった。
結果として、ある文脈で正当と確認された証明を、別の文脈でそのまま通せる状態が生まれる。この経路を使えば、裏付けとなるビットコインを持たないまま L-BTC を作り出せた。L-BTC は Liquid 上でビットコインを表すトークンであり、本来は連合が預かった同量のビットコインが後ろにある。修正では、キャッシュの索引に資産と出力スクリプトが追加された。索引が足りていなかった、という一行に収まる欠陥である。
下流はすべて正しく動いた
流出の手順自体に不正なステップはない。攻撃側は L-BTC を SideSwap の入金アドレスへ送り、SideSwap は通常どおり資金をホットウォレットへ集約し、ペグアウト窓口が連合へ3,996.018 BTC の払い出しと0.1%の手数料を請求した。連合は9月6日14時28分56秒(UTC)に支払い、SideSwap は同じブロックの中で3,995.99999857 BTC を宛先へ転送した。
どの部品も、受け取った指示を仕様どおりに処理しただけである。入口で存在してはいけないものが作られると、下流が正確であるほど損失は速く確定する。ここが本筋だ。
流出後、連合ウォレットに残ったのは約197 BTC だった。
返却と、残った差
攻撃側は9月6日18時30分(UTC)、チェーン上のメッセージで「we are whitehats. contact us on chain」と伝えた。翌7日9時4分57秒(UTC)、Blockstream 側は PGP 署名つきのメッセージで「Bridge nodes are patched, safe to return the funds」と応じている。同日、3,400 BTC が連合のペグウォレットへ戻された。約2億6,800万ドル相当にあたる。
手元に残されたのは598.5 BTC で、当時のレートで4,700万ドルから4,800万ドルの範囲とされる。返却後の状態は、連合が保有するビットコインが約3,600 BTC、正規に発行されている L-BTC が約4,200 枚。差はそのまま埋まっていない。ネットワークは停止したままで、ブリッジノードは無効化され、中央集権型取引所での L-BTC の入出金も止まっている。
攻撃側が最後に残したチェーン上のメッセージは「:(」だった。
この事故が示す構造
サイドチェーンやブリッジの安全性は、署名鍵を誰がどう分散して持つかという話に還元されがちだ。今回壊れたのはその層ではない。鍵の管理は最後まで機能しており、連合は正当な請求に対して正当に支払った。破れていたのは、発行できる量を決める側の検証である。
発行の正しさが崩れると、鍵の分散も多重署名も損失を止められない。むしろ、それらが正しく動くほど支払いは滞りなく完了する。この種の設計では、資産の裏付けを確認する経路と、支払いを実行する経路が、それぞれ独立に信頼できることが要る。片方の前提が崩れたとき、もう片方は警報にならない。
最適化は正しさの外側に置かれることが多い。キャッシュは結果を速く返すための仕組みであって、何を同じとみなすかを決めた時点で、実質的には検証の一部になっている。今回、索引の設計が検証の設計そのものだった。
なお本稿は公式一次ソース未確認の段階にあり、独立した複数報道の一致に基づいて書いている。連合側の正式な事後報告が公開された時点で、原因の記述と数値は確認し直す必要がある。
🔗 一次ソース
