Liquid Networkの不具合が約3.2億ドル相当BTC流出の原因か

約3.2億ドル相当のLiquid Network関連事案を調査する研究者らは、ソフトウェアの取引検証キャッシュに不具合があった可能性を指摘した。これにより、裏付けのないトークンが正規のビットコイン（BTC）と交換（peg-out）され得たという。 Mononautは、悪用されたバグが前週にElementsのmaster開発ブランチへ取り込まれた一方、タグ付きリリースには含まれていなかったと述べた。Liquidのフェデレーション運用者（functionaries）がそのコードを稼働させていた可能性があるという。ほかのノードは不正な取引を拒否したとも指摘しており、Blockstreamは現時点で公表された声明の範囲ではこの導入状況を確認していない。仮に事実であれば、正規の署名権限が、バグで生成されたとされるLBTCに対してBTCを放出する形で使われたことになり、ソフトウェア展開の是非が事案の中心論点となる。 Liquidはビットコインのサイドチェーンで、LBTCはフェデレーションが保管するBTCに1対1で裏付けられる設計だ。CryptoSlateの既報によれば、SideSwapは9月6日、顧客がpeg-outサービス経由で4,000 LBTCを申請し、約3,996 BTCが放出されたと説明している。 Liquid側は、SideSwapのpeg-out承認キーや他のフェデレーション鍵が侵害された事実はないとしている。焦点は、LBTCがどのようにして引き出しプロセスへ到達したかに移っている。 Calleは、レンジプルーフ（range proofs）に関する欠陥を挙げた。レンジプルーフは、金額を秘匿したまま取引額が許容範囲にあることを検証する仕組みで、Liquidのコンフィデンシャル・トランザクションでは、入出力の一致確認だけでは不十分とされる。秘匿された負の出力が正の出力を相殺し、新規発行トークンが数学的に整合して見えてしまう可能性があるためで、レンジプルーフはそれを防ぐ目的で用いられる。 ただし検証は計算負荷が高く、ノードは成功した検証結果をキャッシュして再利用する。Calleによれば、攻撃者は無効な出力とプルーフを作り、過去に有効だった検証と同じキャッシュキーに一致させられた可能性がある。キャッシュ済み結果を参照したノードは本来拒否すべき検証をスキップし、インフレ的な出力を通してしまうという。 BlockstreamのCharles Guillemetもこの説明を支持し、細工されたキャッシュキーの衝突により無効なコンフィデンシャル取引がレンジチェックを回避し得たと述べた。Calleは、自身の説明は単純化しており誤りを含む可能性があるとも注意している。 別の再構成としてStuは、準備取引の後にLiquidのブロック4,050,336で不正とされる取引が実行されたと報告した。この取引で約3,996.0183 LBTCが作られ、その後SideSwap経由で引き出しが行われたという。 Mononautは、取引を受け入れたノードと拒否したノードが分かれた点を強調した。フェデレーション運用者は悪用取引を受理し、引き出しを承認した上でブロック生成を継続した一方、mempoolのLiquidエクスプローラーを支えるノードを含む他ノードは問題のブロックを拒否したという。この挙動の差により、拒否側のノードに追随するエクスプローラーでは、他所で見える取引が表示されない説明がつく。 この分岐が事実であれば、どのソフトウェア版が稼働していたかが不具合解明の重要要素となる。事後検証（ポストモーテム）では、どのコードが実行されたのか、なぜそれが導入されたのか、拒否側ノードと検証挙動がどう異なったのかの確定が求められる。 引き出されたBTCを管理する主体はホワイトハットを名乗り、多くの資金返還を「影響ノード全体でバグが修正されること」を条件としている。現時点の報道では、返還の完了やパッチ展開の完了は確認されていない。 BTCの回収が実現すれば準備不足は解消される。一方で、フェデレーションノードがなぜ取引を受理したのかを説明し、修正後ソフトウェアが当該取引を確実に拒否することを示すことが、準備が流出し得た根本要因の解消につながる。