詳解Covenants：如何實現比特幣的可程式性？

HashKey Capital ｜2024-05-20 13:30

限制条款（covenants）可以直接在比特币脚本中实现对交易进一步花费的限定，从而实现类似智能合约效果的交易规则。

作者：HashKey Capital Head of Investment Research Jeffrey HU、HashKey Capital Investment Manager Harper LI

近期比特幣社群裡掀起來一波關於重新啟用OP_CAT 等操作碼的討論。 Taproot Wizard 也透過推出Quantum Cats 的NFT、聲稱已經獲得BIP-420 的編號等，吸引了不少人的注意。支持者宣稱，啟用了OP_CAT 可以實現「限制條款」（covenants）、實現比特幣的智慧合約或可程式性。

如果你注意到“限制條款”這個詞並稍作搜索，你會發現這是另一個很大的兔子洞。開發人員已經討論了多年，除了OP_CAT 之外，還有OP_CTV、APO、OP_VAULT 等等實現限制條款的技術。

那麼，究竟什麼是比特幣的「限制條款」呢？為什麼能吸引到如此多的開發人員持續數年的關注和討論？能實現比特幣的哪些可程式性？背後的設計原理是什麼樣的？本文試做一個概覽性的介紹與討論。

什麼是「限制條款」

Covenants，中文譯為「限制條款」，有時也翻譯為「契約」，是一種能夠為未來的比特幣交易設定條件的機制。

目前的比特幣腳本也包含了限制的條件，例如花費的時候要輸入合法的簽名、送入符合的腳本等。但只要使用者能解鎖，就可以將該UTXO 花到任何他希望的地方。

而限制條款是，在此限制如何解鎖的基礎之上，做出更多限制，例如限制UTXO 之後的花費，也就是實現類似“專款專用”的效果；或一筆交易中送入的其他輸入條件等。

更嚴謹地說，目前的比特幣腳本也具備一定的限制條款，例如基於操作碼的時間鎖，就是透過內省交易的nLock 或者nSequence 欄位來實現交易花費前的時間限制，但也基本上僅限於時間方面的限制。

那麼，開發和研究人員為什麼要設計這些限制檢查？因為限制條款不只是為了限製而限制，更是設定了交易執行的規則。這樣，使用者只能依照預先設定的規則來執行交易，從而完成預定的業務流程。

所以比較反直覺的是，這可以解鎖更多應用程式場景。

應用場景

確保Staking 的懲罰

限制條款的一個最直觀的例子是Babylon 在Bitcoin staking 流程中的slash 交易。

Babylon 的Bitcoin staking 過程是使用者將自己的BTC 資產在主鏈上發送到一個特殊的腳本中，花費條件包括兩種：
Happy ending：經過一定的時間後，使用者用自己的簽名即可解鎖，即完成unstake 的過程

Bad ending：如果使用者在某個被Babylon 租借安全性的PoS 鏈上有雙簽等作惡行為，那麼透過EOTS（extractable one-time signatures，一次性可提取簽名），可以解鎖出這部分資產，並由網路中的執行角色將一部分資產強制傳送到燃燒位址（slash）

詳解Covenants：如何實現比特幣的可程式性？

來源：Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy

注意這裡的「強制發送」，這意味著即便是可以解鎖這筆UTXO，但該資產不能任意地發送到其他任何地方，只能燃燒掉。這樣才能確保作惡的用戶無法搶先用自己已知的簽名把資產轉回給自己，以逃脫懲罰。

這個功能如果在OP_CTV 等限制條款實現後，可以在staking 腳本的“bad ending”分支中增加OP_CTV 等opcode 以實現限制。

而在OP_CTV 啟用前，Babylon 就需要透過變通的方法，由使用者+ 委員會共同執行的方式來模擬實現限制條款強制執行的效果。

擁塞控制

一般而言，擁塞是指當比特幣網路上手續費率很高，交易池中累積了比較多的交易等待打包，所以如果用戶想要快速確認交易，就需要提高手續費。

而此時如果一個使用者必須發送多筆交易給多個收款方，就得提高手續費，承擔比較高的成本。同時也相應的會進一步推高整個網路的手續費率。

如果有了限制條款，一個解決方法是發送方，可以先承諾到一筆批量發送的交易上。這個承諾可以讓所有的接收者相信，最終的交易都會進行，可以等到手續費率低的時候再發送具體的交易即可。

