閃電網絡通道關閉類型詳解：合作關閉與強制關閉的分別、觸發條件、等待期與資金風險

在閃電網絡上，一筆通道資金的歸屬最終只有兩種收場方式：雙方一起把它送回鏈上，或者其中一方單方面把它送回鏈上。前者稱為合作關閉（cooperative close），後者則是強制關閉（force close，亦稱單方面關閉、不合作關閉）。這個二分法決定了三件最切身的事：多久能拿回資金、能拿回多少、以及過程中會不會因為操作失誤或對手方的動作而產生資金損失。

基礎：通道本金從哪裡來，又回到哪裡去

要理解關閉，得先回顧通道的資金結構。建立通道時，雙方把比特幣鎖進一筆鏈上交易的輸出，稱為資金輸出（funding output）。在傳統格式中，這是一個 2-of-2 的多重簽名腳本；在 Taproot 通道（Simple Taproot Channels）中，則是以 MuSig2 聚合公鑰形式呈現的單一 Schnorr 輸出。資金輸出本身並非通道全部，它是一份共享的鏈上鎖定合約。真正驅動通道運作的，是雙方在鏈下持續簽署的一系列承諾交易（commitment transaction），每一筆都會花掉該資金輸出，並依照當前餘額比例分配給雙方。

承諾交易具備版本遞更機制：每產生一筆新承諾交易，舊版本就必須被撤銷。雙方透過交換撤銷密鑰（revocation secret）使舊狀態失效。若任何一方將已被撤銷的舊狀態廣播至鏈上，對手方就能利用撤銷密鑰在時限內將違規方的通道餘額全數罰沒，這就是閃電網絡的核心防作弊懲罰機制（Breach Remedy）。

因此，關閉通道的兩條路徑在邏輯上截然不同：

• 合作關閉：雙方協商簽署一筆全新的專用結算交易花掉資金輸出。這筆交易獨立於鏈下承諾交易序列之外，不受撤銷機制約束，也沒有任何懲罰風險與協議等待期。
• 強制關閉：其中一方單方面將手上最新的承諾交易廣播至比特幣網絡，強制進入鏈上腳本分配。這筆交易屬於承諾交易，因此必須接受時間鎖與防作弊懲罰機制的檢驗。

合作關閉：雙方簽字，一次結清

流程與訊息交換

合作關閉始於 shutdown 訊息。任何一方皆可發送此訊息表達關閉意向，並附上用來接收鏈上結算款項的交付地址（delivery script）。發送 shutdown 後，通道立即進入凍結狀態：禁止新增任何哈希時間鎖合約（HTLC, Hash Time Locked Contract），也停止路由新付款。此時雙方必須等待已在途的 HTLC 處理完畢——透過正常結算或超時退款予以清空。

待所有在途 HTLC 完全清零、通道餘額回歸雙方單純的餘額劃分後，雙方進入 closing_signed 訊息交換階段，針對關閉交易手續費達成共識並完成雙向簽名，最後將結算交易廣播上鏈。整個流程僅需一筆單純的鏈上交易。

觸發條件

實務上選擇合作關閉的典型情境包括：

• 節點營運者主動取回流動性或重組資金配置；
• 節點需要計畫性停機、系統升級、更換伺服器或遷移錢包後端；
• 通道長期單向流動導致流動性嚴重失衡，雙方決定拆除重開；
• 通道路由收益不符維持成本，雙方協議清算；
• 對等節點（Peer）主動通知即將下線並請求配合關閉。

這些情境的共通特徵是：雙方節點皆處於在線狀態、通訊暢通且願意配合協商。

等待期與資金可用時間

合作關閉的結算交易腳本沒有施加任何相對或絕對時間鎖。交易一旦被廣播，資金可用時間完全取決於比特幣區塊鏈的打包確認速度：協議層的等待期為零。在常規網絡環境下，只要獲得 1 次或數次鏈上確認，資金即可自由轉移與運用。

需要注意的是，若廣播時設定的手續費率低於當前記憶池（Mempool）的打包門檻，交易可能會在記憶池中滯留。這屬於鏈上手續費市場的排隊延遲，而非協議層的時間鎖阻擋。

手續費由誰負擔與協商機制

依據 BOLT #2 規範，合作關閉交易的鏈上手續費預設由通道出資方（Funder）負擔。發起 shutdown 的一方不必然是出資方；出資方會優先在 closing_signed 中提議一個費率，對手方可以同意或回送不同的費率提議進行協商，直到雙方數值收斂一致。這可能帶來幾種情況：

• 雙方順利收斂費率並完成簽名，交易即刻廣播；
• 出資方提議過低或對手方要求過高，導致 closing_signed 往返僵持；
• 若對手方長時間無回應或拒絕妥協，發起方最終可選擇直接轉為強制關閉以打破僵局。

強制關閉：單方面把承諾交易推上鏈

流程與訊息交換

強制關閉無需對手方配合或在線。當節點判定無法繼續等待時，會直接將本地保存的最新一版承諾交易廣播至比特幣網絡。該交易花費資金輸出，輸出結構通常包含：

• to_local：廣播方自己的份額，受相對時間鎖（to_self_delay）限制；
• to_remote：對手方的份額，直接支付至其交付腳本，對手方於交易確認後即可立即動用；
• 在途 HTLC 輸出：若關閉時存在未結清付款，將衍生對應的 HTLC 輸出，各自受絕對時間鎖（CheckLockTimeVerify, CLTV）約制。

此處存在一項核心設計不對稱：只有主動廣播的一方需要承擔時間鎖等待期，被動的對手方無需承擔此延遲。

觸發條件

強制關閉的觸發原因可歸納為三類：

