比特幣合約 (Covenants)：從基礎到 OP_VA 最新升級

理解比特幣腳本限制與合約實現的可能性。

比特幣的腳本系統長期以來有一個根本限制：無法限制資金的未來用途。傳統比特幣腳本只驗證當前交易的簽名，無法約束比特幣被花費後的流向。Covenants（合約）機制旨在打破這一限制，允許開發者對「未來花費條件」設限，實現諸如 Vault（比特幣金庫）、受限提款、機構級風控等應用場景。然而，這種能力也伴隨著設計失誤可能導致資金永久鎖定的風險，因此必須審慎設計 emergency path（緊急恢復路徑）。

比特幣腳本的原生限制

比特幣採用的腳本語言 Bitcoin Script 設計上刻意保持簡單，以確保安全性。其核心限制體現在以下幾個層面：

首先，腳本無法存取交易輸出本身的金額資訊。在 OP_CHECKSIG 相關操作碼執行時，簽名驗證只確認簽名有效性，無法限制花費金額。這意味著即使設定了輸出腳本，也無法確保比特幣被花費時的金額符合預期。

其次，腳本無法引用父交易的資訊。比特幣的 UTXO 模型設計中，每筆交易只能花費來自先前交易的輸出，無法在花費時驗證資金的來源歷史。這種設計雖然保護了隱私，但同時也阻礙了更複雜的金融合約實現。

第三，腳本無法限制自身的修改。由於比特幣腳本在設定後無法自我修改，任何發送到該腳本的比特幣，一旦設定了花費條件，就無法在不滿足條件的情況下轉移。這是比特幣「不可逆轉」特性的體現，但也帶來了操作失誤導致資金永久鎖定的風險。

Covenants 的核心概念與類型

Covenants（合約）機制的核心思想是：允許比特幣所有者設定不僅限於「誰可以花費」，還包括「如何花費」、「花費到哪裡」、「花費多少」等更細緻的限制條件。這些限制在比特幣被鎖入腳本時就已經確定，且無法被繞過。

金額限制 Covenant

金額限制是最直觀的 Covenant 類型。透過限制每次花費的最高金額，可以防止大規模資金被一次性盜走。例如，一個養老金儲蓄帳戶可以設定每日最多提取總額的 1%，即使私鑰洩露，攻擊者也無法在短期內轉移全部資金。

金額限制的典型應用場景包括：家庭共享帳戶（限制未成年人的每日提取額度）、企業金庫（多簽名加上金額上限）、遺產規劃（設定受益人的定期領取規則）。這種機制類似於傳統銀行帳戶的轉帳限額，但完全由密碼學而非中心化機構執行。

時間鎖 Covenant

時間鎖 Covenant 允許設定資金的「冷卻期」。在發起提款後，需要經過一段時間（如 24 小時或 7 天）才能完成轉账。在這段冷卻期內，如果帳戶所有者發現異常活動，可以發起取消交易，將資金轉入另一個安全地址。

這種機制的設計靈感來自傳統金融的「電匯撤回」功能，但在比特幣網路中以去中心化的方式實現。時間鎖的長度選擇需要權衡安全性與便利性：過短則無法有效阻止攻擊，過長則影響正常使用的靈活性。

目的地限制 Covenant

目的地限制 Covenant 允許限定比特幣只能被發送到特定地址或地址集合。例如，一個慈善捐贈帳戶可以設定資金只能用於特定幾個已批准的慈善機構地址；一個家族辦公室可以確保資金永遠留在「家族地址」集合內。

這種機制的實現需要使用比特幣腳本的 OPCHECKTEMPLATEVERIFY（原 OPSECURETHEBAG）或其他類似操作碼，允許輸出腳本指定未來交易的輸出模板。

遞迴 Covenant 與狀態機

更進階的 Covenant 實現允許資金在滿足特定條件後，自動轉入另一個具有類似限制的新腳本。這種「遞迴」設計可以實現完整的狀態機邏輯，例如：

