比特幣的“Covenants”是一種爲未來比特幣交易設置條件的機制。本文概述了限制條款的基本概念、應用場景及技術實現方法，並討論了其背後的設計原則。文章介紹了如OP_CAT、OP_CTV和APO等技術提案，以及它們如何增強比特幣的可編程性和智能合約功能。同時，本文還涉及限制條款在比特幣網路中的應用，如擁堵控制、金庫（vaults）、狀態通道等，並討論了實現限制條款的設計理念及潛在的社區爭議。

由 Jeffrey Hu 和 Harper Li 聯合撰寫

最近在比特幣社區中，有關重新啓用如OP_CAT等操作碼的討論引起了熱議，Taproot Wizard通過推出Quantum Cats的NFT並聲稱獲得了BIP-420的分配而備受關注。支持者們聲稱，啓用OP_CAT將實現“Covenants”，從而爲比特幣帶來智能合約或可編程性。

如果你注意到“Covenants”這個詞，並稍加搜索，你會發現這是另一個大的研究領域。多年來，開發者們一直在討論實現Covenants的技術，如OP_CTV、APO、OP_VAULT等，除了OP_CAT之外。

更確切地說，當前的比特幣腳本也有一些類型的Covenants，例如基於操作碼的時間鎖定，通過檢查交易的nLock或nSequence字段來限制交易在一定時間內不能被花費，但這些仍然僅限於時間限制。

那麼，到底什麼是比特幣的“Covenants”？爲什麼它多年來吸引了這麼多開發者的關注和討論？比特幣的可編程性可以實現到什麼程度？它背後的設計原則是什麼？本文試圖提供一個概述和討論。

什麼是“Covenants”？

Covenants是一種可以爲未來比特幣交易設置條件的機制。事實上，目前的比特幣腳本中已經包含了約束條件，例如必須輸入合法籤名、在花費時提交合規的腳本。只要用戶能解鎖，就可以將UTXO（未花費的交易輸出）用於任何用途。

而Covenants是在這種解鎖限制的基礎上，增加更多的限制，例如在花費之後限制UTXO的使用，這類似於資金劃撥或其他交易輸入條件的效果。

那麼，爲什麼開發者和研究人員要設計這些限制檢查呢？因爲Covenants不僅僅是限制，而是爲了設定交易執行的規則。通過這種方式，用戶只能按照預設規則執行交易，從而完成預期的業務流程。

相對直觀的是，這帶來了更多的應用場景。

應用場景

確保質押懲罰

Covenants的一個最直觀的例子是Babylon在比特幣質押過程中的削減交易。

Babylon的比特幣質押過程涉及用戶將其BTC發送到主鏈上的一個特殊腳本，具有兩個支出條件：

• Happy ending：在一定時間後，用戶可以通過自己的籤名解鎖，這意味着質押過程完成。
• Bad ending：如果用戶在PoS鏈上進行雙重花費攻擊，用戶可以通過EOTS（可提取一次性籤名）解鎖資產，並由網路中的執行者將部分資產強制發送到銷毀地址（削減）。

來源：《比特幣質押：解鎖2100萬比特幣以保障權益證明經濟》

注意“強制”一詞，這意味着即使UTXO可以解鎖，資產也不能被發送到其他地方，只能被銷毀。這確保了惡意用戶不能通過自己的已知籤名將資產轉回自己。

這種特性在實現如OP_CTV（CheckTemplateVerify）等Covenants後，可以通過在質押腳本的“壞結局”中添加操作碼來實現。在OP_CTV啓用之前，Babylon需要通過用戶和委員會的合作來模擬強制執行Covenants的效果。

擁堵控制/擴展

常來說，比特幣網路擁堵是指交易費用較高、交易池中積累了大量等待打包的交易，因此，如果用戶希望快速確認交易，就需要提高費用。

此時，如果用戶需要向多個地址發送多筆交易，他們將不得不提高費用，導致成本增加。這將進一步推高整個網路的交易費用。

如果有Covenant，則有解決方案：一個包含多個輸出的單一承諾交易。這種承諾可以讓所有接收方確信最終交易會發生，每個人可以等到費用降低後再發送具體交易。

如下所示，當區塊空間需求高時，進行交易的成本非常高。通過使用OP_CHECKTEMPLATEVERIFY（OP_CTV），一個高流量支付處理器可以將其所有支付合並到一個O(1)交易中進行確認。然後，經過一段時間，當區塊空間需求下降時，可以從該UTXO中擴展出支付。

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

