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