技术分享：CAT20 — Fractal BTC 上的代币协议

作者：ZAN Team

本文仅作为技术分享，不构成任何投资建议。

BTC 上也要有自己的智能合约了？

最近比特币生态上，Fractal BTC 在经历了多次测试网之后，终于在 9 月份上线主网。Fractal 的一大特点就是具备「智能合约」的能力，并且几乎在推出主网的同时，上线了一个新的代币协议 CAT20。CAT20 有什么技术上的巧妙设计呢？我们又可以学到什么？

Fractal Bitcoin

在了解 CAT20 之前我们需要简单了解一下 Fractal Bitcoin，他们的关系就像 ERC20 和 ETH 一样，CAT20 协议是部署在 Fractal Bitcoin 上的。

Fractal Bitcoin 又称作分形比特币，是一个完全兼容 BTC 的「二层」网络。相比于 BTC，它的区块确认时间更快，仅需要 1 分钟。它的基本原理简单来说就如它的名字所言，就是将 BTC 网络复制了几份，每条链都会处理交易，可以处理交易的节点多了，速度也就自然快了。不过具体的细节比如不同链之间是如何通信的目前还不是很清楚，官方也没有对应的技术文档可以参考。

如果只是一个二层链交易更快，似乎没有让人兴奋的点。但是，在 Fractal 中启用了 BTC 很久之前就因为安全原因弃用的操作码 OP_CAT，让 Fractal Bitcoin 的能力上升了一个台阶，有人说 OP_CAT 能让 BTC 具有智能合约的能力，这样的话可以遐想的空间就更多了。

现在，就有人在 Fractal Bitcoin 上实现了一个类似 ERC20 的协议。

关于 OP_CAT 为什么弃用以及为什么又可以在 Fractal Bitcoin 上使用，后续可以展开讲讲，这里我们关注 CAT20。

CAT Protocol