如下圖所示，當對區塊空間的需求很高時，進行交易變得非常昂貴。透過使用OP_CHECKTEMPLATEVERIFY，大批量支付處理商可以將其所有付款聚合到單一O（1）事務中以進行確認。然後，一段時間後，當對區塊空間的需求減少時，付款可以從該UTXO 中擴展出來。

詳解Covenants：如何實現比特幣的可程式性？

資料來源：https://utxos.org/uses/scaling/

這個場景是OP_CTV 這個限制條款所提出的比較典型的一個應用案例。還有更多的應用案例可從https://utxos.org/uses/ 找到，除了上述擁塞控制，該網頁列舉了Soft Fork Bets、Decentralized options、Drivechains、Batch Channels、Non Interactive Channels、Trustless Coordination-Free Mining Pools、Vaults、Safer Hashed Time Locked Contracts (HTLCS) Limits 等。

保管庫

保管庫（vault）是比特幣應用程式中一類比較廣泛討論的應用場景，特別是在限制條款領域內。因為日常操作不可避免的要在資金保管與資金使用需求之間進行平衡，所以人們希望能有一類保管金庫的應用：可以保證資金安全，甚至即使帳戶被駭（洩露了私鑰），也能限制資金的使用。

基於實現限制條款的技術，保管庫類別的應用可以比較容易的建置出來。

以OP_VAULT 的設計方案為例：在花費保管庫中的資金時，需要先發送一筆交易上鍊。這筆交易表明了希望花費保管庫的意圖，即“trigger”，並在其中設置了條件：

如果一切正常，那麼第二筆交易是最終提款的交易。等待N 個區塊後，可以將資金進一步花費到任何地方
如果發現是這筆交易被竊取的（或者是被「扳手攻擊」時候脅迫的），在N 個區塊的取款交易發送前，可以立即發送到另一個安全地址（用戶更安全的保管）

詳解Covenants：如何實現比特幣的可程式性？

 OP_VAULT 的流程，來源：BIP-345

要注意的是，在沒有限制條款的情況下，也可以建構出來一個保管庫應用，一個可行的辦法是用私鑰來準備好以後花費的簽名，然後銷毀掉這個私鑰。但限制仍然比較多，例如需要確保這個私鑰已經銷毀掉（類似於零知識證明中的trusted setup 過程）、金額和手續費提前確定（因為要預簽名）因而缺乏靈活性等。

詳解Covenants：如何實現比特幣的可程式性？

 OP_VAULT 與預簽名式的保管庫流程對比，來源：BIP-345

更健壯和靈活的狀態通道

一般可以認為，包括閃電網路在內的狀態通道擁有和主鏈近乎等同的安全性（在保證節點可觀察最新狀態、能夠正常發布最新狀態上鍊的情況下）。然而在有了限制條款之後，一些新的狀態通道的設計想法可以在閃電網路的之上更加健壯或靈活。這其中比較知名的包括Eltoo、 Ark 等。

Eltoo （也稱為LN-Symmetry）就是其中一個比較典型的例子。這個技術方案取「L2」的諧音，為閃電網路提出了一種執行層，允許任何後來的通道狀態取代之前的狀態，而不需要懲罰機制，因此也可以同時避免類似閃電網路節點那種必須保存多個之前狀態以防止對手作惡。為了達到上述效果， Eltoo 提出了SIGHASH_NOINPUT 的簽章方式，即APO（BIP-118）。

而Ark 旨在降低閃電網路的入站流動性和通道管理等難度。它是一種joinpool 形式的協議，多個用戶都可以在一定時間內接受一個服務提供者作為交易對手，在鏈外進行虛擬UTXO（vUTXO）的交易，但在鏈上共享一個UTXO 從而降低成本。和保管庫類似，Ark 也可以在當前的比特幣網路上實現；但引入了限制條款之後，Ark 可以基於交易模板降低所需的交互量，實現更去信任化的單邊退出。

限制條款技術概覽

從上述應用可以看到，限制條款更像是效果而非某種技術，因此有許多種實現的技術方式。如果進行分類，可以包括：

類型：通用型、專用型
實作方式：基於Opcode、基於簽名
遞迴：遞迴、非遞迴

詳解Covenants：如何實現比特幣的可程式性？

而其中，遞歸是指：有一些限制條款的實現，也可以透過限制下一筆輸出來限制再下一筆的輸出，可以實現添加的限制可以超越一筆交易，達到更高的交易深度。

一些主流的限制條款設計包括：

詳解Covenants：如何實現比特幣的可程式性？

