在鏈錢包中，交易幾乎可以實現一對一的映射：對於用戶執行的每筆經濟交易，大約需要一筆區塊鏈交易。匯總、coinjoin、削減支付等都會對這一說法進行一定程度的改變。但大致上是正確的。

閃電實現了將多個交易映射到單個交易的魔法：閃電的神奇之處在於在單個閃電通道中可以發生有效無窮多的經濟交易，而這個通道本身與單個未花費的交易輸出（UTXO）相關聯。基本上，我們通過折疊“時間”維度-交易，實現了顯著的擴展。

但是每個用戶創建一個UTXO甚至可以說還不夠好。因此，有許多提案旨在通過自主方式允許多個用戶共享單個UTXO，以實現更大的擴展。再次將另一個“空間”維度的擴展 - 用戶 - 折疊到一個UTXO中。

我們的目標是對所有這些提案進行概述，找出它們共享的技術模式，找出它們需要哪些新的操作碼和其他軟分叉升級來運作，並創建一個比較表，展示所有部分如何配合。在此過程中，我們還將定義L2協議到底是什麼，閃電已經具備了哪些擴展能力，並了解我們需要對記憶池進行哪些改進才能實現所有這些目標。

感謝Fulgur Ventures贊助本研究。他們對本文內容沒有編輯控制，並且在發布前未審核。

感謝也送給Daniela Brozzoni, Sarah Cox，以及其他用於預發佈審查。

定義

Layer 2是什麼？

通常，“二層”這個術語的定義很廣泛，甚至可以將類似銀行實體（例如Liquid）定義為二層。就本文而言，我們將採用一個嚴格的定義：二層（L2）是一個以比特幣為基礎的系統，目的是允許比特幣與其他交易對方進行的交易次數超過鏈上交易次數的數量。這樣可以實現以下兩種情況之一：

1. 沒有人能夠在系統中盜取資金並獲利，考慮到系統內的懲罰和成本。我們的定義中不考慮系統外的成本和懲罰，比如聲譽損失、法律後果等。
2. (首選) 資金的真正擁有者能夠在沒有任何第三方合作的情況下，單方面提取他們的資金，減去交易手續費。

第一個選項是必需的，因為我們希望我們的L2系統能夠表示無法在鏈上表示的小額價值和交易。例如，在閃電網絡中，HTLC的價值可能太小而無法在鏈上表示。在這種情況下，HTLC的價值將被添加到承諾交易的交易費用中。儘管閃電節點可以在適當的時刻關閉通道來“竊取”一個微小的HTLC，但這樣做更加昂貴。¹比HTLC的價值還要高，使得偷竊變得不值得。

話雖如此，單方面退出始終是我們的主要設計目標。²

根據這個定義，像閃電這樣的事物被視為L2系統。然而，像Liquid、Cashu和Fedimint這樣的系統不是L2系統，因為另一方或多方控制著你的資金。像RGB這樣的客戶端驗證方案在這個定義下也不是L2系統，因為它們無法信任地進行BTC本身的交易。最後，@RubenSomsenStatechains未能入選，因為如果Statechain實體不遵循協議，則可能會竊取資金。

Covenants是什麼？

…為什麼更具可擴展性的Layer 2系統需要它們？

在比特幣腳本中，契約是一種機制，通過該機制，txout 的花費方式被事先限制，以便花費該 txout 的交易形式被預定義或以其他方式限制，並不僅僅限於簽名。共享UTXO的L2系統需要契約，因為它們需要限制UTXO的花費方式，以實現L2協議的規則和激勵。

遞歸契約

遞迴契約是具有以下特性的契約：對於支出交易的子UTXO可以無限遞迴地應用約束UTXO支出方式的規則。遞迴契約有一直被一些人認為是不可取的因為它們可以無限期地拖累硬幣。或者至少在沒有第三方（如政府）許可的情況下無限期地拖累。

目標

閃電是目前“最好的”Layer 2系統。然而它有限制。即:

1. 擴展 - 閃電網路目前要求每個最終使用者至少有一個UTXO。³
2. 流動性 - Lightning 要求資金必須綁定在通道中。
3. 互動性 - 閃電需要支付接收者在線才能無需信任地收款。

在評估第二層系統時，我們的目標是改善這些關鍵限制，最好不要增加新的限制。

閃電網路的擴展限制

「每個終端用戶一個UTXO」在實踐中是什麼意思？由於閃電通道可以無限期地運作，這是一種問題的看法，即每年可以創建多少個新通道。⁴. 創建一個 taproot 輸出的邊際成本為 43vB；如果通道創建是分攤的，即在一個交易中創建許多通道，那麼其他交易開銷可以忽略不計，每年可以開通大量通道來吸納新用戶。例如，假設 90% 的區塊容量用於開通新的 taproot 閃電通道：

据估计全球約一半的人口擁有智慧手機43億人。因此，事實上，我們可以加入整個可能每年能夠使用閃電通道的人口的相當大比例。

然而，通道並非永恆存在。有時用戶會希望切換錢包、增加或減少通道容量等。改變通道容量的最有效方法是通過拼接，尤其是在實施上，Phoenix 錢包.

就像通道開啟一樣，拼接也可以以分攤的方式進行，以提高效率，多個拼接操作共享一個交易，減少添加和移除資金所需的輸入和輸出數量。⁵因此，假設使用，每個用戶的接合所需的增量區塊空間。musig, 是43vB taproot输出加上，

57.5vB taproot keypath花費，總共100.5vB。如果我們再次假設90%的區塊空間使用率，我們得到：

最後，請注意如何在錢包之間切換閃電通道可以通過單一交易完成，方法是在將資金發送到承諾地址後信任下一個錢包簽署承諾交易，或在兩個錢包實現合作關閉新通道支持時進行。

當然，除了閃電網路之外，比特幣還有相互競爭的用例，這將如何轉化為費率很難知道。但這些數位給了我們一個粗略的大概，表明以目前的技術，至少在技術上可以支持數億自我主權的閃電網路使用者。

L2 概述

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

1. 通道
2. 虛擬UTXOs

在通道模式中，其中閃電網絡是主要示例，協議通過在各方之間交換預先簽名的交易來進展，這些交易可能已挖礦，但並非處於“快樂路徑”。這些預先簽名的交易將未使用交易輸出（UTXO）在各方之間進行劃分；交易通過重複改變該劃分的餘額以及新的預先簽名交易來進行。由於將存在許多不同的可能有效交易來花費相同的UTXO，因此需要某種激勵機制來確保正確的交易實際上被挖礦。

在虛擬UTXO（V-UTXO）設計模式中，其中Ark是最突出的例子，V-UTXO是通過契約或多方協議創建的，通過創建交易來將其放入鏈上挖掘，但不在“快樂路徑”上單方面提取V-UTXO資金。在這方面，V-UTXO與通道類似。但與通道不同的是，V-UTXO方案通過花費V-UTXO本身進行交易，在（概念上）單一⁶預簽名交易。

“快樂路徑”設計模式是使用“所有方​​​​​​​式同意”的腳本路徑，例如N-of-N多重簽名；taproot專門為此概念設計，允許通過musig將密鑰路徑設置為N-of-N多重簽名。假設所有方​​​​​​​式都同意，快樂路徑允許有效（且私密）地花費貨幣。