以下内容参考白皮书：Introduction | CAT Protocol (https://catprotocol.org/)

以及 github 仓库：

GitHub – CATProtocol/cat-token-box: A monorepo for packages implementing CAT protocol (https://github.com/CATProtocol/cat-token-box)

有了底层的 OP_CAT 支持，很快就有了对应的协议，CAT Protocol。目前一个已经在实际跑的协议是 CAT20 协议，在 Unisat 上也新增了对应的面板：https://explorer.unisat.io/fractal-mainnet/cat20。

看到 CAT20 的名字大家应该也能反应过来，它应该和 ERC20 比较像。相比于成熟的 ERC20 协议，大家部署一个 Token 已经非常的方便，CAT20 是如何实现 ERC20 类似的生命周期呢。

Deploy

在部署之前，用户需要指定自己的钱包地址以及代币的基本信息，代币的基本信息和 ERC20 的类似：

会有一些不同点 CAT20 可以设置预挖和每次 Mint 的数量限制。当然 ERC20 可以通过合约的能力也可以实现这些能力。

在部署阶段，会发起两笔交易，可以认为是两个阶段：「 commit 」和「 reveal 」。引用官方上的图，部署的阶段如下：

在「 commit 」阶段，交易的输出脚本中会将代币的基本信息写入，比如代币的名称、符号等。在「 commit 」阶段发起的交易 hashId 会作为该代币的标志，用于区分其他代币。

可以看到这笔交易「 bc1pucq…ashx 」这个 utxo 就是对应了 commit。然后剩下的两笔指向「 bc1pszp…rehc4 」的交易，第一笔是用于支付下面「 reveal 」阶段的 gas 费，另一笔则是找零。

在「 reveal 」阶段，可以看到有两笔 utxo 输入，对应了之前 commit 阶段的前两个输出。这笔交易首先会输出一个 OP_RETURN，在 OP_RETURN 中会保存 CAT20 的初始状态的 Hash。之后会再输出一个 Minter，它会在后续的 Mint 过程中发挥重要作用，用来维护 Mint 过程的状态变化。

回过头看整个 Deploy 的过程，「 commit 」和「 reveal 」遵循了区块链上常用的提交和揭示两个步骤，是一种比较常见的部署项目的方式，项目的一些数据只在「 reveal 」阶段才会揭露出来。

Mint

我们先看一下 Mint Token 的时候，交易是这么样的。

在上图中可以看到，Mint 的过程有以下几个特征。

• mint 的输入是一个 minter，最开始是由 deploy 的时候生成的。

• 每一次 mint 都有且只有一个 minter 作为输入，有任意个 minter 作为输出（有点点问题）

• 每一次 mint 都有且只有一个 token（有点点问题）

• 输出的顺序是有要求的，minter 后面必须是 token

知道了 Mint 的过程，其实我们可以发现一些特殊情况，会让整个 Mint 的过程变得有趣。

比如，minter 作为 mint 交易的输出，他可以是 1 个、多个甚至是 0 个。如果每次 Mint 的时候都设置为 1 个，那么整个网络中可以使用到的 minter 数量就会保持不变（1 个），这会让 Mint 变得拥挤，大家都需要抢这个 minter，为了避免这种情况，是需要将每次输出的 minter 数量设置为大于 1 ，这样 mint 之后，大家可以使用的 minter 就会越来越多。

不过，每多输出一个 minter 意味这你需要多支付一笔 utxo，出于经济考虑，更多的人会乐意将 minter 设置为 0，就会不可避免的让 minter 变得通缩，这就需要一些人来进行奉献了，自愿支付多出来的 minter。

在 V2 版本，默认是生成两个 Minter，并且两个 Minter 的状态会尽可能相近。

交易的构建

可能有小伙伴发现了一个问题，那就是为什么可以使用 minter 的 utxo 进行交易的构建？想要了解这个问题就需要对“合约”的源码进行分析。

1、reveal utxo

首先我们对 reveal 过程中的交易进行分析，我们发现他使用了前一个交易的输出 commit 作为输入。为什么可以拿一个不是我们地址的 utxo 构建交易的输入呢？

按照常理，一个私钥对应一个公钥，公钥派生出地址。当验证一个输入的 utxo 是否有效的时候，一般是通过比较签名用公钥解密之后是否和原本的交易一致来确定。这部分的逻辑是写在比特币脚本中的。所以我们可以巧妙的改写脚本的逻辑，在脚本中写的公私钥对是我们自己地址的，这样我们就可以控制两个不同地址的 utxo 了。

看源码我们就能知道发生了什么：

这里还会有一个问题，就是一个私钥对应一个公钥，那么为什么生成的 commit 地址会和我们地址不一样呢？这里从源码中可以看到

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

2、minter utxo

reveal 过程中，我们使用不同的 utxo 的作为输入，但其实加密的密钥是同一把，也就是部署者的私钥。但是在 minter 阶段，所有的人都可以使用这些 utxo 作为输入，这又是怎么做到的呢？

这部分我猜测是之前说的 OP_CAT 的能力，也就是智能合约的能力，每一个 minter 就是一个智能合约。不过目前这部分的源码没有公开，暂时不知道具体的实现是怎么样的。

交易的状态（V2）

在 minter 中，还保留了状态。这个状态存在两个地方：一个是交易输出的 OP_RETURN 中，另外就是存储在智能合约中，也就是上述提到的 Minter 以及 Token。

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

最后打完的时候，所有 Minter 的剩余数量为 0。

回到最开始的那张图上，除了 Minter 是一个智能合约之外，生成的 Token 也是智能合约，也就是 CAT20。CAT20 有两个基本的状态：数量以及 Token 的归属者地址。可以看到不像之前的 BRC20 或者铭文，你的 CAT20 并不是在你地址的 UTXO 上。

Transfer

Transfer 的时候，构建交易的输入和输出的 token 其里面的数量需要保持一致。当然同一笔交易里面可以有多个不同的 token，只需要不同 token 的其输入输出的数量保持一致就行。

Burn

想要燃烧掉 Token 的话，只需要将 Token 转到一个普通地址上即可。

总结

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

这样的设计可以有一些好处：

1. 如果想要查找所有的 Token 的持有情况，只需要查一下 token 的 utxo 就行，不需要继续往上查。

2. 如果想要查看 mint 的当前情况，可以搜索 OP_RETURN 中数据带有 cat 的交易就好。