本文將從流動性擴展套件的視角，探討通道網路的演進歷程及其未來發展趨勢。本文源自 Ben，Founder of Discoco Labs 所著文章，由 深潮 TechFlow 整理、編譯。
（前情提要：主網上線半個月，Fractal Bitcoin 產生了哪些新機會？ ）
（背景補充：AMA揭秘》以太坊擴展挑戰：Based Rollup 如何緩解流動性破碎問題？ ）
長期以來，我一直在思考一個問題：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 理想的 to C 鏈下擴容網路的特性
那麼，現在我們設想一下 C 端使用者真正所需要的比特幣鏈下擴容網路應具備哪些特性：
- 採用非 P2P 模型，使用者無需自行維護節點，同時保持良好的安全性和便捷性
- 在互動端，使用者支付時無需同時線上，一方離線、非同步操作均可實現
- 提高資本效率，同時滿足非託管需求
- 廉價高效的流動性管理機制，甚至無需使用者自行維護流動性
基於這些目標，本文將帶領讀者一同探索比特幣鏈下擴容網路的未來發展方向。
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。
總結問題與教訓：
- 需要流動性的潤滑保證動態面額支付 (可找零交易)：這需要保留通道設計，且同時也可以避免退出問題。
- 減少對所有參與者同步線上的依賴：我們不希望每個使用者在鏈下網路進行任何狀態更新的時候都線上，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」 的通道設計，但同時應保留引入通道的優點：
- 流動性帶來的動態面額
- 易於退出
基於此，一種利用 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 的鏈下擴容之路必將迎來更加光明的發展前景。我們將繼續在這一領域進行深入研究，敬請讀者期待我們的進一步成果。
