一句话定位
OP_CHECKTEMPLATEVERIFY（简称 CTV）是 BIP119 提出的一个脚本操作码提案：把一笔输出的锁定脚本绑定到一个三十二字节的哈希上，这个哈希预先承诺了“花钱时必须长什么样的下一笔交易”——版本号、锁时间、输入数量、序列号、输出列表等字段全部入哈希。花费时节点现场重算新交易对应字段的哈希，对不上就拒绝。它本质是一种极简的协约（covenant）：一种限制币将来流向哪里的规则。
先理解协约这个词在比特币里多敏感
协约意味着币被“上一段历史”约束了“下一段去向”。比特币社区长期对全面协约持保留态度：担心规则复杂、担心被锁进协约的币和其他币不再是同一种东西（同质性受损），也担心递归协约让脚本变成另一个图灵完备平台。CTV 的切入点是做减法：模板是一次性、完全枚举、无动态状态的——模板不能递归定义“下一笔也要符合某种模式”，每一跳都必须提前把整条路线列完。这让它在协约家族里属于最受限、最容易审计的一档。
机制细节：它到底比什么
提案把 CTV 映射到既有的保留操作码 OP_NOP4 上，作为软分叉升级：未升级节点仍把它当空操作，升级节点开始校验。校验规则简单到一行：栈上必须有一个元素；元素是三十二字节时，比较当前交易在当前输入位置上的模板哈希；不相等则脚本失败；元素长度不合规则按未来升级的惯例当空操作处理。模板哈希承诺的字段集与 Taproot 为防二次哈希攻击而预计算的哈希结构可以共享，这是提案里工程复用意识很强的一处。
提案设想的用武之地
提案文档列了若干场景。拥堵控制是最常被引用的一类：大型输出预先绑定一张含几百个输出的模板，在费用暴涨时段，参与者无法把币挪去别处，只能按模板参与批量合并，矿工的验证成本也低。支付通道实例化是另一类：通道开启交易的形态被模板锁住，省掉一部分多轮签名协商，也让通道在链上的形态趋同、更像普通交易。在 BIP119 之前，社区邮件列表里也零星讨论过类似的模板锁思路，但多因共识分歧停在纸面；BIP119 于 2020 年初正式立项，是这条线索里设计最收敛、讨论最系统的一版，提案人在社区做过演示与答疑。
状态边界要说死
截至本文写作，BIP119 的状态是草案（Draft），从未进入主网激活流程：没有软分叉部署时间表，比特币核心对升级默认持保守立场，也没有钱包把它作为可用的脚本类型交付给普通用户。在支持它的实验分支与测试网络上，相关演示确实验证过机制可行性——但那属于“实验与演示”层级，与主网激活是协议进程里完全不同的两档。任何把 CTV 说成“比特币已支持”的说法都不成立。
一条直觉线
把 CTV 想成快递单：普通脚本只验证“发货人有钥匙”，CTV 额外要求“包裹从今以后的每一程必须按预先打印好的路线表走，路线表哈希焊死在箱子上”。它既不能中途改道，也不许下一程自带新规则——这种笨拙正是提案人换来的信任筹码。
常见误区
一是把 CTV 与 Taproot 的脚本路径混谈：Taproot 已于 2021 年激活，CTV 与之无关且未激活。二是把测试网或实验分支的可用状态当成主网能力。三是把 CTV 当成”更聪明的脚本”：它故意不聪明，只会比对一个哈希。
快速问答
问：它和 OP_CHECKCONTRACTVERIFY 那类更新的协约讨论什么关系？答：后者是更宽泛的 introspection 设计空间，社区仍在探索阶段；CTV 是最窄的那条路线。问：主网激活要什么条件？答：要走完版本位部署、阈值锁定、回收期等一整套软分叉流程，目前连部署信号都没有。
风险提示：本文为协议提案科普，不构成投资建议；引用脚本细节请以 BIP119 原文与当期文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。