• 狀態 1：資金鎖定，需要 3 把私鑰中的 2 把簽名
• 狀態 2：觸發報警條件後，資金進入 7 天冷卻期
• 狀態 3：冷卻期結束，資金只能轉入預設的恢復地址

這種狀態機設計可以實現類似智慧合約的複雜邏輯，同時保持比特幣網路的簡單性。

主流 Covenant 提案深度解析

比特幣社群提出了多種實現 Covenant 的提案，每種提案在功能性、可審計性、風險程度和實現複雜度之間有不同的取捨。

OPCHECKTEMPLATEVERIFY (OPSTB / BIP-119)

OP_CHECKTEMPLATEVERIFY（CTV）是最早被提出且最被廣泛討論的 Covenant 提案之一。由 Bitcoin Core 開發者 Jeremy Rubin 提出的 BIP-119，允許輸出腳本指定未來交易的「模板」，限制花費交易必須符合預定義的輸出格式。

CTV 的核心機制是「輸出模板匹配」。當設定一個 CTV 輸出時，輸出腳本包含了一個 commitment（承諾），指定了未來花費時必須滿足的輸出數量、金額和地址。任何試圖花費這個輸出的交易，其輸出必須與這個模板完全匹配。

CTV 輸出腳本範例：
OP_CHECKTEMPLATEVERIFY <commitment_hash>
OP_DROP
OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

CTV 的優勢在於其簡單性和可預測性。由於模板在資金鎖定時就已經確定，且無法被修改，因此合約的行為是完全確定的。然而，這種確定性也是其限制：無法實現需要動態調整的邏輯。

CTV 的主要應用場景包括：

1. 比特幣金庫（Bitcoin Vaults）：設定提款冷卻期和取消機制
2. 承諾市場（Commitment Markets）：允許用戶鎖定資金並承諾在未來某個時間進行結算
3. 儲蓄帳戶：限制每日提取金額
4. 遺產規劃：確保資金只能轉入預設的受益人地址

OP_CAT 與腳本可表達性

OPCAT 是比特幣操作碼家族中的「復古」成員。這個操作碼最初在比特幣早期版本中存在，後來因為安全考量被禁用。2024 年，BIP-347 提議重新啟用 OPCAT，允許將兩個腳本元素連接成一個。

OPCAT 的價值在於其「可組合性」。雖然 OPCAT 本身不是 Covenant 提案，但它極大地增強了腳本的可表達性，使得實現更複雜的 Covenant 邏輯成為可能。

OP_CAT 使用範例：
<element_a> <element_b> OP_CAT → <element_a + element_b>

例如，透過 OP_CAT 可以動態構造簽名所需的訊息，實現「簽名覆蓋輸出」的效果。這種能力可以與 Covenant 機制結合，實現更靈活的資金控制邏輯。

OP_CAT 的支持者認為，這是比特幣腳本語言的「缺失拼圖」，可以解鎖大量的創新應用。批評者則擔心它可能增加腳本複雜度，帶來意外的安全風險。

OP_VA：最新的 vault 導向 Covenant 提案

OPVA（Vaults with Annotations）是 2024 年提出的最新 Covenant 提案，由比特幣開發者 Ethan T. Clark 和 Bryan Bishop 共同設計。OPVA 專為實現安全的比特幣金庫（Vault）而優化，提供了比 CTV 更精細的控制能力。

OPVA 的核心創新是「註釋」（Annotations）機制。每個 OPVA 輸出可以附加多個「註釋」，這些註釋在花費時可以選擇性地暴露或隱藏。透過巧妙設計註釋的暴露條件，可以實現帶有緊急恢復路徑的 Vault 邏輯。

OP_VA 腳本結構：
OP_VA <annotations> <policy> <data>

OP_VA 的 policy（策略）參數定義了花費規則，包括：

• 花費閾值：需要多少簽名才能觸發特定動作
• 延遲時間：觸發後需要等待多長時間
• 恢復目的地：緊急情況下資金可以轉入的地址集合

