Lightning Networkでは通常、送信者が経路を構築します。公開gossipグラフ、受取人が示す情報、自身の結果から宛先へのpathを推定し、各hopの金額・fee・CLTVを終点から逆算してonion packetへ格納し、失敗すれば別経路を試します。公開グラフは現在の残高配分を示さないため、routingは不完全かつ急変する情報に基づく確率的判断です。
Routingはpayer側から始まります。walletまたはnodeがpayeeへの候補pathを選び、各中継者に次のchannelを指定します。受取人はidentity、features、必要に応じroute hintsやblinded pathsを示しますが、公開部分は通常送信者が計算します。
BOLT #7はchannel announcementsと方向別channel updatesを伝播し、base fee、比例fee、CLTV delta、最小・最大値、可用性を示します。これは公開policyとtopologyであり、peerのonline状態や現在の十分な流動性を証明しません。
公開gossipはchannel両側のbalance配分を明かしません。Routerは既知のローカル流動性、capacity、過去の成功・失敗、penalty、実装固有のscoringを組み合わせます。理論上最安のpathが最も成功しやすいとは限りません。
金額とexpiryはpayeeからpayerへ逆向きに組み立てます。各hopへのincoming amountは次のhop分と自身のfeeを含み、incoming CLTVは公開deltaだけoutgoing CLTVより大きくなります。hopが増えるほど総feeとtimelock余裕が増えます。
BOLT #4はonion routingを採用します。payerは各hop専用の暗号化payloadを持つSphinx packetを作ります。中継nodeは隣接peerと自分の指示だけを知り、path全体、長さ、位置は知りませんが、traffic analysisや共謀のリスクは残ります。
一時的channel failure、fee不足、誤ったCLTV、未知のnext peerは限定的なfailure signalをpayerへ返します。実装は候補をpenalizeして再計算・再試行できますが、その結果は変化するchannelを永久には表しません。
全hopがHTLCを受け入れ、reserve、pending HTLC、htlc_minimum_msat、htlc_maximum_msatを考慮した正方向の流動性を持つ必要があります。大きな総capacityや多数のconnectionsでも、一つの不均衡channelは解消できません。
Invoiceがbasic MPPを対応する場合、payerはtotal_msatを複数pathsへ分け、受取人が一組として決済します。MPPは分散流動性を使えますが、HTLC、試行、feesを増やし、方向別capacityを作りません。
BOLT 11 route hintsは末端の非公開hopsを示せます。BOLT 12とroute blindingはintroduction point経由の暗号化末尾を提供します。それでもpayerは最初の既知点まで到達し、集約feeとCLTV条件を満たす必要があります。
実装とversion、amount、最大feeとCLTV、attempt数、使用paths、完了時間、正確なfailure reasonを記録します。同じnodeペアを近い時点で比較してください。成功は特定の支払いとnetwork stateに属し、永続的な全体scoreではありません。 出典: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
理解を深めるには、この項目とあわせて次もお読みください Lightning Network, HTLC, Lightningの流動性, Payment Channel, Bitcoin, Inbound Liquidity. 次の項目からも参照されています HTLC, Lightningの流動性, BOLT 12, Inbound Liquidity.