banner
CKB 中文

CKB 中文

CKB 是理想的比特币 Layer 2

閃電網絡流動性管理方案科普

在之前的科普文章中,我們已經就支付通道多跳路由HTLC 等閃電網絡相關的核心概念進行了簡要科普。

我們提到,要在閃電網絡中進行轉帳,往往要經由多個中間人節點搭建路徑,而中間節點的可轉餘額往往有限,最終會影響到支付的成功率。為了確保路徑中的節點有足夠資金,增強用戶體驗,要通過一些流動性管理方案來進行調節。 但要深入理解流動性管理問題,我們要先引入幾個基本概念,比如本地餘額和遠端餘額(Local and Remote Balance)、入帳容量和出帳容量(Inbound and Outbound Capacity)等。

img

過去我們曾提到,閃電網絡的基本組成單位是節點和通道,後者是基於比特幣網絡搭建的鏈下 1 對 1 轉帳設施。在通道初始化時,雙方會轉入一些錢作為初始餘額,在你這邊的餘額,叫 “本地餘額”,你對手方那邊的餘額,叫 “遠端餘額 ”。 本地餘額決定了你能向對手方轉多少錢,限制了你的支付能力即 “出帳容量”,遠端餘額決定了對手方能轉給你多少錢,限制了你的 “入帳容量” 即收款能力。

雖然參與雙方各自的餘額在通道關閉前可以頻繁變更,但二者加總後的通道總容量無法改變,除非你整個重啟通道或者用 “通道拼接” 注入資金。

img

(這張圖展示了你和 Robert 各自的餘額,你的本地餘額為 5,遠端餘額為 3,通道的整體容量為 8)

理解了上面幾個基礎概念後,我們再來看閃電網絡中的流動性管理到底是要解決什麼問題。下圖中展示了一個簡化的節點連接圖示,我們不難看到,你(左下角)只連接到了 LNTop 一個節點,由於你的遠端餘額為 3,最多能收到 3 美元的轉帳。而如果 Sophie 要給你轉帳 1 美元,則會因中間節點對 LNTop 的可轉餘額不足而失敗(紅框處,該節點對 LNTop 的出帳容量為 0)。

img

可以說,通道容量是閃電網絡在早期階段遇到的嚴重問題之一。如果流動性在整個網絡中的分布更充分,此類問題將有效減輕,對此的解決方案往往被統稱為 “流動性管理”, 比如通過租賃市場(Lighting Pool)讓客戶端連接到多個流動性充沛的節點、根據需要打開 / 關閉新通道,或是引入通道拼接、再平衡(Channel Rebalancing)等方法,在鏈上或鏈下對通道中的餘額進行調控。

現在一些錢包客戶端還提供自動化的通道管理功能,根據用戶的支付行為和網絡狀況對通道進行智能管理,確保有足夠的流動性進行轉帳。新用戶在剛連入閃電網絡時還可以採用 “單向注資” 的模式,就是只讓通道對手方注資,自己不在通道初始化時注資,這樣就能夠減輕用戶的經濟成本,但代價是初始時沒有對外支付的能力 / 出帳容量。

下面我們將對閃電網絡中流動性管理方案的常用手法進行更細致的科普。首先讓我們了解下通道租賃,該方案主要解決節點的 “入帳容量” 問題, 就是當其他人想要向你轉帳時,你要保證能讓對方成功搭建起支付路徑,這就要對路徑中包含的每個節點都提出要求,比如必須有充足的可轉餘額 / 出帳容量。前面我們提到的路徑失敗的場景,根源在於某些中間節點與其他節點建立的通道中流動性不足。

構建通道是有代價的,因為參與方往往要鎖定一部分資金,會產生機會成本。而所謂的通道租賃,其思路是通過市場化的手段讓節點運行者們直接進行交易,通過 “租賃” 制讓資金富餘的節點主動為其他節點搭建通道。 比如你是一個商戶,需要隨時接收其他人轉來的錢,對額度有很高要求,一天內的 “收款能力” 要超過 200 枚 BTC。