有趣的是，由於虛擬UTXOs在許多意義上都是“真實的”，所以通過創建虛擬UTXOs來構建通道是相當容易的，如果挖礦成功，將導致創建通道所需的UTXOs。從這個意義上講，虛擬UTXO方案是一種

比通道略低的層次。

閃電

現狀，實施在生產上的閃電網絡，主要基於BOLT標準. Lightning是由多個元素組成的，包括閃電通道和HTLC，P2P路由網絡，洋蔥路由，發票標準等。值得注意的是，Lightning不是一個共識系統，因此，“Lightning系統”的不同元素不需要被所有用戶以完全相同的方式採用。對於本文而言，當我們說“Lightning”時，我們將在廣義上使用它，包括對目前（典型的）廣泛使用的Lightning協議的易見升級。

如上所述，閃電網路的關鍵特徵是其最終使用者可擴展性限制，因為每個使用者至少需要一個UTXO。也就是說，對於閃電網路的“核心”路由元素 - 路由絕大多數交易的公共閃電節點 - 這些可擴展性限制並不是什麼大問題，因為如果最終使用者比路由節點多得多，閃電網路的功能就很好，因為用於支付路由的每個公共管道都可以輕鬆支援每秒的大量交易。這也是為什麼未來的許多L2系統也希望參與閃電網路的原因。我們也從現有的非L2系統（如Cashu）嚴重依賴閃電網路來實際發揮作用中看到了這一點：Cashu的主要用途可能是發送和接收閃電網路付款。

非互動管道

這種構造通過使用OP_CTV來降低交互性要求，從而改進了閃電通道。但是，由於它沒有改進每個使用者 1-UTXO 的擴展限制，因此我們不會進一步討論它。

頻道工廠

在這裡，多個方進行談判，以產生一個n-of-n多重簽名地址，以及一筆交易來花費該多重簽名地址，並創建n個不同的UTXO以分割資金。這些UTXO進而用於支付通道。如果需要將通道狀態放在鏈上，則可以挖掘分裂交易，因此通道可以像直接在鏈上開啟通道一樣使用相同的安全性。當關閉通道時，這可以潛在地節省鏈上空間，因為在理論上，n方可以共同關閉所有nn通道。

由於通道工廠正在協商可被挖掘但在正常情況下不會被挖掘的UTXO，它們是V-UTXO非常原始的示例。

通道工廠本身並不需要任何軟分叉才能實現。然而，上述簡單的通道工廠可能在實際獲得擴展效益時由於所需的協調而變得不切實際，除非參與者人數較少。因此，諸如契約提議之類的...OP_Evict或CTV（通過txout樹）的目標是允許更精細的結果，其中可以強制單個方​​式在鏈上，而不必同時強制所有人在鏈上。

埃爾圖/LN對稱

由於Eltoo是一個非常令人困惑的名稱，因此我們將只會在未來使用更新後的名稱LN-Symmetry。

雖然 Poon-Dryja 通道通過懲罰不正確的狀態來鼓勵在鏈上發佈正確的狀態，但 LN-Symmetry 卻允許使用額外的交易更新不正確的狀態。這樣做的好處是通過消除懲罰的複雜性來簡化閃電通道。但是，在不受信任的場景中，這可能是一個劣勢，因為可以說需要懲罰來阻止欺詐。

LN-Symmetry需要軟分叉才能啟用SIGHASH_ANYPREVOUT，這是在更新期間允許狀態交易重新花費其他狀態交易所需的。

單獨看，LN-Symmetry對於傳統閃電通道沒有任何扩展優勢。但是，支持者們辯稱這讓諸如通道工廠等事情更容易實現。

方舟

Ark採用了一種新的交易擴展方法：完全可轉讓的虛擬UTXO（V-UTXO），可以在原子方式下合併和分割⁷鏈下交易。在方舟中，中央協調方舟服務提供者（ASP）為使用者提供具有定義壽命的V-UTXO，例如4周。這些週期稱為回合。這些 V-UTXO 是通過池 txout（每輪一個）通過某種機制（如 CTV）創建的，以允許單個鏈上 txout 提交到 V-UTXO 樹。回合到期是 Ark 實現擴展優勢的方式：在一輪結束時，池 txout 解鎖，允許 ASP 在小額交易中單方面使用單個簽名使用它。由於輪次到期時間，V-UTXO本身在創建它們的池txout過期時過期：擁有V-UTXO的用戶必須在池txout到期時間之前花費該V-UTXO，或者將其放在鏈上（單方面提款）。

為了在各方之間進行V-UTXO交易，Ark協調器共同簽署花費一個或多個V-UTXO的交易，只有在不同回合中創建了一個或多個其他V-UTXO時，這些交易才有效。結合一些謹慎的超時機制-請參閱Ark文檔以獲取詳細信息-這種依賴性是使得花費V-UTXO的過程無需信任的原因：只有在不同的交易池中創建新的V-UTXO時，V-UTXO才無法在鏈上被索取。實際實現這種依賴性有幾種潛在的方法。但是，具體細節與本文的目的無關。

请注意，这意味着给定的ASP将同时进行多个不同的活动轮次。新的轮次经常会被创建，以便允许现有轮次中的资金进行转移。但现有轮次与新的轮次重叠，因为它们通常会在新的轮次和新的池子交易产生后的某个时间过期。

Ark經濟學

當一個V-UTXO被花費時，ASP必須提供匹配的比特幣在一個新的池子交易中代表一個新的輪次。但在輪次到期之前，他們無法回收花費的V-UTXO的價值。因此，V-UTXO的花費經濟學有一個時間價值的費用，這是由於ASP需要提供流動性所致。

具體而言，成本是在 V-UTXO 被支出時產生的。當 V-UTXO 未被使用時，它代表著一個非常真實的潛在 UTXO，可以被放置在鏈上以單方面提取資金；用戶擁有這些資金。然而，要支出 V-UTXO，ASP 必須創建一個新的池 txout，使用 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的資本成本實際上更高，他們假設平均客戶在不到一年的時間內使用其流入的流動性。此外，Phoenix還通過交易費賺錢，可能補貼通道流動性。最後，Phoenix可能並不盈利！

美國國庫券利率為我們提供了另一個估計。根據最新數據，3個月期國庫券利率約為每年5%。由於有人認為這個利率存在通脹，我們將假設比特幣計價基金的流動性成本為每年3%進行分析。

如果每輪間隔為4週，這意味著交易將以流動性成本開始

假設用戶在回合到期前兩周嘗試將其資金轉移到新回合，最終下降至零。使用者為實現自我保管支付約1.5％的流動性成本。另一方面，如果用戶等到最後一刻⁸，成本可能接近于零，但有错过到期时间的风险。

使用者可能不會認為這是微不足道的成本。這個成本假設每一輪的固定成本通過攤銷大量參與者的交易費用和其他成本變得微不足道。

