1. BRC420

BRC420是个比特币链上铭文的嵌套协议。有两个主要作用：

1. 如何让铭文之间互相引用（可递归），从而构造更复杂，生动的链上世界（元宇宙）。
2. 铭文引用如何定价收费

   1.1 问题和方案

   当前web3上的内容是碎片化的。例如一个游戏资产，游戏结束（倒闭）后就没有价值了。 因此考虑引入一套协议，设置人人都可使用的公共资产。通过共识，让链上游戏们都能遵守这套协议。如此就让链上资产称为永久资产。即使你参与的游戏不存在了，这份资产也可以继续在其他游戏里使用。

   1.2 metaverse 协议

   基本资产由三部分组成： ● 基本资源（Base data）.存储和设置资产的基本属性。可以在“程序扩展属性”中扩展和引用这些特性。可能包括： ○ 图形资源铭文地址：指向资源的视觉表示的地址，例如图像、3D 模型等。 ○ 基本属性：例如大小、动画设置和其他使资源可用的属性在基本层面上。 ● 预览显示（previewData）用于预览 Ordinals 生态（如 Ordiscan 或其他网页）中的资产。高度可定制，理论上遵循嵌套原则，允许多种显示选项。主要包含两部分： ○ 显示属性：定义资源的显示方式。可能包括帧大小、宽高比或为预览定制的特定设置等内容。 ○ 属性显示代码（链上）：需要上传到链上，让显示属性起作用的实际代码。 ● 程序数据（appData）存储特定于应用程序的属性，使得该资产能够在各种应用程序中具有高度的通用性和适应性，确保其在不同的用例中保留其价值和实用性。 ○ 自定义属性：应用程序可以为资产定义自己的一组独特属性。 ○ 外部属性引用：应用程序可以引用其他应用程序中定义的属性，也可以构建自己独特的属性块进行扩展。 完整的资源铭文应至少包含“metaverse”和“metaversepreview”部分。如果没有“metaverse”，协议就毫无意义；如果没有“metaversepreview”，资源可能仍然适用于游戏和应用程序，但可能无法在浏览器等（例如“ordiscan”）上显示或预览，并且图像可能会显示错误 <!--StartFragment-->

<!--EndFragment-->

递归铭文使用XML

2D铭文

就如上面示例中的metaverse和metaversepreview展示的代码，就是一些基本图片和显示设置的组合。通过组合来实现更复杂图片的显示。 https://rcsv.gitbook.io/brc-420/brc-420-metaverse-standard/1.1-2d-inscription

3D铭文

3D铭文更复杂一些，涉及到模型和材料。具体参见： https://rcsv.gitbook.io/brc-420/brc-420-metaverse-standard/1.2-3d-inscription-experimental-stage

Re-Inscription

就是通过对铭文进行嵌套，然后增加新扩展的属性，来形成更复杂多样性的铭文。 <!--StartFragment-->

<!--EndFragment-->

1.3 版税协议（Royalty）

允许出售铭文的副本，以及使用权。 有如下角色： ● 所有者（owner）：特定铭文的当前所有者。 ● 部署者（deployer）：用于部署特定铭文的BRC420的钱包。部署者与所有者相同。 ● 版税接收者(Royalty Receiver)：用于获取 Minter 支付的版税费用的钱包。版税接收者与部署者相同。 ● Minter：用于通过遵循 BRC420 协议为特定铭文铸造递归内容的钱包 如何使用： ● 部署 BRC420 作为一个铭文的owner。可以将使用费在铭文部署函数中指定。minter支付的使用费将始终转入部署者账户。 ● Mint 递归任何人都可以按照部署函数中定义的参数来写入递归内容。也就是说，必须向brc420部署者支付部署函数中定义的额外版税。该费用应在铸造铭文过程（commit-reveal inscription）的交易中支付。 目前文档中没有说明版税是如何被强制支付的。不知道是否有一种BRC20代币可以用来支付该版税。 部署 每个铭文只能部署一个brc420，后续无论它在哪个账户中流通，后续的部署都是无效的。

