Это многоуровневый 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 и уметь выбрать другой узел или попытку.
02Trampoline Routing и LSP — одно и то же?+
Нет. LSP — операционная роль, способная предоставлять соединение, канал и ликвидность; trampoline node рассчитывает делегированный участок маршрута. Один оператор может выполнять обе роли, но они различны, а их концентрация усиливает зависимость доступности и приватности.