詳解限制條款:實現比特幣的可編程性

近期比特幣社區掀起了一波關於重新啓用 OP_CAT 等操作碼的討論。Taproot Wizard 通過推出 Quantum Cats NFT 和聲稱獲得 BIP-420 編號等方式,吸引了不少人的注意力。支持者宣稱,啓用 OP_CAT 可以實現"限制條款",從而實現比特幣的智能合約或可編程性。

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

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

什麼是"限制條款"

限制條款(Covenants)是一種能夠給未來的比特幣交易設置條件的機制。

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

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

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

那麼,開發和研究人員爲什麼要設計這些限制檢查?因爲限制條款不只是爲了限制而限制,更是設置了交易執行的規則。這樣,用戶只能按照預先設定的規則來執行交易,從而完成預定的業務流程。

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

應用場景

確保 Staking 的懲罰

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

Babylon 的 Bitcoin staking 過程是用戶將自己的 BTC 資產在主鏈上發送到一個特殊的腳本中,花費條件包括兩種:

• 正常情況:經過一定的時間後,用戶用自己的籤名即可解鎖,即完成 unstake 的過程
• 異常情況:如果用戶在某個被 Babylon 租借安全性的 PoS 鏈上有雙籤等作惡行爲,那麼通過 EOTS(extractable one-time signatures,一次性可提取籤名),可以解鎖出這部分資產,並由網路中的執行角色將一部分資產強制發送到燃燒地址(slash)

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

這個功能如果在 OP_CTV 等限制條款實現後,可以在 staking 腳本的"異常情況"分支中增加 OP_CTV 等 opcode 以實現限制。

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

擁堵控制

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

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

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

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

這個場景是 OP_CTV 這個限制條款提出的比較典型的一個應用案例。

保管庫

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

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

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

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

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

更健壯和靈活的狀態通道

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

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

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

限制條款技術概覽

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

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

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

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

• OP_CTV:通用型,基於 Opcode,非遞歸
• OP_VAULT:專用型,基於 Opcode,非遞歸
• APO:通用型,基於籤名,非遞歸
• OP_CAT:通用型,基於 Opcode,遞歸*
• OP_CSFS:通用型,基於籤名,遞歸

*如果結合 OP_CAT

限制條款的設計

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

原因主要在於目前的比特幣腳本無法讀取交易自身的內容,即交易的"內省"(introspection)。

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

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

基於操作碼 vs 基於籤名

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

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

APO

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

而 APO 的 SIGHASH 則是只對輸出籤名,而不對輸入部分籤名。這也就意味着,用 APO 方式籤名之後的交易,可以在