作者：Anony
在本系列的第二篇文章中，我們已經指出，閃電通道的構造方法和最終效果，可以隨比特幣協議的提升而提升。然而，實際上，在一個較少獲得關注、但與通道的構造緊密相關的領域，閃電通道一直在比特幣協議的共識規則未升級的前提下不斷優化，那就是交易的手續費支付。
在閃電通道中，通道狀態以承諾交易來表達，而每一筆承諾交易都有可能被髮送上鍊，那就必須為這些交易考慮手續費問題。反過來，支付手續費的方法也會影響通道內可用的餘額和批量處理交易的可能性，進而影響用戶體驗。
在本文中，我們會回顧閃電通道的手續費支付設計是如何得到逐步優化的，這些優化又如何改進用戶體驗。需要讀者先理解閃電網絡的工作原理和安全要求。
在開始之前，請想一個 “簡單” 的問題：一條通道是由雙方共同擁有的，雙方都有可能在其中持有餘額，那麼，在需要將交易提交上鍊的時候，應該由誰來支付手續費呢？在比特幣交易中，這該如何實現？
好了，我們先從比特幣手續費支付的方法說起。
手續費的支付與追加
在一筆比特幣交易得到區塊確認時，其輸入資金之和與輸出資金之和的差值，可以被挖出這個區塊的礦工收取，這個差值就被稱為 “手續費”，也是礦工將這筆交易納入區塊的主要激勵。
在構造交易時，用戶為交易選定輸入和輸出，同時也就決定了手續費的大小。然而，手續費市場可能會劇烈變化，用戶選定的手續費大小，可能在稍後被證明不足以讓該交易在用戶希望的時間內得到確認，因此，我們需要考慮 “追加” 手續費。這是改善用戶體驗的必需。
RBF
其中一種方法稱作 “手續費替換（Replace-by-fee）”，其原理是使用原交易的部分或全部輸入來發起一筆新交易，並讓新交易（替代交易）攜帶比原交易更高的手續費，從而吸引礦工打包替代交易。如下圖所示（留意數額）：
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} U1 --> T1[Tx #1] T1 -.-> P1(Payment #1, 300 sats) T1 -.-> C1(Change #1, 100 sats) T1 -.-> F1{{Fee #1, 100 sats}}你也可以認為，Tx #1 是在嘗試重複花費 UTXO #0，兩筆交易是在 “賽跑”。但因為 Tx #1 給出了更高的手續費，顯然礦工會更喜歡這筆交易。這就起到了我們所說的 “追加手續費”、吸引礦工優先打包交易的效果。
CPFP
另一種方法是，使用原交易的輸出發起新交易，並讓新交易攜帶較高的手續費，從而，礦工如果想要打包新交易，就必須打包原交易（換句話說，舊交易和新交易將作為一個整體 —— “交易包” —— 與交易池內的其它交易競爭）；這就叫 “子為父償（CPFP）”。如下圖所示：
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} C0 --> T1[Tx #1] T1 -.-> C1(Change #1, 50 sats) T1 -.-> F1{{Fee #1, 100 sats}}與 RBF 相比，CPFP 有個缺點：新交易需要佔用額外的區塊空間（也就意味著新交易所攜帶的部分手續費將用來讓自身得到確認，而不是為原交易追加），而 RBF 則基本上不需要。這意味著在兩種方法都能使用的場合，RBF 的效率更高、經濟性更好。
有了這些基本概念，我們再來看看閃電通道的設計。
早期設計（Legacy Channels）
graph LR Channel(The Chennel, 2-of-2 Multi-sig) --> TC1[Commit #1] TC1 -.-> TR(To Remote) TC1 -.-> TC(To Local) TC1 -.-> OH(An Offered HTLC) TC1 -.-> RH(A Received HTLC) OH --> HT[HTLC-Timeout tx] RH --> HS[HTLC-Success tx]上圖展示了對通道的一個參與者來說，與一個通道狀態有關的交易：Offered HTLC 和 Received HTLC 分別代表著這個參與向對方提供的 HTLC 以及從對方收到的 HTLC，為一致地適用基於懲罰的閃電通道安全規則（LN-Penalty），這兩類輸出都必須得到預簽名的交易（並在交易的輸出中放置懲罰分支，在上圖中沒有畫出） [2]。上圖所概述的兩類交易（承諾交易、HTLC 相關交易）都必須考慮手續費支付和追加的問題。
最初的閃電網絡規範在手續費支付上作了這些設計：（1）總是由通道的發起方為承諾交易支付手續費（這跟本系列第五篇提到的 “單向注資” 設計是高度綁定的）；（2）在 HTLC 交易中，讓交易的得益者來支付手續費。除此之外，儘管承諾交易的特殊性使得 RBF 幾乎不可用（設想在強制關閉場景中，一方希望讓一筆承諾交易上鍊，但對方卻不配合，他們無法形成新的交易來替代以往簽名的承諾交易），承諾交易沒有作出便於使用 CPFP 的設計 —— 儘管 To Local 輸出是交給交易廣播者自己的，但這個輸出帶有時間鎖，無法立即動用，因此也就無法即時用於發起子交易；HTLC 交易自身同樣需要對方的簽名，而其輸出同樣帶有時間鎖分支。
這樣的設計在以下幾個方面影響了用戶體驗：
- 總是讓一方支付手續費，有損於公平；
- 承諾交易無法使用 RBF，又沒有針對 CPFP 的設計，因此必須在構造階段就保證其帶有高得足以得到確認的手續費；但是，由於承諾交易在未來的上鍊時間是不確定的，這就成了一個幾乎無解的問題 —— 實用的辦法就只有非常保守地高估手續費 [3]；但這些手續費又會佔用一部分通道資金，降低通道的有用性；
- 此外，手續費市場也會波動，由此帶來的預估手續費的波動，也會使通道參與者的可用餘額產生波動，這會給用戶帶來困惑；而且，在鏈上手續費高漲的時期（也是人們最希望能夠利用閃電網絡來節約手續費的時期），這會大大壓縮可用的通道容量、削弱閃電網絡的效用 [4]。
那麼，要如何優化呢？
錨點通道
“錨點通道（Anchor Channels）” 的思想是，在承諾交易中額外為每一方安排一個低價值但即刻可用的輸出（同時為所有其它輸出增加一個長達 1 區塊的相對時間鎖），以允許每一方都能在廣播承諾交易之後，使用該錨點輸出來發起 CPFP。當然，由於錨點輸出自身的價值較低，用戶必須為子交易注入額外的資金，才能成功追加手續費。
除此之外，錨點通道還對 HTLC 交易應用了一種大膽的技巧：當一方為對方的 HTCL 交易簽名時，使用 “SIGHASH_SINGLE | ANYONECANPAY” 的哈希標籤 [5]；這種標籤使得簽名僅覆蓋一對輸入（也即目標 HTLC）和輸出，並使這對輸入和輸出可以組合到其它有效的交易中。這就使用戶可以將自己得到的多個預簽名 HTLC 交易組合成一筆。而且，閃電網絡規範還特別規定：錨點通道的 HTLC 交易自身不應攜帶任何手續費；也即，用戶就應該將自己應得得 HTLC 交易都組合（批處理）成一筆，然後通過為之添加輸入和找零輸出的方式支付手續費。
在這兩項設計的結合之下，閃電通道的實現得到了簡化，手續費佔用餘額的問題得到了優化：
- 在承諾交易中，不必完全依賴於承諾交易自身來支付手續費，相反，可以設定一個較為穩定的手續費，並將手續費追加的問題留給依據錨點輸出發起的子交易；這樣，手續費佔用通道可用餘額的問題就得到了緩解；
- 請注意，這並沒有完全解決需要預估手續費的問題。因為手續費市場的波動，交易能夠得到節點轉發的費率門檻值也會波動，儘管承諾交易不必再保證自己隨時都能得到確認，但依然需要保證自身的費率高得能夠吸引節點傳播；如果傳播不出去，那 CPFP 方法也不會奏效。但這個難度已經降低了。
- 在 HTLC 交易中，手續費不再由交易的輸入（也即 HTLC）來支付，因此也不必再考慮費率水平如何影響 HTLC 交易的構造及其可欲性。
代價是，在使用錨點通道時，用戶必須確保自己在錢包中放置了可用的鏈上資金，以備支付手續費的需要。
複雜的事實
你可能會認為，給定比特幣交易的結構和追加手續費的方法，應用上述改進應該是自然而然並且簡單的。然而，事實是，儘管可以說是順理成章的，卻並不那麼容易。因為，多筆交易所能形成的順序關係（拓撲），是多種多樣的。而無論 RBF 還是 CPFP，允許這種行為，都等於是允許交易的發起者佔用傳播交易的節點的一部分資源。這種佔用必須得到約束，否則攻擊者就可以通過交易的替換和交易包的構造，對傳播交易的節點發起 DoS 攻擊。但另一方面，這些用來約束行為的規則也有可能被利用來發起攻擊。
舉個例子。為約束 CPFP 行為，Bitcoin Core 的交易池規則要求，一筆未確認的交易只有擁有 24 個後代交易。那麼好了，在上述錨點通道的承諾交易中，由於兩方都有錨點輸出，因此，一方可以通過利用己方的錨點輸出給承諾交易添加 24 個子交易，從而阻止對方發起 CPFP。由於這種攻擊風險（它被稱作 “交易釘死攻擊”）的存在，上述 Bitcoin Core 規則允許一個例外：當一筆子交易自身重量低於 1000 vB、且僅有一個未確認的祖先交易時，則可成為該未確認祖先交易的第 25 個後代交易。這一例外規則（稱為 “Carve Out”）使上述錨點通道得以安全運作（但依然無法排除被對手影響的風險） [6]。
最終來說，由比特幣全節點組成的網絡以及被各個節點適用的交易池規則，構成了閃電通道這樣的合約式協議的安全依賴（它們往往都需要讓交易即時得到確認，來保證用戶的資金安全性），但這些交易池規則卻可能不夠完美。設計出可靠又能抵禦濫用的交易池規則，並不是容易的事。
自 2022 年以來，比特幣的開發者們開始形成對交易池規則的新想法，其中著名的有 “v3 交易 [7]” 和 “族群交易池 [8]”；前者通過約束交易間的拓撲來支持設計更精妙的規則，後者則希望重新設計交易池的內部排序來支持更好的 RBF 規則。有趣的是，由於族群交易池不允許 CPFP-Carve Out，v3 交易（現已改稱 “TRUC 交易”）將是我們走向族群交易池的橋樑。
下一節，我們就介紹這些想法在 Bitcoin Core 28.0 中的實現（詳情可見這份指南 [9]），以及閃電通道可以如何利用它們來改善用戶體驗。
基於 1P1C 交易包的新範式
首先，Bitcoin Core 28.0 引入了一種新的交易池單元，稱為 “1P1C 交易包”，故名思議，就是僅由兩筆親子交易組成的交易包，它們會作為一個整體跟其它交易池單元（比如交易單體或其它 1P1C 交易包）競爭區塊確認。其中，父交易的手續費率只需滿足 1 聰/vB 的費率下限，不再需要考慮節點隨時波動的進入交易池的手續費率門檻。
其次，在 1P1C 交易包基礎上，如果其中的交易都使用 “3” 的版本號，那麼它們會適用 “TRUC 交易” 的規則：其中的交易單體體積不得超過10 kvB、子交易體積不得超過 1kvB；父交易的費率不再有任何要求（可以是零費率）；最重要的是，當另一筆子交易被添加到同一個父交易上時，不論它與原來的子交易是否使用了相同的輸入，都會當成兩者衝突，並適用 RBF 替代規則。
也就是說，雖然 28.0 允許了交易包的轉發，但將交易包的形式限制成了僅有兩筆交易的形式，並且，在子交易層級上的直接衝突和競爭，都不能破壞這樣的形式。這種約束極大地降低了分析和設計替代規則的難度。
回到閃電通道：
- 當閃電通道的承諾交易採用 v3 交易，它自身就無需攜帶任何手續費，這就徹底解決了需要預估手續費以及手續費佔用通道容量的問題！
- 不再需要考慮變更手續費，也就不再需要協商手續費，也不會再有因為手續費意見分歧而關閉通道的惱人情形！
- 由於不再依賴 Carve-Out，我們也不必再為雙方各設置一個錨點，只需設置一個雙方都可以使用的錨點輸出即可。這可以降低承諾交易的體積，略微改善經濟性。甚至可以使用不需要密鑰就能花費的錨點輸出 [10]。
結語
回到文章開頭的問題：應該由誰來為承諾交易支付手續費呢？理想情況下，當然是誰希望讓一筆交易上鍊，就由誰來支付手續費。如今，在 1P1C 交易包和 TRUC 交易的支持下，我們終於能夠實現這種理想。
腳註
1. https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#channel-establishment-v1 ↩
2. https://ellemouton.com/posts/htlc-deep-dive/ ↩
3. 有一種有趣的想法，來自 Peter Todd，就是在更新狀態時，讓通道參與者為同一個通道狀態按照不同的手續費水平簽名多套承諾交易，從而允許參與者依據上鍊時的具體情形廣播合適費率的承諾交易，包括也可以在彼時發起 RBF。但可以想象，這種版本不一定適合所有類型的通道參與者。詳見：https://www.btcstudy.org/2024/01/07/v3-transactions-review-by-peter-todd/#%E6%89%8B%E7%BB%AD%E8%B4%B9%E6%9B%BF%E6%8D%A2 ↩
4. https://www.btcstudy.org/2024/01/12/rethinking-lightning-by-benthecarman/ ↩
5. 在為比特幣交易的輸入生成簽名時，可以通過一種叫做 “sighash” 的標籤來表明該簽名所覆蓋的交易部分（也即該資金的主人所同意的資金用法）；只有變更被簽名覆蓋了的部分才會使簽名失效（無法通過比特幣腳本的驗證程序）。常見的標籤是 “SIGHASH_ALL”，意味著該簽名覆蓋了所有的交易輸入和輸出 —— 增加、刪除、改變交易輸入和輸出的任何部分都會使簽名失效。詳見：https://www.btcstudy.org/2021/11/09/bitcoin-signature-types-sighash/ ↩
6. https://www.btcstudy.org/2022/08/08/anchor-outputs/ ↩
7. https://bitcoinops.org/en/topics/version-3-transaction-relay/ ↩
8. https://www.btcstudy.org/2024/01/16/an-overview-of-the-cluster-mempool-proposal/ ↩
9. https://www.btcstudy.org/2025/01/07/bitcoin-core-28-wallet-integration-guide/ ↩
10. https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412 ↩
