|
3 | 3 | // The update scheme is built on swarm chunks with chunk keys following |
4 | 4 | // a predictable, versionable pattern. |
5 | 5 | // |
6 | | -// Updates are defined to be periodic in nature, where periods are |
7 | | -// expressed in terms of number of blocks. |
8 | | -// |
9 | | -// The root entry of a mutable resource is tied to a unique identifier, |
10 | | -// typically - but not necessarily - an ens name. The identifier must be |
11 | | -// an valid IDNA string. It also contains the block number |
12 | | -// when the resource update was first registered, and |
13 | | -// the block frequency with which the resource will be updated, both of |
| 6 | +// Updates are defined to be periodic in nature, where the update frequency |
| 7 | +// is expressed in seconds. |
| 8 | +// |
| 9 | +// The root entry of a mutable resource is tied to a unique identifier that |
| 10 | +// is deterministically generated out of the metadata content that describes |
| 11 | +// the resource. This metadata includes a user-defined resource name, a resource |
| 12 | +// start time that indicates when the resource becomes valid, |
| 13 | +// the frequency in seconds with which the resource is expected to be updated, both of |
14 | 14 | // which are stored as little-endian uint64 values in the database (for a |
15 | | -// total of 16 bytes). It also contains the unique identifier. |
| 15 | +// total of 16 bytes). It also contains the owner's address (ownerAddr) |
16 | 16 | // This MRU info is stored in a separate content-addressed chunk |
17 | 17 | // (call it the metadata chunk), with the following layout: |
18 | 18 | // |
19 | | -// (startblock|frequency|address|identifier) |
| 19 | +// (00|length|startTime|frequency|name|ownerAddr) |
20 | 20 | // |
21 | 21 | // (The two first zero-value bytes are used for disambiguation by the chunk validator, |
22 | 22 | // and update chunk will always have a value > 0 there.) |
23 | 23 | // |
| 24 | +// Each metadata chunk is identified by its rootAddr, calculated as follows: |
| 25 | +// metaHash=H(len(metadata), startTime, frequency,name) |
| 26 | +// rootAddr = H(metaHash, ownerAddr). |
| 27 | +// where H is the SHA3 hash function |
| 28 | +// This scheme effectively locks the root chunk so that only the owner of the private key |
| 29 | +// that ownerAddr was derived from can sign updates. |
| 30 | +// |
24 | 31 | // The root entry tells the requester from when the mutable resource was |
25 | | -// first added (block number) and in which block number to look for the |
| 32 | +// first added (Unix time in seconds) and in which moments to look for the |
26 | 33 | // actual updates. Thus, a resource update for identifier "føø.bar" |
27 | | -// starting at block 4200 with frequency 42 will have updates on block 4242, |
28 | | -// 4284, 4326 and so on. |
| 34 | +// starting at unix time 1528800000 with frequency 300 (every 5 mins) will have updates on 1528800300, |
| 35 | +// 1528800600, 1528800900 and so on. |
29 | 36 | // |
30 | 37 | // Actual data updates are also made in the form of swarm chunks. The keys |
31 | 38 | // of the updates are the hash of a concatenation of properties as follows: |
32 | 39 | // |
33 | | -// sha256(period|version|address|namehash) |
34 | | -// |
35 | | -// The period is (currentblock - startblock) / frequency |
| 40 | +// updateAddr = H(period, version, rootAddr) |
| 41 | +// where H is the SHA3 hash function |
| 42 | +// The period is (currentTime - startTime) / frequency |
36 | 43 | // |
37 | | -// Using our previous example, this means that a period 3 will have 4326 as |
38 | | -// the block number. |
| 44 | +// Using our previous example, this means that a period 3 will happen when the |
| 45 | +// clock hits 1528800900 |
39 | 46 | // |
40 | | -// If more than one update is made to the same block number, incremental |
| 47 | +// If more than one update is made in the same period, incremental |
41 | 48 | // version numbers are used successively. |
42 | 49 | // |
43 | | -// A lookup agent need only know the identifier name in order to get the versions |
| 50 | +// A lookup agent need only know the rootAddr in order to get the versions |
44 | 51 | // |
45 | | -// the resourcedata is: |
46 | | -// headerlength|period|version|identifier|data |
| 52 | +// the resource update data is: |
| 53 | +// resourcedata = headerlength|period|version|metaHash|rootAddr|data |
47 | 54 | // |
48 | 55 | // the full update data that goes in the chunk payload is: |
49 | 56 | // resourcedata|sign(resourcedata) |
50 | 57 | // |
51 | | -// headerlength is a 16 bit value containing the byte length of period|version|name |
| 58 | +// headerlength is a 16 bit value containing the byte length of period|version|rootAddr|metaHash |
52 | 59 | package mru |
0 commit comments