ニューヨークのコーヒーからふるさとのお年玉まで。ビットコインはあらゆる場面において世界中で使うことのできるお金です。ひと昔前までビットコインは送金に時間がかかり手数料が高いと言われた時期もありましたが「ライトニングネットワーク(Lightning Network)」という技術の登場により、圧倒的に決済体験が良くトラストレスでパーミッションレスな支払いが可能になりました。

はじめに歴史と概要を端的に説明すると、ライトニングネットワークが提案されたのは2015年の2月。Joseph PoonとThaddeus Dryjaの共同執筆による初期ドラフト(0.5)が公開され、2016年1月14日に最終的なバージョン0.5.9.2が公開されています。

💡
コラム① ビットコインと日本の繋がりとは
ライトニングネットワークの提案者であるThaddeus Dryja氏は2011年頃に三重大学にて勤務された経歴を持つ人物です。

またビットコインを発明したサトシ・ナカモトは、日本人のような名前をしています(その正体は現在も明らかになっていません)。ビットコインは意外なところで日本とのつながりを感じさせる存在だと言えます。
ライトニングネットワークの論文(0.5.9.2)

ライトニングネットワークにはBitcoin Coreのようなリファレンス実装、つまり参考となる基準がないため、異なる開発チームが相互運用できるよう技術的な仕様が必要になります。

このような基準は、世界中の開発者によって議論されています。その内容はBOLT(Basis of Lightning Technology)という標準規格として文書化されており、2026年10月現在、BOLT #0〜#12(#6を除く)の計12セクションで構成されています。

各BOLTの詳細は、以下の表にあるリンクからご確認ください。

BOLT #0 用語
BOLT #1 基本プロトコル
BOLT #2 ピアプロトコル
BOLT #3 トランザクションとスクリプト
BOLT #4 オニオンルーティング
BOLT #5 オンチェーン処理の推奨事項
BOLT #6 (削除)
BOLT #7 ノードとチャネルの発見
BOLT #8 暗号化トランスポート
BOLT #9 機能フラグ
BOLT #10 DNSブートストラップ
BOLT #11 インボイス
BOLT #12 Offers
💡
コラム② ライトニングネットワークにはテーマソングが存在する?
BOLT #0を一番最後までスクロールすると「Theme Song」というセクションが存在し、Anthony Towns氏が作詞した歌詞が書かれています。気になる方はぜひご覧ください。

ライトニングネットワークはBOLTという標準規格に基づき、2016年頃から複数のチームによって開発が進められ、2018年頃からメインネットで本格的に使われ始めました。ユーザーは好きな実装を選択して自由に利用することが可能なのも、複数実装が存在するメリットだと言えます。

主要な実装はLND(Lightning Network Daemon)・CLN(Core Lightning)・Eclairの3つがあります。

実装 開発元 言語
LND Lightning Labs Go
CLN Blockstream C
Eclair ACINQ Scala

2026年10月現在は世の中のライトニングノードのおよそ98%がLNDとCLNに該当すると言われるほど2つの実装がシェアを寡占しています。EclairについてはACINQ社が運営する大規模なルーティングノードで使われていますが、個人でEclairを使っている人はほとんど見かけません。

加えてライトニングネットワークのノードやウォレットを自分のアプリに組み込みたい場合は、Spiral社が提供するライブラリのLDK(Lightning Development Kit)を使うのも選択肢の1つです。

本稿ではさらに深堀りしてライトニングネットワークがどのようにして機能しているのか、その仕組みを解説します。

なお初学者の方や事業者の方は以下の記事もご覧になると従来のビットコインが抱えていた問題をライトニングネットワークはどのように解決したのか、またライトニングネットワークの活用事例と日本国内でのポテンシャルを知ることができるので併せてご覧ください。

「ビットコインは決済に使えない」はもう古い!ライトニングネットワークで高速決済を実現
ビットコイン決済が抱えていた「遅い」「高い」「価格変動リスクがある」といった問題を解決し、ビットコインを決済手段として実用的なレベルまで引き上げたライトニングネットワークについて紹介します。世界中でのいくつかの導入事例を紹介し、日本企業がどのように活用したらよいかについてもご提案します。

