I would like to draw attention to what seems to be a commonly misunderstood property of distributed applications running on a blockchain, or DApps for short. A claim I have repeatedly seen creeping up is a DApp’s alleged superior availability compared to a traditional centralized web application. One must take this with a grain of salt, as it depends largely on what is meant when one talks about a “DApp” and what this actually entails. I mean to write this as a heads-up for a non-technical audience, such as economists, investors, and other non-technical decision makers, as I’m sure developers or people with a technical background do see the problem in this argument straight away.
Terminology
Let’s clarify terminology and scope of argument briefly. I’m not aware of any precise definition of the term, but simply judging by what appears to be common appropriation (see for instance the DApp browser), a DApp is an application that partially or fully executes on a blockchain (such as Ethereum.) A user facing DApp (UFDA) is then a DApp that is made accessible to an end user through some form of gateway technology such as web browsers or desktop and mobile applications. Not all DApps are UFDAs; it is perfectly feasible and desirable to run DApps that purely execute on the blockchain as some form of mediator between other DApps. Examples include escrow services, oracles, and blockchain middleware. For most people, however, the most interesting DApps are naturally those that are user facing, so I would like to focus on these hereafter, and whenever I say DApp, I really mean a UFDA. Examples for UFDAs include gambling and betting applications, blockchain explorers, identity services and many more.
As for availability, when I say a DApp is (partially) available, I mean it must be ready to serve the end user by carrying out at least a portion of its defined functionality. It is unavailable if none of its features can be accessed by means of its gateway technology. That portion of a DApp which is used by an end user directly is called the interface from here on. We will see shortly why this distinction is important when talking about DApp availability.
Why DApps can experience downtime
Now to the core of my argument: most or all DApps will by their very nature be susceptible to down time, that is, to being unavailable for some fraction of their life-time. The reason why is that a typical DApp runs only a small portion of its code on the strong backbone that is the blockchain. To use an analogy, think of a car. A car has many moving parts: an engine, doors, wheels and so forth. Some parts are more important for the car to remain functional than others. For instance, I can remove a door, but the car will still run. If I remove the engine, it won’t run. What if I take off the wheels though?
Let’s carry this analogy to its conclusion: the blockchain is to DApps what the engine is to a car. Here’s the twist: If the engine runs with 99.99999% availability, but your tires go flat, your car isn’t going anywhere. It becomes unavailable from an end user’s perspective. The same is true for DApps. It is really only the core business logic and small amounts of state data that execute on the highly available blockchain. This is only the tip of the iceberg though; the user interface and more data heavy portions of a DApp will not actually execute on the blockchain, but most likely use standard web technology as found in any ordinary web app. Hence, they are just as susceptible to unavailability as any other web app out there.
This is exactly what happened during the DAO attack on June 17 2016: while Ethereum nodes were happily crunching away on transactions, major crypto exchanges and blockchain explorers suffered outages due to panicking traders flocking to those websites to rescue their investments from a rapidly decreasing Ether value. So if not even exchanges and key services such as those monitoring the blockchain are safe from downtime, what does this say about the general availability of DApps?
Breaking down availability
I would like to come back briefly to the point of what can and can not be made highly available. Again, one needs to understand the nature of DApps to understand which parts can remain available in cases of traffic spikes as those witnessed during the DAO attack and which ones might not. Let’s break it down.
1 — Business rules
Business logic and the associated persistent state transitions can — and probably should — execute on the blockchain. This will allow you to reap the availability and security benefits you gain from blockchain technology. This is great, but it’s simply only part of the picture.
2 — Data storage
For many DApps, like those that operate on large data files (such as music or photo attribution services), storing their data on general purpose blockchains like Ethereum is simply impractical. Being fully replicated (at least thus far —Ethereum is considering a sharding approach in the future, effectively splitting up the blockchain among nodes) blockchain size is quite literally one of its biggest growth pains. This is why DApp developers should not get incentivized to store large amounts of data directly on the blockchain. The Ethereum projects solves this problem by making it extraordinarily expensive to store data. In fact, at the time of this writing, a transaction storing 100KB worth of data on the Ethereum blockchain costs more than 17 US dollars (0.000000021 ETH/gas * 640000 gas/KB * 100KB * 12.85 USD/ETH). This makes it economically unfeasible to store things such as images directly on the blockchain. Instead, a DApp would most likely involve a traditional (centralized) storage solution and merely record the existence and ownership attribution of said data on the blockchain, but not the data itself. What this amounts to is obvious: the availability of said data is not bound to the availability of the blockchain.
3 — User interface
I mentioned before that user need to interface with a DApp. This will most likely happen through standard web technology such as HTTP, HTML and web browsers, where a user request is made through the web interface, the request gets routed through a traditional web app, and only then talks to the blockchain to execute business logic or query for account data. None of the code realizing these interactions, let alone the code responsible for an app’s presentational aspects, is stored on the blockchain. This, again, makes it susceptible to down time just as much or little as any other web app.
Conclusion
What does this all mean? It means that you shouldn’t read too much into the claims of blockchains being the silver bullet for app availability in the foreseeable future. It does mean, however, that crucial pieces of a DApp, namely state transitions, business rules and account data can still live on the blockchain and benefit from its distribution and availability aspects. So just keep in mind that a DApp is typically more than just some smart contract that runs on a blockchain.
