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

概述

閃電網路（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）

動態調整通道容量：

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

原子支付路徑搜尋機制

HTLC 的原子性保證

HTLC（Hash Time Locked Contract）是閃電網路實現原子支付的核心機制。其原子性通過密碼學保證，確保支付要么完全成功，要么完全失敗，不存在中間狀態。

HTLC 的結構

# HTLC 腳本結構
# 輸出腳本（鎖定階段）
htlc_script = """
# 收款方路徑：揭示原像獲得資金
OP_HASH160 <hash(preimage)> OP_EQUALVERIFY <receiver_pubkey> OP_CHECKSIG

OP_IF
    # 時間鎖後允許退款
    <timeout> OP_CHECKSEQUENCEVERIFY OP_DROP
    <refund_pubkey> OP_CHECKSIG
OP_ENDIF
"""

原子性分析

1. 哈希鎖（Hash Lock）：

• 付款方預先產生隨機原像 R，計算 H = Hash(R)
• 將 H 包含在 HTLC 中
• 只有知道原像 R 的人才能解鎖

1. 時間鎖（Time Lock）：

• 設定解鎖剩餘時間（以區塊數表示）
• 超時後資金退還給付款方

1. 原子性保證：

• 如果收款方揭示原像，必須在時間鎖到期前完成
• 如果收款方未能揭示原像，資金自動退還
• 雙方都無法單方面控制資金

多路徑支付（Multipath Payments, MPP）

大額支付可以拆分為多個小額支付，通過不同路徑傳輸，提高成功率和隱私性：

MPP 機制

class MultipathPayment:
    def __init__(self, total_amount, max_shard_size):
        self.total_amount = total_amount
        self.max_shard_size = max_shard_size
        self.shards = self.split_payment(total_amount)

    def split_payment(self, amount):
        """將支付拆分為多個小額分片"""
        shards = []
        remaining = amount

        while remaining > 0:
            shard_size = min(remaining, self.max_shard_size)
            shards.append(shard_size)
            remaining -= shard_size

        return shards

    def route_shards(self):
        """為每個分片計算路由"""
        routes = []
        for shard in self.shards:
            # 計算最小費用路徑
            route = calculate_route(shard)
            routes.append(route)
        return routes

MPP 優勢

1. 流動性效率：避免單一通道餘額不足
2. 隱私提升：大額支付拆分散布於網路
3. 失敗恢復：部分失敗不影響整體

路徑搜尋算法詳解

完整路徑搜尋流程

class LightningRouter:
    def __init__(self, network_graph):
        self.graph = network_graph

    def find_path(self, source, target, amount):
        """完整路徑搜尋流程"""
        # 步驟 1: 構建增廣圖
        augmented_graph = self.build_augmented_graph(
            source, target, amount
        )

        # 步驟 2: 計算候選路徑
        candidates = self.compute_candidate_paths(
            augmented_graph, source, target
        )

        # 步驟 3: 流動性檢查
        valid_routes = []
        for route in candidates:
            if self.check_liquidity(route, amount):
                valid_routes.append(route)

        # 步驟 4: 費用優化
        best_route = self.optimize_fee(valid_routes)

        return best_route

    def build_augmented_graph(self, source, target, amount):
        """構建考慮費用的增廣圖"""
        G = Graph()

        for node in self.graph.nodes:
            G.add_node(node)

        for channel in self.graph.channels:
            # 計算邊權重 = 基礎費用 + 比例費用
            weight = self.calculate_edge_weight(
                channel, amount
            )

            # 排除流動性不足的通道
            if self.has_sufficient_liquidity(channel, amount):
                G.add_edge(channel, weight=weight)

        return G

費用感知 Dijkstra 算法

傳統 Dijkstra 只考慮跳數或距離，閃電網路需要考慮費用：

