这是一种多层 source routing：发送方创建包含目标、金额、手续费预算和 CLTV 预算的内部 trampoline onion，再用普通 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 节点：它们按 BOLT #4 处理标准 onion 和 HTLC。Trampoline node 填补路径空白，但无法更改金额、时间条件或最终支付秘密而不触发后续校验失败。 [2]
委托不等于托管。Trampoline node 不会得到 seed、私钥或单方面花费通道资金的权利；但它可以拒绝或拖延支付、选择糟糕或昂贵的路径，并观察本段元数据。钱包必须强制执行手续费和 CLTV 预算、payment secret、加密错误与重试规则。 [1]
截至 2026 年十月初，公开的 BOLTs 提案 #836 仍处于开放状态，而 Eclair 与 lightning-kmp 已提到实现较新的提案格式并从旧实验协议迁移。这说明存在真实部署，但不代表全网互操作已经完成；当前 Eclair 配置也把一般支付开关与 prototype feature flag 分开。 [5]
BOLT #4 保护各 onion 层的内容，并只让一个 hop 知道前驱和后继，但不会自动隐藏全部元数据。单一 trampoline 服务商可能知道发送客户端，并在转接给不支持 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 隐私.
01Trampoline node 能窃取闪电支付吗？+
仅委托寻路不会给它私钥，也不能让它绕过支付条件。但它仍可拒绝、拖延、尝试昂贵路径或收集元数据。钱包必须限制手续费和 CLTV，验证 onion 与 payment secret，并能更换节点或重试。
02Trampoline Routing 与 LSP 相同吗？+
不同。LSP 是可提供连接、通道与流动性的运营角色；trampoline node 计算受托的路径段。同一运营者可以兼任，但协议角色不同，集中在一家服务也会增加可用性和隐私依赖。