铭文是在单个聪上铭刻任意内容,创建独特的比特币原生数字收藏的协议。
铭文的优势
- 铭文不依赖侧链或单独的代币。
- 铭文可以保存在比特币钱包中,并使用比特币交易进行传输。
- 铭文与比特币本身一样持久、不可变、安全和去中心化。
铭文的劣势
- 为了发送特定铭文,必须根据序数理论严格控制输入输出的顺序和大小。
- 铭文滥用了比特币链作为货币交易的功能,把比特币网络看成了去中心化的存储设施,存储了和交易不相干的信息。
- 铭文基于共识,这个共识并不在比特币代码中,后续可能被其它共识取代。
铭文的内容模型
铭文的内容模型就是web媒体类型,包含MIME type和内容本身,存储在taproot的花费脚本中。taproot技术是锁定utxo的几种方式之一,它允许根据私钥或者隐含的脚本来花费utxo。隐含的脚本对于其内部内容的限制很少,而且上链费用较低,铭文正是存储在该脚本中。
铭文过程包括两步,首先是使用taproot script-path创造一个utxo,这个script path包含了铭文内容脚本的哈希;然后是使用铭文script来花费这个utxo,实现铭文内容的上链。这两步的交易分别称为提交交易和显露交易。
比特币脚本有其特定的编程语言,铭文利用了其中的条件语句,通过OP_PUSH
把铭文放入了一个永远不会执行的代码块内,实现了内容的上链。这个代码块被称为信封。下面是放入了”Hello World!”这个字符串的信封:
OP_FALSE |
在这个信封里,首先推入的是协议名称:ord
。OP_PUSH
1 表明下次推入的是MINE type;OP_PUSH
0 则表示下次推入的是内容本身。
如果铭文内容很长,可以使用多个OP_PUSH
,因为一个OP_PUSH
推入的数据不能超过520 bytes。
这个铭文内容包含在显露交易中,并锚定在该交易输入的第一个聪中。之后,这个被铭刻的聪可以根据序数理论进行转移、交易等等。
字段
信封内可以包含多个字段,每个字段包含两次数据推入,分别是标签和值。目前定义了6种字段:
content-type
MIME类型,标签为0。pointer
标签为2,指定铭文在输入utxo的哪个聪上,默认为第一个聪。parent
标签为3,指定铭文的父铭文id。metadata
标签为5,指定元信息,使用CBOR编码元信息。metaprotocol
标签为7,元协议。content_encoding
标签为9,铭文内容字符编码。delegate
标签为11,代理另一个铭文的内容,指定代理铭文的id。
铭文内容和字段之间是一个空的Data Push。
不识别标签根据是奇数还是偶数有着不同的处理策略。偶数标签会影响铭文的创建和转移,因此,不识别的偶数标签必须被展示为unbunded,即不存在于任何聪之上。奇数标签不会影响铭文的创建和转移,比如元信息,因此可以忽略。
铭文ID
铭文包含在显露交易的输入之中。为了唯一确定铭文,使用下面的形式给铭文赋予ID:
521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0
在字符i
之前是交易ID,i
之后是这个交易内的铭文的编号,一个交易可能会生成多个铭文,分布在不同的input之上,下面是有5个inputs的交易的铭文分布的例子,总共生成了7个铭文:
Input | Inscription Count | Indices |
---|---|---|
0 | 2 | i0,i1 |
1 | 1 | i2 |
2 | 3 | i3,i4,i5 |
3 | 0 | |
4 | 1 | i6 |
铭文序号
铭文可以根据显露交易出现的顺序从0开始进行编号。这里的一个例外是,如果铭文创建后,在同一个区块内被当成交易费使用,其编号会排在区块内铭文的最后。
被诅咒的铭文的编号是从-1开始,不断递减。从区块824544开始,被诅咒的铭文被认为是正常的铭文而以正数进行编号。
源码阅读
- 铭文定义
pub struct Inscription { |
- 铭文写入taproot script-path脚本
pub fn append_reveal_script_to_builder(&self, mut builder: script::Builder) -> script::Builder { |
- 铭文ID
pub struct InscriptionId { |
- 信封
// 二进制信封 |
- 标签的实现
pub(crate) enum Tag { |
为比特币网络建立铭文索引
铭文附着在聪上,上文已经介绍了聪和UTXO的关联,这里基本上就是建立铭文和聪的关联。
// 待分配的浮动铭文 |