OP_CAT(BIP-347)2026 进度到哪了?会激活吗?
如果你在 2024 年第一次听说 OP_CAT,大概率会把它当成另一个「永远在 PR 评审里的提案」。但是到 2026 年 5 月,情况已经不一样了。BIP-347 正式拿到了官方编号,代码层面有 Bitcoin Core PR、btcd、Bitcoin Knots 三个独立实现,Tadge Dryja、Olaoluwa Osuntokun(Lightning Labs CEO)、Andrew Poelstra(Blockstream 研究总监)等核心研究者公开表态支持,Taproot Wizards、Botanix Labs、Citrea 等团队也在测试网把它当成「假设已激活」的前置依赖在编排路线图。
这并不是说 OP_CAT 已经在主网启用。它没有。但从「冷启动的想法」到「等待软分叉激活路径讨论」的阶段切换,确实在过去十二个月里完成了。这篇文章的目的,是把 2026 年 OP_CAT 的真实进度逐项摆出来,不夸大,也不为了「叙事」而省略坑。
一、OP_CAT 到底想做什么,为什么 2009 年被禁
OP_CAT 是个非常老的操作码。它最早出现在 Bitcoin v0.1 的脚本系统里,作用极其直白:把栈顶的两个字节串拼接(concatenate)起来,推回栈顶。听起来无聊,但脚本里能拼字符串,就意味着你可以在脚本里构造、验证、比较任意结构化数据,而不只是签名和哈希。
中本聪在 2010 年 8 月把 OP_CAT 连同其他几个操作码一起禁用了。原因是当时的实现里栈元素长度没有强约束,如果不停 OP_DUP + OP_CAT,栈上的元素长度可以指数级膨胀,直接 OOM。这是 2009-2010 年那一批「砍掉一切可能炸节点的操作码」操作的一部分,不针对 OP_CAT 本身的语义。
到了 Taproot(2021,BIP-342 tapscript)之后,情况变了:tapscript 默认对栈元素长度有 520 字节的硬上限,所以早年那种「指数级膨胀」的攻击面已经没了。重新启用 OP_CAT 在工程上是可行的——BIP-347 干的正是这件事。
二、BIP-347 在 2026 年的官方进度
BIP-347 的标题是 “OP_CAT in Tapscript”,作者是 Ethan Heilman 和 Armin Sabouri。把核心进展按时间排一下:
- 2023 年 10 月:草案首次以邮件列表形式发起讨论。
- 2024 年初:Taproot Wizards 牵头做了一轮社区动员,带火了「重新启用 OP_CAT」的话题,但当时仍未拿到编号。
- 2024 年中:BIP 编辑给出编号 347,文档进入 Draft。
- 2025 年:Bitcoin Core 出现实验性分支 implementation,btcd、Bitcoin Knots 各自做了节点端实现并跑通联合 fuzz 测试。
- 2026 年第一季度:BIP-347 在 GitHub 上的状态被推进到 Proposed,具体激活方式(BIP-9 vs BIP-8 vs Speedy Trial 变体)在 Delving Bitcoin 和 bitcoin-dev 邮件列表上展开正式辩论。
- 2026 年 5 月:Bitcoin Core 25.1 之后多个开发者维护的分支默认带 OP_CAT 的 tapscript-only 实现作为可选 build flag,但未启用到 main consensus。
注意,BIP 编号本身不代表激活。它只表示这个提案的文档格式、技术描述被 BIP 编辑接受为「值得继续讨论」。从 BIP-347 到主网激活,中间至少还要走完三件事:激活路径达成共识、节点升级覆盖率、矿工信号(如果选 BIP-9 类路径)。这条路目前没有任何一项已经完成。
三、为什么 Dryja、Osuntokun、Poelstra 这一批人现在愿意公开支持
OP_CAT 在 2022 年之前在核心圈子里其实不算主流话题。原因是它「太简单」,看起来不像一个需要单独搞软分叉的功能。但 2023 年之后,几个研究方向把它的价值重新拉了出来:
- Covenants 的最小可用实现。Covenants(契约)是指脚本可以约束「这笔 UTXO 被花出去时,下一笔交易必须长什么样」的能力。OP_CTV、APO、TXHASH 都是 covenants 方案,但都需要新增独立操作码。OP_CAT 配合现有的 OP_SHA256、OP_CHECKSIG,可以模拟出 covenants 的大部分能力,而不需要单独引入 OP_CTV。Andrew Poelstra 在 2024 年的 Symbolic Computation in Bitcoin Script talk 里系统论证了这一点。
- BitVM 与 ZK 验证。 Tadge Dryja 和 Robin Linus 推动的 BitVM 系列,需要在脚本里做大量的字符串拼接与哈希链验证。没有 OP_CAT 时只能用 bit commitment 方案模拟,代价极其昂贵(主网验证一次需要数十 KB witness)。OP_CAT 一旦上线,BitVM 的链上 footprint 可以缩到原来的几分之一。
- Lightning 与状态通道升级。 Lightning Labs 的 Osuntokun 公开表示,OP_CAT 是 PTLC 与一些跨通道协议工程化的关键依赖。
简单说,OP_CAT 不是「一个功能」,它是一个底层 primitive,谁都能从中拿一块。这就是这一轮支持者光谱比以往任何一次软分叉提案都更宽的原因。
四、争议、反对意见与「会不会激活」的现实判断
要避免一头热,得把反对意见也老实摆出来:
| 担忧 | 来源 | 是否成立 |
|---|---|---|
| 拼接出指数级长字符串、撑爆节点 | 历史教训 | tapscript 520 字节上限已堵住,不成立 |
| 启用 covenants 会引入「币的可编程性差异化」(币不再可互换) | Luke Dashjr 等 | 哲学层面的反对,技术上不可证伪 |
| 矿工激励变化 | 部分 mining pool | 暂无实证,仍在辩论 |
| 软分叉激活机制本身没共识 | bitcoin-dev 邮件列表 | 成立,这是当前最大瓶颈 |
最后一条才是真正的瓶颈。Bitcoin 自 Taproot(2021)之后再没有过任何一次成功的软分叉,社区对「该用什么样的激活流程」没有统一意见。Speedy Trial 在 Taproot 上跑通过,但之后的 Drivechain、CTV、APO 都因为激活路径吵不出结果而停滞。OP_CAT 即使技术上准备好了,也会被这个结构性问题拖住。
如果你想跟进比特币 L2 的整体格局,我之前写过一篇 《2026 年比特币 L2 真实落地用例》,里面提到的 Citrea、Botanix 都把 OP_CAT 作为「未来一旦上线就立刻接入」的依赖项;另外 《Bitcoin Hyper:基于 SVM 的比特币 L2 怎么看》 里也涉及到了 covenants 在不同 L2 模型里的角色差异。
五、对开发者与普通用户分别意味着什么
对开发者: 现在就可以在 signet 或 mutinynet 上用启用了 OP_CAT 的实验性节点跑实际代码。Taproot Wizards 维护了一个叫 cat-signet 的测试网络,Citrea 也在自己的 devnet 启用了 OP_CAT。如果你做 BitVM 类应用,直接在那上面写脚本会比等主网快得多。
对普通持币者: 现阶段没有任何动作需要你做。OP_CAT 即使激活也是软分叉,旧节点不会被分叉出去,钱包不需要升级。真正需要关注的时间点,是激活路径辩论收敛之后——可能是 BIP-9 信号窗口开启那天,也可能是某个 client-driven 激活方案被多数节点采用。
按当前节奏,主网激活最早也是 2027 年的事,中位预期更可能在 2027 下半年到 2028 年。任何说「OP_CAT 今年就要上线」的叙事都是营销话术。BIP-347 拿到编号、有了多实现、有了顶级研究者背书,只是把它从「能不能做」推到了「什么时候做、怎么做」。这两个阶段之间隔着的不只是技术,还有比特币社区那套独特的、缓慢的、刻意保守的治理文化。
六、值得继续盯的几个信号
如果你不打算每天刷 bitcoin-dev,我建议把注意力收敛到这几个信号上:
- bitcoin-dev 邮件列表关于激活机制的新一轮讨论(关键词:BIP-8、LOT=true/false、flag day activation)。
- Delving Bitcoin 论坛 OP_CAT 与 covenants 子板块的月度活跃度。
- Bitcoin Core 的 review club 是否把 BIP-347 实现 PR 列入正式 review 议题。
- Citrea 主网(2026-01-27 已上线)、Botanix 等 L2 是否公开「OP_CAT-ready 路径切换」。
只要这四个信号同时升温,就是真信号;只看 Twitter 热度,会被反复带节奏。OP_CAT 在 2026 年的位置,不是终点,也不是炒作,它是比特币软分叉治理这台老机器在 Taproot 之后第一次重新发出嗡嗡声的证据。