ODIN(Open Data Index Name) - 开放数据索引命名标识技术规范

1、ODIN简介

ODIN(Open Data Index Name) 是开放数据索引命名标识的缩写。广义上,ODIN 是指在网络环境 下标识和交换数据内容索引的一种开放性系统,它遵从URI(统一资源标识符) 规范,并为基于数字加密货币区块链(BlockChain)的自主开放、安全可信的数据内容管理和知识产权管理提供了一个可扩展的框架。它包括4 个组成要素:标识符、解析系统、元数据和规则(Policies) 。狭义上,ODIN 是指标识任何数据内容对象的一种永久性标识符。

ODIN可以被形象地理解为“数据时代的自主域名”。

2、ODIN 的技术方案

参考了XCP(合约币)和Mastercoin(万事达币)等数字加密货币的技术原理,ODIN的实现是通过将特定消息数据按比特币协议规范进行特定编码后,作为比特币交易广播到比特币网络上存入区块链。

每个ODIN信息包括以下特性:

(a)一个比特币源地址(对应ODIN消息生成者)

(b)一个比特币目的地址(对应受ODIN消息指向的目标个体,当具体消息定义不需要指定目标个体时,该地址可以为空)

(c)若干个1-of-N多重签名输出比特币地址公钥,按照ODIN数据包格式定义编码生成,具体定义如下:

