V Lightning Network sestavuje trasu obvykle odesílatel. Z veřejného gossip grafu, údajů od příjemce a vlastních výsledků odhaduje cestu k cíli; pro každý hop počítá částku, fee a CLTV odzadu, zabalí instrukce do onion packetu a při selhání zkouší jinou cestu. Protože veřejný graf neukazuje aktuální rozdělení zůstatků, je routing pravděpodobnostní rozhodování nad neúplnými a rychle se měnícími informacemi.
Routing začíná u payera, nikoli u routing nodů: jeho wallet nebo node zvolí kandidátní path k payee a každému mezilehlému nodu určí následující channel. Příjemce dodá identitu, vlastnosti a případně route hints či blinded paths, ale veřejnou část trasy k němu běžně dopočítá odesílatel.
BOLT #7 šíří channel announcements a směrové channel updates s base fee, proportional fee, CLTV delta, minimem, maximem a příznakem dostupnosti. Tyto údaje popisují nabídnutou forwarding policy a topologii; nepotvrzují, že je peer online ani že má channel právě dost likvidity pro zvolenou částku.
Veřejný gossip neprozrazuje rozdělení balance mezi stranami channelu. Router proto kombinuje známou lokální likviditu, kapacitu, starší úspěchy a chyby, penalizace a implementační scoring. Nejlevnější teoretická cesta tak nemusí mít nejvyšší pravděpodobnost úspěchu.
Částky a expirace se skládají odzadu od payee k payerovi. Každý forwarding node musí dostat incoming amount pokrývající částku pro další hop plus vlastní fee a incoming CLTV dost vzdálené od outgoing CLTV o zveřejněné delta; delší cesta proto zvyšuje souhrnný fee i časový prostor uzamčení.
BOLT #4 používá onion routing: payer vytvoří Sphinx packet s odděleným šifrovaným payloadem pro každý hop. Mezilehlý node zjistí předchozího a následujícího peeru a své forwarding instrukce, ne však celou path, její délku ani přesnou pozici; traffic analysis a koluze přesto mohou část soukromí oslabit.
Dočasná chyba kanálu, nedostatečné fee, nesprávné CLTV nebo neznámý next peer vrátí payerovi omezený failure signal. Implementace může kandidáta dočasně penalizovat, přepočítat route a payment zopakovat; jeden úspěch ani neúspěch není trvalý popis channelu, protože jeho stav se mezitím mění.
Payment projde jen tehdy, když každý hop přijme HTLC a má správným směrem dost použitelné liquidity po započtení rezerv, pending HTLC a limitů htlc_minimum_msat a htlc_maximum_msat. Vysoká celková capacity nebo mnoho connections neodstraňují bottleneck jediného nevhodně vyváženého channelu.
Pokud invoice podporuje basic MPP, může payer rozdělit total_msat mezi několik paths a příjemce je vypořádá jako jeden celek. MPP může obejít limit jednoho channelu a využít rozptýlenou liquidity, ale přidává více HTLC, pokusů a fees a stále vyžaduje dost souhrnné směrové kapacity.
BOLT 11 route hints mohou zpřístupnit poslední neveřejné hops; BOLT 12 a route blinding dovolují příjemci předat šifrovaný konec trasy přes introduction point. Tyto mechanismy zlepšují dosažitelnost a soukromí, ale payer stále musí najít použitelnou cestu k prvnímu známému bodu a respektovat agregované fee a CLTV podmínky.
Při ověřování zaznamenejte implementaci a verzi, amount, maximální fee a CLTV limit, počet attempts, použité paths, dobu dokončení a přesný failure reason. Srovnávejte stejnou dvojici uzlů v podobném čase; routing success je vlastnost konkrétní platby a stavu sítě, nikoli trvalé globální skóre. Prameny: 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.
Pro nejúplnější obraz čtěte toto heslo společně s Lightning Network, HTLC, Lightningová likvidita, Payment Channel, Bitcoin, Inbound Liquidity. Opačným směrem na něj odkazují také HTLC, Lightningová likvidita, BOLT 12, Inbound Liquidity.