這種場景是OP_CTV限制所展示的一個典型用例。更多用例可以在UTXOs找到。除了上述提到的擁堵控制，該頁面還列出了軟分叉下注、去中心化期權、驅動鏈、批量通道、非交互式通道、無需信任的無協調挖礦池、金庫（Vaults）、更安全的哈希時間鎖定合約（HTLCs）限制等。

金庫（Vaults）

金庫是比特幣應用中討論最廣泛的用例之一，尤其是在Covenants的領域。由於日常操作不可避免地需要平衡資金安全和使用的需求，人們希望有一個金庫能夠保障資金安全，甚至在帳戶被黑客攻擊（例如，私鑰被泄露）時限制其使用。

基於用於實現限制條款的技術，這種托管金庫可以相對容易地構建。

以OP_VAULT的設計方案爲例：當要花費金庫中的資金時，首先需要向鏈上發送一筆交易。這筆交易表明花費金庫的意圖，即“觸發器”，並在其中設置條件：

• 正常情況：如果一切順利，那麼第二筆交易最終會提取資金。在等待N個區塊後，資金可以進一步花費到任何地方。
• 異常情況：如果交易被盜（或在“觸發攻擊”中被脅迫），在N個區塊後的提取交易發送之前，資產可以立即發送到另一個安全地址（對用戶更安全）。

OP_VAULT 流程，來源：BIP-345

需要注意的是，也可以在沒有Covenants的情況下建立金庫，一種可能的方法是使用私鑰準備好用於後期花費的籤名，然後銷毀這個私鑰。然而，這種方法仍然有更多的限制，例如需要確保私鑰已經被銷毀（類似於零知識證明中的可信設置過程），以及在預籤名時難以靈活地確定金額和費用。

預計算金庫和 OP_VAULT ，來源：BIP-345

更加穩健和靈活的狀態通道

通常認爲，狀態通道（包括閃電網絡）的安全性幾乎與主鏈相同（確保節點能夠觀察到最新狀態並能夠正確地將最新狀態發布到鏈上）。然而，通過Covenants，可以在閃電網絡基礎上設計出更加穩健或靈活的新型狀態通道。其中一些較爲知名的包括Eltoo和Ark。

Eltoo

Eltoo（也稱爲LN-Symmetry）是一個典型的例子。作爲“L2”的縮寫，這項技術提出了一個閃電網絡的執行層，允許任何後續通道狀態替換先前狀態而無需懲罰機制，從而避免了閃電網絡節點需要保存多個先前狀態以防止對手實施惡意行爲。爲了實現上述效果，Eltoo提出了SIGHASH_NOINPUT籤名和APO（BIP-118）。

Ark

Ark旨在減少閃電網絡的入站流動性和通道管理難度。它是一種類似於joinpool的協議，其中多個用戶可以在一段時間內接受一個服務提供商作爲對手方，並在鏈下交易虛擬UTXO（vUTXO），但在鏈上共享一個UTXO以降低成本。類似於金庫（vaults），Ark可以在當前的比特幣網路上實現；然而，通過引入Covenants，Ark可以基於交易模板減少所需的交互量，實現更加無信任的單向退出。

Covenants概述

從上述應用中可以看出，Covenants更像是一種效果而非某種特定技術，因此有多種技術方式可以實現。它們可以分類爲：

• 類型：通用型（generic），限制型（restrictive）
• 實現方式：基於操作碼（opcode-based），基於籤名（signature-based）
• 遞歸性：遞歸（recursive），非遞歸（non-recursive）

遞歸意味着：某些Covenants的實現可以通過限制當前交易的輸出來限制下一筆交易的輸出，這意味着交易鏈中的每一筆交易都受到前一筆交易的限制。

一些流行的Covenants設計包括：

Covenants的設計

從前面的介紹中可以看出，當前的比特幣腳本主要限制了解鎖條件，但不限制UTXO（未花費的交易輸出）進一步的花費方式。爲了實現Covenants，我們需要反向思考：爲什麼當前的比特幣腳本不能實現Covenants？

主要原因是當前的比特幣腳本無法讀取交易本身，這意味着無法對交易進行內省。如果我們能夠實現內省——檢查交易中的任何內容（包括輸出）——那麼我們就可以實現Covenants。因此，Covenants的設計也圍繞如何實現內省展開。

基於操作碼 vs 基於籤名

最簡單和最粗暴的想法是添加一個或多個操作碼（一個操作碼加多個參數，或多個具有不同功能的操作碼），直接讀取交易的內容。這也被稱爲基於操作碼的設計思路。

另一種思路是，不直接在腳本中讀取和檢查交易內容，而是使用交易內容的哈希值。這意味着如果該哈希值已經被籤名，那麼通過在腳本中轉換類似於OP_CHECKSIG的操作碼來檢查這個籤名，就可以間接實現交易內省和Covenants。這種思路基於籤名的設計方法，主要包括APO（ANYPREVOUT）和OP_CSFS（CheckSigFromStack）。

