閃電網路 BOLTs 規範完全指南

進階 📅 發布：2026-03-04 🏷️ lightning, bolt, specification, htlc, routing, protocol 計算中...

深入解析閃電網路的核心技術規範，包括 BOLT 11 支付請求格式、BOLT 2 通道建立、BOLT 3 HTLC 機制、BOLT 4 路由協議、BOLT 5 狀態管理等完整技術細節。

閃電網路 BOLTs 規範完全指南

概述

閃電網路（Lightning Network）是比特幣最重要的第二層擴展解決方案，而支撐其運作的核心正是 BOLT 規範。BOLT 是「Basis of Lightning Technology」的縮寫，這一系列技術規範定義了閃電網路的協議設計、訊息格式、通道管理與路由機制。本文將深入解析 BOLTs 規範的完整內容，幫助讀者理解閃電網路的技術基礎與設計原理。

BOLTs 規範的架構

規範的層級結構

BOLTs 規範採用分層設計，不同的 BOLT 負責不同的功能領域。目前主要的 BOLTs 包括：

BOLT 0：閃電網路概述與術語定義
BOLT 1：節點發現與通道建立
BOLT 2：點對點訊息協定
BOLT 3：比特幣交易與櫻桃取樣
BOLT 4：路由與訊息轉發
BOLT 5：通道狀態與關閉
BOLT 7：P2P 節點發現與公告
BOLT 8：加密傳輸
BOLT 9：功能協商
BOLT 10：節點本地儲存
BOLT 11：閃電支付請求格式

每一個 BOLT 都有其特定的角色，共同構成完整的閃電網路協議棧。

規範的演進

BOLTs 規範是開放且持續演進的。隨著閃電網路的實際部署經驗累積，規範也在不斷更新。主要的閃電網路實現——包括 LND、c-lightning、Eclair 和 Core Lightning——都遵循這些規範，確保彼此之間的互操作性。

BOLT 11：支付請求格式

請求格式詳解

BOLT 11 定義了閃電支付請求的標準格式，這是使用者進行閃電支付時最常接觸的部分。一個典型的閃電網路支付請求看起來像這樣：

lnbc100n1p0testn...

這個字串包含了所有必要的支付資訊：金額、節點識別碼、過期時間、支付雜湊等。

編碼結構

閃電支付請求使用 Bech32 編碼，這與比特幣的隔離見證地址使用相同的編碼方式。解碼後的資料包含以下欄位：

金額：以毫兆比特幣（millisatoshi）為單位
節點公鑰：收款節點的識別碼
支付雜湊：支付的唯一識別符
過期時間：請求的有效期限
備注欄位：可選的付款說明
路由提示：可選的私人路由資訊

支付請求解析
═══════════════════════════════════════════════════════════════════════════════

lnbc100n1p0testn...
├─ lnbc: 閃電網路 Bech32 前綴
├─ 100n: 金額 100 毫比特幣 (0.000001 BTC)
├─ p0: 時間戳記和支付雜湊編碼
└─ ...: 其他可選欄位和校驗和

金額表示

BOLT 11 使用特別的金額表示法：

1 兆比特幣（pico bitcoin）= 0.000000001 比特幣
1 毫兆比特幣（millisatoshi）= 0.000000000001 比特幣
1000 毫兆比特幣 = 1 原子比特幣（satoshi）

金額字首使用小寫字母表示：

p = pico bitcoin（十億分之一比特幣）
n = nano bitcoin（十億分之十比特幣）
u = micro bitcoin（百萬分之一比特幣）
m = milli bitcoin（千分之一比特幣）

BOLT 2：點對點訊息協定

通道建立流程

BOLT 2 定義了閃電通道的建立過程。這是閃電網路最核心的協議之一，包含了複雜的密碼學交互。

通道建立流程
═══════════════════════════════════════════════════════════════════════════════

┌─────────┐                              ┌─────────┐
│  Alice  │                              │   Bob   │
└────┬────┘                              └────┬────┘
     │                                        │
     │─────── Open Channel ──────────────────▶│
     │                                        │
     │◀────── Accept Channel ───────────────│
     │                                        │
     │────── Funding Created (Tx) ──────────▶│
     │                                        │
     │◀───── Funding Signed ──────────────────│
     │                                        │
     │───── Funding Locked ─────────────────▶│
     │                                        │
     │◀───── Channel Ready ──────────────────│
     │                                        │
     │         通道已建立完成                  │
     └────────────────────────────────────────┘

