Es ist mehrstufiges Source Routing: Der Sender erstellt eine innere Trampoline-Onion mit Ziel, Betrag sowie Gebühren- und CLTV-Budget, transportiert sie in einer normalen Onion zum ersten Trampoline Node, und dieser berechnet den konkreten Zwischenpfad zum nächsten Trampoline Hop oder Empfänger; jeder delegierte Node kennt nur seinen Aufgabenteil.
Normales Lightning Source Routing setzt voraus, dass der Sender einen nutzbaren Netzwerkgraphen kennt und jeden Hop selbst auswählt. Für ein oft offline befindliches Telefon bedeutet das, Channel Gossip herunterzuladen und zu bereinigen sowie vor der Zahlung eine Route zu berechnen; Trampoline Routing verlagert diese Arbeit auf mehrere Nodes mit aktuellerem Netzblick, nicht die Verwahrung von Schlüsseln oder Channels. [6]
Der Sender wählt den ersten Trampoline Node, legt Betrag, Endziel sowie Gebühren- und CLTV-Budget fest und erzeugt eine Trampoline-Onion. Eine normale Payment-Onion bringt diese kleinere Onion zum Node; er legt nur die Anweisung für den nächsten Trampoline Hop frei, findet über normale Nodes einen konkreten Pfad und verpackt die verbleibende Onion für den nächsten Abschnitt neu. [1]
Zwischen zwei Trampoline Nodes können gewöhnliche Lightning Nodes liegen, die den Vorschlag nicht unterstützen: Sie verarbeiten eine Standard-Onion und einen HTLC gemäß BOLT #4. Der Trampoline Node schließt die Lücke, kann aber Betrag, Zeitbedingungen oder das endgültige Zahlungsgeheimnis nicht ändern, ohne dass eine spätere Prüfung scheitert. [2]
Delegation ist keine Verwahrung. Ein Trampoline Node erhält weder Seed noch privaten Schlüssel oder ein einseitiges Ausgaberecht am Channel; er kann jedoch die Zahlung ablehnen oder verzögern, einen schlechten oder teuren Pfad wählen und Metadaten seines Abschnitts beobachten. Die Wallet muss Gebühren- und CLTV-Budget, Payment Secret, verschlüsselte Fehler und Wiederholungen erzwingen. [1]
Anfang Oktober 2026 ist der öffentliche BOLTs-Vorschlag #836 weiterhin offen, während Eclair und lightning-kmp bereits auf die Implementierung des neueren vorgeschlagenen Formats und den Übergang vom älteren experimentellen Protokoll verweisen. Das belegt reale Einführung, nicht fertige netzweite Interoperabilität; die aktuelle Eclair-Konfiguration trennt außerdem allgemeine Zahlungsfreigabe und einen Prototype Feature Flag. [5]
BOLT #4 schützt die Inhalte der Onion-Schichten und zeigt einem Hop nur Vorgänger und Nachfolger, verbirgt aber nicht automatisch alle Metadaten. Ein einzelner Trampoline-Anbieter kann den sendenden Client und beim Übergang zu einem Empfänger ohne Unterstützung auch das Ziel kennen; mehrere Trampoline Hops und ein Blinded Path können dieses Wissen verteilen, während Zeit, Betrag und Wiederverwendung korrelierbar bleiben. [2]
Route Blinding lässt sich mit Trampoline kombinieren, indem verschlüsselte Daten outgoing_node_id statt outgoing_channel_id enthalten. Ein Trampoline Node entschlüsselt nur den nächsten Node und berechnet den Pfad dorthin; der Empfänger kann seinen Abschnitt verbergen und bei vorübergehend fehlender Liquidität neue Pfadsuchen erlauben. [4]
Zur Prüfung einer Wallet muss man klären, ob sie Gossip wirklich begrenzt, wie sie Trampoline Nodes auswählt, welche Feature Bits und Onion TLVs sie nutzt, ob das Format alt oder vorgeschlagen ist, wie Gebühren- und CLTV-Budgets, Fehler und MPP behandelt werden und ob ein Ziel ohne Unterstützung dem Node mehr verrät als erwartet. [3]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Bitcoin-Privatsphäre.
01Kann ein Trampoline Node eine Lightning-Zahlung stehlen?+
Die delegierte Pfadsuche gibt ihm weder private Schlüssel noch eine Möglichkeit, Zahlungsbedingungen zu umgehen. Er kann aber ablehnen, verzögern, teure Pfade versuchen oder Metadaten sammeln. Die Wallet muss Gebühren und CLTV begrenzen, Onion und Payment Secret prüfen und einen anderen Node oder Versuch wählen können.
02Ist Trampoline Routing dasselbe wie ein LSP?+
Nein. Ein LSP ist eine Betriebsrolle, die etwa Verbindung, Channel und Liquidität bereitstellt; ein Trampoline Node berechnet einen delegierten Routenabschnitt. Ein Betreiber kann beides tun, doch die Rollen sind verschieden und ihre Bündelung erhöht die Abhängigkeit bei Verfügbarkeit und Datenschutz.