通過這些技術，Covenants爲比特幣網路帶來了更多的靈活性和可編程性，開闢了新的應用場景和可能性。這使得比特幣不僅僅是一種簡單的數字貨幣，還能夠實現更加復雜的金融和商業應用。

APO (SIGHASH_ANYPREVOUT)

SIGHASH_ANYPREVOUT (APO) 是一種籤名哈希提案。最簡單的籤名方式是同時提交交易的輸入和輸出，但比特幣可以通過一種更靈活的方式選擇性地提交交易的輸入或輸出，這被稱爲SIGHASH。

當前SIGHASH範圍及其交易輸入和輸出籤名組合

如上圖所示，除了適用於所有數據的ALL，NONE的籤名方式僅適用於所有輸入而不適用於輸出，而SINGLE則僅適用於具有相同輸入索引號的輸出。此外，SIGHASH可以與ANYONECANPAY修飾符結合，僅適用於一個輸入。

APO的SIGHASH

與上述不同，APO的SIGHASH僅對輸出進行籤名，而不對輸入籤名。這意味着使用APO籤名的交易可以在之後附加到任何符合條件的UTXO上。

這種靈活性是APO實現Covenants的基礎：

• 可以預先創建一個或多個交易。
• 使用這些交易的信息構建一個公鑰，只有通過/檢查花費籤名才能從中導出。
• 這樣，發送到這個公鑰地址的任何資產只能通過預創建的交易來花費。

值得注意的是，由於這個公鑰沒有對應的私鑰，確保了這些資產只能通過預創建的交易來花費。然後，我們可以通過在這些預創建的交易中指定資產的去向來實現Covenant。

這種機制可以與以太坊的智能合約進行比較：我們可以通過智能合約實現只有在滿足某些條件時才能從合約地址中提取資金，而不是通過EOA（外部擁有帳戶）籤名任意花費。從這個角度來看，比特幣可以通過改進籤名機制實現這一效果。

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV)，也稱爲BIP-119，是一種對操作碼的改進。它以承諾哈希（commitment hash）作爲參數，要求任何執行該操作碼的交易都包含一組與該承諾匹配的輸出。通過CTV，比特幣用戶可以限制他們使用比特幣的方式。

最初以OP_CHECKOUTPUTSHASHVERIFY（COSHV）的形式引入，早期主要關注於創建擁堵控制交易的能力，該提案的批評點也集中在其不夠通用，過於具體針對擁堵控制用例。

在上述擁堵控制用例中，發送方Alice可以創建10個輸出，並將這10個輸出的哈希值作爲結果摘要，使用該摘要創建包含COSHV的tapleaf腳本。Alice還可以使用參與者的公鑰形成一個Taproot內部密鑰，使他們能夠在不暴露Taproot腳本路徑的情況下合作花費資金。

然後，Alice將所有10個輸出的副本分發給每個接收方，以便他們可以驗證Alice的設置交易。當他們稍後想要花費支付時，任何人都可以創建一個包含承諾輸出的交易。

在整個過程中，Alice可以通過現有的異步通信方式（如電子郵件或雲盤）發送這10個輸出的副本。這意味着接收者無需在線或彼此互動。

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

類似於APO，可以基於花費條件構建地址，並以不同方式“鎖定”它們，包括額外的密鑰、相對或固定的時間鎖定及其他邏輯來組合它們。

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

基於此，CTV提出檢查花費交易的哈希是否與定義的匹配，這意味着交易數據用作解鎖“鎖”的鑰匙。

我們可以拓展上述10個接收者的例子，其中一個接收者可以進一步將其地址密鑰設置爲一個已籤名但未廣播的交易，發送給下一批接收者，如此形成一個如圖所示的樹結構。Alice可以使用一個UTXO的區塊空間構建涉及多個用戶的帳戶餘額變化。

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

如果其中一片葉子是閃電通道、冷藏庫或其他支付路徑怎麼辦？那麼樹會從單維多層支付樹擴展到多維多層支付樹，可以支持的場景會更豐富、更靈活。

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

如果其中一個葉節點是閃電通道、冷存儲或其他支付路徑呢？那麼，這棵樹將從單維多層支付樹擴展爲多維多層支付樹，支持的場景將更加豐富和靈活。

自提議以來，CTV經歷了從2019年的COSHV改名爲2020年的BIP-119的過程，並且出現了用於創建支持CTV合約的編程語言Sapio。在2022年和2023年期間，社區對其激活選項進行了大量討論、更新和辯論，CTV仍然是社區中討論最多的軟分叉升級提案之一。