def dijkstra_fee_aware(graph, source, target, amount):
    """
    費用感知的最短路徑算法
    """
    distances = {source: 0}
    previous = {}
    visited = set()
    pq = PriorityQueue()

    pq.put((0, source))

    while not pq.empty():
        current_dist, current = pq.get()

        if current in visited:
            continue
        visited.add(current)

        if current == target:
            break

        for neighbor, channel_data in graph.neighbors(current):
            # 計算通過此通道的費用
            fee = calculate_channel_fee(
                channel_data,
                amount - distances[current]
            )

            # 總費用作為權重
            new_dist = distances[current] + fee

            if new_dist < distances.get(neighbor, infinity):
                distances[neighbor] = new_dist
                previous[neighbor] = current
                pq.put((new_dist, neighbor))

    return reconstruct_path(previous, target)

流動性感知路由

閃電網路的獨特挑戰在於動態的通道餘額，以下是流動性感知的路由策略：

流動性模型

class LiquidityModel:
    def __init__(self, channel_state_history):
        self.history = channel_state_history
        self.capacity = channel_state_history.capacity

    def estimate_success_probability(self, channel, amount):
        """估計通道對特定金額的成功概率"""
        # 基於歷史數據估計
        historical_success = self.history.success_rate(
            time_window=7 * 144  # 7 天
        )

        # 考慮當前餘額
        local_balance = channel.local_balance
        remote_balance = channel.remote_balance

        # 如果金額小於本地餘額，成功率較高
        if amount < local_balance:
            return historical_success * 0.95

        # 如果金額大於遠端餘額，成功率很低
        if amount > remote_balance:
            return 0.01

        # 區間內使用歷史成功率
        ratio = remote_balance / self.capacity
        return historical_success * ratio

混合費用-流動性優化

def hybrid_route_optimization(source, target, amount):
    """
    同時考慮費用和流動性的路徑優化
    """
    # 權重公式
    # total_weight = alpha * fee + beta * (1/probability)

    alpha = 0.6  # 費用權重
    beta = 0.4   # 流動性權重

    candidates = find_all_paths(source, target, max_hops=20)

    best_route = None
    best_weight = infinity

    for route in candidates:
        total_fee = sum(hop.fee for hop in route.hops)
        success_prob = 1.0

        for hop in route.hops:
            prob = liquidity_model.estimate_success_probability(
                hop.channel, amount
            )
            success_prob *= prob

        # 計算混合權重
        weight = alpha * total_fee + beta * (1 / success_prob)

        if weight < best_weight:
            best_weight = weight
            best_route = route

    return best_route

原子性跨鏈交換

閃電網路的一個重要應用是原子跨鏈交換（Atomic Swap），實現不同區塊鏈之間的去中心化交易：

閃電網路原子交換原理

class AtomicSwap:
    def __init__(self, alice, bob, amount_sat, swap_amount_btc):
        self.alice = alice
        self.bob = bob
        self.amount = amount_sat
        self.swap_amount = swap_amount_btc
        self.secret = os.urandom(32)  # 隨機秘密
        self.secret_hash = hashlib.sha256(self.secret).digest()

    def create_swap_htlc(self, payer, payee):
        """
        創建原子交換 HTLC
        """
        # 哈希鎖：只有知道秘密才能解鎖
        # 時間鎖：超時后退還
        script = f"""
        OP_HASH160 {self.secret_hash.hex()} OP_EQUALVERIFY
        {payee.pubkey} OP_CHECKSIG

        OP_IF
            # 正常解鎖路徑
            <receiver_pubkey> OP_CHECKSIG
        OP_ELSE
            # 退款路徑
            <timeout> OP_CHECKSEQUENCEVERIFY OP_DROP
            <refund_pubkey> OP_CHECKSIG
        OP_ENDIF
        """
        return script

原子交換流程

時間線：

T0: 雙方創建 HTLC
    - Alice 在比特幣上創建 HTLC（使用 H）
    - Bob 在萊特幣上創建 HTLC（使用相同 H）

T1: Bob 揭示原像
    - Bob 必須先揭示原像 R 才能獲得資金
    - 揭示的 R 被 Alice 看到

T2: Alice 使用原像解鎖
    - Alice 使用 R 解鎖萊特幣 HTLC
    - 交易在區塊鏈上確認

T3: 雙方獲得資金
    - Bob 獲得比特幣
    - Alice 獲得萊特幣
    - 交換完成

超時情況：
- 如果 T1 未發生，雙方 HTLC 超時
- 資金退還給各自