訊息類型

通道建立過程中交換的訊息包括：

open_channel：發起者發送，包含通道參數
accept_channel：接收者回應，接受通道參數
funding_created：發起者創建資助交易
funding_signed：接收者簽署資助交易
funding_locked：雙方確認資助交易已確認
channel_ready：通道可以開始使用

通道參數

每個閃電通道都有以下關鍵參數：

通道容量：通道中比特幣的總額
To Self Push：初始資金分配
Dust Limit：粉塵閾值
Max HTLC Value：單一 HTLC 最大值
Min HTLC Value：單一 HTLC 最小值
Feerate：手續費率
CLTV Expiry Delta：時間鎖差值

BOLT 3：比特幣交易與 HTLC

HTLC 機制詳解

Hash Time Locked Contract（HTLC）是閃電網路的核心技術元件。BOLT 3 詳細定義了 HTLC 的比特幣腳本實現。

HTLC 的基本邏輯是：

收款方需要提供原像（preimage）才能獲得資金
如果收款方在超時前未能提供原像，資金退還給付款方

HTLC 輸出腳本範例
═══════════════════════════════════════════════════════════════════════════════

# 收款方取款條件
OP_HASH160 <ripemd160(sha256(preimage))> OP_EQUALVERIFY
OP_DUP OP_HASH160 <receiver_pubkey> OP_EQUALVERIFY OP_CHECKSIG

# 付款方退款條件（帶時間鎖）
OP_IF
    OP_DUP OP_HASH160 <sender_pubkey> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
    <expiry_blocks> OP_CHECKLOCKTIMEVERIFY OP_DROP
    OP_DUP OP_HASH160 <sender_pubkey> OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

櫻桃取樣

BOLT 3 還定義了「櫻桃取樣」（Splicing）機制，這是一種動態調整通道容量的方法：

Splice In：向通道添加資金
Splice Out：從通道提取資金
Splice Cancel：取消正在進行的櫻桃取樣

交易結構

閃電通道使用特殊的兩方交易結構：

資助交易（Funding Transaction）：鎖定通道資金的基礎交易
承諾交易（Commitment Transaction）：記錄通道當前狀態
結算交易（Settlement Transaction）：HTLC 履約時使用
關閉交易（Closing Transaction）：通道正常關閉時使用

每個參與者都需要保存多個簽名的承諾交易，以便在需要時執行正確的通道狀態。

BOLT 4：路由與訊息轉發

路由協議

BOLT 4 定義了閃電網路的訊息轉發機制。節點通過互相公告通道資訊來建立網路拓撲。

路由發現流程
═══════════════════════════════════════════════════════════════════════════════

節點發布的通道公告：
┌─────────────────────────────────────────────────────────────────────────────┐
│  Channel Announcement                                                        │
│  ├── 節點密鑰簽名 1                                                         │
│  ├── 節點密鑰簽名 2                                                         │
│  ├── 節點公鑰 1                                                             │
│  ├── 節點公鑰 2                                                             │
│  ├── 短期通道公鑰 1                                                         │
│  ├── 短期通道公鑰 2                                                         │
│  ├── 比特幣簽名                                                             │
│  ├── 通道 ID                                                                │
│  └── 通道特性                                                               │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│  Channel Update (由節點定時更新)                                            │
│  ├── 通道 ID                                                                │
│  ├── 節點簽名                                                               │
│  ├── 時間戳記                                                               │
│  ├── 通道特性位                                                             │
│  ├── 最小 HTLC                                                              │
│  ├── 費用比例 (ppm)                                                         │
│  ├── 基礎費用                                                               │
│  └── HTLC 過期高度差                                                        │
└─────────────────────────────────────────────────────────────────────────────┘

費用計算

閃電網路的手續費由兩部分組成：

基礎費用（Base Fee）：每個 HTLC 固定收取
比例費用（Proportional Fee）：按 HTLC 金額比例收取

費用計算公式：

total_fee = base_fee + (htlc_amount * fee_proportional_millionths / 1000000)

例如，如果基礎費用為 1 毫兆比特幣，比例費用為 100 ppm（即 0.01%），則傳送 100,000 毫兆比特幣的手續費為：