ライトニングネットワークはなぜ生まれたのか

突然ですが、ライトニングネットワークはなぜ生まれたのでしょうか。

ライトニングネットワークが登場する以前のビットコインはブロックチェーン上の送金に限られていたため、様々な課題が存在しました。

大きな課題としては以下の2つが挙げられます。

  • 送金時間が長いこと(通常着金に10分程度かかる)
  • 手数料が高いこと(ネットワークの混雑度に応じて可変)

これらの課題を解決するために、「ブロックチェーン外で送金を行い結果のみをブロックチェーンに記録する仕組み」として生まれたのがライトニングネットワークです。

ビットコインのスケーラビリティ問題

2017年頃になるとビットコインの利用者が急増し、ブロックに入りきらないトランザクションが増えたことで、送金時間が遅延し手数料が高騰するという問題が発生しました。この問題をスケーラビリティ問題といいます。

Bitcoinのスケーラビリティ問題とLightningの成功: 次のL2へ
Bitcoin が初期から抱えてきたスケーラビリティ問題にどのように向き合い、Lightning Networkが生まれ、普及してきたのかの過程。その延長線上にある Ark や Spark といった新しいオフチェーンプロトコルが、なぜ現在注目を集めているのか、その背景を整理します。

より詳しい解説はこちらの記事をご覧ください

以下の図は当時の状況を表しており、年代別のブロックあたりの手数料を示しています。

https://mempool.space/ja/graphs/mining/block-fees

図より2017年の後半には手数料は一時的なピークを迎えていることがわかります。当時は送金に数十分かかり手数料は数千円かかることも多々ありました。

主な原因は、ブロックのサイズが1MBに制限されていたことです。当時はブロックサイズを大きくして、増大するトランザクション数を受容できるようにするべきか否かをめぐり、ブロックサイズ論争が起きました。

最終的にビットコインは、ブロックサイズを単純に大きくするハードフォークではなく、2017年8月に「SegWit」というソフトフォークを有効化する道を選びました。

ライトニングネットワーク自体は2015年に提案されていましたが、このSegWitの有効化によって安全に実装できる土台が整い、オンチェーンとは別のレイヤーで送金を行う仕組みとして本格的に開発されていきました。

トランザクション展性(マリアビリティ)とはなにか?何故問題か?Segwitでどう解決するのか?
今回のレポートは、先週に引き続きまして、ビットコインのスクリプトにまつわる話をしたいとおもいます。テーマは、トランザクション・マリアビリティです。トランザクション・マリアビリティというのは、ビットコインの実装における最大の欠陥とも指摘されていたものです。 Mt.Gox事件を当時体験しているひとだったら、かならずや聞いたことのある言葉とおもいます。マーク・カルプレス元CEOの「システムに弱いところがあって、ビットコインがなくなってしまいました」という言葉は記憶に新しいとおもいます。この「システムの弱いところ」というのが、トランザクション・マリアビリティの欠陥をついたバグということなのです。コインが盗まれた原因だとされていました(が、事件の顛末としてはCEOによる内部犯罪の線が濃厚です)。 トランザクション・マリアビリティがある限り、取引所などのシステムにもややこしい対応が必要になりますし、ライトニングネットワークやサイドチェーンといったものが開発できないといわれています。 なんとかして、マリアビリティ問題を解決できないか? 実は、Segwitというのが、このマリアビリティ問題の
💡
コラム③ なぜブロックサイズを大幅に大きくしなかったのか
デジタルゴールドと呼ばれるビットコインですがゴールドにはなくて、ビットコインにある特徴は検証が容易であることです。つまりゴールドは本物かどうかを見分けるのに専用の高額な機械を必要としますが、ビットコインでは手元のPCさえあれば検証できます。しかし、ブロックサイズを大きくしてしまうと検証をするのに動かすPCのストレージを大幅に蝕んでしまい、誰もが簡単に検証することが難しくなってしまいます。

そこでビットコインは2017年8月に「Segwit(Segregated Witness)」というアップデートを行いました。Segwitはトランザクションのうち署名などのデータサイズを1/4倍にすることで実質的なブロックサイズの拡張をすることができます。

