流動性的藝術：我們需要怎樣的比特幣鏈下擴容網絡

原文標題：《流動性的藝術：我們需要什麼樣的比特幣鏈下擴容網絡》
原文作者： Ben, Discoco Labs founder

前言

長期以來，我一直在思考一個問題：Bitcoin 原生擴容的核心邏輯是什麼？

在深入研究閃電網絡，並試圖在閃電網絡上實現非託管業務時，我們感覺到某些方面的不協調。兩方通道理論上擁有最強大的交易吞吐量，但是實際維護和使用上的問題卻比預期要多得多。閃電網路目前在最初的微支付方向的表現不盡人意，最核心的原因便是流動性。即便當下有大量所謂改善流動性的基礎設施被引入，實際效果仍未達到預期。

就在本文撰寫期間，業界知名的閃電自託管錢包Mutiny Wallet 宣布關閉，隨後結束營運的還有其合作的Liquidity Service Provider（LSP） 。自託管錢包與 LSP 的協作模式一直被認為是閃電網路未來的重要方向，這不免讓人又一次對其未來充滿憂慮。所以，在這個時間點，本文將從流動性擴展的視角，探討通道網路的演進歷程及其未來發展趨勢。

1. 目前閃電網路的問題是什麼？

比特幣的區塊容量有限且主網出塊時間較長，平均約為10 分鐘，這顯然對於其要成為全世界的點對點現金系統的需求來說相差太遠。有鑑於此，我們迫切需要一個擴容方案：其需要對區塊空間佔用小、可以快速結算且必須是一種原生基於比特幣的方案。於是，閃電網路應運而生。

閃電網路定義在鏈上鎖定資產後，在鏈下完成一筆承諾交易的交換即遍算是交易完成，也這是其號稱即時支付的原因。這在體驗上相對比 Bitcoin 主網支付的確認時間受限 10 分鐘而言，對於小額支付場景，無疑是解決了頭號問題。

然而，在閃電網路的實際發展和使用過程中，多個問題逐漸浮現，本文在此總結了四個核心問題：

1.1 節點維護難度高

當下的閃電網路基於P2P 的懲罰交易博弈模型，為了在通道存續期間時刻監控對方是否將不利於自己的舊狀態上鍊，該模型需要WatchTower 時刻在線，這就需要用戶自己維護節點。此外，用戶還需要本地保存懲罰私鑰和承諾交易數據，導致節點的維護門檻和教育成本都很高。

1.2 高度互動性

在閃電網路中，互動性（interactivity）通常指的是在交易過程中，使用者需要進行的一系列互動操作。這些操作往往涉及簽署、交換承諾交易、懲罰私鑰等。例如，每次在鏈下狀態更新時，交易雙方必須同時上線，並簽署新的承諾交易進行交換，這對於用戶的互動性要求很嚴苛。而且在多方互動的時候，HTLC、多跳帶來的複雜性也難以克服。

1.3 資本效率低

兩方通道的LN -Panelty 機制在某種程度上相當於用戶開啟自己的銀行帳戶，還需要自備準備金。典型問題就是用戶接收資金還需要確保通道流動性，資本效率很低。而且許多處於邊緣的通道流動性也不會被充分利用。

1.4 頻道管理成本高

在P2P 頻道中，極度容易出現流動性不平衡的現象，使用者不得不依賴各種工具來輔助補充流動性，例如潛水艇互換、通道拼接等。但這些技術都需要額外的鏈上交易對原始的 FundingTx 進行調整才能夠實現。總的來說，所有的調整手段都代價高昂，特別是在手續費上漲的時候，代價讓使用者難以忽視。

想像一下，對於那些認為自己在使用Layer2 技術進行廉價交易的用戶，突然面臨幾筆主網的鏈上手續費會是怎樣一個尷尬的場面。這種尷尬在主網鏈上手續費變得越高時就越明顯，堪稱「手續費刺客」。

種種問題在閃電網路的實際採用中也展現出了明顯的後果：使用者成長乏力，而且新增使用者大部分會選擇託管方案，從下圖中的統計資料中可見一斑。

新增加的閃電網路使用者選擇使用託管錢包方案和非託管錢包方案的數量統計

