摘要
递归铭文作为 Ordinals 最近的一次重大更新,为 Ordinals 协议的可组合性发展打开了广阔的想象空间。
递归铭文是一种铭文解析标准,创建 PFP 合集铭文可通过上传对应的元素特征,可以进行组合拼接,无需上传或下载实际图片。递归铭文有增强互操作性、降低成本、让铭文大小突破 4MB 限制等特点。
基于递归铭文的创意方向有:铭文拆解与组合、比特币音乐、比特币链游、生成艺术、去中心化网站等。本文详细介绍了一些结合递归铭文的典型案例,它们为我们展示了递归铭文的强大潜力。
递归铭文也面临着一些挑战:递归层级增加时链下渲染的相关解析器是否能够快速解析;引用铭文数量增加时链下渲染的相关解析器是否能够快速解析等问题。理论上,递归铭文产生的游戏或 NFT 可以无限复杂无限精细。但受 BTC 网络本身的限制,需要通过间接的技术方案进行实现。
递归铭文允许铭文相互交互,从而实现新的用例,生成艺术、链上展示和高效存储现已成为现实,我们可以对递归铭文有望得以深度采用的生成艺术、链游、元宇宙等赛道报以期望,相信未来的杀手级应用正在酝酿中。
![](https://img.jinse.cn/7189965_image3.png)
Ordinals 协议的诞生,为比特币提供了编号和铭文的功能,从而拓宽了比特币生态系统的产品范围,并为比特币生态带来了巨大的应用潜力。
在过去的短短的几个月内,我们看到了 Ordinals 赛道从默默无闻逐步成长为一个生态系统,期间 Ordinals 协议也经历了重要的升级,并产生了一系列的衍生协议:
![](https://img.jinse.cn/7158107_image3.png)
在我们六月份的 Ordinals 系列文章里,我们也更新了对 Ordinals 及 BRC20 各种衍生协议的详细介绍( link :https://medium.com/@gryphsisacademy/diving-into-ordinals-how-to-bet-on-bitcoin-ecosystem-as-halving-approaches-3486db8cbf12)
,这其中,不得不提 Ordinals 最近的一次重大更新——递归铭文的出现。
递归铭文是 6 月 12 日由比特币协议 Ordinals 新任首席维护者 Raph 在 Github 上宣布推出的,它进一步将比特币协议 Ordinals 创建者 Casey Rodarmor 提出的递归铭文 2167 号更新合并到 Ordinals 代码中,从而为 Ordinals 协议的可组合性发展打开了广阔的想象空间。
本文将探讨递归铭文的原理以及对 Ordinals 的影响,并结合现有的案例进一步展望递归铭文可能的创新应用方向。
![](https://img.jinse.cn/7189966_image3.png)
自 2022 年 12 月底以来, Casey Rodarmor 发布 Ordinals 协议,通过 Ordinals 和 Inscriptions (序数和铭文)为比特币网络引入了 NFT。
该协议可以将任意内容,如文本、图像、视频甚至应用,添加到按顺序编号的 sats(比特币中的最小单位),来创建独特的数字人工制品,并且可以通过比特币网络传输。下面我们梳理 Ordinals 协议所涉及的重要技术原理:
![](https://img.jinse.cn/7189967_image3.png)
比特币采用了一种称为“未花费交易输出” (UTXO,Unspent Transaction Output )的支付模型,所有的余额都存储在 UTXO 的列表中。每个 UTXO 都包含一定数量的比特币、所有者信息,并标明是否可用。
在比特币交易中,每笔交易有输入和输出。输入是现有UTXO的引用,输出指定新的地址和金额。发起交易后,输入锁定相关 UTXO,防止重复使用,直至交易被确认。确认后,交易的输入 UTXO 移除,输出生成新的 UTXO。
交易的总输入金额通常超过总输出,差额称为网络费,奖励打包交易的矿工。网络费与交易复杂性成正比,多输入输出交易通常需支付更高网络费。
![](https://img.jinse.cn/7189968_image3.png)
比特币网络上一共有 2100 万* 10^8 个聪。Ordinals 协议是如何做到为每一个聪进行唯一编号,并且如何追踪其所在的账户的呢?
根据 Ordinals 协议,聪的编号是根据它们被开采的顺序而定。Ordinals 的元数据并没有存储在一个特定的位置上,而是嵌入到交易的见证数据中,这些数据被像铭文一样“刻”在比特币交易的特定部分上,而这些数据正是附着在特定聪上的。
这一过程通过隔离见证(Segregated Witness, SegWit)和“向 Taproot 支付”(Pay-to-Taproot, P2TR)的方式实现,能够将任何形式的内容(如文本、图像或视频)铭刻在指定的聪上。
![](https://img.jinse.cn/7189969_image3.png)
SegWit 是比特币的一个重要协议升级,它将一些交易签名数据(见证数据)与交易本身分离,从而减少了存储在比特币区块中的数据大小。这个举措扩大了区块的容量,使其能够容纳更多交易,提高了网络的交易处理能力,并降低了手续费。
SegWit 协议升级引入了交易输出中的一个新的见证字段,以保护隐私和提升性能。虽然见证数据的设计初衷并非为了存储数据,但实际上它为我们提供了存储铭文等元数据的机会。
2021 年引入的 Taproot 协议升级使得不同交易条件可以更隐私地存储于区块链中。通过Taproot 脚本路径,我们能够将铭文内容存储在支出脚本中,这些脚本在内容方面几乎没有限制。而且,由于 Taproot 的折扣机制,存储铭文内容变得更加经济,可以节省大量资源。
Ordinals 协议巧妙利用了 SegWit 放宽了写入比特币网络内容大小的限制,将铭文内容存储在见证数据中,最多可以存储 4MB 的元数据。Taproot 使得在比特币交易中存储任意见证数据变得更加容易,这使得 Ordinals 的开发者 Casey Rodarmor 可以重新使用旧的操作码(OP_FALSE、OP_IF、OP_PUSH )来描述封装为铭文的内容,从而存储任意数据。
![](https://img.jinse.cn/7189970_image3.png)
通过以上两个步骤,铭文内容已经与其所铭记的 UTXO 绑定在一起。接着,根据之前所述的聪,铭刻是在输入的 UTXO 对应的第一个聪上实现的。铭文内容包含在显示交易的输入中。这个经过铭记的特殊聪可以被转移、购买、出售、丢失和恢复。
![](https://img.jinse.cn/7189971_image3.png)
了解完 Ordinals 的基本原理,我们再来看递归铭文:
Ordinals 协议引入了在比特币上将文件完全铭刻于链上的能力,在递归铭文出现之前,序数犹如孤立且有限的岛屿。虽然你可以铭刻文本、图像和代码,但它们无法相互交互。
然而,随着递归铭文的引入,情况即将发生改变。现在,铭文可以使用特殊的 "/-/content/:inscription_id" 语法来请求其他铭文的内容。这使得用户在比特币链上创建铭文时可以使用更少的容量和更低的手续费。
递归铭文是一种铭文解析标准。其语法本质上类似于使用代码来寻找图像,创建 PFP 合集铭文可通过上传图片对应的图案、颜色、动作等元素特征,然后可以将链上已存在的相应元素进行组合拼接,无需上传或下载实际图片。
![](https://img.jinse.cn/7189972_image3.png)
递归铭文具有以下特点:
通过递归铭文的独特自引用属性,我们有机会打破之前铭刻方式的束缚,摆脱了每个铭文孤立无关的尴尬状态,从而开启了创造自由组合的可能性。
递归铭文以其文字代码的形式,保持了体积的小巧,不仅降低了成本,还让铭文的大小能突破比特币区块 4MB 的限制。
这一进步增强了互操作性、可编程性和扩展性,为比特币链注入了更多可能性和创意想象。
从协议层面来看,未来的前景十分广阔,有着丰富的叙事等待着开发者和用户去建构和运用。
然而,目前还存在一些挑战,例如铭文是否能在平台上线合集和索引,这将决定其发展的速度和被广泛认同的程度。
![](https://img.jinse.cn/7189973_image3.png)
递归铭文的出现解锁了许多强大的创新应用。递归铭文具有灵活性度高的调用性、拼接组合性和低成本优势,给铭文带来了无限的新可能,下面本文将以部分具体案例来介绍递归铭文的潜在创新和应用方向。
通过递归,Inscriptions 可以轻松引用其他 Inscriptions 的代码。一个铭文的内容现在可以被许多其他铭文使用。这种新的可组合性开辟了我们几乎没有探索过的可能性领域,例如可以将复杂的图片视频、3D 游戏等形式的内容刻在链上。递归铭文使建立一个内部互联网成为可能。更多的可能性包括铭文二次创作、GitHub 去中心化、NFT 组合碎片化等等。利用递归铭文,我们可以实现以下创意:
![](https://img.jinse.cn/7189974_image3.png)
下面我们详细介绍一些典型的案例,它们为我们展示了递归铭文的强大潜力。
![](https://img.jinse.cn/7189975_image3.png)
通过对前面所提到的各种初阶方案进行进一步的搭配组合,进一步的可以实现各种合集的组合、铭文的二创等:例如a合集内部的 a1 与 a2 进行组合,a 合集和 b 合集进行组合。在此基础上,BTC链上有望诞生真正由社区驱动的原生的交互式生成艺术。
我们先来看第一个案例:1Mask。
这是 BTC 链上的一个以面具为主题的全链上生成艺术项目。1Mask 项目巧妙地融合了 Ordinals 的递归技术,整体由模版、算法以及铭文生成三个要素交织而成。
![](https://img.jinse.cn/7189976_image3.png)
Source:https://1mask.io/
模版部分共包含七种铭文,分别对应七个独特类型的模版,其格式遵循 image/svg+xml。
算法部分的基本原理在于将用户钱包地址作为种子,运用随机函数创造多种不同的颜色组合,以用来为面具模型上色。
铭文生成机制借助递归技术实现对算法铭文的引用。每个面具铭文均内嵌了构建最终多彩面具图像所需的 HTML 代码。其实现方式在于运用随机种子执行嵌存于算法铭文中的代码,同时以特定于用户的链上数据(如钱包地址)填充该随机种子,使其具备随机性但与用户相关。因此,同一钱包地址在使用相同模版时,生成结果始终保持一致。
每当创造一则全新的面具铭文时,其中融合了用户特定的链上细节,并引用了算法铭文。借助递归铭文技术的威力,一经新创的面具铭文进入市场或被钱包索引,它便自主激活内含于算法铭文的参考代码。这些代码运行时采用用户特定的链上数据作为输入,最终展示出独一无二、彰显个性的面具图像。
在比特币网络环境下,铭文蕴含的数据具有不可变性,从而确保了其完整性。这种特性决定了以这一不可更改的铭文数据为基础所呈现的实时图像也同样具备不可变性。只要面具铭文中所涉及的随机种子和算法正确,用户随时都能验证创作过程的真实和准确。
在这个项目的背后,1Mask 进一步推出了一个叫做 BRC721Auto 的标准,提出了完全链上生成艺术至少由两种铭文组成:一是代码的铭文,二是个性化参数的铭文。
在代码铭文中,我们需要编码一个算法,可以根据参数的内容自动生成 HTML DOM。该 DOM 可以是画布、SVG 或其他可以被浏览器识别并相应渲染为图形的内容。
当然,代码铭文也可以引用其他铭文的内容来完成其算法。
在参数铭文中,我们需要定义一个 HTML,并在其中定义一个全局参数 p 来引用一个 Code Inscription。当普通浏览器尝试显示这个 Parameter Inscription 时,它们会识别出全局参数 p ,并自动执行 Code Inscription 中的 start ()函数来添加或修改当前 HTML 的 DOM,最终渲染这个 HTML 的内容。因此,参数铭文可以被视为最终的 NFT(Non-Fungible Token)。
借助 Recursive Inscription 技术,将生成图形所需的代码、代码的执行过程、验证过程都置于比特币区块链共识的保护之下。除非有人能够对比特币发起 51% 攻击,否则没有人能够控制 ERC721Auto NFT 的生成过程,该生成过程将由比特币生态系统自主执行。
1Mask 还进一步提出了全链上生成艺术项目的三大标准。这三大标准是:
根据以上标准,不难发现,基于递归铭文的链上艺术具有以下特点:
相比以太坊等其他链上的生成艺术项目,基于 BTC 递归铭文的生成艺术是完全链上的生成艺术,是独立的、不依赖任何链下资源的去中心化生成艺术。
![](https://img.jinse.cn/7189977_image3.png)
由于递归铭文的灵活性,这为极客们提供了施展才华的舞台,富有极客精神的项目进一步探索着 Ordinals 技术的各种可能性边界。
“Orbinals” 就是这样的典型代表,它是一个没有推特没有官网的极客项目,项目所有的内容都是基于 Uncommon sat 之上的,根据 f2pool 最新的价格显示,截至 8 月 20 号,Uncommon sat 的单价达到了 366 美金以上。
![](https://img.jinse.cn/7189978_image3.png)
Source:https://www.ord.io/?satributes=uncommon&contentType=html&sortBy=newest
如果直接打开 Orbinals 的收藏系列网址,你会发现它的天体运动系列的每个图打开之后引用的一些内容是一样的,里边参数会有一些不同,在它的递归铭文里边深扒所引用的内容后,我们可以发现关于项目的真实秘密藏在这个引用链接里(https://ordin-delta.vercel.app/content/b5091b76f78d73677ad6b81e4785b0dfebc62b1079a0bf78b8366859a1ffacbci0) ,Orbinals 的全称是 “Orbinals: Three Body Orbit Artifacts on Ordinals“,它的背后是使用 HTML 和 JavaScript 对三个物体的运动进行编程,建立在二体仿真代码的基础之上的。
![](https://img.jinse.cn/7189979_image3.png)
Source:https://evgenii.com/blog/three-body-problem-simulator/
在数学与物理方程的支撑下,天体运动之美以一种简洁的方式呈现在比特币链上。
并且由于不设立 Twitter、Discord、官网等任何社交媒体,项目将很有可能使用一种很极客的方式,未来的信息将呈现在团队自己掌握的 sats 上。
![](https://img.jinse.cn/7189980_image3.png)
Source:https://ordin-delta.vercel.app/content/b5091b76f78d73677ad6b81e4785b0dfebc62b1079a0bf78b8366859a1ffacbci0
除了项目方披露的四个渠道以外,还隐藏了一个彩蛋:在项目引用的铭文内容中(https://ordin-delta.vercel.app/content/4f59fc257a7c78d4074dcd7a4a55360d56986f474700adc7dc37ac231901fc40i0),代码中藏着一串说明:future Communication channels on /sats/ acknowledge,而 acknowledge 也正好是归属于团队的一个 sats。
![](https://img.jinse.cn/7189981_image3.png)
Source: https://www.ord.io/sat/1940129935364125
![](https://img.jinse.cn/7189982_image3.png)
BRC69 是 Luminex 发布的打造递归集合的新标准(https://github.com/luminexord/brc69),该标准利用递归铭文来优化使用序数协议在比特币上铭文的成本,有助于在比特币上推出递归集合。此外,BRC69 提供高度灵活性,并为更多增强功能和功能打开了大门,为更有趣的链上功能铺平了道路,例如预展示功能等。
借助 BRC69,可以将 Ordinals 收藏的铭文成本降低 90% 以上。这种减少是通过 4 个步骤的过程实现的:
只要 collection 创建者按照当前要求发布其藏品的官方铭文列表,所有这些过程都可以在不需要外部索引器的情况下进行。此外,图像将自动渲染在所有已经实现递归铭文的前端界面上,无需额外的步骤。
Orditroops 就是基于 BRC69 的一个递归 NFT,它落实了 BRC69 协议的内容,增加了特性的可组合性,缩小了图片的占用空间,图片相当高清,士兵、武器、装扮的灵活搭配都给这个 NFT 集合增添了很多特色和乐趣。
![](https://img.jinse.cn/7189983_image3.png)
Source: https://twitter.com/OrdiTroops
![](https://img.jinse.cn/7189984_image3.png)
![](https://img.jinse.cn/7189985_image3.png)
Source: https://www.ord.io/3563188a3db53850bba48747293def7bd6b7395e4241b29ec7d49892945cf927i0
OCM 是应用递归铭文标准的第一个 3D NFT 项目。OnChainMonkey 最早是 2021 年 9 月在以太坊上创建的 NFT 项目,在今年早些时候,OnChainMonkey 系列作为第一个被刻在比特币上的 10k 系列出现。
作为一种高分辨率的 3D 动画铭文,OCM 很快以细节和质量脱颖而出。要知道,在它之前大部分铭文仍然是小文本文件或低分辨率图像。即使在 4K 或 8K 显示器上 OCM 也能提供较好的清晰度,这种质量是通过每个大小不超过1 KB的文件来实现的,这是 OCM 之前的项目很难达到的。
OCM 之所以能够实现这些,是因为它率先使用了强大的递归铭文。OCM 的前 300 个刻在比特币上的连续 300 个聪上,从 2009 年的第 78 区块开始,按其聪数升序在链上排序。OCM 构建者使用了压缩的代码,并且引用了 P5.JS 和 Three.JS 库,以供未来的创建者使用。用户可以在浏览器查看并访问库,渲染 Dimensions Interactive Art 时自动在 Ordinals 协议中进行解压缩。
通过递归铭文,OCM 高效地利用了区块空间(每个小于 1 KB),并且实现了随机的链上揭示,将高清品质、3D、动画和互动艺术等特征集于一身。
![](https://img.jinse.cn/7189986_image3.png)
![](https://img.jinse.cn/7189987_image3.png)
Source: https://ordinals.com/content/6fd06768414dfc2bd68b55869eea6844864fbf71ee72ec26568520e313c2bda2i0
输入任何单词或短语即可生成独特的链上音乐,该音乐引擎是 MUD RPG 游戏 “Descent Into Darkness” 的配套产品,通过输入关键词来生成音乐。
创始人 Ratoshi 强调了 ChatGPT 在开发该项目使用音乐方面发挥了重要作用,而使用递归铭文有助于显著节省成本。区块链技术和人工智能的特殊结合,向复古电子游戏的经典音乐致敬。
![](https://img.jinse.cn/7189988_image3.png)
一个游戏需要图片、前端、业务逻辑等多种组件素材构成,如果素材总大小小于 4M,则可以通过铭刻一个 Sat 完成,不需要使用递归铭文。
有两种情况下,适合使用递归铭文技术:
素材本身大(大于 4M),比如一个背景图 5M 则无法直接铭刻到一个 Sat 上,但是可以拆分后,放入不同 Sat 进行引用显示出来;
如果要实现更好业务逻辑,如有 100 个 Sat 铭文是一个系列的游戏,使用的是同一个 JavaScript(JS)文件,在这种情况下,也适合会使用递归铭文,因为没有必要每个 Sat 都将 JS 文件重新铭刻一次。
游戏的 HTML(前端) 和 JS (业务逻辑)都刻在 BTC 的“聪”上,互相引用,便可以生成一个单人 H5 小游戏。
下面是这类单人 H5 小游戏的 3 个示例:
a. 贪吃蛇游戏
![](https://img.jinse.cn/7189989_image3.png)
Source: ord.io/431507
Bitcoin Snake Game,这个游戏是典型的 H5 单人小游戏,也是大家熟知的游戏:贪吃蛇。这个游戏的前端和执行逻辑全部写在这个 Sat 上,并没有使用递归铭文技术,这个系列 NFT 总量为 100 个。
其实,更加好的方法应该是在一个 Sat 上铭刻 JS 文件(业务逻辑),然后用 100 个不同的铭刻 HTML 的 Sat 去引用(或者叫做递归)这个 JS 文件所在的 Sat 生成铭文。这样会更加简洁。
b. 连连看游戏
![](https://img.jinse.cn/7189990_image3.png)
Source: ord.io/18201467
如图所示,该游戏为 3*4 数位方格(此为简单模式,复杂模式为 6*6 数位方格),一次可以点开两个方格,当两个方格图片相同时,则固定下来显示;不同时候,则直接显示为问号,在一定的点击次数内完成才算胜利。限制点击次数,来考验玩家的短期记忆力。
此游戏类似大家熟悉的连连看游戏。这个游戏的 JS 和 HTML 全部铭刻在这个 Sat 里,但是其引用了“背景图片”(background image 如下图所示),所以是递归铭文的一个简单应用。
![](https://img.jinse.cn/7189991_image3.png)
Source: ord.io/18201467
c. MUD游戏
![](https://img.jinse.cn/7189992_image3.png)
Source: https://ordinals.com/content/1915ae7d46502199a7d03256efd7f6e2f6aabb8ed7176b34f70b7b8fd778b36ci0
Descent into Darkness,是一款基于文字的角色扮演游戏,结合了经典的 MUD 游戏元素和ordinals 技术,为玩家提供了一个独特的游戏体验。
在 Descent into Darkness 中,玩家将扮演一个冒险者在黑暗中寻求出路,游戏中有怪物和任务以及 BOSS 战,玩家需要与怪物战斗以完成任务,解锁新任务以及获取金币升级装备和购买物品。
以上 3 个单人 H5 小游戏,是非常简单的应用,作为游戏是不完备的,游戏开始、进行、结束等过程都没有上链,游戏的过程也无法进行存档,游戏结束后,Sat 的铭文也没有任何改变。,只定义了游戏的逻辑,而没有保存游戏的状态。这只是 BTC 链游的初步尝试。
![](https://img.jinse.cn/7189993_image3.png)
![](https://img.jinse.cn/7189994_image3.png)
Source: https://twitter.com/btcpixelwar
BTC PixelWar 是一款 BTC 全链上多人游戏,该项目声称是 BTC 链上的第一款全链多人游戏。参与者在 256*256 像素格的画布上,进行创作。可以直接点击像素点,也可以将图片上传生成像素点放到画布上。
每次 Submit 都会产生一个整张画布最新状态的铭文,每次产生的铭文都引用上次已经产生的铭文状态,铭文层层递归,这或许是目前市面上递归次数最多的一个项目,也是递归铭文应用领域一个具有标志意义的应用。
该项目提出了一种全新的标准,“BRC721Cofound”,该标准利用递归铭文使所有比特币用户可以在同一张画布上进行协作,并记录其过程,每个时刻都是一个铭文,描绘了共同创建的画布这一时刻的样子,该铭文称之为“时刻铭文”,包含了此时新添加或更新的像素,并且包含了对之前“时刻铭文”的引用以及处理两个时刻之间图像变化的“代码铭文”。
考虑到共同参与作画的人数可能很多,渲染最新画布状态需要深度递归才能加载每个人绘制的像素,然而此过程可能会导致加载时间的延长,为了解决这个问题,“代码铭文”设计为在当前“时刻铭文”渲染完成后对最新画布状态进行快照。然后将此快照存储在当前“时刻铭文”的DOM树中。因此,顺序浏览器可以通过缓存每个渲染时刻铭文的 DOM 树来简化渲染过程,从而减少递归层数。
总体来说,BTC PixelWar 是一款具有创新性和标志性的 BTC 多人全链上游戏,实现了多人协同创作的同时,优化了渲染过程,引入的 “BRC721Cofound” 标准为比特币链上的多人游戏应用领域开辟了新的可能性,也展示了递归铭文在游戏和社交领域的潜力。
![](https://img.jinse.cn/7189995_image3.png)
递归铭文,开启了链上铭文 2.0 的时代,使得 BTC NFT 的玩法越来越丰富,BTC NFT 走出与以太坊等其他链的 NFT 完全差异化的道路已经越来越可能了,未来的想象/叙事空间很大。
递归铭文让之前独立的铭文直接有了联系,可以互相引用,从而形成类型繁多的数据库的结构。在过去的文章中,我们讨论了基于 Ordinals 的各类衍生协议,实际上递归铭文和前文讲到的衍生协议搭配起来,将能通过读取其他铭文并根根据自身的智能指令做出反应从而更新自己的状态,通过索引就能直接操作协议的状态,这样就形成了一套连贯的类似智能合约效果的动作。
与此同时,庞大的递归铭文数据库给铭文更多操作空间和想象空间,其中包括基础数据、知识库、代码库、函数库等各个领域的元数据,而且他们直接可以互相引用,实现复杂逻辑的产品应用,因此我们可以对递归铭文有望得以深度采用的生成艺术、链游、元宇宙等赛道报以期望,相信未来的杀手级应用正在酝酿中。
与此同时,递归铭文也面临着一些挑战:
如果递归层级增加,如增加到一万层递归,链下渲染的相关解析器是否能够快速解析;
如果引用铭文数量增加,如一个 Sat 同时引用了一万个铭文,链下渲染的相关解析器是否能够快速解析。
如果这两点能够做到,理论上,则递归铭文产生的游戏或 NFT 可以无限复杂无限精细。这两个问题受 BTC 网络本身的限制,很难从根本上解决,但是,可以通过间接的技术方案进行实现。
![](https://img.jinse.cn/7189996_image3.png)
Ordinals 协议中的递归升级允许铭文相互交互,从而实现新的、令人兴奋的用例。有了这个功能,生成艺术、链上展示和高效存储现已成为现实,我们能够看到,BTC 生态内的开发者们正在继续沿着链游、生成艺术等方向做着各类创造与开发,基于递归铭文的作品接连涌现,构建一个庞大工程的各种零部件正在慢慢集齐中,未来我们可以进一步期待具有复杂产品逻辑的链上游戏、元宇宙、交互式生成艺术等项目的诞生。
![](https://img.jinse.cn/7161529_image3.png)
声明
本报告是由 @GryphsisAcademy 的学生 @JellyZhouishere 完成的原创作品, 由 Gryphsis Academy 导师 @979_eth 和 @Erjiueth 给出修改建议。作者自行对所有内容负责,该内容并不必然反映 Gryphsis Academy 的观点,也不必然反映委托撰写报告的组织的观点。编辑内容和决策不受读者的影响。请知悉,作者可能拥有本报告中提到的加密货币。本文件仅供信息参考,不应作为投资决策的依据。强烈建议您进行自己的研究,并在进行投资决策之前咨询中立的财务、税务或法律顾问。请记住,任何资产的过去表现并不保证未来的回报。
参考资料
[1]https://github.com/1nftopia/brc721cofound
[2]https://github.com/1nftopia/brc721auto/tree/main
[3]https://medium.com/@gryphsisacademy/diving-into-ordinals-how-to-bet-on-bitcoin-ecosystem-as-halving-approaches-3486db8cbf12
<p );'>