No, launching a decentralized application (dapp) on the blockchain will not lead to a successful business. In fact, most users don't even consider whether the application runs on a blockchain — they simply choose a product that is cheaper, faster, and easier to use.
Unfortunately, even if blockchain has its unique features and advantages, most applications that run on it are much more expensive, slower, and less understandable than their centralized competitors.
It’s quite common to find a paragraph in the whitepapers of applications built on the blockchain stating: "blockchain is expensive and unable to support the required number of transactions per second. Fortunately, many smart people are working on scaling blockchain, and by the time our application launches, it will be scalable enough."
In a simple paragraph, a dapp developer may avoid a deeper discussion of scalability issues and alternative solutions. This often leads to inefficient architecture where the backend and core of the application consist of smart contracts running on the blockchain.
However, there are still untested approaches in the architecture of decentralized applications that allow for much better scalability by reducing dependency on the blockchain. For example, Blockstack is working on an architecture where most of the application's data and logic is stored off the blockchain.
Let’s first look at a more traditional approach in which blockchain is used as a direct intermediary between application users, a method that does not scale particularly well.
Approach #1: Blockchain as Backend
To illustrate, let’s take the hotel industry as an example. This is a huge industry where intermediaries like Booking.com for connecting guests and hotels.
In any situation where we want to overcome such an intermediary using this approach, we will attempt to replicate its business logic by utilizing smart contracts on a blockchain like Ethereum.
Open-source smart contracts running on the 'world computer' can connect sellers directly to consumers without intermediaries, ultimately reducing the fees and commissions charged by middlemen.
As shown in the image below, hotels use a decentralized application to store information about rooms, their availability, and prices on the blockchain for both weekdays and weekends, and possibly even descriptions of the rooms along with all other relevant information.
Anyone looking to book a room uses this application to search for hotels and rooms listed on the blockchain. Once the user selects a room, the booking is made by sending the required amount of tokens to the hotel as a deposit. In return, the smart contract updates the information on the blockchain, marking the room as no longer available.
This approach presents two sides of the scalability issue. First, the maximum number of transactions per second. Second, the volume of data that can be stored on the blockchain.
Let’s do some rough calculations. Booking.com claims to have nearly 2 million hotels registered. Assuming that on average each hotel has 10 rooms and each room is booked just 20 times a year — this gives us approximately 13 bookings per second.
To assess this number, it is worth noting that Ethereum can process about 15 transactions per second.
Additionally, it should be considered that our application will also have transactions from hotels — to upload and constantly update information about their rooms. Hotels frequently update room prices, sometimes even daily, and every price or description change requires a transaction on the blockchain.
There is also the issue of size — the weight of the Ethereum blockchain has recently crossed the 2TB mark. If applications with this approach were to become truly popular, the Ethereum network would become extremely unstable.
Such a blockchain-based system can exclude outsiders due to its impartiality and decentralization — the main advantages of blockchain technology. However, blockchain also has other characteristics — it is distributed and immutable, which are excellent features, but they come at the cost of transaction speed and fees.
Therefore, dapp developers must carefully assess whether every feature utilizing blockchain truly requires decentralization and immutability.
For instance, what is the advantage of distributing data about each hotel across hundreds of machines worldwide and constantly storing it there? Is it really important for historical data on prices and room availability to always be included in the blockchain? Probably not.
If we start asking such questions, we begin to see that we do not necessarily need all the costly features of blockchain for all our functions. So, what is the alternative?
Approach #2: Architecture Inspired by Blockstack
While the main focus is on applications where users own their data (such as , , or ), Blockstack also has a philosophy of minimal blockchain use — only when absolutely necessary. Their main argument is that blockchain is slow and expensive, and therefore should only be used for infrequent or singular operations. All other interactions with applications should occur via peer-to-peer; that is, users of decentralized applications should share data directly with each other, rather than through the blockchain. Ultimately, the oldest and most successful decentralized applications, such as BitTorrent, email, and Tor, were created well before the concept of blockchain itself.
Left: the first approach, where users interact through the blockchain. Right: users interact directly with each other, and the blockchain is used only for identification and similar purposes..
Let’s return to the hotel booking example. We want an impartial, independent, and open protocol for connecting guests with hotels. In other words, we want to eliminate the centralized intermediary. There is no need, for example, to constantly store room prices in a common distributed ledger.
Why don't we simply allow guests and hotels to interact directly instead of through blockchain? Hotels can store their prices, room availability, and any other information anywhere it will be accessible to all — for example, IPFS, Amazon S3, or even their own local server. This is exactly what the decentralized storage system from Blockstack 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 public keys associated with that hotel’s identification information stored on the blockchain.
In the case of Blockstack, only your identification information is stored on the blockchain. Information on how to access each user's data is kept in zone files and distributed via a peer-to-peer network using nodes. And once again — you don’t have to trust the data that nodes provide because you can verify its authenticity by comparing it to the hashes stored on the blockchain and with other users.
In a simplified version of the system, guests will use the Blockstack peer-to-peer network to search for hotels and obtain information about their rooms. 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 sophisticated infrastructure. In fact, this is where Blockstack comes in, providing all the necessary components to create such a decentralized system.
With this architecture, we only store in the blockchain the data that genuinely needs to be distributed and is non-overwritable. In the case of Blockstack, you only need transactions in the blockchain to register and specify where your data should be stored. You might need more transactions if you want to change any of this information, but that is not a recurring event.
Moreover, the application logic, unlike the first approach, operates on the client side rather than on smart contracts. This allows developers to modify this logic without costly or sometimes even impossible updates to the smart contract. By keeping data and application logic out of the blockchain, decentralized applications can achieve performance and scalability levels comparable to traditional centralized systems.
Conclusion
Applications built on Blockstack can scale much better than typical blockchain applications, but this is a newer approach with its own challenges and unanswered questions.
For instance, if a decentralized application does not rely on smart contracts, it reduces the need for utility tokens. This could pose challenges for businesses, considering that ICOs have been a primary funding source for decentralized applications (including Blockstack itself).
There are also technical issues involved. For example, implementing a hotel booking function in a smart contract is relatively straightforward, where booking rooms occurs in exchange for tokens through an atomic operation. It is less clear how booking would work in a Blockstack application without smart contracts.
Applications targeting global markets with the potential for millions of users must scale very effectively to succeed. It is a mistake to rely solely on blockchains for achieving such scalability in the near future. To compete with major centralized market players like Booking.com, decentralized application developers need to consider alternative approaches to designing their applications, such as the one proposed by Blockstack.
Source: habr.com
