作者：Ben，Founder of Discoco Labs
前言
長期以來，我一直在思考一個問題：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端用戶真正所需要的比特幣鏈下擴容網絡應具備哪些特性：
採用非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 的鏈下擴容之路必將迎來更加光明的發展前景。我們將繼續在這一領域進行深入研究，敬請讀者期待我們的進一步成果。
