HashKey Capital研報：Covenants，比特幣的可編程性

2024-05-21 00:05:05

近期比特幣社區裏掀起來一波關於重新啓用 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）

比特幣的可編程性" />

來源：Bitcoin Staking: Unlocking 21 M 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 中擴展出來。比特幣的可編程性" />

來源：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 個區塊的取款交易發送前，可以立即發送到另一個安全地址（用戶更安全的保管）

比特幣的可編程性" data-img-size-val="1165,369" />

OP_VAULT 的流程，來源：BIP-345

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

比特幣的可編程性" />

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

更健壯和靈活的狀態通道

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

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

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

限制條款技術概覽

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

類型：通用型、專用型
實現方式：基於 Opcode、基於籤名
遞歸：遞歸、非遞歸

比特幣的可編程性" data-img-size-val="1112,515" /> 而其中，遞歸是指：有一些限制條款的實現，也可以通過限制下一筆輸出來限制再下一筆的輸出，可以實現添加的限制可以超越一筆交易，達到更高的交易深度。

一些主流的限制條款設計包括：比特幣的可編程性" />

* 遞歸：如果結合 OP_CAT

限制條款的設計

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

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

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

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

基於操作碼 vs 基於籤名

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

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

APO

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

比特幣的可編程性" data-img-size-val="1003,616" />

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

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

而 APO 的 SIGHASH 則是只對輸出籤名，而不對輸入部分籤名。這也就意味着，用 APO 方式籤名之後的交易，可以在之後附加到任何一個滿足條件的 UTXO 上。比特幣的可編程性" data-img-size-val="1013,324" />

這種靈活性是 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 個輸出副本。這意味着，接收者不需要在线，也不需要相互交互。比特幣的可編程性" data-img-size-val="1138,509" />

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

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

比特幣的可編程性" />

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

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

我們可以將上面 10 個接收者的例子繼續延伸，接收方可進一步將其地址密鑰設置為已籤名但未廣播的 tx 發送給下一批接收方地址，以此類推，形成一個如下圖所示的樹狀結構。Alice 在鏈上只用 1 utxo 的區塊空間就可以構造一個涉及多個用戶的账戶余額變更。比特幣的可編程性" data-img-size-val="736,409" />

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

而如果其中一個葉子是閃電通道、是 cold storage、是其他支付路徑呢？那么這棵樹將從單維多層的支出樹擴展至多維多層次的支出樹，能支持的場景將更為豐富和靈活。比特幣的可編程性" data-img-size-val="756,500" />

來源：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_SHA 256 等 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 對本文的審閱和建議！

參考資料
https://utxos.org/

https://bitcoincovenants.com/

A collection of resources related to covenants:

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-final2 8.pdf

https://maltemoeser.de/paper/covenants.pdf

https://bitcoinops.org/en/topics/op_cat/