翻译了Runes文档,并在链上找了一些实际交易示例
官方文档:
https://docs.ordinals.com/runes.html
即协议消息,保存在比特币交易的output里。
一个transaction最多只能有一个符石。
符石总是以 OP_RETURN开头,然后跟着OP_13,然后是一堆data push,它们被认为是一串128bit的integer连接的数据,被解码为符石。
一个符石可能是铭刻(部署)一个新的符文,也可能是mint一个符文,也可能是转账符文。
tx的output里可以包含任意数量的符文
符文被ID标识,ID是由铭刻(部署)这个符文的块高和其交易index组成的,记为:BLOCK:TX。例如一个由第500个块的第20个交易铭刻的符文,标记为500:20
Runes是通过Ethe来创造(部署)的,创造时提供的参数:
当mint开放后,任何人都能参与,需遵守Terms
Edicts(法令):一个符石可能包含任意数量的Edicts,一个Edicts包含Rune ID,数量,output number。Edicts按顺序处理,把符文分配给outputs
Pointer:Edicts被处理完后,没分配的符文被默认分配到第一个非OP-RETURN的output。符石里也可能会设置一个默认输出
Burning:转给OP_RETURN的output,就是烧掉了
符石可能会因各种原因而出错,比如无法识别的错误格式等。这种错误的符石被称为纪念碑
纪念碑可以被用作一种协议升级机制,因此新的协议上可以看到符文的用途,而运行旧协议的,会认为被烧掉了。
符文的实现参考代码:ord,就是符文的规范,它没有文本规范
Edict里的RuneId里的区块高度和输出index都是按相对数字来编码的(应该是为了省空间)。 Edict rune ID的解码中,块高是从base高度(84000)开始的,交易的index是从0开始。
所以Edict必须以Rune ID排序(要不就没法节省空间了)。
例如一笔交易里有如下Edict:
先按block和tx的index排序:
然后按相对位置方式编码:
解析符石时,需要使用下面这些tag:
这些tag是按奇偶分组的,无法识别的奇数tag会被忽略,甚至无法识别的tag会产生纪念碑。 所有未使用的tag做保留,且不得使用。
Rune:要铭刻的符文的名字。如果有设置Etching flag,但没设置Rune,则使用默认名字。
Premine:要预挖的数量
Cap:允许mint的次数的上限
Amount:每次mint能收到的数量
HeightStart和HeightEnd:允许mint的BTC区块块高上下限
OffsetStart和OffsetEnd:允许mint的BTC区块,计数方式为从铭刻的那个块高开始。
Mint:包含本次mint的符文的ID
Pointer:未被edicts指定的符文要被transfer到哪个output。如果这个位没有,则未被指定的符文会被transfer到第一个非OP_RETURN的输出
Cenotaph:不识别
Divisibility:十进制的小数点,例如1234,如果Divisibility是2,那就是12.34
Spacers:名字的分隔符。表示从最低有效位开始,是否在符文名字从左往右第N和N+1之间现实分隔符.例如AAAA: (没太看懂,怎么区分11是3,还是1,1?)\
名字的编码方式:
然后持续...
AAAAAAAAAAAAAAAAAAAAAAAAAAA及更高的名字被保留用作自动名字:
如果没指定名字,则会产生一个自动的: fn reserve(block: u64, tx: u32) -> Rune {
Rune(
6402364363415443603228541259936211926
+ (u128::from(block) << 32 | u128::from(tx))
)
}
上面6402364363415443603228541259936211926就是AAAAAAAAAAAAAAAAAAAAAAAAAAA
符文协议从840000块开始激活,最初13位到上面保留名字之间的被解锁(也就是可以etch)。此后,每17,500个区块周期,不断解锁下一个最短长度的符文名称。因此,在区块 840,000 和区块 857,500 之间,十二字符符文名称被解锁,在区块 857,500 和区块 875,000 之间,十一个字符符文名称被解锁,以此类推,直到区块之间一字符符文名称被解锁。
为了防止抢跑交易,即把别人要etch的,已经发出来但还没被打包的交易给抢跑了,需要在etch时必须包含一个承诺(在输入的utxo里)。这个承诺是个TapScript (花费掉一个utxo),它的解锁脚本包含符文名称的data push,小端编码,省略后面的0;它要花费的utxo已经至少有6个确认。
可以在符石里mint位包含Rune ID来mint一个符文。
如果Mint开放,则Mint Amount将添加到交易input中的未分配符文中。这些符文可以使用edict进行转移,否则将被转移到第一个非 OP_RETURN output,或由Point指定的输出。
Mint可以在雕刻后的任何交易中进行,包括同一个区块内。需符合Term规定
Transfer通过edict进行:
一个符石可以包含任意数量edict,按顺序处理。
输入的符文是unlocated,每个edict把unlocated符文变成located。
如果一个edict要分配的符文,比剩下的未分配符文要多,那实际分配的就是当前未分配数量。
因为一个符文在上链之前,不知道block和tx的index,所以如果要在铭刻这个符文的交易里表示这个符文,就用0:0作为其ID
如果一个edict的amount是0,则它会把当前rune ID的所有剩下的符文都分配出去。
如果一个edict的output等于该tx的output数量,则它会把amount分配个每个非OP_RETURN的output (OP_RETURN也计入output数量吗?)
一个Amount为零且output等于交易output数量的edict会将ID的所有未分配单位分配给每个非 OP_RETURN 输出。如果未分配的符文数量不能被非 OP_RETURN 输出的数量整除,那么多余的 符文将被分配给第 R 个非 OP_RETURN 输出,其中 R 是未分配的符文ID单位的余数除以非 OP_RETURN 输出的数量后的余数。
如果edict里,id的block是0而index是非0,或output大于tx的output数量,则这是个纪念碑。
runealpha.xyz
etching:
https://runealpha.xyz/txs/de52156262b35b9c741ecb4ba4ef5e31d55b97c5c9190d576a13bd29799d4a3b
mint:
https://runealpha.xyz/txs/3578c086c9b4acc900cd69f28d3af4da7a81e3a2e074244190da3e3d7d1d235c
Transfer:
https://runealpha.xyz/txs/6acff1810abfa3a78687df5b188ea0836a8173c81c368a231ecc2c2f75cf11a2
直接把拥有符文的utxo转账,输出在第一个非OP_RETURN的output
https://runealpha.xyz/txs/63b416898452e859fb1d5f06162ba93936b962d990183f845f7b62f14b298c73
把一个符文拆分,通过OP_RETURN规定拆出的量和output index,剩下的在第一个非OP_RETURN的output里。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!