如果固定成本不那麼微不足道怎麼辦？假設 ASP 有 1000 個用戶，每小時平均創建一次池 txouts。在 4 周的時間內，這是 672 筆 on-chain 交易。這意味著為了簡單地持有他們的資金，ASP 的用戶集體必須支付幾乎與用戶一樣多的交易！他們大概可以更便宜地打開自己的閃電通道，即使 ASP 要求他們等待整整一個小時的確認。

引導啟動 Ark

一個用戶較少的新ASP面臨著兩難：ASP回合發生不頻繁，用戶必須等待長時間，以便提議的回合收集足夠的V-UTXO來實現有用的擴展和交易費用減少。或者ASP池交易頻繁發生，每個用戶支付高交易費。正如我們在前一節中所示，需要很多用戶來攤提頻繁回合和它們的基礎池txouts的成本。

因為回合會過期，這個問題是一個持續的問題，比閃電通道面臨的問題還要嚴重：至少一個閃電通道可以無限期使用，允許現在開啟通道，並在多個月內逐漸攤分。其次，由於回合會過期，新的 txouts 支持這些回合的創建時間更不具彈性：如果費用高達一兩個星期，使用者將無法選擇不支付高額費用以維護他們的資金。與閃電通道相比，開啟通道的時間更具靈活性。

雖然Ark的作者最初設想了一個非常樂觀的場景，即每隔幾秒鐘就會有新的回合，但如果交易費用沒有補貼，最初的引導可能不得不發生在可以等待數小時才能確認Ark交易的用例中。

互動性

非託管Ark是一個高度互動的協議：由於您的V-UTXO到期，您必須在ASP與之互動，否則ASP可能選擇拿走您的資金。這種互動性也無法外包：雖然閃電網路有觀測塔即使您的通道尚未上線，也會阻止對手試圖欺騙您 - Ark幣擁有者必須使用自己的私鑰在無需信任的情況下刷新資金。在Ark中，最接近觀測塔的可能是簽署交易，允許觀測塔在到期時間單方面從鏈上提取您的資金，這將產生顯著的交易費用。

考慮一下如果擁有者離線，V-UTXO會發生什麼：在回合到期后，ASP需要收回資金以恢復其流動性以進行後續回合。如果V-UTXO擁有者下線，將V-UTXO放在鏈上會產生巨大的交易成本，因為ASP現在需要在V-UTXO樹的多個級別收回資金。ASP可以在新一輪中重新創建未花費的V-UTXO。但從V-UTXO擁有者的角度來看，這並非不可信，因為他們不能在沒有獲得數據的情況下花費這些V-UTXO⁹從ASP。ASP也可以將未用的V-UTXO記錄為保管餘額。或者甚至有一個扣押資金的政策！

就我個人而言，我懷疑考慮到方舟中自我託管的不平凡成本，許多使用者會選擇具有將資金轉入新一輪的政策的ASP，並在每一輪結束時簡單地接受潛在的欺詐行為。這比儘早主動轉移資金以保證安全要便宜，例如，他們未能及時打開手機，以便錢包將資金轉移到新一輪。

高級方舟

通過更高級的契約來降低方舟的流動性需求可能是可行的，如果流動性通常在一輪中途用完。例如，假設池 txout 中總 V-UTXO 值的 50% 已用完。如果平均售價只能贖回本輪資金池的那部分，他們可以更快地恢復流動性，從而降低整體流動性成本。雖然沒有發表關於如何做到這一點的具體建議，但似乎應該可以通過足夠先進的™盟約來實現。最有可能通過某種腳本復興軟分叉，一次添加許多有用的操作碼。

同樣地，通過充分先進™的契約，整個txout樹結構可以被某種滾動提取方案替換，可能提供空間節省。我們將在進一步的章節中介紹這個技術，因為這種技術對其他方案也可能有用。

結束回合時的保管問題是另一個情況，足夠先進的™契約可以解決問題：特別是，一個ZK-proof契約可以強制ASP在下一個回合中重新創建所有未花費的V-UTXO，從而消除了在回合結束時將保管權歸還給他們的問題。雖然可能無法實現無需信任，因為用戶可能需要一些來自ASP的數據來在新的回合上花費他們的V-UTXO，但它可以防止ASP從對離線用戶的欺詐中獲得經濟利益。

單方面提款的鏈上手續費支付

和閃電網絡類似，鏈上手續費支付的經濟學和V-UTXO在手續費後的實際價值確定了Ark使用是否符合我們對L2的定義，即通過單方提款或未能使ASP受益的詐騙。在討論txout樹設計模式時，我們將進一步討論其具體細節。

Validity Rollups

一大類類似側鏈的結構，一般提出使用各種形式的零知識（ZK）證明技術來強制鏈的規則。 ZK-proof 技術是有效滾動技術和其他形式的側鏈之間的關鍵區別：如果 ZK-proof 方案有效，則交易的有效性可以通過數學而不是信任第三方來保證。在這種用例中，“零知識”方面其實並不是一個要求：如果證明“洩漏”有關其正在證明的信息，這是完全可以接受的。只是碰巧，這種證明的大多數數學方案碰巧是零知識證明。

從比特幣的角度來看，有效性匯總方案需要契約，因為我們希望能夠為只有在遵循方案規則的情況下才能花費的方案創建UTXO。這不一定是一個分散的過程。許多有效性匯總方案實際上是完全集中的;匯總證明證明集中式事務排序器遵循特定事務序列的規則。

至於什麼盟約... 零知識證明技術仍然是一個非常新的領域，仍然經常有進展。因此，我們很難看到任何直接驗證特定ZK證明方案的比特幣操作碼的添加。相反，人們普遍認為特定方案將使用更通用的操作碼，尤其是OP_CAT，通過腳本驗證ZK證明。例如，斯塔瓦雷是競選OP_CAT通過。

有效性滾動是一個潛力巨大的話題，有很多低實質/高炒作的項目，我們不會進一步討論它，只是指出哪些操作碼可能使這種設計類別成為可能。

比特虛擬機

嚴格來說，BitVM是一種在兩個方之間構建閃電通道的方法，以使閃電通道的規則通過零知識證明得到執行。由於它實際上不需要在比特幣上實施契約，並且由於它不能直接用於創建超出每個用戶1 UTXO限制的L2系統，因此我們不會進一步討論它。

階層通道

階層通道¹⁰旨在快速且廉价地调整通道大小：“分层通道对于通道容量的作用就像闪电网络对比特币的作用一样”。然而，它们仍然没有从根本上超过每个用户的1个UTXO限制。无论如何，它们也不需要对比特币协议进行任何更改。因此，我们不会进一步讨论它们。它们的支持者应该直接实施它们！它们不需要我们的许可。

CoinPool

CoinPool允許多個用戶共享單個UTXO，在不同用戶之間轉移資金，並單方面提領。 CoinPool論文提議需要三個新的軟分叉功能，SIGHASH_ANYPREVOUT，SIGHASH_GROUP允許簽名僅應用於特定的UTXO，以及OP_MerkleSub用於驗證從Merkle樹中刪除特定分支；後者也可以使用OP_CAT來實現。

目前，CoinPool的開發似乎停滯不前，最後一次提交規範網站是在兩年前。

Enigma 网络

