PIN数据结构
MAN索引器會從taproot交易的reveal腳本中獲取MetaID協議數據,具體協議請參照MetaID Specification章節。
PIN數據結構
type PinInscription struct {
Id string `json:"id"`
Number int64 `json:"number"`
RootTxId string `json:"rootTxId"`
Address string `json:"address"`
Output string `json:"output"`
OutputValue int64 `json:"outputValue"`
Timestamp int64 `json:"timestamp"`
GenesisFee int64 `json:"genesisFee"`
GenesisHeight int64 `json:"genesisHeight"`
GenesisTransaction string `json:"genesisTransaction"`
TxInIndex uint32 `json:"txInIndex"`
TxInOffset uint64 `json:"txInOffset"`
Operation string `json:"operation"`
Path string `json:"path"`
ParentPath string `json:"parentPath"`
Encryption string `json:"encryption"`
Version string `json:"version"`
ContentType string `json:"contentType"`
ContentTypeDetect string `json:"contentTypeDetect"`
ContentBody []byte `json:"contentBody"`
ContentLength uint64 `json:"contentLength"`
ContentSummary string `json:"contentSummary"`
}PIN索引規則
通用
識別Flag:
metaid大小寫規則:大小寫不敏感,索引器可以全部轉為小寫保存。
Operation
init類型PIN所在的交易的txid為一個metaid的roottxid。init、create遵循先到先得原則。同一區塊內
init、create不區分先後順序,索引器應先處理init類型PIN,再處理其他類型PIN,先處理init是為了得到roottxid/metaid。
Path
對於相同的
path,所有init和create的PIN是看最舊的,只有modify/revoke才是看最新的。modify/revoke必須對已入塊的PIN操作,即modify/revoke只對已經入塊的PIN有效,即使同區塊也是無效的。非
init-PIN的path一定是在以下path內,一個metaid默認存在這五個一級path:/info/file/protocols/nft/ft
以
/file、/protocols、/nft、/ft開始的path應該是全路徑的,如/protocols/simplebuzz/file/my-pfp.jpg。
PIN状态码
0
正常的PIN
-1
revoke的PIN
1
modify的PIN
-101
目標PIN所在區塊高度 ≤ 當前PIN所在區塊高度
-102
目標PIN已經被轉移
-201
modify的PIN,格式正確,但@+PINID中的PINId不存在(已確認的PIN)
-202
modify的PIN,格式正確,但發起modify的地址不存在
-203
modify的PIN,格式正確,發起modify的地址存在,但目標PIN的地址不等於當前PIN的address
-204
目標PIN已經有modify(狀態碼為1)
-205
目標PIN的Operation是init
-301
revoke的PIN,格式正確,但@+PINID中的PINId不存在
-302
revoke的PIN,格式正確,但發起revoke的地址不存在
-303
revoke的PIN,格式正確,發起revoke的地址存在,但目標PIN的地址不等於當前PIN的地址
-304
目標PIN已經被revoke過(狀態碼為-1)
-305
revoke的PIN,格式正確,但目標PIN的Operation是init或目標PIN的Path是/info/
更多信息,請參考 MAN 源代碼。
Last updated