作者：Peter Todd
來源：https://petertodd.org/2024/covenant-dependent-layer-2-review
鏈上錢包實現了從交易到交易的（大致上）一一映射：對於用戶要執行的一筆 經濟 的交易，大致上需要一筆 區塊鏈 交易。交易的聚合、coinjoin、cut-through，等等技術，都稍稍偏離了一點點，但大體上，我們這個說法還是對的。
閃電通道則實現了一種 多對一 映射：閃電通道的魔法就在於，實質上不限量的經濟交易可以在一條通道內發生，而通道自身綁定在一個未花費的交易輸出（UTXO）中。本質上，我們抓住了 “時間” 維度 —— 交易 —— 並通過讓這個維度塌縮實現了顯著的擴容。
但是，讓每個用戶創建一個 UTXO 是不夠好的（至少可以爭議）。所以，出現了許多提議，嘗試讓多個用戶可以自主保管地共享一個 UTXO 來實現更大的擴容效果。這一次，塌縮的是 “空間” 維度 —— 用戶 —— 化為一個 UTXO。
我在這裡的目標是審核所有這些提議，找出它們共有的技術模式，找出它們所需的新的操作碼類型或軟分叉升級，然後建立一個綜合性的表格，將所有方案都放入表格中。在這個過程中，我們也會定義什麼是 “Layer 2 協議”、閃電網絡已經能夠實現何種擴容，並理解要實現這些提議，我們需要對交易池（mempool）作那些升級。
感謝 Fulgur Ventures 資助這項研究。他們對本文的內容沒有編輯權限，在正式出版之前也沒有審核過。
感謝 Daniela Brozzoni、Sarah Cox 等人在出版前的審核。
1 定義
1.1 什麼是 “Layer 2”？
通常人們會給 “Layer 2” 採用寬泛的定義，以至於連銀行一樣的實體（例如 Liquid）也可以被定義成 Layer 2。出於本文的目的，我們會採用一種更狹窄的定義：Layer 2 是一種以比特幣為主導（Bitcoin-denominated）系統，其存在目的是允許 BTC 以高於鏈上交易的頻率在相關人之間轉移，並且：
- 考慮了 系統內 的懲罰和代價之後，沒人能從系統中偷盜資金而獲利。系統外的成本和懲罰，比如聲譽損失、法律後果，等等，在我們的定義中是 不考慮的。
- （優先）資金的真正所有者可以單方面取出自己的資金（減去交易手續費），而無需任何第三方的合作。
第一項是有必要的，因為我們希望我們的 L2 系統可以表示價值很小、小到無法在鏈上表示的數額和交易。舉個例子，在閃電通道中，HTLC 可以有小到無法在鏈上表示的面額。在這種情況下，HTLC 的價值會被加到承諾交易的交易手續費中。雖然閃電節點可以有針對地關閉通道來 “盜取” 一個粉塵 HTLC，但這樣做是非常昂貴的 [1]，代價超過 HTLC 本身的價值，所以盜竊是無利可圖的。
第二項則是說，單方面取款總是我們的首要設計目標 [2]。
在這個定義下，閃電通道會被認為是一種 L2 系統。但是，像 Liquid、Cashu、和 Fedemint 這樣的系統，則 不是 L2，因為是另一方（或幾方）控制著你的資金。“客戶端驗證（client-side validation）” 方案（比如 RGB）也不是 這個定義下的 L2，因為它們是無法免信任地轉移 BTC 本身的。最後，“Statechains”也不符合這個定義（中文譯本），因為如果 Statechain 實體（服務商）有意不遵守協議，就可以偷盜資金。
1.2 什麼是 “限制條款”？
……那麼，為什麼 L2 系統需要限制條款來實現更強的可擴展性呢？
在比特幣的腳本編程中，“限制條款” 指的是一種機制，可以提前限制一個交易輸出（txout）被花費的方式，從而花費這個 txout 的交易的形式是預先定義好的，或者，以一種不完全取決於電子簽名的方式來限制它的花費。在多個參與者之間共享 UTXO 的 L2 系統需要限制條款，因為它們需要限制 UTXO 的花費方式，以實現 L2 協議的規則和激勵因素。
1.2.1 遞歸型限制條款
遞歸型限制條款是具有這樣的屬性的限制條款：限制一個 UTXO 花費方式的規則可以遞歸地應用，無限地延伸到花費交易的子 UTXO 中。遞歸型限制條款長期被一些人認為是不可取的，因為它們可能導致資金被永遠拘限。或者，至少，在沒有第三方（比如政府）的許可時就會永遠受困。
2 目標
閃電通道是目前 Layer 2 系統中的 “翹楚”。但它也有侷限性，即：
- 可擴展性 —— 閃電通道目前要求每個終端用戶至少要有一個 UTXO [3]。
- 流動性 —— 閃電通道要資金被綁定在通道中。
- 交互式 —— 閃電通道要求支付的接收者在線，以免信任地收取支付。
在評估 Layer 2 系統時，我們的目標是能夠在這些關鍵的侷限性上有所提升，最好是不會引入新的侷限性。
2.1 閃電通道的可擴展性限制
在真實場景中，“每個終端用戶需要一個 UTXO” 意味著什麼？因為閃電通道可以無限期運行，分析它的一種辦法是搞清楚每年可以創建多少條新的通道 [4]？創建一個 taproot 輸出的邊際成本是 $43vB$；如果通道的創建可以平攤，也就是許多通道可以在一筆交易中開啟，那麼其它的交易開銷就會變得微不足道，並且每年都可以新開相當多的通道來容納新的用戶。 舉個例子，假設 90% 的區塊空間都被用來開啟新的 taproot 閃電通道：
$$
52{\small,}560\frac{\mathrm{blocks}}{\mathrm{year}} \times 1{\small,}000{\small,}000\frac{\mathrm{vB}}{\mathrm{block}} \times 90% \times 1\frac{\mathrm{channel}}{43\mathrm{vB}} = 1.1,\mathrm{billion}\frac{\mathrm{channels}}{\mathrm{year}}
$$
（結果是每年可以開啟 11 億條新通道）
預估全世界有一半人口擁有智能手機，也就是 43 億人。所以事實上，每年我們都可以引導有可能用得上閃電網絡的人群中的一大比例進入閃電網絡。
然而，通道不會永遠不關閉。有些時候，用戶想要切換錢包、增加或減少通道的容量，等等。改變通道容量最高效的辦法就是 “通道拼接”，尤其是 Phoenix Wallet 的實現。
就像通道的開啟，通道拼接也可以平攤，以提高效率：多個拼接操作可以共享一筆交易，以減少為添加和移除資金而需要的輸入和輸出的數量 [5]。因此，每個用戶的拼接操作所需的增量區塊空間，假設用戶使用 musig，是 $43vB$ 的 taproot 輸出加上 $57.5vB$ taproot 密鑰路徑花費的見證數據，總計是 $100.5vB$。如果我們再一次假設 90% 的區塊空間都被用於這個用途，那麼是：
$$
52{\small,}560\frac{\mathrm{blocks}}{\mathrm{year}} \times 1{\small,}000{\small,}000\frac{\mathrm{vB}}{\mathrm{block}} \times 90% \times 1\frac{\mathrm{splice}}{100.5\mathrm{vB}} = 470,\mathrm{million}\frac{\mathrm{splices}}{\mathrm{year}}
$$
（結果是每年可執行 4.7 億次通道拼接）
最後，注意，在錢包之間切換閃電通道是可以在一筆交易中完成的，要麼是信任新錢包，在資金已經被髮到承諾地址後再簽名一筆承諾交易；要麼是在新舊兩個錢包實現中支持合作式 “關閉又開啟新通道”。
當然，在閃電通道之外，會有別的比特幣應用場景來爭奪區塊空間，而且很難知道這會怎樣轉化為手續費率。但這些數字給了我們一個粗糙的估計，說明以當前的技術，至少在技術上，是可能做到支持數億自主保管的閃電網絡用戶的。
3 L2 綜述
在我們的 L2 定義下，比特幣開發者社區一直在討論的設計模式有兩個：
- 通道
- 虛擬 UTXO
在通道模式中，閃電通道是一個主要的例子，狀態的推進是通過參與者交換預先簽名的、可以 被挖出（但不代表 “皆大歡喜” 結局）的交易來實現的。這些預先簽名的交易會在參與者之間分割一個 UTXO 的價值；經濟往來是通過反覆使用新的預簽名交易改變分割的結果來實現的。因為會有許多有效交易在花費同一個 UTXO，就需要一些激勵機制來保證只有正確的交易會真正得到區塊確認。
而在 “虛擬 UTXO（V-UTXO）” 設計模式中，Ark 是最顯著的例子，V-UTXO 是通過限制條款或多方的約定創造出來的；表示價值的交易 可以 被挖出，從而將各方的 V-UTXO 在鏈上變成真正的 UTXO，但這樣的交易也不代表 “皆大歡喜” 結局。從這個角度看，V-UTXO 也類似於通道。但與通道不同的是，V-UTXO 方案是通過花費 V-UTXO 自身來實現交易的，（概念上）是是用單筆 [6] 預先簽名的交易。
而 “皆大歡喜” 設計模式是使用 “所有參與者都同意” 的腳本路徑，例如一個 N-of-N 的多簽名裝置；taproot 是專門為這個概念而設計的，允許密鑰路徑（通過 musig）成為一個 N-of-N 的多簽名裝置。假設所有參與者都同意，這一路徑會允許資金被高效（且私密）地花費。
有趣的是，因為虛擬 UTXO 在許多方面是 “真實的”，在虛擬 UTXO 上建立通道是非常容易的，只需讓虛擬 UTXO 在被挖出時會導致通道所需的 UTXO 被創建即可。在這個意義上，虛擬 UTXO 比通道稍微低層一些。
3.1 閃電網絡
截至目前為止，在生成環境中實現的閃電網絡，主要基於 BOLT 標準。閃電網絡是一系列技術的組合，包括閃電通道和 HTLC、P2P 路由網絡、洋蔥路由、發票標準，等等。重要的是，閃電網絡 不是 一個公示系統，所以 “閃電系統” 的不同模塊不需要被所有用戶以完全相同的方式採用。出於本文的目的，在我們說 “閃電網絡” 的時候，我們採取廣義，包括對現有的（典型的）、已被廣泛使用的閃電網絡協議（們）的易於預見的升級。
如前所述，閃電網絡的關鍵特徵是終端用戶的可擴展性限制，來自於每個用戶都需要至少一個 UTXO 的要求。也就是說，對於閃電網絡的 “核心” 路由模塊來說 —— 公開的、轉發大量交易的閃電節點 —— 這些可擴展性限制並不是很大的困擾，因為只要終端用戶的數量比路由節點多得多，閃電網絡就能良好運作，每一條公開的、用戶支付轉發的通道都可以瞬時地輕鬆處理大量交易。這也是為什麼許多新提出的 L2 系統都被期望能夠參與閃電網絡。我們也可以觀察到，現有的、並不那麼符合 L2 標準的系統，比如 Cashu，要重度依賴於閃電網絡，才能真正變得有用：Cashu 的主要用法可能就是發送和收取閃電支付。
3.1.1 非交互式通道
這種構造通過使用 OP_CTV 來減少交互需求、優化閃電通道。不過，它並不能優化 “每個用戶一個 UTXO” 的可擴展性限制，所以我們不會進一步討論它。
3.2 通道工廠
在這種構造中，我們可以讓多方協調進入一個 n-of-n 的多簽名地址，與之匹配的一筆預簽名交易會花費這個多簽名地址、創造出 n個不同的 UTXO 來分割資金。而這 n 個 UTXO 分別都會用作一個支付通道。這些通道的安全性跟直接在鏈上開啟是相同的，因為在需要將通道狀態發佈到鏈上的時候，分割資金的交易可以被挖出。這可能可以節約鏈上的空間，因為當通道關閉的時候，因為 —— 理論上 —— $n$ 個參與者可以合作一次性關閉所有 $n$ 條通道。
因為通道工廠是協調型 UTXO，是 可以 被挖出的，但在愉快結局中並不被期望要實際挖出，所以它是 V-UTXO 的一個 非常 原始的例子。
通道工廠的實現並不要求任何軟分叉。但是，上面所述的簡單的通道工廠可能在參與者稍微多一些之後就會變得不實用，因為需要用戶的協作才能真正實現擴容的好處。因此，OP_Evict 或者 CTV（通過 txout 樹）這樣的限制條款提議可能會帶來幫助，它們允許發佈更細粒度的結果 —— 單方可被彈出到鏈上，而無需強迫所有人都同時出現在鏈上。
3.3 Eltoo/LN-Symmetry
因為 Eltto 是一個糟糕的容易引起混淆的名字，我們在下文中只使用更新後的名稱 “LN-Symmetry”。
Poon-Dryja 通道懲罰發佈不正確的狀態的行為來激勵發佈正確的狀態，LN-Symmetry 則反其道而行之，允許不正確的狀態用額外一筆交易來更新。它的好處是通過移除懲罰的複雜性簡化了閃電通道。不過，在不可信任的環境中，它可能也會有不利之處，因為可以說為了遏制其中，懲罰是有必要的。
LN-Symmetry 需要一個軟分叉來啟用 SIGHASH_ANYPREVOUT，以允許新的狀態交易可以重複花費舊的狀態交易。
就其自身而言，LN-Symmetry 並不能為傳統的閃電通道帶來擴展性能提升。但其支持者們主張它會讓通道工廠更容易實現。
3.4 Ark
Ark 採用了新的方法來實現交易擴容：完全可轉移的虛擬 UTXO（V-UTXO），這些虛擬 UTXO 可以在原子化的 [7] 鏈下交易中合併及分割。在 Ark 中，一箇中心協調者 “Ark 服務商（ASP）” 給用戶提供定義好時限（比如 4 周）的 V-UTXO。這些週期叫做 “輪次”。這些 V-UTXO 是通過資金池交易輸出創造出來的，每一輪會創造一次，通過某種機制（比如 CTV）來讓單個鏈上交易輸出能夠承諾一棵 V-UTXO 的樹。輪次的過期機制是 Ark 實現可擴展性好處的關鍵：在一輪的末期，資金池交易的輸出會解鎖，允許 ASP 單方面在一筆小體積的交易中用一個簽名來花費它。因為輪次有過期時間，被資金池交易輸出創建出來的 V-UTXO 也就有了過期時間：持有 V-UTXO 的用戶必須要麼在相應池交易輸出過期之前花掉這個 V-UTXO，要麼將它發佈到鏈上（單方面取款）。
為了轉移 V-UTXO，Ark 協調者要一同簽名花費一個或多個 V-UTXO 的交易，並讓交易僅在 另一個 輪次中創造出一個或更多其它 V-UTXO 時才會生效。結合一些精心設計的超時機制 —— 完整的細節要看 Ark 的文檔 —— 這一依賴就是讓 V-UTXO 的花費變得免信任的地方：除非新的 V-UTXO 在另一個池交易中創造出來，舊的 V-UTXO 就無法在鏈上（隨著池交易輸出被花費而一併）取走。有一些辦法可以實現這種依賴。但確切的細節跟本文的目的不相關。
注意，這意味著一個 ASP 將同時操作多個活躍中的輪次。新的輪次會被頻繁創建，以允許現有輪次中的資金被轉移。但現有的輪次會跟新的輪次重疊，因為它們一般會在新的輪次（新的池交易）創建之後過期。
3.4.1 Ark 的經濟模型
在一個 V-UTXO 被花費掉的時候，ASP 必須在一個表示新輪次的池交易輸出中提供匹配的 BTC。但是，在當前的輪次結束之前，他們是無法動用被花費 V-UTXO 的價值的。因此，V-UTXO 的花費有一個成本：貨幣的時間價值，這是因為 ASP 必須墊付資金。
確切地說，這個代價是在 V-UTXO 被 花費 的時候才產生的。在 V-UTXO 沒有被花費的時候，它代表著一個非常真實的、可以被髮布到鏈上以單方面取出資金的潛在 UTXO；用戶自己控制著自己的資金。然而，為了花費這個 V-UTXO，ASP 必須創造一個 新的 池交易輸出，用的是 ASP 從別處獲得的資金，而被花費的 V-UTXO 中的資金，在其輪次到期之前，是不能為這個 ASP 所用的。
因此，花費一個 V-UTXO 需要一個短期的貸款，以覆蓋從現在到輪次過期的這段時間。意思是，隨著 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 還有可能不賺錢！
美國的國債（US Treasury Bill）收益率可以給我們另一個估計。在本文撰寫之時，3 月期的國債收益率大概是年化 5% 。因為美元的通脹會使這個收益率有水分，出於分析的目的，我們就假設以 BTC 為本位的資金的流動性成本是年化 3%。
如果一輪長 4 周，那麼交易的流動性成本會從 $3% / \frac{52}{4} = 0.23%$ 開始，逐步降低到 0 。假設用戶在當前輪過期的兩週之前移動資金，為實現資金的自主保管而需支付的流動性成本大約是年化 1.5% 。另一方面，如果用戶一直等待到最後一刻 [8]，這個流動性成本將接近於零，風險是錯過到期時間。
用戶可能不會認為這代價很便宜。而且，這個代價假設了每一輪的成本都是固定的，並且已經通過大量參與者來攤銷交易手續費和其它代價，使它們都已經變得微不足道。
但如果這個固定成本並不小呢？假設一個 ASP 有1000 個用戶，平均一個小時創建一筆池交易。在 4 周時間裡，就會有 672 筆鏈上交易。這意味著，只是為了保管自己的資金，這個 ASP 的用戶整體上就必須為幾乎跟用戶數量一樣多的交易支付手續費！對他們來說，如果都跑去開啟自己的閃電通道，可能還會更便宜，而且 ASP 還會讓他們等待一個小時來確認交易。
3.4.2 冷啟動 Ark
一個只有少數用戶的新 ASP 會面臨一個困局：要麼 ASP 的輪次不那麼頻繁地發生，從而用戶需要等待很長時間才能等到相應的輪次收集到足夠多的 V-UTXO 來實現有用的可擴展性喝交易手續費減免；要麼，ASP 的池交易發生得很頻繁，然後每個用戶都要支付較高的交易手續費。如我們在上一節討論的，它可能需要大量的用戶來攤銷頻繁發生的輪次以及相應的池交易。
由於存在過期時間，這個問題會變得更加嚴重，甚至比閃電通道要面臨的更嚴重：至少一條閃電通道可以無限期有用，在一條通道開啟之後，它可以在接下來幾個月裡逐步攤銷。其次，因為輪次會過期，在創建支持這些輪次的交易輸出的 時機 選擇上，不夠靈活：如果高手續費的情形持續一週或兩週，即將過期的池交易輸出的用戶就別無選擇，只有（集體）支付高手續費率來維持資金的保管。而在閃電通道中，開啟通道的時機選擇會靈活得多。
雖然 Ark 的作者一開始想得非常樂觀，認為只需幾秒就可以創建新的一輪，但是，如果交易費無法得到補貼，Ark 的初次啟動也許只能發生在可以等待幾個小時來確認交易的應用場景中。
3.4.3 交互性
非託管的 Akr 是一種高交互需求的協議：因為你的 V-UTXO 會過期，你需要在過期之前跟 ASP 交互，不然，ASP 可以取走你的資金。這種交互需求也是無法外包的：相比之下，閃電通道有 “瞭望塔”，可以遏制你的對手嘗試欺詐你 —— 即使你的節點離線了，而 Ark V-UTXO 的持有者為了免信任，必須使用自己的私鑰來刷新資金。在 Ark 中，與瞭望塔最接近的東西是簽名交易以允許瞭望塔在到期之前代你單方面取回資金，而這會有高昂的交易費成本。
考慮一下，要是資金所有者離線，它的 V-UTXO 會發生什麼事：在輪次過期之後，ASP 需要回收資金，以應對未來輪次的流動性需要。如果一個 V-UTXO 的持有者離線，將 V-UTXO 發佈到鏈上將面臨高昂的交易代價，因為 ASP 需要取出多層的 V-UTXO 樹上的資金。ASP 可以在一個新的輪次中重新創建出未花費的 V-UTXO，但是，從 V-UTXO 持有者的角度看，這不是免信任的，因為他們將無法在缺乏來自 ASP 的數據 [9] 的前提下花費這些 V-UTXO。ASP 也可以直接將未花費的 V-UTXO 記錄成託管的餘額。甚至可以有沒收資金的條款！
我個人的看法是，考慮到 Ark 中自主保管的代價並不便宜，許多用戶會轉而選擇可以自動滾動資金到新輪次中的 ASP、直接接受每一輪的末尾都可能出現欺詐的風險。這比預防性轉移資金以保證資金安全（例如，不會因為沒有及時打開手機、控制錢包轉移資金）要更便宜。
3.4.4 更高級的 Ark
使用更高級的限制條款來減少 Ark 的流動性需求，也許是可信的，如果典型的情形是流動性會在一輪中全部用完的話。舉個例子，我們假設一個交易池輸出中所有 V-UTXO 總價值的 50% 會被花掉。如果 ASP 可以僅回收交易池輸出的一部分的話，他們就可以更快地回收資金、降低整體的流動性成本。雖然現在還沒有公開出現這樣的具體提議，似乎只要有 充分高級TM 限制條款，是可以做到的。最有可能的是通過某種 “腳本復活（Script Revival）”軟分叉，一次性添加多個有用的操作碼。
類似地，通過這樣的 充分高級TM 限制條款，完整的交易輸出樹結構可以被替換成具有某種滾動取款方案，從而節約空間。我們會在下一個章節中討論這個話題，因為這種技術可能對其它方案也有用。
輪次結束時候的保管問題是 充分高級TM 限制條款 可以解決的另一個問題：一種限制條款，尤其是一種可以驗證零知識證據（ZK-proof）限制條款，可以強制 ASP 在下一輪中重新創建所有未花費的限制條款，消除在一輪結束時監護權被交給 ASP 的問題。雖然可能這也不足以讓它成為 免信任的，因為用戶可能依然需要來自 ASP 的一些數據來花費自己在新輪次中的 V-UTXO，這可以防止 ASP 從對離線用戶的欺詐中獲得好處。
3.4.5 單方面取款時候的鏈上手續費支付
類似於閃電通道，鏈上手續費率支付的經濟原理和一個 V-UTXO 在支付完手續費後的實際價值，決定了 Ark 的用法是否符合我們的 L2 定義（可以單方面退出，不會讓 ASP 從欺詐中獲利）。我們會在下文討論交易輸出樹設計模式時進一步討論。
3.5 Validity Rollups
一個類似於側鏈構造的大類，普遍被提議使用某種形式的零知識證明技術來強制執行規則。這樣的零知識證明技術是 “有效性 rollup（validity rollup）” 跟其它形式的側鏈的關鍵區別：如果相關的零知識證明方案能夠工作，交易的有效性將由數學來保證，而不需要信任一個第三方。在這個用法中，零知識證明的 “零知識” 特性並不是必要的：即使證據 “洩露”了它要證明的東西的信息，也是完全沒問題的。只是碰巧這類數學方案中的絕大部分都恰好是零知識證明方案。
從比特幣的角度，有效性 rollup 方案需要一種限制條款，因為我們希望能夠為這樣的方案創建出一種 UTXO，僅在方案的規則得到遵守時才能被花費。這也並不 必然 是一種去中心化的系統。許多有效性 rollup 方案實際上完全是中心化的；rollup 證據僅用來證明一箇中心化的交易排序者為一組排序好的交易應用了規則。
至於要用什麼限制條款 …… 零知識證明技術依然是一個非常新的領域，經常有進展出現。所以，我們極不可能看到任何直接驗證某一種零知識證據的操作碼被添加到比特幣中。相反，普遍接受的事情是具體的方案會用更通用的操作碼（尤其是 OP_CAT）以在腳本中驗證零知識證據。舉個例子，StarkWare 正在爭取讓 OP_CAT 能被採用。
有效性 rollup 是一個非常大的領域，有許多的 低質量/高炒作 的項目。除了指出可能需要什麼操作碼來讓這一類設計變得可行之外，我們不會進一步討論。
3.6 BitVM
非常粗糙地說，BitVM 是一種在兩個參與者之間構造一條閃電通道、讓閃電通道的規則能夠用一種零知識證據來強制執行的方法。因為它不需要限制條款就能在當今的比特幣上實現，而且它無法直接用來創建可擴展性強於 “每個用戶要有 1 個 UTXO” 的 L2 系統，我們不會進一步討論。
3.7 層級式通道
層級式通道 [10] 致力於讓通道的容量調整（resizing）更快更便宜：“層級式通道之於通道容量，如果閃電通道之於比特幣。”然而，在根本上，它依然不能超越 “每個用戶要有 1 個 UTXO” 的限制。它也不要求對比特幣協議的任何變更。所以我們我們也不會進一步討論。層級式通道的支持者們應該直接實現它！這不需要我們的許可。
3.8 CoinPool
Coinpool 讓多個用戶可以共享一個 UTXO、在用戶之間轉移資金，並且用戶都可以單方面取款。CoinPool 的書面提議需要三種新的軟分叉特性：SIGHASH_ANYPREVOUT、SIGHASH_GROUP 以允許一個簽名僅能應用到某一個 UTXO 上，以及 OP_MerkleSub 以驗證某一個分支從一棵默克爾樹上移除了；後者也可以用 OP_CAT 來實現。
目前，CoinPool 的開發似乎有些停滯，表述其規範的網頁的最後一次更新是兩年前的了。
3.9 Enigma Network
雖然我被請求討論 Enigma Network，似乎沒有文檔能說明這個提議真正的樣貌。Bitfinex 的博客文章提出了一系列口號；而 MIT 的頁面是空白的。因為這篇博客文章並沒有真的說清楚它的實際構造，我們不再進一步討論。
4 交易池的考慮
Bitcoin Core 當前的交易池策略對 L2 系統來說是不理想的。在這裡，我們會介紹它所面臨的一些重大挑戰，以及可能的優化。
4.1 交易釘死
最終來說是一種經濟上的爆破。“交易釘死攻擊”，指的是多種情形，一些人可以有意（或無意）讓一筆目標交易變得難以挖出，因為另一筆與之衝突的交易被搶先廣播並且也 沒有 挖出。這是一種經濟上的爆破，是因為在一個真正的交易釘死場景中，目標交易是礦工一旦挖出就能得到好處的；而相沖突的交易在很長時間（可能是永久）裡 沒有 被挖出。
釘死攻擊的最簡單例子來自一個事實：沒有 “full-RBF”（即節點默認所有交易都是可被替換的），交易替換特性可以被關閉。然後，我們可以發起一筆低手續費率、關閉了替換特性的交易，那麼它既不會被挖出，也無法被替換。基本上，所有的出塊者都開啟了 full-RBF，從而解決了這個問題；並且，截至本文撰寫之時，在下一版本的 Bitcoin Core 中，full-RBF 應該會默認開啟了（在努力了 11 年之後！）。
這讓 BIP-125 規則 #3 相關的釘死攻擊，變成了剩餘唯一跟多方 L2 協議有關（且在 Bitcoin Core 還沒有得到解決）的釘死攻擊。此處引用 BIP-125 規則 #3：
替代交易需要支付更高的手續費絕對值（而不僅僅是手續費率）；要高出所有被替換的交易所支付的手續費總和。
這一規則是可以被利用的：可以廣播一筆（或者一組）大體積但低手續費率的釘死交易、花費跟多方協議相關的輸出。因為交易的手續費率很低，它就不會很快被挖出（可能永遠不會）。然而，因為它的手續費總和較高，用另一筆交易來替換它是不經濟的。
BIP-125 規則 #3 相關的釘死攻擊在 “手續費率替換（RBFR）” 中是很容易解決的，而且在所有情形中都可以解決。遺憾的是，尚不清楚 RBFR 會不會很快被 Bitcoin Core 採用，因為他們在一種較差的不完整解決方案 “TRUC/V3 交易” 中花了大量時間（中文譯本）。
4.2 手續費支付方法
RBF、CPFP、SIGHASH_ANYONECANPAY、錨點輸出和手續費資助
因為手續費率是無法預測的，可靠而又經濟的手續費，在交易被預簽名的情形中，是非常難做到的。手續費支付的黃金標準是使用 RBF（手續費替換），從一個 “低估” 數值開始，逐步替代以更高手續費的版本，直到交易被挖出。舉個例子，OpenTimestamps 日曆軟件已經用這種辦法很多年了，而且 LND 也在 v0.18 中支持了 “考慮終止期限的 RBF”。
RBF 之所以是黃金標準，因為它在幾乎所有 [11] 場景中，都是最節約區塊空間的：相對於一開始就猜對了正確的手續費的交易而言，替代交易並不需要額外的輸入或輸出。
效率是重要的，因為手續費中支付中的低效率會讓暗箱的手續費支付變成大礦工的利潤來源；而體量小的、分散的礦工，則無法從中獲益，因為給小礦工支付以期望交易確認是不切實際的、沒有用的。協議外的支付也可能會招來 AML/KYC 問題：目前，大部分的協議外手續費支付支付系統都要求某種形式的 AML/KYC 流程；一個顯著的例外是 mempool.space 加速器，在本文撰寫之時（2024 年 8 月），可以用閃電支付，無需賬戶。
為了在預簽名交易的情形中直接使用 RBF，你需要預簽名同一交易攜帶不同手續費的變體，以覆蓋手續費的完整可能區間。雖然這在許多情形中是相當可行的，因為必要的變體數量通常很少 [12]，但目前，生產環境中的閃電網絡協議 —— 以及提議中的其它協議 —— 都轉而選擇了 “子為父償（CPFP）”，通常會通過 “錨點輸出”。
錨點輸出背後的想法是，向一筆交易添加一個或更多小額（或是零價值）的輸出，讓子交易在追加手續費（即 CPFP）時可以花費這些輸出。在應用到閃電通道這樣使用小體積鏈上交易的協議上時，這自然是非常低效的，會讓使用臨時錨點輸出的承諾交易的總體積膨脹到原來的幾乎兩倍。在應用到使用較大體積交易的協議 —— 比如使用 OP_CAT 來實現限制條款 —— 上時，就不會那麼令人困擾了。
錨點輸出的一個不那麼顯著的問題是，需要保留額外的 UTXO（用在子交易中）來支付手續費。在一個標準的 “客戶端” 應用中，這可能是一個重大的開銷負擔，因為不使用錨點輸出的時候，通常完全不需要保管超過一個 UTXO。實際上，在現有的一些面向消費者的閃電錢包中，無法在高手續費環境中支付手續費可能會讓他們容易被通道對手攻擊（偷盜資金）。
SIGHASH_ANYONECANPAY 可以在某些場合下用來支付手續費，它允許給簽好名的交易增加額外的輸入；SIGHASH_SINGLE 則允許也加入輸出。閃電網絡協議將它們用在 HTLC 交易中。在目前，如果沒有謹慎處理 [13]，這種用法是容易遭到釘死攻擊的，因為攻擊者可以加入許多輸入 以及/或者 輸出來製作 高手續費/低費率 的釘死交易。RBFR 可以解決這個問題；而用在 TRUC/V3 交易中的方法則不能解決這個問題。這種手續費支付方法不如 RBF 那麼高效，但可以比錨點輸出更高效。
最後，也有許多軟分叉提議，要給比特幣協議加入一種手續費資助系統。這讓交易可以聲明對其它交易的依賴關係，使得，資助交易只能在被資助交易被挖出的時候挖出（極可能在同一個區塊）。這可以比傳統的 CPFP 效率高得多，因為資助交易可以使用比交易輸入少得多的字節來聲明這種依賴關係。
4.3 替代交易循環攻擊
“替代交易循環攻擊”[14] 嘗試用替代交易阻擋一筆目標 L2 交易足夠長事件，並讓一筆不那麼好的交易被挖出。本質上，對攻擊者來說，替代交易循環攻擊是交易釘死攻擊的一種替代，因為攻擊者的意圖是阻止一筆好的、誠實的交易足夠長事件（不讓它被挖出），從而讓一筆不那麼有價值的的、不誠實的交易被挖出。不同的是，替代交易循環攻擊不可能是無意中觸發的。
典型的例子是針對閃電通道中的 HTLC 交易的。雖然人們可能會認為 HTLC 是一種合約，要麼 一筆交易通過揭曉原像來花費它，要麼它就會超時。但事實上，因為比特幣腳本的限制，通過揭曉原像來花費它的機會是 永遠 存在的，在超時之後，只是會 額外 開啟一種超時花費機制。
替代交易循環攻擊就利用了這一點，在超時 之後 繼續嘗試使用原像花費交易，來替換嘗試通過超時機制贖回價值的交易，同時，不讓受害者知道這個原像。成功的替換交易循環攻擊要持續足夠長時間，直到另一條通道中的 HTLC 超時。
要從替換交易循環中獲利，一大挑戰在於攻擊的每一輪都需要消耗資金。一個能夠覺察最終期限的閃電網絡實現會使用越來越高的手續費，以嘗試在下一個 HTLC 輸出過期之前花費（贖回）當前的 HTLC。其次，一旦替代循環結束，任何人都可以通過重新廣播被替代的交易 [15] 來挫敗這種攻擊。
跟釘死攻擊一樣，替代交易循環也是對礦工的經濟爆破。在每次循環結束的時候，都又一筆交易會從交易池中移除，雖然它是完全有效的，也是可以挖出的，只要礦工的交易池中保留了它的話。
5 特性模式與軟分叉
我們已經為多種依賴於限制條款的 L2 系統以及交易池所面臨的挑戰作了概述，接下來我們要提煉一系列著名的軟分叉特性（主要是新的操作碼）和這些 L2 系統共有的設計模式。對軟分叉提議，我們也會討論跟這些提議相關的技術風險，以及部署它們所面臨的挑戰。
5.1 OP_Expire
我們先把這個搞清楚。OP_Expire 是作為一種直接消除替代交易循環攻擊的辦法而被提出的 [16]，它直擊根本：HTLC 是可以同時被兩種不同方式花費的。在 L2 系統的語境下，這跟所有使用 HTLC 及類似機制的系統有關，可能也會跟其它用法有關。OP_Expire 將讓一個交易輸出在某個時間點 之後 不能再被花費，從而 HTLC 的花費條件變成真正排他性的 OR，而不是 “程序員的 OR”。
真正的 OP_Expire 軟分叉可能會由兩個特性組成，類似於分兩步到來的 OP_CheckLockTimeVerify 和 OP_CheckSequenceVerify（譯者注：分別是腳本層面的絕對時間鎖和相對時間鎖）：
- 交易的過期高度字段，最有可能通過 taproot annex 來實現。
- 一個
OP_Expire操作碼，可以檢查交易的過期高度不低於目標高度。
雖然 OP_Expire 自身很難算是限制條款，卻似乎對許多依賴於限制條款的 L2 系統都是有用的。不過，給定替代交易循環也可以通過互助重廣播 [15] 來緩解，它又可能不夠有用。
部署和使用 OP_Expire 的一個非常明顯的挑戰在於區塊鏈重組：在比特幣的技術社區中，從重本錯 [17] 開始，就在嘗試保證比特幣的共識協議具有這樣一種特性：即使發生了深度的重組，以前被挖出的交易也可以進入新區塊。這一設計原則嘗試避免得到了大量確認的 UTXO 一夕之間變成永久無效的惡魔場景 —— 依賴這些 UTXO 的人就會丟失資金 —— 如果一次共識錯誤導致了大規模的重組。
在大規模重組事件中，使用上述過期機制的交易可能會變成無法再挖出，因為抵達了它們的過期高度。OP_Expire提議認為可以將使用上述過期機制的交易當作 coinbase 交易，讓它的輸出也在 100 個區塊內無法花費，從而緩解這個問題。
部署交易過期機制的一種重大負擔是達成共識：這種取捨是可接受的嗎？甚至，我們需要它嗎？在 OP_Expire能夠起作用的交易中，已經包含了凍結用戶資金的長時間鎖定。加入更長的超時時間是不合適的。此外，在區塊重組之後，重複花費總是能夠作廢某一些 UTXO：隨著 RBF 的普及和 “無密鑰錨點輸出” 的是由，交易超時機制還會有很大作用嗎？
5.3 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 簽名被髮布，它就可以被用來花費 任何 使用相同腳本的交易輸出。因此，只要第二個使用相同腳本的輸出被偶然創建出來了，SIGHASH_ANYPREVOUT 就允許一種簡單的重放攻擊（replay attack），會導致資金被盜。然而，因為錢包和 L2 實現還有許多可能搬起石頭砸自己的腳的地方，這一顧慮似乎也消亡了。
在此時，廣大的技術社區對於實現 BIP-118 似乎是合理樂觀的。然而，就像我們在討論 LN-Symmetry 時候說的，人們也在辯論他的主要應用場景 —— LN-Symmetry —— 是不是一個好的想法。
5.3 OP_CheckTemplateVerify
我們要討論的第一個專為限制條款設計的提議是 OP_CheckTemplateVerify，常常也被稱為 “CTV”，它致力於創建一種非常具體的、受限的限制條款操作碼，只做一件事：以特定方式哈希不包含具體輸入 UTXO 的花費交易，然後檢查檢查得到的哈希摘要是否與腳本堆棧棧頂的元素相等。這使得我們可以提前約束花費一個輸出的花費交易，而不會 讓真正的遞歸型限制條款成為可能。
為什麼 CTV 不能實現遞歸型限制條款？因為哈希函數：CTV 用一個模板哈希值來檢查花費交易，那麼就沒有辦法 [18] 創建一種可以包含 CTV 和自身哈希值的模板。
話說回來，這不盡然是一種真正的限制：在最新的計算機上，你可以在幾秒內輕鬆哈希出一條深度達到幾千萬筆交易的 CTV 模板鏈條。而 nSeuqunce 相對時間鎖和有限的區塊空間，會讓這個鏈條輕輕鬆鬆將一筆資金鎖定幾千年。
當前 BIP-119 中的 CTV 提議只有一種哈希模式，叫做 DefaultCheckTemplateVerifyHash，本質上就是在模板哈希值中承諾花費交易的每一方面。從實用的角度看，這意味著，在許多情況下，CPFP 會成為唯一可用的手續費支付手段。如前所述，這可能是一個問題，因為它讓暗箱的支付變成可以節約大量成本的手段，在使用 CTV 的交易體積較小的時候。
公允地說，CTV 也在圍繞限制條款操作碼提議的技術社區中得到了廣泛的支持，因為它相對簡潔，用途廣泛。
5.3.1 LNHANCE
一種實現 CTV 的提議是將它與額外兩種操作碼 OP_CheckSigFromStack(Verify) 和 OP_InternalKey 相結合。問題在於，截至本文撰寫之時，相關 PR 和 BIP 中的文檔不足以支持或否決這一提議。對於這些操作碼被期待在哪一些真實案例中發揮作用，相關的 BIP 完全沒有任何分析，更不用說深度的案例腳本了。
雖然這個提議的作者們可能有很好的理由，他們有責任解釋這些理由並給予恰當的證明。因此，我們不會再進一步討論。
5.4 OP_TXHASH
類似於 CTV，這一提議通過哈希來自花費交易的數據，從而實現一種非遞歸的限制條款功能。與 CTV 不同的是，TXHASH 提議提供了一個 “字段選擇器” 機制，允許靈活地限制花費花費。這種靈活性實現了兩個主要目標：
- 允許為交易添加手續費，而不會打破多交易串聯的協議。
- 多用戶的協議可以允許用戶只限制自己的輸入和輸出。
OP_TXHASH 的主要問題在於，字段選擇器機制也帶來了非常多的複雜性，讓審核以及測試變得更難（相比於簡單得多的 CTV 提議）。截至本文撰寫時，甚至還沒有出現關於字段選擇器機制到底能帶來什麼好處、具體如何使用的設計分析。因此我們不再討論。
5.5 OP_CAT
這是個拼接操作碼，可以拼接堆棧棧頂的兩個元素，然後將結果推回棧中。比特幣最初發布的時候，是啟用了 OP_CAT 的。但中本聰在 2010 年就悄悄移除了它，因為最初的實現缺乏對結果元素的體積限制，從而容易受到 DoS 攻擊。看看這樣一個腳本：
DUP CAT DUP CAT...如果堆棧元素的體積沒有限制，每迭代一輪 DUP CAT 都會讓棧頂元素的體積倍增，最終用盡所有內存。
拼接足以實現許多類型的限制條款，也包括遞歸型限制條款，通過：
- 在堆棧中，使用一個或更多
OP_CAT裝置（以及所需的無論什麼限制條款專用型邏輯），組裝出 沒有見證數據 的 殘缺 交易。 - 在堆棧中驗證組裝出來的交易跟花費交易相匹配。
事實證明，通過濫用 Schnorr 簽名的數學，就可以用精心構造的簽名，在 OP_CheckSig 中執行上述第二個步驟。不過，更可能的是，OP_CAT 軟分叉會跟 OP_CheckSigFromStack 相結合，後者允許用驗證堆棧中的一個簽名是對某一目標交易的有效簽名 [19]，來執行上述第二個步驟；然後再對同一個簽名使用 OP_CheckSig，來驗證花費交易跟目標交易一致 [20]。
事實上，我們只需要組裝交易 而不需要 見證數據，是一個關鍵點：限制條款只需要驗證交易 做了什麼 —— 其輸入和輸出 —— 而不需要驗證見證數據（如果有的話）能否讓這個操作有效。
模數腳本體積限制，結合 OP_CAT 和 OP_CheckSigFromStack，足以開發只是許多類型的限制條款，包括遞歸型限制條款。相比更高效的解決方案（比如 CTV），這會更貴一些。但代價上的差別會比你想的要小！
大致上，使用 OP_CAT，會需要將花費交易的所有非見證數據部分，都通過見證數據放置再堆棧中。對於標準的 CTV 應用場景，例如交易輸出樹，來說，花費交易完全沒有見證數據。但因為見證數據可以打 75% 的折扣，因此子交易的實質交易手續費僅僅高出了 25% 。還不錯！
5.5.1 OP_CAT 是否太過強力？
這可能是部署 OP_CAT 要面臨的最大的政治和技術阻力：很難預測 OP_CAT 會讓哪些用法成為可能。貓咪一旦出了籠子，想抓回來就不是那麼容易的了。
一個很好的例子是，有人主張只需要 OP_CAT 就可以在比特幣腳本中實現相當高效且安全的 STARK（可擴展的透明知識陳述）驗證。因為 STARK 可以證明相當廣泛的語句，所以，可以高效實現 STARK 就有極大的影響，不會隻影響 L2 系統，因為它會使得許多不同的系統都可以建立在比特幣上。一種強烈的反對一件事：這些用法可能不是對所有比特幣用戶都好。
產生有害的、會誘發中心化的 “礦工可抽取價值（MEV）”，被 Matt Corallo 命名為 “邪惡 MEV（MEVil）”，是一個關鍵的潛在問題（中文譯本）。簡而言之，MEVil 是指 大礦工/大礦池 可以通過使用複雜的交易挖礦策略賺取額外收益 —— 而不僅僅是儘可能多的手續費 —— 而小礦工難以採用這些策略的情形。OP_CAT 可以創造出來的金融工具非常複雜，這會讓 MEVil 很難消除。在比特幣上，顯著的 MEVil 在代幣拍賣協議出現的時候，就已經出現；幸運的是，這個問題已經因為 full-RBF 的採用而被解決掉了。
除了潛在的 MEVil，OP_CAT 還有其它幾種用法可能是有害的。舉個例子，我們之前已經評審過的 Drivechain 提議，就被廣泛認為是對比特幣有害的。有人認為使用 OP_CAT 就可以實現 Drivechain。另一個例子是 Taproot Assets 這樣的代幣協議。雖然基本上無法阻止使用 “客戶端驗證” 概念來實現它們，但也有人提出使用 OP_CAT 來實現它們，這對終端用戶可能更有吸引力，但這可能會使用多得多的區塊空間，可能會擠出 “正統的” 比特幣交易。這些用法可能會帶來司法問題，取決於這些代幣協議多麼經常用在金融欺詐中。
5.6 遞進哈希
在限制條款的實現中，OP_CAT 的主要用法是拼接數據，然後哈希它們。另一種實現相同目標的方法是使用某種遞進哈希的操作碼（incremental hashing opcode），取一個 SHA256 運算的某個中間狀態，然後哈希更多數據；SHA256 自身是在 64 字節的數據塊上操作的。遞進哈希操作碼有許多種可能的設計。
一個重要的設計抉擇是，在將實際的中間狀態字節暴露在堆棧中的時候，要使用某種規範的形式，還是用某種不透明的類型來表示它們（使得實際的字節數值無法被直接操作）。SHA256 被指定了一個具體的、固定的初始化向量，如果可以使用任意的 中間狀態/初始化向量，不確定 SHA256 的密碼學屬性是否還能得到保留。
當然，因為遞進哈希可以做到 OP_CAT 能做的許多事，只是效率更高，它也要面臨一樣的顧慮：太過強大。
5.7 Script Revival
OP_CAT 是中本聰禁用的 15 個操作碼之一。除了恢復 OP_CAT，Rusty Russell 正在提議 [21] 通過重啟啟用其中的大部分操作碼、加入 DoS 限制（可能還要在同一個軟分叉中加入少量新操作碼），將比特幣的腳本編程能耐復原成 “中本聰初版”。具體來說，可能會加入一個 OP_CheckSigFromStack。
雖然 OP_CAT 自身已經讓（遞歸的）限制條款成為可能，完整的 “script revival（腳本復興）” 會讓更加複雜的限制條款成為可能 —— 實現起來也容易得多 —— 因為可以直接操作花費交易的某些部分。舉個例子，你可以事項一種限制條款腳本，使用算數操作碼來保證交易的輸出的總價值會保持一些有趣的屬性。
此外，腳本復興也面臨跟 OP_CAT 相同的顧慮，甚至更多，因為它比 OP_CAT 還要強力。
5.7.1 Simplicity
類似於腳本復興，Simplicity 跟 L2 和限制條款相關是因為它可以做所有事情。而與腳本復興不同的是，Simplicity 軟分叉可能會給比特幣的腳本系統加入一種全新的編程語言，基於 9 種叫做 “結合碼（combinator）” 的操作碼原語。
實際上，Simplicity 既過於簡單，又一點也不簡單。結合碼過於底層，以至於連加法這樣基本的操作都要辛辛苦苦從頭實現；裸的 Simplicity 代碼在實踐中會過於繁瑣。因此，Simplicity 的任何真實用法可要利用一種代碼替換系統，類似於庫函數調用，叫做 “jet”。這就成了一個 實用/政治 問題：如何決定要實現哪個 jet？很可能 jets 會用 C++ 語言來實現，就跟別的操作碼一樣，從而每加入一個新的 jet 都需要一次軟分叉。
5.8 OP_FancyTreeManipulationStuff
人們還提出了許多相對專用的操作碼，以更節約空間的方式操作樹結構，以供依賴於限制條款的 L2 系統使用。舉個例子，Coinpool 提議就提出了 TAPLEAF_UPDATE_VERIFY 和 OP_MERKLESUB，兩種操作碼都是對 taproot 腳本樹的操作，對 Coinpool 提議來說都是必要的，而 MATT 也提出了一種 OP_CheckContractVerify 操作碼，基本上，就是驗證關於默克爾樹的陳述。
從本文的目的出發，我們不需要細究這許多提議中每一種的細節。相反，我們可以把它們都當成一類：它們全部是相對專用的協議，旨在讓一類 L2 成為可能，並希望沒有意料之外的副作用。它們都有高效的優點：比起使用更通用的操作碼（例如 OP_CAT 操作），它們都使用更少的區塊空間，就能實現相同的目標。但它們
