比特币NFT的时代变了？「量子猫」Quantum Cats为何备受瞩目？

近期最受瞩目的比特币 NFT 项目，无疑是 Taproot Wizards「大巫师」团队即将发行的 Quantum Cats「量子猫」系列。

Quantum Cats「量子猫」

抛开「大巫师」在比特币 NFT 生态内强大的影响力以及玩家们对持有「量子猫」更有机会获得「大巫师」白单的影响，「量子猫」是一个很有趣的项目。「量子猫」用「进化铭文」来形容自己——每个「量子猫」都将随着时间的推移以及故事线的发展，以一种确定性的方式不断变化。

「量子猫」在一年后会变成什么样？

我们知道，比特币主网没有智能合约，而且铭文一经刻录内容就固定了，「量子猫」是怎么让铭文图像不断变化的呢？律动 BlockBeats 与您一起探索这个有趣的问题。在探索完这个问题后，我们也会发现，比特币 NFT 已经进入到了一个新的时代。

「量子猫」的变化——递归+预签名交易

Taproot Wizards「大巫师」的 CTO @rot 13 maxi 在推文中提到，为了实现「量子猫」的动态变化，他们使用到了如下技术：

- 递归铭文

- 预签名交易

- 对称加密

- 客户端负载管理

递归铭文想必大家都很熟悉了。简而言之，递归铭文使得铭文间能够相互引用并获取内容。递归铭文中有 JavaScript 代码，当使用浏览器查看包含了 JavaScript 代码的铭文时，浏览器会在沙盒中执行代码，最终呈现出运行代码所得到的内容。

通过引用链上的其它铭文来实现图像的变化，这很好理解，但是其它铭文如果已经上链了，引用的内容就是透明的，一切都不再有惊喜。怎么办？这里就用到了预签名交易——如果引用的内容是一个还没有上链的铭文，显示的结果自然是「 404 Not Found」。对实现「开图」动作的交易进行预签名，但是不广播它，等到某一天把预签名交易进行广播后，引用的内容就出现了，「量子猫」图像就会出现变化。

对称加密是为了保证在用户看到更新的图像前不会有任何的数据泄露，防止惊喜大打折扣。这里要提到的是，「量子猫」其实加了两道保险。第一道保险是多加了一层映射，比如背景、身体、鼻子等等特征都被分配为「层」，每一个「量子猫」都会指向一个 JSON 文件，其 ID 将被映射到一个新的短 ID，再将短 ID 映射到特征的铭文 ID，这个 JSON 文件被称为「层连接器」。在「层连接器」上链以前，持有者们都只能看到自己引用了「层连接器」，但是不知道执行后会被分配什么特征。

这第一道保险是为了防止直接引用铭文带来的麻烦。即使可以对直接引用的铭文进行延迟上链来保密，但是根据引用次数的多少还是可以算出「量子猫」的特征稀有度。

第二道保险才是对称加密，是为了防止在这个 JSON 文件上联防止在「开图」交易上链后可能遭遇突然的矿工费暴增的情况。交易若无法在第一时间完成，JSON 文件的代码就会在「开图」前泄露。咋办呢？只好对每「层」都对称加密了。

至于客户端负载管理，它和实现「量子猫」的动态变化其实没有直接关系，只是为了给用户在浏览一堆「量子猫」的时候提供良好的体验，防止网络超时和浏览器线程池耗尽。

「量子猫」的这种做法以外，还有 Pizza Ninjas 的递归 + Sat Endpoint 方法。

Pizza Ninjas 的变化——递归+Sat Endpoint

Sat Endpoint 实际上是一个大大强化了递归铭文的功能，通过使用 Sat Endpoint 功能，可以在一聪上进行重新刻录，也可以将存在于一聪上的不同版本铭文都调取显示出来。如果说「量子猫」的技术创新更多是为了其艺术叙事（致敬 OP_CAT) 和艺术行为（渐进式开图），那么使用 Sat Endpoint 的 Pizza Ninjas 就更多是想在功能上创造突破。

不仅如此，Sat Endpoint 实际上相比智能合约有「信任度」优势。

尽管铭文是不可变的，但 Sat Endpoint 可以利用重刻录来使得铭文能够以持有人许可的方式进行升级。智能合约的变更权掌握在项目方/开发者手里，但在比特币上，情况则完全不同——可以理解成一个软件会发布多个版本，用户可以自行选择留在自己喜欢/更为稳定的旧版本，也可以升级到最新版本，因为 NFT 的持有者才握有重刻录的权力。而且，使用了不同版本「智能合约」（实际上是一个 .js 文件）的 NFT 依然会完整保持在同一个系列下，不会像以太坊那样因为合约变更使一个 NFT 系列分裂成多个。