Jde o víceúrovňové source routing: odesílatel sestaví vnitřní trampoline onion s cílem, částkou a rozpočtem poplatku a CLTV, dopraví jej běžným onionem k prvnímu trampoline uzlu a ten dopočítá konkrétní mezilehlou cestu k dalšímu trampoline hopu nebo příjemci; každý delegovaný uzel zná jen svou část úkolu.
Běžné Lightning source routing předpokládá, že odesílatel zná použitelný síťový graf a sám vybere každý hop. Pro telefon, který bývá offline, to znamená stahovat a prořezávat channel gossip a počítat trasu před platbou; Trampoline Routing přesouvá tuto práci na několik uzlů s aktuálnějším pohledem na síť, nikoli správu klíčů nebo kanálu. [6]
Odesílatel vybere první trampoline node, stanoví částku, konečný cíl a rozpočty poplatku a CLTV a vytvoří trampoline onion. Běžný payment onion dopraví tento menší onion k trampoline uzlu; ten odhalí jen instrukci pro další trampoline hop, najde k němu konkrétní cestu přes běžné uzly a přebalí zbývající onion pro další úsek. [1]
Mezi dvěma trampoline uzly mohou ležet běžné Lightning uzly, které návrh podporovat nemusí: zpracují standardní onion a HTLC podle BOLT #4. Trampoline uzel tím vyplňuje mezeru v trase, ale nemůže změnit částku, časové podmínky nebo konečné platební tajemství bez toho, aby další kontrola selhala. [2]
Delegace není úschova. Trampoline node nedostává seed, privátní klíč ani jednostranné právo utratit z kanálu; může však platbu odmítnout, zdržet, vybrat špatnou nebo drahou cestu a pozorovat metadata svého úseku. Peněženka proto musí vynutit fee budget, CLTV budget, payment secret a správně zpracovat šifrované chyby a opakování pokusu. [1]
Na začátku října 2026 zůstává veřejný BOLTs návrh #836 otevřený, zatímco Eclair a lightning-kmp už odkazují na implementaci novějšího navrženého formátu a přechod od staršího experimentálního protokolu. To dokládá reálné nasazování, nikoli hotovou interoperabilitu celé sítě; současná konfigurace Eclair navíc odděluje obecné povolení plateb a prototypový feature flag. [5]
Základní BOLT #4 chrání obsah vrstev a odhaluje hopu jen předchůdce a nástupce, nikoli však automaticky veškerá metadata. Jediný trampoline poskytovatel může znát odesílajícího klienta a při přechodu na příjemce bez podpory trampoline také cíl; více trampoline hopů a blinded path mohou znalost rozdělit, ale časování, částka a opakované použití zůstávají korelačními signály. [2]
Route blinding lze s trampoline kombinovat tak, že šifrovaná data nesou outgoing_node_id místo outgoing_channel_id. Trampoline uzel rozšifruje jen následující trampoline node a dopočítá cestu k němu; příjemce tak může skrýt svou část trasy a přitom nechat uzel opakovat hledání při dočasném nedostatku likvidity. [4]
Ověření konkrétní peněženky vyžaduje sledovat, zda opravdu omezuje gossip, jak vybírá trampoline uzly, jaké feature bits a onion TLV používá, zda jde o starší nebo navržený formát, jak vynucuje fee a CLTV rozpočty, jak zachází s chybami a MPP a zda při cíli bez podpory neprozradí trampoline uzlu více, než uživatel očekává. [3]
Pro nejúplnější obraz čtěte toto heslo společně s Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Soukromí v Bitcoinu.
01Může trampoline node ukrást Lightning platbu?+
Samotná delegace hledání trasy mu nedává privátní klíče ani možnost obejít platební podmínky. Může ale platbu odmítat, zdržovat, zkoušet drahé trasy nebo sbírat metadata. Peněženka proto musí omezit poplatek a CLTV, ověřovat onion a platební tajemství a umět zvolit jiný uzel nebo pokus.
02Je Trampoline Routing totéž co LSP?+
Ne. LSP je provozní role poskytující například konektivitu, kanál a likviditu; trampoline node delegovaně počítá část trasy. Jeden provozovatel může dělat obojí, ale protokolové role jsou odlišné a jejich soustředění u jedné služby zvyšuje dostupnostní i soukromostní závislost.