The content of this page has evolved over the years (check wayback machine for previous iterations) and was last updated in July 2019, with an excerpt from the book Token Economy which builds – among others – on the educational blogposts that have been published on this website since 2015.
As opposed to centralised applications that run on a single computer, decentralized applications run on a P2P network of computers. They have existed since the advent of P2P networks.
Decentralized applications don‘t necessarily need to run on top of a blockchain network. Tor, BitTorrent, Popcorn Time, BitMessage, are examples for decentralized applications that run on a P2P network, but not on a blockchain – which is a special kind of P2P network (read more: Origins of Bitcoin and Web3).
Decentralized applications are a piece of so ware that communicates with the blockchain, which manages the state of all network actors. The interface of the decentralized applications does not look any different than any website or mobile app today. The smart contract represents the core logic of a decentralized application. Smart contracts are integral building blocks of blockchains, that process information from external sensors or events and help the blockchain manage the state of all network actors.
The frontend of a decentralized application represents what you see, and the backend represents the entire business logic. This business logic is represented by one or several smart contracts interacting with the underlying blockchain. The frontend, as well as files like a photo, a video, or audio, could be hosted on decentralized storage networks such as Swarm or IPFS. Traditional Web applications use HTML, CSS, and javascript or the like to render a webpage. This page interacts with a centralized database, where all the data is stored. When you use a service like Twitter, Facebook, Amazon, or Airbnb, for example, the webpage will call an API to process your personal data and other necessary information stored on their servers, to display them on the page. User ID and passwords are used for identification and authentication, with low levels of security, since personalized data is stored on the server of the service provider.
Traditional websites: Front End → API → Database.
Decentralized applications are similar to a traditional Web application. The frontend uses the exact same technology to render the page. It contains a “wallet” that communicates with the blockchain. The wallet manages cryptographic keys and the blockchain address. Public-key infrastructure is used for user identification and authentication. Instead of an API connecting to a database, a wallet so – ware triggers activities of a smart contract, which interacts with a blockchain: Web3 compatible website:
*Front End (including wallet) → Smart Contract → Blockchain.
*
In contrast to Web2 applications, Web3 applications need a connection to the blockchain, which is managed by a special application called “wallet.” It keeps a record of the private keys and blockchain address, which represents the unique 30 identities and point of reference. Without a so ware that manages our digital identity, we will not be able to interact with the blockchain. The Web3, therefore, builds on the current Web2 stack and introduces additional elements on an application level. In the backend, the Web3 adds a whole new infrastructure layer for decentralized applications to interact with – the decentralized protocol stack. Decentralized apps need to have a component that manages a user’s private keys, with which one can sign transactions on the state layer, the blockchain (read more: Token Security – Cryptography).
Top comments (1)
Well, the architectural order is actually more like this:
Because first you need to establish the connection to the blockchain ("web3 provider") and only then it's possible to communicate with a smart contract.