作者：RGB++ Fans；來源：字節元CKB
在先前的科普文章中，我們已經就支付通道、多跳路由、HTLC 等閃電網路相關的核心概念進行了簡要科普。
我們提到，要在閃電網路中進行轉賬，往往要經由多個中間人節點搭建路徑，而中間節點的可轉餘額往往有限，最終會影響到支付的成功率。為了確保路徑中的節點有足夠資金，增強使用者體驗，要透過一些流動性管理方案來進行調節。但要深入理解流動性管理問題，我們要先引入幾個基本概念，例如本地餘額和遠端餘額（Local and Remote Balance）、入帳容量和出帳容量（Inbound and Outbound Capacity）等。
過去我們曾提到，閃電網路的基本組成單位是節點和通道，後者是基於比特幣網路搭建的鏈下1 對1 轉帳設施。在通道初始化時，雙方會轉入一些錢作為初始餘額，在你這邊的餘額，叫“ 本地餘額”，你對手方那邊的餘額，叫“遠端餘額”。本地餘額決定了你能向對手方轉多少錢，限制了你的支付能力即“出賬容量”，遠端餘額決定了對手方能轉給你多少錢，限制了你的“入賬容量”即收款能力。
雖然參與雙方各自的餘額在通道關閉前可以頻繁變更，但二者加總後的通道總容量無法改變，除非你整個重啟通道或用「通道拼接」 注入資金。
（這張圖顯示了你和Robert 各自的餘額，你的本地餘額為5，遠端餘額為3，通道的整體容量為8）
在理解了上面幾個基礎概念後，我們再來看閃電網路中的流動性管理到底是要解決什麼問題。下圖中展示了一個簡化的節點連接圖示，我們不難看到，你（左下角）只連接到了LNTop 一個節點，由於你的遠端餘額為3，最多能收到3 美元的轉帳。而如果Sophie 要給你轉帳1 美元，則會因中間節點對LNTop 的可轉餘額不足而失敗（紅框處，該節點對LNTop 的出帳容量為0）。
可以說，通道容量是閃電網路在早期階段遇到的嚴重問題之一。如果流動性在整個網路中的分佈更充分，此類問題將有效減輕，對此的解決方案往往被統稱為“流動性管理”，例如透過租賃市場（Lighting Pool）讓客戶端連接到多個流動性充沛的節點、依需求開啟/關閉新通道，或引入通道拼接、再平衡（Channel Rebalancing）等方法，在鏈上或鏈下對通道中的餘額進行調控。
現在有些錢包客戶端還提供自動化的通道管理功能，根據用戶的支付行為和網路狀況對通道進行智慧管理，確保有足夠的流動性進行轉帳。新用戶在剛連入閃電網路時還可以採用「單向注資」 的模式，就是只讓通道對手方注資，自己不在通道初始化時注資，這樣就能夠減輕用戶的經濟成本，但代價是初始時沒有對外支付的能力/出帳容量。
以下我們將對閃電網路中流動性管理方案的常用手法進行更細緻的科普。首先讓我們了解下通道租賃，該方案主要解決節點的「入帳容量」 問題，就是當其他人想要向你轉帳時，你要保證能讓對方成功搭建起支付路徑，這就要對路徑中包含的每個節點都提出要求，例如必須有充足的可轉餘額/出帳容量。前面我們提到的路徑失敗的場景，根源在於某些中間節點與其他節點建立的通道中流動性不足。
建構通道是有代價的，因為參與者往往要鎖定一部分資金，會產生機會成本。而所謂的通道租賃，其想法是透過市場化的手段讓節點運作者直接進行交易，透過「租賃」 制讓資金富餘的節點主動為其他節點搭建通道。例如你是個商戶，需要隨時接收其他人轉來的錢，對額度有很高要求，一天內的「收款能力」要超過200 枚BTC。
於是你透過Lighting Pool 與4 個大型節點達成協議，這4 個節點都與你搭建為期24 小時的通道，各鎖入50 枚BTC，分別為你提供50 BTC 的遠端餘額，這樣在每條通道中你的收款能力都會達到50 BTC。如果有人向你轉賬，可以把這4 個節點中任意1 個當作中間人來搭建支付路徑。
（在1ml.com 上，我們可以看到多個知名的閃電網路節點營運商，這些節點擁有較富餘的資金，與其他節點建立了多個通道，可以透過租賃流動性來獲取收益）
除了上面說的租賃池以外，還有流動性廣告（Liquidity Advertisement），流動性提供者可以用閃電節點的gossip 訊息來播報自己的要價以及通道持續時間，接受要價的節點可以與之開啟通道。此類基於租賃制的方案都會結合保證金制度，防止一方突然違約。
目前Lighting Labs 等閃電網路開發商和Fiber 都在嘗試對單向注資下的流動性租賃場景進行優化，例如Fiber 計劃在CKB 智能合約功能的基礎上引入流動性代付制，會有指定的LSP 服務商節點與用戶建立通道，並在一段時間內為用戶免費提供入帳容量，滿足其收款需求。等用戶收到一些錢後，合約再自動從中抽回成本，與此類場景相關的流動性質押機制也在討論中。
大體來看，通道租賃往往用於解決節點間建立連接、獲取入帳流動性的問題，而下面的通道拼接（Splicing）方案會透過鏈上操作進行注資/提現，直接變更通道中雙方的總餘額。正常情況下通道的開啟和關閉都會用到2/2 簽名，由參與雙方對共同擁有的鏈上資產進行再分配，而在早期的閃電網路方案中通道一旦開啟，除非將其關閉後再重啟，否則無法改變頻道中的整體餘額。
而通道拼接是後來提出的新方案，可以不關閉既有通道，在參與者的協作下，直接在鏈上對通道雙方共同支配的UTXO 進行重組更新，例如在既有資產基礎上增添新的資產讓參與者共同控制，進而改變通道中的整體餘額。下圖簡單概述了這個思路，其中左側是舊通道對應的鏈上資產（UTXO1），由Alice 和Bob 多簽控制，之後雙方發起通道拼接，把另一筆資產（UTXO2）也加進來共同管理，最終通道雙方可共同支配的資產（UTXO3）數量增多，容量增加。
通道拼接也可以用來減少通道中的過剩資金，把暫時處於閒置的資產轉移出通道，提高資金利用效率。相較於傳統的關閉/重啟通道時需要兩次鏈上交互，通道拼接只需要單次鏈上操作，可以顯著降低成本。儘管通道拼接具有明顯優勢，但由於歷史原因該方案沒有徹底成熟落地，其大範圍採用仍需時日。
在了解了通道拼接後，我們繼續介紹通道再平衡（Channel Rebalancing）的思想，這同樣是一種在不關閉通道、不改變通道內總容量的前提下（忽略手續費），對不同通道內的鏈下餘額進行調節的手段。假設你運行了一個閃電網路客戶端，與其他節點之間建立了共三個支付通道：
-
通道1：與節點X 建立，總容量為1 個BTC
-
通道2：與節點Y 建立，總容量為0.5 個BTC
-
通道3：與節點Z 建立，總容量為0.5 個BTC
每個通道的資金分佈如下：
-
頻道1：你的本地餘額：0.9 BTC 遠端餘額：0.1 BTC
-
頻道2：你的本地餘額：0.1 BTC 遠端餘額：0.4 BTC
-
頻道3：你的本地餘額：0.1 BTC 遠端餘額：0.4 BTC
現在的問題是，在通道2 和通道3中你的出帳容量不足，最多能轉給對手方0.1 BTC，無法滿足大額轉帳的需求。同時，頻道1 的出帳容量過剩，達到0.9 BTC，但你短期內根本用不了這麼多。顯然最好的方法是把通道1中富餘的資金移到另兩條通道。於是你打算從頻道1 的本地餘額轉移0.4 枚BTC 到頻道2，轉移0.4 枚BTC 到頻道3。而要達成這樣的效果，你需要完成兩個環路支付（circular payment）。
具體的操作方法如上圖所示，你可以直接轉0.8 枚BTC 給節點X，後者再向Y 和Z 各自轉0.4 枚BTC，然後Y 和Z 分別在通道2 和通道3 中向你轉0.4 枚BTC，增加你的本地餘額，這樣你就有了充沛的可轉資金，滿足未來的大額轉帳需求。
觀察上圖，不難發現環路支付的本質是你向自己轉賬，把自己在不同通道中的餘額轉來轉去，最後讓整體的餘額分配達到你的預期結果，但單憑這種方法無法憑空增加任何一個通道中雙方的總餘額，此外其實施需要依賴以下假設：X 對Y、Z 有充足的可轉資金，換句話說，環路支付往往要求相關節點事先有一定的流動性儲備。
環路支付是通道再平衡思想的一種實現思路，而再平衡方案在實踐中還可以配合其他方法，例如潛水艇互換等。以下讓我們介紹潛水艇互換（Submarine Swaps），該方案的核心思想是在不關閉通道的前提下，借助HTLC 等方法對鏈上與鏈下資金進行互換。
最簡單的潛水艇互換場景是在鏈上向通道中充值，假設Alice 已經和Bob 建立了1 對1 通道，但一段時間後，Alice 的本地餘額基本耗盡，無法再向外支付。此時Alice 要注入更多資金，需要把通道關閉後再重啟，但這條通道是租賃來的，提前關掉不太划算，那該怎麼辦？
如果透過潛水艇互換的話，過程會比較容易，但要藉助HTLC。首先Alice 可以產生一個隨機數R，對其取哈希H(R)。後面Alice 可以在鏈上向Bob 的地址發送BTC，其解鎖條件受到HTLC 的限制。 Bob 要在鏈上解鎖這些比特幣，必須知道H(R) 對應的原像R。
Bob 在鏈下通道中與Alice 透過HTLC 進行交易，但方向反過來：Alice 要出示R，然後才能解鎖Bob 支付的錢。只要Alice 出示了R 的數值，Bob 就可以用它來解鎖Alice 在鏈上鎖定的BTC。之後，Alice 在通道中的本地餘額增加了，在鏈上的資產餘額等價減少（忽略手續費的話），基本上是1 比1 的置換（上面為了便於說明原理，沒有嚴格按照潛水艇互換的常規操作順序來講解，實際上大多數時候是一方先在鏈下創建HTLC，另一方才在鏈上創建對稱的HTLC）。
上述場景主要用於鏈上資產置換鏈下餘額，只要對Alice 和Bob 的操作方向進行調整，就可以調換為提現操作，把鏈下餘額變現為鏈上資產。潛水艇互換是憑藉HTLC 與時間鎖等組合功能來保證安全的，即便對方中途放鴿子拒絕配合你，你鎖在HTLC 裡的錢也安全，因為對方不知道解鎖HTLC 的密鑰，等時間鎖過期後，你便可以拿回本金。
但要注意，上述場景中雖然你的本金不會被盜，但需要有一方在鏈上創建HTLC 鎖定資金，這就必然會產生手續費磨損，如果對方放鴿子必然會對你產生一定影響。為了解決這些問題，潛水艇互換往往有一些配合的輔助手段，例如預付金、聲譽系統等懲罰手段。
我們再概括下，潛水艇互換的核心思想是讓鏈上/鏈下資產實現靈活互換，如果順著通道再平衡的思路，可以實現出更優的流動性調整措施。這裡我們簡單舉個例子：
假設你運行了一個節點，開通了多個通道，某些通道的本地餘額富餘，其他通道的本地餘額嚴重不足，影響了你的支付能力。你想在不關閉通道的情況下，平衡各通道的資金分佈，潛水艇互換可以成為一種良好的解決方法，你可以選擇本地餘額過多的通道，透過潛水艇互換將資金轉移到鏈上，然後再透過潛水艇互換把鏈上資產注入目標通道，整個過程中，不需要關閉任何通道。
不過，總結上述知識點，我們不難發現潛水艇互換和通道拼接、通道租賃等流動性調節操作均會在鏈上留下操作痕跡，進而產生手續費，如果頻繁地進行此類操作，必然會在使用者的經濟成本和UX 上產生壓力。由於比特幣閃電網路依賴BTC 主網，頻繁的進行鏈上互動並不現實，而基於CKB 的Fiber 面臨的此類壓力相對較小，在流動性管理的體驗上較為流暢。但無論如何，閃電網路和Fiber 都在對更新穎的流動性解決方案進行深入研究，未來或將在與Mercury Layer 等專案團隊的積極合作下，摸索出更合適的路徑。