つまり、ビットコインはブロックサイズをまったく大きくしなかったわけではなく、古いノードとの互換性を保つソフトフォークという形で、検証のしやすさを損なわない範囲で容量を拡張したのです。そのうえで、それ以上の決済増加には、ライトニングネットワークのような別のレイヤーで対応する道を選びました。

一方、ハードフォークによりブロックサイズを大きくした側は2017年8月にビットコインから分岐し、現在はBitcoin Cash(ビットコインキャッシュ)と呼ばれています。

ライトニングネットワークの仕組み

https://mempool.space/ja/graphs/lightning/nodes-channels-map

上の図はライトニングネットワークを可視化したものです。ここではライトニングネットワークの解説に必要な用語をご紹介します。

ライトニングネットワークはブロックチェーン(オンチェーン)とは別のレイヤーに上図のようなネットワークを形成しています。世界中でコンピュータが動かされており、それぞれのソフトウェアを動かすコンピュータのことを「ノード」と呼びます。またノード間をつなぐ線のことを「ペイメントチャネル(チャネル)」と呼び、チャネルを通じてビットコインが送受金されています。

ペイメントチャネル

最初はビットコインをブロックチェーン外(オフチェーン)で送金するための経路である「ペイメントチャネル」から解説していきます。

次の図をご覧ください。

ライトニングネットワークの概念簡略図

こちらはライトニングネットワークにおけるチャネルのフローを簡略化して表した図です。点線より上の領域がオフチェーンつまりライトニングネットワークのことであり、点線より下がオンチェーンです。

主なライトニングネットワークのサイクルは以下のようにまとめられます。

  • チャネルの開設(オープン)
  • 状態の更新
  • 最終的な状態を記録(クローズ)

チャネルの開設(オープン)

最初のステップではオンチェーン上にあるビットコインをオフチェーンに移動させるために、チャネルを開設しています。

チャネルの開設

図を見ると、オンチェーンにあるビットコインを2-of-2のマルチシグのアドレスに送ってロックし、ペイメントチャネルを開設しています。言い換えると、2人の署名が揃わないと開けられない金庫にビットコインを預けている状態です。資金そのものはオンチェーンに置かれたまま、その分配だけをオフチェーンでやり取りしていくのが、ライトニングネットワークの基本的な考え方です。

このとき、チャネルを形成しようとしている側がビットコインを入金(ファンディング)する必要があるため、図の場合はチャネル内がAのビットコインで満たされています。

💡
コラム④ デュアルファンドのペイメントチャネル
通常ライトニングネットワークではチャネルを開設するノードが入金を行う必要があります。両方のノードが入金する「デュアルファンドチャネル」は以前から提案されていますが、実装をしているのは2026年10月現在CLNとEclairです。

状態の更新

送金が行われるときは、イメージでいうとそろばんの珠が移動するようにチャネル内のビットコインが遷移し、状態が更新されます。

状態の更新

図ではAがビットコインを送金することでチャネル内のビットコインが再分配されていることが分かります。つまりライトニングにおける送金はチャネル内の資金以上には原理的に送ることができないのが特徴です。

ここで用語の紹介です。チャネル内にあるビットコインの総容量のことを「キャパシティ」、またAから見た時、送金することができる容量のことを「アウトバウンドキャパシティ(ローカルバラン)」、受け取れる容量のことを「インバウンドキャパシティ(リモートバランス)」と呼んでいます。

一方でキャパシティを集計してもライトニングネットワーク全体を俯瞰することのできる指標とは言えないので注意が必要です。これはチャネルというのは全てが公開されているわけではなく、存在を秘匿することができる「プライベートチャネル」を形成することができるためです。

詳しくはBOLTの整備にも関わられたLandonさんの記事をご覧ください。

Lightning Networkの「キャパシティ」は流動性ではない
Lightning Networkの「キャパシティ」は流動性ではありません。エクスプローラー間で数値が食い違う理由、残高が公開されない設計上の理由、そしてキャパシティから流動性やTVLを読み取ってはいけない理由を、BOLT仕様と実証研究に基づいて解説します。

最終的な状態を記録(クローズ)

