路由與尋路
閃電網路是一個動態的支付網路。了解節點如何發現路徑並成功轉發支付。
閃電網路拓撲
閃電網路是由節點和通道組成的圖狀結構。每個節點都維護著這個網路的「地圖」， 稱為「路由表」或「網路圖」。
網路組成
節點 (Nodes)
運行閃電網路軟體的實體
由公鑰識別
通道 (Channels)
兩個節點之間的支付通道
由資金交易的 TXID 識別
Gossip 協議
節點通過 gossip 協議互相交換網路信息，傳播三類消息：
| 消息類型 | 內容 | 作用 |
|---|---|---|
| node_announcement | 節點公鑰、別名、地址 | 宣布節點存在 |
| channel_announcement | 通道 ID、兩端節點 | 宣布新通道 |
| channel_update | 費率、時間鎖、啟用狀態 | 更新通道參數 |
注意： Gossip 只傳播公開通道的信息。 「私有通道」不會在網路中廣播，只有通道雙方知道它的存在。
尋路算法
發送支付時，節點需要找到一條從自己到收款人的路徑。 這是一個經典的圖論問題，通常使用 Dijkstra 算法的變體。
路徑選擇考量
- • 費用：總路由費用最低
- • 可靠性：節點在線率和成功率
- • 跳數：較少的跳數意味著較低的延遲和時間鎖
- • 容量：通道必須有足夠的流動性
流動性挑戰
尋路的最大挑戰是：節點只知道通道的總容量，不知道餘額分布。 因此可能選擇的路徑實際上沒有足夠的流動性。
流動性問題示例
通道容量：1 BTC
實際分布：Alice 0.1 BTC ⟷ Bob 0.9 BTC
→ Alice 最多只能發送 0.1 BTC，儘管通道容量是 1 BTC
解決方案
1. 探測 (Probing)
發送虛假支付來探測路徑是否有足夠流動性。這會暴露網路信息但幫助找到可行路徑。
2. 多路徑支付 (MPP)
將大額支付拆分成多個小額支付，通過不同路徑發送。這大大提高了大額支付的成功率。
MPP 示例
目標：支付 1 BTC
路徑 1: Alice → Bob → Carol (0.4 BTC)
路徑 2: Alice → Dave → Carol (0.3 BTC)
路徑 3: Alice → Eve → Carol (0.3 BTC)
3. 重試機制
如果支付失敗，節點會記住失敗原因，避開有問題的通道，嘗試其他路徑。
洋蔥路由
閃電網路使用「洋蔥路由」(Onion Routing) 保護支付隱私。 每個節點只知道前一跳和下一跳，不知道完整路徑。
洋蔥結構
Layer 4 (外層): [加密: Bob 的下一跳信息]
Layer 3: [加密: Carol 的下一跳信息]
Layer 2: [加密: Dave 的下一跳信息]
Layer 1 (核心): [payment_hash, amount]
每個節點只能解密自己的那一層，然後轉發給下一跳
隱私保護
- • 中間節點不知道發送者是誰
- • 中間節點不知道接收者是誰
- • 中間節點不知道支付在路徑中的位置
- • 路徑長度被填充到固定大小（1300 bytes）
路由提示 (Route Hints)
對於使用私有通道的接收者，發票中可以包含「路由提示」， 告訴發送者如何到達最後一跳。
路由提示示例：
{
"pubkey": "02abc...", // 最後一個公開節點
"short_channel_id": "...", // 私有通道 ID
"fee_base_msat": 1000,
"fee_proportional_millionths": 1,
"cltv_expiry_delta": 40
} Trampoline 路由
對於輕客戶端，維護完整的網路圖太昂貴。Trampoline 路由允許將尋路工作委託給中間節點：
- 發送者只指定幾個「Trampoline 節點」
- Trampoline 節點負責找到到下一個 Trampoline 的路徑
- 支付在 Trampoline 節點之間跳轉，最終到達目的地
路由節點運營
運營路由節點需要考慮：
- ✓ 費率設置：太高沒人用，太低不賺錢
- ✓ 流動性管理：定期 rebalance 通道
- ✓ 節點連接：與活躍節點建立通道
- ✓ 正常運行時間：7×24 在線
延伸閱讀： 了解 閃電發票格式， 學習如何解碼和創建閃電網路支付請求。