雖然我被要求報導Engima網路，但似乎缺乏關於該提案真正是什麼的檔。比特菲尼克斯的部落格文章提出了很多主張;MIT頁面是空的。由於這篇博客文章並未清楚說明究竟應該發生什麼，我們將不再討論此事。

Mempool 考慮事項

比特幣核心中的當前記憶體池策略對於L2系統並不理想。在這裡，我們將介紹他們面臨的一些主要挑戰以及潛在的改進。

交易固定化

最終是一種經濟攻擊，交易固定攻擊是指某人可以有意地（或者是不小心的） 使得難以挖掘所需的交易，因為事先廣播了未被挖掘的衝突交易。這是一種經濟漏洞，因為在真正的交易固定情況下，存在一個理想的交易，如果礦工開採它，他們會從中獲利;衝突的固定交易不會在合理的時間內開採，如果有的話。

固定的最簡單示例來自沒有全 RBF 的事實，可以關閉事務替換。因此，我們可以進行低費率交易，關閉替換，該交易不會被開採，但無法更換。基本上 100% 的哈希算力通過啟用全 RBF 解決了這個問題，截至撰寫本文時，應在下一個版本的比特幣核心中預設啟用全 RBF（之後11年的努力!).

這意味著BIP-125規則＃3固定是唯一與多方L2協議相關且在比特幣核心中未修復的剩餘固定問題。參考BIP-125規則＃3如下所述：

更換交易需要支付較高的絕對費用（不是

僅手續費率) 高於被替換的所有交易支付的手續費總和。

透過廣播一個大量低費率的固定交易，花費與多方協議相關的輸出（或是一組交易），可以利用這個規則。由於交易具有低費率，如果有的話，它將不會及時被開採。然而，由於它具有高總費用，用另一個交易來取代它是不經濟的。

規則 #3 固定很容易通過以下方式修復replace-by-fee-rate，此修復程式適用於所有情況。不幸的是，目前還不清楚 RBFR 是否會在不久的將來被 Core 採用，因為他們在劣質部分解決方案上花費了大量精力，TRUC/V3 事務.

費用支付：RBF、CPFP、SIGHASH_ANYONECANPAY、主播和贊助

由於費率不可預測，因此在事先簽署交易的情況下可靠且經濟地付款是困難的。付費的黃金標準是使用RBF，從初始的“低估”開始，並根據需要將交易替換為更高費用的版本，直到它被採礦。例如，OpenTimestamps日曆軟件多年來一直使用RBF這種方式，而LND則添加了對其的支持。v0.18中的deadline aware RBF.

RBF是最节省区块空间的收费标准，因此在几乎所有情况下都是最好的选择。¹¹情況：相對於第一次猜測正確費用所需的額外輸入或輸出，替換交易不需要任何額外的輸入或輸出。

效率很重要，因为付款效率低会造成帶外費用支付對於大型礦工來說，這是一個有利可圖的收入來源；較小的去中心化礦工無法從帶外費用支付中獲利，因為支付小礦工以確認交易的不實用性和無用性。帶外費用支付似乎也會引發AML/KYC問題：目前，現有的大多數帶外費用支付系統都需要某種AML/KYC過程才能進行費用支付，但有一個值得注意的例外，即mempool.space加速器截至2024年8月撰寫時，支持閃電交易而無需帳戶的平台（第2層）

要直接在具有預簽署交易的情況下使用RBF，您需要預先簽署各種費用變體，以涵蓋潛在費用的全部範圍。雖然在許多情況下這是相當可行的，因為通常所需的變體數量很少¹²目前為止，生產閃電協議-以及其他提議的協議-選擇使用Child-Pays-For-Parent(CPFP)，通常透過錨定輸出。

錨定輸出的概念是將一個或多個輸出添加到具有最小或零值的交易中，目的是通過在次要交易中花費這些輸出來支付費用，從而通過CPFP支付費用。當應用於具有小型鏈下交易的協議（例如LN）時，這當然非常低效。將臨時錨定輸出使用LN承諾交易的總大小加倍.當應用協定使用較大的事務時，例如任何使用OP_CAT來實現契約的協定，這將不是一個問題。

錨定輸出的一個不太明顯的問題是需要保留額外的UTXO來支付費用。在典型的“客戶”應用程序中，這可能是一個重要的負擔，因為如果沒有錨定輸出，通常完全不需要維護多個UTXO。實際上，在高費用環境中，一些現有的面向消費者的閃電錢包可能由於無法支付費用而容易受到通道的遠程方的盜竊。

在某些情況下，SIGHASH_ANYONECANPAY可以用於通過允許將額外的輸入添加到已簽名的交易中進行費用支付；SIGHASH_SINGLE還允許添加輸出。閃電網絡在HTLC交易中使用此功能。目前，如果不小心處理，這種做法可能會導致交易被固定。¹³由於攻擊者可能會在交易中添加大量輸入和/或輸出以創建高費率/低費用率的交易，所以RBFR修復了這個問題；TRUC/V3交易中使用的方法無法修復這個問題。這種費用支付方式不如RBF高效，但比錨定輸出更高效。

最後有各種軟分叉提議來添加一個手續費贊助將閘道系統鏈接到比特幣協議。這將允許交易聲明對其他交易的依賴，從而只有在贊助交易也被挖掘（很可能在同一個區塊中）的情況下，贊助交易才能被挖掘。這可能比傳統的CPFP更有效，因為贊助交易可以使用比交易輸入的大小更小的vbytes來聲明依賴關係。

替換自行車

替換式循環攻擊¹⁴利用交易替換來嘗試取代所需的L2交易，以便足夠長的時間獲取一個不需要的交易來進行挖掘。實質上，對於攻擊者來說，替換循環攻擊是交易固定技術的替代方案，因為它們旨在阻止所需的誠實交易在被挖掘之前足夠長的時間允許一個不需要的不誠實交易來進行挖掘。與交易固定攻擊不同，替換循環攻擊不會意外發生。

典型的例子是针对哈希时间锁定合约（HTLC）的。虽然我们很容易将HTLC想象成一种合约，要么通过揭示预图来允许交易被支出，要么通过超时来支出。但实际上，由于比特币脚本的限制，HTLC允许交易始终通过揭示预图来支出，然后在超时后，另外也可以通过超时机制支出。

替換迴圈利用這一點，在超時後使用前像來替換嘗試通過超時機制贖回 HLTC 輸出的事務，而無需受害者學習前像。成功的替換迴圈攻擊會執行足夠長的時間，以使不同通道的HTLC超時。

在有利可圖地利用更換週期的主要挑戰是每個更換週期都會產生成本。具有截止日期意識的閃電實現將會花費越來越高的費用，試圖在下一個HTLC輸出到期之前花費過期的HTLC輸出。其次，任何人都可以通過簡單地重新廣播替換的交易來擊敗這種攻擊。¹⁵一旦更換週期完成。

與交易固定相同，替換循環也是礦工的經濟攻擊。 在每個替換循環的結尾，存在一個已從記憶池中刪除但完全有效且如果礦工仍然將其放在記憶池中，則可以開採的交易。

功能模式和软分叉

