That’s not a Dapp!
Written by Daniel Larimer, republished with his permission.
A lot of people are peddling their “decentralized” application on the basis that it runs on a public blockchain. I would like to take a moment and ask ourselves “what qualifies as a Dapp?”. If we leave this question unexamined then we might not get the freedom and independence that many of us want. Furthermore, a lot of time and energy could be wasted building a product that has all of the disadvantages of “decentralization” and “centralization” and none of the advantages of either.
The key word here is “decentralized”. This is a word that has defied definition over the past decade. I’m going to take a stab and define it as “no central point of failure”. The question then becomes how much redundancy is necessary to be considered a “Decentralized Application”?
Let’s look at some examples of how Decentralized Applications are not actually decentralized:
Centralized Web Service
If an application must connect to a specific server for its API or a user must use a specific web interface to interact with a smart contract and its state, then what you have is a centralized application using a public blockchain as a database.
An argument is made that “anyone” could host a particular service to interact with the blockchain, but that is often an illusion. How would clones make money by hosting a mirror interface? Are there any proprietary services that require undocumented expertice to setup and maintain? If a user of a particular Dapp doesn’t have a half dozen independent and competing “api providers” to select from then the application is still centralized. If the existing “centralized provider” is shut down, what are the chances that a new “centralized provider” will pop up? How much time and energy does it take to restore the application to functionality?
There are many reasons why a centralized service would be built upon a public blockchain. The most obvious is the ease of integration with other centralized and decentralized systems operating on the same blockchain. These kinds of services have one leg in the centralized world and one leg in the decentralized world. Unfortunately, that single dependency on the centralized world is enough to disqualify them from being a decentralized application.
Centralized Wallet Service
There are many wallets that rely upon API servers to fetch data and submit transactions. More advanced wallets even integrate services such as multi-factor authentication and resource management. They might even depend upon companies like Apple to allow their interface to exist in their centralized app store.
Many wallets do allow you to swap out some aspects of the service provider API.
These centralized wallet services may be easier to use and potentially more secure, but they are nevertheless centralized. Applications that depend upon these wallets are in turn centralized.
Centralized Contract Ownership
Have you ever heard about a token being “delisted” from a “decentralized” exchange? That is a sure fire way to know that what you were dealing with was a centralized exchange using a public ledger to implement their matching engine. The ‘owners’ of these “decentralized exchanges” end up subject to all manner of laws and regulations.
If the individual who deploys a smart contract retains control over the contract and has the ability to modify or shutdown the contract then you are dealing with a centralized application deployed on a decentralized ledger.
What would a decentralized application look like?
A decentralized application would be downloadable to your desktop computer. It would come preloaded with a number of services it could connect to for data and could support a gossip protocol to learn of new service providers. Lastly it would interact with a smart contract controlled by a decentralized governance process involving people from multiple jurisdictions where no single person is deemed the owner. There would be no legal entity behind the contract. The best case scenario would be a completely immutable contract published by an anonymous individual.
The most important aspect of a decentralized application is the economic incentives that keep it operating. Users are either bartering chunks of files (Bittorrent) or utilizing a cryptocurrency to facilitate fee-for-service arrangements.
Stated more broadly, a decentralized application is downloaded to your computer and interacts with a multitude of virtual “vending machines” which anyone can deploy in order to generate a profit selling data services. If you cannot find a “vending machine” you trust then it should be relatively cheap to host your own vending machine.
I call these “vending machines” a “business in a box”. Turn-key services that require minimal setup and generate a revenue stream for their owner with just a little bit of advertising. Ideally the advertising is built into the protocol.
The simplest example is the original Bitcoin client. It would provide a user interface on top of a full bitcoin node. Every node could serve as a peer and everyone could mine to earn fees.
The original BitShares application worked just like the original Bitcoin app. This was truly decentralized finance. Many of the applications attempting to pass themselves off as DeFi are dependent upon a centralized hosted interface.
Now that blockchains like Bitcoin, EOS and Ethereum are too heavy-weight for most people to operate at home we need a new architecture for ensuring decentralization. We have been lulled into complacency by the convenience of “light clients” that depend upon “centralized APIs” which are not widely and easily replicated.
Decentralizing EOS
Applications looking to build on EOS need a multitude of economically sustainable API nodes to feed them data. These API nodes need to do more than simply answer queries, they need to make money for their operators! They need to be general enough in the types of queries they can answer that application developers do not need to create custom indexes in order to function. In this manner, the API node operates in an application neutral and theoretically unregulated manner.
Applications need to provide their users with an experience that is as simple as possible. An example of a “bad” experience is telling the user they must do the following before interacting with your application:
Buy RAM
Rent CPU from the network or a 3rd party (like Anchor Fuel)
Pay one or more API service providers to give you data
Configure endpoints for submitting transactions
Then after figuring out all of those things you can start to pay the fees needed by the actual decentralized application. Note that while the example above applies to EOS, it equally applies to many Ethereum applications. Users must pay Gas costs and need someone to provide them with indexed data for the application.
Today many decentralized applications are relying upon individuals providing free (and therefore unsustainable and unscalable) services. Block producers are operating at a loss while most of their income goes to pay for votes. This loss is only sustainable through profits generated by other, often centralized, businesses owned by the block producers.
Proposal
I propose forming a team that integrates the best API services from dfuse, Hyperion, Greymass, and others along with an automated billing system. Combine all of this into an easy to configure and deploy service that allows people to make money. Then we can sustainably and profitably decentralize the scalable infrastructure required by growing Dapps. Until this is achieved most blockchains and blockchain powered “DApps” are really a new kind of centralized application leveraging some decentralized infrastructure.
How will we know that our goal has been achieved? When applications can be deployed as a progressive web application which does not depend upon the original server once it has been installed to the home screen of your phone. When these applications come pre-configured with a half dozen independent API nodes and allow for the easy addition of more. Lastly, when this entire user experience is simplified to a point that “things just work”.
If we don’t take this seriously then one day we could wake up to companies like Apple threatening to “delist” any application that doesn’t block the use of certain “illegal” smart contracts. We could find wallet providers expected to enforce AML/KYC and sanctions rules. We could find domain names seized by regulators. In short we will find that power was not restored to the people and that the “decentralization” was an illusion.
This post was originally posted on https://eoscommunity.org/ be sure to sign up and join the EOS community!
Learn how to earn…
Become part of our community.
Follow our socials.
Subscribe to our podcast.
Subscribe to this publication.
It’s free (for now)