閃電網路路由機制完全指南

概述

閃電網路（Lightning Network）是比特幣的第二層支付解決方案，其核心功能是實現快速、低費用的鏈下交易。路由機制是閃電網路的關鍵技術，決定了支付如何從發送方流向接收方。本文深入解析閃電網路的路由機制，包括通道發現、路由計算、費用計算等核心概念。

為什麼需要路由機制

閃電網路的基本假設

閃電網路假設不會有節點與所有其他節點直接建立通道。因此，當用戶 A 想要支付給用戶 B 時，可能需要透過多個中間節點來轉發支付。這就是路由機制存在的意義。

路由的挑戰

閃電網路路由面臨幾個獨特挑戰：

1. 網路拓撲動態變化：通道會打開和關閉，節點會上線和離線
2. 隱私要求：不能向中間節點暴露完整的支付路徑
3. 流動性限制：每個通道都有容量限制，不是所有路徑都能成功轉發
4. 費用優化：需要在速度和費用之間取得平衡

通道與節點

節點識別

每個閃電節點都有：

• 節點公鑰（Node ID）：節點的唯一標識
• 網路地址：IP 地址或 .onion 地址
• 通道：與其他節點建立的雙向支付通道

通道容量

通道是閃電網路的基本單元：

• 本地餘額：自己這邊的資金
• .remote 餘額：對方的資金
• 總容量：兩者之和

例如，A 和 B 建立通道，A 投入 0.1 BTC，B 投入 0.05 BTC，總容量為 0.15 BTC。支付時，資金會在這個範圍內流動。

路由演算法

通道消息

閃電節點透過 Gossip 協議交換網路資訊：

1. channel_announcement：宣佈新通道
2. node_announcement：節點上線
3. channel_update：通道資訊更新（費用、延遲、容量）
4. error：錯誤消息

路徑發現

盲目探索（Blind Exploration）

早期閃電實現使用盲目探索：

1. 選擇隨機節點作為下一跳
2. 檢查是否有足夠流動性
3. 如果失敗，嘗試其他路徑

這種方法效率低下，容易失敗。

源路由（Source Routing）

現代閃電網路使用源路由：

1. 發送方計算完整路徑
2. 支付包含整個路徑的詳細資訊
3. 每個中間節點只知道前驅和後繼

路由計算流程

1. 獲取網路拓撲圖
2. 排除不可用的節點和通道
3. 計算候選路徑（通常是最短路徑）
4. 檢查每個通道的流動性
5. 計算每條路徑的總費用
6. 選擇最優路徑
7. 構建支付 HTLC

最短路徑演算法

Dijkstra 演算法

計算兩個節點之間的最短路徑：

def dijkstra(graph, source, target):
    distances = {source: 0}
    previous = {}
    nodes = set(graph.nodes)

    while nodes:
        current = min(nodes, key=lambda n: distances.get(n, infinity))
        nodes.remove(current)

        if current == target:
            break

        for neighbor, data in graph.neighbors(current):
            distance = distances[current] + data['weight']
            if distance < distances.get(neighbor, infinity):
                distances[neighbor] = distance
                previous[neighbor] = current

    return reconstruct_path(previous, target)

費用權重

費用影響路徑選擇：

def calculate_weight(channel, amount):
    base_fee = channel.base_fee
    proportional_fee = amount * channel.fee_rate
    total_fee = base_fee + proportional_fee
    return total_fee

跳數限制

閃電協議通常限制最大跳數為 20-30 跳，這是因為：

• HTLC 有時間鎖（CLTV delta）
• 每跳增加延遲和失敗風險
• 過長路徑費用更高

隱私保護

洋蔥路由（Onion Routing）

閃電使用類似 Tor 的洋蔥路由：

1. 發送方構造完整路徑
2. 為每個節點創建加密的「洋蔥層」
3. 每個節點只知道：

• 前一個節點是誰
• 下一個節點是誰
• 需要轉發多少 HTLC
• 額外數據（用於下一跳）

1. 節點無法知道：

• 支付的原點
• 支付的最終目的地
• 路徑上的其他節點

洋蔥結構