mint ● 每个人都可以根据 brc420 部署铭文定义的规则铸造递归铭文 ● brc420定义的递归铭文的mime-type 应与原始铭文相同 ● 内容简单地遵循递归风格：/content/<INSCRIPTION_ID>，这里的INSCRIPTION_ID指的是要递归的铭文，它与brc420部署铭文中指定的铭文id相同 ● 在mint过程中，应将正确数量的 BTC 发送给 brc420 部署者 项目： https://rcsv.io/

2. Bitmap

Bitmap是把历史上的比特币区块打成铭文，如3241123.bitmap。谁打了，这个区块就归谁。比特币已经有70多w个区块，因此可以初始打70多w张。后续每天100多个块，每天就能多增加100多张，看谁打得到。 每个区块里有很多交易，Bitmap会根据交易转账的value，使用的数据长度等，把一个比特币区块抽象成一个2D或3D的图片。 <!--StartFragment-->

<!--EndFragment-->

<!--StartFragment-->

<!--EndFragment-->

交易所： https://magiceden.io/ordinals/marketplace/bitmap https://ordinalswallet.com/collection/bitmap 设计： Bitmap以聪为单位，每个聪代表一个点。 一个块称为一个District，块里的交易称为Parcels，它们有包含关系；当一个块被铭刻时，块里的交易也跟着它被打了。如果块被转让了，那么里面的parcels也被转让了，这里有个父子关系。但parcels也可以单独被打铭文，从而拥有独立的right，如果交易被打了，其right就不再跟随district了。如：0.404.bitmap， 0代表404这个块里的第0个交易。只有district的owner才能给这个district里的parcels打铭文。并不推荐给parcel打铭文，因为这样会导致交易district时，对里面的parcels的归属权混乱。如果要交易district，需要把里面的parcels的归属明确的表达出来。 1.0.404.bitmap代表404块第0个交易的第1个输出。1.这个层级称为chunk -1.0.404.bitmap代表404块第0个交易的第1个输入。称为caves，它代表chunk之间的空间。 21.1.0.404.bitmap，21代表404块第0个交易的第一个输出的第21个聪，称为Blanks。是能索引/引用到的最小颗粒。blank可以是cave的或者chunk的，分别代表空白点或陆地点。可以是处于UTXO空间或已消费的空间（称为bitoshi space）. Portal：输入和输出是联系的，也就是类似一扇门，可以通往其他district等。 Warp Zone：即比特币地址，一个地址的交易的输入，输出就是绑定的portal Neighbourhood ：每2016个district就是一个Neighbourhood ，这是难度调整的范围。 Section ：每210000district是一个Section ，对应减半 Blockstep ：表示两个区块之间的时间。 Entities：每个铭文被称为一个实体，可以添加自定义属性，可以在游戏里添加各种应用。 构建： 亲子法：可以以District, Parcel, or Chunk为parent，创建一个子铭文，从而为该地块提供metadata，描述该地块的属性。 pinning法：还在设计和实现中，想法是把铭文和输入输出绑定，并添加metadata 地形修改： Bitoshi->Satoshi，表示地形的修改，即余额的变动。表示能量无法进入或离开该系统，只能移动。可以通过提取Bitoshi来改造地形，但没看懂怎么弄。还在设计开发。 Signal: 还在开发中。它面向的是District, Neighbourhood, Section这级别的，这个级别上没有人可以控制，它就像一个区域、地块或块所做的声明，广播到更广泛的网络。 Command: 对各种entity产生作用。可自定义。支持不同的游戏对同一个地块并行起作用。 一些项目： https://medium.com/@Trubitzh/%E8%A7%A3%E8%AF%BB%E6%AF%94%E7%89%B9%E5%B8%81%E7%94%9F%E6%80%81%E6%9C%80%E5%A4%A7%E7%9A%84%E5%85%83%E5%AE%87%E5%AE%99%E9%A1%B9%E7%9B%AEbitmap%E7%94%9F%E6%80%81%E5%8F%91%E5%B1%95%E7%8E%B0%E7%8A%B6-51b169745ca2 https://bitmap.game/