コストゼロでLNを止める｜チャネルジャミング攻撃の盲点

ライトニングネットワークで送金しようとしたとき、「支払いに失敗しました」と表示された経験はないでしょうか。ルートが見つからない、流動性が足りない――よく聞く説明ですが、もう一つ、ほとんど語られない原因があります。意図的に仕掛けられた攻撃です。しかも攻撃者は資金を一切失いません。

なぜLNチャネルは止められるのか

ライトニングネットワーク（LN）は、HTLC（ハッシュタイム・ロック・コントラクト）と呼ばれる仕組みを使い、オフチェーンで送金を中継します。このHTLCには、各チャネルが同時に処理できる数の上限があります。プロトコル仕様で定められた上限は最大483スロットです。

この数字はプロトコルに直接埋め込まれており、変更するにはLN全体のアップグレードが必要です。そして攻撃者は、まさにここを狙います。

攻撃の構造はシンプルで残酷

攻撃者がやることは単純です。ターゲットのチャネルに対して、決済されないHTLCを483個送りつけ、スロットをすべて占有します。チャネルが満杯になると、そのノードは正規ユーザーの送受信を一切受け付けられなくなります。事実上の機能停止です。

一定時間が経過すると、攻撃者はHTLCをキャンセルします。拠出した資金はそのまま手元に戻ります。攻撃にかかった実質コストはほぼゼロ。これがチャネルジャミング攻撃の構造です。

非対称性が問題の本質

セキュリティの世界では、攻撃コストと防御コストの非対称性が重要です。通常のDDoS攻撃でも、攻撃側はネットワーク帯域や計算リソースを消費します。しかしチャネルジャミングでは、HTLCの一時的な拠出だけで攻撃が成立し、資金は後で全額返ってきます。

一方、攻撃を受けたノードは機能停止中ずっと機会損失を被ります。攻撃者はゼロコストで、防御側に実害を与え続けられる。この非対称性こそが、この問題を根本的に厄介にしている理由です。

2021年から研究が続くが、解決策はまだ実装されていない

このリスクは新発見ではありません。2021年に研究者のClara ShikhelmanとSergei Tikhomirovが詳細なレポートを発表し、「チャネルジャミング問題」として広く認識されるようになりました。

以来、Lightning開発コミュニティで対策の議論が続いています。提案の一つに「Upfront fee（前払い手数料）」があります。HTLC送信時に小額の手数料を課すことで、攻撃コストを引き上げようというアプローチです。しかし実装すると正規ユーザーにも追加コストが発生するため、2026年現在も本番環境での採用には至っていません。根本的な解決策はまだ実装されていない。これが現状です。

取引所に預けたままでは、二重のリスクを抱える

取引所がLNを活用した出金・送金サービスを提供している場合、そのインフラがジャミング攻撃を受けると、あなたのビットコインを引き出せない状態が発生しえます。技術的な原因であれ、出金が滞る体験は変わりません。

さらに根本的な問題があります。取引所に資産を預けている限り、そのビットコインを動かす権限は取引所が持っています。送金の可否も、引き出しのタイミングも、最終的にはプラットフォームの判断に依存します。出金が止まったとき、その原因がLNの技術的問題なのか、業者の経営問題なのかを、外部から判断することはほぼできません。

セルフカストディであれば、LNの設計上の限界を把握した上で、オンチェーン送金と使い分けることができます。少額の高速決済にはLN、大きな金額や長期保管にはオンチェーン。このような選択ができるのは、秘密鍵を自分で管理しているからです。

理解している人だけが選択できる

チャネルジャミングを知っているビットコインホルダーは、LNをどの場面で使い、どの場面では避けるかを意識的に判断できます。プロトコルの限界は変わらなくても、その限界の中で最善の行動を取れます。

ビットコインの設計原則は「自己検証、自己管理」です。技術的な欠陥があるとしても、それを把握した上で保有するのと、把握せずに人任せにするのとでは、リスクの質が根本的に異なります。

自分の秘密鍵を持ち、LNの設計上の制約を理解した上で使う。それが今できる最も堅実な判断です。まず秘密鍵を自分で管理することから始めてください。

※本記事は一般的な情報提供を目的としており、投資助言ではありません。