PTLC（Point Time Locked Contract）

PTLC 是 Taproot 升級後引入的新機制，相比 HTLC 有以下優勢：

PTLC vs HTLC

PTLC 實現原理

class PTLC:
    def __init__(self):
        self.curve = secp256k1

    def create_ptlc(self, amount, receiver_pubkey, timeout):
        """創建 PTLC"""
        # 生成隨機點 R
        self.r = self.curve.generate_random_point()
        self.R = self.r * self.curve.G

        # 計算調適因子
        # 付款方和收款方協商產生
        self.adaptor = self.compute_adaptor(
            receiver_pubkey, self.R
        )

        # 創建 PTLC 輸出
        # 收款方需要產生 D = r + e*k
        # 其中 e = Hash(R, amount)
        output = {
            'amount': amount,
            'point': self.adaptor,
            'timeout': timeout
        }

        return output

    def unlock_ptlc(self, adaptor_secret):
        """解鎖 PTLC"""
        # 收款方公鑰 P
        # 需要計算 D = r + e*k
        # 其中 e = Hash(R, amount)
        D = self.compute_adaptor_signature(
            self.r,
            self.R,
            adaptor_secret
        )

        return D

MPP 與 PTLC 最新進展（2024-2025）

Base AMP（原子多路徑支付）的改進

2024 年以來，閃電網路的 MPP 實現取得了重大進展，Base AMP（原子多路徑支付）成為標準功能：

Base AMP 技術進展：

┌─────────────────────────────────────────────────────────────────────────────┐
│  功能                     │  2023 年狀態    │  2025 年狀態              │
├────────────────────────────┼────────────────┼───────────────────────────┤
│  原子性保證               │  部分支援       │  完整支援                  │
│  自動拆分                 │  手動           │  自動                      │
│  費用優化                 │  基礎           │  智慧                      │
│  失敗重試                 │  有限           │  完整                      │
│  路由並行性               │  2-4 路徑      │  8+ 路徑                   │
└────────────────────────────┴────────────────┴───────────────────────────┘

Base AMP 核心改進：
1. 智慧路徑選擇：根據流動性和費用自動選擇最佳路徑
2. 失敗恢復：單一路徑失敗時自動重新路由
3. 費用估算：即時費用計算避免過度支付
4. 延遲優化：減少多路徑支付的總延遲

PTLC 與 Taproot 整合的最新進展

PTLC（Point Time Locked Contract）與 Taproot 的整合是 2024-2025 年閃電網路最重要的技術升級：

PTLC 與 Taproot 整合現況：

技術改進：
1. 單簽名 PTLC
   • 使用 Schnorr 簽名實現 PTLC
   • 簡化通道設置流程
   • 減少鏈上交易大小

2. PTLC 路由隱私
   • 每筆支付使用獨立的適配器點
   • 消除 HTLC 哈希指紋
   • 路徑關聯變得極度困難

3. 多簽名 PTLC
   • MuSig2 實現多人通道
   • 閾值簽名支援
   • 提升通道安全性

4. PTLC 魚叉式支付
   • 為特定收款人生成專屬 PTLC
   • 防止中間節點提前解鎖
   • 增強支付隱私

MPP + PTLC 組合優勢

MPP 與 PTLC 的結合帶來了顯著的性能和隱私提升：

