No, running a decentralized application (dapp) on the blockchain will not lead to a successful business. In fact, most users don’t even think about whether the application runs on the blockchain – they just choose a product that is cheaper, faster and easier.
Unfortunately, even if the blockchain has its own unique features and benefits, most of the applications that run on it are much more expensive, slower, and less understood than their centralized competitors.
Quite often in the white papers of applications that are built on the blockchain, you can find a paragraph that says: "the blockchain is expensive and is not able to support the required number of transactions per second. Fortunately, many smart people are working on scaling the blockchain and by the time our application is launched it will be quite scalable."
In one simple paragraph, a dapp developer can skip a deeper discussion of scalability issues and alternative solutions to problems. This often leads to an inefficient architecture, where smart contracts running on the blockchain serve as the backend and core of the application.
However, there are still untested approaches in the architecture of decentralized applications that allow much better scaling due to reduced dependence on the blockchain. For example, Blockstack is working on an architecture where most of the application data and logic is stored outside of the blockchain.
Let's first look at a more traditional approach that uses the blockchain as a direct intermediary between application users and doesn't scale very well.
Approach #1: Blockchain as a backend
To make it clearer, let's take the hotel industry as an example. It's a huge industry where intermediaries like Booking.com, for connecting guests and hotels.
In any situation where we want to defeat such an intermediary using this approach, we will try to replicate its business logic using smart contracts on a blockchain such as Ethereum.
Open-source smart contracts running on the "worldwide computer" can connect merchants to consumers without a third-party company in between, ultimately reducing the fees and commission charged by the intermediary.
As shown in the image below, hotels use a decentralized application to post information about rooms, their availability and prices on weekdays or weekends on the blockchain, and perhaps even a description of the rooms with all other pertinent information.
Anyone who wants to book a room uses this app to find hotels and rooms hosted on the blockchain. As soon as the user selects a room, the reservation is made by sending the required amount of tokens to the hotel as a deposit. And in response, the smart contract updates the information in the blockchain that the number is no longer available.
There are two sides to the scalability problem in this approach. First, the maximum number of transactions per second. Secondly, the amount of data that can be stored on the blockchain.
Let's do some rough calculations. Booking.com claims they have almost 2 million hotels registered. Let's assume that on average a hotel has 10 rooms and each room is booked only 20 times a year - this gives us an average of 13 bookings per second.
To estimate this number, it is worth noting that Ethereum can process approximately 15 transactions per second.
At the same time, it should be taken into account that in our application there will also be transactions from hotels - to download and constantly update information about their rooms. Hotels update room rates very frequently, sometimes even daily, and each price or description change requires a transaction on the blockchain.
There are also size issues here - the weight of the Ethereum blockchain recently crossed the 2TB mark. If applications with this approach became really popular, then the Ethereum network would become extremely unstable.
Such a blockchain-based system can exclude outsiders due to its impartiality and lack of centralization, the main advantages of blockchain technology. But the blockchain also has other features - it is distributed and not rewritable, these are excellent characteristics, but you have to pay for them with the speed and commission of transactions.
Therefore, dapp developers must carefully evaluate whether every feature using the blockchain really needs to be distributed and non-rewritable.
For example: what is the advantage of distributing each hotel's data to hundreds of machines around the world and permanently storing it there? Is it really important that historical price and room availability data is always included in the blockchain? Probably not.
If we start asking questions like this, we start to see that we don't necessarily need all the expensive features of a blockchain for all of our functionality. So what's the alternative?
Approach #2: Blockstack Inspired Architecture
Although the main emphasis on applications where users are the owners of their data (for example, such as , , or ), blockstack also has a philosophy of using the blockchain lightly, only when absolutely necessary. Their main argument is that the blockchain is slow and expensive, and therefore should only be used for single or infrequent transactions. The rest of the interaction with applications should occur through peer-to-peer, i.e. users of decentralized applications should share data directly with each other, and not through the blockchain. After all, the oldest and most successful decentralized applications such as BitTorrent, email and Tor were created even before the very concept of the blockchain.
Left: The first approach where users interact via the blockchain. Right: Users interact directly with each other, and the blockchain is only used for identification and such.
Let's go back to the hotel booking example. We want an impartial, independent and open protocol for connecting guests to hotels. In other words, we want to remove the centralized intermediary. We do not need, for example, to permanently store room prices in a shared distributed ledger.
Why don't we just let guests and hotels interact directly instead of through the blockchain. Hotels can store their prices, room availability, and any other information somewhere they'll be available to everyone - like IPFS, Amazon S3, or even their own local server. This is exactly what the decentralized storage system from Blockstack provides called . It allows users to choose where they want to store their data and control who can access it through an approach called .
To establish trust, all hotel data is cryptographically signed by the hotel itself. Regardless of where this data is stored, its integrity can be verified using the public keys associated with that hotel's identity stored on the blockchain.
In the case of Blockstack, only your identification information is stored on the blockchain. Information on how to get each user's data is stored in zone files and distributed through the peer-to-peer network using nodes. And once again, you don’t have to trust the data that the nodes give out, because you can verify their authenticity by comparing them with the hashes that are stored on the blockchain and from other users.
In a simplified version of the system, guests will use the Blockstack peer-to-peer network to search for hotels and get information about their rooms. And the authenticity and integrity of all the data you receive can be verified using public keys and hashes stored in blockstack.
This architecture is more complex than the first approach and requires a more complex infrastructure. In fact, this is exactly where Blockstack comes in, providing all the necessary components to create such a decentralized system.
With this architecture, we only store data on the blockchain that really needs to be distributed and non-rewritable. In the case of Blockstack, you only need blockchain transactions to register and specify where your data should be stored. You may need more transactions if you want to change any of this information, but this is not a recurring event.
Moreover, the application logic, in contrast to the first approach, works on the client side, and not on smart contracts. This allows the developer to change this logic without costly or sometimes even impossible smart contract updates. And by keeping the data and application logic off the blockchain, decentralized applications can achieve the performance and scalability of traditional centralized systems.
Conclusion
Applications running on Blockstack can scale much better than conventional blockchain applications, but this is a younger approach with its own problems and unanswered questions.
For example, if a decentralized application does not work on smart contracts, then this reduces the need for utility tokens. This can cause problems for businesses considering that ICOs have been the main source of funding for decentralized applications (including Blockstack itself)
There are also technical issues here. For example, it is relatively easy to implement a hotel reservation function in a smart contract, where, in an atomic operation, room reservation is made in exchange for tokens. And it's not very obvious how the booking will work in the Blockstack app without smart contracts.
Apps that target global markets with the potential for millions of users need to scale very well to be successful. It is a mistake to rely solely on blockchains to achieve this level of scalability in the near future. To be able to compete with big centralized market players like Booking.com, dapp developers should consider alternative approaches to designing their apps, such as the one offered by Blockstack.
Source: habr.com