既然我们已经为您概述了各种依赖契约的L2系统以及内存池挑战，我们将尝试将这些信息提炼为一组值得注意的软分叉功能（主要是新的操作码）和这些L2系统共享的设计模式。对于软分叉提议，我们还将讨论部署每个提议的特定技术风险和挑战。

OP_Expire

首先，讓我們先解決這個問題。OP_Expire被提議¹⁶通過在源頭解決問題，即HTLC可以同時以兩種不同的方式花費，作為消除替換循環攻擊的簡單方法。 在L2系統的上下文中，這對於使用類似HTLC機制的任何東西以及可能的其他用例都是相關的。 OP_Expire將使交易輸出在一段時間後無法花費，從而使HTLC支出條件成為真正的“互斥”，而不是“程序員OR”。

一個真正的OP_Expire軟分叉很可能由兩個功能組成，類似於...OP_CheckLockTimeVerify and OP_CheckSequenceVerify操作碼分為兩部分：

1. 交易的到期高度字段，很可能在Taproot附录中实现。
2. 一個OP_Expire操作碼，它檢查到期高度是否設置為至少所需的高度。

雖然 OP_Expire 本身幾乎不符合契約標準，但對於許多依賴契約的 L2 系統來說似乎很有用。然而，由於利他的轉播也可以減緩替換循環，因此它可能還不夠有用。¹⁵

使用OP_Expire 的一個非常明顯的挑戰是重組：從Satoshi開始，比特幣技術社區¹⁷，已經嘗試確保比特幣共識協議設計成這樣一種方式，在深度重組後，先前挖掘的交易可以被挖掘到新的區塊中。這種設計原則試圖避免一個噩夢般的情景，即大量確認的幣被永久無效，從而依賴這些幣的人損失金錢，如果共識失敗導致大規模重組。

在發生大型重組的情況下，使用到期時間的交易可能因為到達到期高度而無法被挖掘。OP_Expire 提議通過將使用到期時間的交易的輸出與 coinbase 交易類似地處理，同樣使其在大約 100 個區塊內無法被花費，以解決這個問題。

在部署交易到期日方面的一個重要障礙是達成共識，即是否需要這種權衡。需要 OP_Expire 的交易類型已經涉及較長時間的超時，其中用戶資金被凍結。增加這些超時的時間並不理想。此外，雙重花費一直是一種在重組後使硬幣失效的方法：隨著 RBF 的增加使用和建議使用無鑰匙錨點輸出，交易到期日是否會有顯著差異？

SIGHASH_ANYPREVOUT

BIP-118提出了兩種新的簽名哈希模式，都不會承諾特定的UTXO被花費。 SIGHASH_ANYPREVOUT（基本上）承諾scriptPubKey，而SIGHASH_ANYPREVOUTANYSCRIPT則允許任何腳本。正如上文所討論的那樣，最初是為了LN-Symmetry使用，以避免需要單獨簽署可能需要回應的每個先前的通道狀態。

SIGHASH_ANYPREVOUT 在某些情況下也具有潛在的用途，例如當我們想要在預簽 RBF 費率變體與預簽交易一起使用時，由於簽名不再依賴於特定的 txid，因此避免了特定交易的相關問題。費率變體的組合爆炸然而，目前的BIP-118提案並未解決此使用案例，並且由於SIGHASH_ANYPREVOUT提議也承諾對UTXO的值進行了改變，可能與之不相容。

最初反對SIGHASH_ANYPREVOUT的想法是錢包會因為以不適當的方式使用它而陷入麻煩。問題在於，一旦發佈了單個SIGHASH_ANYPREVOUT簽名，就可以使用它來使用指定的腳本進行任何 txout。因此，如果意外創建了具有相同腳本的第二個輸出，SIGHASH_ANYPREVOUT允許進行微不足道的重放攻擊來竊取這些硬幣。然而，由於錢包和L2實現中固有的許多其他腳槍，這種擔憂似乎已經消失了。

目前，一般技術社群似乎對實施BIP-118持有相當正面的態度。然而，正如我們在對LN-Symmetry的討論中所討論的那樣，關於它的主要用例——LN-Symmetry——是否真的是一個好主意，存在爭議。

OP_CheckTemplateVerify

我們的第一個特定契約操作碼提議，OP_CheckTemplateVerify - 或者通常稱為“CTV”，旨在創建一個非常具體，受限制的契約操作碼，只做一件事情：以指定的方式哈希支出交易，不承諾輸入UTXO，並檢查結果摘要與頂部堆棧元素是否相符。這允許預先限制支出交易，而不使真正的遞歸契約限制成為可能。

為什麼在CTV中無法使用遞迴契約？因為哈希函數：CTV檢查支出交易與模板哈希相符，並沒有辦法¹⁸創建一個包含自身哈希值的CTV模板。

话虽如此，这并不一定是真正的限制：您可以在现代计算机上在几秒钟内轻松地将CTV模板哈希链哈希到数千万交易的深度。相對nSequence時間鎖定而且有限的區塊大小實際上到達這樣一條鏈的末端可能需要數千年。

目前的CTV提案在BIP-119只有一種哈希模式，稱為DefaultCheckTemplateVerifyHash，它基本上會將模板哈希中的每個方面都承諾給支付交易。從實際角度來看，這意味著在許多情況下，唯一可用的費用支付機制將是CPFP。如上所述，這是一個潛在的問題，因為在使用CTV的交易量較小的情況下，這使得帶外費用支付成為一種非微不足道的成本節省。

可以说，由于其相对简单和广泛的用例，CTV在技术社区中得到了最广泛的支持，这是任何契约操作码提案中最为普遍的。

LNHANCE

實施CTV的一個提議是將其與兩個更多的操作碼OP_CheckSigFromStack（Verify）和OP_InternalKey結合起來。問題是，截至撰寫本文，該拉取請求和相關的BIP文件並不足以支持或反對這一提議。這些BIP文件完全缺乏任何有關這些操作碼在實際示例中預期執行的理由，更不用說深入的示例腳本了。

雖然作者們可能有他們提議的充分理由，但他們有責任實際解釋這些理由並恰當地加以證明。因此，我們不會進一步討論此事。

OP_TXHASH

與CTV類似，該提案通過從支出交易中的數據進行哈希處理來實現非遞歸契約功能。與CTV不同，TXHASH提案提供了一種“字段選擇器”機制，允許對支出交易的約束方式進行靈活調整。這種靈活性實現了兩個主要目標：

1. 在不破壞多交易協議的情況下，使交易能夠增加費用。
2. 多用戶協議，用戶僅限制自己的輸入和輸出。

OP_TXHASH 的主要問題在於字段選擇器機制增加了相當多的複雜性，使得審查和測試比起更簡單的 CTV 提案來說更具挑戰性。目前，對於字段選擇器機制的實際效益以及如何使用的設計分析並不多。因此，我們將不再進一步討論它。

OP_CAT

連接運算子，將堆疊中的頂部兩個元素連接在一起，並將連接結果推回堆疊。比特幣最初啟用了OP_CAT。但 Satoshi 2010年悄悄移除了它可能是因為初始實現容易遭受DoS攻擊，因為生成的腳本元素沒有大小限制。請考慮以下腳本:

