/
PPK_ODIN_SPEC.txt
243 lines (196 loc) · 15.3 KB
/
PPK_ODIN_SPEC.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
开放数据索引命名(ODIN)根标识符技术规范
-- PPk开放技术社区 ( PPk Public Group ) 2018-12-18
http://ppkpub.org/
1、ODIN简介
ODIN是Open Data Index Name即“开放数据索引命名”的缩写。广义上,ODIN 是指在对等网络环境下标识和交换数据内容索引的一种开放性系统,它遵从URI(统一资源标识符)
规范,并为基于数字加密货币区块链（Blockchain）的自主开放、安全可信的数据内容管理和价值权益管理提供了一个可扩展的框架。它包括4 个组成要素:标识符、解析系统、
元数据和规则(Policies) 。狭义上,ODIN 是指对等、可信地标识任何数据内容对象的一种永久性标识符。
2、ODIN根标识的技术方案
参考了XCP和OMNI等数字加密资产协议的技术原理，ODIN根标识的实现是通过将特定消息数据按比特币协议规范进行特定编码后，作为比特币交易广播到比特币网络上存入区块链。
每个ODIN根标识信息包括以下特性：
(a)一个比特币源地址（必须是1打头的普通地址，对应ODIN消息生成者）
(b)一个比特币目的地址（必须是1打头的普通地址，对应受ODIN消息指向的目标个体，当具体消息定义不需要指定目标个体时，该地址可以为空）
(c)若干个1-of-N多重签名输出比特币地址公钥，按照ODIN数据包格式定义编码生成，具体定义如下：
第一条1-of-N多重签名输出中, 第一个公钥固定是发送者的,第二个公钥固定是ODIN特征公钥（33个字节公钥，16进制HEX字符串"0320a0de360cc2ae8672db7d557086a4e7c8eca062c0a5a4ba9922dee0aacf3e12"，对应地址为1PPkPubRnK2ry9PPVW7HJiukqbSnWzXkbi），可选的第三个公钥开始为具体ODIN消息内容编码而成（格式为：第一个字节为取值3，第二个字节为后续有效数据长度L，第3个字节开始从ODIN消息内容中按顺序每提取L个字节，总共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.00001 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编码文本字符串”,
D 表示“经deflate算法压缩得到的二进制数据，需解压后可得到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表示“注册者或管理者任一都可以更新标识相关配置信息，当auth字段不存在或取值非法时，默认按该项处理”,
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编码文本字符串”,
D 表示“经deflate算法压缩得到的二进制数据，需解压后可得到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表示“注册者或管理者任一方都可以更新标识相关配置信息，当auth字段不存在或取值非法时，默认按该项处理”,
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编码文本字符串”,
D 表示“经deflate算法压缩得到的二进制数据，需解压后可得到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/"},"1":{"url":""},"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编码文本字符串”,
D 表示“经deflate算法压缩得到的二进制数据，需解压后可得到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发布数据时所用非对称签名验证算法类型，缺省为SHA256withRSA，可选SHA1withRSA等",
"cert_uri":"说明：验证所需要的公钥证书对应URI，需保证对应资源内容是持久不变的，缺省用去中心化的文件系统ipfs来承载内容较大的证书，也可以用'data:'形式URL来直接内嵌Base64编码的二进制公钥字符串",
}
}
消息正文举例：
{"ver":1,"cmd":"VD","vd_set":{"algo":"SHA256withRSA","cert_uri":"ipfs:QmaZGNj6G2sgRESZDEQgQybwZrigRW4UHsxquvt1C3qdyt"}}
或
{"ver":1,"cmd":"VD","vd_set":{"algo":"SHA256withRSA","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编码文本字符串”,
D 表示“经deflate算法压缩得到的二进制数据，需解压后可得到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编码文本字符串”,
D 表示“经deflate算法压缩得到的二进制数据，需解压后可得到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",
"...",
"待确认操作对应交易记录标识N"
]
}
消息正文举例：
{"ver":1,"cmd":"CU","tx_list":["432821.323","432823.222"]}
4、FAQ
4.1 ODIN根标识的消息数据大小有什么限制？
按既有的比特币协议定义，单个区块不能超过1MB，单条交易数据块一般在1KB左右，过大的数据包会需要很长时间的等待延迟才能被成功写入区块链，超过限制的会被比特币网络拒绝收录。
一般情况下，单个ODIN消息原始正文或经压缩后的长度最大不能超过65535字节，建议控制在1KB以下，对于超过1KB的消息可以适当增加支付给比特币网络矿工的成本费用，可以加快被收录入区块链的速度。
-------------------------------------------------------------------------------------------------
Released under the MIT License.
Copyright (C) 2015-2018 PPk Public Group (ppkpub.org).
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.