There has been a big push in the cryptocurrency space about “dApps” lately, with many cropping up as potential replacements to a lot of centralized services we currently are using. Like with the big push towards “cloud computing”, as an academic I often feel like we get caught up in buzzwords and hype rather than dig down into what actually makes something unique. When I see “we put our computing in the cloud!” I often really see “we run our computation on someone else’s computer now”. This didn’t need the existence of cloud computing, but applying the buzzword makes people (and investors) happy more often than not. But I digress about buzzwords, because the intent of these words do have meaning and, in many cases, implementations do adhere to the real definition. So, to start, we need to explore that real definition, and then understand what makes dApps unique.
What Makes a dApp a dApp?
Or, specifically, what are the properties that differentiate a “Decentralized App” from a centralized one? To clarify that definition, we need to dig deep into what an App means first. The most common use case of the word “App” was introduced with the advent of smartphones, where we click a little icon and a self-contained program runs. So, the fact that hundreds of people can use the same app concurrently, does that make it decentralized? Well, clearly, that’s not what we mean when we say dApps -- it’s not about the interface, it’s more about the structure, and the internals. When we say dApp, we tend to think within the cryptocurrency realm of “it can’t be stopped or shutdown, and it is accessible and verifiable to all”.
It’s commonly touted that “Crypto currencies were the first dApps”, but this is not actually correct. Similar to asking a distributed computing experts’ opinion on “cloud computing”, they would tell you “It’s just a buzzword, we’ve been doing this for ages”, and the same is true here. One of the first well known 'dApps' would be p2p torrents. Indeed, it adheres to all the ideologies of a decentralized application: it cannot be stopped or shutdown (since it is peer to peer), it is accessible (non-permissioned), and perhaps most importantly, it does not require trust (verifiable). Part of the coolness that makes torrents tick is also used in cryptocurrency -- the ease of the verification. When you are sent components of a file, you can quickly hash the components and form a verification structure to confirm you actually got the files you were looking for and not junk.
So what Makes Cryptocurrency based dApps Unique?
Although cryptocurrencies haven’t really invented the concept of a 'dApp', they have however done something extremely important: they have created a platform where dApps can be built and used with little barrier to entry, and linked into a tool we are already using. Similar to how Blockbuster was kicked to the curb by a new technology platform (the internet) enabling digital streaming, we are now seeing a rise of cryptocurrency platforms enabling new opportunities for change.
Cryptocurrency dApps also come in a unique flavour: the programmability of them. Rather than create a structure from scratch that has the properties required (p2p, non-permissioned, verifiable), we get this 'for free' by latching into a cryptocurrency. Then, we get the easy programmability that lets us build an application rapidly, which improves programmer efficiency and enables creativity with the fast turnaround time.
To summarize, there isn’t anything particularly unique about dApps enabled by cryptocurrencies, compared to those built without, as the uniqueness is only in the chosen platform. But, as we see with many other technologies, the ability to enable rapid innovation with an easy-to-use platform is the real win -- and is what we now see driving adoption and growth.
So, with all these cool things we’re seeing with dApps, are there issues that come with it?
The Dark Side of buzzwords: The Old Masquerading as New
As with most buzzwords, we often see a race to look like one is on top with the latest technology. With dApps, this actually can become dangerous to the user when there are certain assumptions that come with dApps. So, when looking at a self-proclaimed dApp, it’s important to ask, "Is this a 'dApp' or just an 'App'?”
We discussed briefly the key characteristics of a dApp, but the single most important property that often gets squashed by Apps masquerading as dApps is the verifiability. If you see a self-proclaimed dApp that relies on an unverifiable component (often being centralized or closed source), then be warned, it is not a dApp, it is just an App.
With the thought of a centralized, closed source component making a dApp just an App, you might now be wondering “well don’t all these dApps typically require a single source anyways?” -- which is a valid question, and which is actually two different issues: the first is the bootstrapping problem, and the second being outsourced verification. Let’s discuss these in turn.
The Bootstraping Issue
The issue of bootstrapping comes with the problem of identifying an initialization point into the decentralized world. How do you verify that the world you are seeing isn’t being intercepted by a man-in-the-middle attack, wherein they block you from viewing the whole picture? This issue also crops up in most decentralized system, including many cryptocurrencies (specifically, those that deploy PoS and DPoS). However, we often discard this concern due to the nature of the internet -- it is very hard for a man-in-the-middle to hide (forever!) a real entry point into the correct ecosystem, when we have such a well connected internet. But none the less, it is an important consideration when bootstrapping to ensure that you do not simply trust a single source to be your entry point.
An example of this issue we often see with torrents as well -- some new torrents crop up on sites, and you might download a virus that was pretending to be your totally legal linux distribution. This bootstrapping issue is often solved socially, with a strong and transparent community -- one that for example comments on these torrent sources about their validity.
Outsourcing Verification: The Problem with Interfaces
When we use a dApp, we do often have a single point of entry into the ecosystem. For example, STEEM here has Steemit. While the back-end might be completely compliant -- open source with verifiable logic -- not every person will be verifying the entirety of the application state before using it. We often call an interface that accesses a dApp this way a 'light' client. Light wallets are another example of this, which require an API endpoint to function. When the API endpoint is a trusted third party, we have outsourced verification to this trusted entity. When we use steemit.com, we have outsourced our verification to Steemit.
Funny enough, we’ve gone full circle here: one has created a decentralized application that does not require a trusted third party, and then has presented the entry point as using a trusted third party. Adding back in this trusted third party can be a cause for concern to a user -- this is the target point for phishing attacks (as an example, a malicious interface or light wallet that will steal your funds when you enter your keys), and has privacy risks (as the third party is aware of your interactions -- similar to how advertisements and platforms track your actions).
Yet, unfortunately, this is how most dApps are designed right now. We’ve gone full circle out of convenience: we don’t expect a user to be both competent and patient enough to verify completely the entire state of the ecosystem before issuing a transaction within it. And indeed, while many dApps have a completely verifiable back-end, very little auditing occurs: there are no 'watchmen' that ensure something fishy hasn’t happened on a dApp’s back-end. Which begs the question, "what advantages does a dApp offer us if it is only ever used exactly as an App?"
As an example problem, consider an 'decentralized exchange' dApp. When you submit a purchase order through the trusted third party, that trusted third party might front-run you and purchase what you were trying to, and then sell it back to you at a small premium. Structurally, the dApp is still a dApp -- everything was verifiable -- however the trusted third party has abused its position of power for a competitive advantage.
Finally, the single trusted third party offering the entry point into the dApp re-enables permissioned behaviour: censorship by the third party becomes possible. The information the entity presents to you might not match the real (verifiable) information, and things may be hidden. If your Light Wallet told you that you had zero funds, how can you be certain they are telling the truth? Thus, if you are not running complete verification yourself, you will not be able to notice such a discrepancy.
So, what are the solutions? Can we make dApps more decentralized?
Cliffhanger! While this post was a bit 'negative', in part two, I will talk about the positives on this topic: why decentralization is important to dApps and what opportunities that brings, and how we can make dApps more decentralized.
In fact, there are some interesting advantages that come with certain cryptocurrencies -- STEEM included! We can have the opportunity to take previous 'light' clients to dApps that outsource verification to a trusted third party, and instead design them to get full validation with little overhead. Seems crazy right? So stay tuned for the secret sauce on how that’s possible!