OP_CAT 复活提案 BIP-347：比特币脚本多了拼接能力，会发生什么

凡是关注比特币铭文、Vault 或跨链桥的人，近两年几乎都听过”OP_CAT 回归”的讨论。它没有地板价、没有代币，却牵动着比特币最底层的一条规则：脚本能做什么。先把最容易出错的一件事说清楚——截至 2026 年 9 月 9 日，OP_CAT 没有在比特币主网激活，BIP-347 只是规格文档进入了 Complete 状态的提案文本，激活需要软分叉共识，两码事不能混。

一个被删掉十四年的操作码

OP_CAT 是比特币创世脚本系统里的操作码，作用只有一句话：弹出栈顶两个元素，拼接成一个，压回栈。2010 年，中本聪把它与一批算术类操作码一起临时禁用，原因与当时观察到的恶意脚本风险有关，此后它一直躺在”永久禁用”名单里。争议在于：脚本里少了通用的拼接能力，就无法在链上高效构造和验证默克尔证明这类哈希数据结构，很多协议只能绕远路。

2023 年 10 月，Ethan Heilman 与 Armin Sabouri 在 bitcoin-dev 邮件列表提出复活方案，2024 年 4 月被分配编号 BIP-347。方案没有走”直接解禁”的老路，而是限定在 Tapscript 内，把保留操作码 OP_SUCCESS126（十六进制 7e，与原始 OP_CAT 同值）重新定义为 OP_CAT。这样做的妙处在于软分叉兼容性：旧节点把 7e 当作永远成功的占位操作码，新节点把它当拼接指令，按 Tapscript 规则仍构成一次兼容的软分叉。

为什么当年危险、现在被认为可控

2010 年被担忧的”指数级膨胀”攻击——用拼接把小数据滚成巨型字符串撑爆节点——在 Tapscript 语境下有了一道明确闸门：BIP-342 规定栈元素上限 520 字节，拼接结果超限即无效，滚雪球的攻击路径被规则本身堵死。这是提案强调”仅在 Tapscript 内复活”的核心理由。

拼接能力本身不直接改变支付方式，改变的是”脚本能否检查正在花费它的那笔交易”。把交易的版本、输入、输出等字段逐个压上栈，用 OP_CAT 拼回签名预镜像的样子，再交给签名验证——脚本第一次可以”看清”花自己的长什么样。这类交易内省是承诺（covenant）类结构的原料，Vault 延时取款、更轻量的桥与二层构造才因此进入讨论范围。

2026 年中的真实位置

按公开可查的状态：BIP-347 规格文本在 bitcoin/bips 仓库标注 Complete，含义是文档定稿，不含激活参数，也完全不等于部署；主网共识代码没有合并，没有信号时间表。测试网络上，专门用来实验候选软分叉的 Bitcoin Inquisition 已于 2024 年 4 月底把 OP_CAT 带入 signet 供开发者试验；个别与比特币对齐的侧链网络自行启用了它。同时在主流开发者社区的排序里，与承诺相关的另外两条提案（CTV 与 CSFS）在激活参数讨论上走得更靠前，OP_CAT 自己的激活路径仍是开放议题。

对普通持有人，这意味着三件具体的事：第一，任何声称”主网已经支持 OP_CAT 协议”的产品宣传都值得警惕，主网交易的脚本规则没有变化；第二，若未来软分叉真的落地，按比特币惯例属于后向兼容升级，老节点、老钱包不会一夜失效，也不需要用户做额外操作；第三，围绕它的多空争论（可编程性收益对脚本复杂度风险）没有权威裁判，把它当技术议程跟踪即可，不必站队。

与铭文和 NFT 的关系

铭文与基于比特币的资产协议大量依赖脚本与见证数据的表达方式，交易内省能力的扩展会改变这些协议能写多复杂的状态机——这是它与本栏目读者的关联。但”能写更复杂的状态机”既不指向任何具体资产的涨跌，也不构成对新协议安全性的担保。本文为协议机制科普，不构成投资建议；状态以 bitcoin/bips 仓库与比特币核心代码库为准（核验时间 2026 年 9 月 9 日）。