Covenants

安娜用 Bitcoin 储蓄。钱包是接收和发送比特币的应用程序或设备。钱包显示的余额由以前交易中尚未花费的输出组成，这些输出称为 UTXO。每个输出都记录金额和花费条件，条件写在名为 Bitcoin Script 的短程序里。数字签名利用私钥这个秘密数值证明付款获得授权，同时不泄露私钥。Multisig 可以要求多个签名，Timelock 则加入等待条件。Covenant 还可以限制下一笔交易的结构，例如资金必须转入哪些输出。即使窃贼拿到了正确的密钥，也必须满足这项规则。不过，必须检查所有可用的花费路径：如果另一条分支允许绕过限制，就不能依赖它来保护资金。 [1] [5] [9] [11]

假设安娜把积蓄放进带有延迟的金库。这里的金库不是某种特殊设备，而是一组花费规则。她的日常密钥可以发起提现，但资金要先进入一个等待输出。只有等待期结束，资金才能继续转给指定收款人。如果提现由窃贼发起，安娜可以在等待期间使用事先准备的恢复路径，将资金转入更安全的条件下。不过，她必须发现这次提现，并及时让恢复交易在区块中得到确认。区块把交易组成一批，加入共同历史记录。这既不是撤销已经完成的付款，也不会在无人干预时自动救回资金。具体能做什么，取决于金库的设计。 [6] [10]

应用承诺延迟提现，可能只是运营方的承诺。Bitcoin 脚本中的规则则由节点检查；节点就是按照网络共同规则验证交易的软件。在相应的 covenant 构造中，节点必须拒绝违反限制的转账。一个提议中的工具是 OP_CHECKTEMPLATEVERIFY，简称 CTV，由 BIP119 描述；BIP 是提出 Bitcoin 相关方案的文档。CTV 会把待验证交易中选定数据的哈希，与事先保存的指纹比较。这里可以把哈希理解为简短、可核验的数据指纹。修改已经规定的收款人或金额会改变指纹，因此不符合模板的转账无法通过检查。应用里单单写着“金库”，并不能保证这种约束。 [2]

CTV 将交易绑定到事先准备的模板，包括交易的输出。研究中还有其他方法。BIP443 提议的 OP_CHECKCONTRACTVERIFY 用于携带特定数据之可验证承诺的输出。这里的承诺意味着，不能事后换成另一个值而不被检查发现。数据可以描述合约的状态，例如共享资金目前如何分配；只要满足规定的规则，下一个输出就可以携带更新后的状态。因此，CTV 和这项提案不是同一件事的两个名字。对每种设计，都要了解哪些内容必须提前确定、哪些内容以后可以改变，以及完整构造还需要哪些工具。 [2] [7]

递归结构可以要求下一个输出再次携带某种限制。这样，规则就能延续到多笔交易，例如随合约状态逐步变化而继续生效。这不是在验证单个脚本时运行无限循环。Russell O’Connor 与 Marta Piekarska 在 2017 年的论文中描述过此类结构；是否支持重复约束，需要看具体提案。 [3]

有些限制可通过预签名交易、时间锁和密钥管理提前安排。但这种组合可能要求可靠地删除密钥、保存全部交易，或继续获得其他人的合作。依靠另一位签名者拒绝不合适付款的 Multisig，又引入了不同的信任前提。用户体验相似，不代表规则的强制方式或恢复能力相同。 [5] [6]

除金库之外，研究还包括共享 UTXO，以及让结算分散在不同时间进行的付款安排。目的可能是减少持续协作需求，或更有效地利用区块空间。但这不意味着交易数量无限，也不保证手续费低廉。设计还必须说明单个参与者如何退出、其他人离线时怎么办，以及网络拥堵时如何支付手续费。 [2] [7]

截至 2026 年 10 月 17 日，BIP119 和 BIP443 的状态都是 Draft，即仍在完善中的提案。较早的 BIP345（OP_VAULT）状态为 Closed，并将 BIP443 列为提议的替代方案。关闭这份文档不代表金库研究已经结束。同样，获得 BIP 编号也不表示网络已经接受改动。测试网络或演示钱包可以展示某项功能，而 Bitcoin 主网 mainnet 的规则仍然没有改变。如果服务商提供 covenant 金库，请核实它实际运行在哪个网络、采用哪些规则。 [6] [8]

模板过于狭窄，或金额、脚本、手续费处理有误，都可能使预期花费无法进行。增加操作也扩大了实现必须安全验证的范围。因此，共识变更要依据精确规范及出错时的行为来评估。Covenant 本身不会赋予陌生人事后修改你已有 UTXO 条件的权力。 [4] [8]

面对具体方案，应问清谁能发起提现、谁能启动恢复、反应窗口有多长，以及是否需要有人持续监控链。还要核实备份、手续费、退出方式，以及方案实际运行在哪个网络。Covenants 可能增强你对资金的控制，但产品介绍中的这个词本身并不能证明这种控制。 [3] [6]