CAT20有什么技术上的巧妙设计？CAT20-Fractal BTC上的代币协议

CAT20 这个协议到底在技术上玩出了什么新花样？简单说，它就是运行在 Fractal BTC 上的一套代币标准。比特币生态最近热闹得很，Fractal BTC 经过好几轮测试网折腾，终于在去年 9 月上线了主网。它最大的亮点是支持「智能合约」功能，而且主网上线几乎同步就推出了一个叫 CAT20 的代币协议。CAT20 到底有什么巧妙的设计？我们能从中学到什么？下面就来好好聊聊。

Fractal Bitcoin 是什么

在讲 CAT20 之前，得先搞清楚 Fractal Bitcoin 这个底层网络。它们的关系就像以太坊和 ERC20：CAT20 是在 Fractal Bitcoin 上跑的一套协议。

Fractal Bitcoin 也叫分形比特币，本质上是一个完全兼容比特币的「二层」网络。跟比特币主网相比，它的区块确认时间更快，只要 1 分钟。原理其实有点粗糙——就像把比特币网络复制了好几份，每条链都在处理交易，处理节点多了，速度自然就提上来了。不过，不同链之间具体怎么通信，目前官方也没给详细文档，细节还比较模糊。

如果只是二层网络反赌，那确实没啥好激动的。但 Fractal 重新启用了比特币早期因为安全原因删除的操作码 OP_CAT，这让它的能力一下子提升了不少。有人说 OP_CAT 能让比特币拥有智能合约的能力——这个想象空间就大多了。

所以现在，有人就在 Fractal Bitcoin 上搞出了一个类似 ERC20 的协议。

至于 OP_CAT 为什么被弃用、又为什么能在 Fractal 上用，这个可以另开一篇细聊，我们先专注 CAT20。

CAT 协议是怎么回事