{
    "hop_payloads": [
        {
            "amt_to_forward": 1000,
            "outgoing_cltv_value": 500000,
            "short_channel_id": "123456x789x1"
        },
        {
            "amt_to_forward": 990,
            "outgoing_cltv_value": 499000,
            "short_channel_id": "123456x789x2"
        }
    ],
    "encrypted_payloads": [
        "encrypted_for_node_1...",
        "encrypted_for_node_2..."
    ]
}

每個節點只能解密自己的那一層，無法看到其他層的內容。

費用計算

費用組成

閃電網路費用由兩部分組成：

1. 基礎費用（Base Fee）：每筆支付固定的費用
2. 比例費用（Proportional Fee）：按支付金額比例計算

def calculate_route_fee(base_fee, fee_rate, amount):
    proportional = amount * fee_rate
    total = base_fee + proportional
    return total

費用市場

節點可以自由設定費用：

• 高流量節點：可能設定較低費用吸引路由
• 高需求時段：費用自然上漲
• 獨特路徑：可以設定較高費用

費用結算

費用在每跳累積：

• 發送方支付總費用
• 每個中間節點從收到的金額中扣除自己的費用
• 最終接收方收到金額 = 原始金額 - 路徑總費用

例如：

• 發送方：支付 1000 satoshi
• 節點 A：收到 1000，轉發 995（扣 5 satoshi）
• 節點 B：收到 995，轉發 988（扣 7 satoshi）
• 接收方：收到 988 satoshi

流動性管理

通道流動性

路由時必須考慮流動性：

• 發送方向：本地餘額必須足夠
• 接收方向：遠端餘額必須足夠（對方可以支付給我們）

流動性問題

1. 單向流動：資金只往一個方向流動
2. 通道耗盡：一側餘額耗盡
3. 再平衡成本：移動資金需要鏈上交易

解決方案

1. 流動性廣告：節點廣告其輸入流動性需求
2. 流動性市場：Splicing、Loop 等工具
3. 冰塊支付：拆分大額支付為小額

支付失敗處理

失敗原因

1. 流動性不足：通道餘額不夠
2. 節點離線：路徑上的節點不可用
3. 超時：HTLC 超過 CLTV 期限
4. 路由錯誤：路徑資訊過時

失敗處理

def handle_payment_failure(route, error):
    if error == "temporary_channel_failure":
        # 臨時錯誤，嘗試其他路徑
        return retry_with_alternative_route()
    elif error == "final_expiry_too_soon":
        # 期限太短，延長時間
        return retry_with_extended_cltv()
    elif error == "insufficient_funds":
        # 流動性不足，需要再平衡或新建通道
        return suggest_rebalance()
    else:
        # 其他錯誤
        return notify_user()

重試策略

1. 失敗替補：計算新的替代路徑
2. 費用增加：願意支付更高費用
3. 路徑拆分：拆分支付為多個小額支付

現代改進

支付地址（Offers）

BIP 21 擴展允許生成靜態支付請求：

• 接收方生成一次性地址
• 包含路由提示和金額
• 簡化支付流程

支付結果（Hold Invoice）

支持條件支付：

• 接收方可以延遲兌現
• 支援時間鎖、雜湊鎖條件

通道拼接（Splicing）

動態調整通道容量：

• 可以在不改變通道的情況下增加/減少容量
• 改善流動性管理

常見問題

閃電路由是否完全匿名？

不完全匿名。雖然使用洋蔥路由，但：

• 路徑上的節點知道前後節點
• 節點可以推斷部分資訊
• 需要結合CoinJoin才能達到較高隱私

為什麼支付會失敗？

最常見原因是流動性不足：

• 目標路徑沒有足夠餘額
• 通道餘額方向不對
• 需要重新平衡或使用其他路徑

如何改善路由成功率的路由？

1. 保持多個通道
2. 選擇費用合理的節點
3. 避免高峰期支付
4. 使用流動性較好的主要節點

路由費用由誰決定？

每個節點可以自行設定費用，通常基於：

• 市場供需
• 節點成本
• 流量策略

總結

閃電網路路由機制是一個複雜的系統，涉及路徑計算、費用市場、流動性管理等多個方面。通過洋蔥路由保護隱私，使用 Dijkstra 演算法計算最短路徑，並透過費用激勵節點提供流動性。理解這些機制有助於更好地使用閃電網路和優化支付體驗。隨著技術的發展，閃電路由將變得更加高效和可靠。