OPVA 的設計特別強調「可恢復性」。傳統 Vault 的一個主要風險是：如果用戶忘記了 Vault 的設定或遺失了解鎖所需的資訊，資金將永久鎖定。OPVA 透過強制包含「緊急恢復路徑」來解決這個問題，確保即使主要設定遺失，資金仍可透過備用方式轉出。

LNOE 與 ANYPREVOUT

LNOE（Leaf-Script Modification of Existing Outputs）是另一種 Covenant 實現思路，透過修改比特幣的葉腳本（Leaf Script）來實現輸出限制。ANYPREVOUT（APO）是 BIP-118 提出的提案，允許簽名不綁定特定的輸出 ID，使得簽名可以對多個潛在輸出重複使用。

APO 與 Covenant 的結合特別強大。例如，可以創建一個輸出，其花費規則是「任何滿足特定簽名條件的交易」，而不需要指定具體的輸出地址。這打開了「閃電網路風格的 Channel 工廠」等創新應用的大門。

OP_CSFS 與共識關鍵 Covenant

OPCSFS（OPCheckSigFromStack）是另一個增強比特幣腳本的提案，允許腳本驗證任意訊息的簽名，而不僅僅是交易本身的簽名。雖然 OP_CSFS 不是直接的 Covenant 提案，但它可以與其他機制結合，實現更複雜的合約邏輯。

共識關鍵 Covenant（Consensus-Violating Covenants）是一個特殊的類別，它們透過共識規則層面的修改來實現 Covenant 功能，而非僅僅依賴腳本層面的驗證。這種方法的優勢是可以實現更強大的限制，缺點是需要更廣泛的共識變更，實施難度更高。

Vault（比特幣金庫）實現深度分析

比特幣金庫是 Covenant 最重要的應用場景之一。一個設計良好的 Vault 可以同時保護資金免受盜竊和用戶自身操作失誤的影響。

經典 Vault 設計

經典的比特幣金庫設計包含兩個主要地址：

1. 主地址（Main Vault Address）：這是資金的主要存放處。從這個地址提款需要滿足特定的延遲條件。

1. 恢復地址（Recovery Address）：這是緊急情況下資金的最終歸屬。如果用戶發現異常提款，可以立即觸發將資金轉入恢復地址的流程。

典型的 Vault 工作流程如下：

存款階段：用戶將比特幣發送至主地址。這個地址的腳本設定了提款規則，例如：

• 正常路徑：需要用戶的簽名，觸發 24 小時延遲
• 緊急路徑：需要用戶的另一把私鑰（存放在異地），可立即轉入恢復地址

正常提款：用戶發起提款請求。交易進入「待確認」狀態，開始 24 小時倒數計時。在這段時間內，如果用戶沒有取消交易，資金將在倒數結束後轉入指定地址。

取消提款：如果在延遲期內發現異常，用戶可以發起「取消交易」。這個交易使用緊急路徑，將資金直接轉入恢復地址。為防止攻擊者同樣使用緊急路徑，緊急路徑通常需要不同的私鑰或額外的認證因素。

Vault 設計的關鍵參數

設計一個安全的 Vault 需要仔細選擇以下參數：

延遲時間（Delay Period）：這是用戶發現異常後可以取消提款的時間窗口。建議值為 24-72 小時。選擇時需要考慮：

• 用戶檢查帳戶的頻率
• 區塊鏈確認時間
• 攻擊者可能的下次攻擊時間

取消窗口（Cancellation Window）：這是延遲結束後、資金實際轉出前的額外緩衝時間。建議值為 4-12 小時，用於處理邊緣情況。

恢復路徑數量：建議至少設計兩條獨立的恢復路徑：

• 快速路徑：用於緊急情況，需要較高的認證閾值
• 慢速路徑：用於一般性故障恢復，允許更長的處理時間

分割策略：對於大額資金，建議分散存放在多個獨立的 Vault 中，而非集中存放。這樣即使一個 Vault 被攻破，損失也有限。

多方 Vault 與機構級風控

機構級 Vault 需要支援多方參與的決策流程。這種「多方 Vault」的典型配置包括：

