No, running your decentralized application (dapp) on blockchain will not lead to a successful business. In fact, most users don’t care if an app is running on blockchains or not — they just pick a cheaper, faster and easier to use product.
Sadly, even if blockchains come with their own unique set of properties, most apps running on them are more expensive, slower and less intuitive to use than their centralized counterparts.
It is not uncommon to find a paragraph in a dapp whitepaper that says: “blockchains are expensive and not capable to support the required number of transactions per second yet. Fortunately, a lot of smart people are working on public blockchain scaling and blockchains will be scalable enough by the time we launch our dapp.”
In just one simple paragraph, a dapp developer can discard any deeper discussion on scalability issues and alternative solutions to the problem. This often leads to an inefficient software design where smart contracts running on blockchains are at the core of the application and serve as its backend system.
There are, however, unexplored venues in terms of the dapp design that scale much better by reducing the reliance on blockchains. Blockstack, for example, advocates a design where most of the application data and logic is stored outside of blockchains.
Let’s first take a look at a more traditional approach that uses blockchain as an intermediary between dapp users and that doesn’t scale so well.
Approach #1: Blockchain as Backend
To make things clearer let’s use the hospitality industry as an example. It’s a huge industry where intermediaries, like Booking.com, charge outrageous fees for connecting hotel guests and hoteliers.
For any intermediary we want to eliminate using this approach, we try to replicate its business logic using smart contracts on blockchains such as Ethereum.
The open source smart contracts running on an impartial ‘world computer’ can connect value creators and consumers without a third party company in between, with the end result of reducing costs and commissions charged by the intermediary.
As illustrated below, hotels use the dapp to publish to a blockchain the information about rooms in their inventory, their availability and the prices on weekdays and weekends, possibly even storing room descriptions, and any other relevant information.
Anyone who wants to book a room uses the dapp to search through the hotels and rooms available on the blockchain. Once the user picks a room, a reservation is made by transferring the required amount of tokens to the hotel as a deposit. In turn, the smart contract updates the blockchain to reflect that the room is no longer available.
There are two sides to the scalability issue in this approach. Firstly, the maximum number of transactions per second. Secondly, the amount of data that has to be stored on the blockchain.
Let’s do a rough calculation. Booking.com claims to have almost 2 million hotels on their website. Let’s say that on average a hotel has 10 rooms and each one is booked just 20 times a year — this gives us an average of approximately 13 bookings per second.
To put this number into perspective, Ethereum can process roughly 15 transactions per second.
Even more transactions would be generated by hotels uploading and constantly updating their inventory. Hotels update room prices frequently, sometimes daily, and every pricing and inventory change requires a blockchain transaction.
There is also a size problem — Ethereum blockchain has exceeded 2TB recently. If Ethereum-style dapps were to become popular, they would bloat up the blockchain unsustainably.
Such a blockchain based system could eliminate third parties because of its impartiality and absence of central authority — the cornerstones of blockchain technology. But blockchains are also immutable, irreversible and distributed — which is great, but it comes at a considerable price in terms of speed and transaction fees.
That is why a dapp developer should carefully assess whether each feature that uses blockchains really requires an immutable, irreversible and distributed ledger.
For example: what is the added value of distributing every hotel’s data across hundreds of machines across the world and then keeping them there forever? Is it essential that historic room prices and availability data are forever embedded in a blockchain? Probably not.
If we ask these questions, we start seeing that we don’t necessarily require all the expensive characteristics of a blockchain for all of the features. So, what’s the alternative?
Approach #2: A Blockstack Inspired Design
Even though Blockstack’s main focus is on dapps where users own their data, they also have a philosophy of using blockchains sparingly — only when absolutely necessary. Their argument goes that blockchains are slow and expensive, and should be used only for one-off or infrequent operations. The rest of the interactions between dapps should happen peer to peer, i.e. dapp users should share data directly with each other, rather than through a blockchain. After all, the oldest and most successful decentralized applications like BitTorrent, Email and Tor, were invented before blockchain technology even existed.
On the left: the first approach, where dapp users communicate through a blockchain. On the right: dapp users communicate directly with each other. A blockchain is only used for identity and other essentials.
Let’s go back the hotel bookings example. What we want is an impartial, independent and open protocol to connect guests with hotels. In other words, we want to eliminate a centralized intermediary. We don’t have a need to, for example, store room prices and hotel inventory on a shared, indestructible and distributed ledger forever.
Why don’t we just let hotel guests and hotels communicate directly — rather than through a blockchain. Hotels can store their prices, inventory and availability somewhere accessible to everyone: whether it’s IPFS, Amazon S3, or even their local server. This is exactly the functionality facilitated by a Blockstack’s decentralized storage system called Gaia. It allows dapp users to choose where they want to store their data and controls who can access it via an approach called multiplayer storage.
To establish trust, every hotel’s data is cryptographically signed by the hotel. Regardless of where this data is stored, its integrity can be verified using the public keys associated with that hotel’s identity stored on a blockchain.
In Blockstack, only your identity information is stored on a blockchain. Information about how to reach every user’s data is stored in zone files and propagated via a peer to peer network of Blockstack nodes. Again, you don’t need to trust the data provided by the nodes, because you can verify its authenticity by comparing it to the hashes stored on a blockchain and owned by other users.
In a simplified version of the system, hotel guests will use Blockstack’s peer network to discover hotels, and retrieve their inventory from the network locations provided. The authenticity and integrity of all the data you retrieve can be verified by using public keys and hashes stored on Blockstack’s virtual chain.
This is a more complicated architecture than the previous one, and requires a more complex infrastructure. In fact, this is where Blockstack comes in by providing all the necessary components to build such a decentralized system.
In this design, we store on a blockchain only data that actually needs to be immutable, irreversible and distributed. In Blockstack you need only blockchain transactions to register your identity and announce where your data will be located online. You might need to issue more transactions if you wanted to change some of that information, but this is not a recurrent event.
In addition, the logic of the application, as opposed to the previous approach, resides on the client side application rather than smart contracts. This lets the developer change that logic without costly, or sometimes impossible, changes to smart contracts; and by keeping the application data and its logic outside of a blockchain, decentralized apps can achieve the level of performance and scalability comparable to traditional centralized systems.
Final Thoughts
Blockstack apps can scale much better than traditional apps running on blockchain, but it is a slightly younger approach with its own challenges and unanswered questions.
For example, not running your dapp on smart contracts diminishes the need for utility tokens specific to the app. This might pose a business problem, given that ICOs have been the main source of funding for such decentralized applications (including Blockstack itself).
There are also technical challenges. For instance, it is relatively simple to implement a hotel booking functionality in a smart contract where in an atomic operation a room reservation is made in exchange for tokens. It is not that obvious how booking reservations could work on a Blockstack app without smart contracts.
Bottom line: dapps that often target global markets with potentially millions of users will need to scale extremely well in order to succeed. 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, decentralized app developers should consider alternative approaches to designing their systems, like the one advocated by Blockstack.
Thanks to Larry Salibra for review and providing the Blockstack chart.
Got feedback or ideas to share? Let’s chat! Connect with me on Twitter or LinkedIn