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

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

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

Fractal Bitcoin

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

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

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

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

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

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。目前一个已经在实际跑的协议是 CAT 20 协议，在 Unisat 上也新增了对应的面板：https://explorer.unisat.io/fractal-mainnet/cat20。

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

在上图中可以看到，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 来调整公钥，这也是 P 2 TR 地址的一个特性。

2、minter utxo

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

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

ZAN 无门槛领水来啦！

Tip：每 24 小时可领取一次 0.01 ETH free testnet token，以支持您在以太坊生态内体验和测试 Web3 项目，点击马上领取: https://zan.top/faucet?chInfo=ch_WZ

更多公链即将支持～

本文由 ZAN Team（X 账号 @zan_team） 的 Yeezo（X 账号 @GaoYeezo 75065 ）撰写