• 管理員集合：有權發起提款請求的授權個人
• 審批者集合：需要批准提款請求的獨立的個人或實體
• 緊急恢復者：在緊急情況下可以激活備用方案的授權方

例如，一個家族辦公室的 Vault 可能有 5 位管理員（家族成員）、2 位審批者（外部律師和會計師）、以及 1 位緊急恢復者（家族信任的摯友）。提款需要 3 位管理員中的 2 位發起、2 位審批者批准，然後進入 48 小時延遲期。在延遲期內，任何管理員可以使用緊急權力將資金轉入預設的安全地址。

這種多方參與的設計可以有效防止內部盜竊和單點故障，同時保持資金的可訪問性。

Covenants 的風險與緩解策略

Covenants 機制的最大風險在於：一旦設定錯誤，資金可能永久鎖定。與傳統比特幣交易不同，Covenant 限制是在協議層面執行的，無法透過「雙花」或其他方式繞過。

操作失誤風險

設定 Covenant 時的常見錯誤包括：

1. 腳本邏輯錯誤：例如，鎖時間條件寫反，導致延遲期過後反而無法提款
2. 密鑰丟失：與 Covenant 關聯的私鑰遺失，導致無法滿足花費條件
3. 升級不相容：比特幣協議升級導致原有腳本無法正確執行
4. 模板僵化：過度限制的輸出模板，無法適應未來的需求變化

緩解策略

緊急恢復路徑設計：每個 Covenant 都應該包含至少一條緊急恢復路徑，允許在主路徑失效時轉出資金。緊急路徑應該：

• 使用與主路徑完全獨立的密鑰
• 不依賴任何可能失效的時間鎖
• 經過充分測試

漸進式部署：新設計的 Covenant 合約應該先在測試網上運行，確認行為符合預期後再部署到主網。初期應該只鎖定少量資金，待運行一段時間後再逐步增加鎖定金額。

模板版本化：為 Covenant 模板引入版本號，方便未來升級。例如：

OP_IF
    OP_VA <version_1_policy>
OP_ELSE
    OP_VA <version_2_policy>
OP_ENDIF

失敗路徑測試：在部署前，必須測試所有可能的失敗場景，包括：

• 正常提款流程
• 取消提款流程
• 緊急恢復流程
• 部分簽名失效的情況
• 時間鎖觸發邊界情況

跨錢包相容性

不同的比特幣錢包可能對 Covenant 類型的支持程度不同。在設計 Covenant 解決方案時，需要考慮：

1. 錢包兼容性：確認目標用戶使用的錢包能夠正確解析和簽名 Covenant 交易
2. 升級路徑：設計從舊版本腳本遷移到新版本的可行路徑
3. 降級策略：當新版本發現問題時，如何回退到舊版本

OP_VA 技術規格深度解析

作為最新的 Covenant 提案，OP_VA 提供了專門針對 Vault 應用優化的功能集。以下是其核心技術規格：

Annotations（註釋）機制

OP_VA 輸出可以附加多個「註釋」，每個註釋包含：

• 狀態標記：表示該註釋當前是「隱藏」還是「暴露」
• 暴露條件：定義在什麼條件下該註釋會被暴露
• 數據內容：註釋實際攜帶的數據

註釋結構範例：
{
    "annotation_id": 0,
    "state": "HIDDEN",
    "reveal_condition": "AFTER_DELAY",
    "content": <recovery_address>
}

註釋的暴露是單向的：一旦暴露，就無法再次隱藏。這確保了 Vault 的安全性：攻擊者即使獲得了延遲後的簽名，也無法利用暴露的資訊進行進一步攻擊。

Policy（策略）引擎

OP_VA 的 policy 參數定義了 Vault 的完整行為規範，包括：

花費條件（Spending Conditions）：定義什麼情況下可以花費資金。例如：

• thresh(2, pk(A), pk(B), pk(C))：需要 A、B、C 中任意 2 把簽名
• after(2025-01-01)：只能在此日期後花費
• older(144)：需要至少 144 個區塊確認