DUP CAT DUP CAT…

沒有元素大小限制，每個DUP CAT迭代都會將頂部堆棧元素的大小加倍，最終使用完所有可用內存。

通過串聯可以實現許多類型的契約，包括遞歸契約，具體操作如下：

1. 在堆疊上組裝一個部分交易，不包括見證數據，並進行一次或多次 OP_CAT 的調用（以及所需的任何契約特定邏輯）。
2. 驗證堆疊上的交易是否與支出交易相符。

結果，由於濫用Schnorr簽名的數學通過精心構造的簽名，可以使用OP_CheckSig執行第二步驟。 但更有可能的是，OP_CAT軟分叉將與OP_CheckSigFromStack結合，從而允許通過驗證堆棧上的簽名是否為交易的有效簽名來執行第二步驟。¹⁹，然後重複使用相同的簽名與OP_CheckSig驗證支出交易是否符合。²⁰

我們只需要組裝交易而無需證人數據這一事實是關鍵:契約只需驗證交易所做的事情 — 其輸入和輸出 — 而不是證人數據(如果有的話)。

在模塊腳本大小限制下，OP_CAT和OP_CheckSigFromStack的結合足以構建許多類型的契約，包括遞歸契約。與CTV等更高效的解決方案相比，它更昂貴。但成本差異比您預期的要小！

大致而言，使用OP_CAT來進行這個操作需要將所有非見證部分的消費交易通過見證放置在堆疊上。對於典型的CTV用例，例如txout樹，消費交易將完全沒有見證數據。由於見證空間享有75%的折扣，這只會將子交易的實際交易費用增加25%。還不錯！

OP_CAT太強大了嗎？

這可能是部署OP_CAT的最大政治和技術障礙：很難預測OP_CAT將可能實現哪些用例。而當“貓”被放出來後，很難再把它放回去。

一個很好的例子是，OP_CAT據稱足以允許相當有效和安全在比特幣腳本中實現STARK驗證. 由於STARKs能夠證明非常普遍的陳述，使得能夠有效實現STARKs具有重要的影響，不僅僅局限於L2系統，因為這將使得許多不同的系統能夠建立在比特幣之上。支持不使用OP_CAT的一個強有力的論點是，這些應用可能對比特幣用戶整體上並不好。

有害的集中式矿工可提取价值的创造是一个重要的潜在问题。稱為“MEV邪惡”（MEVil）由Matt Corallo提出。簡而言之，MEVil是指大型礦工/礦池通過使用複雜的交易挖礦策略（超出僅僅最大化總手續費的範疇），能夠提取額外價值的任何情況，這對於小型礦工/礦池來說是不可行的。使用OP_CAT可能創建的潛在金融工具的複雜性使得排除MEVil變得非常困難。在比特幣上已經出現了顯著的MEVil，來自令牌拍賣協議；幸運的是，通過全面採用RBF，這一特定案例被擊敗了。

除了 MEVil 的潛在潛力外，還有許多其他具體的 OP_CAT 應用案例可能是有害的。例如，Drivechains 提案已經 在這裡審查，並被廣泛認為對比特幣有害。相信是可能的使用OP_CAT實現Drivechain的一個例子。另一個例子是代幣提案，例如Taproot Assets。雖然一般情況下無法阻止它們被實現，但是...用戶端驗證同時，有提議使用OP_CAT的方式來實現這些功能，這些方式對終端用戶更具吸引力，同時使用更多的區塊空間，這可能會將“合法”比特幣交易的出價超過。這些用例可能還會引發法律問題，因為令牌協議在金融詐騙中的使用頻率很高。

增量哈希

對於契約，OP_CAT將主要用於連接數據，然後對其進行哈希處理。實現同一目標的另一種方法是使用某種增量散列操作碼，該操作碼採用某種SHA256中間狀態，並將更多數據散列到其中;SHA256 本身在 64 位元組塊上運行。增量散列操作碼有許多可能的設計。

一個重要的設計決定是是否要以某種規範形式在堆棧上暴露實際的中間狀態位元組，或者以某種新的不透明堆棧項目類型來表示它們，其實際位元組值不能直接操作。 SHA256被指定為特定的固定初始化向量，並且目前尚不清楚是否允許任意中間狀態/初始化向量時，SHA256的加密特性是否成立。

當然，由於增量哈希幾乎可以做到OP_CAT可以做的事情，只是效率更高，因此它與OP_CAT過於強大的所有擔憂都是共享的。

腳本復興

OP_CAT 是薩托希禁用的 15 個操作碼之一。除了恢復 OP_CAT 之外，Rusty Russell 提出了²¹以軟分叉的方式，將比特幣的腳本基本恢復到“中本聰的原始視覺”，重新啟用大部分那些操作碼，添加DoS限制，並可能在同一個軟分叉中添加幾個更多的操作碼。特別是，OP_CheckSigFromStack很可能會被添加。

雖然僅僅使用OP_CAT就可以實現（遞歸）契約，但完整的“腳本復蘇”將使更複雜的契約成為可能 - 並且更容易實施 - 因為可以直接操作交易中的部分支出事務。例如，您可以想像一個契約腳本，使用算術操作碼確保交易中的txouts的總值符合某些期望的屬性。

再次，腳本復興引起了所有相同的擔憂，更多的是對於過度強大的擔憂，只有OP_CAT是不夠的。

簡約

与Script Revival类似，Simplicity与L2和契约有关，使其能够做任何事情。与Script Revival不同，Simplicity软分叉将基于九个原始运算符（称为组合子）添加全新的编程语言到比特币的脚本系统中。

在實踐中，簡潔既過於簡單，又並非簡單。原始組合子非常低級，以至於基本操作，如加法，必須從頭開始繁瑣地實現；在實踐中，原始的簡潔會非常冗長。因此，任何對簡潔的實際使用都會使用一個代碼替換系統，類似於庫函數調用，稱為 噴射機這帶來了一個實際/政治問題：如何決定實施哪些jet？最有可能的是jet將以C++實施，就像任何其他opcode一樣，每個新jet都需要進行軟分叉。

OP_FancyTreeManipulationStuff

有許多相對專門的操作碼被提出，以節省空間的方式進行樹操作，以滿足相依的L2提案。例如，Coinpools提出了TAPLEAF_UPDATE_VERIFY和OP_MERKLESUB都以在Coinpools提案中必需的方式操作taproot樹的方式來操作，而MATT提案提出了一個名為OP_CheckContractVerify的操作碼，基本上用於驗證關於默克爾樹的陳述。

對於本文而言，我們不需要詳細介紹這些提案中的每一個。相反，我們可以將它們作為一組來討論：它們都是相對於特定用例的提案，可以使一類L2成為可能，理想情況下不會產生意外的副作用。它們都具有效率的優勢：它們都比使用更通用的操作碼（如OP_CAT操作）實現相同目標使用更少的塊空間。但它們都有增加腳本系統複雜性的缺點，僅適用於潛在的利基用例。

