长推：从ordinals铭文集合的新视角，解读Generative BRC-721标准

1.背景

项目地址https://github.com/jerryfane/generative-brc-721

链上费率居高不下， Generative BRC-721可以优化ordinals块空间的使用。

2.Generative BRC-721介绍

2.1 利用"deploy"操作来创建具有链上存储的独特特征的生成性BRC-721集合。然后，“mint”操作生成非同质序数，引用自deploy操作的特征。这个过程将块空间使用率减少了50%到90%。前端将需要适应从mint铭文文本数据重新创建和显示图像。

2.2

Base64是一种基于64个可打印字符来表示二进制数据的表示方法。这64个字符通常是A-Z、a-z、0-9和"+"、"/"，并使用"="作为填充字符。Base64的编码过程是这样的：将每三个字节的数据，一共24比特，划分为四组，每组6比特。这是因为64就是2的6次方，所以每6比特可以表示Base64的一个字符。对这四组6比特的数据，分别查找对应的Base64字符，进行替换。

可以将图片转换为Base64编码的字符串，然后在HTML中直接使用这个字符串，这样就不需要额外的HTTP请求来获取图片了。然而，使用Base64编码的图片会比原图片大约增加33%的大小，所以如果图片比较大，或者需要频繁地传输图片，那么可能不适合使用Base64编码。

3.操作

3.1 使用deploy操作创建一个生成性BRC-721集合

Deploy操作是一个包含集合的一般信息和构成集合的特征的base64编码数据的JSON/Text铭文。用于创建非同质序数的特征的独特图像在这个铭文中存储在链上。这个铭文作为特征的参考和最终来源。也可以为同一集合创建多个部署铭文，每个铭文将存储一组不同的特征。

3.2 使用mint操作为该集合创建一个非同质序数

Mint操作使用一个JSON/Text铭文，它封装了关于正在铸造的实际非同质序数以及对Deploy铭文的引用的信息。目的是将生成图像的属性值，最终图像的哈希值，以及集合Deploy铭文的引用存储在链上。这种方法允许任何人使用链上铭刻的数据重新创建图像。

3.3 将非同质序数作为铭文进行转移

4.优点

4.1 优化铭文的空间占用

部署的时候是将组件都部署为json铭文，mint的时候，直接调用该铭文内的信息，所以mint文本的体积会缩小。整个合集在上链过程中，会节约手续费。

4.2 方便管理合集

mint操作中，含有id等一些标签，方便后续项目方对合集的管理，这也是ordinals nft中的一个痛点，Generative BRC-721顺带解决了。

4.3 完全上链

完全上链，理论上也是去中心化的，在去中心化角度，和普通铭文没有区别，只是显示形式不一样。

5.缺点

5.1 节约的手续费不足，官方的项目ordibots只节约了55%，我认为这还是有点少，其实能节约多少根图片大小也有关系，图片越大，节约的比例越多。

5.2 需要前端配合，这是一个比较难达成的共识，市场上的钱包、交易市场不太可能会主动配合开发前端，除非市场规模大到一定程度。

5.3 绕了一步，类似以太坊二层网络，因为主网手续费太高，开发出了二层，如果主网持续火爆，二层有一定的价值，如果主网用户下降，二层的重要性也会下降。

6.总结

Generative BRC-721 在比特币链上费率高的背景下出现不足为奇，减少了手续费，更方便管理，但也距离简单更远了一步。我认为这是一个取舍问题，不存在谁更好谁更差，是想要更直观的链上nft还是经过前端解析的json nft。

Generative BRC-721在逻辑上是没有bug的，能够把合集归类顺便解决了，这是我更愿意看到的，有优点也有缺点，但正是这种创新推动ordinals一点点往前走。