基於軟分叉和 Covenant 的 Layer 2 解決方案評析

2024-10-07 10:46:28

鏈上錢包大致實現了交易對交易的 1:1 映射：用戶執行的每一筆經濟交易，通常都需要對應一筆區塊鏈交易。雖然聚合、coinjoin、剪切支付等技術對此有一些影響，但這一說法大體上是正確的。

閃電網絡實現了交易對交易的多對一映射：閃電網絡的“魔力”在於，一個有效的閃電通道可以進行無限多的經濟交易，而這個通道本身只與一個未花費交易輸出（UTXO）綁定。本質上，我們已經通過壓縮“時間”維度（即交易）實現了顯著的擴容。

然而，即便是為每個用戶創建一個 UTXO，或許仍然不足。因此，有很多提案旨在通過讓多個用戶以自我主權的方式共享單個 UTXO，以實現更大的擴容。這再一次通過將另一個擴容的“空間”維度——用戶——壓縮到一個 UTXO 中。

我們的目標是對所有這些提案進行概述，找出它們共享的技術模式，分析它們需要哪些新的操作碼及其他軟分叉升級來實現功能，並創建一個比較表來展示各部分如何協同工作。在此過程中，我們還將定義什麼是 L2 協議，瞭解閃電網絡目前具備的擴展能力，並探討為實現這一切，我們需要對內存池（mempool）做出哪些改進。

感謝 Fulgur Ventures 贊助了這項研究。他們對這篇文章的內容沒有任何編輯控制權，也沒有在發佈前進行審查。

也感謝 Daniela Brozzoni、Sarah Cox 和其他人在發佈前的審查工作。

定義

什麼是 Layer 2？

“Layer 2” 通常被廣泛定義，甚至像 Liquid 這樣的類銀行實體也能被定義為 Layer 2。然而，本文將採用嚴格定義：Layer 2 (L2) 是一個以比特幣為計價單位的系統，其目的是允許比特幣 (BTC) 在不增加鏈上交易次數的情況下，與其他方進行更多的交易。符合以下條件之一：

在考慮系統內的懲罰和成本時，系統中的任何人都無法通過竊取資金獲利。系統外的成本和懲罰（如聲譽損失、法律後果等）不在我們的定義範圍內。
（首選）資金的真實所有者可以在不依賴任何第三方合作的情況下，單方面提取他們的資金，扣除交易費用。

第一個選項是必要的，因為我們希望 L2 系統能夠處理小到無法在鏈上表示的金額和交易。例如，在閃電網絡中，哈希時間鎖定合約（HTLCs）的金額可能小到無法在鏈上表示。在這種情況下，HTLC 的價值被加入到承諾交易的交易費用中。雖然一個閃電節點可以通過在適當時機關閉通道來“竊取”一個微塵 HTLC，但這樣做的成本高於 HTLC 本身的價值，使得竊取無利可圖。

儘管如此，單方面提款始終是我們首要的設計目標。

基於此定義，像閃電網絡這樣的系統被視為 L2 系統。然而，像 Liquid、Cashu 和 Fedimint 這樣的系統並不屬於 L2，因為它們的資金控制權在其他方手中。客戶端驗證方案（如 RGB）也不被視為 L2，因為它們無法無信任地直接交易 BTC。最後，Statechains 也不符合要求，因為如果不遵循協議，Statechain 實體可以竊取資金。

什麼是 Covenants？

為什麼更具擴展性的 L2 系統需要它們？

在比特幣腳本中，covenants 是一種機制，預先限制了 txout（交易輸出）如何被花費，使得花費該 txout 的交易形式被預定義或以某種方式受到限制，而不僅僅依賴於簽名。L2 系統在多個用戶共享 UTXO 時需要 covenants，因為它們需要通過某種方式約束 UTXO 的使用規則和激勵機制，以實現 L2 協議的運行。

遞歸 Covenants

遞歸 covenant 是指其規則可以無限遞歸地應用於支出交易的子 UTXO，限制其花費方式。遞歸 covenants 長期以來被認為具有潛在問題，因為它們可能會無限期地束縛資金，至少在沒有第三方（如政府）的許可下是如此。

目標

目前，閃電網絡是最先進的 Layer 2 系統，但它仍然有一些限制，具體如下：

擴展性 - 閃電網絡目前要求每個終端用戶至少擁有一個 UTXO。

流動性 - 閃電網絡要求資金鎖定在通道中。

交互性 - 閃電網絡要求接收方在線才能無信任地接收付款。

在評估 Layer 2 系統時，我們的目標是改進這些關鍵限制，理想情況下不引入新的限制。

閃電網絡的擴展性限制

“每個終端用戶一個 UTXO”在實踐中意味著什麼？由於閃電網絡通道可以無限期地運行，一種看法是思考每年可以創建多少個新的通道。創建一個 taproot 輸出的邊際成本為 43 vB；如果通道創建的成本分攤到多通道上，並且在單個交易中創建多個通道，其他交易開銷可以變得微不足道，從而每年可以為新用戶打開大量通道。

例如，假設 90% 的區塊容量用於創建新的 taproot 閃電通道：

據估計，全球大約有一半人口擁有智能手機，約43億人。因此，實際上每年可以為相當大比例的全球人口建立閃電網絡通道，使他們能夠使用該通道進行交易。

然而，通道並不是永久性的。用戶有時會想要更換錢包、增加或減少通道容量等。改變通道容量的最有效方法是通過“拼接”（splicing），這在 Phoenix Wallet 中已經實現。拼接與通道開啟類似，也可以通過攤銷方式來提高效率，即多個拼接操作共享一個交易，從而減少添加和移除資金所需的輸入和輸出數量。

因此，假設使用 musig 簽名方案，每個用戶的拼接所需的區塊空間增量為 43vB 的 taproot 輸出加上 57.5vB 的 taproot 關鍵路徑支出，總計 100.5vB。如果我們再次假設區塊空間的 90% 用於此操作，我們可以計算出：

最後需要注意的是，用戶在切換閃電網絡通道至新錢包時，可以通過一筆交易完成。具體而言，用戶可以選擇信任新錢包，在資金髮送至承諾地址後由其簽署承諾交易，或者雙方錢包實現支持合作關閉並開啟新通道。

當然，除了閃電網絡通道外，比特幣還有其他競爭性的使用場景，而這會如何影響交易費用率（fee-rate）目前難以預測。不過，這些數據為我們提供了一個大致的範圍，表明使用當前技術，至少在技術上可以支持數億自我主權的閃電網絡用戶。

Layer 2 概述

根據我們對 Layer 2 系統的定義，比特幣開發社區討論的主要設計模式有兩種：

通道（Channels）

虛擬 UTXO（Virtual UTXOs）

通道設計模式

在通道設計模式中，閃電網絡是最典型的例子。該協議通過在各方之間交換預簽名交易來運行，這些交易可以被挖掘，但通常不在“正常路徑”（happy path）中。這些預簽名交易將一個 UTXO 在各方之間分割；交易通過不斷改變這個分割的餘額，並創建新的預簽名交易來實現。由於存在多個可能有效的交易花費同一個 UTXO，因此需要某種激勵機制來確保最終被挖掘的是正確的交易。

虛擬 UTXO（V-UTXO）設計模式

在虛擬 UTXO 設計模式中，以 Ark 為最突出的例子。V-UTXO 通過 covenants（契約）或多方協議創建，允許生成可以將 V-UTXO 資金提取到鏈上的交易，但這通常不在“正常路徑”中。在這一點上，V-UTXO 與通道類似。但是，與通道不同，V-UTXO 方案通過花費 V-UTXO 本身來完成交易，這在概念上是在單一的預簽名交易中進行的。