最終的にライトニングネットワークではチャネルをクローズすることで、チャネル内のビットコインを再びオンチェーンに戻すことができます。

最終的な状態を記録してチャネルをクローズ

チャネルを閉じてビットコインをオンチェーンに戻す方法は、大きく分けて「協力的クローズ」と「強制クローズ」の2つがあります。

協力的クローズ(Cooperative Close)

協力的クローズは両方のノードがオンラインで、チャネルを閉じることに合意している場合の方法です。AとBは最終的な残高に基づいて、新たに「クロージングトランザクション」を作成し、両者で署名してブロードキャストします。

強制クローズ(Force Close)

強制クローズは相手のノードがオフラインで応答しない場合や、相手と合意できない場合は、一方のノードだけでチャネルを閉じることができます。

強制クローズを実行する側の残高は一定期間(to_self_delay)待たなければ使えないのに対して、相手側の残高はすぐに使用可能なのが特徴です。これは、強制クローズする側が不正をした場合に相手が対処する猶予期間として時間が設けられています。

また強制クローズは協力的なクローズと比べてより複雑なトランザクションをブロードキャストする必要があるため、手数料が高くなりがちです。事前に決められた手数料率によって強制クローズが行われます。

コミットメントトランザクションとペナルティ

ここでは送金におけるチャネルの状態遷移を詳しく見て、注意すべき点を解説します。

最初にAがチャネルに20,000sats入金した場合を考えます。このときAはBに対して20,000sats分送金することは可能ですが、BはAに対して送金する資金はまだありません。

AからBへの送金はチャネルの残高の再分配を意味しており、これらの状態遷移を行うトランザクションを「コミットメントトランザクション」と呼びます。

コミットメントトランザクションと状態遷移

図では合計で3回の送受金が行われているため、コミットメントトランザクション(0~3)が存在している事がわかります。ビットコインにおいてはトランザクションの有効期限は存在しないため、4つのコミットメントトランザクションは全て有効です。つまり古い状態のトランザクションをオンチェーンに刻むこともできてしまいます。

そこで新たなコミットメントトランザクションを作成する際は、古い状態に対応する「失効用シークレット」という秘密の値を互いに相手へ渡します。もし古いトランザクションがオンチェーンに刻まれた場合、相手はこのシークレットから失効鍵を導き出し、チャネル内のビットコインを全額回収できます。つまり古い状態を使うと全額を失うリスクがあるため、不正をする動機がなくなる仕組みです。

例としてBが何らかの原因でオフラインになった場合を考えます。

古いコミットメントトランザクションを使った不正

現在の状態ではAの残高は6,000satsを所有しています。BはオフラインであるためAは過去の20,000sats所有していたトランザクションの記録をオンチェーンに刻むことで、14,000sats分多くビットコインを引き出す不正を働くことが可能です。

Bはオフラインのため、Aは強制クローズを行います。強制クローズには一定の猶予期間(一般に1日〜2週間程度)が設けられており、Aは自分の取り分をすぐには引き出せません。Bがこの期間内にオンラインに戻って不正に気づけば、ペナルティ用のトランザクションをブロードキャストすることで、チャネル内のビットコインを全て受け取ることができます。

これらの理由からライトニングネットワークのノードは常にオンラインであることが求められます。

またオフラインになってしまった場合の保険として、不正が行われていないかブロックチェーンを監視するWatchtower(ウォッチタワー)を建てることで対策することもできます。

Watchtowerに関する詳しい解説は以下の記事をご覧ください。

Lightning Networkを保護するWatchtower:普及が進まない理由と今後の期待
Lightning NetworkのWatchtower機能の仕組みと課題、普及しない理由と将来性を詳しく解説。LN全体の安全性向上への役割やArk等の新プロトコル連携の視点も紹介し、Watchtowerの現在地を総合的に理解できます。
詳解Watchtower: Lightning Networkノードの守り方
今回の記事では、「Watchtowerがどのように暗号化したトランザクションデータを保管し、違反発見時に公開するのか」や「ユーザーのバランスやトランザクションの中身を把握しないWatchtowerによる監視保護の実現方法」について詳しく解説します。

HTLC(Hash-Time-Lock-Contract)と送金

