Covenant

链上的每个脚本都回答同一个问题：这笔花费是否已获授权？Covenant 则会让脚本就花费它的那笔交易再提出第二个问题，而允许这一点的各项提案（BIP-119、BIP-118、BIP-345、BIP-347）多年来都未获激活。您目前持有的任何资产均不受影响，但人们一直在期待的金库和继承类产品，正等待这一功能。

运作方式

状态： 比特币主网上没有任何 covenant 操作码处于激活状态。下文的每一种设计都只是提案，没有一项已将激活参数合并进 Bitcoin Core。

目前缺少的能力有一个确切的名称：内省（introspection）。节点运行脚本时，脚本可以查看签名、哈希、时间锁和堆栈，却无法读取正在花费这笔币的交易的输出。正是这一个盲点，使得比特币可以表达“这三个人中必须有两人同意”，却无法表达“这笔钱只能转到那个地址”。

各项提案以两种不同的方式弥补这一缺口，而两者之间的差异正是争论的核心。

模板方式预先承诺整笔花费交易的哈希。OP_CHECKTEMPLATEVERIFY 就是这样工作的：输出中保存一个32字节的哈希，除非交易的哈希与该值相同，否则花费失败。这种方式范围狭窄，验证成本低，而且由于一个承诺无法描述另一个承诺，这种限制无法无限重复。

内省方式则把各个组成部分交给脚本，让脚本自行运算。把 OP_CAT 与签名检查结合使用，或加入 OP_CHECKSIGFROMSTACK，脚本就可以用堆栈上的各个片段重建交易的签名哈希并加以验证，此后脚本便可以对输出提出任何要求。这种方式具有通用性，并且是递归的：covenant 可以要求下一个输出带有同样的 covenant。

递归正是拖慢整个进程的反对理由。被锁入自我延续规则的币，原则上可能永远受到约束，这就引出了对可替代性的疑问，也引出了对可能强制推行该规则的发行方的疑问。反方的论点是，一群人如今就可以通过预先签署唯一允许的花费并销毁密钥来模拟 covenant，因此这种能力在实践中已经存在，而由共识层强制执行，主要是免去了必须相信密钥确实已被销毁的需要。

在哪里会遇到它

Covenant 已在复用比特币脚本引擎的链上部署，这是了解其作用的成本最低的方式。

基于 Elements 的侧链 Liquid 运行一种带有内省操作码的 tapscript，可直接读取花费交易的输出，其联盟将这些操作码用于锚定。任何人也可以在自定义 signet 上测试这些拟议的比特币操作码，再决定是否希望在主网上使用它们。

在主网上，替代方式是预先签署的交易加上被删除的密钥。金库服务商生成存款密钥，签署其将允许的唯一一笔提币，然后销毁密钥，使其他任何花费都无法创建。这是靠承诺而不是靠网络来强制执行的 covenant，而真正的 covenant 操作码恰恰会使这一承诺变得没有必要。如果有服务向您出售金库，值得留意：问清它属于这两种中的哪一种。

Covenant vs 担保托管合约

Covenant 限制的是目的地；担保托管合约限制的是签名方。它们解决的是同一个顾虑的不同两半，而且只有其中一种目前可用。

担保托管合约是将第三方纳入签名阈值的普通多签，通常是三选二，目前即可在比特币上使用：交易平台持有一个密钥，买卖双方可以不经它自行结算，也可以请它出面裁决争议。担保托管无法做到的是约束最终结果。一旦达到花费所需的签名阈值，这些币可以去往任何地方，包括仲裁方。Covenant 则会预先固定目的地，并把仲裁方的裁量权从设计中彻底去除。