Lightning Routing とは、Lightning ネットワークで支払いを届ける経路を探し、利用することです。経路を構成するのは決済チャネルです。参加者は Bitcoin 上で共同で資金をロックし、それぞれに帰属する金額を更新していきます。チャネルを管理するプログラムをノードと呼びます。通常、送信者は公開情報、受取人からの情報、過去の試行を基に経路を計画します。ただし、すべての最新残高が見えるわけではないため、その経路が使えるかを推定し、ときには別の経路を試す必要があります。
アンナはコーヒー代を払いたいのですが、カフェとのチャネルを持っていません。アンナにはパヴェルとのチャネルがあり、パヴェルにはカフェとの別のチャネルがあります。そのため支払いは彼を経由できます。最初のチャネルでは残高の一部がアンナからパヴェルへ、次のチャネルではパヴェルからカフェへ移ります。同じコインがチャネル間を移動するのではなく、それぞれの残高が連動して変わる仕組みです。したがってパヴェルには、カフェへ支払う側に自分の使える資金が必要です。送信者のウォレットやノードが受取人までの経路を選び、各段階への指示を用意します。受取人は必要な情報と対応機能を伝え、非公開の最終区間について情報を加えることもあります。途中のノードは指示に従って支払いを転送します。それぞれが目的地までの経路全体を探し直すわけではありません。 [1] [4]
Gossip はノード間で情報を広める仕組みです。BOLT #7 はチャネルの告知と方向別の更新を定め、基本手数料、金額に比例する手数料、CLTV の期限差、最小・最大金額、利用可否の表示を扱います。公表された条件だけでは、相手が今オンラインであることも、十分な資金があることも確認できません。ここでの CLTV は、時計の正確な時刻ではなく、Bitcoin のブロック高、つまりチェーン内でのブロックの位置で表す期限を指します。期限の間に差を設けることで、転送が止まった際に中継ノードが対応する時間を確保します。 [2]
チャネルの総容量からは、各側が今いくら送れるかは分かりません。送信者は自分のチャネルを把握していますが、それ以外は推定や成功・失敗の履歴を使います。そのためソフトウェアは手数料だけでなく通過の見込みも考えます。その間にも、別の支払いによって流動性、つまり必要な方向へ送れる資金が変わる可能性があります。 [4] [5]
各段階は HTLC という条件付きの支払いで結び付いています。完了には対応する秘密の値を明かす必要があり、完了しなかった場合には期限後に資金を取り戻せます。計算は受取人に届く金額から始まり、経路を逆にたどります。各中継ノードは、次のノードに渡す金額と自分の手数料を受け取る必要があります。受信側 HTLC の期限は、必要な CLTV の差に応じて送信側より十分に遅くなければなりません。長い経路では費用が増え、問題が起きた際に資金が拘束される時間も延びる場合があります。 [1] [2]
BOLT #4 の onion routing は Sphinx という構成を使い、各段階への指示を個別に暗号化します。中継ノードは前後の相手と自分への指示を知ります。パケットだけから経路全体、その長さ、自分の正確な位置が分かるわけではありません。ただし、通信の分析や複数ノードの協力により、プライバシーが弱まることはあります。 [1]
チャネルの一時的な不具合、手数料不足、不適切な CLTV、次の相手の停止や不明などで失敗します。送信者に届くエラー情報は限られています。ソフトウェアは経路の評価を下げ、計算し直して再試行できます。これはノードへ支払う罰金ではなく、一度の結果が信頼性の永久的な評価になるわけでもありません。 [1] [4]
接続が見つかるだけでは不十分です。各段階で HTLC を受け入れ、必要な方向に十分な利用可能資金がなければなりません。残高の一部は準備金として残す必要があったり、未完了の支払いに拘束されていたりします。また、技術項目 htlc_minimum_msat と htlc_maximum_msat は、その方向で扱う一つの HTLC の金額の下限と上限を定めます。単位 msat はサトシの千分の一で、サトシは Bitcoin のチェーン上で最小の金額単位です。公表された上限が大きくても、必要な流動性が今あるとは限りません。一つの不適切なチャネルだけで経路全体が使えなくなることもあります。 [2]
受取人が basic MPP、つまり一つの支払いを複数の部分に分ける仕組みに対応していれば、送信者はプロトコルで total_msat と表される合計金額を複数の経路に分割できます。受取人は必要な部分がそろうのを待ち、まとめて決済します。異なるチャネルに分散した流動性を使えますが、MPP が新しい流動性を生むわけではありません。HTLC や試行の数が増え、手数料が増えることもあります。 [1]
BOLT #11 の route hints は、公開されていない最後の数段階について送信者に情報を補います。BOLT #12 で使われる route blinding は、代わりに入口ノードである introduction point を経由する、暗号化された終端区間を提供します。送信者はなお入口までの利用可能な経路を見つけ、合計の手数料と CLTV 条件を満たす必要があります。プライバシーが向上しても、到達は保証されません。 [3] [6] [1]
普段の支払いでは、経路探しはウォレットが行います。以下の詳細は主にノード運営者や、繰り返し起きる問題の原因を調べる際に役立ちます。ソフトウェアとバージョン、金額、手数料と CLTV の上限、試行回数、利用経路、完了までの時間、正確な失敗理由を記録します。同じノードの組み合わせを近い時刻で比べてください。成功率が示すのは、特定のネットワーク状態での特定の支払いであり、永続的な総合点ではありません。 [4] [5]
理解を深めるには、この項目とあわせて次もお読みください Lightning Network, HTLC, Lightningの流動性, Payment Channel, Bitcoin, Inbound Liquidity. 次の項目からも参照されています HTLC, Lightningの流動性, BOLT 12, Inbound Liquidity.