比特币合约原语之争：CTV 是什么，激活信号怎么自己查

承诺是什么：让今天的规则管住明天的花费

比特币脚本默认只管”能不能花”，管不了”花出去之后去哪”。承诺（covenant）改变这一点：在解锁时同时约束下一笔或下几笔交易的形状，使资金的后续流向被写死在第一次锁定的条件里。由此可以搭出撤销期金库、无需信任的币池、可单方中止的通道一类结构——共同思路是给比特币加一点”可编程的延迟与路径约束”，而不是图灵完备的智能合约。支持者视之为把 Custody 从信任里解放出来的最小积木；反对者的担忧同样具体：承诺让第三方得以把排除规则递归写进脚本，为审查提供新工具。原语之争十几年没有答案，直到各方案分别落成了带编号的 BIP。

CTV 的公式化设计

OP_CHECKTEMPLATEVERIFY（BIP119）的做法是把一笔”预约未来”的交易模板哈希进锁定条件：解锁时提供一笔完整交易，脚本要求它的模板哈希与承诺值完全一致。模板覆盖版本、权重、输入计数、各个输入 Prevout、各个输出金额与脚本，等于给未来的钱预先拍照。它故意不做递归——不能由承诺的输出再指向新承诺——以避免滑向可编程审查路径；组合能力则交给配合的构件，例如 OP_CHECKSIGFROMSTACK 搭配后可支撑金库、支付池与闪电网络的对称更新路线。同场竞技的还有 OP_CAT（可组合的递归路线，规范已成稿但未尝试激活）、SIGHASH_ANYPREVOUT 等，截至本文写作时它们都未在主网激活，只能在专门签网（Bitcoin Inquisition）上试用。

激活客户端给出的硬参数

2026 年初，社区按 Taproot 用过的标准 BIP9 模板为 CTV 上线了激活客户端，参数全部公开可查：使用版本号第 5 位信号；窗口自 2026 年 3 月 30 日开启，至 2027 年 3 月 30 日到期；以 2016 个区块为周期，达标线 1815 块，即九成算力；另设最小激活高度 1001952，为钱包与节点留出升级缓冲。这组数字的意义在于把”你觉得热度如何”变成可证伪的问题：每个难度周期的信号率都会如实出现在链上，达标则进入锁定阶段，未达标则窗口届满自动作废，无需任何人宣布失败。对普通读者，值得记住的不是任何一期周期的百分比快照——那类数字每天都在变，也不该被任何二手结论代读——而是参数本身与查法。

自己动手查信号：两个办法

办法一是本地节点。同步中的 Bitcoin Core 执行 getdeploymentinfo，看名为 ctv 的部署项：状态处于 defined 或 started 说明窗口开着，period 内最近周期的信号比例、是否进入 locked_in、active 或已超时作废，一目了然。这个答案不依赖任何浏览器。办法二是区块浏览器或专门的激活观测页，它们展示的同样是每个周期内带该信号位的区块占比，用你自己的节点数字对账即可。阅读时留意三件事：你看到的可能是上一周期的历史值；矿池”声明支持”与”实际出块带信号位”是两回事，只有后者算数；锁定之后、激活之前还有一段强制空窗，专门留给钱包和节点升级，这段时间里链的规则并未改变。

各方位置与风险认知

支持侧的论证围绕用户可感的功能：更便宜的金库撤销、拥塞时的费率控制、闪电协议改进。反对侧的核心不是反对功能，而是担心路径依赖——先承诺模板、再递归承诺、再可编程排除，每一步都有当时的合理理由。历史上对承诺方案的争论从 2016 年延续至今，且社区曾因强推激活方案而经历分裂冲突，这段记忆让多数协议开发者对分叉激活格外保守。读者面对这类议题的健康姿势，是把判断拆成三层：协议此刻的规则（链上可查）、激活机制的状态（参数与信号可查）、功能价值与风险的权衡（见仁见智、随生态演变）。前两层的困惑大多只需要一个节点和几条 RPC；第三层，本文不下结论。

风险提示：本文不构成投资建议，也不构成对任何升级方案的支持或反对立场；软分叉激活进程动态变化，判断状态请以本节点数据与规范原文为准。