我們不難理解造成這種情況的緣由，畢竟對於大部分普通用戶而言，要求其自行維護節點和通道實在是太困難了。

2. 我們需要什麼樣的比特幣鏈下擴容網路？

閃電網路白皮書節錄

依照閃電網路白皮書的描述，如果全世界每個人每年都開關兩次通道，那麼最後需要比特幣區塊容量成長到133MB。比較當下的比特幣主網，區塊大小僅 1MB，即使是使用隔離見證的 P2TR 位址也只有 4MB，可見差距巨大。此外，考慮到實際上對通道流動性的調整的技術(潛水艇交換，通道拼接) 都需要額外的鏈上交易，閃電網路面對比特幣的區塊空間不足的問題在真實場景下則會更加嚴峻。

可見當下的閃電網路在短期內難以滿足大規模C 端用戶的需求，此外，受限於比特幣區塊容量，長期來看閃電網絡在擴容方面的潛力也受到顯著制約。

問題隨之而來：我們究竟需要什麼樣的比特幣鏈下擴容網路？

2.1 閃電網路的現況

為了理解閃電網路目前的局限性，我們需要回溯其設計原理。

當下的閃電網路模型也被稱為LN-Panelty，這個模型通俗來說就是基於懲罰交易的兩方通道模型。其安全性依賴於用戶本地儲存的製衡對方的交易和懲罰私鑰，並且要時刻保持對比特幣鏈上的監控，從而保證交易對手方的一舉一動都在自己監視之下。

在這樣的模型設計下，使用者自己運行節點是無法避免的，因為本地儲存和 WatchTower 功能不可或缺。前文中已經反覆強調了這個部分。

從資本和通訊效率的角度來看，當下的閃電網路流行的模式是一個LSP 超級節點在中間提供流動性，然後用戶再跟LSP 維護者的超級節點建立通道，這本身已經背離了最初設想的P2P 網狀模型。在自然演進的情況下，最後還是回到了經典的軸輻模型。

以下圖為例，左邊是理想的閃電網絡，右邊則是真實的閃電網絡現況。

2.2 理想的toC 鏈下擴容網路的特性

那麼，現在我們設想C 端用戶真正所需的比特幣鏈下擴容網路應具備哪些特性：

1 .採用非P2P 模型，用戶無需自行維護節點，同時保持良好的安全性和便捷性

2.在交互端，用戶支付時無需同時在線，一方離線、非同步操作均可實現

3.提高資本效率，同時滿足非託管需求

4.廉價高效的流動性管理機制，甚至無需用戶自行維護流動性

基於這些目標，本文將帶領讀者一同探索比特幣鏈下擴容網絡的未來發展方向。

3. BTC 原生擴容演進之路

首先我們需要明確，在目前的閃電網路設計的核心機制」LN-Panelty」中，狀態更新機制的基礎在於：

· 承諾交易的儲存與持續監控

· 跨多人協作的多跳機制(HTLC/PTLC)

這些要素構成了目前閃電網路設計的基礎，也直接導致了節點設計的複雜性，表現為：

· 複雜的加密通訊互動

· 本地承諾交易和懲罰私鑰的儲存

· 頻道存續期間無法中斷運作的WatchTower

這些問題促使我們思考是否可以採用更輕量的狀態更新機制來取代 “LN-Penalty”。在這一背景下，BIP118（SIGHASH_ANYPREOUT）被提出作為一種可能的替代方案。

3.1 LN-Symmetry：狀態更新引入版本機制

BIP118 提議引入SIGHASH_ANYPREOUT 簽章模式，它允許交易的輸入無需完全指定前一個輸出，並且在不改變簽名的情況下更新其前序交易。這樣的設計相對「LN-Penalty」就可以顯著降低節點之間的加密通訊複雜度和儲存需求。 SIGHASH_ANYPREOUT 源自論文 eltoo: A Simple Layer2 Protocol for Bitcoin，在最近的閃電網路開發討論中，基於該改進的閃電網路模型也被稱為「LN-Symmetry」。