如果比特幣採用了Simplicity腳本系統，同樣的動態也會發生。在Simplicity中，與操作碼相對應的是為常用模式添加噴射器。同樣地，為像樹操作這樣的用例特定操作實現噴射器與實現複雜操作碼的用例特定操作具有相似的優點和缺點。

基金池

所有試圖讓多個用戶共用一個UTXO的L2系統都可以被認為是某種多用戶資金池，用戶擁有某種提款權。潛在地，還將有一種向資金池添加資金的機制（除了使用預先分配的資金創建資金池之外）。

對於一個基金池來說，它必須與某種“共享數據狀態”相關聯：資金如何分配？如果基金池要隨著時間的推移而發展，這種狀態也必須隨著資金的增減而變化。由於我們是在比特幣上進行構建，從基金池中添加或移除資金必然涉及到使用池子控制的UTXO。

請記住，比特幣共識系統本身是基於狀態變更的驗證：交易通過其證人證明UTXO集狀態的更改是有效的；工作量證明讓我們就正確的交易集達成共識。這意味著基金池本身也將基於狀態變更的驗證：我們向每個比特幣節點證明基金池的規則在每次狀態變更時都在遵循。

但是信任less L2基金池的另一个关键方面是：当基金池的状态发生变化时，系统必须固有地发布足够的数据，以便参与基金池的用户恢复他们的资金。如果我们没有这样做，那么我们的系统就无法提供单方面的撤回，而无需第三方的合作。许多基于Rollup的方案在这里失败：它们遭受数据可用性故障，用户无法在第三方协调员离线时恢复他们的资金，因为他们无法获得构建有效基金恢复交易所需的数据。

考慮到這些限制，基金池將基於哪些數據結構？無可避免地，它們都是某種樹結構。具體來說，是某種默克爾樹。它們必須是樹狀結構，因為這幾乎是計算機科學中唯一可擴展的數據結構；它們必須是默克爾化的，因為這基本上是對樹狀結構的狀態進行加密承諾的唯一合理方式。最後，對樹狀結構的更新將不可避免地發佈到比特幣區塊鏈上，因為這是唯一合理的方式。發布媒介所有L2使用者分享，也是我們唯一能強制使用者發佈以移動貨幣的地方。由於任何契約實施都需要樹的部分來驗證契約的規則是否被遵循。

所以，高層次理論搞定後，這實際上如何轉化為比特幣腳本和交易呢？

單個預先簽署的交易

樹的退化情況，只有一片葉子。在這裡，我們的資金池狀態可以大致地說只有一次變化。例如，標準的閃電通道屬於此類型，一旦開啟，就只能關閉。當通道關閉時發布的數據是交易本身，這足以讓通道中的對方從區塊鏈數據中了解交易id，並通過花費這些資金來恢復他們的資金。

這裡唯一需要的“契約”是最基本的契約：預先簽署的交易。

Txout樹

在基金池中，我们看到的下一个更复杂的设计模式是txout tree。Ark是一个显著的例子。在这里，基金池可以通过花费根UTXO在预定义交易的树中进行分割，通过简单的契约（如预签名交易或CTV）强制执行，将该UTXO的价值分割成越来越小的金额，直到达到可由合法所有者支配的叶节点。

重要的是要認識到，txout樹的目的是為了給用戶選擇恢復資金的方式，而這些選擇是有成本的：txout樹將始終是一種更昂貴的方式來分割資金池，將其返回給其所有者，而不僅僅是在單個交易中分割UTXO。樹中的每一層都會增加成本，因為需要在txouts和txins中使用的字節來創建該層。

那麼，txout tree 可以提供哪些選項？再次以 Ark 為例：我們不希望單個 V-UTXO 的鏈上贖回需要將每個 V-UTXO 都放在鏈上。通過使用樹狀結構，贖回可以將樹狀結構分割成更小的部分，直到所需的 V-UTXO 放在鏈上。

與個別預簽交易案例類似，正在發布的信息是交易本身，這些信息告訴其他用戶的錢包如何在必要時花費他們的資金。

txout 樹的可擴充性具有有趣的規模經濟。在具有n 個V-UTXO的基金池中，第一個V-UTXO上鏈的成本大約是單個交易的log2（n）log2（n）倍，因為log2（n）級別的拆分交易必須放在鏈上。然而，一旦第一個V-UTXO被放在鏈上，後續的V-UTXO在鏈上贖回的成本就會降低，因為其他人已經支付了開採仲介交易的成本。

回想一下，二叉樹中的元素總數

n片葉子是2n。這意味著要將所有V-UTXO放在鏈上，通過txout樹這樣做的總成本將是通過單個交易這樣做的總成本的一個小的倍數。出奇地高效！

也可能不是...如果基金池赎回的总规模足够大，它们可能对整体区块空间需求产生重大影响。区块空间是一个供需系统，所以在某个点上，由于需求量过高，费用会上涨。在极端情况下，可以创建如此庞大和深入的txout树，以至于实际上无法完全赎回每一个

樹中的V-UTXO是不可能的。

txout 樹的一個懸而未決的問題是，誰支付費用，以及如何支付？一個明顯的解決方案是在葉交易中使用無鍵錨輸出，並允許任何希望葉交易被挖掘的人通過 CPFP 支付費用。在某些用例中，V-UTXO本身可以在創建后立即花費，沒有CSV延遲，因此V-UTXO本身可以通過CPFP增加費用。

由於權限的問題，實現RBF是復雜的：從V-UTXO值中收取RBF費用的明顯方式是如何確保只有所有者有能力為更高的費用進行簽名的問題？在許多情況下，這並不明顯該如何以比無密鑰錨輸出更高效的方式來解決此問題。然而，如果V-UTXO本身不能立即被花費，則未能解決此問題將對終端用戶錢包使用的方案構成嚴重挑戰，因為它們可能沒有UTXO可以用於執行CPFP操作。

最後，需要仔細考慮txout樹系統中有哪些激勵措施，同時考慮到費用支付。例如，在類似方舟的系統中，如果一組 V-UTXO 單獨花費太多錢而不值得帶到鏈上 V-UTXO，則不合作的協調員可能會拒絕允許這些 V-UTXO 在鏈下贖回，然後在達到超時后通過在單個 UTXO 支出中竊取這些 V-UTXO 的價值來獲利。

如果是這樣的話，可以說這樣的系統將無法滿足我們的標準，成為小型V-UTXO的L2。

基於餘額的方案

txout 樹的狀態機仍然相對簡單：要麼資金池存在，要麼花費資金池來創建兩個或多個較小的資金池。有了更高級的契約，我們可以將資金池視為一個不斷發展的餘額，能夠從該餘額中增加和減少資金。

要实现这一点，我们需要实现一个非平凡的状态机。但我们还需要一个本质上是共享数据库的东西。为什么？因为这里的目标是在许多不同的所有者之间共享一个UTXO。最后，如果我们真的要获得可扩展性的提升，我们必须以尽可能少地将那些所有权数据放在链上的方式来实现。

這些要求本質上導致我們使用某種類似樹狀的默克爾化數據結構，例如默克爾和樹總和。操作該數據結構本質上需要類似OP_CAT的操作碼，某種零知識證明驗證操作碼，或者一個特定目的的樹操作操作碼。