第一類：對手方節點不可用。對手長久離線、節點宕機、網絡斷連或未回應 shutdown 訊息，導致合作流程無法推進。

第二類：安全性與異常處置。節點偵測到通訊協議異常、對手方嘗試發送不合規狀態，在本地狀態完好且確認握有最新承諾交易的前提下，主動廣播最新承諾交易以拿回鏈上結算主控權。

第三類：HTLC 逾期與通道停滯。在途付款即將抵達超時上限，若不及時透過鏈上結算處理 HTLC，可能導致上下游資金被鎖定或蒙受路由損失。

需要特別釐清：若本地節點遺失了最新狀態資料，切不可盲目廣播舊承諾交易，否則會直接觸發懲罰機制導致資金全失。此時應依循資料遺失保護協議（Data Loss Protect）或使用靜態通道備份（Static Channel Backup, SCB）請求對手方強制關閉通道。

時間鎖機制與實作差異

強制關閉的延遲主要來自兩層機制：

第一層：相對時間鎖 to_self_delay。承諾交易中屬於廣播方的輸出採用 OP_CHECKSEQUENCEVERIFY（CSV）限制。此參數在開通道時由雙方協商確定（腳本底層上限為 65535 個區塊）。不同客戶端實作的預設值有所差異，常見設定區間約在 144 至 2016 個區塊（約 1 天至 2 週不等），實際等待長度以通道建立時的協商值為準。

設置延遲的目的是保留爭議防禦窗口。在延遲期間內，若廣播方使用的是已失效的舊狀態，對手方（或其委託的觀察塔 Watchtower）即可在窗口內廣播懲罰交易，罰沒違規方的全部通道資金。

第二層：在途 HTLC 的 CLTV 到期高度。若關閉時存在未結清 HTLC，必須等待其絕對區塊高度到期後，才能廣播超時交易（HTLC-Timeout）領回資金。因此帶有未結付款的強制關閉，其資金完全清算週期會顯著拉長。

手續費調整與錨點通道

在傳統通道中，承諾交易的費率在鏈下簽署時即已決定。若鏈上手續費市場劇烈波動，且雙方節點在線，平時可透過 update_fee 協商更新未來承諾交易的費率；但一旦節點離線並廣播舊費率的承諾交易，該筆交易便無法直接在原輸出上追加手續費，容易卡在記憶池中。

為了解決此瓶頸，現代閃電網絡廣泛採用錨點通道（Anchor Channels）。錨點輸出允許廣播方在交易發送後，透過「子為父償」（CPFP, Child-Pays-For-Parent）方式花費錨點並追加手續費，大幅降低交易因費率不足而長期滯留的風險。

兩條路徑完整對照

等待期的防禦本質與節點在線要求

許多人在面臨強制關閉時常產生疑慮：既然承諾交易已經確認上鏈，為何資金不能立即使用？

關鍵在於承諾交易的鏈下本質。由於簽名一旦發出便無法在鏈下物理銷毀，若無時間鎖延遲，作弊者即可在離線廣播舊狀態後立即將資金轉移，使受害者即使持有撤銷密鑰也無從追回。時間鎖將單方面清算轉化為具備防禦期的公開檢驗流程——只要誠實方在窗口期內檢測到違規廣播，即可利用懲罰機制全數奪取違規方的餘額。

這也引導出營運閃電節點的核心要求：節點必須定期或持續保持對鏈上交易的監控能力。若節點長期處於離線狀態，可能錯過爭議窗口。若無法維持 24 小時在線，可委託觀察塔（Watchtower）在本地離線時代表自身監控鏈上動態並自動發起懲罰交易，以消除離線期間的安全暴露風險。

資金風險邊界與避坑指引

風險一：錯誤還原引發的舊狀態廣播

這是閃電網絡中最嚴重的操作事故：廣播已撤銷的承諾交易將導致自有資金被全數沒收。這類情況極少源於故意作弊，多數來自不當操作，例如使用過時的檔案系統備份（如磁碟快照或舊 channel.db）還原節點。若節點資料損毀，應一律使用靜態通道備份（SCB）觸發資料遺失保護流程，引導對手方發起強制關閉，而非嘗試從舊狀態資料庫中廣播交易。

風險二：時間鎖期間的流動性鎖定

強制關閉後，廣播方的資金將被鎖定數天至數週不等。在此期間，該筆資金無法用於鏈下路由、支付或鏈上調度。對於依賴高資金週轉率的流動性提供者而言，長期的資金凍結本身即具備顯著的機會成本與市場流動性風險。

風險三：極端鏈上手續費與粉塵輸出磨損

在強制關閉過程中，每筆在途 HTLC 輸出均需額外發送鏈上交易進行清算。當比特幣主網費率飆升時，小額 HTLC 的領取手續費可能高於輸出本身面額，導致該筆資金因不敷成本而必須放棄（粉塵限額限制），造成本金磨損。

通道關閉決策流程

1. 確認對手方狀態：若對手方節點正常在線且通訊正常，一律優先發起合作關閉。
2. 評估在途支付：檢查通道內是否有未決的 HTLC。若有，優先等待其結算或超時，避免帶著在途合約清算。
3. 協商鏈上手續費：出資方依據當前記憶池深度提議合理費率，設定容忍上限；若費率談判無法收斂且急需資金，再考慮強制關閉。
4. 確認本地狀態完備性：在執行強制關閉前，務必確認節點擁有最新狀態數據；若曾發生資料遺失或使用備份還原，嚴禁手動廣播承諾交易，應使用 SCB 請求對手方關閉。
5. 監控時間鎖進度：發起強制關閉後，確保節點或觀察塔在 to_self_delay 期間維持鏈上同步，待區塊高度滿足後自動領回資金。

常見問題 (FAQ)