雖然 LN-Symmetry 降低了本地承諾交易儲存的壓力，但它並未完全消除監控需求。儘管 Eltoo 不需要交換承諾交易和私鑰簽名，但如果某個參與者嘗試將舊狀態發佈到鏈上，另一方仍需即時監控，並及時發布最新的狀態交易以替換舊狀態。這個過程中的監控任務仍然需要傳統的 WatchTower，此時運行 WatchTower 的目的從懲罰變成了狀態替換。用戶依舊需要維護自己的節點。

同時，LN-Symmetry 依然需要HTLC/PTLC 等機制來確保多人協作，這仍然會同過去的閃電網絡節點設計一樣，有很嚴重的通信負擔。

所以，從整體效果來看，LN-Symmetry 給當下閃電網絡的體驗改進是有限的，距離我們追求的目標還有很長的路要走。

為了進一步的改進，本文引出了下一階段的方向：Shared UTXO。

3.2 CoinPool ：降低多方通道的互動性和流動性需求

第一個引出Shared UTXO 概念的論文即是CoinPool: efficient off-chain payment pools for Bitcoin，其核心目標是在SIGHASH_ANYPREOUT 的版本更新機制下進一步解決多方互動的問題。

在 LN-Symmetry 設計中，透過 Eltoo 引入的新的狀態更新機制，的確簡化了點對點通道的狀態管理。然而，當涉及多方協作時，互動的複雜性仍然存在，尤其是在多跳支付（HTLC/PTLC）中，需要各方的密切協調，並多次加密通訊。

CoinPool 的創新之處在於，它利用 Shared UTXO 模型，讓多方在同一個具有版本控制的 UTXO 上協作。透過這種方式，多個參與者可以在不依賴複雜的 HTLC/PTLC 機制的情況下，共同承諾並管理一個 UTXO 的狀態。其主要優勢體現在：

· 大幅降低多方通道的交互複雜性：由於所有參與者都共享同一個UTXO，他們可以透過對該UTXO 的版本更新進行簽署來達成共識，而無需進行多次的鏈上交易或複雜的鏈下互動。這種簡化使得多方通道的管理變得更有效率。

· 鏈下更新機制變得更為直接：在這種設計下，鏈下的狀態更新機制轉變為由多方共同簽章確認某個版本的UTXO。這種方法不僅簡化了狀態更新的流程，還進一步減少了各方之間的依賴性和潛在的衝突點。

· 消除獨立流動性需求：透過Shared UTXO 模型，多位參與者實際上共享了同一個流動性池，無需每位參與者獨立維持足夠的流動性。在多方協作的 CoinPool 設計中，流動性需求可以大幅削減或重新分配。參與者可以利用共享 UTXO 中的流動性來完成支付，而不必各自為自己的通道鎖定大量資金。這不僅提高了資金利用效率，也減少了個別參與者的資金壓力。

CoinPool 的設計透過共享UTXO 的方式，成功地將多方通道中的交互複雜性降至合理水平，同時維持了系統的安全性和高效性。更重要的是，它減少了對每個參與者獨立流動性需求的依賴，為多方協作提供了一種更輕、更靈活的解決方案，突破了傳統LN 模型在多方互動和流動性管理上的局限。

然而，這樣一個具備顯著優勢的方案，為何至今尚未被大規模採用？問題的根源在哪裡？

3.3 為什麼 CoinPool 沒有真正實施？

儘管CoinPool 擁有眾多優點，並被視為一種理想擴容模型，但是其依賴的軟分叉升級要求太多，以至於我們在有生之年都可能看不到其在比特幣網路上落地。 CoinPool 對軟分叉升級的需求主要集中在以下兩個方面：

3.3.1 狀態更新機制升級

由於CoinPool 是基於Eltoo 設計的，繼承了其對狀態更新機制對軟分叉的需求，即需要比特幣升級啟用一個新的簽名模式SIGHASH_ANYPREVOUT(APO)，但眾所周知，比特幣軟分叉升級進展緩慢，使得CoinPool 的狀態更新機制所依賴的技術難以應用於現實。

3.3.2 Shared UTXO 需要契約簡化操作機制