• 以下内容参考了白皮书：Introduction | CAT Protocol (https://catprotocol.org/)
• 以及 GitHub 仓库：
• GitHub - CATProtocol/cat-token-box: 实现 CAT 协议的包集合 (https://github.com/CATProtocol/cat-token-box)

有了 OP_CAT 这个底层支持，很快就有团队搞出了 CAT 协议。目前跑起来的是 CAT20 协议，在 Unisat 上也有对应的面板可以查看：https://explorer.unisat.io/fractal-mainnet/cat20。

看到 CAT20 这个名字，你应该能猜到它跟 ERC20 有点像。ERC20 已经非常成熟，部署代币很方便，那 CAT20 是怎么实现类似的生命周期管理呢？

部署（Deploy）

部署之前，用户要指定自己的钱&包地址和代币基本信息。这些基本信息和 ERC20 差不多：

不同的是，CAT20 可以设置预挖数量以及每次 Mint 的数量限制。当然，ERC20 通过智能合约也能实现这些功能。

部署过程会发起两笔交易，分成两个阶段：「commit」和「reveal」。用官方的图来看，部署流程大概这样：

在「commit」阶段，交易输出脚本里会写入代币的基本信息，比如名称、符号等。这笔交易的哈希 ID 会作为这个代币的唯一标识，用来区分其他代币。

可以看到，这笔交易中「bc1pucq...ashx」这个 UTXO 就是 commit 的输出。剩下的两笔指向「bc1pszp...rehc4」的交易，第一笔是给后面「reveal」阶段付 gas 费，另一笔是找零。

在「reveal」阶段，输入有两笔 UTXO，对应 commit 阶段的前两个输出。这笔交易会先输出一个 OP_RETURN，里面保存了 CAT20 初始状态的哈希。然后会再输出一个 Minter，这个 Minter 会在后续的 Mint 过程中用来维护状态变化。

回头看整个部署过程，「commit」和「reveal」遵循了区块链上常见的“提交-揭示”机制。项目数据只有在 reveal 阶段才会公开，是一种比较常见的部署方式。

铸造（Mint）

我们来看看铸造代币时交易长什么样。

从上面的图可以看到，Mint 过程有这几点特征：

• Mint 的输入是一个 minter（铸造者），最开始由部署阶段生成。
• 每次 mint 只有且必须有一个 minter 作为输入，但可以有任意个 minter 作为输出（这点有点争议）
• 每次 mint 只有且必须有一个 token（也有点争议）
• 输出顺序有要求：minter 后面必须是 token

知道这些规则后，你会发现有些特殊情况会让 Mint 过程变得很有意思。

比如，minter 作为 mint 交易的输出，可以是 1 个、多个甚至 0 个。如果每次 mint 都只输出 1 个 minter，那么网络中可用的 minter 数量会保持不变（就 1 个），这样大家就会争着抢这个 minter，变得很拥挤。为了避免这种情况，最好每次输出多个 minter，这样 mint 之后可用 minter 越来越多。

不过，每多输出一个 minter 就意味着你得多付一笔 UTXO 费用。从经济角度考虑，很多人会倾向于把 minter 设为 0，这样 minter 数量就会不断减少。这就需要有人“无私”地多输出 minter，自愿多付费用。

在 V2 版本中，默认每次生成两个 Minter，而且这两个 Minter 的状态会尽量相近。

交易是怎么构建的

可能有朋友会问：为什么能用 minter 的 UTXO 来构建交易？要回答这个问题，得看看“合约”的源码。

先看 reveal 过程中的交易。它用了前一笔交易（commit）的输出作为输入。为什么可以用一个不属于自己地址的 UTXO 来构建交易输入呢？

通常逻辑是：私钥对应公钥，公钥生成地址。验证输入 UTXO 是否有效，是通过比对签名用公钥解密后是否与原始交易一致。这部分逻辑写在比特币脚本里。所以我们可以修改脚本逻辑，让脚本中用的公私钥对是我们自己地址的，这样就能控制两个不同地址的 UTXO 了。

看源码就能明白：

还有一个问题：一个私钥对应一个公钥，那为什么生成的 commit 地址和我们自己的地址不一样？源码显示：

也就是说，我们的私钥会基于一个 ISSUE_PUBKEY 来调整公钥，这是 P2TR 地址的一个特性。

在 reveal 过程中，虽然用了不同 UTXO 作为输入，但加密用的密钥其实是同一把——也就是部署者的私钥。但在 minter 阶段，所有人都能把这些 UTXO 当输入，这又是怎么做到的？

我猜测这靠的是前面提到的 OP_CAT 的能力，也就是智能合约的能力——每个 minter 就是一个智能合约。不过这部分源码目前没公开，具体实现还不清楚。

交易的状态（V2）

在 minter 里还保留着状态。状态存在两个地方：一个是交易输出的 OP_RETURN 里，另一个就存在智能合约里，也就是上面提到的 Minter 和 Token。

在 OP_RETURN 里存的是当前交易输出状态的哈希，合约里存的是 Token 剩余可 Mint 的次数。每次 Mint 之后，新生成的 Minter 的剩余 mint 数量会等于剩余可 mint 数量除以二。用图表示：

等到 mint 打完了，所有 Minter 的剩余数量就变成 0。

回到最开始那张图，除了 Minter 是智能合约，生成的 Token 也是智能合约——也就是 CAT20。CAT20 有两个基本状态：数量和 Token 归属者的地址。注意，跟 BRC20 或铭文不同，你的 CAT20 并不在你的地址 UTXO 上。

转账（Transfer）

转账的时候，构建交易的输入和输出 token 里的数量必须一致。同一笔交易里可以有多个不同 token，只要每个 token 的输入输出数量相等就行。

销毁（Burn）

想销毁 Token，只需要把它转到普通地址上就行。

总结

可以看到，所有操作都由用户自己构建，灵活性非常大，所以合约部分需要做很多校验逻辑。最近爆出的一些漏洞，就是因为校验逻辑出了疏忽。

这种设计有几个好处：

1. 如果想查所有 Token 的持有情况，只需要查一下 token 的 UTXO 就行，不需要往上追溯。

2. 如果想看 mint 的当前进度，搜索 OP_RETURN 里带“cat”标识的交易就行。