この事件は一般的なスマートコントラクトの脆弱性攻撃と本質的に何が違うのか？
多くのスマートコントラクトの脆弱性（リエントランシー攻撃など）は単一コントラクトのロジック内で発生し、通常は丁寧なコード監査で発見できる。問題が「このロジックが間違って書かれている」ことだからだ。Liquidのケースが異なるのは、単一の行が間違って書かれていたわけではなく、パフォーマンス最適化の手段（キャッシュメカニズム）が設計時に一部の文脈情報を欠落させていたことにある。この欠落自体は通常の状況下では全く問題を引き起こさない——誰かが意図的にバイトレベルの衝突を構成し、システムに2つの異なる取引を同一のものと誤認させるまでは。
これはまた、この脆弱性が8年間潜伏できた理由も説明している——「機能が壊れていた」わけではなく、「機能は大多数のケースで正しく動作しており、非常に特定のバイト組み合わせの下でのみ誤作動した」のだ。この種の脆弱性は標準的な監査プロセスでは特に発見しにくい。監査は通常、ロジックが期待される動作をするかどうかをテストするものであり、可能な全てのバイト組み合わせを網羅的に列挙するものではないからだ。
攻撃者が後に3,400 BTCを返還し「ホワイトハット」を自称したことは、この事件の性質を変えるのか？
資金の流れの結果だけを見れば、部分的な返還によって実際の損失額は確かに減少した（約3億1,900万ドルから、未返還分の約4,800万ドルへ）。しかしこれは、この事件が「善意の脆弱性開示」として再定義できることを意味しない。本物のホワイトハット行為は通常、実際にエクスプロイトを実行せずに、プロジェクトチームに非公開で脆弱性を報告するものだ。今回のケースでは、攻撃者はまず無担保資産の鋳造と実際のビットコインの引き出しという一連のプロセスを完全に実行し、資金の実際の支配権を獲得した上で、その後大部分を返還することを選んだ。
この「まず資金を手に入れ、後で部分的に返還する」というパターンは、近年の複数のオンチェーン事件で繰り返し見られるものであり、一般的には攻撃者が自身の身元がオンチェーンの足跡から追跡されうること、あるいは法的・名誉的リスクに直面することを認識した後に採る、単純な善意の行為ではなくリスク管理戦略として理解されている。読者の視点からすれば、攻撃者の後の動機がどうであれ、脆弱性が実際に悪用される前に、プロトコル側にこの種の取引を阻止する仕組みが明らかに存在しなかったことこそが、本当に検証すべき問題である。
Bug Aは8月初旬に既に報告され修正されていたのに、なぜその修正自体がBug Bを生み出し、誰も気づかなかったのか？
これこそがこの事件で最も考察に値する層だ——既知の脆弱性を修正するプロセス自体が新たな脆弱性を生み出したのだ。8月3日の修正は「キャッシュキーが重要なフィールドを欠落させている」という問題を解決したが、その方法は欠落していたフィールドを直接バイト連結で追加するというものだった——長さプレフィックス付きシリアライゼーションではなかった。この2つの方法は大多数のケースで同一の結果を生むが、その違いが現れるのは特定の境界条件下のみ、つまり異なるフィールドの組み合わせが偶然に同一のバイト列を構成してしまう場合に限られる。
この種の問題はしばしば「長さプレフィックス混同」（length-prefix confusion）と呼ばれ、シリアライゼーションとハッシュ設計における典型的だが見落とされやすい落とし穴である。なぜなら修正時の焦点は通常「報告された具体的な問題が解決されたか」であり、「この修正方法自体が新たな境界状況を生み出していないか」ではないからだ。修正は9月1日に公開でマージされたが、9月6日まで悪用されず、その間誰も気づかなかった——このことは、この種のバイトレベルの衝突脆弱性が、コード自体が公開され透明であっても、必ずしも時間内に発見されるとは限らないことを示している。
L-BTCを直接保有していないが、自分が利用するプロトコルが何らかのラップド資産を担保として受け入れている場合、この事件は自分に関係するのか？
関係がある。しかも間接的だが実質的なエクスポージャーだ。あなたが利用する貸付やデリバティブプロトコルが何らかのラップドビットコイン（WBTC、L-BTC、その他の変種を問わず）を適格担保として受け入れている場合、そのラップド資産の基礎となる検証メカニズムに同様の欠陥があれば、攻撃者は理論上、同じ手法を使って無担保のラップド資産を鋳造し、それをあなたが利用するプロトコルで他の資産を借り入れるために使う可能性がある——これはプロトコルレベルの不良債権を生み出し、不良債権は通常、そのラップド資産を直接保有する人だけでなく、全ての預金者が共同で負担することになる。
実際の確認方法としては、利用しているプロトコルがどのラップド資産を担保として受け入れているかを確認し、それぞれのラップド資産の技術文書を調べて、その鋳造・償還の検証ロジックが最後に公開監査を受けた、あるいはセキュリティ事件に関与した時期を確認することだ。プロトコルが受け入れるラップド資産の種類が多く、その基礎実装の透明性が低いほど、この種の「検証ロジックの欠陥」によるプロトコル全体のエクスポージャーは分散し、追跡しにくくなる。
2026年9月6日、Blockstreamが運営するビットコインのサイドチェーンLiquid Networkが攻撃を受け、実際のビットコインの裏付けを一切持たない約3,998.5 L-BTC（Liquid Bitcoin）が無から鋳造された。そのうち約3,996.02 BTCが数十分以内にビットコインのメインチェーンへ引き出され、総額は約3億1,900万ドル相当となった。この事件はラップド資産の信頼構造が破られる典型的なケース（マルチシグ鍵の盗難など）ではなく、オープンソースコードの中に8年間潜んでいたロジックの欠陥が、今年9月、無関係な修正作業によって偶然再活性化したものだった。
Liquidは、世界各地に分散配置された15の「ファンクショナリーノード」によって統治される稼働中のビットコインサイドチェーンであり、ブロックの検証には15ノードのうち最低11ノードの署名が必要となる。ユーザーがメインチェーン上でビットコインをロックすると、Liquidチェーン上で対応する1:1のL-BTCを受け取る（これをペグインと呼ぶ）。逆にL-BTCを焼却すると、連合の「ペグアウト認可鍵」（PAK）メカニズムを通じて、メインチェーン上で対応するビットコインが解放される（これをペグアウトと呼ぶ）。PAKメカニズム自体は二鍵式設計を採用している——オフライン鍵は資金の送付先アドレスが正当かどうかを検証し、オンライン鍵は誰がペグアウトを承認できるかを管理する。この設計全体の前提は、Liquidチェーン上の各L-BTCが、メインチェーン上でロックされた同量のビットコインに確実に対応しているということだ。
Blockstreamの公式事故評価報告によると、問題の根源は2018年に存在したコードの簡略化にある。Liquidノードが取引内の金額範囲証明（range proof、取引金額が実際の数字を明かさずに正当な範囲内にあることを証明する暗号技術）を検証する際、性能向上のために検証結果をキャッシュするが、当時のキャッシュキー設計では、アセットコミットメント（asset commitment）と宛先スクリプト（scriptPubKey）という2つの重要な文脈情報が欠落していた。これは、ある取引の検証結果が、本来拒否されるべき別の取引に誤って適用される可能性があることを意味した——両者のキャッシュキーが偶然一致した場合に限られる。2026年8月2日、外部研究者stutxo氏がこの根本的な脆弱性をBlockstreamに報告し、チームは8月3日に迅速に修正を展開した。その対応は、欠落していたフィールドを直接キャッシュキーの計算に連結するというものだった。問題は、この修正が「長さプレフィックス付きのシリアライゼーション」ではなく「生のバイト連結」を採用したことにあり、これが第二の脆弱性を残した——攻撃者が長さを調整したrange proofと対応するスクリプトを構成し、両者を連結したバイト列が別の正当な取引と完全に一致するようにできれば、検証結果が衝突し、本来拒否されるべき無効な取引が誤って正当と判定されてしまう。
9月6日13時53分10秒（UTC）、攻撃者はこのバイト衝突の欠陥を利用し、ブロック高4,050,336で実際のビットコインの裏付けを持たない約4,000 L-BTCを鋳造した。攻撃者はまず2.5 L-BTCで小規模なテストを行い、サードパーティサービスSideSwapの引き出し機能を通じて資金がスムーズに転送できることを確認した。確認後の14時05分、約4,000の無担保L-BTCをSideSwapのペグアウトサービスに預け入れた。14時28分56秒、Liquidの連合ノードは通常の手続きに従ってこの引き出し要求を処理し、ビットコインメインチェーンのブロック965,783で約3,996.02 BTCの実際のビットコインを解放した——鋳造からメインチェーン資金の引き出しまで、全体の過程は35分未満だった。Blockstreamは18時26分に異常を検知し、緊急にブリッジノードを停止したが、その時点で資金は既に流出していた。注目すべきは、攻撃者が18時30分にオンチェーンで「我々はホワイトハットだ。オンチェーンメッセージで連絡してほしい」と投稿し、翌日（9月7日）16時09分に自発的に3,400 BTCを返還したことだ。現時点でも約602 BTCが未回収のままである。
Blockstreamは9月7日未明に緊急の過渡的パッチを展開し、9月8日には徹底的に強化された修正（Elements PR #1600）をマージした。これはキャッシュキーの計算に長さプレフィックス付きシリアライゼーションを採用し、異なる取引入力の組み合わせが同一のキャッシュキーバイト列を生成できないようにするものだった。9月9日早朝にElements v23.3.4の正式版がリリースされ、同日夜にLiquidチェーンはブロック生成を再開した。復旧過程では、チームがキャッシュ機能を無効化して取引を再検証し、元の2つの無効な出力とそこから派生した4つの後続取引を決定論的に特定し、それに基づいて正しいチェーン状態を再構築した。Liquidのビットコイン準備金は一時約4,205 BTCから197 BTCまで急落し、攻撃者が3,400 BTCを返還した後にある程度回復したが、残りの約602 BTCの回収作業は依然進行中である。
何らかの形でラップド資産を保有している場合——L-BTCだけでなく、WBTCや他のオンチェーンラップド資産にも同じ論理が当てはまる——この事件は「このラップド資産がハッキングされたかどうか」と「このラップド資産の信頼構造がどのような技術基盤の上に構築されているか」が別々の問題であることを思い出させてくれる。マルチシグ鍵の盗難やソーシャルエンジニアリングによるガバナンス権限の取得は、過去の大半のラップド資産事件に共通するパターンだった。しかし今回は全く異なっていた——コードロジック自体は設計通りに正確に実行されていた。ただ、8年前に行われたコード簡略化の決定が、後になって発見される隙間を検証メカニズムに残していたのだ。次にラップド資産を評価する際は、マルチシグガバナンス構造を見るだけでなく、こう問う価値がある——この資産の鋳造・償還の検証ロジックは、最後に独立したコード監査を受けたのはいつか。