2.0, 3.0, 4.0… What’s next 5.0?! Probably… However these version numbers are very unofficial and not necessarily very meaningful. So what is this article about?!
This article is about the decentralized web, sometimes also referred to as Web 3.0. It aims to give the reader a basic understanding of what all the fuss is about regarding dApps.
The traditional web
Before getting into this decentralized web and how it works, let’s first look (back) at the traditional web that we have been using for quite some time.
Traditionally the web is based around centralized resources. When we want to look at a website, we use our browser to make a request to a web server using the HTTP protocol (in most cases and for convenience let’s ignore SPDY for now) and the browser sends us some data back. The browser processes the data and if everything is alright it renders the layout for us.
The data that is send back is most likely stored on that server or perhaps another server that is connected to the same network. Point being, that the data is mostly stored in a single location and accessing it requires us to request it from that same location.
Typically this kind of centralization gives us some advantages. For example there could be a “single source of truth” situation, providing a trust between the requester and the data, providing a guarantee that information from this source can be trusted.
Another advantage could be that the data is easy to maintain, because it is only stored in 1 location it is easy to modify it.
These advantages could however just as easily turn into disadvantages:
If the single source of truth is incorrect somehow, everyone will consider the incorrect data as truthful, because it came from a “trusted” source.
Easy to maintain, can also mean easy to hack, as only 1 source needs to be affected, for all requesters to start receiving incorrect data.
The decentralized web
With the decentralized web things work differently. Instead of data being stored in a central location, data is being stored on many (if not all) nodes of the network. This allows for systems that no longer need a middle man to provide data.
As an example imagine Twitter. Twitter provides us with a platform where we can share small bits of information with other users. In the traditional web we send a tweet to the twitter servers and it gets stored in the database owned, maintained and managed by Twitter.
Others then request a list of tweets from the same servers and our tweet is retrieved from that database and send back to the users.
Using a decentralized approach we would (sort of) store our tweet directly in a database (of which many copies exist) and this database would then be “synchronized” with all other nodes, using a peer-to-peer network.
Of course this causes some new challenges to present themselves. The biggest of them all being: keeping the data safe from unwanted alterations. Fortunately some very smart people came up with a way to do just that using cryptography; blockchain.
Blockchain
After the last few years it would be very surprising if there still are people that have not heard about this technology. It is of course widely known for its use in the cryptocurrency world. Without blockchain technology, there would be no Bitcoin, Ether, Ripple, Monero, etc....
Blockchain technology uses cryptography to guarantee the integrity of the data that is stored in it. It does that in such a way that the data can not ever be modified after storing it.
Going into how exactly the blockchain manages to keep the integrity of the data technically goes far beyond the scope of this blog.
To achieve the above and still be able to update data somehow the blockchain generally stores events instead of storing the desired data directly. Events could be things like:
- “Store” new data
- “Update” existing data
By storing these events instead of the actual data, the state of the data (and all previous states) can always be restored, thus all modifications are public to everyone on the network.
The changes are then compared across nodes of the network and if found okay, accepted into the blockchain.
Dapps
Okay that’s great, but what about Dapps?!
Technically dApps, Dapps or dAPPS (not sure about the capitalization), have been around almost as long as peer-to-peer networks have. To qualify for being a Dapp an application should not run on a single computer (like a server), but instead on a peer-to-peer network.
Examples of Dapps that were popular before blockchain technology:
- BitTorrent
- Tor (Dark web)
- Popcorn Time
- Etc…
These all function decentralized, some with help of servers to help nodes discover each other (although they can function without the servers).
Blockchain enabled Dapps
The new type of Dapps that are very popular right now use a blockchain p2p network.
So what do we know about blockchain networks?
- They somehow manage to store data in such a way that it cannot be altered
- They’re widespread use is cryptocurrency trading
To be able to trade cryptocurrency on the blockchain network (basically registering a change in ownership on the blockchain), there has to be some code that enables users to do that.
That code is called a “smart contract”. The smart contract for BitCoin enables users to transfer ownership of a virtual currency from one wallet address to another wallet address. This can be very secure, because the transactions are stored on the blockchain, making it next to impossible to commit fraud.
Of course it is possible to fork the BitCoin code, modify the smart contract to fulfill a different purpose and start running a new network to make a new Dapp, but there are better ways.
Some networks allow users to create and add their own smart contract to the blockchain and on top of that provide a universal way to communicate with the contract. One such network is Ethereum, currently the most popular blockchain network for Dapps.
Smart contracts are for a Dapp, what the backend is for a traditional web app.
Traditionally a request for a traditional web application looks something like this:
[FrontEnd] <----request/response----> [BackEnd] <----------> [Database]
With Dapps:
[FrontEnd] <----request/response----> [SmartContract]
We still have a frontend application, but no longer any backend code or database, instead we have a smart contract (that runs on a peer-to-peer network).
Implementing the situation above leaves us with a situation where we somehow need to provide the frontend code to the user and the user should be a node on the blockchain network. When developing a desktop application or mobile application, that might not be a big problem. We could just use the official library to start running our own node.
When we want our application to be web based it turns into a bigger problem. We cannot run a blockchain node in a browser efficiently. We would also need to download at least a big portion of all of the data on the blockchain (every time we connect or stay connected 24/7 to stay in sync).
To be able to provide the frontend to the user in a web based application we need a web server. To prevent the situation discussed above where users need to be their own node on the network, most Dapps include one or more servers that are nodes on the blockchain network and can be accessed using an API (in that way forming a backend server).
To be able to identify oneself on the blockchain network an account has to be created. This account can function as a wallet and hold currency. Typically a browser extension (like MetaMask) is then used to connect and communicate with the blockchain node.
The browser extension also injects some javascript code into every page that is loaded, so that potential Dapps can detect it and use it to make requests to the blockchain node.
Gas
What keeps the integrity of the data on the blockchain is that nodes have to reach consensus about what is written to the blockchain. In order to do that theoretically all nodes should execute the same instructions and compare the result.
If executing code/storing data on the blockchain network would be free, the network would congested in a matter of minutes as users could massively try to write as much data as they desire. To limit that kind of behavior and force users to only write the data they need to, there is gas.
Just like with driving a car, you have to fill it up before you can go anywhere. Buying gas costs money. While you are driving, the car burns gas. So if a user doesn’t want to waste money he or she will most likely not aimlessly drive around.
Typically executing code that writes data to the blockchain will have to be executed on many nodes and thus gas needs to be used. However instead of polluting the environment with burned gas, the gas is send to the miner of the block that the data is to be stored in.
This creates an incentive for people to keep the network running. As without miners there can be no blockchain network (mining is the source of new blocks on the blockchain, if no one is mining, no new blocks are added and the network + all smart contracts come to a halt).
Reading from the blockchain however is free. This can be done using only 1 node and no communication with the rest of the network is required.
Conclusion
Dapps are not a new thing, but have been around for a long time. The latest iteration of decentralized applications use blockchain networks and seem ideal when data integrity is of the highest priority.
A Dapp typically consists out of 2 parts:
- Frontend (UI)
- Smart Contract (Blockchain)
It is possible to have a fully serverless infrastructure. However to keep things accessible often at least a web server is required to serve the frontend and to provide a node on the blockchain network (at least for web based applications).
0 Comments:
Post a Comment