A decentralized application (dapp, Dapp, dApp or DApp) is a computer application that runs on a distributed computing system.
Dapps, by definition, are regular/web/mobile applications built on top of a p2p network with below characteristics
- Completely Open Source – to gain the trust of potential users and increase transparency
- No Central Point of Failure – Application data cryptographically stored across all the nodes.
- Cryptographic Tokens (app currency)- the Dapps must use cryptographic tokens for application usage and incentivization.
- Decentralized Consensus – to support a trustless environment; and a mechanism to achieve consensus.
In this series of blogs, I am going to describe the common architectural components that constitute a Dapp. A real-world use case will be presented where scarce resources are shared in a distributed and trustless environment with no central authority or intermediaries. Afterwards, I will be providing code snippets of the Dapp built on top of EOSIO blockchain framework using a simple React.js web app along with reference to the git-repo.
Architectural Components
At the very basic, a Dapp has two components. Frontend and Backend. The frontend is a regular web application created using HTML/CSS and other web technologies. However, instead of interacting with a centralized backend server, they interact with blockchain node using smart contract(s). The application data in Dapp is stored in a decentralized way and the wallet-based mechanism is used instead of login/password to store user information in a secure way. In most real-world applications, there is also a need for some backend module where non-transactional/non-critical data is stored and utilized by front-end.
Since a smart contract cannot interact with the outside world, a trusted (and most often decentralized) service is used to fetch live data such as stock price or weather update. These trusted services are called oracles.
Blockchain Node
A full blockchain node stores a full copy of blockchain transactions, current state and blockchain protocol implementation along with API endpoints for clients. This validator node (or minor in bitcoin terms) is responsible for validation of transactions and generation of blocks.
Smart Contract
A smart contract is a cryptographically secure code segment on blockchain executed by validator node when a client triggers some action on that contract. This action takes the blockchain from one valid state to another and requires some incentive for the validator to consume his resource for taking up this task.
Wallet
User management in blockchain is done in a decentralized and secure way using the concepts of public-private key cryptography. Users use their private keys to sign all the transactions and publish a public key for anyone to verify. This allows for password-less authentication across web services and the private key is never revealed to the server or third parties. This private key is never shared with anyone.
These keys are stored safely in a wallet on the user’s mobile or computer and used by the user application while sending transactions.
Techniques like hardware wallets and custodial wallets can be utilized for specific use cases.
Web/Mobile Application
The frontend is a regular HTML/CSS/Javascript application which uses client javascript libraries like web3.js (for ethereum) and EOS.js (for EOSIO) to connect to the blockchain server via JSON RPC protocol and utilize the wallet functionalities for transactions.
Data Storage
1 KB of storage (in form of contract code or data fields) costs 0.032 ETH on Ethereum. In EOS, a user needs to stake 0.053 EOS to access 1KB of memory.
As we can see, Blockchain is not suitable for storing application data as this data needs to be replicated across all network nodes. We need an alternative storage mechanism that is price efficient and follows the distributed systems philosophy of blockchain.
IPFS is designed to create the content-addressable, p2p method of storing and sharing file data. I used IPFS as a mechanism to store our application data such as available parking spaces and retrieve using the generated hash code.
Couple of caveats that we need to take care of:
- At least one IPFS node should be up and have accepted to store my data.
- If the data contents are changed, hash codes need to be updated in an application as the stored hash codes are not valid anymore. This can be resolved using IPNS
Communication
Most blockchain frameworks provide ways for one smart contract to execute the action on another contract. This is useful in scenarios where one transaction needs to be triggered by another or there are dependent transactions that need to be executed in sequence.
To communicate some blockchain event to a front-end app, there are different mechanisms provided which differ across blockchains. Most of them provide block-level event notification which can be used to either update the front-end or execute some backend job.
Conclusion
In this blog, we explored the architecture of a common Dapp. In the next part, we will continue with a real-world use case of the blockchain, ParkAssist – a distributed parking space sharing application.
