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!
I can't help but think of D-Live as an example of the use of the Dapp buzzword. People were so happy to have what appeared to be a smooth functioning "Decentralized"-Live streaming service that most never bothered to check under the hood to see if the platform was what it claimed to be. Dapp - Dupped maybe?
Seems pretty simple to just call your App a Dapp, and most people won't ever bother to check for themselves if an application is centralized or decentralized.
Thanks for this article, I've never thought of the prospect of a DEX front-running a transaction to earn small profits. With enough volume and over time this could be a substantial amount.
Definitely food for thought.
It's possible for parts of an app to be decentralized and parts not. With Steem, most people really just care about the decentralized reward system (or really they probably just care about the reward system which happens to be decentralized, but that's beside the point here). So D-Live was a centralized app which utilized the Steem decentralized reward system to reward the content.
I think that is totally fine, and would like to see more apps use that model (vs the dtube model of trying to fully decentralize everything and having a poorly working product as a result).
Indeed, d-live was one of the catalysts for me wanting to write out my thought's on this topic. I was always thinking "That's not a dApp!" but there really hasn't been a concrete definition of dApps or the degree to which they are truly decentralized.
The DEX example I think is a really powerful one. It shows a clear problem, and one that can only be solved by removing the centralization -- the middle-man sitting in front of the real dApp. Which I will explain how that's possible in part 2 :)
Right on! I'm looking forward to Part 2 as someone who has become increasingly interested in blockchain/crypto/decentralization I'm really interested in learning more about ways in which non-tech / non-developers can play a roll in helping bring actual decentralization to fruition.
Probably getting ahead of myself but any chance you'll be exploring IPFS in your follow up piece at all? I'm curious to know if IPFS or an alternative to it like MaidSafe could transform the landscape and what that might actually look like. But that's a big question, lol, I'm sure there's no simple answers here.
Cheers!
So, IPFS (which is actually very similar to torrent files on a theoretical level) has all the 'nice' properties that come with being stateless. Because of this, IPFS and torrents don't fundamentally need a cryptocurrency platform to enable them (though you can use one, you don't need to).
By stateless I mean this: once you solve the bootstrapping problem (e.g. finding the hash of the file you're looking for, or the torrent file you want), verification is actually quite easy as it doesn't require external validators. The hash of the file always matches -- as it has no state, the file contents don't change, and thus it is easy to verify the hash of the file matches the hash you are looking for.
For statefull content, think about your account balance. There's no way for you to validate your own account balance in constant time -- you need to know the current state of the whole ecosystem and it's entire history to know your balance, as your balance is actually not a single "thing" with cryptocurrencies: your balance is rather the sum of all your historical actions regarding your balance.
So, unfortunately file storage doesn't help with statefull content -- this is where we have that necessity for validation, and where we run into the trusted interfacing problem. If the trusted interface misses (or hides) a historical action, they hide the truth. And unlike with stateless content, you cannot immediately validate on your own that an item is missing.
Another case in point would be steem monsters. Yes your cards "belong" to you but the way they are randomly selected is not verifiable. The same for the combat system, from what I understand.
Nevertheless, this is true to many platforms. Ethereum, that popularized dApps, also has its own share of problems. Chiefly amongst these, is the fact that most apps use Infura as a proxy to the blockchain. Again, outsourcing trust... But of course people are aware of it. Until proper light clients come in this is the only way to have dApps that have some ressemblence of a decent UX... Plasma chains are another option...
Truth be told, DLive was suspicious for me from the start.
@heimindanger's DTube is the only solid truly decentralized attempt out there right now.
Posted using Partiko Android
Are there any Steem “dApps” that are actually decentralized? Or do they all masquerade as “dApps” while a majority of them are actually more centralized than most existing social media apps? I can’t think of any off the top of my head that are decentralized in any sense of the word.
It’s even somewhat questionable to me that Steem is called decentralized, considering how distribution is and how protocols are proposed and implemented.
I would say some are, yes, in the sense that the underlying working parts conform to the constructs that make it a dApp. I have noticed that quite a few rely on some dodgy centralization though.
I would however argue that they are all currently facing the interfacing issue -- so in that sense, none (including all our interfaces to the STEEM dApp) are truly decentralized for all users from start to end, unless you are validating the data yourself.
The STEEM cryptocurrency platform I would argue is decentralized from most metrics (though it does miss a few marks, these concerns are mostly academic). But the way the majority of users interface with it is not decentralized.
To me, only app base on smart contract is the true DAPP.
Posted using Partiko Android
After your definition in our steem ecosystem. Would it true to asses the following?
So, there might be a bit of a misunderstanding here. steemit.com is not a dApp, but not for your reasons -- steemit.com is an interface that access an underlying dApp (the STEEM ecosystem with posts, votes, and rewards). It's also not the only interface to access it.
But currently, steemit.com is not decentralized. When you access steemit.com, you outsource verification of the content displayed to Steemit Inc.
Indeed, if you were to download (and vet) condenser and run it off of your own
steemdnode, which is validating data, then you are accessing the STEEM dApp without outsourcing verification.Congratulations @anyx! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
Click here to view your Board of Honor
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Do not miss the last post from @steemitboard:
Excellent overview, that addresses much too neglected aspects of on-chain apps. Another factor might also be who is in charge of the code. Of course open-source is a strong point. But if one single party is in control of the code and thus the operability of github, it can easily change it at will, which not necessarily reflects what the user community demands. This possibility of arbitrary changes could even lock up the users of the dapp.
This has been a rather enlightening article (which are increasingly hard to find on Steem) so I thank you for that. It has really opened my eyes regarding my perception about what dapp truly is. I will be able to explain the matter correctly myself from now on:) looking forward to reading the (hopefully more positive:D) article!
Resteem btw. I will also think about using another witness vote:).
Very nice article! Now I understand better what an app needs to be considered a dApp!
Indeed, transparency and auditability is very hard to implement and even harder to verify. I remember the old days, when security was assured solely by what UI would tell us, and personal finance apps would have backdoors to change password without requiring current one to be provided. Just hook a dll and u hack the app.
I'm happy to see how Software Engineering has been evolving security, to a point we don't need to trust our apps UI and not even its controller and persistence.
This new generation of apps is just starting, I hope that in some years we have the early ones redesigned to comply. They are still better than top systems like Facebook which isn't even crawled by Google.
Hey You Piece of Shit, why are you fucking up the Al Masdar News Blog?
https://steemit.com/news/@amnlive/nationalmuseumofdamascusreopenedforfirsttimein7years-m5b2eoyjhp