* 遞歸：如果結合OP_CAT

限制條款的設計

從前面的介紹可以看出來，目前的比特幣腳本主要限制了解鎖的條件，沒有限制該UTXO 如何進一步被花費。要實現限制條款，我們就要反過來思考：為什麼目前的比特幣腳本無法實現限制條款？

原因主要在於目前的比特幣腳本無法讀取交易本身的內容，也就是交易的「內省」（introspection）。

如果我們可以實現交易的內省——檢查交易的任何內容（包括輸出），那麼就可以實現限制條款了。

因此限制條款的設計想法也主要圍繞在如何實現內省。

基於操作碼vs 基於簽名

最簡單粗暴的想法是，增加一個或多個操作碼（即一個操作碼+ 多種參數，或多個不同功能的操作碼），直接讀取交易的內容。這個也就是基於操作碼的想法。

而另一個想法是，可以不在腳本中直接讀取和檢查交易自身的內容，而是可以利用交易內容的哈希——如果已經對這個哈希進行了簽名，那麼只要在腳本裡改造例如OP_CHECKSIG等來實現這個簽名的檢查，就可以間接的實現交易內省及限制條款了。這個想法就是基於簽名的設計方式。主要包括APO 及OP_CSFS 等。

APO

SIGHASH_ANYPREVOUT（APO）是提案中的一種比特幣簽名方式。簽名的最簡單的方式是對交易的輸入輸出都承諾，但比特幣還有更靈活的方式，即SIGHASH，選擇性地對一筆交易中的輸入或輸出進行承諾。

詳解Covenants：如何實現比特幣的可程式性？

目前SIGHASH 及其組合對交易輸入輸出的簽章範圍（資料來源《Mastering Bitcoin, 2nd》

如上圖所示，除了適用到全部資料的ALL 之外，NONE 的簽章方式是只適用到所有輸入，而不用於輸出；SINGLE 是在此基礎上，只對適用到相同輸入序號的輸出。另外，SIGHASH 還可以組合，疊加了ANYONECANPAY 修飾符後，只適用於一筆輸入。

而APO 的SIGHASH 則是只對輸出簽名，而不對輸入部分簽名。這也意味著，用APO 方式簽署之後的交易，可以在之後附加到任何一個符合條件的UTXO 上。

詳解Covenants：如何實現比特幣的可程式性？

這種靈活性是APO 實現限制條款的理論基礎：

可以預先建立一筆或多筆交易
透過這些交易的資訊建構出一個只能求出一個簽署的公鑰
這樣任何發送到該公鑰地址上的資產都只能透過預先建立的交易來花費

值得注意的是，因為這個公鑰沒有對應的私鑰，所以可以確保這些資產只能透過預先建立的交易來花費。那麼，我們就可以在預先建立的這些交易中規定資產的去向，從而實現限制條款。

我們可以進一步透過比較以太坊的智慧合約來理解：透過智慧合約我們可以實現的也是只有透過一定的條件，才能從合約地址中取款，而非靠一個EOA 簽名就任意花費。從這一點來講，比特幣透過簽名機制的改進就可以實現這種效果。

但上述過程中的問題在於計算時存在循環依賴，因為需要知道輸入的內容來預簽並建立交易。

APO 以及SIGHASH_NOINPUT實現這種簽章方式的意義在於可以解決這種循環依賴問題，在計算時只需要知道（指定）交易的全部輸出即可。

OP_CTV

OP_CHECKTEMPLATEVERIFY （CTV），即BIP-119 ，採用了改進Opcode 的方式。它將commitment hash 作為參數，並要求任何執行操作碼的交易都包含一組與該承諾匹配的輸出。透過CTV，將允許比特幣用戶限制他們使用比特幣的方式。

該提案最初以OP_CHECKOUTPUTSHASHVERIFY （COSHV）的名義推出，並且早期側重於創建擁塞控制交易的能力，因此對該提案的批評也集中在該方案不夠通用、過於具體地針對擁塞控制用例。

在上文提到的擁塞控制用例中，發送者Alice 可以建立10 個輸出並對這10 個輸出進行哈希，並使用產生的摘要來建立一個包含COSHV 的tapleaf 腳本。 Alice 也可以使用參與者的公鑰來形成Taproot 內部金鑰，以允許他們在不洩露Taproot 腳本路徑的情況下合作支出。

然後，Alice 會給每個接收者一份所有10 個輸出的副本，以便他們每個人都驗證Alice 的設定交易。當他們以後想要花費這筆款項時，他們中的任何一個都可以創建一個包含承諾輸出的交易。