如前文所述，Shared UTXO 每次狀態的更新都需要收集所有共享該UTXO 某個版本的簽章。在這個過程中，如果有一方掉線，那麼整個系統將會陷入停滯，用區塊鏈術語來說就是這樣的系統活性（liveness）很差。為了克服這項挑戰，系統需要一種可以以較低成本且不完全依賴合作更新 Shared UTXO 的機制。

CoinPool 論文中，提出了 OP_MERKLESUB，旨在透過默克爾樹結構來驗證並更新特定參與者的狀態。雖然這個設計想法具有理論上的可行性，但它與其他基於梅克爾樹的操作契約面臨相似的問題，即邏輯實現複雜，且難以形成通用、可復用的契約。例如類似**OP_TAPLEAFUPDATEVERIFY(TLUV)**的契約等等。此外，OP_EVICT 這類直接把不合作的一方踢出 Shared UTXO 的契約功能則過於單一，難以預見其能順利通過比特幣網路的升級。

在這些契約提案中，OP_CheckTemplateVerify(CTV) 逐漸成為關注的焦點。與直接建造和驗證一個默克爾樹不同，CTV 則是透過預先定義交易的模版來進行支出限制。 CTV 不僅實現簡單，還可以透過一個交易的承諾鏈條將一系列鏈下的 UTXO 透過一個鏈上的 UTXO 進行承諾。而這些被鏈上承諾的鏈下 UTXO 就是 Virtual UTXO 概念的最初起源。

在這些契約中，CTV 的普及呼聲最大，因為其既簡單又通用。 CTV 強大的能力不僅可以實現類似 CoinPool 的想法，更是可以為 Rollup 所用。可以想像每次透過 OP_CAT 進行 ZKP-MerkleState 驗證，並且在腳本中直接承諾對應 Layer2 狀態的 Shared UTXO，我們將可以建立真正意義上的比特幣 ZK-Rollup 方案。

綜上所述，CoinPool 的實施面臨的主要問題就在於需要輕量的狀態更新機制APO 和Shared UTXO 的操作碼來幫助實現，而這兩者均需要比特幣的軟分叉升級。以至於 CoinPool 論文誕生多年後，還是屬於一個紙上方案。

3.4 Bitcoin Clique：鏈下抗雙花原語2-AS

在前述CoinPool 模型的討論中，我們了解到，其依賴的APO 機制需要進行軟分叉升級才能讓方案得以實現，這在短期內難以達成。那麼如果有一種不依賴比特幣軟分叉升級的新的鏈下防雙花的原語，那麼實現的問題將在很大程度上得到解決。

SIGHASH_ANYPREVOUT 核心作用是提供的是一種可以避免雙花的鏈下狀態更新機制。基於這個思路，如果能找到等效的密碼學原語，就可以解決鏈下狀態更新的問題，還可以避開比特幣操作原語的更新需求。 Bitcoin Clique 這篇論文的出現帶來了新曙光。它引入了一個全新的密碼學原語，2-shot-adaptor-signature（2-AS），為鏈下防雙花提供了新的解決方案。

2-AS 是基於 Schnorr adaptor signature 的密碼學原語，要理解 2-AS，我們首先要對 Schnorr 簽章和適配器簽章有一定了解。

3.4.1 Schnorr 簽章

Schnorr 簽章具有線性屬性，這表示多個簽名可以聚合成一個簽名。簡單來說，若有多個簽章$S_1$ 和$S_2$，可以透過加法聚合成一個簽章$S=S_1+S_2$，而驗證時對應的公鑰也可以聚合成$P = P_1 + P_2$ 。

3.4.2 適配器簽章

適配器簽章有幾個基本的步驟，如Gen 、PSign、PVrfy、Adapt、Extract。在理解 2-AS 時，特別重要的是理解 Psign 和 Extract 這兩個步驟。

本文著重從用途而非密碼學去理解適配器簽章。簡而言之，當兩個主體希望合作確認一筆簽名時，往往透過對方的適配器來作為簽名的一部分，而適配器往往是公私鑰中的公鑰部分，然後持有該適配器對應私鑰也就是所謂的秘密一方擁有可以Adapt 補全Psign 留下的部分簽名的能力。如果只是這樣的話，和 MuSig 是不是差不多？但適配器簽章獨特之處在於可以Extract，也就是當完整的簽章被釋放後，當初發起適配器簽署的Psign 的一方可以透過完整的簽章、先前的部分簽章以及轉接器（公鑰）提取出對應的秘密（私鑰）。

