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