When migrating data security from a centralized context into a decentralized one, a major challenge is figuring out where to put data that was traditionally stored in the centralized service. For some data, this is relatively straight-forward. For other data, this can be a challenge.
In Secrata, the server stores a large portion of its data in traditional databases (both relational and non-relational). This data translates fairly easily onto the blockchain. After all, many descriptions of blockchains describe them as decentralized databases. For this data, then, we simply convert what were previously database row inserts into blockchain transactions. dApp clients can then read the data out of the blockchain and place it into their data model. For all the basic entity types in Secrata and SDFS, such as containers, members, files, and messages, this approach works great.
However, Secrata and SDFS have a second kind of data that does not lend itself to being stored in the blockchain: file and digital asset data. Because files and digital assets can be quite large (several hundred MBs or more), storing them in the blockchain is impractical. This means that a separate solution is required to store and retrieve this data.
Other blockchain-based file storage solutions adopt the concept of storing your files “in the cloud” by distributing copies of your file to a number of nodes in their respective networks. When a user needs access to their files, the software then fetches the data back from one or more of the nodes holding the copies. For large networks with highly available nodes, this approach provides reliable access to data. However, there is a serious trade off in security; any node that has a copy of your data is able to read it.
Since SDFS is designed to keep your information secure, it approaches the problem from a different angle. While SDFS encrypts all data end-to-end, many users still have discomfort with their data being placed on unknown systems across the globe. Instead of having the data replicated to a bunch of unknown nodes, SDFS has the container members replicate and store the data blocks of the files in the container. This provides multiple copies of the data for data redundancy, and limits potential exposure of data to only those users who have already been granted access to the data.
Conversion of centralized technologies and concepts to decentralized paradigms requires approaching the problem from new angles. But you must always pay attention to the core features of the product to insure that you don’t compromise them. In the case of SDFS, the core of the product is data security, and all choices strive to maintain that security.
In upcoming posts, we will dive into the data security of the Secrata Enterprise Platform and how that data security is being maintained in SDFS.