class AdvancedMPP_PTLC:
    """MPP + PTLC 組合實現"""

    @staticmethod
    def create_advanced_payment(amount, recipient_pubkey, num_paths=4):
        """
        創建高級 MPP + PTLC 支付

        技術特點：
        1. 自動拆分：根據通道容量智慧拆分
        2. PTLC 保護：每路徑使用獨立 PTLC
        3. 失敗隔離：單路徑失敗不影響其他
        4. 隱私增強：無法通過費用關聯路徑
        """
        # 步驟 1：計算最佳路徑數量
        optimal_paths = AdvancedMPP_PTLC.calculate_optimal_paths(
            amount,
            recipient_pubkey
        )

        # 步驟 2：為每個路徑創建 PTLC
        ptlc_paths = []
        for i in range(optimal_paths):
            path_amount = amount // optimal_paths
            if i == optimal_paths - 1:
                path_amount += amount % optimal_paths  # 處理餘數

            # 為每個子支付創建獨立 PTLC
            ptlc = PTLC.create(
                amount=path_amount,
                receiver_pubkey=recipient_pubkey,
                payment_point=AdvancedMPP_PTLC.generate_payment_point(i)
            )
            ptlc_paths.append(ptlc)

        # 步驟 3：構建原子性擔保
        atomic_guarantee = AMP.compute_amp_hash(
            [ptlc.payment_hash for ptlc in ptlc_paths]
        )

        return {
            'paths': ptlc_paths,
            'atomic_hash': atomic_guarantee,
            'total_amount': amount,
            'num_paths': optimal_paths,
            'ptlc_enabled': True,
            'amp_version': 'v2'
        }

    @staticmethod
    def calculate_optimal_paths(amount, recipient):
        """計算最佳路徑數量"""
        # 考慮因素：
        # - 單路徑容量限制
        # - 費用最優化
        # - 隱私權衡
        # - 延遲要求
        base_paths = min(8, max(1, amount // 50000))  # 每路徑約 50k sats
        return max(1, base_paths)

2025 年閃電路由新技術

2025 年閃電路由技術前沿：

1. 路由隱私增強
   • 多路徑費用混淆
   • 虛假路徑混合
   • 時間混合技術

2. 流動性感知路由
   • 實時通道餘額查詢
   • 預測性流動性估計
   • 機器學習路由優化

3. 零知識證明路由
   • ZK 範圍證明驗證餘額
   • 隱私保護的費用計算
   • 可驗證的路由正確性

4. 分散式路由協調
   • 路由節點網路
   • 集體路徑發現
   • 流動性市場整合

路由失敗的進階處理

失敗類型與策略

class RoutingFailureHandler:
    def __init__(self, router):
        self.router = router

    def handle_failure(self, route, error):
        """根據錯誤類型採用不同策略"""
        error_codes = {
            'temporary_channel_failure': self.handle_temp_failure,
            'permanent_channel_failure': self.handle_perm_failure,
            'insufficient_funds': self.handle_liquidity_failure,
            'final_expiry_too_soon': self.handle_timeout_failure,
            'unknown_next_peer': self.handle_unknown_peer
        }

        handler = error_codes.get(error, self.handle_unknown_error)
        return handler(route)

    def handle_temp_failure(self, route):
        """臨時錯誤：使用相同路徑重試"""
        # 短暫等待後重試
        time.sleep(1)
        return self.router.retry(route)

    def handle_perm_failure(self, route):
        """永久錯誤：排除故障節點"""
        # 標記故障節點
        for hop in route.hops:
            self.router.mark_node_failed(hop.node)

        # 計算新路徑
        return self.router.find_new_route(route.target)

    def handle_liquidity_failure(self, route):
        """流動性錯誤：使用 MPP 或其他路徑"""
        # 嘗試多路徑支付
        mpp = MultipathPayment(route.amount)
        return self.router.multipath_route(mpp)

    def handle_timeout_failure(self, route):
        """超時錯誤：增加 CLTV 增量"""
        new_cltv = route.cltv_delta * 1.5
        return self.router.recalculate_route(route, new_cltv)

常見問題

閃電路由是否完全匿名？

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

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

為什麼支付會失敗？

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

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

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

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

路由費用由誰決定？

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

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

外部參考來源

學術論文

• Poon, J., Dryja, T. (2016). "The Bitcoin Lightning Network"
• Roos, S. et al. (2018). "Settling Payments Fast and Private: Efficient Decentralized Routing for Path-Based Transactions"
• Pickhardt, R., Nowostawski, M. (2020). "Imbalance Measure and Proactive Channel Rebalancing Algorithm for the Lightning Network"

技術規範

• BOLT 4: Onion Routing Protocol
• BOLT 7: P2P Node and Channel Discovery
• Lightning Network Specifications

比特幣開發資源

• Bitcoin Optech: Lightning Network
• LNRoute: Lightning Network Routing
• 1ML: Lightning Network Search

數據來源

• Bitcoin Visuals: Lightning Network Statistics
• Amboss Network Graph

總結

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