“正常路徑”設計模式

“正常路徑”是指各方通過一個“全體同意”的腳本路徑（如 N-of-N 多籤）來完成交易。Taproot 專為此設計，允許關鍵路徑使用 musig 來實現 N-of-N 多籤。在各方同意的情況下，正常路徑可以高效且隱私地花費資金。

有趣的是，由於虛擬 UTXO 在許多方面都是“真實的”，因此很容易在虛擬 UTXO 上構建通道。只需創建虛擬 UTXO，如果被挖掘，將導致為通道創建所需的 UTXO。因此，虛擬 UTXO 方案實際上是比通道略低一層的設計。

閃電網絡

當前已在生產環境中實施的閃電網絡，主要基於 BOLTs 標準。閃電網絡結合了多種技術，包括閃電通道、HTLC（哈希時間鎖定合約）、P2P 路由網絡、洋蔥路由和發票標準等。值得注意的是，閃電網絡不是一個共識系統，因此“閃電系統”的不同元素不需要被所有用戶以完全相同的方式採用。在本文中，當我們提到“閃電網絡”時，我們將廣義地使用這個術語，包括當前廣泛使用的閃電協議中可以預見的升級。

如前所述，閃電網絡的一個關鍵特性是其終端用戶的擴展性受限，這是由於每個用戶至少需要一個 UTXO。不過，對於閃電網絡的“核心”路由元素——用於路由大多數交易的公共閃電節點——這些擴展性限制並不是主要問題，因為即使終端用戶遠多於路由節點，閃電網絡仍然能夠正常運作。每個用於支付路由的公共通道可以輕鬆支持大量每秒交易。因此，許多未來的 Layer 2 系統也預期參與到閃電網絡中。我們可以看到，現有的非 Layer 2 系統（如 Cashu）也大量依賴閃電網絡才能真正發揮作用：Cashu 的主要用途可能就是發送和接收閃電支付。

非交互式通道

這一設計通過使用 OP_CTV 減少了交互需求，從而改進了閃電通道。然而，由於它未能改善“每個用戶一個 UTXO”的擴展性限制，因此我們不作進一步討論。

通道工廠

通道工廠的構建方式是由多個參與方協商一個 n-of-n 多籤地址，並生成一筆交易來花費該多籤地址，從而創建 n 個 UTXO，將資金分割開來。這些 UTXO 反過來用於支付通道。這些通道可以像直接在鏈上開設的通道一樣使用，具有相同的安全性，因為如果通道狀態需要上鍊，分割交易可以被挖掘。這種方式可以節省關閉通道時的鏈上空間，因為理論上 n 個參與方可以協同關閉所有 nn 通道。

由於通道工廠協商的是可被挖掘的 UTXO，但在正常路徑中並不期望被挖掘，它們是 V-UTXO 的一種非常原始的例子。通道工廠本身並不需要任何軟分叉就可以實現。然而，簡單的通道工廠設計可能不適用於大量參與方，因為協調所需的複雜性會影響擴展性。為了解決這一問題，類似 OP_Evict 或 CTV（通過 txout 樹）的契約提案旨在允許更精細的結果，其中可以強制將個別參與方上鍊，而不需要所有人同時上鍊。

Eltoo/LN-Symmetry

由於 “Eltoo” 這個名稱容易引起混淆，我們將改用更新後的名稱 LN-Symmetry。

Poon-Dryja 通道通過懲罰發佈錯誤狀態的行為，鼓勵正確的狀態上鍊，而 LN-Symmetry 則允許通過額外的交易來更新錯誤狀態。這簡化了閃電網絡通道，去除了與懲罰相關的複雜性。然而，在不受信任的場景中，這可能是一種劣勢，因為懲罰機制在一定程度上能夠抑制欺詐行為。

LN-Symmetry 需要通過軟分叉啟用 SIGHASH_ANYPREVOUT，這允許狀態交易在更新時重新花費其他狀態交易。

LN-Symmetry 本身並沒有提供相較於傳統閃電通道的擴展性改進，但其支持者認為它可以使通道工廠（channel factories）等機制更容易實現。

Ark

Ark 採用了一種全新的交易擴展方法：完全可轉讓的虛擬 UTXOs (V-UTXOs)，這些 V-UTXOs 可以在鏈下通過原子交易進行合併和拆分。在 Ark 中，一箇中心協調者，即 Ark 服務提供商 (ASP)，為用戶提供具有限定生命週期的 V-UTXOs，例如 4 周。這些週期稱為 輪次 (rounds)。V-UTXOs 通過某種機制（如 CTV）創建的池 txouts 生成，每輪對應一個池 txout，使一個鏈上 txout 能夠承諾一個 V-UTXOs 樹。Ark 的擴展性優勢在於輪次的到期：在輪次結束時，池 txout 解鎖，允許 ASP 通過一個帶有單一簽名的小型交易來單方面花費它。由於輪次到期時間，V-UTXOs 本身在池 txouts 到期時也會失效：擁有 V-UTXO 的用戶必須在池 txout 到期前花費 V-UTXO，或將其上鍊（單方面提款）。

為了在各方之間交易 V-UTXOs，Ark 協調者共同簽署了花費一個或多個 V-UTXO 的交易，只有在不同輪次中創建一個或多個新的 V-UTXO 時，這些交易才有效。結合一些精心設計的超時機制（詳見 Ark 文檔），這種依賴關係使得花費 V-UTXO 是無信任的：除非新的 V-UTXO 在另一個池交易中創建，否則無法在鏈上認領 V-UTXO。雖然實現這種依賴關係的方式有多種選擇，但具體細節對於本文並不重要。

值得注意的是，一個給定的 ASP 同時會有許多不同的活躍輪次。為了允許現有輪次中的資金被轉移，新輪次會不斷被創建。然而，現有輪次會與新輪次重疊，因為它們通常會在新輪次和新池 txouts 創建之後才過期。

Ark 經濟學

當一個 V-UTXO 被花費時，ASP（Ark 服務提供商）必須在新的輪次中提供等量的 BTC 來生成一個新的池 txout。但 ASP 不能立即回收已花費的 V-UTXO 的價值，直到該輪次到期。因此，V-UTXO 交易涉及時間價值成本，因為 ASP 需要提供流動性。

具體來說，這個成本在 V-UTXO 被花費時產生。在 V-UTXO 未被花費之前，它代表了一個潛在的可以上鍊的 UTXO，用戶可以單方面提取資金，用戶擁有這些資金的所有權。然而，為了花費 V-UTXO，ASP 必須創建一個新的池 txout，使用從其他來源獲得的資金，而在此期間，已花費的 V-UTXO 中的資金直到到期時間才可供 ASP 使用。

因此，花費 V-UTXO 相當於短期貸款，ASP 需要借入資金來覆蓋從現在到輪次到期之間的時間間隔。這意味著花費 V-UTXO 的流動性成本會隨著 V-UTXO 的老化和到期時間的接近而下降，理論上在輪次到期時流動性成本會降至零。

需要注意的是，花費 V-UTXO 的成本與所花費的 V-UTXO 的總規模有關，而不是支付給接收方的金額。這意味著，專門用於直接交易 V-UTXO 的錢包（與管理一個 V-UTXO 用於其他目的的情況不同，如基於 V-UTXO 的閃電網絡通道）需要在如何將資金拆分為 V-UTXO 上進行權衡。單一 V-UTXO 最小化了單方面提款的成本，但最大化了基於流動性的交易費用；而將資金拆分為多個 V-UTXO 則相反。這與鏈上比特幣或閃電交易的經濟模型完全不同。

