支付通道原理
深入理解支付通道的開啟、更新和關閉機制,以及承諾交易的運作方式。
什麼是支付通道?
支付通道是兩方之間建立的持續支付關係。雙方將資金鎖定在鏈上的 2-of-2 多簽地址中, 然後透過交換簽章的交易來更新各自的餘額,無需每次都上鏈。
開啟通道
1. 資金交易 (Funding Transaction)
開啟通道需要創建一筆鏈上交易,將資金發送到 2-of-2 多簽地址。 這筆交易被稱為「資金交易」,需要等待確認後通道才正式開啟。
資金交易示例
# Alice 開啟 1 BTC 通道給 Bob
輸入: Alice 的 UTXO (1.0005 BTC)
輸出: 2-of-2 多簽 (Alice + Bob) = 1 BTC
輸出: 找零給 Alice = 0.0004 BTC
手續費: 0.0001 BTC
2. 初始承諾交易
在廣播資金交易之前,雙方必須先交換簽章的「承諾交易」。 承諾交易定義了如何分配通道中的資金,確保在任何時候都可以單方面關閉通道。
初始狀態
Alice 的視角
Alice: 1 BTC
Bob: 0 BTC
Bob 的視角
Alice: 1 BTC
Bob: 0 BTC
承諾交易結構
承諾交易是閃電網路安全性的核心。每一方都持有不同版本的承諾交易, 這些交易設計為:可以單方面廣播,但對方有機會懲罰作弊行為。
非對稱設計
Alice 和 Bob 持有的承諾交易略有不同:
| 輸出 | Alice 版本 | Bob 版本 |
|---|---|---|
| 自己的餘額 | 延遲輸出(to_local) | 延遲輸出(to_local) |
| 對方的餘額 | 立即輸出(to_remote) | 立即輸出(to_remote) |
延遲輸出 (to_local)
廣播承諾交易的一方,自己的資金會被鎖定一段時間(例如 144 區塊 ≈ 1 天)。 這給了對方時間來檢測並懲罰作弊行為。
# to_local 腳本(簡化版)
OP_IF
<revocation_pubkey> # 對方可以立即領取(如果我作弊)
OP_ELSE
<to_self_delay> # 等待 N 個區塊
OP_CSV
OP_DROP
<local_delayed_pubkey> # 然後我可以領取
OP_ENDIF 更新通道狀態
每次支付都會創建新的承諾交易。舊的承諾交易必須被撤銷,否則可能被用來作弊。
撤銷機制
- Alice 想支付 0.1 BTC 給 Bob
- 雙方創建新的承諾交易(Alice: 0.9, Bob: 0.1)
- Alice 交出舊承諾交易的撤銷密鑰
- Bob 交出舊承諾交易的撤銷密鑰
- 舊狀態被撤銷,新狀態生效
撤銷密鑰: 如果 Bob 廣播已撤銷的舊承諾交易(試圖作弊), Alice 可以使用 Bob 之前交出的撤銷密鑰,立即領走通道中的所有資金。
關閉通道
協作關閉 (Mutual Close)
最理想的情況:雙方同意關閉,創建一筆簡單的結算交易, 直接將資金分配給各方,無需等待延遲期。
協作關閉
- • 費用最低(一筆簡單交易)
- • 立即可用(無延遲期)
- • 雙方友好分手
強制關閉 (Force Close)
當對方不合作或離線時,可以單方面廣播最新的承諾交易。 自己的資金會被延遲鎖定,對方可以立即領取。
強制關閉
- • 費用較高(需預估未來費率)
- • 自己的資金需等待延遲期
- • 對方的資金立即可用
懲罰關閉 (Penalty Close)
如果對方試圖廣播已撤銷的舊承諾交易(作弊), 你可以使用撤銷密鑰在延遲期內領走通道中的所有資金。
懲罰機制
- • 作弊者失去所有資金
- • 需要在延遲期內檢測並響應
- • 這就是為什麼需要「瞭望塔」服務
通道容量和流動性
理解通道的容量限制:
- • 通道容量:通道中的總資金
- • 本地餘額:你可以發送的金額
- • 遠端餘額:你可以接收的金額
- • 本地 + 遠端 = 通道容量
通道餘額示例
本地(可發送)
遠端(可接收)
70% 可發送 / 30% 可接收
最佳實踐
- ✓ 選擇穩定、信譽良好的節點開通道
- ✓ 開通道時預留足夠的鏈上手續費
- ✓ 使用瞭望塔服務防止對方作弊
- ✓ 定期備份通道狀態
延伸閱讀: 了解 HTLC, 這是實現多跳支付的關鍵技術。