作者：Pickhardt
在過去幾個月中，我在許多雙邊談話中討論了這篇文章中的想法。為了避免重複不連貫的主張並邀請更多反饋，我將它們寫在這裡。我向已經熟悉這些概念的讀者們道歉，並歡迎評論、反駁和提出開放問題。
注：因為我的母語並不是英語，所以我用了 LLM（大語言模型）來潤色我的文字；而其中的技術內容和論點都屬於我自己。在我指導 LLM 的時候，我並沒有偏離標準的格式和語言風格。
摘要
閃電網絡支持快速、非託管的比特幣支付，前提是在一個支付流的沿路（通常只有一條路徑）都有充足的流動性。然而，支付可行性（payment feasibility）（這樣一個支付流的存在性）是一個結構性的約束，無法單單靠對路由的啟發式分析或者鏈外的再平衡（rebalancing）來解決。在流動性不足的時候，就要發送鏈內交易來修改通道圖譜，這在根本上限制了閃電網絡擴大比特幣支付吞吐量的能力。
眾所周知多方通道能夠提升資金效率，但在實踐中很難協調。Ark 提出了一種機制，以回合為單位協調多方的狀態更新，以相對較低的協調開銷讓成員們對一個新狀態達成共識。本文想要挑戰當前正在形成的觀點：Ark 應主要用作一種服務於 “最後一公里” 的支付系統，彼此之間通過閃電通道連接。相反，本文主張，把 Ark 理解為閃電網絡的基礎設施，可能更好，尤其是，作為一種 “通道工廠”，它可以帶來高效的流動性重新配置。本文的關注點是這樣做的取捨、可行性約束，以及開放的研究問題。
重要提醒：本文並沒有明確反對將 Ark 用於支付，只是追問有沒有更好的應用場景。
1. 回顧支付可行性和閃電網絡的結構性限制
一次閃電支付是可行的，當發送者與接收者在流動性圖譜之間的最小割（minimum cut）超出了支付數量。在實踐中，可行性是難以確定的，因為遠端的通道餘額存在不確定性。這種不確定可以通過使用概率性路由和最優的可靠支付流來減少。
然而，即使優化路由、手續費更新和再平衡能夠提高利用率，它們無法改變全局的支付可行性，除非通道圖譜自身改變。
尤其是：
- 鏈外的再平衡技術可以重新分佈現有通道中的流動性。
- 它 不會 創造新的連接性或單向通行能力（directional capacity）。
- 在無法存在可行的支付流時，就需要發起一筆鏈內交易（開啟通道、關閉通道、通道拼接，等等）。
這個區別就是核心。即使一個節點可以將流動性從一條通道移動到另一條通道（通過環路支付），這樣的操作也會影響遠端的通道，因此不會定向地提高一筆可欲的支付的可行性。想要局部地改變可行性而不影響網絡的其餘部分，就只有通過鏈內交易介入。
《支付通道網絡的一種數學理論》中的形式化分析證明了，最大可行支付速率（maximum supported payment rate）極度依賴於：
- 固定的可用的鏈內帶寬，以及
- 預期的不可行支付比率。
這對兩方支付通道網絡限制非常嚴重，在現實的假設之下，如果沒有持續的鏈內帶寬支持，預期的不可行支付比率可以變得非常高。這一侷限性促使人們探索協調機制，以使用更少的鏈上足跡來重新構造支付網絡圖拓撲。
2. Ark：回合與虛擬 UTXO
Ark 引入了 “回合（rounds）” 的概念：同一回合的參與者們，在一個 Ark 服務提供商（ASP）的協調之下交換 “虛擬 UTXO（vTXO）”。這些 vTXO 代表著鏈外的價值承諾，可以在一段時間內重新分配。
看起來，Ark 風格的系統通過引入 ASP 作為協調員，減少了 coin pool（直譯為 “錢幣池”）的協調和在線交互要求；ASP 會在一個固定的時間窗口內提供過量的流動性，從而不必每個人都立即同一每一個新狀態，而只需最終同意即可。這是一個非常好的屬性。
然而，在 Ark 直接 用作一個支付系統時，其三個屬性就不可不察：
- 因為過期機制而帶來的流動性鎖定：vTXO 帶有過期機制，在還未過期時， ASP 的資金是一直綁定的，等到過期之後才會釋放。
- 找零放大：支付通常要銷燬一個輸入、創建多個輸出（收款和找零），這就增加了 ASP 必須墊付的流動性數量。
- 回合間結算的信任因素：支付只能在回合邊界上最終結算。在兩個回合之間，花掉的 vTXO 在理論上是可以重複花費的，這就產生了關於託管和 ASP 角色的合規解釋的問題。
如果 vTXO 會在到期之前頻繁支付，ASP 需要的運營資本可能會顯著增長（相對於淨支付額）。這讓 Ark 可以獨自提供低開銷、可擴展的支付層的論述變得更加複雜。
3. 將 Ark 解讀為一種通道工廠，和閃電網絡的基礎設施
另一種解讀是不把 Ark 當成一種與閃電網絡競爭的支付系統，而是閃電網絡之下的基礎設施。更具體來說，可以把它理解成一種通道工廠，或者說多方通道機制。
在這種理解之下：
- vTXO 對應於閃電通道，
- 一個 Ark 回合自動可以打開、關閉和重塑許多通道，
- 單筆鏈內交易就可以可以重新構造通道圖譜的一大部分。
這與路由和（鏈外）再平衡都有根本上的不同。它不是 在 一個固定的圖譜中優化支付流，而是帶來圖譜自身的脫坡的結構性變化，這就有可能讓以往不可行的支付成為可行。
多種通道操作 —— 注資、關閉、拼接 —— 都能被壓縮到單筆 Ark 回合交易中。因為閃電網絡已經為這樣的變更要求鏈上確認，所以 Ark 也不會讓時延惡化，因為 Ark 的回合最終可以在每個區塊中發生。
4. 流動性重新配置和操作考慮
閃電網絡運營者已經需要：
- 監視通道，
- 響應鏈內事件，
- 偶爾再平衡或者關閉通道。
在 Ark 回合中輪換 vTXO（例如，每個月幾次），從操作上來看是同類的。具有更高利用率的通道可能要求更加頻繁的輪換，這可以在通道還被主動使用時協調。
故障假設在細節上有所不同，但類型上是一樣的：運營者需要定期參與，而不是持續監視。
5. 流動性池與動態分配
在一個通道工廠（或者說多方通道）中：
- 流動性會在參與者之間形成池子，
- 各池子的規模可以一輪又一輪地調整，
- 需求可以被預測，或者動態響應。
這與當前的 LSP 模式恰好相反：在 LSP 模式中，流動性是以用戶為單位提供的，通常會保持閒置狀態，或者分佈不均。
而池化可以提高資金效率 —— 尤其是（但也不限於）對移動客戶端 —— Ark 也是如此，只是引入了取捨，包括過期事件、協調開銷和 ASP 的流動性管理。確定最優的超時參數（讓 ASP 重新領取 vTXO）依然是一個開放問題。
6. 與閃電網絡集成與託管考慮
當 Ark 被用作一種基礎設施時：
- 支付發生在閃電 通道/網絡 中，
- 結算依然是原子化、端到端的，
- ASP 協調流動性，但並不作為支付的中介。
這保持了閃電通道的非託管、實時結算屬性。相反，在支付中直接使用 Ark 會在回合間引入信任假設。
各司其職 —— 閃電通道用於支付、Ark 用於流動性協調 —— 保持了閃電網絡的核心保證，比如支付的即時結算和強壯的隱私性，同時解決了結構性的可擴展性限制。
7. 路由、Gossip 和開放問題
通過 vTXO 來注資的通道缺少鏈上注資交易，因此在當前，無法通過閃電網絡的 gossip 來公開。這帶來了幾個開放問題：
- 這樣的通道，要如何向路由者表示？
- 路由應該在工廠的層面上運行嗎？
- “流動性廣告（liquidity advertisement）” 是否需要新的抽象？
- 這些機制會如何影響隱私性和可靠性？
- 應該限制基於 vTXO 的通道只能在 ASP 和用戶間存在？還是可以直接在用戶之間存在？
8. 延申的開放問題
將 Ark 視為閃電網絡的基礎設施，而不是一種獨立的支付系統，可以釐清一些取捨，但也提出了一些值得研究的其它開放問題：
- 激勵因素與 ASP 的行為：激勵因素應如何保持一致，從而讓 ASP 的流動性管理決策能夠提升閃電網絡層面的支付可行性，而不僅僅是局部的盈利能力？多個 ASP 之間的競爭會如何影響流動性分配和定價？
- 中心化壓力：在多方構造中彙集流動性，是否會偏向少數量、大規模工廠的規模經濟？這與閃電網絡如今已經存在的支付中心和 LSP 的效應相比如何？
- 故障模式和退出：根據 Peter Todd 論述 Layer 2 的文章（中文譯本）：ASP 故障（或者說大規模退出）的鏈內後果和運營後果是什麼樣的？系統的壓力要如何優雅地釋放？以及，最壞情況下，鏈內操作的代價是多大？
- 時延與可行性：Ark 可以支持結構性的重新配置，但每逢一個回合才能配置一次。回合的頻率和過期窗口要如何選擇，才能平衡支付可行性、資金效率和用戶體驗？
- 隱私性考慮：基於回合的協調機制是否會逐漸洩露關於需求模式的信息或用戶的活動？匿名集與雙向閃電通道相比如何？
- 互操作性和路由抽象：vTXO 注資的通道如何向路由者表示（給定它沒有鏈內的注資交易）？需要新的 gossip 消息或者工廠層面的抽象嗎？
這些問題也不專屬於 Ark ，而是無論什麼時候，只要多方流動性協調裝置出現了，就會自然提出的問題。解決它們，對於理解這樣的機制如何與閃電網絡互補，是根本性的。
參考文獻
- Pickhardt et al., On the Uncertainty of Lightning Network Channel Balances [2103.08576] Security and Privacy of Lightning Network Payments with Uncertain Channel Balances
- Pickhardt & Richter, Optimally Reliable Payment Flows on the Lightning Network [2107.05322] Optimally Reliable & Cheap Payment Flows on the Lightning Network
- Pickhardt A Mathematical Theory of Payment Channel Networks (draft) [Lightning-Network-Limitations/Limits of two party channels/paper/a mathematical theory of payment channel networks.pdf at f670738cd2af93a55c3c919c9a864015f6dd042a · renepickhardt/Lightning-Network-Limitations · GitHub](https://github.com/renepickhardt/Lightning-Network-Limitations/blob/f670738cd2af93a55c3c919c9a864015f6dd042a/Limits of two party channels/paper/a mathematical theory of payment channel networks.pdf)
- Pickhardt How well does Ark scale Bitcoin payments? https://bitcoin.stackexchange.com/questions/128113/how-well-does-ark-scale-bitcoin-payments 5 Todd, Covenant dependent layer 2 review Soft-Fork/Covenant Dependent Layer 2 Review.
- BTC++ Talk on Lightning scaling and limitations https://www.youtube.com/watch?v=c3AuaHJordg
- Bitcoin Amsterdam LN vs Ark panel (2025) https://www.youtube.com/watch?v=AU52kQz2zIM
致謝
在 BTC++ 和 Bitcoin Amsterdam 上與許多朋友的討論以及得到的反饋，幫助我理清了這些論述。本研究就到了 Optensats 和 Patreons 的資助。