流動性成本是多少？

以當前閃電錢包 Phoenix 為例，該錢包為保留 1 年的通道流動性收取 1% 的費用；在最糟糕的情況下，Phoenix 需要將其資金鎖定 1 年。然而，這假設流動性未被使用。實際上，Phoenix 的資金成本可能更高，且假設客戶平均在不到 1 年的時間內使用其預留的流動性。此外，Phoenix 還通過交易手續費賺錢，可能會對通道流動性進行補貼。最後，Phoenix 也可能未實現盈利！

另一個參考值是美國國債利率。當前，3 個月期國債的年利率約為 5%。由於美元的通貨膨脹可能導致該利率被高估，我們可以假設 BTC 計價資金的流動性成本為每年 3%，以此作為分析的基礎。

如果 Ark 的輪次間隔為 4 周，這意味著交易開始時的流動性成本為，並最終逐漸下降至零。假設用戶在輪次到期前兩週將資金轉移至新輪次，那麼用戶大約每年支付 1.5% 的流動性成本來實現對其資金的自主管理。另一方面，如果用戶等到最後一刻才行動，成本幾乎可以降為零，但面臨錯過到期時間的風險。

用戶可能不會認為這是一個微不足道的成本。並且這一成本假設了通過將交易費用和其他成本分攤到大量參與者上，使每輪的固定成本微不足道。

如果固定成本並不小呢？

假設一個 ASP 有 1000 名用戶，平均每小時創建一個池 txout。4 周內，這意味著需要 672 筆鏈上交易。也就是說，ASP 的用戶僅僅為了持有他們的資金，總共需要支付幾乎與用戶數量相同的交易費用。在這種情況下，可能所有用戶自己開設閃電網絡通道會更便宜，儘管 ASP 要求他們等待一個小時的確認時間。

Ark 的啟動難題

對於一個擁有少量用戶的新 ASP 來說，面臨的兩難境地是：要麼 ASP 輪次發生得很少，用戶必須等待很長時間才能彙集足夠的 V-UTXOs 以實現有效的擴展和交易費用降低；要麼 ASP 的池交易發生得很頻繁，但每個用戶支付的交易費用也很高。正如我們在上一部分所示，需要大量用戶來分攤頻繁輪次和池 txout 的費用。

由於輪次會到期，這個問題是持續存在的，甚至比閃電通道面臨的情況更糟糕：至少閃電通道可以無限期地保持有用，允許通道現在開設並在幾個月內逐步攤銷其成本。其次，由於輪次到期，創建支持這些輪次的新 txout 的時間靈活性較小：如果一兩週內費用很高，池 txout 即將到期的用戶別無選擇，只能（集體）支付高額費用來維持他們對資金的託管。而在閃電通道中，用戶可以靈活地選擇何時真正開設通道。

儘管 Ark 的作者最初設想了一個非常樂觀的場景，即每隔幾秒就有新輪次，但在啟動階段，若交易費用沒有補貼，Ark 可能需要等待多個小時才能確認一筆交易的用例才能真正實現。

交互性

非託管的 Ark 是一個高度交互式的協議：由於 V-UTXO 有到期時間，用戶必須在到期前與 ASP 交互，否則 ASP 可能會選擇奪取用戶的資金。這種交互無法外包處理：儘管閃電網絡有瞭望塔（watchtowers）來防止對手方在你離線時試圖欺詐，但 Ark 的持幣者必須使用自己的私鑰在到期前刷新資金，保持對資金的控制。Ark 最接近瞭望塔的機制可能是簽署允許瞭望塔在臨近到期時單方面將資金提取到鏈上的交易，但這會產生顯著的交易費用。

如果 V-UTXO 的所有者離線會發生什麼？在輪次到期後，ASP 需要回收資金以繼續支持後續輪次的流動性。如果 V-UTXO 所有者離線，將 V-UTXO 上鍊會產生高昂的交易成本，因為 ASP 需要在 V-UTXO 樹的多個層次回收資金。雖然 ASP 可以在新輪次中重新創建未花費的 V-UTXO，但這對 V-UTXO 所有者來說並不是無信任的，因為他們無法在沒有從 ASP 獲取數據的情況下花費這些 V-UTXO。此外，ASP 可能會記錄未花費的 V-UTXO 作為託管餘額，甚至可能有沒收資金的政策。

考慮到在 Ark 中自我託管的非小成本，我懷疑許多用戶可能會選擇那些將資金自動轉入新輪次並接受每輪結束時潛在欺詐風險的 ASP。這比用戶主動提早轉移資金以確保在某些情況下（例如他們的手機無法及時打開）資金安全要便宜得多。

先進的 Ark

通過更先進的契約（covenants），有可能減少 Ark 的流動性需求，特別是在輪次期間部分流動性被耗盡的情況下。例如，假設一個輪次的池 txout 中 50% 的 V-UTXO 價值已被花費，如果 ASP 能夠僅兌換該輪次池 txout 的這部分價值，他們可以更快回收流動性，從而降低總體流動性成本。儘管目前還沒有具體的提案來實現這一點，但通過足夠先進的契約技術，這應該是可行的，很可能需要通過某種腳本復興軟分叉，一次性添加許多有用的操作碼。

同樣，通過足夠先進的契約，整個 txout 樹結構可能被某種循環提款方案所取代，從而提供空間節省。這一技術在其他方案中也可能具有潛在的用途，我們將在後續章節中詳細討論。

輪次結束時的託管問題也是一個可以通過先進契約解決的例子：特別是零知識證明（ZK-proof）契約，可以強制 ASP 在下一個輪次中重新創建所有未花費的 V-UTXO，從而避免託管在輪次結束時迴歸到 ASP。雖然這可能無法實現完全的無信任，因為用戶可能仍然需要從 ASP 獲取一些數據才能在新輪次中花費他們的 V-UTXO，但這可以防止 ASP 因離線用戶的欺詐行為獲得經濟利益。

單方面提款中的鏈上費用支付

類似於閃電網絡，鏈上費用支付的經濟學以及扣除費用後的 V-UTXO 實際價值決定了 Ark 使用是否符合我們對 L2 的定義，即通過單方面提款實現資金安全，或防止 ASP 因欺詐獲利。我們將在討論 txout 樹設計模式時進一步探討這一點。

Validity Rollups

Validity Rollups 是一類類似側鏈的設計，通常使用各種零知識（ZK）證明技術來強制執行鏈上的規則。與其他側鏈形式的關鍵區別在於 ZK 證明技術：如果 ZK 證明方案有效，交易的有效性可以通過數學來保證，而無需信任第三方。在這種場景中，“零知識”本身並不是必需的，證明中“洩露”一些信息也沒有問題。只是大多數這種類型的數學證明方案恰好是零知識證明。

從比特幣的角度來看，Validity Rollup 方案需要一個契約（covenant），因為我們希望創建的 UTXO 只能在符合方案規則時被花費。這並不一定是一個去中心化的過程，事實上，許多 Validity Rollup 方案完全是中心化的：rollup 證明只是驗證中心化的交易排序器是否遵循了一定的規則。

