OP_CCV提案列入BIP 443草案，比特幣合約狀態可延續至下一筆交易

OP_CCV提案讓比特幣（BTC）交易結束後，合約狀態仍可延續至下一筆交易，目前正以BIP 443草案形式討論。這項設計會檢查資金移動時，合約狀態是否依照既定規則更新。

Cointelegraph Research於11日發布的比特幣 Covenant 分析第五篇，說明MATT與OP_CHECKCONTRACTVERIFY（OP_CCV）的運作方式。MATT（Merkleize All The Things）是一套試圖在交易之間傳遞狀態的設計框架，OP_CCV則是其中一種實作方式。

Salvatore Ingala於2022年11月8日首次在比特幣開發者郵件論壇提出MATT。OP_CCV規格則收錄於2025年5月8日取得編號的BIP 443草案。

比特幣腳本會逐筆檢查交易條件，但本身不會記住前一筆交易中的合約狀態。Covenant指限制使用UTXO的方式，或限制下一筆交易輸出的規則。UTXO是尚未花費的交易輸出，用來構成比特幣餘額。

MATT會將合約狀態的密碼學承諾寫入Taproot輸出金鑰。使用UTXO建立下一筆交易的輸出時，狀態資料也會依照新狀態延續。

使用者花費UTXO時，必須在交易的見證資料（witness）中提供狀態資料，腳本再根據這些資料執行指定運算。

OP_CCV不會代替腳本執行運算，而是檢查輸入與新輸出的合約規則（腳本）及狀態承諾是否符合條件。若條件不符，交易驗證就會失敗。

BIP 443規定，輸入金額可全數保留在指定輸出，或將部分金額分配至多個輸出後，再檢查剩餘金額等方式。如此一來，設計除了能限制狀態變化，也能約束合約資金的流向。

在這種金額保留架構下，難以直接從金庫型UTXO扣除交易手續費。MIT數位貨幣倡議在報告中分析指出，啟動提款流程的交易手續費無法由金庫UTXO支付，復原交易的手續費也無法由已提款的UTXO支付，因此設計時需考慮額外的手續費支付輸入等方式。

金庫（vault）是一種在提款流程中加入條件與延遲步驟，以因應未授權提款嘗試的保管架構。若提款流程啟動後發現問題，也可設計將資金轉往更安全地址的路徑。

MIT數位貨幣倡議於9月8日發布的金庫設計比較報告分析指出，採用CCV的設計可支援部分提款，也能在提款流程啟動階段選擇提款地址。部分提款是指領出部分資金，同時將其餘資金留在金庫中。

OP_CAT是另一項提案，可將堆疊上的兩筆資料串接。有人提出，可將它與MATT搭配使用，以建構更多功能，例如驗證默克爾證明。

依照這項構想，較長的運算可在鏈下執行；若對運算結果有異議，再搭配默克爾證明，將有爭議的計算步驟提交鏈上驗證。這是結合MATT與OP_CAT的應用構想，並不代表比特幣主網目前已具備這項功能。

Bitcoin Inquisition已為BIP 443指派BIN-2026-0002識別碼，但取得識別碼不代表已完成測試網部署。實作PR #102目前仍在公開審查中，BIP 443的啟用方式與時程尚未確定。

關於OP_CAT的BIP 347，規格狀態標示為「Complete」。規格完成與採納至比特幣主網仍是不同階段。