Це багаторівневий source routing: відправник створює внутрішній trampoline onion із ціллю, сумою та бюджетами комісії й CLTV, доставляє його звичайним onion до першого trampoline node, а той обчислює конкретний проміжний шлях до наступного trampoline hop або одержувача; кожен делегований вузол знає лише свою частину завдання.
Звичайний Lightning source routing передбачає, що відправник знає придатний граф мережі й сам обирає кожен hop. Для телефона, який часто офлайн, це означає завантажувати й очищати channel gossip та рахувати маршрут перед платежем; Trampoline Routing переносить цю роботу на кілька вузлів з актуальнішим баченням мережі, а не передає їм ключі чи канали. [6]
Відправник обирає перший trampoline node, задає суму, кінцеву ціль і бюджети комісії та CLTV і створює trampoline onion. Звичайний payment onion доставляє менший onion до вузла; той відкриває лише інструкцію для наступного trampoline hop, знаходить конкретний шлях через звичайні вузли й перепаковує решту onion для наступної ділянки. [1]
Між двома trampoline nodes можуть бути звичайні Lightning-вузли без підтримки пропозиції: вони обробляють стандартний onion і HTLC за BOLT #4. Trampoline node заповнює прогалину маршруту, але не може змінити суму, часові умови чи кінцевий платіжний секрет так, щоб наступна перевірка цього не виявила. [2]
Делегування не є зберіганням коштів. Trampoline node не отримує seed, приватний ключ або одностороннє право витрачати з каналу; однак він може відхилити чи затримати платіж, обрати поганий або дорогий шлях і бачити метадані своєї ділянки. Гаманець має примусово обмежувати бюджети комісії й CLTV, перевіряти payment secret, зашифровані помилки та повторні спроби. [1]
На початку жовтня 2026 року публічна пропозиція BOLTs #836 лишається відкритою, тоді як Eclair і lightning-kmp уже посилаються на реалізацію новішого запропонованого формату та перехід зі старого експериментального протоколу. Це доводить реальне розгортання, але не завершену сумісність усієї мережі; поточна конфігурація Eclair також розділяє загальне ввімкнення платежів і prototype feature flag. [5]
BOLT #4 захищає вміст шарів і відкриває hop лише попередника та наступника, але не приховує автоматично всі метадані. Єдиний trampoline-провайдер може знати клієнта-відправника й, при переході до одержувача без підтримки, ціль; кілька trampoline hops і blinded path можуть розділити ці знання, хоча час, сума та повторне використання лишаються сигналами кореляції. [2]
Route blinding можна поєднати з trampoline, записавши в зашифровані дані outgoing_node_id замість outgoing_channel_id. Trampoline node розшифровує лише наступний вузол і рахує шлях до нього; одержувач може приховати свою ділянку маршруту й дозволити повторний пошук за тимчасової нестачі ліквідності. [4]
Перевірка гаманця вимагає з’ясувати, чи справді він обмежує gossip, як обирає trampoline nodes, які feature bits та onion TLV використовує, чи формат старий або запропонований, як застосовує бюджети комісії й CLTV, обробляє помилки та MPP і чи ціль без підтримки розкриває вузлу більше, ніж очікує користувач. [3]
Для повної картини прочитайте також Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Приватність у Bitcoin.
01Чи може trampoline node украсти Lightning-платіж?+
Саме делегування пошуку маршруту не дає йому приватних ключів або способу обійти умови платежу. Він усе ж може відмовити, затримати, спробувати дорогі шляхи чи збирати метадані. Гаманець має обмежувати комісію й CLTV, перевіряти onion і payment secret та вміти обрати інший вузол або спробу.
02Чи Trampoline Routing — те саме, що LSP?+
Ні. LSP — операційна роль, що може надавати з’єднання, канал і ліквідність; trampoline node обчислює делеговану ділянку маршруту. Один оператор може виконувати обидві ролі, але вони різні, а їх поєднання посилює залежність доступності й приватності.