W Lightning Network trasę zwykle buduje nadawca. Z publicznego grafu gossip, danych odbiorcy i własnych wyników szacuje ścieżkę do celu; wstecz oblicza kwotę, fee i CLTV każdego hopu, pakuje instrukcje do onion packet i po błędzie próbuje innej drogi. Ponieważ graf nie pokazuje aktualnego podziału sald, routing jest decyzją probabilistyczną przy niepełnej i zmiennej informacji.
Routing zaczyna payer: jego wallet lub node wybiera path do payee i wskazuje następny channel każdemu pośrednikowi. Odbiorca podaje tożsamość, features i ewentualne route hints lub blinded paths; część publiczną zwykle liczy nadawca.
BOLT #7 rozsyła announcements i kierunkowe channel updates z base fee, fee proporcjonalnym, CLTV delta, minimum, maksimum i dostępnością. Opisują policy i topologię, ale nie dowodzą stanu online ani bieżącej płynności.
Gossip nie ujawnia podziału balance. Router łączy znaną lokalną płynność, capacity, wcześniejsze sukcesy, błędy, kary i własny scoring. Najtańsza teoretycznie ścieżka nie musi być najbardziej prawdopodobna.
Kwoty i expiry buduje się wstecz od payee. Każdy hop otrzymuje kwotę kolejnego plus własne fee i CLTV większe o jego delta; więcej hopów zwiększa koszt i margines timelock.
BOLT #4 stosuje onion routing: payer tworzy pakiet Sphinx z osobno szyfrowanym payloadem dla hopu. Pośrednik zna sąsiadów i instrukcję, nie całą ścieżkę, długość ani pozycję; analiza ruchu i zmowa nadal zagrażają.
Tymczasowy błąd kanału, zbyt małe fee, błędne CLTV lub nieznany next peer zwracają ograniczony sygnał. Implementacja może ukarać kandydata, przeliczyć i ponowić; wynik nie opisuje kanału na stałe.
Każdy hop musi przyjąć HTLC i mieć płynność w dobrym kierunku po rezerwach, pending HTLC i limitach min/max. Duża łączna capacity ani wiele connections nie usuwa jednego źle zbalansowanego bottlenecku.
Basic MPP dzieli total_msat na kilka paths rozliczanych razem przez odbiorcę. Wykorzystuje rozproszoną płynność, lecz dodaje HTLC, próby i fees i nie tworzy capacity.
Route hints BOLT 11 pokazują końcowe prywatne hopy; BOLT 12 i route blinding dostarczają zaszyfrowany koniec przez introduction point. Payer nadal musi tam dotrzeć i spełnić łączne fee oraz CLTV.
Zapisuj implementację, wersję, amount, limity fee i CLTV, próby, paths, czas i dokładny błąd. Porównuj tę samą parę nodes w podobnym czasie: sukces dotyczy konkretnej płatności i stanu sieci. Źródła: 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.
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, HTLC, Płynność Lightning, Payment Channel, Bitcoin, Inbound Liquidity. Do tego hasła prowadzą również odsyłacze z HTLC, Płynność Lightning, BOLT 12, Inbound Liquidity.