浅谈比特币新提案「OP_CAT」：对BTC生态后续市场演变有何影响？

原文作者：Haotian（X：@tmel0211）

如何看待最近被热议的比特币新提案 OP_CAT？ 尽管其目前还没有被正式 Merge 到 Bitcoin Core 代码中，但已经在 BTC 社区引发了广泛的讨论。那么，OP_CAT 操作码到底解决什么问题？若被引入会给 BTC 的可编程能力带来哪些提升？会对 BTC 生态后续市场演变产生哪些影响？接下来，简单谈谈我的理解：

1）OP_CAT 是一个全新的操作码提案，被开发者戏称为处于 BIP 420 和 BIP 347 的量子纠缠叠加状态，具体哪个 EIP 不重要，只要搞清楚这只是一个还在被讨论并没正式纳入的提案足够了。 

简单来说，OP_CAT 可以实现多个 UTXO 解锁脚本字节串的组合连接处理，可以提升 BTC 主网的可编程特性，程序扩展性以及链上验证计算复杂性；

2）和 Covenant 契约作为比特币脚本扩展提案类似，OP_CAT 目标也是要提升比特币脚本的扩展能力，区别是，Covenant 目标让比特币交易实现更复杂的可编程性，以支持复杂的智能合约和应用场景。 

相比之下，OP_CAT 更加好落地一些，目标要简化复杂脚本的构建和执行，以提高链上验证的效率。通俗理解：OP_CAT 提供了组合脚本片段的能力，在其引入前，每一个 UTXO 脚本都是独立执行的，有了 OP_CAT 后我们可以把一个复杂的执行逻辑拆分成一连串组合的简单脚本片段，并被存储于不同的 UTXO 中，由不同的交易创建，需要完整执行时，全节点用 OP_CAT 指令把这些脚本片段按顺序拼接起来执行触发。 

3）有了这种组合能力，理论上可以让比特币上出现很多复杂的执行逻辑：比如， 

1、多重签名加时间锁，可以跨多个主体多个 UTXO 和时间锁设置较为复杂的执行解锁条件； 

2、递归和循环，可以让多个脚本字节串之间构成递归和条件执行，一直循环直到满足某个终止条件； 

3、模块化应用，常见脚本逻辑可以被提取出来，在多个程序执行片段中复用。 

Alice 把托管在平台 C 的钱向 Bob 转账，必须三个主体同时签名，若 C 平台超出签名时间，Alice 和 Bob 则可以一同签名来取回资金；若 Bob 长时间没有签名获取转账，Alice 可以撤回交易；若 Bob 认为 Alice 的资金来源有问题可以拒收等等。这只是一个简单的例子，实际可以利用脚本片段之间的组合实现更复杂更颗粒化的控制； 

4）此前，BitVM 把复杂操作在链下执行，只在链上实现关键验证结算的范式，让大家对 BTC 的可编程和图灵完备计算迸发了极大的想象力。OP_CAT 在 BTC 主网上“递归”组合执行算是又一次想象力的补充，而且 OP_CAT 对加速 BitVM 的落地和降低链上验证成本等都大有裨益。 

如何理解呢？原本 BitVM 要执行，需要把链下的程序封装成一个个独立的可共单个 UTXO 执行的脚本片段，链下构建成本较大，将这些片段都在链上执行拼凑，也会需要更复杂的 TaprootTree 结构，意味着 BitVM 一段程序执行下来链上交互验证的成本会相对较高。当 OP_CAT 被引入后，BitVM 链下封装的片段就不需要每个都能完整独立执行，链上可以在 UTXO 解锁条件累计到一定程度后进行一次汇总并更新状态，显然，脚本片段的组合可大大减少链上验证交互所需的次数和成本。 

总之，OP_CAT 被热议包含着大家对于比特币进一步增强可编程性的期待，其若真正落地，对 BitVM 的落地，各类 BTC layer 2 跨链资产解决方案的安全性提升，以及 UTXO 同构绑定链的生态拓展和主网的同频发展，甚至譬如闪电网络、RGB 客户端验证等潜在可延展市场的进展都会起催化作用。 

理论上任何 BTC 可编程能力的提升对其延展生态的刺激作用会立竿见影，毕竟大家都试图在沙漠里建绿洲，如果有一天沙子变成水泥地板了，那大楼盖起来岂不是要方便很多了。

只是，它会被真正 Merge 通过吗？ 想想已经被提出多年但未被采纳的 Covenant 提案，用 OP_CAT 新提案来脑补一些市场想象空间也挺好。

原文链接