How Web3.0 can become a safe haven for the private data?
It’s almost impossible to talk about Web3.0 without digging into blockchain and the surrounding crypto tech. The reason for this is simple. In the pre-crypto era, the dream of a decentralized web, controlled by people rather than governments or corporations, was just that, a dream. While Bitcoin’s or Ethereum’s success as a new currency is questionable, what it really did was tip the fragile balance. For the first time we saw a live demonstration of a decentralized network. But what the dream needs now is infrastructure.
As blockchain technology evolves and more ventures seek solutions to their problems in crypto tech, two things happen:
- developers and companies find use cases at which blockchain on its own is best;
- new use cases emerge, where another infrastructural solution is needed.
At the stage of its maturity, crypto technologies will require a solid infrastructure to rely on in order to achieve wide adoption. A crucial part of this infrastructure will be solutions for data storage.
Each new web-service needs a place to host its site, app, server, and, most importantly, store its user’s data. As the number of these services grows, the amount of data they generate skyrockets. It becomes too expensive to store and support this amount of data in-house for almost any business no matter how big or small it is.
For some time, cloud solutions seemed like an answer to this: you can buy space and computational power from Amazon Web Services, Microsoft Azure, Oracle, or any other smaller player in the market. The problem is that clouds are convenient for a transitional state of the web, but don’t look like a permanent solution. Why?
- Clouds are vulnerable: Each day user data gets compromised and can be used in malicious ways. And not just small companies! Equifax, Yahoo, Uber — no one is safe in the cloud. This is because clouds are centralized: you have one place, where everything is kept. If it gets compromised, there’s no way to undo the harm.
- It is cheap, but to the point: At some level, the monthly paycheck for the cloud services becomes too big, as companies with a large quantity of data,require high volumes of computations.This is highly relevant for IoT services, where multiple sensors from various devices generate tremendous amounts of data per second, all of which needs to be processed immediately
- The architecture behind the clouds does not satisfy the demands of the modern web: We’re talking not only about the decentralized apps(services that don’t rely on the single server to function), but also the social demand.
As industries like healthcare become digitized, a question arises: who owns the patient’s data, who has the right to store, transfer or grant access to it? It appears that we need a whole new level of tech to make this kind of data safe and transferable in digital form, or else it would still be simpler to use fax to send your autopsy results.
At first look, blockchain does not look like a solution to these problems. Yes, you can store records in an immutable ledger like the one used in Bitcoin, but for several gigabytes of data, the price would be astronomical. It would take minutes, if not hours, to process a single request for data to be stored this way. Thus the decentralized data storage projects emerged as an answer.Decentralized data storage projects like IPFS (used to build Filecoin), Storj, or Fluence aim to change the market by offering an affordable and secure data storage to anyone. They plan to achieve this by connecting supply(storage providers with underutilized capabilities) with demand(app developers, ventures, and users.)
What’s so different about this approach?
While the clouds rely on the storage and computational capabilities they own, decentralized storage is a network of independent nodes connected with the protocol and incentivized with the token economy. To keep it simple: anyone with free disk space can start a node, join the network, and earn by providing storage services. This creates several crucial features:
- Eliminating single point of failure: When your data is split and replicated over several independent nodes, there’s no way to gather it all or somehow tamper with it. The attacker will need to control 50% of the network in order to do that.
- Cryptography protection: nobody except for the owner can access the data. Even if the hacker gets a piece of dataset, it would be impossible to tell what’s inside. The node itself has no idea what it stores.
- No authority, meaning no censorship: In order to block access to any data in the network, you’d have to shut down the whole network entirely. Since the nodes are distributed anonymous, and can anywhere in the world, censorship is almost impossible.
- No middleman, the user owns the data.
Why do we focus on these features exactly? To be clear, there were several projects in academia aimed to prove that the decentralized database is a viable concept and could be built. However, they were focused on the question “if the technology will work at all”, while for a wide adoption not just a protocol, but a commercial product is required. The listed above features shape a scientific concept into a competitive market product, able to substitute traditional storages like clouds, NoSQL DBs, and their lookalikes.
When will we see a mass market adoption?
There are several projects approaching the problem of decentralized data storage from various angles (Filecoin, Storj, Streamr, Fluence). All of them promise to deliver an MVP at some time this year.
For now, we can hope that there are several social and economic factors that will boost interest in decentralized solutions, making it easier for them to find their way to the market. Problems with security and data leaks, high cloud costs, a growing number of applications that need decentralized architecture behind them — these trends combined might bring a decentralized vision of Web 3.0 much closer than one might think.
Until then the only good piece of advice we can give is: don’t trust your data to anyone, always make backups, and use 2-factor authentication.