在整個過程中，在Alice 建立並傳送設定交易時，Alice 可以透過現有的非同步通訊方法（如電子郵件或雲端硬碟）發送這10 個輸出副本。這意味著，接收者不需要在線，也不需要相互互動。

詳解Covenants：如何實現比特幣的可程式性？

來源：https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

和APO 類似，地址也可根據支出條件來構建，可以用不同的方式來製作「鎖」，包括：增加其他的key、時間鎖、可組合邏輯。

詳解Covenants：如何實現比特幣的可程式性？

來源：https://twitter.com/OwenKemeys/status/1741575353716326835

CTV 在此基礎上提出了可以檢查經過hash 後的花費交易是否與定義的匹配，即將交易資料作為開「鎖」的密鑰。

我們可以將上面10 個接收者的例子繼續延伸，接收方可進一步將其位址金鑰設定為已簽署但未廣播的tx 發送給下一批接收方位址，以此類推，形成一個如下圖所示的樹狀結構。 Alice 在鏈上只用1 utxo 的區塊空間就可以建構一個涉及多個用戶的帳戶餘額變更。

詳解Covenants：如何實現比特幣的可程式性？

來源：https://twitter.com/OwenKemeys/status/1741575353716326835

而如果其中一個葉子是閃電通道、是cold storage、是其他支付路徑呢？那麼這棵樹將從單維度多層的支出樹擴展至多維多層次的支出樹，所能支援的場景將更為豐富和靈活。

詳解Covenants：如何實現比特幣的可程式性？

來源：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 樹可以理解為兩個元素先拼接，再進行hash。目前比特幣腳本裡有OP_SHA256 等hash 的操作碼，所以如果能用OP_CAT 實現對兩個元素拼接，就可以在腳本中實現merkle 樹的驗證功能，也就在一定程度上具備了輕客戶端驗證的能力。

另外的實作基礎還包括對於Schnorr 簽名的增強：可以對腳本的花費簽名條件設定為用戶的公鑰和公開nonce 的拼接；之後如果簽署者如果想要另簽一個交易將這筆資金花費到其他地方，就不得不使用同樣的nonce 而導致私鑰外洩。也就是透過OP_CAT 實現了對nonce 的承諾，進而確保已簽署交易的有效性。

OP_CAT 的其他的應用場景還包括：Bistream、樹形簽名、抗量子的Lamport 簽名、保管庫等等。

OP_CAT 本身並不是一個新的功能，它曾在比特幣最早版本中存在過，不過由於可能導致被攻擊所利用而在2010 年開始被禁用。例如，重複使用OP_DUP 和OP_CAT 就可以很容易的讓全節點在處理此類腳本時堆疊爆炸，參考這個demo。

但現在重新啟用OP_CAT 不會發生前面提到的堆疊爆炸問題麼？因為目前的OP_CAT 提案只涉及在tapscript 中啟用，而tapscript 限定了每個堆疊元素不超過520 位元組，所以不會產生先前的堆疊爆炸問題。還有一些開發者認為中本聰直接停用OP_CAT 可能過於嚴苛。但由於OP_CAT 的靈活性，可能確實一些會導致漏洞的應用場景在目前無法窮盡。

所以綜合了應用場景和潛在風險等，OP_CAT 最近受到很多關注，也有過PR review，是目前最熱門的升級提議之一。

結語

「自律帶來自由」，從上面的介紹可以看到，限制條款可以直接在比特幣腳本中實現對交易進一步花費的限定，從而實現類似智能合約效果的交易規則。相較於BitVM 等鏈外方式，這種程式設計方式可以更為原生的在比特幣上驗證，同時也可以改進主鏈上的應用（擁塞控制）、鏈外應用（狀態通道）以及其他的新的應用方向（staking 懲罰等）。

限制條款的實現技術如果能再結合一些底層的升級，會進一步釋放可程式化的潛力。例如，最近在review 中的64 位元運算符的提案，就可以進一步與提議的OP_TLUV 或其他的限制條款結合，可以基於交易輸出的聰的數量來進行程式設計。

但限制條款也可能導致一些計劃外的濫用或漏洞，因此社群對此也比較謹慎。另外，限制條款的升級也需要涉及共識規則的軟分叉升級。鑑於taproot 升級時的情形，限制條款相關的升級也可能需要假以時日來完成。

感謝阿劍、Fisher、Ben 對本文的審閱與建議！