關於使用什麼樣的契約，目前零知識證明技術仍然非常新，頻繁有新的進展。因此，極不可能看到比特幣中直接添加任何驗證特定 ZK 證明方案的操作碼。相反，通常認為這些特定方案會通過更通用的操作碼（特別是 OP_CAT）來通過腳本驗證 ZK 證明。例如，StarkWare 正在推動 OP_CAT 的採用。

由於 Validity Rollups 是一個極具潛力的話題，並且有很多項目帶有過多的炒作而實質內容較少，因此我們不會進一步討論這一點，僅指出哪些操作碼可能使這種設計模式可行。

BitVM

粗略地說，BitVM 是一種在兩方之間構建閃電網絡通道的方法，通道的規則通過零知識證明來強制執行。由於它在現有的比特幣上實現時不需要契約，且無法直接用於創建超越“每個用戶一個 UTXO”限制的 Layer 2 系統，我們不會進一步討論它。

分層通道（Hierarchical Channels）

分層通道旨在使通道容量的調整變得快速且廉價：“分層通道在通道容量上做的事情，就像閃電網絡在比特幣上做的一樣”。然而，它仍然無法突破“每個用戶一個 UTXO”的基本限制。此外，它也不需要對比特幣協議做任何修改，因此我們不會進一步討論這一點。其支持者應該繼續實施它們的方案——他們不需要我們的許可。

CoinPool

CoinPool 允許多個用戶共享一個 UTXO、在不同用戶之間轉移資金，並單方面提款。CoinPool 的論文提案要求三個新的軟分叉特性：SIGHASH_ANYPREVOUT、SIGHASH_GROUP（允許簽名僅適用於特定的 UTXO），以及 OP_MerkleSub（用於驗證從 Merkle 樹中移除特定分支）。最後一項功能也可以通過 OP_CAT 實現。

目前，CoinPool 的開發似乎已經停滯，最後一次提交到其規範網站的更新是在兩年前。

Enigma Network

儘管有人要求我們討論 Enigma Network，但該提案似乎缺乏明確的文檔說明。Bitfinex 的博客文章做了很多聲明，而 MIT 頁面卻是空白的。由於博客文章並未清楚地說明其方案的具體內容，因此我們不會進一步討論它。

內存池（Mempool）考慮

當前比特幣 Core 中的內存池策略並不完全適用於 Layer 2 系統。以下我們將討論一些 L2 系統面臨的主要挑戰及潛在的改進方案。

交易釘住（Transaction Pinning）

交易釘住是一種經濟性攻擊，指的是在某些情況下，由於之前廣播的衝突交易未被挖掘，導致期望的交易難以被礦工確認。這是一種經濟性攻擊，因為在真實的交易釘住情境中，存在一筆礦工挖掘後會獲利的交易，但由於釘住交易的存在，該交易無法及時被挖掘。

一個最簡單的交易釘住例子是，在沒有啟用全局替換（full-RBF，replace-by-fee）的情況下，交易替換功能可以被關閉。因此，可以存在一筆低費用率且不被替換的交易，雖然它不會被挖掘，但也無法被替換。基本上，100% 的算力已經通過啟用 full-RBF 解決了這一問題，截至目前，下一版本的比特幣 Core 將默認啟用 full-RBF（這一改進花了 11 年才完成！）。

BIP-125 規則 #3 釘住

目前，剩下的唯一相關且尚未在比特幣 Core 中解決的釘住問題是 BIP-125 規則 #3。BIP-125 規則 #3 規定：

替換交易必須支付更高的絕對費用（而不僅僅是費用率），以替換所有被取代交易的總費用。

這個規則可以被利用來廣播一筆大額、低費用率的釘住交易，花費與多方協議相關的輸出（或者是一組交易）。由於這筆交易的費用率很低，它不會及時被挖掘，甚至可能永遠不會被挖掘。但因為它的總費用很高，用另一筆交易替換它在經濟上並不可行。

解決方案：基於費用率的替換（Replace-by-Fee-Rate）

規則 #3 釘住問題可以通過基於費用率的替換（replace-by-fee-rate, RBFR）相對簡單地解決，該解決方案適用於所有情況。不幸的是，比特幣 Core 是否會在近期採用 RBFR 還不明確，因為開發團隊已經投入了大量精力在一個較差的部分解決方案上，即 TRUC/V3 交易。

通過實現 RBFR，可以更有效地解決多方協議中的交易釘住問題，從而提高 L2 系統的交易靈活性和安全性。

費用支付：RBF、CPFP、SIGHASH_ANYONECANPAY、錨點輸出（Anchors）和贊助支付

由於費用率難以預測，在預簽名交易中可靠且經濟地支付費用變得困難。最理想的費用支付方式是使用 Replace-by-Fee (RBF)，從初始低估的費用開始，然後根據需要用更高費用版本替換交易，直到交易被挖掘。例如，OpenTimestamps 日曆軟件多年來一直以這種方式使用 RBF，而 LND 在 v0.18 中加入了支持截止時間的 RBF 功能。

RBF：費用支付的黃金標準

RBF 是費用支付的黃金標準，因為它在幾乎所有情況下都是最有效的。替換交易不需要額外的輸入或輸出，只要最初正確估算了費用，它的區塊空間使用是最優的。

效率很重要，因為費用支付中的低效操作可能使鏈外費用支付成為大礦工的盈利來源。小型去中心化礦工由於無法從鏈外費用支付中獲利，很難在交易確認中競爭。此外，鏈外費用支付還可能帶來反洗錢（AML）和了解你的客戶（KYC）問題。目前，大多數鏈外費用支付系統都要求某種形式的 AML/KYC 認證（例如 mempool.space 加速器），儘管它接受閃電網絡支付，不需要賬號。

要在預簽名交易中直接使用 RBF，你需要預先簽署覆蓋潛在費用範圍的多個費用變體。雖然在許多情況下，這種變體的數量較少且可行，但目前生產中的閃電協議（以及其他提議的協議）通常選擇使用 Child-Pays-For-Parent (CPFP)，通常通過錨點輸出（anchor outputs）來實現。

錨點輸出與 CPFP

錨點輸出的原理是為交易添加一個或多個最小值或零值的輸出，目的是通過 CPFP 機制在次級交易中花費這些輸出來支付費用。這種方式在像閃電網絡這樣的小型鏈上交易協議中是非常低效的，因為它幾乎使 LN 承諾交易的總大小增加了一倍。然而，對於使用更大交易的協議（例如使用 OP_CAT 實現的契約），這種問題的影響較小。

錨點輸出的另一個問題是需要保留額外的 UTXO 以支付費用。在典型的“客戶端”應用程序中，這可能是一個顯著的負擔，因為沒有錨點輸出時，通常只需要維持一個 UTXO。實際上，一些現有的面向消費者的閃電錢包在高費用環境中，可能會因為無法支付費用而容易被通道另一端的對手方盜取。

SIGHASH_ANYONECANPAY 和 SIGHASH_SINGLE

SIGHASH_ANYONECANPAY 可以在某些情況下用於費用支付，它允許在簽名交易中添加額外的輸入；而 SIGHASH_SINGLE 則允許添加輸出。閃電網絡在 HTLC 交易中使用了這種方式。當前，這種做法可能容易受到交易釘住攻擊的影響，如果處理不當，攻擊者可以通過添加大量輸入或輸出，製造高費用/低費用率的釘住交易。RBFR 可以解決這個問題，而 TRUC/V3 交易中的方法無法解決該問題。這種費用支付方式雖然沒有 RBF 高效，但可以比錨點輸出更高效。

費用贊助系統