ここからはノード間の送金においてどのようなやり取りが行われ、送金が失敗した際は安全にビットコインが返金される理由を紐解いていきます。

次の図はライトニングネットワークにおいて送金を行うフローを表した図です。

AはBに対してインボイスをリクエスト

送金者であるAは金額などが記載された「インボイス(請求書)」をBに要求します。これはECサイトにおいて購入ボタンを押すとQRコード(請求書)が表示されることに似ています。

一方でBは秘密の値である「プリイメージ」をハッシュ化させた「プリイメージ・ハッシュ」を用いてインボイスを作成し、インボイスのみをAに提供します。この時点ではプリイメージは誰にも教えてはいけません。

インボイスについての詳しい解説は以下の記事をご覧ください。

ライトニングインボイスの中身を理解する:BOLT11の構成要素を1つずつ解説
ライトニングインボイス(BOLT11)とは何か。プレフィックス・金額・タイムスタンプ・タグ付きフィールド・署名まで、Bech32でエンコードされたインボイスの構造と読み方を初心者向けに解説します。

インボイスを受け取ったAはHTLC(Hash-Time-Lock-Contract)という暗号学的な仕組みを利用して、送金額をロックします。まだ送金はこの状態では完結していません。

HTLCによりビットコインをロック

仮にインボイスに書かれた金額が10,000satsであった場合は、HTLCにより10,000satsをロックします。このとき、HTLCを解除する方法は以下の2つです。

① Bがプリイメージを明かした場合:

プリイメージをハッシュ化した値がプリイメージ・ハッシュと一致すれば、HTLCが解除されビットコインはBに送金されます。この条件はビットコインのスクリプトで強制されるため、Aが支払いを拒むことはできません。また、受け取ったプリイメージはAにとって支払いが完了した証明(領収書)になります。

② 指定した時間が経過してもプリイメージが明かされなかった場合:

送金は失敗とみなされ、HTLCが解除されてAにビットコインが返金されます。なお実際には、送金が失敗すると多くの場合タイムロックを待たずにすぐ取り消され、タイムロックは最終的な安全装置として働きます。

①、②よりライトニングネットワークの送金は成功するか、失敗するかの2択しかなく中途半端な金額が送金されたり、不足するという事はありません。これはアトミック性と呼ばれます。

またトラストレスに送受金ができるのも、HTLCという暗号学的な仕組みにより不正が行われることがないためです。

オニオンルーティング

先ほどまでは直接チャネルが繋がっているノード間の送金を見てきました。

ところで、世界中にはおよそ16,000のノードと32,500のチャネルが存在します。もちろん全てのノードとチャネルを繋ぐことはできません。ではライトニングネットワークはいかにしてチャネルを繋げていないノードにビットコインを送金するのでしょうか。

答えは単純で間にいくつかのノードが支払いを中継、つまり「ルーティング」を行うことで遠方のノードまでビットコインを届けることができます。

ルーティングで中継ノードがビットコインを中抜きするのではないかと心配になるかもしれませんが、HTLCと「オニオンルーティング」という仕組みによりアトミック性を担保しています。

例としてAからB、Cと経由してDに送金することを考えます。

オニオンルーティング

ここでマトリョーシカのようなデータ構造のことを「オニオン」と呼び、各ノードが外側にある自分のデータしか暗号学的な仕組みで見られないようになっているため、中継ノードは送金の前後の情報しか知ることができず、プライバシーはある程度担保されています。

💡
コラム⑤ なぜプライバシーはある程度しか担保されないのか
オニオンルーティングにより中継ノードは送金の前後の情報しか分かりません。しかし、最終中継ノードであるCはどうでしょうか。仮に受け取り主であるDがモバイルウォレットを使っていた場合、モバイルはルーティングを行わないのでCからするとDが最終受け取り手であることが容易に推察できてしまいます。

また各ノード間の送金は通常の送金と同様にHTLCによりアトミック性が担保されているため、全体的に見てもアトミックな送金を実現しています。

ルーティング手数料

ここではライトニングネットワークで送金をする時の手数料について見ていきます。
手数料はおおまかに分類すると以下の2つが存在します。

  • 基本手数料(Base_fee)
  • 手数料率(Fee_rate)