第一条1-of-N多重签名输出中, 第一个公钥固定是发送者的,第二个公钥固定是ODIN特征公钥(33个字节公钥,16进制HEX字符串"0320a0de360cc2ae8672db7d557086a4e7c8eca062c0a5a4ba9922dee0aacf3e12",对应地址为1PPkPubRnK2ry9PPVW7HJiukqbSnWzXkbi),可选的第三个公钥开始为具体ODIN消息内容编码而成(格式为:第一个字节为取值3,第二个字节为后续有效数据长度,第3个字节 开始从ODIN消息内容中按顺序每提取31个字节,总共33个字节对应一个比特币压缩公钥(如果不足33个字节的自动在尾部追加ASCII空格字符填满直到达到33字节);

可选第二条和更多1-of-N多重签名输出中,第一个公钥固定是发送者的,第二个公钥开始为具体ODIN消息内容编码而成。

注:N取值范围为3-16,按目前的比特币协议标准建议取值为3。对于1条1-of-N多重签名输出仍无法容纳的ODIN数据块,可依样扩展存入第2条,第3条等更多条多重签名输出记录中即可,如果不超出75个字节,可以选择存入后文的OP_RETURN备注消息。

(d)一条OP_RETURN备注消息(在标准的多重交易数据块无法容纳过长的ODIN数据包时,提供额外的不超过75个字节存储空间)

(e)比特币源地址中有一定数量的比特币余额(建议有0.001BTC以上,用于生成从源地址发送到目的地址的若干有效交易条目以嵌入ODIN数据包。注: 因为比特币1-of-N多重签名交易的特点,这些比特币金额不会发生实际支出,将在下一个ODIN消息中被回收循环利用)

(f)以比特币计的消息成本固定费用(缺省是0.0001 BTC),将支付给收录这个交易数据块的比特币网络矿工。

(g)一个比特币找零地址(与上述第一项的比特币源地址相同,用于按照比特币交易协议将输入交易的比特币金额在生成若干条满足嵌入ODIN数据包的交易条目后多出的金额回收到消息发送者账户)

上述的特性c是技术实现的关键,ODIN数据块会嵌入到比特币交易的多重签名输出数据块中,是1-of-N输出,每个数据块的第一个公钥固定是发送者的,因而输出的币值可以赎回循环使用。关于比特币多重签名交易的详细说明请参考比特币协议规范。

每个ODIN信息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节。

第2字节到消息结束为按消息类型区分的不同消息数据,详见下文的“3、ODIN 的消息类型”。      

3、ODIN 的消息类型

3.1 新注册ODIN

比特币源地址:对应ODIN标识注册者

比特币目的地址:对应ODIN标识管理者(可选,为空表示管理者与注册者相同)

消息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节,取值为ASCII字符R

第2字节  : 消息正文数据格式,1个字节。

      取值定义:ASCII字符,

           T 表示“UTF-8编码文本字符串”,

           G 表示“经gzip算法压缩得到的二进制数据,需解压后可得到UTF-8编码的原始文本字符串”

第3字节开始: 消息正文数据字节长度,采用比特币协议的可变长度整型(Varint)定义。当取值小于253时,采用1个字节存放;当取值大于等于253时小于65536时,采用3个字节存放,其中第一个字节固定为253。后面两个字节存放实际数据值(低位在前,高位在后);当取值大于等于65536时小于4294967295时,采用5个字节存放,其中第一个字节固定为254。后面四个字节存放实际数据值(低位在前,高位在后)。

后续到消息正文指定长度结束是按字节存放的消息正文数据,需根据第2字节的数据格式取值来获得原始消息文本,为UTF-8编码的JSON格式字符串,对应一个JSON对象数据,说明如下:

  {

    "ver":"说明:数据格式定义版本,初始为1",

    "title":"说明:个体名称字符串",

    "email":"说明:个体的公开EMAIL,可选",

    "auth":"说明:配置权限,取值定义见下方注释",

  }

  

  注:配置权限的取值说明:ASCII字符0,1或2

    0表示“注册者或管理者任一都可以更新标识相关配置信息”,

    1表示“只有管理者能修改标识相关配置信息”,

    2表示“注册者和管理者必须共同确认才能更新标识相关配置信息”,

  

消息正文举例:

{"ver":1,"title":"PPk-Sample","email":"ppkpub@gmail.com","auth":"0"}

注:为了保证标识短编号的唯一有效性,只要符合ODIN特征公钥及消息内容第1字节为R,则都需要记录为一条新的ODIN标识,即使其后续消息正文不可用。对于登记内容有误的ODIN标识允许后续修改正确。

3.2 更新ODIN的基本信息

比特币源地址:对应有权限更新ODIN标识配置数据的注册者或者管理者

比特币目的地址:对应ODIN标识的新管理者(可选,为空表示不更改管理者身份)

消息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节,取值为ASCII字符U

第2-31字节 : 类似“351474.430”的标准ODIN标识,30个字节,如果标识本身不足30字节,则在右侧用ASCII空格字符补足

第32字节  : 消息正文数据格式,1个字节。

      取值定义:ASCII字符,

           T 表示“UTF-8编码文本字符串”,

           G 表示“经gzip算法压缩得到的二进制数据,需解压后可得到UTF-8编码的原始文本字符串”

第33字节开始: 消息正文数据字节长度,采用比特币协议的可变长度整型(Varint)定义。当取值小于253时,采用1个字节存放;当取值大于等于253时小于65536时,采用3个字节存放,其中第一个字节固定为253。后面两个字节存放实际数据值(低位在前,高位在后);当取值大于等于65536时小于4294967295时,采用5个字节存放,其中第一个字节固定为254。后面四个字节存放实际数据值(低位在前,高位在后)。

后续到消息正文指定长度结束是按字节存放的消息正文数据,需根据第32字节的数据格式取值来获得原始消息文本,为UTF-8编码的JSON格式字符串,对应一个JSON对象数据,说明如下:

消息正文定义: 

  JSON格式字符串,对应一个JSON对象数据,说明如下:

  {

    "ver":"说明:数据格式定义版本,初始为1",

    "cmd":"说明。更新命令类型,取值为BI表示更新基本信息",

    "title":"说明:个体名称字符串",

    "email":"说明:个体的公开EMAIL,可选",

    "auth":"说明:配置权限,取值定义见下方注释",

  }

  

  注:

  1.采用增量更新模式,只追加或更新请求中所列字段,未在更新请求中出现的字段将保持不变

  2.配置权限的取值说明:ASCII字符0,1或2

    0表示“注册者或管理者任一方都可以更新标识相关配置信息”,

    1表示“只有管理者能修改标识相关配置信息”,

    2表示“注册者和管理者必须共同确认才能更新标识相关配置信息”,

  

消息正文举例:

{"ver":1,"cmd":"BI","title":"PPk-Update-Sample"}

3.3 更新ODIN的访问点配置

比特币源地址:对应有权限更新ODIN标识配置数据的注册者或者管理者

比特币目的地址:空

消息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节,取值为ASCII字符U

第2-31字节 : 类似“351474.430”的标准ODIN标识,30个字节,如果标识本身不足30字节,则在右侧用ASCII空格字符补足

第32字节  : 消息正文数据格式,1个字节。

      取值定义:ASCII字符,

           T 表示“UTF-8编码文本字符串”,

           G 表示“经gzip算法压缩得到的二进制数据,需解压后可得到UTF-8编码的原始文本字符串”

第33字节开始: 消息正文数据字节长度,采用比特币协议的可变长度整型(Varint)定义。当取值小于253时,采用1个字节存放;当取值大于等于253时小于65536时,采用3个字节存放,其中第一个字节固定为253。后面两个字节存放实际数据值(低位在前,高位在后);当取值大于等于65536时小于4294967295时,采用5个字节存放,其中第一个字节固定为254。后面四个字节存放实际数据值(低位在前,高位在后)。

后续到消息正文指定长度结束是按字节存放的消息正文数据,需根据第32字节的数据格式取值来获得原始消息文本,为UTF-8编码的JSON格式字符串,对应一个JSON对象数据,说明如下:

消息正文定义: 

  JSON格式字符串,对应一个JSON对象数据,说明如下:

  {

    "ver":"说明:数据格式定义版本,初始为1",

    "cmd":"说明。更新命令类型,取值AP表示更新AP访问点配置表",

    "ap_set":{

     "AP记录项编号":{"url":"对应URL"},

     "AP记录项编号":{"url":"对应URL"},

     ...

     "AP记录项编号":{"url":"对应URL"},

    }

  }

  注:AP记录项从0开始以依次按1,2..,n顺序编号即可。当URL取值为""即长度为的字符串,表示该AP记录项置空失效,但该记录项不会删除,即不影响后续记录的编号。

  

消息正文举例:

{"ver":1,"cmd":"AP","ap_set":{"0":{"url":"http://ap1.ppkpub.org/"},"2":{"url":"http://ap2.ppkpub.org/"}}}

3.4 更新ODIN的数据签名验证参数

比特币源地址:对应有权限更新ODIN标识配置数据的注册者或者管理者

比特币目的地址:空

消息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节,取值为ASCII字符U

第2-31字节 : 类似“351474.430”的标准ODIN标识,30个字节,如果标识本身不足30字节,则在右侧用ASCII空格字符补足

第32字节  : 消息正文数据格式,1个字节。

      取值定义:ASCII字符,

           T 表示“UTF-8编码文本字符串”,

           G 表示“经gzip算法压缩得到的二进制数据,需解压后可得到UTF-8编码的原始文本字符串”

第33字节开始: 消息正文数据字节长度,采用比特币协议的可变长度整型(Varint)定义。当取值小于253时,采用1个字节存放;当取值大于等于253时小于65536时,采用3个字节存放,其中第一个字节固定为253。后面两个字节存放实际数据值(低位在前,高位在后);当取值大于等于65536时小于4294967295时,采用5个字节存放,其中第一个字节固定为254。后面四个字节存放实际数据值(低位在前,高位在后)。

后续到消息正文指定长度结束是按字节存放的消息正文数据,需根据第32字节的数据格式取值来获得原始消息文本,为UTF-8编码的JSON格式字符串,对应一个JSON对象数据,说明如下:

消息正文定义: 

  JSON格式字符串,对应一个JSON对象数据,说明如下:

  {

    "ver":"说明:数据格式定义版本,初始为1",

    "cmd":"说明。更新命令类型,取值VD表示更新AP访问点所提供数据的验证参数",

    "vd_set":{

      "algo":"说明:通过AP发布数据时所用非对称签名验证算法类型,缺省为MD5withRSA",      "cert_uri":"说明:验证所需要的公钥证书对应URI,需保证对应资源内容是持久不变的,缺省用去中心化的文件系统ipfs来承载内容较大的证书,也可以用"data:"形式URL来直接内嵌Base64编码的二进制公钥字符串",

    }

  }

  

消息正文举例:

 {"ver":1,"cmd":"VD","vd_set":{"algo":"MD5withRSA","cert_uri":"ipfs:QmaZGNj6G2sgRESZDEQgQybwZrigRW4UHsxquvt1C3qdyt"}}

 {"ver":1,"cmd":"VD","vd_set":{"algo":"MD5withRSA","cert_uri":"data:,E48A37882B123499011339DD338920..............2011BBS"}}

3.5 转移ODIN的注册者身份

比特币源地址:对应ODIN标识的原注册者

比特币目的地址:对应ODIN标识的新注册者

消息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节,取值为ASCII字符U

第2-31字节 : 类似“351474.430”的标准ODIN标识,30个字节,如果标识本身不足30字节,则在右侧用ASCII空格字符补足

第32字节  : 消息正文数据格式,1个字节。

      取值定义:ASCII字符,

           T 表示“UTF-8编码文本字符串”,

           G 表示“经gzip算法压缩得到的二进制数据,需解压后可得到UTF-8编码的原始文本字符串”

第33字节开始: 消息正文数据字节长度,采用比特币协议的可变长度整型(Varint)定义。当取值小于253时,采用1个字节存放;当取值大于等于253时小于65536时,采用3个字节存放,其中第一个字节固定为253。后面两个字节存放实际数据值(低位在前,高位在后);当取值大于等于65536时小于4294967295时,采用5个字节存放,其中第一个字节固定为254。后面四个字节存放实际数据值(低位在前,高位在后)。

后续到消息正文指定长度结束是按字节存放的消息正文数据,需根据第32字节的数据格式取值来获得原始消息文本,为UTF-8编码的JSON格式字符串,对应一个JSON对象数据,说明如下:

消息正文定义: 

  JSON格式字符串,对应一个JSON对象数据,说明如下:

  {

    "ver":"说明:数据格式定义版本,初始为1",

    "cmd":"说明。更新命令类型,取值为TR表示转移注册者",

  }

  

消息正文举例:

{"ver":1,"cmd":"TR"}

注:

1.转移注册者需要按标识更新权限设置进行确认后需再得到新注册者的签名交易确认才能生效。

2.一旦转移注册者事务得到新注册者的确认并被区块收录生效时,如果该ODIN标识仍存在其它未生效的转移注册者事务,则相应未生效的转移事务自动失效。

3.5 确认对ODIN标识的更新操作

比特币源地址:对应待确认ODIN标识更新操作的当前注册者、当前管理者或作为转移目标的新注册者

比特币目的地址:无

消息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节,取值为ASCII字符U

第2-31字节 : 类似“351474.430”的标准ODIN标识,30个字节,如果标识本身不足30字节,则在右侧用ASCII空格字符补足

第32字节  : 消息正文数据格式,1个字节。

      取值定义:ASCII字符,

           T 表示“UTF-8编码文本字符串”,

           G 表示“经gzip算法压缩得到的二进制数据,需解压后可得到UTF-8编码的原始文本字符串”

第33字节开始: 消息正文数据字节长度,采用比特币协议的可变长度整型(Varint)定义。当取值小于253时,采用1个字节存放;当取值大于等于253时小于65536时,采用3个字节存放,其中第一个字节固定为253。后面两个字节存放实际数据值(低位在前,高位在后);当取值大于等于65536时小于4294967295时,采用5个字节存放,其中第一个字节固定为254。后面四个字节存放实际数据值(低位在前,高位在后)。

后续到消息正文指定长度结束是按字节存放的消息正文数据,需根据第32字节的数据格式取值来获得原始消息文本,为UTF-8编码的JSON格式字符串,对应一个JSON对象数据,说明如下:

消息正文定义: 

  JSON格式字符串,对应一个JSON对象数据,说明如下:

  {

    "ver":"说明:数据格式定义版本,初始为1",

    "cmd":"说明。更新命令类型,取值为CU表示二次确认更新操作",

    "tx_list":[

     "待确认操作对应交易记录标识1",

     "待确认操作对应交易记录标识2",

    ]

  }

  

消息正文举例:

{"ver":1,"cmd":"CU","tx_list":["432821.323","432823.222"]}

3.6 扩展登记二级ODIN标识索引数据块

比特币源地址:一级ODIN标识配置数据的管理者

比特币目的地址:空

消息数据块的格式按字节顺序定义如下:

第1字节  : 消息类型,1个字节,取值为ASCII字符E

第2-31字节 : 类似“351474.430”的标准ODIN标识,30个字节,如果标识本身不足30字节,则在右侧用ASCII空格字符补足

第32字节  : 消息正文数据格式,1个字节。

      取值定义:ASCII字符,

           T 表示“UTF-8编码文本字符串”,

           G 表示“经gzip算法压缩得到的二进制数据,需解压后可得到UTF-8编码的原始文本字符串”

第33字节开始: 消息正文数据字节长度,采用比特币协议的可变长度整型(Varint)定义。当取值小于253时,采用1个字节存放;当取值大于等于253时小于65536时,采用3个字节存放,其中第一个字节固定为253。后面两个字节存放实际数据值(低位在前,高位在后);当取值大于等于65536时小于4294967295时,采用5个字节存放,其中第一个字节固定为254。后面四个字节存放实际数据值(低位在前,高位在后)。

后续到消息正文指定长度结束是按字节存放的消息正文数据,需根据第32字节的数据格式取值来获得原始消息文本,为UTF-8编码的JSON格式字符串,对应一个JSON对象数据,说明如下:

消息正文定义: 

  JSON格式字符串,对应一个JSON对象数组数据,说明如下:

  [

    "ver":"说明:数据格式定义版本,初始为1",

    "cmd":"说明。更新命令类型,取值为EX表示扩展标识",

    "ex_list":[

     {

      "index":"说明,新增的二级区块数字编号",

      "hash":"说明:新区块的HASH唯一值",

      "ex_data_uri":"说明:相关的二级扩展ODIN标识记录区块数据URI,比如用ipfs来承载",

     }

     ...

    ]

  ]

  

消息正文举例:

{"ver":1,"cmd":"EX","ex_list":[{"index":2,"hash":"cb2fcb3248e9388b8a8f8c9a822878d01f65713cb83d0fbedd7cacb51f6ab965","ex_data_uri":"ipfs:QmaZGNj6G2sgRESZDEQgQybwZrigRW4UHsxquvt1C3qdyt"},{"index":3,"hash":"cbnkle89e8a8f8c9a822878d01f65713cb83d0fbedd7cacb51f6ab965","ex_data_uri":"ipfs:j6G2sgRESZDEQgQybwZrigRW4UHsxquvt1C3qdytHkdfs"}]}

4、FAQ

4.1 ODIN消息数据的大小有什么限制?

按既有的比特币协议定义,单个区块不能超过1MB,单条交易数据块一般在1KB左右,过大的数据包会需要很长时间的等待延迟才能被成功写入区块链,超过限制的会被比特币网络拒绝收录。

一般情况下,单个ODIN消息原始正文或经压缩后的长度最大不能超过65535字节,建议控制在1KB以下,对于超过1KB的消息可以适当增加支付给比特币网络矿工的成本费用(可以参考按每多出1KB增加支付0.0001BTC),可以加快被收录入区块链的速度。