比特幣限制條款:開啓BTC新一代可編程性

比特幣限制條款:實現可編程性的新方向

比特幣社區最近對重新啓用OP_CAT等操作碼展開了熱烈討論。Taproot Wizard通過推出Quantum Cats NFT和聲稱獲得BIP-420編號等方式,吸引了大量關注。支持者稱,啓用OP_CAT可以實現"限制條款",從而爲比特幣帶來智能合約和可編程性。

"限制條款"(covenants)這個概念引發了開發人員多年的討論。除了OP_CAT,還有OP_CTV、APO、OP_VAULT等多種實現限制條款的技術方案。那麼,什麼是比特幣的"限制條款"?爲什麼能引發如此廣泛和持久的關注?它能爲比特幣帶來哪些可編程性?背後的設計原理是什麼?本文將對這些問題進行概覽性介紹和討論。

詳解Covenants:如何實現比特幣的可編程性?

什麼是"限制條款"

"限制條款"(covenants)是一種可以爲未來的比特幣交易設置條件的機制。當前的比特幣腳本已經包含了一些限制條件,比如需要輸入有效籤名、提供符合要求的腳本等。但只要用戶能解鎖,就可以將UTXO花費到任意地方。

而限制條款在此基礎上增加了更多限制,例如限制UTXO後續的花費去向,實現"專款專用"的效果;或者限制一筆交易中其他輸入的條件等。

更準確地說,目前的比特幣腳本也具備一定的限制條款功能,如基於操作碼的時間鎖。通過檢查交易的nLock或nSequence字段,可以實現交易花費前的時間限制。但目前主要局限於時間方面的限制。

開發人員設計這些限制檢查的目的,不僅僅是爲了限制,更是爲了設置交易執行的規則。用戶只能按照預先設定的規則執行交易,從而完成預定的業務流程。

因此,限制條款反直覺地可以解鎖更多應用場景。

詳解Covenants:如何實現比特幣的可編程性?

應用場景

確保Staking的懲罰

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

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

  1. 正常結束:經過一定時間後,用戶用自己的籤名即可解鎖,完成unstake過程。

  2. 懲罰結束:如果用戶在Babylon租借安全性的PoS鏈上有雙籤等作惡行爲,那麼通過EOTS(可提取一次性籤名)可以解鎖資產,由網路中的執行角色將部分資產強制發送到燃燒地址(slash)。

這裏的"強制發送"意味着即使可以解鎖UTXO,該資產也不能隨意發送到其他地方,只能被燃燒。這確保了作惡用戶無法搶先用已知籤名將資產轉回給自己,逃脫懲罰。

在OP_CTV等限制條款實現後,可以在staking腳本的"懲罰結束"分支中增加相關操作碼來實現限制。

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

詳解Covenants:如何實現比特幣的可編程性?

擁堵控制

網路擁堵時,交易池中積累了大量待打包交易,用戶需要提高手續費以獲得快速確認。如果用戶必須發送多筆交易給多個收款方,就不得不承擔較高成本,同時進一步推高整個網路的手續費率。

有了限制條款後,發送方可以先承諾一筆批量發送交易。這個承諾讓所有接收方相信最終交易都會執行,可以等到手續費率降低時再發送具體交易。

當對區塊空間需求很高時,交易變得昂貴。使用OP_CHECKTEMPLATEVERIFY,大批量支付處理商可以將所有付款聚合到單個O(1)交易中確認。之後當區塊空間需求減少時,可以從該UTXO中擴展出付款。

這是OP_CTV這個限制條款提出的典型應用案例之一。

詳解Covenants:如何實現比特幣的可編程性?

保管庫

保管庫(vault)是比特幣應用中廣泛討論的場景,尤其在限制條款領域。日常操作需要在資金保管與使用需求間平衡,人們希望有一類保管金庫應用:既能保證資金安全,即使帳戶被黑(私鑰泄露)也能限制資金使用。

基於限制條款技術,可以較容易構建保管庫類應用。

以OP_VAULT方案爲例:花費保管庫資金時,需要先發送一筆交易上鏈表明意圖("trigger"),並設置條件:

  • 正常情況:第二筆交易是最終取款交易。等待N個區塊後,可將資金進一步花費到任意地址。

  • 異常情況:如發現是被盜交易(或被脅迫),在N個區塊的取款交易發送前,可立即將資金發送到更安全的地址。

需要注意,即使沒有限制條款,也可以構建保管庫應用。一種方法是用私鑰準備好未來花費的籤名,然後銷毀私鑰。但這種方式仍有局限,如需確保私鑰已銷毀、金額和手續費需提前確定等,缺乏靈活性。

詳解Covenants:如何實現比特幣的可編程性?

更健壯和靈活的狀態通道

狀態通道(包括閃電網絡)在節點可觀察最新狀態、能正常發布最新狀態上鏈的情況下,可以認爲具有與主鏈近乎相同的安全性。而有了限制條款後,一些新的狀態通道設計可以在閃電網絡基礎上更加健壯或靈活,比較知名的包括Eltoo、Ark等。

Eltoo(也稱LN-Symmetry)是典型例子。它爲閃電網絡提出了一個執行層,允許任何後來的通道狀態取代之前狀態,無需懲罰機制,因此可以避免閃電網絡節點必須保存多個之前狀態以防對手作惡。Eltoo提出了SIGHASH_NOINPUT籤名方式,即APO(BIP-118)來實現這一效果。

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

詳解Covenants:如何實現比特幣的可編程性?

限制條款技術概覽

從上述應用可以看出,限制條款更像一種效果而非某種具體技術,因此有多種實現方式。可以從以下幾個維度進行分類:

  • 類型:通用型、專用型
  • 實現方式:基於操作碼、基於籤名
  • 遞歸性:遞歸、非遞歸

其中,遞歸是指一些限制條款的實現可以通過限制下一筆輸出來限制再下一筆的輸出,實現跨越多筆交易的限制。

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

  • OP_CTV:通用型,基於操作碼,非遞歸
  • APO:通用型,基於籤名,非遞歸
  • OP_VAULT:專用型,基於操作碼,非遞歸
  • OP_CAT:通用型,基於操作碼,遞歸(如果與OP_CAT結合)

詳解Covenants:如何實現比特幣的可編程性?

限制條款的設計

目前的比特幣腳本主要限制了解鎖條件,沒有限制UTXO如何進一步被花費。要實現限制條款,需要反思爲什麼當前腳本無法實現這一功能。

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

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

因此限制條款的設計主要圍繞如何實現內省展開。

詳解Covenants:如何實現比特幣的可編程性?

基於操作碼 vs 基於籤名

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

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

詳解Covenants:如何實現比特幣的可編程性?

APO

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

APO的SIGHASH只對輸出籤名,不對輸入部分籤名。這意味着用APO方式籤名後的交易,可以之後附加到任何滿足條件的UTXO上。

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

  • 可以預先創建一筆或多筆交易
  • 通過這些交易信息構建出一個只能求出一個籤名的公鑰
  • 這樣任何發送到該公鑰地址上的資產都只能通過預先創建的交易來花費

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

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

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

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

詳解Covenants:如何實現比特幣的可編程性?

OP_CTV

OP_CHECKTEMPLATEVERIFY(CTV),即BIP-119,採用了改進操作碼的

查看原文
此页面可能包含第三方内容,仅供参考(非陈述/保证),不应被视为 Gate 认可其观点表述,也不得被视为财务或专业建议。详见声明
  • 讚賞
  • 留言
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate APP
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)