基本手数料は固定でかかる手数料、手数料率は中継額に応じて変動してかかる手数料です。これらの手数料は中継を行ったノードが自分のチャネルバランス(チャネル内の残高)を動かす見返りに徴収するものです。そのため各ノードはチャネルごとに手数料を設定することができます。

基本手数料(Base_fee)

基本手数料は固定手数料のことで、中継する額とは関係なく手数料を課すことができます。単位としてはmsat(ミリサトシ)というsatの1000分の1の値を用いるのが特徴です。経験則的にはほぼ全てのノードが0~1000msat、つまり0~1satsしか基本手数料を課さないためとても低いです。

手数料率(Fee_rate)

Fee_rateは従量手数料のことで、中継額により変動する値を取ります。具体的にはppm(=parts per million、100万分率)という単位を用いて、100万sats当たりいくらの手数料を取るかを表しています。例えば、ppm=500とすると送金額100万satsにつき500sats(0.05%)の手数料ということになります。

ライトニングネットワークではこの2つの手数料を足し合わせた額が中継する際に課されます。

手数料の計算

送金手数料は送金者(図ではA)が受信者側から計算を行います。

C→Dでは10,000satsが中継されるのでノードCでは7sats、B→Cでは10,007sats中継されるのでノードBでは6sats手数料を必要とします。そのため図ではAからDに10,000satsを送金するのに、手数料は13sats必要という計算です。

ライトニングネットワークではチャネルごとに手数料を決めることができますが、手数料が低い経路が選択されるため比較的安く送金を行うことができます。

より詳しい手数料の解説は次の記事をご覧ください。

LN手数料分布から読み解くノード運用の傾向|ゴシップ情報で可視化
ライトニングネットワーク(LN)の手数料設定に悩むノード運用者向けに、ゴシッププロトコルで取得したデータからBase_feeやFee_rate、インバウンド手数料の分布を可視化。ネットワーク全体の手数料傾向を累積分布図で俯瞰し、ノード運用における手数料戦略の参考になる知見をまとめました。
💡
コラム⑥ インバウンドルーティングフィーとは
ここまで説明した手数料は、送金を中継するときに「出ていく側」のチャネルに設定するものでした。これに対し「入ってくる側」のチャネルに設定する手数料を、インバウンドルーティングフィーと呼びます。

これはLNDが独自に導入した仕組みで、BOLTの標準規格ではありません。主に手数料を割り引く(マイナスの値を設定する)目的で使われており、対応していない実装は割引を無視して通常の手数料を支払うため、送金自体は成功します。
LNDのInbound Routing Fee対応が目前に
去年の1月、本稿でライトニングネットワークにおける「Inbound Routing Fee」をめぐる論争について取り上げました: 難ありなInbound Fees実装をLndが強行突破で導入する思惑にライトニング開発者らが反発今週の論争で際立ったのは、ライトニングでInbound Feesを実現する方法をめぐり、明確に最適な提案がいない状況で、ロールアウトや後方互換性の面で懸念が残る実装方法をLndが強行突破で導入しようとしていることと、それに対する反発でした。 今日はどのような実装方法が議論に上がっているのか、それぞれの特徴と欠点、そして論争の内容をまとめました。 Inbound Feesでライトニング上の資金の流れを効率化 ライトニングにおけるルーティングノードは送金を中継する際に自らが中継先に送る金額について手数料を徴収することができます。その一方で、送金元に近いノードから自身が受け取る送金については送金元に近いノードが手数料を設定することになります。 ルーティングノードはチャネルの手数料を設定する際に自身の都合も考慮して設定します。例えば、これ以上残高がリモート側に流れてほし

経路探索

送金する側のノードはできるだけ低い手数料で抑えたいところです。そのため送金する側のコンピュータは受信者までの送金経路を手数料が低くなるように計算しています。

一般的にライトニングネットワークではこの計算を「経路探索」と呼び、多くの実装がダイクストラ法という数学的手法を用いています。

