É source routing em vários níveis: o remetente cria uma trampoline onion interna com destino, valor e orçamentos de taxa e CLTV, leva-a numa onion comum ao primeiro trampoline node, que calcula o caminho intermediário concreto até o próximo trampoline hop ou destinatário; cada nó delegado conhece apenas sua parte.
O source routing comum da Lightning pressupõe que o remetente conheça um grafo utilizável e escolha cada hop. Para um celular frequentemente offline, isso exige baixar e podar channel gossip e calcular a rota antes do pagamento; Trampoline Routing transfere esse trabalho a vários nós com visão mais atual da rede, não a custódia de chaves ou canais. [6]
O remetente escolhe o primeiro trampoline node, define valor, destino final e orçamentos de taxa e CLTV e cria uma trampoline onion. Uma payment onion comum leva essa onion menor ao nó; ele revela somente a instrução para o próximo trampoline hop, encontra um caminho concreto por nós comuns e reempacota a onion restante para o trecho seguinte. [1]
Entre dois trampoline nodes podem existir nós Lightning comuns sem suporte à proposta: eles processam onion e HTLC padrão conforme BOLT #4. O trampoline node preenche a lacuna da rota, mas não pode mudar valor, condições de tempo ou segredo final sem causar falha numa verificação posterior. [2]
Delegação não é custódia. O trampoline node não recebe seed, chave privada nem direito unilateral de gastar do canal; ainda pode recusar ou atrasar o pagamento, escolher rota ruim ou cara e observar metadados do trecho. A carteira deve impor orçamentos de taxa e CLTV, payment secret, erros cifrados e novas tentativas. [1]
No início de outubro de 2026, a proposta pública BOLTs #836 continua aberta, enquanto Eclair e lightning-kmp já citam a implementação do formato proposto mais novo e a migração do protocolo experimental antigo. Isso mostra implantação real, não interoperabilidade concluída em toda a rede; a configuração atual do Eclair também separa a habilitação geral de pagamentos de um prototype feature flag. [5]
BOLT #4 protege o conteúdo das camadas e revela a um hop apenas predecessor e sucessor, mas não oculta automaticamente todos os metadados. Um único provedor trampoline pode conhecer o cliente remetente e, ao encaminhar para destinatário sem suporte, o destino; vários trampoline hops e blinded path podem dividir esse conhecimento, mas tempo, valor e reutilização continuam correlacionáveis. [2]
Route blinding combina-se com trampoline usando outgoing_node_id em vez de outgoing_channel_id nos dados cifrados. O trampoline node decifra apenas o próximo nó e calcula a rota até ele; o destinatário pode ocultar seu trecho e permitir novas buscas durante falta temporária de liquidez. [4]
Verificar uma carteira exige conferir se ela realmente limita gossip, como escolhe trampoline nodes, quais feature bits e onion TLV usa, se o formato é antigo ou proposto, como impõe orçamentos de taxa e CLTV, trata erros e MPP e se um destino sem suporte revela ao nó mais do que o usuário espera. [3]
Para ter uma visão mais completa, leia este verbete junto com Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Privacidade no Bitcoin.
01Um trampoline node pode roubar um pagamento Lightning?+
Delegar a rota não lhe dá chaves privadas nem forma de contornar as condições. Ele ainda pode recusar, atrasar, tentar rotas caras ou coletar metadados. A carteira deve limitar taxa e CLTV, validar onion e payment secret e conseguir trocar de nó ou tentativa.
02Trampoline Routing é o mesmo que LSP?+
Não. LSP é uma função operacional que pode fornecer conectividade, canal e liquidez; trampoline node calcula um trecho delegado. Um operador pode exercer ambos, mas são papéis distintos e concentrá-los aumenta dependência de disponibilidade e privacidade.