@ckbfs/api 1.2.4 → 1.2.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/RFC.v2.md DELETED
@@ -1,341 +0,0 @@
1
- # CKBFS Protocol
2
-
3
- `CKBFS` is a protocol defined in order to describe a witnesses based file storage system. With CKBFS, one can:
4
-
5
- - Store files on Nervos CKB Network
6
- - Publish large files that may exceed block size limitation(~500kb), across multiple blocks, while still keep the index and retrieve action simple and straight
7
-
8
- It contains:
9
-
10
- - A hasher binary that uses [Adler-32 checksum algorithm](https://en.wikipedia.org/wiki/Adler-32)
11
- - A type script contract that applies restrictions to avoid invalid file publication
12
-
13
- ## Core Concepts
14
-
15
- Core concepts of CKBFS is:
16
-
17
- - One single cell(called CKBFS cell) to index one file, even multi-part file that split across blocks.
18
- - **Permanent** storage. Deletion is **forbidden** through contract, which means the file metadata will never lost. Which also means you will need to lock some CKB capacity **FOREVER** in order to create it.
19
- - Simple cell structure, encoded with molecule.
20
- - Built-in checksum provided, both on-chain and off-chain side.
21
-
22
- # The Protocol - or, the standard
23
-
24
- ## Data Structure
25
-
26
- ### CKBFS Cell
27
-
28
- CKBFS Cell is a cell that stores:
29
-
30
- A CKBFS cell in should looks like following:
31
-
32
- ```yaml
33
- Data:
34
- content_type: Bytes # String Bytes
35
- filename: Bytes # String Bytes
36
- indexes: Vec<Uint32> # referenced witnesses index.
37
- checksum: Uint32 # Adler32 checksum
38
- backlinks: Vec<BackLink>
39
-
40
- Type:
41
- hash_type: "data1"
42
- code_hash: CKBFS_TYPE_DATA_HASH
43
- args: <TypeID, 32 bytes>,[<hasher_code_hash>, optional]
44
- Lock:
45
- <user_defined>
46
- ```
47
-
48
- The following rules should be met in a CKBFS cell:
49
-
50
- - Rule 1: data structure of a CKBFS cell is molecule encoded. See [Molecule](https://github.com/nervosnetwork/molecule) definitions below.
51
- - Rule 2: checksum must match with specified witnesses. Default checksum algorithm will be Alder32 if not specify `hasher_code_hash` in Type script args.
52
- - Rule 3: if backlinks(see definition below) of a CKBFS cell is not empty, it means file was stored across blocks.
53
- - Rule 4: if `hasher_code_hash` is specified, then it will use hasher binary from CellDeps that matches `code_hash`, with same input parameter.
54
- - Rule 5: Once created, a CKBFS cell can only be updated/transfered, which means it can not be destroyed.
55
- - UPDATES IN VERSION 2: `indexes` is a vector of witness indexes, stored CKBFS structured contents in splited witnesses.
56
-
57
- ---
58
-
59
- ### BackLink
60
-
61
- BackLink stands for the prefix part of a living CKBFS cell. The strategy of CKBFS is similar to a linked list:
62
-
63
- [backlink]←[backlink]←[…]←[CKBFS cell]
64
-
65
- ```yaml
66
- BackLink:
67
- tx_hash: Bytes,
68
- indexes: Vec<Uint32>,
69
- checksum: Uint32,
70
- ```
71
-
72
- ---
73
-
74
- ### Witnesses
75
-
76
- File contents are stored in witnesses. In a single transaction, witnesses can be splitted into multiple parts and concat together while verification.
77
-
78
- ```yaml
79
- Witnesses:
80
- <"CKBFS"><0x00><CONTENT_BYTES>
81
- ```
82
-
83
- The following rules should be met for witnesses used in CKBFS:
84
-
85
- - Rule 6: The first 5 bytes must be UTF8 coded string bytes of `CKBFS`, which should be: `0x434b424653`
86
- - Rule 7: The 6th byte of witnesses must be the version of CKBFS protocol, which should be: `0x00`.
87
- - Rule 8: File contents bytes are stored from 7th byte. Checksum hasher should also take bytes from `[7…]`.
88
- - UPDATES IN VERSION 2: Every parts of the splitted content stored in witnesses must follow Rule 6 to Rule 8.
89
-
90
- ---
91
-
92
- ## Operations
93
-
94
- This section describes operations and restrictions in CKBFS implementation
95
-
96
- ### Publish
97
-
98
- Publish operation creates one or more new CKBFS cell.
99
-
100
- ```yaml
101
- // Publish
102
- Witnesses:
103
- <...>
104
- <0x434b424653, 0x0, CKBFS_CONTENT_BYTES>
105
- <...>
106
- Inputs:
107
- <...>
108
- Outputs:
109
- <vec> CKBFS_CELL
110
- Data:
111
- content-type: string
112
- filename: string
113
- indexes: vec<uint32>
114
- checksum: uint32
115
- backlinks: empty_vec
116
- Type:
117
- code_hash: ckbfs type script
118
- args: 32 bytes type_id, (...)
119
- <...>
120
- ```
121
-
122
- Publish operation must satisfy following rule:
123
-
124
- - Rule 9: in a publish operation, checksum must be equal with `hash(Witnesses[index])`.
125
-
126
- ---
127
-
128
- ### Append
129
-
130
- Append operation updates exist live CKBFS cell, validates the latest checksum.
131
-
132
- ```yaml
133
- // Append
134
- Witnesses:
135
- <...>
136
- <CKBFS_CONTENT_BYTES>
137
- <...>
138
- Inputs:
139
- <...>
140
- CKBFS_CELL
141
- Data:
142
- content-type: string
143
- filename: string
144
- indexes: vec<uint32>
145
- checksum: uint32
146
- backlinks: empty_vec
147
- Type:
148
- code_hash: ckbfs type script
149
- args: 32 bytes type_id, (...)
150
- <...>
151
- Outputs:
152
- <...>
153
- CKBFS_CELL:
154
- Data:
155
- content-type: string
156
- filename: string
157
- indexes: vec<uint32>
158
- checksum: uint32 # updated checksum
159
- backlinks: vec<BackLink>
160
- Type:
161
- code_hash: ckbfs type script
162
- args: 32 bytes type_id, (...)
163
- ```
164
-
165
- - Rule 10: backlinks field of a CKBFS cell can only be appended. Once allocated, all records in the vector can not be modified.
166
- - Rule 11: new checksum of updated CKBFS cell should be equal to: `hasher.recover_from(old_checksum).update(new_content_bytes)`
167
- - Rule 12: `content-type`, `filename`, and Type args of a CKBFS cell CAN NOT be updated in ANY condition
168
- - Rule 13: in an append operation, Output CKBFS Cell’s `indexes` can not be `empty`
169
-
170
- ---
171
-
172
- ### Transfer
173
-
174
- Transfer operation transfers ownership of a CKBFS cell, and ensure it did not lost tracking of backlinks.
175
-
176
- ```yaml
177
- // Transfer
178
- Witnesses:
179
- <...>
180
- Inputs:
181
- <...>
182
- CKBFS_CELL
183
- Data:
184
- content-type: string
185
- filename: string
186
- index: uint32
187
- checksum: uint32
188
- backlinks: empty_vec
189
- Type:
190
- code_hash: ckbfs type script
191
- args: 32 bytes type_id, (...)
192
- Lock:
193
- <USER_DEFINED>
194
- <...>
195
- Outputs:
196
- <...>
197
- CKBFS_CELL:
198
- Data:
199
- content-type: string
200
- filename: string
201
- index: null
202
- checksum: uint32 # updated checksum
203
- backlinks: vec<BackLink>
204
- Type:
205
- code_hash: ckbfs type script
206
- args: 32 bytes type_id, (...)
207
- Lock:
208
- <USER_DEFINED>
209
- ```
210
-
211
- - Rule 14: in a transfer operation, Output CKBFS Cell’s `indexes` must be empty
212
- - Rule 15: if Input CKBFS Cell’s backlinks is empty, then output’s backlink should be append following Rule 10. Otherwise, the backlinks should not be updated
213
- - Rule 16: in a transfer operation, `checksum` CAN NOT be updated
214
-
215
- ---
216
-
217
- ## Other Notes
218
-
219
- ### Molecule Definitions:
220
-
221
- Here’s molecule definitions of CKBFS data structures
222
-
223
- ```jsx
224
- vector Bytes <byte>;
225
- option BytesOpt (Bytes);
226
- option Uint32Opt (Uint32);
227
- vector Indexes <index>;
228
-
229
- table BackLink {
230
- tx_hash: Bytes,
231
- index: Indexes,
232
- checksum: Uint32,
233
- }
234
-
235
- vector BackLinks <BackLink>;
236
-
237
- table CKBFSData {
238
- index: Indexes,
239
- checksum: Uint32,
240
- content_type: Bytes,
241
- filename: Bytes,
242
- backlinks: BackLinks,
243
- }
244
- ```
245
-
246
- ### Checksum Validator Procedure:
247
-
248
- Bellow is pseudocodes shows how one can validates the checksum:
249
-
250
- ```pascal
251
- function validate_checksum(witness, expected_checksum, backlinks);
252
- var
253
- hasher: thasher;
254
- computed_checksum: uint32;
255
- content_bytes: bytes;
256
- last_backlink: backlink;
257
- begin
258
- // If backlinks is not empty, recover hasher state from the last backlink's checksum
259
- if length(backlinks) > 0 then
260
- begin
261
- last_backlink := backlinks[length(backlinks) - 1];
262
- hasher.recover(last_backlink.checksum);
263
- end;
264
-
265
- // Extract the content bytes from the witness starting from the 7th byte
266
- content_bytes := copy(witness, 7, length(witness) - 6);
267
-
268
- // Update the hasher with the content bytes
269
- hasher.update(content_bytes);
270
-
271
- // Finalize and compute the checksum
272
- computed_checksum := hasher.finalize;
273
-
274
- // Compare the computed checksum with the expected checksum
275
- if computed_checksum = expected_checksum then
276
- validate_checksum := true
277
- else
278
- validate_checksum := false;
279
- end;
280
-
281
- ```
282
-
283
- ### Advanced Usage - Branch Forking File Appendix
284
-
285
- Assuming that we have created a CKBFS Cell:
286
-
287
- ```yaml
288
- CKBFS_CELL:
289
- Data:
290
- content-type: string
291
- filename: string
292
- indexes: [0x0]
293
- checksum: 0xFE02EA11
294
- backlinks: [BACKLINK_1, BACKLINK_2, ...]
295
- Type:
296
- code_hash: CKBFS_CODE_HASH
297
- args: TYPE_ID_A
298
- Lock:
299
- <USER_DEFINED>
300
- ```
301
-
302
- It is able to creating a forking of this CKBFS by a special publish, similar to append but put the referenced CKBFS Cell in CellDeps:
303
-
304
- ```yaml
305
- CellDeps:
306
- <...>
307
- CKBFS_CELL:
308
- Data:
309
- content-type: string
310
- filename: string
311
- indexes: [0x0]
312
- checksum: 0xFE02EA11
313
- backlinks: [BACKLINK_1, BACKLINK_2, ...]
314
- Type:
315
- code_hash: CKBFS_CODE_HASH
316
- args: TYPE_ID_A
317
- Lock:
318
- <USER_DEFINED>
319
- <...>
320
- Witnesses:
321
- <...>
322
- <CKBFS_CONTENT_BYTES>
323
- <...>
324
- Inputs:
325
- <...>
326
- Outputs:
327
- <...>
328
- CKBFS_CELL
329
- Data:
330
- content-type: string
331
- filename: string
332
- indexes: [uint32]
333
- checksum: UPDATED_CHECKSUM
334
- backlinks: [BACKLINK_1, BACKLINK_2, ...]
335
- Type:
336
- code_hash: ckbfs type script
337
- args: TYPE_ID_B
338
- <...>
339
- ```
340
-
341
- And we are able to create a variant versions from a same reference data, allowing us to achieve something like git branching, shared-header data, etc.
package/append.txt DELETED
@@ -1 +0,0 @@
1
- This is content to append to the previously published file.
package/example.txt DELETED
@@ -1 +0,0 @@
1
- Hello, CKBFS! This is a sample file published using 20240906.ce6724722cf6 protocol.
@@ -1 +0,0 @@
1
- 0x3f61e43834d55fd3f3c8cf9d8a9c643db7790050ffb00734a1fb66da8e98478f
@@ -1,24 +0,0 @@
1
- // Create CKBFS cell output data based on version
2
- let outputData: Uint8Array;
3
-
4
- if (version === ProtocolVersion.V1) {
5
- // V1 format: Single index field (a single number, not an array)
6
- // For V1, use the first index where content is placed
7
- outputData = CKBFSData.pack({
8
- index: contentStartIndex,
9
- checksum,
10
- contentType: textEncoder.encode(contentType),
11
- filename: textEncoder.encode(filename),
12
- backLinks: [],
13
- }, version);
14
- } else {
15
- // V2 format: Multiple indexes (array of numbers)
16
- // For V2, use all the indices where content is placed
17
- outputData = CKBFSData.pack({
18
- indexes: witnessIndices,
19
- checksum,
20
- contentType: textEncoder.encode(contentType),
21
- filename: textEncoder.encode(filename),
22
- backLinks: [],
23
- }, version);
24
- }
package/test-download.txt DELETED
@@ -1,2 +0,0 @@
1
- Hello, CKBFS! This is a sample file published using 20240906.ce6724722cf6 protocol.
2
- This is content to append to the previously published file.