💡
コラム⑦ 経路探索はプロトコルではない?
実は経路探索はBOLTに仕様として書かれていません。そのため実装ごとに経路探索の方法は違いそれぞれに特徴があります。実装ごとの経路探索の方法については記事を書いた際にリンクを貼っておきます。 
赤線:一番手数料が低い経路を表している

ここで注意すべきポイントが2つあります。仮に上図のように赤色の経路が一番手数料が低い場合を考えてみましょう。この経路は4ホップ(4本のチャネル通過)を経て送金されています。

しかし、送金者から受信者に一直線に送金する経路のように最短経路は3ホップであることからも、経路探索は必ずしも一番短い経路が選ばれるわけではないということです。
また次の図をご覧ください。

接続しているチャネルバランスはわかるが他はわからない

図のように送金側としては接続しているチャネルバランスは知っていますが、ネットワーク内の他のチャネルバランスは知り得ません。次のノードへ向かうチャネルで、中継ノード側の残高が支払い額より少ないと、支払いを中継できずに失敗します。そのため手数料が低い経路を見つけたとしても最終的にはトライアンドエラーでの送金となります。

また送金を成功させる工夫として、過去の送金結果を蓄積する仕組みがあります。送金が失敗しやすい経路は送金経路として選ばれづらくなります。

そのためルーティングを行い手数料を稼ぎたいノードからすると、なるべく自分のチャネルを通る送金が失敗にならないよう、チャネルバランスを均等に保つ努力が必要になります。

番外編として経路探索を別のノードに委託するという仕組みもあります。が本稿のレベルを逸脱するので気になる方は以下の記事をご覧ください。

トランポリンルーティングとは?LNの経路探索を委託する仕組み
トランポリンルーティングは、経路探索の一部を中間ノードに委ねることでモバイルウォレットのLNグラフ同期を不要にする仕組みです。ソースルーティングとの比較、送金の流れ、手数料とプライバシー面の注意点、実装ごとの対応状況を解説します。

ゴシッププロトコル

送金するノードはどのようにして世界中のノードの情報を得ているのでしょうか。

実はライトニングネットワークでは、「ゴシップ」つまり噂話のようにノード間を伝搬して情報が伝えられています。この仕組みは「ゴシッププロトコル」と呼ばれ、ライトニングノードを動かしている人なら誰でも取得することができます。

ゴシップで取得できる情報は以下の3つです。

  • node_announcement(ノード情報)
  • channel_announcement(チャネル情報)
  • channel_update(ルーティング情報)

ビットコイン研究所ではこれらの情報を用いて様々な分析を行っています。

以下の記事はライトニングネットワークの全体像を俯瞰できるおすすめの記事です。

データから見るLNのパブリックノードの全体図
ライトニングネットワークの可視化を行ってくれる「ライトニングエクスプローラー」と呼ばれる種類のサービスには数社あり、老舗の1ML.comや最大手のAmboss.space、さらには人気ブロックチェーンエクスプローラーのmempool.spaceなどが参入しています。大量のデータを集めてユーザーに見つけやすくすることで価値を提供しているこれらのサービスですが、実はブロックチェーンエクスプローラー同様、彼らが収集しているデータの多くは一般的なライトニングユーザーにも収集可能なものです。 というわけで、ライトニングネットワークを流れてくるゴシップ情報を保存する仕組みを構築してみました。今回は自分のノードが受信した約10日分のライトニングネットワークのゴシップデータをもとに気づいたことを取り上げてみます。 💡ちなみにAmbossなどで提供されているすべてのデータがライトニングノードから取得できるわけではなく、例えば外部からノードのアップタイムを監視したり、ノードから自主的に提供を受けたり、あるいはエクスプローラーへのアクセス解析のようなメタデータを活用するなど、エクスプローラーによって真

ライトニングネットワークにおけるインボイス以外の送金方法

ほとんどの場合ライトニングネットワークではインボイスを相手に発行してもらい、それを用いて送金を行います。体験だけで言うとPayPayのようにQRを読み込んで送金ボタンを押すだけで数秒で完了します。

補足として、インボイスを発行する以外の送金の仕組みも紹介します。それぞれの詳しい解説はリンク先をご覧ください。