total_fee = 1 + (100000 * 100 / 1000000) = 11 毫兆比特幣

Onion 路由

BOLT 4 使用「洋蔥路由」（Onion Routing）來保護隱私。每個轉發節點只知道：

上一跳和下一跳
需要轉發的 HTLC 金額和手續費
剩餘路程的洋蔥層數

洋蔥路由封裝
═══════════════════════════════════════════════════════════════════════════════

┌─────────────────────────────────────────────────────────────────────────────┐
│  Route Hint (解密後)                                                       │
│  └── 最終目的地資訊                                                         │
├─────────────────────────────────────────────────────────────────────────────┐
│  Layer 3 (節點 C 可解密)                                                   │
│  └── 節點 C 的下一跳和轉發參數                                             │
├─────────────────────────────────────────────────────────────────────────────┐
│  Layer 2 (節點 B 可解密)                                                   │
│  └── 節點 B 的下一跳和轉發參數                                             │
├─────────────────────────────────────────────────────────────────────────────┐
│  Layer 1 (節點 A 可解密)                                                   │
│  └── 節點 A 的下一跳和轉發參數                                             │
└─────────────────────────────────────────────────────────────────────────────┘

BOLT 5：通道狀態管理

通道狀態機

BOLT 5 定義了通道的生命週期狀態：

通道狀態機
═══════════════════════════════════════════════════════════════════════════════

┌─────────┐    open    ┌──────────┐    funding_created    ┌──────────────┐
│  NULL   │──────────▶│  OPENED  │─────────────────────▶│  FUNDING     │
└─────────┘            └──────────┘                       │  SIGNED      │
                                                           └──────┬───────┘
                                                                  │
                                                    funding_locked │
                                                                  ▼
┌─────────┐    close    ┌──────────┐    mutual_close    ┌──────────────┐
│ CLOSING │◀───────────│  NORMAL  │◀───────────────────│   NORMAL     │
└────┬────┘            └────┬─────┘                       └──────────────┘
     │                      │
     │ unilateral_close      │ revoke_and_ack
     ▼                      ▼
┌──────────┐          ┌──────────┐
│  WAIT    │◀─────────│  NORMAL  │
│  ONION   │          └──────────┘
│  UNKNOWN │
└──────────┘

承諾交易更新

通道狀態的每一次變化——無論是新增 HTLC、履行 HTLC 還是更新通道餘額——都需要雙方簽署新的承諾交易。

BOLT 5 定義了以下訊息：

updateaddhtlc：新增 HTLC
updatefulfillhtlc：履行 HTLC
updatefailhtlc：HTLC 失敗
update_fee：協商手續費變更
commitment_signed：簽署承諾交易
revokeandack：撤銷舊承諾

通道關閉

通道可以通過三種方式關閉：

協商關閉（Mutual Close）：雙方同意正常關閉
單邊關閉（Unilateral Close）：一方直接廣播承諾交易
違約關閉（Breach Close）：檢測到對方違約後的關閉

協商關閉是最經濟的選項，因為它不需要等待時間鎖到期。單邊關閉需要等待時間鎖到期才能完成資金分配。

BOLT 8：加密傳輸

Noise Protocol Framework

BOLT 8 使用 Noise Protocol Framework 作為傳輸層加密的基礎。這是一個輕量級的密碼學協議框架，提供了：

前向保密（Forward Secrecy）
身份驗證
加密抗審查

Noise Protocol 的三次握手（Handshake）過程：

Noise 握手流程
═══════════════════════════════════════════════════════════════════════════════