OP_CAT

OP_CAT，如在開頭段落中所述，是一個當前備受關注的升級提案，旨在實現將堆棧中的兩個元素或兩個數據集連接在一起的功能。盡管看起來簡單，但OP_CAT非常靈活，可以在腳本中以多種方式實現。

Merkle樹操作：最直接的示例是Merkle樹的操作，可以解釋爲將兩個元素連接在一起並進行哈希運算。目前，比特幣腳本中有OP_SHA256和其他哈希操作碼，因此如果可以使用OP_CAT連接兩個元素，就可以在腳本中實現Merkle樹驗證功能，從而在一定程度上提供輕客戶端驗證的能力。

Schnorr籤名增強：另一種實現基礎是Schnorr籤名的增強：可以將腳本的花費籤名條件設置爲用戶公鑰和公共隨機數（nonce）的連接；然後如果籤名者想籤署另一筆交易以花費其他地方的資金，他或她必須使用相同的隨機數，這可能會泄露私鑰。也就是說，OP_CAT實現了對隨機數的承諾，從而確保籤署交易的有效性。

OP_CAT的其他應用包括：

• Bistream

• 樹籤名

• 抗量子攻擊的Lamport籤名

• 金庫（vaults）等

OP_CAT本身並不是新特性，它在比特幣的最早版本中就存在，但由於其可能被攻擊者利用，在2010年被禁用。例如，重復使用OP_DUP和OP_CAT可能會導致完整節點在處理此類腳本時堆棧爆炸，如在此演示中所見。

那麼，重新啓用OP_CAT後上述堆棧爆炸問題是否會再次出現呢？當前的OP_CAT提案僅涉及在tapscript中啓用它，每個堆棧元素的大小限制爲520字節，因此不會導致先前的堆棧爆炸問題。還有一些開發者認爲中本聰可能對禁用OP_CAT過於嚴苛。然而，由於OP_CAT的靈活性，確實可能存在一些可能導致漏洞的應用場景。

由於OP_CAT的應用場景和潛在風險相結合，最近它受到了很多關注，並且已經進行了PR（拉取請求）審核，目前是最熱門的升級提案之一。

1. 靈活性：OP_CAT爲比特幣腳本提供了更大的靈活性，使其能夠處理更復雜的數據結構和操作。

2. 應用廣泛：OP_CAT可用於多種應用場景，從Merkle樹驗證到增強Schnorr籤名，再到抗量子攻擊的籤名方案。

3. 安全性改進：通過限制每個堆棧元素的大小，可以避免過去堆棧爆炸的問題。

通過重新啓用OP_CAT，比特幣網路可以實現更高的可編程性和靈活性，爲開發者提供更多的工具和可能性。

結論

“自我約束帶來自由”，正如以上介紹所示，Covenants可以直接在比特幣腳本中實現，從而限定交易的進一步花費，進而實現類似智能合約的交易規則。這種編程方法可以比像BitVM這樣的鏈下方法更本地化地在比特幣上驗證，並且能夠改進主鏈上的應用（如擁堵控制）、鏈下應用（如狀態通道）以及其他新的應用方向（如質押削減等）。

如果將Covenants的實現技術與其他升級結合起來，可能會進一步釋放可編程性的潛力。例如，最近的64位算術提案可以進一步結合提議的OP_TLUV或其他基於交易輸出的聰數量編程的Covenants。

然而，Covenants也可能導致意想不到的濫用或漏洞，因此社區對此也持謹慎態度。此外，Covenants的升級需要涉及共識規則的軟分叉升級。鑑於taproot升級的情況，預計與Covenants相關的升級也需要時間來完成。

特別感謝

感謝Ajian、Fisher和Ben的審閱和建議！

參考

• https://utxos.org/
• https://bitcoincovenants.com/
• 與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-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.md
• CAT 和 Schnorr 技巧： https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

此材料僅供一般信息之用，不構成任何形式的投資建議、招攬或要約，也不應被解釋爲任何形式的投資建議或招攬，HashKey Capital對使用或依賴任何此類信息不承擔任何責任。

關注HashKey Capital的最新動態

網站 - https://hashkey.capital/

推特 - https://twitter.com/HashKey_Capital

領英 — https://www.linkedin.com/company/hashkeycapital/

聲明：

1.本文轉載自[medium]，版權歸原作者所有[Jeffrey Hu和 Harper Li]，如對轉載有異議，請聯系Gate Learn團隊，團隊將盡快按照相關流程處理。

2、免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。

3.文章的其他語言版本由Gate Learn團隊翻譯，文中未提及Gate.io，翻譯的文章不得轉載、轉發或抄襲。