1つ目は「Lightning Address(ライトニングアドレス)」です。こちらはbitcoin-research@example.comのようなメールアドレスに対して送金を行う仕組みです。インボイスは長い文字列であるのに対して、Lightning Addressはメールアドレス形式であるため見やすく、支払い体験が非常にいいのが特徴です。

ただしLightning Addressは、裏側では相手のWebサーバーにアクセスしてインボイスを自動で取得しているため、インボイスが不要になるわけではありません。また、受け取る側がWebサーバー(またはそれを提供する事業者)を用意する必要がある点には注意が必要です。

LNURLとは?QRコードとLightning Addressでビットコイン支払いができる仕組みを解説
本記事ではLNURLやLightning Addressが使われるようになった理由や、送金・受金においてどのように内部処理が行われているかの詳細な仕組みについてを解説します。LN送金・受信のサービス提供や実装を検討している事業者やエンジニアの方は必読です。

2つ目は「Keysend」です。こちらは投げ銭や広告のような形で支払側が一方的に送金を行う際に使います。実はプリイメージを相手に送りつけることで送金を行うというトリッキーな方法を使っています。

Keysendとは?インボイスを発行せず送金する方法
ライトニングのKeysendとは、インボイスなしで相手の公開鍵だけで送れるプッシュ型の送金機能。仕組みと送金の流れ、LNDでの設定方法、ユースケース、レシートがない・インバウンドキャパシティが消費されるといった注意点まで解説します。

3つ目は「BOLT12 Offers」です。インボイスは1回きりの請求書であるのに対して、BOLT12 Offersは再利用が可能な支払い方法となっており、名前の通りBOLT12にて標準化されています。

BOLT12 Offersも、支払い時にはOfferをもとにライトニングネットワーク上で相手からインボイスを取得する仕組みです。Webサーバーを必要としない点がLightning Addressとの大きな違いです。

BOLT12の登場がついにライトニングネットワークにサブスクをもたらすのか
ライトニング決済でサブスクリプションが実現しづらかった理由と、BOLT12に当初含まれていたRecurring Payments構想を解説。仕様からは外れたものの普及との相乗効果を考察します。

番外編:ライトニングを補完する新たな技術について

以上でライトニングネットワークの解説は終わりです。最後まで読んでいただいた方は、ライトニングの全体像を理解することができたと思います。

この章ではライトニングネットワークを補完する最新技術の「Ark」と「Spark」について簡単に紹介します。

両者は共にライトニングのチャネル開設や流動性の管理、複雑なルーティングを不要としてビットコインを高速・低手数料で送ることのできるレイヤー2の送金技術であり、ライトニングネットワークとの間で送受金も請け負うことができます。

この2つの技術は非常に複雑で難解ですが、ビットコイン研究所では過去にいくつか解説記事を出していますので、よりラビットホールに吸い込まれたい方はぜひご覧ください。

Arkは何を変えるのか: Lightning Networkと比較した利点
本記事ではArkが日常的なビットコイン決済においてどのように優れ、Lightning Network送金と比較したメリット・デメリットを、なるべく簡単にユーザー目線で整理します。
Sparkプロトコル徹底解説|ステートチェーンとFROSTで実現するL2
Sparkプロトコルは高速送金が可能なビットコインのレイヤー2技術として注目されています。本記事ではSparkの仕様について、ステートチェーンや閾値署名などの要素技術を元に徹底的に解説します。

まとめ

ライトニングネットワークは、ビットコインのスケーラビリティ問題を緩和するために生まれた、ブロックチェーン外での送金の仕組みです。

2-of-2マルチシグのペイメントチャネルで資金をロックし、コミットメントトランザクションで状態を更新。HTLCによって送金は「成功か失敗か」のどちらかに定まり(アトミック性)、オニオンルーティングを使えば、直接チャネルのない相手にもトラストレスに送金できます。

その結果、ビットコインは高速・低手数料の決済手段として日常でも使えるようになりました。

ここで紹介したのは基礎の部分ですが、Lightning AddressやBOLT12 Offersといった新しい送金方法、Ark・Sparkのような補完技術によって、ライトニングは今も進化を続けています。ぜひ関連記事もあわせて読み、理解を深めてみてください。