jakiro
作者：Chakra；編譯：0xjs@比特鏈視界
本文為Chakra發表的比特幣擴展性系列文章的Part III。
第一部分參閱比特鏈視界此前文章「 比特幣原生擴容方案回顧：SegWit和Taproot 」，
第二部分參閱比特鏈視界此前文章「 比特幣可擴展性：Layer2方案和相關項目解析 」。
第三部分為本文，如下：
概述
相比以太坊等圖靈完備的區塊鏈，比特幣腳本被認為限制性極強，僅能進行基本運算，甚至不支持乘法和除法。更重要的是，區塊鏈自身的數據幾乎無法被腳本訪問，導致靈活性和可編程性嚴重不足。因此，人們一直在努力讓比特幣腳本實現內省（introspection）。
內省是指比特幣腳本檢查和約束交易數據的能力。這允許腳本根據特定的交易細節控制資金的使用，從而實現更複雜的功能。目前，大多數比特幣操作碼要麼將用戶提供的數據推送到堆棧上，要麼操縱堆棧上的現有數據。然而，內省操作碼可以將當前交易的數據（例如時間戳、金額、txid 等）推送到堆棧上，從而可以更精細地控制 UTXO 支出。
截至目前，比特幣腳本中只有三個主要操作碼支持內省：CHECKLOCKTIMEVERIFY、CHECKSEQUENCEVERIFY 和 CHECKSIG，以及其變體 CHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG 和 CHECKMULTISIGVERIFY。
契約（Covenant，也可譯作「限制條款」），簡單地說，是指對貨幣轉移方式的限制，允許用戶指定 UTXO 的分配方式。許多契約都是通過內省操作碼實現的，關於內省的討論現在已經被歸類到比特幣 Optech契約主題下。
比特幣目前有兩個契約，CSV（CheckSequenceVerify）和 CLTV（CheckLockTimeVerify），這兩個契約都是基於時間的契約，是許多擴容解決方案（如閃電網絡）的基礎。這說明了比特幣的擴容解決方案嚴重依賴於內省和契約。
我們如何為代幣的轉移添加條件？在加密貨幣領域，我們最常用的方法是通過承諾，通常通過哈希來實現。為了證明轉移要求得到滿足，還需要籤名機制進行驗證。因此，契約中存在許多對哈希和籤名的調整。
下面，我們將描述被廣泛討論的Covenant操作碼提案。
CTV（CheckTemplateVerify）BIP-119
CTV（CheckTemplateVerify）是BIP-119中的一個比特幣升級提案，引起了社區的廣泛關注。CTV允許輸出腳本指定交易中資金支出的模板，包括nVersion、nLockTime、scriptSig哈希、輸入計數、序列哈希、輸出計數、輸出哈希、輸入索引等欄位。這些模板限制是通過哈希承諾實現的，當資金被花費時，腳本會檢查支出交易中指定欄位的哈希值是否與輸入腳本中的哈希值匹配。這有效地限制了該UTXO未來交易的時間、方法和數量。
值得注意的是，輸入的 TXID 被排除在此哈希之外。這種排除是必要的，因為在傳統和隔離見證交易中，當使用默認的 SIGHASH_ALL 籤名類型時，TXID 取決於 scriptPubKey 中的值。包括 TXID 會導致哈希承諾中的循環依賴，從而無法構建。
CTV 的內省方式是直接拉取指定的交易信息進行哈希運算，然後與堆棧上的承諾進行比較。這種內省方式對鏈空間要求較低，但缺乏一定的靈活性。
比特幣二層解決方案（如閃電網絡）的基礎是預籤名交易。預籤名通常是指提前生成和籤署交易，但在滿足某些條件之前不廣播它們。本質上，CTV 實現了一種更嚴格的預籤名形式，將預籤名的承諾發布在鏈上，並限制在預定義的模板內。
CTV 最初是為了緩解比特幣的擁堵而提出的，這也可以稱為擁堵控制。在擁堵嚴重時，CTV 可以在單筆交易中承諾多筆未來交易，避免在尖峰時段廣播多筆交易，並在擁堵緩解後完成實際交易。這在交易所擠兌期間可能特別有用。此外，該模板還可用於實施 Vault 以防止黑客攻擊。由於資金流向是預先確定的，黑客無法使用 CTV 腳本將 UTXO 指向自己的地址。
CTV 可以顯著增強二層網絡。例如，在閃電網絡中，CTV 可以通過將單個 UTXO 擴展為 CTV 樹來創建超時樹和通道工廠，只需一筆交易和一次確認即可打開多個狀態通道。此外，CTV 還通過 ATLC 支持 Ark 協議中的原子交易。
APO（SIGHASH_ANYPREVOUT）BIP-118
BIP-118 為 tapscript 引入了一種新型籤名哈希標誌，旨在促進更靈活的支出邏輯，稱為 SIGHASH_ANYPREVOUT。APO 和 CTV 有很多相似之處。在解決 scriptPubKeys 和 TXID 之間的循環問題時，APO 的方法是排除相關輸入信息並僅對輸出進行籤名，從而允許交易動態綁定到不同的 UTXO。
從邏輯上講，籤名驗證操作OP_CHECKSIG（及其變體）執行三個功能：
1、組裝支出交易的各個部分。
2、對它們進行哈希處理。
3、驗證哈希是否已由給定的密鑰籤名。
籤名的具體細節具有很大的靈活性，由SIGHASH標誌決定對交易的哪些欄位進行籤名。根據BIP 342中簽名操作碼的定義，SIGHASH標誌分為SIGHASH_ALL，SIGHASH_NONE，SIGHASH_SINGLE和SIGHASH_ANYONECANPAY。SIGHASH_ANYONECANPAY控制輸入，而其他控制輸出。
SIGHASH_ALL 是默認的 SIGHASH 標誌，對所有輸出進行籤名；SIGHASH_NONE 不籤名任何輸出；SIGHASH_SINGLE 籤名特定輸出。SIGHASH_ANYONECANPAY 可以與前三個 SIGHASH 標誌一起設置。如果設置了 SIGHASH_ANYONECANPAY，則只對指定的輸入進行籤名；否則，必須對所有輸入進行籤名。
顯然，這些 SIGHASH 標誌並不能消除輸入的影響，即使是 SIGHASH_ANYONECANPAY，它也需要承諾一個輸入。
因此，BIP 118 提出了 SIGHASH_ANYPREVOUT。APO 籤名不需要承諾已花費的輸入 UTXO（稱為 PREVOUT），而只需籤署輸出，從而為比特幣控制提供更大的靈活性。通過預先構建交易並創建相應的一次性籤名和公鑰，發送到該公鑰地址的資產必須通過預先構建的交易來使用，從而實現契約。APO 的靈活性還可用於交易修復；如果交易因費用過低而卡在鏈上，則可以輕鬆創建另一筆交易來增加費用，而無需新的籤名。此外，對於多重籤名錢包來說，不依賴於已花費的輸入會使操作更加方便。
由於消除了 scriptPubKeys 和輸入 TXID 之間的循環，APO 可以通過在 Witness 中添加輸出數據來執行內省，儘管這仍然需要額外的 Witness 空間消耗。
對於閃電網絡和金庫（Vaults）等鏈下協議，APO 減少了保存中間狀態的需要，大大降低了存儲要求和複雜性。APO 最直接的用例是 Eltoo，它簡化了通道工廠，構建了輕量級且廉價的瞭望塔，並允許單邊退出而不留下錯誤狀態，從而在許多方面增強了閃電網絡的性能。APO 還可用於模擬 CTV 功能，儘管它要求個人存儲籤名和預籤名交易，這比 CTV 更昂貴且效率更低。
APO 的主要批評集中在它需要一個新的密鑰版本，而這不能通過簡單的向後兼容來實現。此外，新的籤名哈希類型可能會帶來雙重支付的潛在風險。經過廣泛的社區討論，APO 在原有的籤名機制之上增加了常規籤名以緩解安全擔憂，從而獲得了 BIP-118 代碼。
OP_VAULT BIP-345
BIP-345 提議增加兩個新的操作碼，OP_VAULT 和 OP_VAULT_RECOVER，它們與 CTV 結合使用時，可實現專門的契約，允許用戶強制延遲使用特定貨幣。在此延遲期間，可以通過恢復路徑「撤銷」之前進行的交易。
用戶可以通過創建特定的 Taproot 地址來創建 Vault，該地址必須在其 MAST 中包含至少兩個腳本：一個帶有 OP_VAULT 操作碼以促進預期的提款過程，另一個帶有 OP_VAULT_RECOVER 操作碼以確保在提款完成之前可以隨時恢復代幣。
OP_VAULT 如何實現可中斷的定時鎖定提款？OP_VAULT 通過用指定腳本替換已使用的 OP_VAULT 腳本來實現這一點，從而有效地更新 MAST 的單個葉子，同時保持其餘 Taproot 葉子節點不變。此設計類似於 TLUV，只是 OP_VAULT 不支持對內部密鑰的更新。
通過在腳本更新過程中引入模板，可以限制付款。時間鎖參數由OP_VAULT指定，CTV操作碼的模板限制了可以通過此腳本路徑使用的輸出集。
BIP-345 專為Vaults設計，利用 OP_VAULT 和 OP_VAULT_RECOVER 為用戶提供安全的託管方法，使用高度安全的密鑰（例如紙錢包或分布式多重籤名）作為恢復路徑，同時為定期付款配置一定的延遲。用戶的設備會持續監控保險庫的支出，如果發生意外轉帳，用戶可以啟動恢復。
通過 BIP-345 實現 Vault 需要考慮成本問題，尤其是對於恢復交易。可能的解決方案包括 CPFP（子節點為父節點付費）、臨時錨點和新的 SIGHASH_GROUP 籤名哈希標誌。
TLUV（TapleafUpdateVerify）
TLUV 方案圍繞 Taproot 構建，旨在有效解決共享 UTXO 退出問題。指導原則是，當 Taproot 輸出被使用時，可以通過加密轉換和 Taproot 地址的內部結構對內部密鑰和 MAST（tapscript trie）進行部分更新，如 TLUV 腳本所述。這使得 Covenant 功能的實現成為可能。
TLUV 方案的概念是通過引入新的操作碼 TAPLEAF_UPDATE_VERIFY 根據當前支出輸入創建一個新的 Taproot 地址。這可以通過執行以下一項或多項操作來實現：
-
更新內部公鑰
-
修剪 Merkle 路徑
-
刪除當前正在執行的腳本
-
在 Merkle 路徑末尾添加新步驟
具體來說，TLUV 接受三種輸入：
-
指定如何更新內部公鑰。
-
為 Merkle 路徑指定新步驟的一種方法。
-
指定是否刪除當前腳本和/或要修剪 Merkle 路徑的多少步。
TLUV操作碼計算更新的scriptPubKey，並驗證當前輸入對應的輸出是否花在這個scriptPubKey上。
TLUV 的靈感來源於 CoinPool 的概念。如今，聯合資金池僅需預先籤名的交易即可創建，但如果要實現無需許可的退出，則需要創建數量成倍增長的籤名。而 TLUV 則允許無需許可的退出，無需任何預先籤名。例如，一組合作夥伴可以使用 Taproot 構建共享的 UTXO，將他們的資金匯集在一起 。他們可以使用 Taproot 密鑰在內部轉移資金，也可以聯合籤名以在外部發起付款。個人可以隨時退出共享資金池，刪除他們的付款路徑，而其他人仍可以通過原始路徑完成付款，並且個人的退出不會暴露有關內部其他人的其他信息。與非池化交易相比，這種模式更高效、更私密。
TLUV 操作碼通過更新原始 Taproot Trie 實現了部分支出限制，但它沒有實現對輸出金額的自省。因此，還需要一個新的操作碼 IN_OUT_AMOUNT。此操作碼將兩個項目推送到堆棧上：此輸入的 UTXO 金額和相應輸出的金額，然後使用 TLUV 的人需要使用數學運算符來驗證資金是否適當地保留在更新的 scriptPubKey 中。
輸出金額的內省增加了複雜性，因為以 satoshis 為單位的金額需要最多 51 位來表示，但腳本僅允許進行 32 位數學運算。這需要重新定義操作碼行為以升級腳本中的運算符或使用 SIGHASH_GROUP 替換 IN_OUT_AMOUNT。
TLUV 有潛力成為去中心化第 2 層資金池的解決方案，但其調整 Taproot Trie 的可靠性仍需確認。
MATT
MATT（Merkleize All The Things）旨在實現三個目標：Merkleizing the state、Merkleizing the script、Merkleizing the performing，從而實現通用智能合約。
-
對狀態進行 Merkle 化（Merkleizing the state）：這涉及構建 Merkle Trie，其中每個葉節點代表一個狀態的哈希值，而 Merkle Root 則體現合約的整體狀態。
-
對腳本進行 Merkle 化（Merkleizing the script）：這指的是使用 Tapscript 形成 MAST，其中每個葉節點代表一種可能的狀態轉換路徑。
-
Merkle 化執行（Merkleizing the performing）：通過加密承諾和欺詐挑戰機制對執行進行 Merkle 化。對於任何計算函數，參與者可以在鏈下計算，然後發布承諾 f(x)=y。如果其他參與者發現錯誤結果 f(x)=z，他們可以發起挑戰。仲裁通過二分搜索進行，類似於 Optimistic Rollup 的原理。
默克爾化執行
為了實現 MATT，比特幣腳本語言需要具備以下功能：
-
強制輸出具有特定腳本（及其數量）
-
將一段數據附加到輸出
-
從當前輸入（或另一個輸入）讀取數據
第二點至關重要：動態數據意味著可以通過消費者提供的輸入數據來計算狀態，因為這允許模擬狀態機，能夠確定下一個狀態和附加數據。MATT 方案通過 OP_CHECKCONTRACTVERIFY (OP_CCV) 操作碼實現這一點，該操作碼是之前提出的 OP_CHECKOUTPUTCONTRACTVERIFY 和 OP_CHECKINPUTCONTRACTVERIFY 操作碼的合併，使用附加標誌參數來指定操作的目標。
控制輸出金額：最直接的方法是直接內省；但是，輸出金額是 64 位數字，需要 64 位算術，這在比特幣腳本中帶來了很大的複雜性。OP_CCV 採用延遲檢查方法，如 OP_VAULT，其中 CCV 中相同輸出的所有輸入的輸入金額相加，作為該輸出金額的下限。延遲是因為此檢查發生在交易過程中，而不是在腳本評估輸入期間。
鑑於欺詐證明的普遍性，MATT 合約的某些變體應該能夠實現所有類型的智能合約或 2 層構造，儘管需要準確評估額外要求（例如資金鎖定和挑戰期延遲）；需要進一步研究以評估哪些應用程式可以接受交易。例如，使用加密承諾和欺詐挑戰機制來模擬 OP_ZK_VERIFY 函數，在比特幣上實現無需信任的 Rollups。
實踐上，事情已經發生了。Johan Torås Halseth 利用 MATT 軟分叉提案中的 OP_CHECKCONTRACTVERIFY 操作碼實現了elftrace，這使得任何支持 RISC-V 編譯的程序都可以在比特幣區塊鏈上進行驗證，從而使合約協議中的一方能夠通過合約驗證來訪問資金，從而橋接比特幣原生驗證。
CSFS（OP_CHECKSIGFROMSTACK）
從APO操作碼的介紹中我們了解到OP_CHECKSIG（及其相關操作）負責組裝交易、哈希計算和驗證籤名。但是這些操作驗證的消息是通過操作碼序列化交易而來的，不允許指定任何其他消息。簡單來說，OP_CHECKSIG（及其相關操作）的作用是通過籤名機制來驗證作為交易輸入被花費的UTXO是否被籤名持有者授權使用，從而保護比特幣的安全。
CSFS，顧名思義，就是從堆棧中檢查籤名（Checks the Signature From Stack）。CSFS操作碼從堆棧中接收三個參數：籤名、消息和公鑰，並驗證籤名的有效性。這意味著人們可以通過見證人將任何消息傳遞到堆棧，並通過 CSFS 進行驗證，從而實現比特幣的一些創新。
CSFS 的靈活性使其能夠實現諸如支付籤名、授權委託、預言機合約、雙重支付保護保證以及更重要的交易自省等機制。使用 CSFS 進行交易內省的原理非常簡單：如果 OP_CHECKSIG 使用的交易內容通過見證者推送到堆棧，並且使用相同的公鑰和籤名對 OP_CSFS 和 OP_CHECKSIG 進行驗證，並且如果兩次驗證都成功通過，則傳遞給 OP_CSFS 的任意消息內容與 OP_CHECKSIG 隱式使用的序列化支出交易（和其他數據）相同。然後我們在堆棧上獲得經過驗證的交易數據，這些數據可用於對使用其他操作碼的支出交易施加限制。
CSFS 經常與 OP_CAT 一起出現，因為 OP_CAT 可以連接交易的不同欄位以完成序列化，從而可以更精確地選擇自省所需的交易欄位。如果沒有 OP_CAT，腳本就無法從可以單獨檢查的數據中重新計算哈希值，因此它真正能做的是檢查哈希值是否對應於特定值，這意味著只能通過單個特定交易來使用代幣。
CSFS 可以實現 CLTV、CSV、CTV、APO 等操作碼，使其成為多功能內省操作碼。因此，它也有助於比特幣 2 層的可擴展性解決方案。缺點是它需要在堆棧上添加已籤名交易的完整副本，這可能會顯著增加使用 CSFS 自省的交易的大小。相比之下，像 CLTV 和 CSV 這樣的單一用途內省操作碼的開銷很小，但添加每個新的特殊內省操作碼都需要進行共識更改。
TXHASH (OP_TXHASH)
OP_TXHASH 是一個簡單的內省操作碼，允許operator選擇特定欄位的哈希並將其推送到堆棧上。具體來說，OP_TXHASH 從堆棧中彈出一個 txhash 標誌，並根據該標誌計算（帶標籤的）txhash，然後將生成的哈希推送回堆棧。
由於TXHASH與CTV的相似性，社區內對兩者產生了大量討論。
TXHASH 可以看作是 CTV 的通用升級，它提供了更高級的交易模板，允許用戶明確指定支出交易的各個部分，解決了許多與交易費用相關的問題。與其他 Covenant 操作碼不同，TXHASH 不需要見證中必要數據的副本，從而進一步降低了存儲要求；與 CTV 不同，TXHASH 不兼容 NOP，只能在 tapscript 中實現；TXHASH 和 CSFS 的組合可以作為 CTV 和 APO 的替代方案。
從構建契約的角度來看，TXHASH 更有利於創建「加法契約」，其中你希望修復的所有交易數據部分都被推送到堆棧上，一起進行哈希處理，並驗證生成的哈希是否與固定值匹配；CTV 更適合創建「減法契約」，其中你希望保持自由的所有交易數據部分都被推送到堆棧上。然後，使用滾動 SHA256 操作碼，哈希處理從固定的中間狀態開始，該狀態提交到交易哈希數據的前綴。自由部分被哈希到這個中間狀態。
TXHASH規範中定義的TxFieldSelector欄位預計會擴展到其他操作碼，比如OP_TX。
與TXHASH相關的BIP目前在GitHub上處於Draft狀態，尚未分配編號。
OP_CAT
OP_CAT 是一個神秘的操作碼，最初被中本聰出於安全考慮而放棄，但最近卻引發了比特幣核心開發者的激烈討論，甚至在網絡上掀起了 Meme 文化。最終，OP_CAT 在 BIP-347 下獲得批准，被稱為近期最有可能通過的 BIP 提案。
事實上，OP_CAT 的行為非常簡單：它將兩個來自堆棧的元素連接起來。它如何實現 Covenant 功能？
事實上，連接兩個元素的能力對應著一個強大的加密數據結構：Merkle Trie。要構建 Merkle Trie，只需要連接和哈希運算，而比特幣腳本中提供了哈希函數。因此，使用 OP_CAT，我們理論上可以在比特幣腳本中驗證 Merkle 證明，這是區塊鏈技術中最常見的輕量級驗證方法之一。
前面提到，CSFS 藉助 OP_CAT 可以實現通用的 Covenant 方案。實際上，即使沒有 CSFS，利用 Schnorr 籤名的結構，OP_CAT 本身也可以實現交易內省。
在Schnorr籤名中，需要籤名的消息由以下欄位組成：
這些欄位包含交易的主要元素。通過將它們放在 scriptPubKey 或 Witness 中，並使用 OP_CAT 結合 OP_SHA256，我們可以構造 Schnorr 籤名並使用 OP_CHECKSIG 進行驗證。如果驗證通過，堆棧將保留已驗證的交易數據，從而實現交易自省。這使我們能夠提取和「檢查」交易的各個部分，例如其輸入、輸出、目標地址或所涉及的比特幣金額。
關於具體的密碼學原理，可以參考Andrew Poelstra的文章《CAT and Schnorr Tricks》。
總而言之，OP_CAT 的多功能性使其能夠模擬幾乎任何 Covenant 操作碼。許多 Covenant 操作碼都依賴於 OP_CAT 的功能，這大大提升了其在合併列表中的位置。從理論上講，僅依靠 OP_CAT 和現有的比特幣操作碼，我們就有希望構建一個信任最小化的 BTC ZK Rollup。Starknet、Chakra 和其他生態系統合作夥伴正在積極推動這一目標的實現。
結論
當我們探索擴展比特幣和增強其可編程性的各種策略時，很明顯，前進的道路涉及原生改進、鏈下計算和複雜腳本功能的融合。
如果沒有靈活的基礎層，就不可能構建更靈活的二層。
鏈下計算擴展是未來的趨勢，但比特幣的可編程性需要突破，才能更好地支持這種擴展性並成為真正的全球貨幣。
然而，比特幣上的計算性質與以太坊上的計算性質有著根本區別。比特幣只支持「驗證」作為一種計算形式，無法執行一般計算，而以太坊本質上是計算性的，驗證是計算的副產品。從一點可以看出這種區別：以太坊對無法執行的交易收取 Gas Fee，而比特幣則不收取。
契約是一種基於驗證而非計算的智能合約形式。除了少數中本聰原教旨主義者外，似乎所有人都認為契約是改進比特幣的好選擇。然而，社區仍在激烈爭論應該採用哪種方法來實現契約。
APO、OP_VAULT、TLUV 偏向直接應用，選擇這三種方式可以更便宜更高效地實現特定應用。閃電網絡愛好者會選擇 APO 來實現 LN-Symmetry；想要實現 Vault 的用戶最好使用 OP_VAULT；而對於搭建 CoinPool，TLUV 可以提供更好的隱私性和效率。OP_CAT 和 TXHASH 功能更豐富，出現安全漏洞的概率更小，與其他操作碼結合可以實現更多用例，但代價可能是腳本複雜度增加。CTV 和 CSFS 調整了區塊鏈處理方式，CTV 實現延遲輸出，CSFS 實現延遲籤名。MATT 以樂觀執行和欺詐證明的策略脫穎而出，利用 Merkle Trie 結構實現通用智能合約，但內省功能仍需要新的操作碼。
我們看到比特幣社區正在積極討論通過軟分叉獲得 Covenants 的可能性。Starknet 已正式宣布加入比特幣生態，計劃在 OP_CAT 合併後六個月內在比特幣網絡上實現結算。Chakra 將繼續關注比特幣生態的最新動態，推動 OP_CAT 軟分叉的合併，並利用 Covenants 帶來的可編程性構建更安全、更高效的比特幣結算層。
