对BRC420 和 Bitmap协议的学习。 主要内容来自官方文档
BRC420是个比特币链上铭文的嵌套协议。有两个主要作用:
当前web3上的内容是碎片化的。例如一个游戏资产,游戏结束(倒闭)后就没有价值了。 因此考虑引入一套协议,设置人人都可使用的公共资产。通过共识,让链上游戏们都能遵守这套协议。如此就让链上资产称为永久资产。即使你参与的游戏不存在了,这份资产也可以继续在其他游戏里使用。
基本资产由三部分组成: ● 基本资源(Base data).存储和设置资产的基本属性。可以在“程序扩展属性”中扩展和引用这些特性。可能包括: ○ 图形资源铭文地址:指向资源的视觉表示的地址,例如图像、3D 模型等。 ○ 基本属性:例如大小、动画设置和其他使资源可用的属性在基本层面上。 ● 预览显示(previewData)用于预览 Ordinals 生态(如 Ordiscan 或其他网页)中的资产。高度可定制,理论上遵循嵌套原则,允许多种显示选项。主要包含两部分: ○ 显示属性:定义资源的显示方式。可能包括帧大小、宽高比或为预览定制的特定设置等内容。 ○ 属性显示代码(链上):需要上传到链上,让显示属性起作用的实际代码。 ● 程序数据(appData)存储特定于应用程序的属性,使得该资产能够在各种应用程序中具有高度的通用性和适应性,确保其在不同的用例中保留其价值和实用性。 ○ 自定义属性:应用程序可以为资产定义自己的一组独特属性。 ○ 外部属性引用:应用程序可以引用其他应用程序中定义的属性,也可以构建自己独特的属性块进行扩展。 完整的资源铭文应至少包含“metaverse”和“metaversepreview”部分。如果没有“metaverse”,协议就毫无意义;如果没有“metaversepreview”,资源可能仍然适用于游戏和应用程序,但可能无法在浏览器等(例如“ordiscan”)上显示或预览,并且图像可能会显示错误 <!--StartFragment-->
<!--EndFragment-->
递归铭文使用XML
就如上面示例中的metaverse和metaversepreview展示的代码,就是一些基本图片和显示设置的组合。通过组合来实现更复杂图片的显示。 https://rcsv.gitbook.io/brc-420/brc-420-metaverse-standard/1.1-2d-inscription
3D铭文更复杂一些,涉及到模型和材料。具体参见: https://rcsv.gitbook.io/brc-420/brc-420-metaverse-standard/1.2-3d-inscription-experimental-stage
就是通过对铭文进行嵌套,然后增加新扩展的属性,来形成更复杂多样性的铭文。 <!--StartFragment-->
<!--EndFragment-->
允许出售铭文的副本,以及使用权。 有如下角色: ● 所有者(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/
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/
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!