┌─────────┐                                            ┌─────────┐
│  Alice  │                                            │   Bob   │
└────┬────┘                                            └────┬────┘
     │                                                      │
     │───────────→  NE (Alice's ephemeral) ────────────────▶│
     │                                                      │
     │◀────────  NE, ENC(Bob's static), MAC(Bob) ─────────│
     │                                                      │
     │──────────  ENC(Alice's static), MAC(Alice) ─────────▶│
     │                                                      │
     │     雙方建立加密隧道，可傳輸應用數據                  │
     └──────────────────────────────────────────────────────┘

加密方案

閃電網路使用的加密方案：

Curve25519：用於密鑰交換
ChaCha20-Poly1305：用於對稱加密
SHA256：用於訊息認證碼

BOLT 9：功能協商

特性位

BOLT 9 定義了節點之間協商功能的機制。每個節點在連接建立時公告自己支持的功能。

重要的特性位包括：

特性位	名稱	描述
option_anchors	錨點輸出	支持改進的承諾交易格式
optionanchorszerofeehtlc_tx	零費用 HTLC 交易	支持零費用的 HTLC 結算交易
optionrouteblinding	路由盲化	支持隱藏路由節點的機制
optionscidaliasID 別	SC名	支持通道 SCID 別名
option_keysend	金鑰發送	支持無請求的支付
option_zeroconf	零確認	支持零確認通道

功能協商流程

節點連接時會比較雙方的特性位，選擇雙方都支持的功能集合。如果某個必要功能不被支持，連接可能會失敗。

BOLT 10：本地資料儲存

節點資料管理

BOLT 10 定義了節點本地資料的儲存格式和原則。這包括：

通道資料：通道狀態、承諾交易、HTLC 訊息
節點資料：已知的節點和通道資訊
支付資料：支付歷史和預圖像

節點需要能夠從本地資料中恢復完整的通道狀態，這是實現備份和災難復原的基礎。

備份考量

閃電節點的備份比比特幣全節點更複雜：

需要備份通道狀態
需要安全的密鑰管理
需要處理狀態變化的即時性

規範的未來演進

正在進行的工作

閃電網路社群持續在多個方向推進規範的演進：

通道工廠（Channel Factories）：批量建立通道
PTLC（Point Time Locked Contract）：替代 HTLC 的新機制
路由盲化：增強隱私
Wumbo 通道：更大容量的通道
原子多路徑支付：分割支付的原子性

與 Taproot 的整合

Taproot 升級為閃電網路帶來了新的可能性：

更高效的通道關閉交易
更便宜的多元簽名通道
更好的隱私特性
可能的無狀態通道

結論

BOLTs 規範是理解閃電網路技術的關鍵。從支付請求格式（BOLT 11）到通道建立（BOLT 2）、從 HTLC 機制（BOLT 3）到路由協議（BOLT 4），每一個 BOLT 都代表著閃電網路的一個重要組成部分。

這些規範的設計體現了比特幣社群對安全、隱私和可擴展性的持續追求。隨著規範的不斷演進和実装的成熟，閃電網路將繼續在比特幣的支付基礎設施中扮演關鍵角色。

什麼是閃電網路 — 理解比特幣第二層支付解決方案。
閃電網路完整開發指南：從基礎到生產環境部署 — 深入探討閃電網路的技術架構、客戶端選擇、通道建立、路由機制、流動性管理，以及生產環境部署的最佳實踐，包含 Python、JavaScript 與 Rust 完整程式碼範例。
閃電網路路由機制完全指南 — 深入解析閃電網路的路由演算法、費用計算、流動性管理與隱私保護機制。
閃電網路 Channels 詳解 — 深入理解 HTLC、通道狀態與流動性管理。
HTLC 深度解析 — 哈希時間鎖定合約詳解

延伸閱讀與來源

比特幣開發者文檔比特幣官方開發者指南
比特幣 Wiki 比特幣社群維基

這篇文章對您有幫助嗎？

請告訴我們如何改進：

0 人覺得有帮助

閃電網路 BOLTs 規範完全指南

概述

BOLTs 規範的架構

規範的層級結構

規範的演進

BOLT 11：支付請求格式

請求格式詳解

編碼結構

金額表示

BOLT 2：點對點訊息協定

通道建立流程

訊息類型

通道參數

BOLT 3：比特幣交易與 HTLC

HTLC 機制詳解

櫻桃取樣

交易結構

BOLT 4：路由與訊息轉發

路由協議

費用計算

Onion 路由

BOLT 5：通道狀態管理

通道狀態機

承諾交易更新

通道關閉

BOLT 8：加密傳輸

Noise Protocol Framework

加密方案

BOLT 9：功能協商

特性位

功能協商流程

BOLT 10：本地資料儲存

節點資料管理

備份考量

規範的未來演進

正在進行的工作

與 Taproot 的整合

結論

相關文章

延伸閱讀與來源

這篇文章對您有幫助嗎？

評論

發表評論