最後，已經有各種軟分叉提案提出添加一種費用贊助系統（fee sponsorship）到比特幣協議中。這種系統允許交易聲明對其他交易的依賴，贊助交易（sponsor transaction）只有在受贊助交易（sponsored transaction）被挖掘時才會被挖掘（很可能在同一個區塊中）。這種方式可能比傳統的 CPFP 更高效，因為贊助交易可以用遠少於一個輸入大小的 vbytes 來聲明這種依賴關係。

替換循環攻擊（Replacement Cycling Attack）

替換循環攻擊利用交易替換機制，試圖長時間替換掉一個期望的 Layer 2 交易，最終使一個不期望的交易得以被挖掘。這種攻擊方式與交易釘住（Transaction Pinning）類似，目的是阻止一個誠實交易被挖掘，以便讓一個不誠實的交易得以挖掘。不同的是，替換循環攻擊不能偶然發生，而是攻擊者有意為之。

經典示例：HTLC

一個典型的替換循環攻擊場景是針對 Hashed-Time-Locked-Contract (HTLC)。通常情況下，我們認為 HTLC 是通過揭示預映像（preimage）來花費交易，或通過超時機制進行花費。然而，由於比特幣腳本的限制，HTLC 實際上允許交易始終通過揭示預映像來花費，並且在超時後，交易可以通過超時機制額外地進行花費。

替換循環攻擊利用這一點，在超時後使用預映像替換試圖通過超時機制花費 HTLC 輸出的交易，而受害者並未獲知該預映像。成功的替換循環攻擊可以使這種情況持續足夠長的時間，直到其他通道中的 HTLC 過期。

替換循環的挑戰

要成功實施替換循環攻擊並獲利，面臨的一個主要挑戰是每次替換都會產生費用。一個具有截止時間感知的閃電網絡實現會嘗試支付越來越高的費用，試圖在下一個 HTLC 輸出過期之前花費已過期的 HTLC 輸出。此外，一旦替換週期結束，任何人都可以通過重新廣播被替換的交易來擊敗攻擊。

與交易釘住類似，替換循環攻擊也是一種經濟性攻擊，針對的是礦工。在每次替換週期結束時，存在一筆已從內存池中移除的有效交易，礦工若仍保留這筆交易則可以挖掘並獲利。

軟分叉功能與設計模式

在概述了依賴契約的 L2 系統及內存池挑戰後，我們將總結這些系統所共享的一些重要的軟分叉特性（主要是新操作碼）和設計模式。對於軟分叉提案，我們還將討論部署這些提案時面臨的技術風險和挑戰。

OP_Expire

OP_Expire 被提出作為一種解決替換循環攻擊的簡單方法，通過從源頭解決問題：HTLC 同時可以通過兩種不同的方式花費。在 L2 系統中，任何使用類似 HTLC 機制的場景，以及可能的其他應用場景，都會涉及這個問題。OP_Expire 允許某筆交易輸出在某個時間點之後無法被花費，使得 HTLC 的花費條件變為真正的互斥選擇（exclusive-OR），而不是“程序員的 OR”（允許多個條件同時成立）。

一個實際的 OP_Expire 軟分叉大概由兩個特性組成，類似於 OP_CheckLockTimeVerify 和 OP_CheckSequenceVerify 的雙重結構：

一個交易的到期高度字段，可能會在 Taproot 附件 中實現。
一個 OP_Expire 操作碼，用於檢查到期高度是否至少設定為所需高度。

儘管 OP_Expire 本身幾乎不算是一個契約（covenant），但它對於許多依賴契約的 L2 系統可能會非常有用。不過，它的實用性或許不足以單獨部署，因為替換循環攻擊也可以通過重新廣播交易來緩解。

部署 OP_Expire 的挑戰

一個明顯的挑戰是與 重組（reorgs） 相關：從中本聰開始，比特幣技術社區一直試圖確保比特幣共識協議的設計使得在深度重組之後，之前已被挖掘的交易可以重新被包含在新的區塊中。這一設計原則是為了避免出現大規模已確認的幣突然變得永久無效的情況——在共識失敗導致的大規模重組中，這種情況可能會讓依賴這些幣的人損失慘重。OP_Expire 的使用可能會與這一原則產生衝突，因此部署時需要特別小心。

OP_Expire 與重組（Reorg）

在發生大規模重組的情況下，使用 OP_Expire 的交易可能會因為達到其到期高度而變得無法被挖掘。為此，OP_Expire 提案建議將使用到期交易的輸出類似於 coinbase 交易對待，使其在約 100 個區塊內不可花費，以緩解這個問題。

交易到期 面臨的一個主要障礙是圍繞是否接受這一權衡進行的共識達成，甚至要決定這一機制是否真正必要。使用 OP_Expire 的交易類型已經涉及較長的超時時間，用戶的資金在此期間被凍結，進一步增加超時時間對用戶來說並不理想。此外，雙花（double-spends）一直是重組後使幣失效的另一種方式。隨著 RBF 的更多使用以及 keyless anchor 輸出的提議，交易到期是否會顯著改變現狀仍存在疑問。

SIGHASH_ANYPREVOUT

BIP-118 提出了兩種新的簽名哈希模式，允許簽名不依賴於具體的 UTXO。SIGHASH_ANYPREVOUT 基本上是對 scriptPubKey 的承諾，而 SIGHASH_ANYPREVOUTANYSCRIPT 則允許任何腳本。最初，這個提案是為了支持 LN-Symmetry，以避免對每個可能的通道狀態單獨簽署。

SIGHASH_ANYPREVOUT 還可能在預簽名 RBF 費用率變體中發揮作用，因為簽名不再依賴於特定的交易 ID，這避免了費用率變體的組合爆炸。然而，當前的 BIP-118 提案並未針對這一用例，且可能與其不兼容，因為 SIGHASH_ANYPREVOUT 也承諾了 UTXO 的具體數值。

早期對 SIGHASH_ANYPREVOUT 的反對意見主要來自於錢包可能在不適當的情況下使用它，導致問題。因為一旦發佈了 SIGHASH_ANYPREVOUT 簽名，它可以花費任何帶有相同 script 的 txout。如果意外創建了具有相同 script 的第二個輸出，可能發生重放攻擊。然而，隨著錢包和 Layer 2 實現中其他潛在問題的增多，這一擔憂似乎已經淡化。

目前，技術社區對實施 BIP-118 持相對積極的態度。不過，正如我們在討論 LN-Symmetry 時提到的，關於其主要用例——LN-Symmetry——是否合理，仍存在爭論。

OP_CheckTemplateVerify (CTV)

OP_CheckTemplateVerify (CTV) 是第一個特定於契約的操作碼提案，它的目標是創建一個非常具體、受限的契約操作碼，專注於執行一項功能：以特定方式哈希花費交易，而不承諾輸入的 UTXO，並將結果摘要與堆棧頂部的元素進行比對。這使得可以提前約束花費交易，但不會導致真正的遞歸契約限制。

CTV 的設計非常簡潔，專注於為複雜的 Layer 2 方案提供基礎支持，但避免了引入過多的複雜性。它可能是 Layer 2 系統中更廣泛使用的契約操作碼的基礎之一。

為什麼 CTV 不支持遞歸契約？

OP_CheckTemplateVerify (CTV) 之所以無法支持遞歸契約，是因為它依賴於哈希函數。CTV 檢查的是花費交易與模板哈希的匹配，而沒有辦法創建一個包含自身哈希的 CTV 模板。這意味著 CTV 只能對靜態的模板進行驗證，無法嵌套或者遞歸地進行自我引用。

