Scratchpad data structure (old versions access)

Development
1

I am working on a project which could make use of the properties of the scratchpads data structure.

A “deal breaker” in my design is the “mutability without history” of the data stored in the scratchpad. I did not find a clear explanation in the developer docs about that aspect. It mentiones a version counter (and I understand it can be set to MAX to effectively make a scratchpad unmutable and final) but it does not mention anywhere if this is really just a counter for reference and signing/verification or if older versions of the data are also permanently stored in the network.

So my question is: After an update of the data in a scratchpad, is old data by no means accessible through the network and effectivly gone (not just because there is currently no API call for it)?

And more general: Could a global passive observer reconstruct history (old versions of the scratchpad data) if they later (after change or deletion of scratchpad data by the “owner”) get hold of the scratchpad address and even private encryption key for the data?

Furthermore, the “pay once, change forever” concept of scratchpads has been discussed critically in the forum already. I have searched for a final confirmation of the team that this concept is here to stay (sorry if this has been mentioned on Discord or buried deep in some dev-update - I really tried to find an answer).

3 Likes
2

Once you overwrite a scratchpad, the old data is gone forever. A passive observer could only reconstruct the history if they were storing every version themselves.

The counter is there mostly for reference. It is used to sign the scratchpad as well when you do an update. It doesn’t have to be an incrementer, just an increasing value.

If you want to store history, you should look into writing directly to chunks, using the graph entry type to stitch them together, and a pointer that updates to the latest graph entry. That’s assuming your data will fit into a chunk, if not, it gets a little more complicated, but you use the same datatypes to build up a container that can hold N number of chunks.

It is my understanding that the ‘pay once change forever’ concept of scratchpads will not change, it has never been mentioned otherwise. That said, once the network gains traction, if an application begins exploiting this feature to the point it affects the network itself, I can imagine them adding a nominal fee as spam prevention.

3 Likes
3

Excellent, thank you for the clarification. Actually preserving a history is prohibitive (even a deal breaker) for my application, so the current implementation of distributed storage for mutable data in the form of scratchpad is exactly what I need. :+1:

And it seems it’s pretty unique in the space as I have not found another distributed storage with mutable data w/o history as most are blockchain based and therefore store old versions.

4 Likes
4

For future reference if you do ever need a history you have two options:

  • Autonomi Register data type which holds an append-only list of pointers
  • dweb History which is similar to an Autonomi Register, but is implemented as a templated type to simplify storage and retrieval of any serialised data (struct). It also has a type value (like a GUID), so when using a History you can discover what type of data the History references.
3 Likes