有趣的是，就像在txout樹中一樣，您在保持類似安全屬性的同時，無法做得比秩序log(n)更好。為什麼？假設我們有一個假想的OP_ZKP，通過一些高級數學，只需32字節就可以證明任何語句。儘管這個zk-proof可以證明merkelized數據結構已根據第二層系統的規則進行了操作，但它無法提供下一個用戶所需的數據，以便其也可以進行狀態更改。這不符合我們希望的無條件提款標準：最多只能有一個用戶能夠實現無條件提款。但是沒有進一步的用戶能夠這樣做。

相比之下，如果Merkle化數據結構的修改部分是通過契約腳本（例如Merkle樹中的兄弟摘要）發布的，則下一個用戶將有足夠的數據來更新他們對系統狀態的理解，並且自行進行無條件提款。

繞過這個問題的一種潛在方法是，如果契約要求在比特幣鏈之外的其他出版媒體上證明發布。然而，安全保證會比通過比特幣實現的保證要弱。

最後，請注意如何結合txout樹和基於餘額的方法。如果正在操作的數據結構是txout樹，可以通過花費輸出並添加新資金將資金添加到txout樹中，並使用驗證這些資金確實已添加到txout樹中的契約腳本。同樣，資金可以通過所有對txout樹通常可用的機制進行刪除。進階Ark是這類方案的一個例子。

損毀資料比率

L2通過在對抗情況下增加交互性要求來實現擴展。幾乎在所有情況下，這意味著協議中的誠實方需要在截止日期前挖掘交易；如果未能達到截止日期，資金可能會被盜。

所有去中心化（和中心化）區塊鏈的最大區塊容量都受到技術限制。在比特幣中，最大區塊大小設定為幾乎始終運行在容量的100％左右。由於比特幣挖礦行為類似於拍賣系統，將區塊空間拍賣給出價最高的投標者，實際上這意味著隨著需求的增加和減少，使得交易被挖掘的最低費率會上下波動。

費率始終是L2經濟和失敗模式的因素。例如，在閃電網絡中，“塵埃大小”的HTLCs太小，無法在鏈上有利可圖地贖回，因此使用了不同的安全模型。儘管閃電協議尚未正確實現此功能，但理論上此門檻應根據費率的上升和下降而動態變化，最理想的情況是，一方可以根據費率選擇是否在特定承諾交易中存在HTLC。

已经有多种攻击方法被提出，其中包括洪水和掠夺，这些攻击会故意在闪电网络上触发此类情况。²²和大规模退出攻击²³.由於比特幣區塊鏈的容量是共享的，因此不同的L2系統之間也可能發生攻擊：例如觸發Ark的大規模退出以從閃電通道中獲利。

在多個用戶之間共用UTXO的L2本質上會使這些問題變得更糟，因為故障期間最壞情況下的塊空間需求成比例地更高。在撰寫本文時，我們從未真正在閃電網路上看到過必須同時關閉大量通道的大規模故障。有一個很好的論點是，在使用UTXO共用方案進一步突破極限之前，我們應該獲得閃電網路及其每個用戶大約1-UTXO擴展的額外操作經驗。

其次，在廣泛採用新的UTXO共享方案之前，應對在對區塊空間需求高峰期進行攻擊的潛在盈利能力進行仔細研究。例如，在像Ark這樣的系統中，ASP可以使用比其他方面少得多的區塊空間贖回資金，有可能有意觸發高手續費率，然後奪取無法單方面有利可圖地撤回的資金，這是一種有利可圖的詐騙行為，違反了我們對真正L2系統的條件。

共識清理

在最初的比特幣協議中，有一些事情是Satoshi在技術上搞錯了的，特別是腳本DoS攻擊、時光隧道攻擊和默克爾樹的問題。此前，已經通過軟分叉修復了許多其他共識錯誤，例如切換到根據過去中位數時間評估基於時間的nLockTime、（試圖）修復重複的交易ID問題等。

最新的軟分叉taproot有一個相對有爭議的部署過程，需要相當長的時間才能真正部署。在為新型L2啟用任何新的操作碼或其他功能之前，首先進行共識清理軟分叉的一個論點是，我們將更多地瞭解更廣泛的社區有多願意實施一個相對無爭議的軟分叉，可以說是每個人都受益。

測試軟分叉依賴的L2

開發人員不需要等待軟分叉實際發生來測試他們的想法。方舟開發人員正在使用的一種特別複雜的方法無約束的方舟是為了模擬他們需要的契約與預簽交易。這使他們能夠在主網上用真正的比特幣測試 Ark 的想法，並具有與契約預期實現的相同信任特性。其中的折衷是無契約的 Ark 需要所有方在線簽署預先簽署的交易。由於 clArk 確實可以與真正的比特幣一起工作，它甚至可能證明對於某些可以容忍互動折衷的生產用途轉移是足夠有用的。

一種更簡單的方法是簡單地假裝某些各方不能做契約會阻止的行動。例如，如果提議的協定想要使用CTV來強制txout樹用於事務樹，則每次使用CTV都可以替換為NOP或CheckSig。雖然實際上txout樹實際上並沒有被強制執行，但與樹和每一方交互的每一位代碼都可以像測試一樣進行測試，並且由於標準腳本中允許NOP和CheckSig，因此該協定可以用真實資金在主網上進行測試。

潛在的軟分叉

前進的道路是什麼？在這裡，我們將列出我們分析的所有主要L2方案，以及哪些軟分叉是有用的（U）或必需的（R）使這些L2方案成功。如上所述，OP_CAT（以及相應的Script Revival，包括OP_CAT）可以模擬此列表中所有其他軟分叉，但不包括OP_Expire和Fee Sponsorship，因此如果項目的需求可以通過其他軟分叉直接有效地滿足，我們將不包括OP_CAT。

我們還將放棄所有提議的默克爾樹操作碼。它們都太專門化，太特定於使用案例，以至於在這個時候有很大的機會被採用。在某種程度上，這些操作碼的用途是有用的，通過OP_CAT和/或Script Revival實現它們的效果更有可能被採用。

CTV是這裡的明顯贏家，其次是SIGHASH_ANYPREVOUT（OP_Expire通過替代自行車修復對許多事情都很有用，但不是必需的）。CTV之所以獲勝，是因為很多東西都符合「確保支出交易與此範本匹配」的設計模式;即使是OP_CAT結構也可以有效地利用CTV。

與OP_CAT不同，CTV除了在某些情況下鼓勵帶外費用支付外，似乎不會帶來太大的意外後果風險。這並不理想。但是沒有人提出一個得到廣泛支援的替代方案。

我的個人建議：進行共識清理軟分叉，然後是 CTV。

免責聲明：

1. 本文轉載自[彼得托德], 轉發原標題‘以太坊路線圖是否偏離軌道？’，所有版權屬於原作者[petertodd]。如果有對此轉載有異議，請聯繫Gate 學習團隊，他們會及時處理。

2. 免責聲明：本文所表達的觀點和意見僅代表作者本人，並不構成任何投資建議。

3. Gate Learn 團隊負責將文章翻譯成其他語言。未經許可，禁止複製、散佈或剽竊翻譯後的文章。