於是你通過 Lighting Pool 與 4 個大型節點達成協議,這 4 個節點都與你搭建為期 24 小時的通道,各鎖入 50 枚 BTC,分別為你提供 50 BTC 的遠端餘額,這樣在每條通道中你的收款能力都會達到 50 BTC。如果有人向你轉帳,可以把這 4 個節點中任意 1 個作為中間人來搭建支付路徑。

img

(在 1ml.com 上,我們可以看到多個知名的閃電網絡節點運營商,這些節點擁有較富餘的資金,與其他節點建立了多條通道,可以通過租賃流動性來獲取收益)

除了上面說的租賃池以外,還有流動性廣告(Liquidity Advertisement) ,流動性提供方可以用閃電節點的 gossip 消息來播報自己的要價以及通道持續時間,接受要價的節點可以與之開啟通道。此類基於租賃制的方案都會結合保證金制度,防止一方突然違約。

目前 Lighting Labs 等閃電網絡開發商和 Fiber 都在嘗試對單向注資下的流動性租賃場景進行優化, 比如 Fiber 計劃在 CKB 智能合約功能的基礎上引入流動性代付制,會有指定的 LSP 服務商節點與用戶搭建通道,並在一段時間內為用戶免費提供入帳容量,滿足其收款需求。等用戶收到一些錢後,合約再自動從中抽回成本,與此類場景相關的流動性质押機制也在討論之中。

大體來看,通道租賃往往用於解決節點間建立連接、獲取入帳流動性的问题,而下面的通道拼接(Splicing)方案會通過鏈上操作進行注資 / 提現,直接變更通道中雙方的總餘額。 正常情況下通道的開啟和關閉都會用到 2/2 簽名,由參與雙方對共同擁有的鏈上資產進行再分配,而在早期的閃電網絡方案中通道一旦開啟,除非將其關閉後再重啟,否則無法改變通道中的總體餘額。

而通道拼接是後來提出的新方案,可以不關閉既有通道,在參與方的協作下,直接在鏈上對通道雙方共同支配的 UTXO 進行重組更新,比如在既有資產基礎上增添新的資產讓參與方共同控制,進而改變通道中的總體餘額。下圖簡單概述了這個思路,其中左側是舊通道對應的鏈上資產 (UTXO1),由 Alice 和 Bob 多簽控制,之後雙方發起通道拼接,把另一筆資產(UTXO2)也加進來共同管理,最終通道雙方可共同支配的資產(UTXO3)數額增多,容量增加。

img

通道拼接也可以用於減少通道中的過剩資金,把暫時處於閒置的資產轉移出通道,提高資金利用效率。相比於傳統的關閉 / 重啟通道時需要兩次鏈上交互,通道拼接只需要單次鏈上操作,可以顯著降低成本。儘管通道拼接具有明顯優勢,由於歷史原因該方案沒有徹底成熟落地,其大範圍採用仍需時日。

在了解了通道拼接後,我們繼續介紹通道再平衡(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

img

現在的問題是,在通道 2 和通道 3 中你的出帳容量不足,最多能轉給對手方 0.1 BTC,無法滿足大額轉帳的需求。與此同時,通道 1 的出帳容量過剩,達到 0.9 BTC,但你短期內根本用不了這麼多。顯然最好的辦法是把通道 1 中富餘的資金挪到另兩條通道中。於是你打算從通道 1 的本地餘額中轉移 0.4 枚 BTC 到通道 2,轉移 0.4 枚 BTC 到通道 3。而要達成這樣的效果,你需要完成兩筆環路支付(circular payment)

img

具體的操作方法如上圖所示,你可以直接轉 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。

img

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 等項目團隊的積極合作下,摸索出更為合適的路徑。

📖 推薦閱讀:

載入中......
此文章數據所有權由區塊鏈加密技術和智能合約保障僅歸創作者所有。