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的协议。

CAT Protocol

有了底层OP_CAT的支持,很快就出现了相应的协议CAT Protocol。目前一个已经在实际运行的协议是CAT20协议。

与成熟的ERC20协议相比,大家部署一个Token已经非常便捷,那么CAT20是如何实现类似ERC20的生命周期的呢?

Deploy

在部署之前,用户需要指定自己的钱包地址以及代币的基本信息,这些信息与ERC20的类似。CAT20的一些不同之处在于可以设置预挖和每次Mint的数量限制。当然,ERC20也可以通过合约能力实现这些功能。

部署阶段会发起两笔交易,可以看作是两个阶段:"commit"和"reveal"。在"commit"阶段,交易的输出脚本中会写入代币的基本信息,如代币的名称、符号等。"commit"阶段发起的交易hashId将作为该代币的标识,用于区分其他代币。

在"reveal"阶段,交易首先会输出一个OP_RETURN,其中保存CAT20的初始状态的Hash。之后会再输出一个Minter,它在后续的Mint过程中发挥重要作用,用来维护Mint过程的状态变化。

整个Deploy过程,"commit"和"reveal"遵循了区块链上常用的提交和揭示两个步骤,是一种比较常见的部署项目的方式。

Mint

Mint Token时,交易有以下几个特征:

• mint的输入是一个minter,最初由deploy时生成。
• 每次mint都有且只有一个minter作为输入,有任意个minter作为输出。
• 每次mint都有且只有一个token。
• 输出的顺序有要求,minter后面必须是token。

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

然而,每多输出一个minter意味着需要多支付一笔utxo。出于经济考虑,更多人会倾向于将minter设置为0,这不可避免地会让minter变得通缩,需要一些人进行奉献,自愿支付多出来的minter。

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

交易的构建

为什么可以使用minter的utxo进行交易构建?这需要对"合约"的源码进行分析。

在reveal过程中,交易使用了前一个交易的输出commit作为输入。这是通过巧妙地改写脚本逻辑实现的,在脚本中写入的公私钥对是我们自己地址的,这样就可以控制两个不同地址的utxo。

对于minter utxo,所有人都可以使用这些utxo作为输入,这可能是OP_CAT提供的智能合约能力,每一个minter就是一个智能合约。

交易的状态(V2)

minter中保留了状态,存储在两个地方:一是交易输出的OP_RETURN中,二是存储在智能合约中。

OP_RETURN中存储当前交易输出状态的Hash,合约中存储Token剩余的Mint次数。每次Mint后,新生成的Minter的mint数量会等于剩余可mint数量除以二。

除了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的交易。