Trampoline Routing 蹦床路由

Traditional Source Routing:

Sender requirements:
1. Complete network graph (~50-100 MB)
2. Continuously sync gossip messages
3. Calculate optimal path to destination
4. Build complete onion packet

Impact on mobile wallets:
• Storage: need large space for graph
• Bandwidth: constantly downloading channel_update
• Battery: path calculation consumes CPU
• Time: initial sync takes long time
• Staleness: graph may be outdated after offline

Problem example:
User opens App -> needs sync -> waits minutes -> finally can pay
This is disastrous for user experience!

Trampoline 路由架構：

┌──────────┐    ┌───────────┐    ┌───────────┐    ┌──────────┐
│  Alice   │───>│Trampoline │───>│Trampoline │───>│   Bob    │
│ (手機)   │    │  Node 1   │    │  Node 2   │    │ (接收方) │
└──────────┘    └───────────┘    └───────────┘    └──────────┘
      │               │                │                │
      │  只知道       │   計算路徑      │   計算路徑      │
      │  T1 的位置    │   到 T2        │   到 Bob       │
      └───────────────┴────────────────┴────────────────┘

Alice 只需要知道：
1. 自己的直接連接節點
2. 一些知名的 Trampoline 節點
3. Bob 的節點 ID（不需要知道 Bob 的位置）

Trampoline 節點負責：
1. 維護完整的網路圖譜
2. 計算到下一跳的路徑
3. 轉發支付

Nested Onion Structure:

Outer onion (traditional BOLT 4):
  Hop 1: Alice -> direct peer Node A
    payload: forward to Node B
  Hop 2: Node A -> Node B
    payload: forward to Trampoline T1
  Hop 3: Node B -> Trampoline T1
    payload: [inner Trampoline onion]

Inner onion (Trampoline):
  T-Hop 1: T1 -> T2
    payload: amount, expiry, next trampoline
  T-Hop 2: T2 -> Bob
    payload: final payment details

When T1 receives:
1. Decrypt outer onion, discover Trampoline payment
2. Decrypt first layer of inner onion
3. Find need to forward to T2
4. Calculate path to T2
5. Build new outer onion to T2
6. Keep inner onion (peel one layer)

Trampoline Fee Structure:

Traditional routing:
  Total fee = sum of each hop's routing fee
  Sender knows exact fee for each hop

Trampoline routing:
  Total fee = Alice->T1 fee + T1 budget + T2 budget + ...

  Alice specifies:
  • T1 budget: 1000 sats (max allowed)
  • T2 budget: 800 sats

  T1 actually routes to T2 for 500 sats
  -> T1 keeps 500 sats as service fee

Challenges:
• Budget too low: payment fails
• Budget too high: overpay fees
• Need experience to set reasonable budget

Optimizations:
• Trampoline nodes can return fee estimates
• Clients can gradually adjust budget
• Use historical data to optimize

Trampoline Onion TLV 欄位：

在 hop_payload 中添加：

trampoline_onion_packet (type 66100)
├── version: 0
├── public_key: 33 bytes
├── hop_payloads: encrypted
└── hmac: 32 bytes

trampoline_hop_payload:
├── amt_to_forward (type 2)
├── outgoing_cltv_value (type 4)
├── outgoing_node_id (type 14)  // 下一個 Trampoline
├── invoice_features (type 66102)
└── invoice_routing_info (type 66103)

功能位：
- trampoline_routing_optional: bit 56
- trampoline_routing_required: bit 57