不過，這未必是一個實際的限制。通過鏈式哈希函數，你可以在現代計算機上在幾秒鐘內生成深度達到數千萬的 CTV 模板哈希鏈。通過使用相對的 nSequence 時間鎖（timelocks） 和比特幣的有限區塊大小，實際要執行完如此長的鏈條可能需要數千年。

CTV 提案的當前狀態

根據 BIP-119 的提案，當前的 CTV 只有一種哈希模式，即 DefaultCheckTemplateVerifyHash，它本質上對花費交易的每個方面都進行承諾。在實際操作中，這意味著在許多情況下，唯一可用的費用支付機制是 Child-Pays-For-Parent (CPFP)。如前所述，CPFP 的一個潛在問題是，當 CTV 交易較小時，鏈外費用支付可能會成為一種非小的成本節省。

儘管如此，CTV 由於其相對簡單性和廣泛的應用場景，得到了技術社區最廣泛的支持。

LNHANCE 提案

有一個提案建議將 CTV 與兩個其他操作碼 OP_CheckSigFromStack(Verify) 和 OP_InternalKey 結合使用。然而，截止目前，與該提案相關的文檔和提案（BIP）尚不足以詳細討論其優點或缺點。這些 BIP 並未提供這些操作碼在實際場景中的使用理由或具體的腳本示例。

因此，雖然該提案的作者可能有很好的理由支持這一想法，但他們需要更清楚地解釋併合理地證明其可行性。因此，我們在這裡不做進一步討論。

OP_TXHASH

類似於 CTV，OP_TXHASH 通過哈希花費交易的數據來實現非遞歸契約功能。然而，與 CTV 不同，TXHASH 提案提供了一個 “字段選擇器” 機制，允許靈活地控制花費交易的具體約束方式。這種靈活性實現了兩個主要目標：

允許向交易添加費用而不會破壞多交易協議。
支持多用戶協議，在這些協議中，用戶只約束自己的輸入和輸出。

OP_TXHASH 的主要問題是字段選擇器機制增加了相當大的複雜性，使得審查和測試相比於更簡單的 CTV 提案更具挑戰性。目前，關於字段選擇器機制的具體好處和使用方式，設計分析還不充分。因此，我們暫時不對其進行進一步討論。

OP_CAT 操作碼

OP_CAT 是一個連接操作符，它將棧頂的兩個元素連接起來，並將結果重新推入棧中。比特幣最初啟用了 OP_CAT，但 中本聰 在 2010 年悄悄地移除了它，可能是因為早期的實現容易受到 拒絕服務（DoS）攻擊 的影響，原因是連接後的腳本元素大小沒有限制。考慮以下腳本：

DUP CAT DUP CAT...

在沒有元素大小限制的情況下，每次 DUP CAT 迭代都會將棧頂元素的大小加倍，最終耗盡所有可用的內存。

OP_CAT 的用途

連接操作對於實現多種契約（covenants）足夠有用，甚至包括遞歸契約。可以通過以下步驟實現：

使用一個或多個 OP_CAT（和任何契約相關的邏輯）將一個部分交易（不含見證數據）組裝到棧中。
驗證棧中的交易是否與花費交易相匹配。

令人驚訝的是，通過濫用 Schnorr 簽名 的數學特性，能夠通過精心構建的簽名使用 OP_CheckSig 來完成第二步。然而，更可能的情況是，OP_CAT 軟分叉會與 OP_CheckSigFromStack 結合使用，從而允許通過驗證棧上的簽名是否為交易的有效簽名來完成第二步，然後重用該簽名通過 OP_CheckSig 驗證花費交易是否匹配。

不需要見證數據

一個關鍵點在於，契約只需要驗證交易的操作——即其輸入和輸出——而不需要驗證實際使其有效的見證數據。因此，交易僅需在不含見證數據的情況下組裝即可。

結合腳本大小限制，OP_CAT 和 OP_CheckSigFromStack 的組合足以構建多種類型的契約，包括遞歸契約。與更高效的解決方案（如 CTV）相比，使用 OP_CAT 的成本更高，但差異比預期的要小。

大致來說，使用 OP_CAT 實現此功能需要將花費交易的非見證部分通過見證數據放入棧中。對於 CTV 的典型用例，如 txout 樹，花費交易不會有見證數據。由於見證空間的折扣為 75%，這將使子交易的有效交易費用只增加約 25%。考慮到其功能性，這並不算差！

OP_CAT 是否過於強大？

OP_CAT 的部署面臨的最大政治和技術障礙之一在於，它的強大能力可能引發許多不可預見的使用場景。一旦 OP_CAT 被啟用，就很難撤銷其影響。其廣泛應用可能會帶來一些無法預測的後果，這些後果可能對比特幣生態系統產生深遠影響。

STARK 驗證的潛力

一個典型的例子是，OP_CAT 被認為足夠支持在比特幣腳本中實現合理高效且安全的 STARK（可擴展透明知識論證）驗證。STARK 能夠證明非常通用的命題，如果能夠高效地在比特幣上實現 STARK，將帶來巨大的影響，超越了 L2 系統的範圍。它將允許在比特幣上構建許多不同的系統。然而，反對 OP_CAT 的一個有力論據是，這些用例整體上可能對比特幣用戶並不利。

MEV 與 MEVil 的風險

礦工可提取價值（MEV） 是另一個關鍵潛在問題，特別是由 Matt Corallo 所稱的“邪惡的 MEV”（MEVil）。簡而言之，MEVil 指的是大型礦工/礦池可以通過採用複雜的交易挖掘策略來提取額外的價值，而不僅僅是最大化總費用。這些策略對小型礦工/礦池來說是不可行的。OP_CAT 帶來的複雜金融工具的潛在使用場景非常廣泛，使得很難排除 MEVil 的風險。

比特幣上已經出現了一些 MEVil 的實例，比如 代幣拍賣協議 造成的中心化風險。幸運的是，通過全局替換（Full-RBF）的採用，這個特定問題得到了緩解。

其他有害的 OP_CAT 用例

除了 MEVil，OP_CAT 還可能帶來其他具體的、有害的使用場景。例如，Drivechains 提案已經在多個場合受到審查，並且被廣泛認為對比特幣有害。相信可以通過 OP_CAT 實現 Drivechain。此外，像 Taproot Assets 這樣的代幣提案也是潛在的風險。儘管一般情況下無法完全阻止它們通過客戶端驗證實現，但有些提案試圖通過 OP_CAT 實現更具吸引力的代幣協議，這不僅可能消耗更多的區塊空間，還可能對合法的比特幣交易形成競爭，導致出價上升。

這些用例還可能帶來法律問題，特別是代幣協議經常被用於金融欺詐。例如，證券型代幣的使用涉及到合規和法律風險，而通過 OP_CAT 實現這些代幣可能使其更容易在比特幣網絡上運行，從而增加了比特幣的法律風險。

增量哈希（Incremental Hashing）

對於契約（covenants），OP_CAT 主要用於連接數據並對其進行哈希。另一種實現相同目標的方法是使用某種 增量哈希操作碼，它通過接收 SHA256 中間狀態（midstate）並繼續對新數據進行哈希計算。SHA256 本身在 64 字節塊上運行，因此有許多不同的設計可能用於增量哈希操作碼。

設計考量

一個重要的設計決策是是否將實際的中間狀態字節以某種標準形式暴露在棧上，或者用一種新的不可見類型表示其中間狀態，從而無法直接操控其字節值。SHA256 的初始化向量（initialization vector, IV）是固定的，尚不清楚允許任意中間狀態或初始化向量是否會影響 SHA256 的密碼學特性。