3.4.3 兩者結合：2-AS

前面已經了解Schnorr 簽章和適配器簽章的特性，現在我們可以看看將兩者結合的魔法：2-AS。

假定我們有一個VTXO，並且希望在鏈下能保證其在雙花的時候能被罰沒，那麼我們可以這樣設計：

· 首先我們要有一個懲罰輸出，其中能解鎖的pubkey 是一個懲罰公鑰。保證用戶在進行雙花的時候能夠進行罰沒。

· 交易對手之間合作進行適配器簽章確認鏈下交易，如果使用者兩次使用同一個輸入，那麼該輸出能被服務商罰沒。

· 要求使用者每次在更新狀態的時候都需要產生一個pubkey 作為懲罰輸出，該懲罰輸出的懲罰公鑰由事先決定好的兩對公鑰進行Schnorr 簽章技術加法所構成。

所以我們每次交易前都確認好隨後使用的公私鑰對，提前產生懲罰輸出。那麼一旦雙花發生，服務商就可以透過兩次適配器簽章最終得到對應懲罰輸出的私鑰。

3.4.4 Bitcoin Clique 的優缺點

Bitcoin Clique 方案也並非完美無缺。其缺點在於，在鏈下狀態更新時，需要不斷交換用於建立新的懲罰公鑰的 2-AS 金鑰。並且由於方案是基於 CoinPool 設計，同時為了每次交換 2-AS 金鑰和對新版本的 UTXO 進行校驗簽名，該方案也要求狀態更新時所有人在線上。也就是說通訊的複雜度和互動性依舊很高。

最重要的一點就是這樣的模型是一種類似StateChain 的設計，每次我們在鏈下轉移的是某個UTXO 的所有權，所以使用類似2-AS 的double-spend-prevent signatures 的系統都無法在鏈下支付中進行找零，這就讓應用場景非常有限。

此外，即便是有了便於操作的SharedUTXO 機制和不需要軟分叉的鏈下防雙花原語，我們仍需要所有人在線更新確認UTXO 的新狀態，即使是每次狀態更新只會影響鏈下網路中的一部分人。讓不相關的人在線上參與鏈上更新是不合理的。而完全消除流動性需求也不是我們所期望的，缺乏流動性潤滑的支付方案無法進行面額找零，且由於退出問題，所有人的面額往往必須相同。

因此，目前不存在一個非通道且支援動態面額並基於 UTXO 的鏈下擴容方案。曾經以太坊也在這個路線上飽受困擾，我們稱之為 Plasma 陷阱，相關的研究可以參考論文 Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma。

總結問題與教訓：

1.需要流動性的潤滑保證動態面額支付(可找零交易)：這需要保留通道設計，同時也可以避免退出問題。

2.減少對所有參與者同步在線的依賴：我們不希望每個用戶在鏈下網絡進行任何狀態更新的時候都在線，Shared UTXO的更新應該是相關的人在線上協作更新即可。

基於上述認識，本文繼續沿著這一方向，探索更優化的方案。

3.5 通道工廠和虛擬通道

在前面的討論中，我們認識到不僅需要保留通道的設計，也需要Shared UTXO 為我們帶來鏈條下的低成本效益。那麼有一個在閃電網路領域討論已久的概念進入了我們的視野，即通道工廠（Channel Factory）。

先前，我們提到了被鏈上 UTXO 承諾的鏈下 UTXO 被稱為 Virtual UTXO。如果把鏈下的 Virtual UTXO 作為通道的 FundingTx，我們就得到了一個新概念，也就是虛擬通道（Virtual Channel）。那麼在這個 Shared UTXO 中鏈下的虛擬通道就由 Virtual HTLC 連接。一切都鏈下了，全都「虛擬化」了。這似乎提供了一個理想的解決方案：在鏈下實現大部分功能，包括流動性調整等，閃電網路的擴展似乎迎刃而解了。

但事實真的如此美好嗎？

