Decentralized Applications (dApps)
A decentralized application (dApp) is an application built on a decentralized network that combines a smart contract and a front-end user interface. On Ethereum, smart contracts are accessible and transparent –– like open APIs –– so your dApp can even include a smart contract that someone else has written.
A dApp has its backend code running on a decentralized peer-to-peer network. Contrast this with an app where the backend code is running on centralized servers.
A dApp can have frontend code and user interfaces written in any language (just like an app) to make calls to its backend. Furthermore, its front end can get hosted on decentralized storage such as IPFS.
- Decentralized – dApps operate on blockchains, an transparent platform where no one person or group has control
- Deterministic – dApps perform the same function irrespective of the environment in which they get executed
- Turing complete – dApps can perform any action given the required resources
- Isolated – On Ethereum, for example, dApps are executed in a virtual environment known as Ethereum Virtual Machine so that if the smart contract has a bug, it won’t hamper the normal functioning of the blockchain network
To introduce dApps, we need to introduce smart contracts –– a dApp's backend for lack of a better term. For a detailed overview, head to our section on smart contracts.
A smart contract is a set of code that lives on a blockchain and runs exactly as programmed. Once smart contracts are deployed on the network you can't change them. DApps can be decentralized because they are controlled by the logic written into the contract, not by an individual or company. This also means you need to design your contracts very carefully and test them thoroughly.
- Zero downtime – Once the smart contract is deployed on the blockchain, the network as a whole will always be able to serve clients looking to interact with the contract. Malicious actors, therefore, cannot launch denial-of-service attacks targeted towards individual dApps.
- Privacy – You don’t need to provide real-world identity to deploy or interact with a dApp.
- Resistance to censorship – No single entity on the network can block users from submitting transactions, deploying dApps, or reading data from the blockchain.
- Complete data integrity – Data stored on the blockchain is immutable and indisputable, thanks to cryptographic primitives. Malicious actors cannot forge transactions or other data that has already been made public.
- Trustless computation/verifiable behavior – Smart contracts can be analyzed and are guaranteed to execute in predictable ways, without the need to trust a central authority. This is not true in traditional models; for example, when we use online banking systems, we must trust that financial institutions will not misuse our financial data, tamper with records or get hacked.
- Maintenance – DApps can be harder to maintain because the code and data published to the blockchain are harder to modify. It’s hard for developers to make updates to their dApps (or the underlying data stored by a dApp) once they are deployed, even if bugs or security risks are identified in an old version.
- Performance overhead – There is a huge performance overhead, and scaling is difficult. To achieve the level of security, integrity, transparency and reliability that blockchains like Ethereum aspire to, every node runs and stores every transaction. On top of this, the overhead required in these systems is something like 1,000,000x that of standard computation currently.
- Network congestion – When one dApp uses too many computational resources, the entire network gets backed up. If transactions are being sent in faster than a blockchain's upper limit of transactions per second (TPS), the pool of unconfirmed transactions can quickly balloon. Ethereum's proof-of-work model only allowed for 10-15 TPS, though that upper limit is set to increase with its merge to Proof of Stake.
- User experience – It may be harder to engineer user-friendly experiences because the average end-user might find it too difficult to set up a tool stack necessary to interact with the blockchain in a truly secure fashion.
- Centralization – User-friendly and developer-friendly solutions built on top of the base layer of Ethereum might end up looking like centralized services anyways. For example, such services may store keys or other sensitive information server-side, serve a frontend using a centralized server, or run important business logic on a centralized server before writing to the blockchain. Centralization eliminates many (if not all) of the advantages of blockchain over the traditional model.