由於增量哈希可以完成 OP_CAT 所做的事情，只是更加高效，它也面臨著與 OP_CAT 類似的關於功能過強的擔憂。

腳本復興（Script Revival）

OP_CAT 是中本聰禁用的 15 個操作碼之一。除了恢復 OP_CAT，Rusty Russell 提議通過重新啟用大多數被禁用的操作碼，以及增加 DoS 限制，基本上恢復比特幣腳本到“中本聰的初衷”。此外，可能會引入 OP_CheckSigFromStack。

儘管 OP_CAT 本身可以使（遞歸）契約成為可能，但全面的“腳本復興”會使更復雜的契約變得可能，並且更容易實現。例如，可以想象一個契約腳本使用算術操作碼來確保交易輸出的總價值符合某種預期的屬性。

然而，腳本復興引發了與 OP_CAT 類似的關於功能過強的擔憂，甚至更多。

Simplicity

類似於腳本復興，Simplicity 也與 Layer 2 和契約相關，使其幾乎可以實現任何操作。與腳本復興不同，Simplicity 通過引入基於九個基本操作符（組合子）的全新編程語言到比特幣腳本系統。

在實踐中，Simplicity 看似“簡單”，實則並不簡單。它的基本組合子過於低級，連基本操作如加法都需要從頭開始實現，導致原始 Simplicity 代碼極為冗長。因此，實際使用 Simplicity 時會依賴一套代碼替代系統，類似於庫函數調用，稱為 jets。這帶來了實際和政治上的問題：如何決定實現哪些 jets？大多數 jets 可能會像其他操作碼一樣用 C++ 實現，並且每個新 jet 都需要軟分叉。

OP_FancyTreeManipulationStuff

還有一系列相對專門的操作碼被提議用於 樹操作，以更高效地進行依賴契約的 Layer 2 提案。例如，Coinpools 提議了 TAPLEAF_UPDATE_VERIFY 和 OP_MERKLESUB，用於操作 Taproot 樹，MATT 提案則提出了 OP_CheckContractVerify，主要用於驗證 Merkle 樹的某些聲明。

這些提案總體上都是針對特定用例的，它們使某一類 Layer 2 系統成為可能，同時避免了不必要的副作用。它們的優勢在於效率——相對於使用 OP_CAT 這樣的通用操作碼，專用操作碼能使用更少的區塊空間。然而，它們的劣勢在於增加了腳本系統的複雜性，而這些複雜性可能只適用於少數用例。

如果比特幣採用了 Simplicity 腳本系統，同樣的動態也會發生。Simplicity 中操作碼的等價物是為常用模式添加 jet。實現專門操作（如樹操作）的 jets，其優缺點與為特定用例添加複雜操作碼類似。

資金池（Fund Pools）

所有嘗試讓多個用戶共享一個 UTXO 的 Layer 2 系統，都可以被視為某種 多用戶資金池（fund pool），用戶持有某種 提款權。通常，這種系統還會包括一種機制，允許用戶向資金池中添加資金（不僅僅是預分配資金來創建資金池）。

資金池的狀態變化

要使資金池有用，它必須與某種“共享數據狀態”相關聯：txout 的價值如何在用戶之間分配？如果資金池隨著時間的推移而演變，該狀態也必須發生變化，因為資金會被添加或移除。由於我們構建在比特幣之上，向資金池中添加或移除資金必然涉及花費資金池控制的 UTXO。

比特幣的共識系統本質上基於狀態變化的驗證：交易通過見證證明對 UTXO 集合狀態的更改是有效的，工作量證明（PoW）則幫助我們在哪些交易是正確的上達成共識。這意味著，資金池本身也將基於狀態變化的驗證：我們需要向每一個比特幣節點證明，資金池的規則在每次狀態變化時都得到了遵守。

去信任的資金池

另一個信任最小化的 Layer 2 資金池關鍵點是，當資金池的狀態發生變化時，系統必須公開足夠的數據，以便參與資金池的用戶能夠提取他們的資金。如果我們無法做到這一點，系統將無法在沒有第三方合作的情況下提供單方面提款的功能。

許多基於 Rollup 的方案在這裡失效了：它們容易受到 數據可用性問題 的影響，如果第三方協調器下線，用戶將無法恢復其資金，因為他們無法獲得構建有效資金恢復交易所需的數據。

資金池的數據結構

在這些約束下，資金池的數據結構不可避免地是某種樹形結構，具體來說是某種 Merkle 樹。這是因為樹幾乎是計算機科學中唯一可擴展的數據結構，而採用 Merkle 化是進行加密承諾的唯一合理方式。此外，樹的更新必然會發布到比特幣區塊鏈上，因為這是所有 L2 用戶共享的唯一發布媒介，也是我們可以強制用戶發佈以移動資金的唯一媒介。由於契約的實施需要驗證樹的部分，以確保契約規則得到遵守，樹結構顯得尤為重要。

比特幣腳本與交易中的應用

1. 預簽名交易（Individual Pre-Signed Transactions）

這是樹的退化情況，只有一個葉節點。資金池的狀態只能變化一次。例如，標準的閃電網絡通道就屬於這種情況，通道一旦打開，只能關閉。當通道關閉時發佈的數據是交易本身，這足以讓通道中的對手方從區塊鏈數據中獲知交易 ID，並通過花費這筆交易來恢復他們的資金。

此類情況只需要最基本的“契約”：預簽名交易。

2. Txout 樹（Txout Trees）

資金池更復雜的設計模式是 txout 樹，例如 Ark 就是一個典型的例子。在這種情況下，資金池可以通過花費根 UTXO，使用簡單的契約（如預簽名交易或 OP_CheckTemplateVerify（CTV））將該 UTXO 拆分成越來越小的部分，直到葉節點達到可以由合法所有者花費的狀態。

txout 樹的目的是為用戶提供恢復其資金的選項，但這些選項是有代價的：與通過單筆交易拆分 UTXO 並將其返還給所有者相比，txout 樹總是更昂貴。每一層樹結構都增加了創建該層所需的 txout 和 txin 字節成本。

Txout 樹的用例

Ark 是一個很好的例子：我們不希望鏈上的單個 V-UTXO 贖回要求將每個 V-UTXO 都上鍊。通過使用樹結構，贖回可以將樹拆分為更小的部分，直到需要的 V-UTXO 上鍊為止。

類似於預簽名交易的情況，發佈的信息是交易本身，這使得其他用戶的錢包在需要時知道如何花費他們的資金。

Txout 樹 在共享 UTXO 的 L2 系統中提供了有趣的規模經濟。對於包含 n 個 V-UTXO 的資金池來說，將第一個 V-UTXO 上鍊的成本大約是單筆交易成本的 log2(n) 倍，因為需要在鏈上處理 log2(n) 層的拆分交易。然而，一旦第一個 V-UTXO 被上鍊，隨後 V-UTXO 的贖回成本會降低，因為中間交易的費用已經由其他用戶支付。

規模經濟的限制

在理想情況下，整個樹的節點總數為 2n，因此將所有 V-UTXO 上鍊的總成本只會比單筆交易略高一些，展示出令人驚訝的高效性。然而，如果資金池的規模足夠大，可能會對整個區塊空間的總需求產生重大影響。區塊空間是一個供需系統，需求過高時費用將上漲。在極端情況下，可能會創建如此龐大而複雜的 txout 樹，以至於實際上無法將樹中的每一個 V-UTXO 贖回上鍊。