延遲配置（Delay Configuration）：定義提款的延遲參數：

{
    "delay_period": 144,  // 144 個區塊，約 1 天
    "cancellation_window": 6,  // 6 個區塊，約 1 小時
    "fast_path_threshold": 1000  // 小於此金額可使用快速路徑
}

恢復目的地（Recovery Destinations）：定義緊急情況下的資金去向：

{
    "primary_recovery": <primary_recovery_address>,
    "secondary_recovery": <backup_address>,
    "timeout": 525600  // 1 年後自動轉入備份地址
}

範例腳本

以下是一個完整的 OP_VA Vault 腳本範例：

OP_VA
    <annotations>
        // 註釋 0：恢復地址（延遲後暴露）
        {
            "id": 0,
            "reveal_after": 144,
            "content": <recovery_pubkey>
        }
        // 註釋 1：快速取消密鑰（立即可用）
        {
            "id": 1,
            "reveal_condition": "IMMEDIATE",
            "content": <cancel_pubkey>
        }
    </>
    <policy>
        // 主提款路徑：需要 2/3 簽名 + 144 區塊延遲
        {
            "condition": "thresh(2, pk(user1), pk(user2), pk(user3))",
            "delay": 144,
            "fast_path": false
        }
        // 取消路徑：需要 cancel 密鑰
        {
            "condition": "pk(cancel)",
            "delay": 0,
            "destination": <recovery_address>
        }
    </>
    <data>
        // 附加元數據
        {
            "created": 1706745600,
            "version": "1.0",
            "vault_type": "personal"
        }
    </>
OP_DROP

實際部署考量

測試網驗證

在部署 OP_VA 合約到主網前，強烈建議：

1. 單元測試：使用 Bitcoin Core 的功能測試框架，驗證腳本邏輯的每個分支
2. 模擬運行：在 Signet 或 Testnet 上進行完整的存款、提款、取消流程
3. 壓力測試：模擬各種邊界條件和異常情況
4. 安全審計：聘請專業比特幣安全團隊進行代碼審計

監控與告警

運營 Vault 服務時，應建立完善的監控體系：

• 異常提款檢測：監控大額或異常時間的提款請求
• 延遲期追蹤：追蹤所有待處理的提款，確保及時響應
• 密鑰健康檢查：定期驗證所有相關密鑰仍可正常使用
• 區塊鏈狀態監控：監控比特幣網路的健康狀況和潛在的分叉風險

備份與災難恢復

確保所有 Vault 相關的關鍵資訊都有備份：

• 腳本模板和版本歷史
• 所有相關私鑰的備份（存放在不同地理位置）
• 緊急恢復程序的文檔
• 測試記錄和參數選擇的理由

結論

比特幣 Covenant 機制代表了比特幣腳本系統的重大進化。從最早的金額限制、時間鎖，到最新的 OP_VA 專門優化，比特幣正在逐步獲得實現複雜金融合約的能力，同時保持其去中心化和安全性的核心特性。

然而，這種能力的獲得伴隨著新的責任。Covenant 設計中的任何失誤都可能導致資金永久鎖定，這是比特幣「不可逆轉」特性的必然代價。因此，任何 Covenant 實現都應該：

1. 優先正確性：確保邏輯無誤再部署
2. 包含 Emergency Path：永遠保留資金恢復的可能性
3. 漸進式部署：從小額測試開始
4. 充分測試：覆蓋所有可能的失敗場景
5. 持續監控：運營階段保持警惕

OP_VA 作為最新的 Covenant 提案，專門針對 Vault 應用進行了優化，提供了更好的可恢復性和靈活性。隨著比特幣社群的持續討論和改進，我們可以期待看到更多基於 Covenant 的創新應用，從企業級資金管理到個人資產保護，都將從這些新能力中獲益。

更新日期：2026-02-23

版本：2.0

相關 BIP：BIP-119 (CTV)、BIP-347 (OP_CAT)、BIP-118 (APO)