由於繼承了 Shared UTXO 的特性，通道工廠需要多個使用者的協同工作來開通和關閉。如果其中任何一個使用者無法及時配合（例如離線或不回應），可能會影響整個通道工廠的功能。由於通道工廠涉及多方共同簽署狀態更新，任何一方的不同步或惡意行為可能導致其他使用者無法順利關閉通道並提取資金。

而這樣的設計的問題也很明顯，雖然透過這種方式把通道開關的成本降低了，但是通道之間的安全模型還是依賴承諾交易和HTLC。因此，通訊和互動的問題依舊存在，甚至這種方案的實現複雜性比當下的 LN-Panelty 還要高。

3.6 ARK JoinPool 和臨時通道

透過先前通道工廠的案例回顧，我們得到一個結論：在基於Shared UTXO 中的通道設計中，也許並不應該繼續沿用經典的「LN-Panelty」的通道設計，但同時應保留引入通道的優點：

1.流動性所帶來的動態面額；

2.易於退出。

基於此，一種利用 JoinPool 的臨時通道的設計應運而生，即 ARK Protocol。

3.6.1 JoinPool：部分人參與更新

如前文所述，CoinPool 給多人的鏈下協作擴容帶來的潛力，例如不需要流動性、多跳、HTLC 等複雜且容易出故障的設計。但是 CoinPool 模型最關鍵的問題就是對使用者的線上需求：整個 Shared UTXO 中的使用者在鏈下狀態更新時都必須在線，即便部分使用者的狀態沒有改變，依然需要線上驗證並給予對應的簽章。這項要求讓我們始終無法避免使用者需要運行自己節點的問題。

為了解決這個難題，一個新的模型被提出，即 JoinPool。 JoinPool 在 Shared UTXO 之中的理念是：每次有使用者需要更新其鏈下狀態時，大家一起加入到一個代表其對應 UTXO 新狀態的 Shared UTXO 之中。這就解決了不相關的用戶在他人執行時也需要在線的問題。也就是說，在基於 JoinPool 的設計中，用戶僅在需要進行交易時才需在線上。

但是我們都明白，需要不間斷運行閃電網路節點除了需要保證用戶私鑰在線可以進行簽名外，還有一個重要的原因是，每個通道成員都需要WatchTower 持續監視交易對手方是否把對自己不利的承諾交易到鏈上。這引出了我們需要解決的第二個問題。

3.6.2 WatchTower 職責轉移：使用者無須自行維護節點

在經典的LN -Panelty 的設計中，每個使用者需要建立自己的WatchTower 來監控對方是否把舊的狀態上鍊，若是則會進行懲罰。在這樣的舊模型中，我們所有人的交易對手方都是對等的閃電節點，每次參與交易都有可能是和不同的節點開啟通道進行交易。但在 ARK 中，所有的使用者其實都是和 ASP（ARK Service Provider）交互，並不會直接和別的使用者交互。

對 ASP 來說，用戶在鏈下的 VTXO 一經交易，就會簽署一份棄權交易。這是因為理想情況下用戶在鏈下的 VTXO，是不會被提到鏈上的，而是不斷被引用再進行到下一輪交易之中。若是一份VTXO 在鏈下被交易，同時在鏈上被提出，這就代表著這個VTXO 被用戶進行了雙花交易，那麼ASP 就會用該用戶當初鏈下簽署的棄權交易來對該用戶提到鏈上的資金進行罰沒。 ASP 會對歷史上所有出現的 VTXO 進行監控，防止有人從鏈下已經花費的 VTXO 中再到鏈上惡意退出。

這就將WatchTower 的營運責任從普通用戶轉移到了operator，相對於閃電網路而言，這種模式有了一個巨大的改進：我們終於不再需要一般使用者運行自己的節點來保障自己的安全。

關於其他方案在最佳化使用者節點運作方面的小結：

· 閃電網路節點雲端託管

有些方案選擇在雲端平台上運行閃電網路節點，以協助使用者降低運行節點的使用門檻。然而，這種方案本質上違背了閃電網路本身的安全假設。 在閃電網路技術中，私鑰和承諾交易的儲存在許多場景中同樣重要。因此，簡單地使用遠端私鑰並不能保證安全。