費用支付問題

一個未解的問題是，誰支付費用，以及如何支付？一種明顯的解決方案是使用 無密鑰錨點輸出（keyless anchor outputs）在葉節點交易中，允許想讓葉節點交易上鍊的任何人通過 CPFP（Child Pays for Parent）支付費用。在某些用例中，V-UTXO 本身可以在創建後立即花費，這樣也可以通過 CPFP 機制添加費用。

使用 RBF（Replace-by-Fee）來支付費用比較複雜，尤其是涉及權限管理：顯然的費用來源是 V-UTXO 的價值，但如何確保只有所有者能夠簽署更高費用的交易？在許多情況下，要做到這一點比使用無密鑰錨點輸出更復雜。如果 V-UTXO 本身不能立即花費，這將給用戶錢包的設計帶來嚴重挑戰，尤其是當錢包沒有 UTXO 來執行 CPFP 時。

激勵機制與潛在攻擊

在設計 txout 樹系統時，還需仔細考慮費用支付的激勵機制。例如，在 Ark 類似的系統中，如果某些 V-UTXO 贖回上鍊的成本太高，協調者可能會拒絕離線用戶的鏈下贖回請求，並通過在超時後將所有 V-UTXO 的價值合併為單個 UTXO 來獲利。這樣一種情況會導致該系統無法滿足 L2 系統的基本要求，尤其是對於小額 V-UTXO 的用戶。

基於餘額的方案

相比於簡單的 txout 樹，基於餘額的方案 可以更復雜。它將資金池視為一個不斷變化的餘額，允許添加和移除資金。這需要一個複雜的狀態機，還需要一個共享數據庫，因為目標是讓多個所有者共享一個 UTXO。為了提高擴展性，必須儘量減少將所有權數據寫入鏈上。

這些需求自然會引導我們使用類似 Merkle 樹 的數據結構，例如 Merkle 和樹。操控這種數據結構需要類似 OP_CAT 的操作碼，某種 零知識證明（ZKP） 驗證操作碼，或者專門的樹操作操作碼。

可擴展性的限制

即使使用最先進的數學技術，例如假設我們有一個只需 32 字節的 OP_ZKP 來證明任意命題，我們仍然無法打破 log(n) 級別的擴展性限制。為什麼？即便 ZK 證明可以證明 Merkle 化數據結構的操作遵循 L2 系統規則，它也無法提供下一用戶進行狀態更新所需的數據。這樣，雖然可能有一個用戶能夠實現無條件提款，但其他用戶無法繼續操作。

相比之下，如果通過契約腳本將 Merkle 樹的修改部分（例如 Merkle 樹中的兄弟摘要）發佈，下一用戶將獲得足夠的數據來更新他們對系統狀態的理解，從而也能實現無條件提款。

將 Txout 樹與餘額方案結合

基於餘額的方案和 txout 樹 可以結合使用。如果正在操控的數據結構是 txout 樹，資金可以通過花費輸出並添加新資金的方式加入到 txout 樹中，契約腳本可以驗證資金的確已加入。同樣，資金可以通過 txout 樹的常規機制移除。高級 Ark 就是這種結合方案的一個例子。

故障數據率

L2通過在對抗性場景中增加交互性要求來實現擴展。在幾乎所有情況下，這意味著協議中的誠實方需要在截止日期之前將交易上鍊；如果未能在截止日期前完成，資金可能會被盜。
所有去中心化（和中心化）區塊鏈的最大區塊容量都受到技術限制。在比特幣中，最大區塊大小使得比特幣幾乎始終在接近100%的容量下運行。由於比特幣挖礦是通過競拍系統進行的，將區塊空間拍賣給出價最高的人，因此實際上，隨著需求的增加和減少，最低交易費率也隨之上下波動。

費用率始終是L2經濟和故障模式的一個重要因素。例如，在閃電網絡中，“dust-sized”（塵埃大小的）HTLCs（哈希時間鎖合約）由於金額過小，無法通過鏈上贖回盈利，因此使用了與較大HTLC不同的安全模型。雖然閃電網絡協議尚未正確實現這一點，但理論上，這一閾值應根據費用率的波動動態調整，理想情況下，應該允許一方根據費用率的高低決定HTLC是否在給定的承諾交易中存在。

已有多種攻擊方案被提出，旨在通過故意觸發這種情況攻擊閃電網絡，比如“洪水與掠奪”攻擊和“大規模退出攻擊”。由於比特幣區塊鏈的容量是所有使用場景共享的，不同L2系統之間的攻擊也是可能的：例如，通過在Ark中觸發大規模退出從閃電通道中獲利。
共享UTXO（未花費交易輸出）的L2由於多個用戶共享，因此在故障期間對區塊空間的最壞需求可能會更高。截至撰寫本文時，尚未在閃電網絡中看到大規模的故障，即大量通道需要同時關閉的情況。有人認為，在進一步推動UTXO共享方案之前，應該首先通過閃電網絡的每用戶1個UTXO擴展方式獲得更多的實際操作經驗。

其次，在廣泛採用新的UTXO共享方案之前，應對區塊空間高需求期間攻擊的潛在盈利性進行仔細研究。例如，在像Ark這樣的系統中，ASP（應用服務提供商）可以使用比其他方更少的區塊空間贖回資金，因此有可能故意觸發高費率並抓取那些無法通過單方面贖回而盈利的資金，這種情況可能是一種盈利性欺詐，違反了我們對真正L2系統的要求。

共識清理

中本聰在最初的比特幣協議中做錯了很多事情，特別是腳本的DoS攻擊、時間扭曲攻擊以及Merkle樹的問題。此前，已經通過軟分叉修復了其他一些共識漏洞，例如評估基於時間的nLockTime時切換為與過去中位時間對比、（試圖）修復重複txid問題等。

最近的一次軟分叉——Taproot的部署過程相對具有爭議，實際部署花費了很長時間。主張首先進行一次共識清理軟分叉的論點是，在啟用任何新操作碼或L2新特性之前，我們可以瞭解更廣泛的社區在實施這種相對無爭議、對所有人都有利的軟分叉時的意願。

潛在的軟分叉

未來的路徑是什麼？在這裡，我們將列出所有主要的第二層方案（L2）以及為使這些L2方案成功而有用（U）或必要（R）的軟分叉。如上所述，OP_CAT（以及其擴展功能，包括OP_CAT的Script Revival）可以模擬列表中所有其他軟分叉——除了OP_Expire和Fee Sponsorship。因此，當某個項目的需求更有效地通過其他軟分叉直接滿足時，我們將不再包括OP_CAT。

我們還將忽略所有提議的默克爾樹操作碼。這些操作碼都過於小眾、特定於用例，在目前的情況下，它們被廣泛採用的可能性不大。在這些操作碼有用的情況下，通過OP_CAT和/或Script Revival實現它們的效果更有可能被採納。

CTV（CheckTemplateVerify）是這裡的明顯贏家，其次是SIGHASH_ANYPREVOUT（OP_Expire通過提供替代循環修復對很多項目有用，但並非必需）。CTV獲勝的原因是，許多事情都可以符合“確保支付交易與此模板匹配”的設計模式；即使是OP_CAT構造也可以高效地利用CTV。

與OP_CAT不同，CTV似乎不會帶來超出某些情況下鼓勵帶外支付費用的意外後果。這並不理想，但目前還沒有人提出一個廣泛支持的替代方案。

我個人的建議是：首先進行一次共識清理軟分叉，然後實施CTV。