HashKey Capital的Jeffrey HU和Harper LI討論了比特幣社群對重新啟用OP_CAT等操作碼的熱議，以及透過推出Quantum Cats的NFT和獲得BIP-420編號來吸引關注。支持者實現了利用OP_CAT實現契約、比特幣智能合約或可調度性。討論了限制條款的技術應用，例如在比特幣質押中的使用、擁塞控制、保管庫等。介紹了關於OP_CTV、APO、OP_VAULT等技術實現限制條款。最後，探討了限制條款技術的設計概念、實現方式，以及未來在比特幣網路中的應用。 OP_CAT和OP_CTV等實現限制條款的技術在比特幣應用上具有重要意義。
作者：HashKey Capital 投資研究主管Jeffrey HU、HashKey Capital 投資經理Harper LI
比特幣社群裡掀起一波關於重新啟用OP_CAT 等操作碼的討論。 Taproot Wizard 也透過推出Quantum Cats 的NFT、聲稱已經獲得BIP-420 的編號等，吸引了令人驚嘆的人們的注意。支持者由此，實現了OP_CAT 可以實現「限制條款」（契約）、實現比特幣的智慧合約或機動性。
如果你注意到“限制條款”這個詞並稍作搜索，你會發現這是另一個很大的兔子洞。開發人員已經討論了很多年，除了OP_CAT 之外，還有OP_CTV、APO、OP_VAULT 等等實現限制條款的技術。
到底什麼是比特幣的「限制條款」？為什麼能夠吸引如此多的開發人員持續數年的關注和討論？能夠實現比特幣的哪些預防性？當今背後的設計原理所關注的？嘗試做一個概述性的介紹和討論。
什麼是「限制條款」
契約，英文譯為“限制條款”，有時也翻譯為“契約”，是一種能夠給予未來的比特幣交易設定條件的機制。
目前的比特幣腳本也包含了限制的條件，例如佔用的時候要輸入合法的簽名、發送符合腳本的等。但只要使用者能解鎖，就可以將UTXO 花到他想要的任何地方。
限制條款是，在此限制如何解鎖的基礎之上，做出更多的限制，例如限制UTXO之後的支出，才能實現類似“專款專用”的效果；或要求交易中送入的其他條件輸入等。
嚴格來說，目前的比特幣腳本也具備一定的條款，例如基於操作碼的時間鎖定，就是透過內部省份交易的nLock 或nSequence 欄位來實現交易佔用之前的時間限制，但也基本上僅限於時間方面的限制。
那麼，開發和研究人員為什麼要設計這些限制檢查？因為條款不只是為了限製而限制，更是設定了交易執行的規則。這樣，使用者就只能依照預先設定的規則來執行交易，從而完成預定的業務流程。
所以相對反直覺的是，這可以解鎖更多應用程式場景。
應用場景
確保Stake 的懲罰
限制條款的一個最引人注目的例子是Babylon在比特幣質押流程中的斜線交易。
Babylon 的比特幣質押過程是用戶將自己的BTC 資產在主鏈上發送到一個特殊的腳本中，佔用條件包括以下兩種：美好結局：經過一定的時間後，用戶用自己的簽名即可解鎖，即完成解鎖的過程
壞結局：如果用戶在某個被Babylon租借安全性的PoS鏈上有雙簽等作惡行為，那麼透過EOTS（extractable one-time簽名，一次性可提取簽名），可以解鎖出這部分資產，並由網路中的執行角色將部分資產強制發送到銷毀位址（斜線）
來源：比特幣質押：解鎖2,100 萬比特幣以確保權益證明經濟
注意這裡的“強制發送”，這意味著甚至是解鎖可以解鎖UTXO，但該資產不能任意地發送到其他任何地方，只能燒掉。這樣才能確保作惡的用戶無法先用自己已知的簽名搶奪把資產轉回給自己，以逃脫懲罰。
此功能如果在OP_CTV 等限制條款實現後，可以在stake 腳本的「badending」分支中增加OP_CTV 等操作碼以實現限制。
而在OP_CTV 啟用之前，Babylon 就需要透過變通的方法，由使用者+委員會共同執行的方式來模擬實現限制條款強制執行的效果。
擁塞控制
一般而言，累積流量是指當比特幣網路上的手續費率很高，交易礦池中累積了比較多的交易等待資源，所以如果用戶想要快速確認交易，就需要提高手續費。
而此時如果一個使用者必須發送多筆交易給多個收款方，就得提高手續費，承擔比較高的成本。同時也相應的會進一步推高整個網路的手續費率。
如果有限制條款，一個解決方法是發送方，可以先承諾到批量發送的交易上。這個承諾可以讓所有的接收者相信，最終的交易都會進行，可以等到手續費率低的時候再進行發送具體的交易即可。
如下圖所示，當對區塊空間的需求非常小時，進行交易變得非常昂貴。透過使用OP_CHECKTEMPLATEVERIFY，大規模支付處理商可以將其所有付款聚合到單一O（1） 事務中以進行確認。然後，一段時間後，當對區塊空間的需求減少時，付款可以從該UTXO 中擴展出來。
資料來源：https://utxos.org/uses/scaling/
這個場景是OP_CTV 這個限制條款所提出的比較典型的一個應用案例。還有更多的應用案例可以從https://utxos.org/uses/ 找到，除了上述阻塞控制，該網頁列舉了軟分叉質押、去中心化選項、驅動鏈、批量通道、非交互通道、去信任的免協調礦池、金庫、更安全的哈希時間鎖定合約（HTLCS）限制等。
保管庫
保管庫（金庫）是比特幣應用程式中一類比較廣泛討論的應用場景，特別是在限制條款領域內。因為日常操作首先是要在資金保管與資金使用需求之間進行平衡，所以人們希望能能夠有一類保管金庫的應用：可以保證資金安全，甚至即使帳戶被駭（洩漏了私鑰），也能限制資金的使用。
基於實現限制條款的技術，保管類的應用可以比較容易建構出來。
以OP_VAULT 的設計方案為例：在佔用保管庫中的資金時，需要先發送一筆交易上鍊。此時交易表明了希望佔用庫中的意圖，即「觸發」，並在其中設定了條件：
如果一切正常，那麼第二筆交易是最終的交易。等待N個區塊後，可以將資金進一步消耗到任意地方如果發現近期交易被竊取的（或者是被“鬧鐘攻擊”時臨近的），在N 個區塊的付款交易發送前，可以立即發送到另一個安全地址（用戶更安全的保管）
OP_VAULT 的流程，來源：BIP-345
要注意的是，在沒有限制條款的情況下，也可以建構出來一個保管庫應用，一個可行的辦法是用私鑰來準備好以後佔用的簽名，然後召回掉這個私鑰。但限制仍然比較多，例如需要確保這個私鑰已經介入（類似於零知識證明中的可信設定過程）、金額和手續費提前確定（因為要預簽名）因而缺乏靈活性等。
OP_VAULT與預簽名式的保管庫流程對比，來源：BIP-345
更健壯、靈活的狀態通道
一般可以，包括閃電網路擁有的狀態通道和主鏈近乎後續的安全性（在保證節點可觀察最新狀態、能夠正常發布最新狀態上鍊的情況下）。但是在有了限制條款之後，一些新的狀態通道的設計理念可以在閃電網路之上更加健壯或靈活。其中較知名的包括Eltoo、Ark等。
Eltoo（也稱為LN-Symmetry）就是其中一個比較典型的例子。這個技術方案取「L2」的諧音，為閃電網路提出了執行層，允許任何後續的通道狀態取代之前的狀態，而不是需要懲罰機制，因此也可以同時避免類似閃電網路那種必須保存多個之前狀態以防止對手作惡。為了達到上述效果， Eltoo 提出了SIGHASH_NOINPUT 的簽章方式，即APO（BIP-118）。
而方舟則旨在降低閃電網路的入站流動性和通道管理等入口。它是一種加入礦池形式的協議，多個用戶都可以在一定時間內接受一個服務作為交易對手，在鏈外進行虛擬UTXO（vUTXO）的交易，但在鏈上共享一個UTXO 從而降低成本。和保管庫類似，Ark 也可以在當前的比特幣網路上實現；但引入限制條款之後，Ark 可以基於交易模板降低所需的交互量，實現更多去信任化的單邊退出。
限制條款技術概述
從應用中可以看到，限制條款形成了一種上述效果而非某種技術，有多種實現的技術方式。如果進行分類，可以包括：
類型：通用型、專用型實作方式：基於Opcode、基於簽章下跌：下跌、非下跌
而其中，下跌是指：有一些限制條款的實現，也可以透過限制下筆輸入來限制再下筆的輸出，可以實現添加的限制可以超越筆交易，達到更高的交易深度。
一些主流的限制條款設計包括：
* 梯度：如果結合OP_CAT
限制條款的設計
從前面的介紹可以看出，目前的比特幣腳本限制了解鎖的條件，沒有限制該UTXO 如何進一步被佔用。要實現限制條款，我們就要反過來思考：為什麼目前的比特幣腳本無法實現限制條款？
主要原因是目前的比特幣腳本無法讀取交易本身的內容，即交易的「內省」（內省）。
如果我們可以實現交易的內省——檢查交易的任何內容（包括輸出），那麼就可以實現限制條款了。
因此限制條款的設計想法也主要圍繞在如何實現內部省。
基於操作碼與基於簽名
最簡單粗暴的想法是，增加一個或多個操作碼（即一個操作碼+多種參數，或多個不同功能的操作碼），直接讀取交易的內容。這個基於操作碼的想法。
而另一個想法是，可以不用腳本中直接讀取和檢查交易本身的內容，而是可以利用交易內容的哈希——如果已經對這個哈希進行了簽名，那麼只需在腳本裡修改例如OP_CHECKSIG等來實現對這個簽章的檢查，就可以間接的實現交易內省及限制條款了。這個思路是基於簽名的設計方式。主要包括APO 及OP_CSFS 等。
載脂蛋白
SIGHASH_ANYPREVOUT（APO）是提案中的一種比特幣簽名方式。簽名的最簡單的方式是對交易的輸入輸出都承諾，但比特幣還有更靈活的方式，即SIGHASH，撥號地對簽名交易中的輸入或輸出進行承諾。
目前SIGHASH及其組合對交易輸入輸出的簽名範圍（來源《掌握比特幣第二期》
如上圖所示，除適用於所有資料的ALL 之外，NONE 的簽署方式僅適用於所有輸入，而不用於輸出；SINGLE 是在此基礎上，僅適用於相同輸入序號的輸出。另外， SIGHASH 還可以組合，增加了ANYONECANPAY 修飾符後，只適用於記帳輸入。
而APO 的SIGHASH 只對簽章輸出，而不是對輸入部分簽章。這意味著，用APO 方式簽署之後的交易，可以在之後附加到任何一個符合條件的UTXO 上。
這種靈活性是APO 實現限制條款的理論基礎：
可以預先建立報表筆交易透過這些交易的資訊建構出一個只能求出一個簽署的公鑰這樣任何發送到該全球地址上的資產都只能透過預先建立的交易來消耗
意義在於，因為這個預設沒有對應的私鑰，所以可以確保這些資產只能透過預先建立的交易來消耗。那麼，我們就可以在預先建立的這些交易中規定資產的去向，從而實現限制條款。
我們可以進一步透過比較以太坊的智慧合約來理解：透過智慧合約我們可以實現的也只有透過一定的條件，才能從合約地址中，而不是靠一個EOA簽名就可以了。從這一點來說，比特幣透過簽名機制的改進就可以實現這種效果。
但上述過程中的問題在於計算時存在循環依賴，因為需要知道輸入的內容來預簽並建立交易。
APO 以及SIGHASH_NOINPUT 實作這種簽章方式的意義在於可以解決這種循環依賴問題，在計算時只需要知道（指定）交易的全部輸出即可。
OP_CTV
OP_CHECKTEMPLATEVERIFY （CTV） ，即BIP-119 ，採用了改進Opcode 的方式。將承諾雜湊作為參數，並要求任何執行操作碼的交易都包含一組與該承諾相符的輸出。透過CTV，將允許比特幣用戶限制他們使用比特幣的方式。
該提案最初以OP_CHECKOUTPUTSHASHVERIFY （COSHV）的名義推出，並且早期關注於創建擁塞控制交易的能力，因此該提議的批評也中心化在該方案不夠通用、完全具體針對擁塞控制例子。
在前面提到的阻塞控制範例中，發送者Alice 可以建立10 個編輯器，這10 個編輯器進行哈希，並使用產生的摘要來建立一個包含COSHV 的Tapleaf 腳本。 Alice 還可以使用參與者的芭來形成了Taproot 內部金鑰，以允許他們在不洩露Taproot 腳本的情況下花費開支。
然後，Alice 會給每個接收者一份所有10 個輸出的副本，以便他們每個人都驗證Alice 的設定交易。當他們以後想要花上一筆付款時，他們可以在其中的任何一個都創建一個包含的副本承諾輸出的交易。
在整個過程中，在Alice 建立並傳送設定交易時，Alice 可以透過現有的非同步通訊方法（例如電子郵件或雲端硬碟）發送這10 個列印副本。這意味著，接收者不需要在線，也不需要需要相互交易所。
來源：https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
和APO類似，地址也可以根據開支條件來構建，可以用不同的方式來製作“鎖”，包括：增加其他的密鑰、時間鎖、可組合邏輯。
來源：https://twitter.com/OwenKemeys/status/1741575353716326835
CTV在此基礎上提出了可以檢查經過哈希後的花費交易是否與定義的匹配，即將交易資料作為開「鎖」的關鍵。
我們可以將上面10個接收方的例子繼續延伸，接收方可進一步將其位址金鑰設定為已簽署但未廣播的tx發送給下一個接收方位址，以此類推，形成如下圖所示的樹狀結構。 Alice在鏈上只用1個utxo的塊空間就可以建構一個涉及多個用戶的帳戶餘額變更。
來源：https://twitter.com/OwenKemeys/status/1741575353716326835
而如果其中一個葉子是閃電通道、是冷藏、是其他行走路徑呢？那麼這棵樹密度單維度的支出樹擴展至多維多層的支出樹，能支援的場景將更加豐富和靈活。
來源：https://twitter.com/OwenKemeys/status/1744181234417140076
CTV 自提出以來，經歷了2019 年從COSHV 更名、在2020 年被分配了BIP-119，並出現用於支持CTV 合約的編程語言Sapio，在22、23 年得到了很多社區討論、更新，以及此次激活方案的爭論，目前仍是社區討論較多的一個軟分叉升級提案之一。
OP_CAT
OP_CAT 如本文所介紹的，也是一個目前非常受關注的升級提案，實現對堆疊中的兩個元素進行拼接（concatenante）的功能。雖然看起來很簡單，但OP_CAT 可以很靈活的在腳本中實現很多功能。
最直接的例子就是與merkle 樹相關的操作。 Merkle 樹可以理解為兩個元素先拼接，然後再進行雜湊。目前比特幣腳本裡有OP_SHA256 等哈希的操作碼，所以如果能用OP_CAT 實作對兩個元素編輯，就可以在腳本中實現merkle樹的驗證功能，在一定程度上具備了輕客戶端驗證的能力。
另外的實現基礎還包括針對Schnorr 簽名的增強：可以為腳本的佔用簽名條件設定為用戶的共享和公開隨機數的裁剪；此後如果簽名者想要另外簽一筆交易將節省資金佔用到其他地方，就不得不使用同樣的nonce而導致私鑰外洩。清楚透過OP_CAT實現了對nonce的承諾，進一步確保已簽署交易的有效性。
OP_CAT 的其他應用場景還包括：Bistream、樹形簽名、抗量子的Lamport 簽名、保管庫等。
OP_CAT 本身並不是一個新的功能，它曾在比特幣最早版本中存在過，不過可能由於導致被攻擊所利用而在2010 年開始被禁用。例如，重複使用OP_DUP 和OP_CAT 就可以輕鬆的讓全部節點在處理此類腳本時爆炸，請參考這個示範。
但現在重新啟用OP_CAT 不會發生前面提到的堆疊爆炸問題麼？因為目前的OP_CAT 提議只涉及在tapscript 中啟用，而tapscript 限定了每個堆疊元素不超過520 字節，所以不會產生先前的堆疊爆炸問題。還有一些開發者認為中本聰直接取消OP_CAT可能過度一些嚴苛。但由於OP_CAT的靈活性，可能確實會導致漏洞的應用場景在目前無法窮盡。
所以綜合了應用場景和潛在風險等，OP_CAT 受到了很多關注，也有最近的PR 審核，是目前最熱門的升級建議之一。
結語
「自律帶來自由」，從上面的介紹可以看到，條款可以直接在比特幣腳本中實現對交易進一步支出的限制，從而實現類似智能合約效果的交易規則。相較於BitVM 等鏈外方式，這種刷單方式可以在比特幣上進行更初步的驗證，同時也可以改善主鏈上的應用（擁塞控制）、鏈外應用（狀態通道）以及其他的新的應用方向（質押懲罰等）。
限制條款的實現技術如果能再結合一些底層的升級，會進一步釋放興奮性的潛力。例如，最近在回顧中結合的64個激勵的提議，就可以進一步位與引發的OP_TLUV 或其他的限制條款，可以根據交易輸出的聰的數量來進行編程。
但限制條款也可能導致一些計劃外的打擾或漏洞，因此社區也比較穩定。另外，限制條款的升級也需要涉及共識規則的軟分叉升級。由此主幹升級時的那麼，條款相關的升級可能也需要假以時日才能完成。
感謝阿劍、Fisher、Ben對本文的審閱與建議
參考資料
https://utxos.org/
https://bitcoincovenants.com/
與契約相關的資源集合：https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
https://anyprevout.xyz/
BIP 345：OP_VAULT 提案：https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
https://maltemoeser.de/paper/covenants.pdf
https://bitcoinops.org/en/topics/op_cat/
OP_CAT：https://github.com/bitcoin-inquisition/binana/blob/master/2024/
BIN-2024-0001.mdCAT 與Schnorr 技巧：https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
資訊來源：0x資訊編譯自網際網路。版權歸作者HashKey Capital所有，未經許可，不得轉載