MSTR Cat

区块链/等级 IV · 深入协议/4.2 升级/课程 5

契约与保险库：CTV、OP_CAT 与 2026 年之争

限制下一笔花费的规则，以及由此换来的延迟

材料BIP119（OP_CHECKTEMPLATEVERIFY）的副本BIP347文档的副本（在Taproot架构中重新启用OP_CAT功能）Bitcoin Core 中脚本验证逻辑的源代码具有交易查询功能的区块浏览器

好奇

  1. 为什么标准的比特币脚本能够验证谁持有密钥，却无法限定币接下来流向何处？
  2. OP_CHECKTEMPLATEVERIFY 对未来的交易有哪些具体的限制？
  3. 为什么通过软分叉重新启用单个拼接操作码，就能为契约打开大门？

探索

    部分 I契约提案：CTV与OP_CAT

  1. 标准的比特币脚本能够验证对某个密钥或哈希的所有权，却无法限制币在解锁之后的去向。契约通过对后续输出的 `scriptPubKey` 施加条件改变了这一点。这种机制常被比作餐券：现金可以在任何地方使用，而这些资金只能在指定的合作餐厅使用。已提出的用途包括带延迟提款路径的保险库（vault）、拥堵控制，以及更简洁的闪电网络设计。
  2. 2019年，Jeremy Rubin 提出了 OP_CHECKTEMPLATEVERIFY（CTV）。该操作码将一个未来交易模板的哈希嵌入当前的 UTXO 中。要花费它，花费交易本身必须与这个模板完全一致；验证步骤不涉及任何签名。它在执行当前一步之前就锁定了下一步。金额、目标地址或脚本结构的任何偏差都会导致验证立即失败，从而确保严格遵循预先设定的路径。
  3. CTV 的局限在于其刚性：下一笔交易的输出在币被锁定时就已固定，因此手续费必须用其他方式处理，例如借助锚定输出和子为父付（CPFP）。作为交换，CTV 易于分析，验证成本也很低。
  4. OP_CAT 是一个将两个栈元素拼接起来的操作码，2010年中本聪出于防范内存耗尽攻击的考虑将其禁用。BIP347 提议专门在 Tapscript 中重新启用它。结合 Schnorr 签名技巧，OP_CAT 可以实现契约及其他复杂逻辑，而无需为每一种具体用例制定新的共识规则。它提供了一个基础构件，开发者可以将其组合起来，为未来的交易创建定制的限制。
  5. 相关提案还包括 OP_CHECKSIGFROMSTACK（BIP348），它验证的是对栈上提供的任意消息的签名，而非对花费交易的签名。这种灵活性与 CTV（或另行提出的 ANYPREVOUT）结合，将能够实现对称的闪电网络通道，使任何一方都无需为每个旧通道状态保存惩罚数据。
  6. 截至2026年，这些契约提案均未激活，但激活的推动和争论仍在继续。关于它们的实用性、给共识规则增加的风险，以及激活所需的治理流程，争论仍在持续。共识规则的扩展引发了关于网络复杂性和长期可维护性的问题，这些问题在社区中仍未解决。

    7. 部分 II契约与保险库：2026年的争论

  7. 比特币脚本目前只能验证当前交易的条件，例如签名或锁定时间。它们无法检查花费交易的输出。契约（covenant）扩展了这一范围：一个 scriptPubKey 可以对花费它的交易所创建的输出的 scriptPubKey 施加约束。这限制了币接下来能去往何处，从而实现地址白名单和非交互式支付通道等功能。
  8. BIP-119 提出了 OP_CHECKTEMPLATEVERIFY（CTV）。它允许脚本嵌入一个模板哈希；花费交易在输出、输入数量、序列号、锁定时间和版本上必须与该模板一致，但花费哪些输入则不受约束。CTV 是非递归的，即只约束紧接着的下一步。它替代 OP_NOP4，需要通过软分叉实现。它可以作为“保险库”的基础，为被盗资金的追回增加一段时间延迟。
  9. 在保险库中，提款需经过一段等待时间（例如12小时），在此期间可以使用另一把恢复密钥将资金转至安全处。如果攻击者窃取了日常使用的密钥并开始提款，账户所有者可以通过链上信息及时发现并在等待期结束前夺回资金。这样一来，只要受害者能够监控区块链，密钥被盗带来的损失便不再是无法挽回的，而可以被挽回。
  10. 尽管自2013年以来一直有相关讨论，但至今没有任何契约类软分叉被激活。Taproot（2021年11月）仍是最近一次重大升级。2026年2月，一款 BIP-119 激活客户端在没有 Bitcoin Core 参与的情况下发布。它要求在2026年3月至2027年3月期间获得90%的矿工信号支持。截至2026年5月，信号支持率仍接近于零，表明在采用问题上尚无共识。
  11. OP_CAT（BIP-347）的完整规范已于2026年3月制定完成，但目前尚缺乏激活参数。该功能允许将不同的脚本元素组合在一起，从而实现比单独使用CTV更为复杂的逻辑处理。CTV通常与CheckSigFromStack（CSFS）配合使用，后者能够验证栈中任意数据的签名，而不仅限于支出交易本身的签名。二者结合为智能合约及协议设计带来了显著的功能提升。
  12. 争论的焦点在于取舍：契约能够增强安全性，并支持保险库等新协议，但也带来了复杂性和治理风险。软分叉会改变共识规则，需要矿工和节点运营者的广泛认同。当前的停滞反映出人们对实现漏洞以及链状态变更不可逆的谨慎。用户必须在这些收益与激活失败或激活引发争议的风险之间进行权衡。

关键事实

  • 契约限制的是未来交易的 `scriptPubKey`，而不仅仅是当前的解锁条件。
  • OP_CHECKTEMPLATEVERIFY（BIP119）使一个输出承诺于其花费交易的确切结构。
  • CTV要求预先计算未来的交易详情，在创建时确定金额和费用。
  • OP_CAT 于2010年被禁用，但已通过 BIP347（2023–2024年）被提议在 Tapscript 中重新启用。
  • BIP348提出了OP_CHECKSIGFROMSTACK，用于验证从栈中取出的消息上的签名。
  • 截至2026年，尚无任何契约提案被激活；关于其实用性、风险和激活方式的争论仍在继续。
  • 契约会限制花费某个 UTXO 的交易的输出。
  • 根据 BIP-119（CTV）规定，在 2026 年 3 月至 2027 年 3 月期间，需有 90% 的矿工发出信号才能使其生效。
  • 截至2026年5月，BIP-119 的信号支持率接近0%。
  • Taproot（2021年11月）是最近一次激活的软分叉；目前没有任何契约上线。
  • OP_CAT 于2026年3月完成了完整规范，但尚无激活参数。
  • 保险库利用契约增加延迟和追回路径，以防范私钥被盗。

练习 九、六、三、一

9收集列出9种与契约或脚本扩展相关的比特币操作码或机制（例如CTV、APO、OP_CAT）。
6归类将这9项按主要约束类型分为6类：交易结构、密钥派生、拼接逻辑等。
3提炼将这6组归纳为灵活性与验证成本之间的3个核心技术权衡。
1凝结用一句话说明为什么像 CTV 这样的刚性契约比基于 OP_CAT 的灵活脚本验证成本更低。

事实核查

日期、数字及数据均依据下方列出的已发表资料进行核实。

在互动学院中打开 →

EN PT ES JA KO RU DE FR MS