作者：Haotian

如何理解@StarkWareLtd 最新发布的ColliderScript白皮书？ 简单而言：ColliderScript通过哈希碰撞机制，在不修改比特币协议的情况下实现Covenant，超前OP_CAT提案实现了比特币主网的复杂合约功能。具体工作原理如何？和OP_CAT区别在哪？会加速Starknet比特币layer2落地？看完白皮书，跟大家分享下：

1）ColliderScript顾名思义“对撞机”，表明其核心机制是对脚本实施哈希碰撞实现。 由于比特币存在Big Script 和Small Script两种脚本类型，大脚本能看到签名等交易数据但是只能处理有限的计算，小脚本可以32位数据的任意计算，但看不到交易数据。

这意味着验证大脚本就只能限于签名交易等有限验证，根本无法处理复杂的合约逻辑，而小脚本有容纳复杂逻辑的能力但是没了交易签名所属权关联，单独处理毫无意义。

怎么办呢？ColliderScript巧妙地设计了一个“桥梁”，利用SHA1和RIPEMD实施160位哈希碰撞，，实现了大脚本（处理签名等大数据）和小脚本（只能处理32位数据）之间的等价性证明。虽然无法处理小脚本大于32位的签名数据，但通过一套密码学验证机制，可以证明大小脚本中的内容趋于一致。

就是这么一个巧妙的数学技巧，ColliderScript把大小脚本的信息能做到有效连接，复杂的合约交易逻辑可以集成进小脚本进行计算，而大脚本保留交易签名验证，最终ColliderScript把大小脚本的信息能做到有效连接，让比特币脚本内可以实现复杂的合约功能。

2）OP_CAT我之前写文章具体分析过，它是一种全新的操作码提案，可以把多个脚本字节串数据连接起来处理，从而实现整体的复杂合约验证和计算能力。

通过OP_CAT，原本需要在单个数据块中处理的逻辑，可以拆分成多个数据片段，在脚本执行过程中动态组合，实现更灵活的验证和计算。

由于OP_CAT是一个未Merge的提案，是否能顺利上线是个未知数，而ColliderScript的出现可以抢先实现比特币主网的合约功能。

但是，和BitVM的实现逻辑一样，ColliderScript纳入了链下预处理逻辑，所谓的哈希碰撞需要投入大量的计算和存储成本。根据白皮书介绍，每次使用契约功能需要2的86次方哈希查询和2的56次方存储空间，相当于要消耗比特币网络30多个小时的算力，自然也会加大节点投入的硬件成本和电力消耗等等。

因此，ColliderScript不会完全取代OP_CAT，其会作为一个过渡方案，处理一些特定场景的高价值合约，其他小微交易业务场景走ColliderScript方向投入和产出不成正比。

话说回来，BitVM的推出也存在实用性不强的问题，但却让一大批诸如 @GOATRollup 、@BSquaredNetwork 等在内的项目，基于其实现了Native跨链桥和比特币Specific 挑战证明机制。

以GoatNetwork为例，作为一个能实现去中心化Sequencer和Native安全跨链的Bitcoin layer2解决方案，内核就是基于BitVM2实现了一种OCP乐观挑战协议，所有的计算和交互都在二层离线执行，当“挑战”出现时会在比特币主网执行链上协议，比特币layer1会充当仲裁者来确保安全性。

CollideScript的现实“实用性”困境和其潜在的创新鲶鱼效应也类似，虽说存在大规模普及的成本障碍，但其碰撞大小脚本推进比特币可编程性的探索，一定会率先激活一些特定应用场景。

关键是，这种链下预处理+链上的组合模式长远看会解锁很多复杂应用场景，比纯粹堆砌链上计算验证的逻辑更接地气一些。

3）不过，Starkware发布ColliderScript白皮书倒是饶有趣味，之前 @Starknet 宣布了要基于OP_CAT做bitcoin layer2的计划，现在又推出了全新的过渡方案，从被动转主动，可见目的是为了加速其比特币layer2的落地。

在为Starkware团队的技术拓新能力点赞之余，必须得期待一下，Starknet的这条比特币layer2推出，会给比特币layer2生态带来什么。