本質上，這個方案將兩方博弈場景變成了一個涉及我、交易對手方和雲端託管方的三方博弈場景。自己在與對手方交易後但狀態尚未上鍊的狀態時，雲端託管方可以單方面刪除我雲端節點中的承諾交易，此時我的交易對手方便可將對其有利的狀態上鍊。在這樣的閃電網路雲端節點託管方案中，存在著雲端託管平台和交易對手方串通作惡的風險。

· CRAB 和Sleepy CRAB

Aumayr 等人提出的CRAB (Channel Resistant Against Bribery) 協議，透過額外添加抵押品結合激勵礦工的機制來保障支付通道的安全，尤其是在用戶離線的情況下。這種機制減少了對第三方 WatchtTower 的依賴。然而，這種抵押品機制無疑進一步加劇了類似「入帳流動性」的問題。因為它需要用戶在加入鏈下網路時，鎖定更多與交易目的無關的資金，雖然確保了安全性，但犧牲了資金的流動性和效率。而該類方案仍需要用戶自行運行節點，只是降低了對用戶在線的要求。

3.6.3 臨時通道：使用者無需自行維護通道流動性

有人可能會問，為什麼ASP 服務商願意為我們在JoinPool 的通道注入流動性？這是因為使用者如果想使用基於 ARK 網路的 VTXO，必須先將自己的 UTXO 與營運商一起存入多簽位址，其類似於一個 FundingTx，以換取 VTXO。本質上，用戶每次鏈下交易都是在使用 opeator 的資金，但是會出讓此前自己此前和 opeator 多簽的資金。

而之所以把 ARK 的通道稱為一種臨時通道，是因為它具有單向性和一次性注資 兩種特點。

· 單向性：在單向通道內，資金只會從指定發起方轉入對應的輸出方。

· 一次性注資：ARK 的通道只需要一次性注入資金。資金注入後，不需要繼續維護通道的流動性。

在這樣的臨時通道的設計下，注資完成之後，通道不需要再進行再平衡等調整。相對於閃電而言，不僅使用者不再需要關心通道流動性，流動性提供者也不再需要維護通道流動性。通道中唯一存在的變動只剩下了使用者退出這一事件。

3.6.4 ARK 協議的總結

綜合以上所述，我們可以清楚地看到，ARK Protocol 的設計相對於閃電網路在使用者體驗上已經有了驚人的進步：

· 使用者無需自行維護節點

· 使用者無需自行維護通道流動性，無入帳流動性問題

· 支援非同步交互，無需雙方同時在線

4 . Bitcoin 原生擴容範式的改變

透過上文的研究，我們探討了基於Shared UTXO 的多個鏈下擴容方案。 Shared UTXO 的設計初衷是為了解決流動性問題，然而，隨著協議的不斷演進，我們意外地發現它帶來了許多我們曾期望但未敢奢望的優勢。

這標誌著Bitcoin 鏈下擴容進入了一個新的發展方向，相較於原有閃電網路的模式，這是一種範式轉移：

· 從P2P 模型到引進無信任的operator

鏈下擴容網路的邏輯從最初Lightning 網路的「使用者對使用者」雙邊賽局模型，逐步演變為「使用者與operator」之間的博弈模式。不同的是，用戶無需信任這個第三方的 operator。

· 使用者無需自行維護節點設施來保證資產安全

傳統的LN-Penalty 模型以及諸如CRAB 等最新研究，依賴使用者自行提供抵押品以保障資金安全，同時要求使用者在通道存續期間保持在線並運行節點。然而，未來的方案將不再需要這些操作。更重要的是，這些流程仍保持非託管性質，使用者始終保留對其資產的控制權。

· 流動性管理職責從使用者轉移到operator

在經典的LN-Penalty 模型和改進設計中，使用者需要自行調整通道中的流動性，特別是在流動性不平衡時。這通常需要一定的專業知識，並且在沒有 LSP（流動性服務提供者）的幫助下操作複雜。然而，隨著流動性管理職責轉移到第三方 operator，使用者不再需要擔憂流動性管理。這極大地簡化了用戶體驗，並且消除了加入網路的障礙。

