Bitcoin VerityOtwórz porównywarkę

Poziom 10 · Weryfikacja i drugie warstwy

Routing Lightning, płynność i nieudane płatności

Jak nadawca buduje trasę, co widzi każdy pośrednik i dlaczego publiczny kanał nie gwarantuje przejścia płatności.

Artykuł
100
Czas czytania
19 minut
Zweryfikowano
10 września 2026 r.

Sedno w skrócie

Nadawca w Lightning wybiera trasy na podstawie ogłoszeń publicznych kanałów, opłat kierunkowych i wymagań czasowych. Routing cebulowy pokazuje każdemu hopowi tylko jego instrukcję i kolejny cel. Dokładnej płynności kierunkowej nie ma w publicznym grafie gossip, dlatego trasy są próbowane, a płatności mogą się nie udać.

01

Gossip tworzy niepełną mapę

BOLT 7 definiuje podpisane ogłoszenia węzłów, kanałów i kierunkowe aktualizacje. Zawierają status, opłatę bazową i proporcjonalną, limity HTLC oraz różnicę CLTV, z których nadawca buduje lokalny graf sieci.

Pojemność wyjścia funding jest widoczna on-chain, ale jej bieżący podział nie jest publiczny. Prywatnych kanałów brakuje w globalnym grafie. Mapa pokazuje więc możliwe krawędzie, nie gwarancję dla konkretnej kwoty.

02

Trasę oblicza się od końca

Zaczynając od żądanej kwoty i końcowego terminu, nadawca idąc wstecz dodaje opłatę oraz różnicę CLTV następnego węzła. Pierwszy HTLC niesie zatem większą kwotę i późniejszy termin niż ostatni.

Najtańsza trasa nie musi być najlepsza. Algorytmy portfeli mogą ważyć szansę sukcesu, liczbę hopów, ryzyko czasu, limity kanałów i poprzednie próby. Wybór trasy to polityka portfela, a nie jeden algorytm konsensusu Lightning.

03

Onion ujawnia jeden krok

BOLT 4 używa warstwowego pakietu Sphinx. Każdy hop zdejmuje swoją warstwę, poznaje kanał wyjściowy, kwotę i termin, po czym przekazuje zmieniony pakiet. Nie widzi automatycznie całej trasy ani instrukcji pozostałych hopów.

Nie zapewnia to doskonałej anonimowości. Pierwszy hop zna wysyłającego peera, ostatni wskazuje kierunek odbiorcy, a wskazówek dostarczają czas, kwoty, topologia czy kontrolowane węzły. Powtarzane nieudane próby także ujawniają informacje.

04

Niepowodzenie jest częścią szukania trasy

Płatność może zawieść przez płynność kierunkową, nieaktualną informację, wyłączony węzeł, limity HTLC, opłatę lub czas. Zaszyfrowany błąd pozwala nadawcy poprawić lokalny obraz i spróbować innej trasy bez częściowego rozliczenia płatności.

Portfel może podzielić płatność na kilka ścieżek, lecz każda część nadal wymaga działającej trasy i zgodnego odbiorcy. Lepsza płynność oraz ponowne próby zwiększają prawdopodobieństwo, ale nie dają pewności.

Poziom 10 · Weryfikacja i drugie warstwy

Pojęcia, które warto znać

Gossip
Podpisane ogłoszenia P2P, z których węzły budują publiczny graf Lightning.
Onion routing
Warstwowy routing, w którym każdy hop odsłania tylko własne instrukcje.
Płynność kierunkowa
Kwota, którą można w danej chwili wysłać w jednym kierunku przez kanał.

Częsty błąd

Jeżeli mapa pokazuje połączone węzły i wystarczającą pojemność, płatność musi przejść.

Dokładniejsze wyjaśnienie

Publiczny graf nie ujawnia dokładnych sald kierunkowych ani bieżącej dostępności. Pokazuje trasy kandydujące, które podczas próby mogą zawieść.

Dokładniejsze wyjaśnienie

Czy próbowanie tras nie jest nieefektywne?

To część kompromisu wynikającego z niepublikowania każdego salda kanału. Portfele łączą gossip, wcześniejsze wyniki, ocenę prawdopodobieństwa i wiele ścieżek, aby ograniczyć liczbę prób.

100

Najważniejsze wnioski

  1. 01Gossip opisuje publiczne kanały i reguły kierunkowe.
  2. 02Dokładny rozkład płynności pozostaje niepubliczny.
  3. 03Pakiet onion pokazuje hopowi tylko następny krok.
  4. 04Alternatywne trasy i podział zwiększają szanse, nie pewność.

Podsumowanie jak dla dziecka

Najprościej jak się da

Mapa Lightning pokazuje możliwe drogi, ale nie dokładną kwotę dostępną teraz w każdym kierunku. Każdy pośrednik widzi tylko kolejny krok, więc portfel może próbować kilku tras, a płatność nadal może się nie udać.

Zweryfikowano: 10 września 2026 r.

Źródła i dalsza lektura

Źródła potwierdzają konkretne fakty i definicje; ich wskazanie nie oznacza, że redakcja podziela wszystkie poglądy autora.

01
BOLT 4: onion routingLightning Network Specifications
github.com
02
BOLT 7: wykrywanie węzłów i kanałówLightning Network Specifications
github.com
03
BOLT 11: kodowanie żądań płatnościLightning Network Specifications
github.com
04
BOLT 2: przekazywanie HTLCLightning Network Specifications
github.com

Materiał edukacyjny, nie rekomendacja inwestycyjna.