To wielopoziomowy source routing: nadawca tworzy wewnętrzny trampoline onion z celem, kwotą oraz budżetem opłaty i CLTV, dostarcza go zwykłym onionem do pierwszego trampoline node, a ten oblicza konkretną trasę pośrednią do kolejnego trampoline hop lub odbiorcy; każdy delegowany węzeł zna tylko swoją część zadania.
Zwykły Lightning source routing zakłada, że nadawca zna użyteczny graf sieci i sam wybiera każdy hop. Dla telefonu często będącego offline oznacza to pobieranie i przycinanie channel gossip oraz liczenie trasy przed płatnością; Trampoline Routing przenosi tę pracę na kilka węzłów z aktualniejszym obrazem sieci, a nie pieczę nad kluczami lub kanałami. [6]
Nadawca wybiera pierwszy trampoline node, ustala kwotę, cel końcowy oraz budżet opłaty i CLTV, po czym tworzy trampoline onion. Zwykły payment onion dostarcza mniejszy onion do węzła; ten odsłania tylko instrukcję dla następnego trampoline hop, znajduje konkretną drogę przez zwykłe węzły i pakuje pozostały onion dla kolejnego odcinka. [1]
Między dwoma trampoline nodes mogą działać zwykłe węzły Lightning bez obsługi propozycji: przetwarzają standardowy onion i HTLC według BOLT #4. Trampoline node wypełnia lukę w trasie, ale nie może zmienić kwoty, warunków czasowych ani końcowego sekretu płatności bez niepowodzenia późniejszej kontroli. [2]
Delegowanie nie jest powiernictwem. Trampoline node nie otrzymuje seed, klucza prywatnego ani jednostronnego prawa wydania środków z kanału; może jednak odmówić lub opóźnić płatność, wybrać złą bądź drogą trasę i obserwować metadane swojego odcinka. Portfel musi egzekwować budżety opłaty i CLTV, payment secret, szyfrowane błędy oraz ponowienia. [1]
Na początku października 2026 publiczna propozycja BOLTs #836 pozostaje otwarta, podczas gdy Eclair i lightning-kmp wskazują już implementację nowszego proponowanego formatu i przejście ze starszego protokołu eksperymentalnego. Dowodzi to realnego wdrażania, a nie pełnej interoperacyjności całej sieci; obecna konfiguracja Eclair rozdziela też ogólne włączenie płatności od prototype feature flag. [5]
BOLT #4 chroni treść warstw i ujawnia hopowi tylko poprzednika i następcę, ale nie ukrywa automatycznie wszystkich metadanych. Jeden dostawca trampoline może znać klienta wysyłającego, a przy przekazaniu do odbiorcy bez obsługi także cel; kilka trampoline hops i blinded path mogą rozdzielić tę wiedzę, lecz czas, kwota i ponowne użycie nadal pozwalają korelować. [2]
Route blinding można połączyć z trampoline, umieszczając outgoing_node_id zamiast outgoing_channel_id w zaszyfrowanych danych. Trampoline node odszyfrowuje tylko następny węzeł i wyznacza drogę do niego; odbiorca może ukryć swój odcinek i pozwolić na ponowne szukanie przy chwilowym braku płynności. [4]
Weryfikacja portfela wymaga sprawdzenia, czy faktycznie ogranicza gossip, jak wybiera trampoline nodes, jakich feature bits i onion TLV używa, czy format jest stary czy proponowany, jak egzekwuje budżety opłaty i CLTV, obsługuje błędy i MPP oraz czy cel bez obsługi ujawnia węzłowi więcej, niż oczekuje użytkownik. [3]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Prywatność w Bitcoinie.
01Czy trampoline node może ukraść płatność Lightning?+
Samo delegowanie trasy nie daje mu kluczy prywatnych ani sposobu obejścia warunków płatności. Może jednak odmówić, opóźnić, próbować drogich tras lub zbierać metadane. Portfel musi ograniczać opłatę i CLTV, sprawdzać onion oraz payment secret i potrafić wybrać inny węzeł lub próbę.
02Czy Trampoline Routing to to samo co LSP?+
Nie. LSP to rola operacyjna zapewniająca na przykład łączność, kanał i płynność; trampoline node oblicza delegowany odcinek trasy. Jeden operator może pełnić obie role, ale są różne, a ich skupienie zwiększa zależność dostępności i prywatności.