· 資本效率與潛力極大提升

新的協議設計都在邁向P2POOL 模型，其在資本效率上與當前的閃電網路存在根本性差異。在LN-Penalty 模型中，每個使用者在開啟閃電通道時必須自行提供流動性，但這些通道的流動性大部分時間是閒置的（付款並不頻繁發生，且支付不均勻分佈於各通道），導致用戶的資金未能有效利用。而在新的協議設計趨勢中，流動性被集中到流動性池進行統一管理，這為未來的 DeFi 場景提供了無限可能。

這場範式轉變表明，流動性管理是 Bitcoin 原生鏈下擴容演進的本質，也是未來繼續演化的核心主線。

未來，隨著科技的不斷進步和新方案的不斷湧現，Bitcoin 的鏈下擴容之路必將迎來更光明的發展前景。我們將繼續在這一領域進行深入研究，敬請讀者期待我們的進一步成果。

參考文獻：

· Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off- Chain Instant Payments. Retrieved from https://lightning.network/lightning-network-paper.pdf

· Decker, C., Russell, R., & Osuntokun, O. (n.d.). Eltoo: A Simple Layer2 Protocol for Bitcoin. Blockstream. Retrieved from https://blockstream.com/eltoo.pdf

· Naumenko, G., & Riard, A. (n.d.). CoinPool: Efficient off-Chain Riard, A. (n.d.). CoinPool: Efficient off-Chain Payment Pools for Bitcoin. Retrieved from https://coinpool.dev/v0.1.pdf

· Delving Bitcoin. (n.d.). LN-Symmetry Project Recap. Retrieved from https://delvingbitcoin.org /t/ln-symmetry-project-recap/359

· Riahi, S., & Litos, O. S. T. (2024). Bitcoin Clique: Channel-free Off-chain Payments using Two-Shot Adaptor Signatures. Cryptology ePrint Archive, Report 2024/025.

· Retrieved from https://eprint.iacr.org/2024/025Dziembowski, S., Fabiański, G., Faust, S., & Riahi, S . (2020). Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma. Cryptology ePrint Archive, Report 2020/175.

· Retrieved from https://eprint.iacr.org/2020/ 175ARK Network Blog. (n.d.). Retrieved from https://github.com/ark-network/arkdev.info/tree/master/blog

· Somsen, R. (n.d.). Simplest Ark Explanation . Retrieved from https://gist.github.com/RubenSomsen/a394beb1dea9e47e981216768e007454?permalink_comment_id=4633382

· BRQGoo. (2023). Introducing ARK. Medium. Retrieved from https://brqgoo.medium.com /introducing-ark-6f87ae45e272

· JohnLaw2. (n.d.). LN Scaling Covenants. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-scaling-covenants· JohnLaw2. (n.d.). LN Factory Optimized. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-factory-optimized

· Shinobi. (n.d.). Timeouts: A Solution to Scaling Lightning Network LSPs. Bitcoin Magazine. Retrieved from https://bitcoinmagazine.com/technical/timeout-trees-a-solution-to-scaling-lightning-network-lsps

· Rubin, J ., & O'Beirne, J. (2020). BIP-119: CHECKTEMPLATEVERIFY. Bitcoin Improvement Proposal. Retrieved from https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

mediawiki

· Black, B. (2023). [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS. Linux Foundation Mailing List. Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ 2023-August/021907.html

· Aumayr, L., Avarikioti, Z., Maffei, M., & Mazumdar, S. (2021). Sleepy Channels: Bitcoin-Compatible Bi-DirectionCompal Payment Channels that Do Not Require Monitoring. Cryptology ePrint Archive, Report 2021/1445.

· Retrieved from https://eprint.iacr.org/2021/1445Aumayr, L., Avarikioti, Z., Maffei, M. ., & Mazumdar, S. (2024). Securing Lightning Channels against Rational Miners. Cryptology ePrint Archive, Report 2024/826. Retrieved from https://eprint.iacr.org/2024/826.pdf · Todd, P. (2024). Covenant-Dependent Layer 2 Review. Retrieved from https://petertodd.org/2024/covenant-dependent-layer-2-review

原文連結