Multiple Store/Delete
In an earlier blog post (Vault Network Test) we demonstrated the simple function of storing a chunk of data on the network. However, some questions and doubts may remain regarding multiple users storing and deleting chunks on the network.
In this blog post, we are going to put these doubts to rest by way of a demonstration. But first, we need to introduce to you the concept of personas. A vault (a network chunk storage location) will perform many different roles on the network and we call these roles personas. There are 6 personas in total that have been defined so far (this may expand over time), but for the sake of brevity we will only look at 3 during this post. These personas are:
PmidNode: Responsible for holding the real chunk data on network, it is the furthest Persona from client’s view.
DataManager: Presides over where the data stored and how many owners the data has.
MaidManager: Responsible for holding client related information such as what data has the client has stored, available vault space…etc. This is the closest Persona to the client based on XOR distance.
So, now you know what personas are, let’s commence with the demo.
User 1 stores data
As shown in the following screen shot, user 1 stored one chunk of data to the network. The chunk was duplicated into multiple copies. These copies were then stored in multiple PmidNodes (shown as blue rounded rectangle).
User 1 stores the same data for a second time
In the next screen, user 1 stores the same data to network. This time, only MaidManager (shown as pink ellipse in the following figure) takes action by increasing the reference count of that chunk to 2. There are no other vaults involved and no more copies created.
User 2 stores the same data
Now a different user stores the same data to the network. This time the DataManager (shown in yellow below) automatically increases the subscribers of the data to 2, representing both data owners (User 1 and User 2). The number of copies stays the same.
User 3 tries to delete the data
Now, rather maliciously, user 3 tries to delete the chunks stored by users 1 and 2. The MaidManager of user 3 will block the request because they cannot, quite rightly, find the record in that users account information (this is shown as ‘blocked DeleteRequest from non-owner’ in the following example).
User 1 tries to delete the data first time
Now user 1 decides he no longer requires the file and wants to delete his/her data. The first attempt will trigger the MaidManager to reduce the reference count of the data chunk to 1. However, data is still on network. DataManagers and PmidNodes won’t do anything as the request will not yet be passed down from the MaidManagers.
User 1 tries to delete the data second time
User 1 tries to delete the data again. This time the reference count in MaidManagers reaches 0. This triggers the request to be passed down to the DataManagers persona and it reduces the number of subscribers (owners) to 1. This is where the request ends and therefore the data still exists on network, remember user 2 also owns a copy of this data.
User 1 tries to delete the data third time
It’s now user 1’s turn to be malicious and they try once more to delete the data. Now, the network treats him as a non-owner as the record of the ownership has been removed from his MaidManagers persona, just like in the example of user 3 above.
User 2 tries to delete the data
Now user 2 tries to delete the data and, if you have been following, he/she is now the only user left with a record of ownership to this particular piece of data. User 2’s MaidManagers reduce the reference count to 0, which triggers the request to be passed down to the DataManagers. The DataManagers subsequently reduce the subscribers to 0, which in turn causes a delete request to be sent to all PmidNodes. PmidNodes will then remove the holding chunk and the data is completely removed from network.
Summary
So to summarise the demonstration, we had the PmidNode persona holding the data, however, the network had no knowledge of who owned it. The DataManager knows where the data was stored and the number of owners. The MaidManager knows what data the user stored, but doesn’t know where it was stored or who else owns the data. As you can see, requests will only be passed down to next level of persona when certain pre determined rules are met (i.e. reference counts reaching 0 cause requests to be passed to Data Managers who reduce the subscriber count to 0 which causes a delete request to be sent to PmidNodes).
You can watch this happening in real-time by clicking on the video clip below.
