Architecture of a dApp

The architecture of dApp or Decentralized applications is quite different from traditional applications. Decentralized applications require a unique system design to achieve high security, reliability, and privacy.

In decentralized applications, there’s no centralized database that stores the application state. It means, unlike centralized applications the client-side application does not communicate to the database instead it communicates directly to the blockchain.

Introduction to Decentralized Application(DApp)

A decentralized application is an application built on a decentralized network that combines a smart contract and a front-end user interface. It is a type of distributed open-source software application that runs on a peer-to-peer blockchain network. The use of blockchain in dApps allows them to process data through distributed networks and execute transactions.

• They are open-source which means that all the required changes are agreed upon by a consensus of the majority of the users.
• dApps provide decentralized storage.
• They offer cryptography. The decentralized blocks of data are validated and proven true.

dApp Architecture

Below are the components of the dApp architecture:

• Ethereum blockchain.
• Smart Contracts.
• Ethereum Virtual Machine (EVM).
• Front-end.

The following diagram shows what the actual architecture of DApp looks like:

Let’s discuss the components in detail:

1. Ethereum blockchain: Ethereum is a decentralized and open-source blockchain platform that establishes a peer-to-peer network that securely executes and verifies application code, called smart contracts. Decentralized applications have their backend code (smart contracts) running on a decentralized network and not a centralized server. DApps use the Ethereum blockchain for data storage.

2. Smart Contracts: DApps use smart contracts to define the state changes happening on the blockchain. A smart contract is a collection of code and data that resides at a specific address on the Ethereum Blockchain and runs on the Ethereum blockchain. They are written in high-level languages such as Solidity and Vyper.

Solidity

// Example of smart contract in
// decentralized application

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;

contract Migrations
{
  address public owner = msg.sender;
  uint public last_completed_migration;

  modifier restricted()
  {
    require(
      msg.sender == owner,
      "This function is restricted to the contract's owner"
    );
    _;
  }

  function setCompleted(uint completed) public restricted
  {
    last_completed_migration = completed;
  }
}

3. Ethereum Virtual Machine(EVM): The Ethereum Virtual Machine is the global virtual computer that executes the logic defined in the smart contracts and processes the state changes that happen on this Ethereum network.

4. Front-end: The front-end is the part of the DApps users can see and interact with such as the graphical user interface(GUI), but the front-end also communicates with the application logic defined in smart contracts.

Communication Between Frontend And Smart Contract On Ethereum

To invoke functions the front end needs to communicate with smart contracts. But Ethereum is a decentralized network. Every node in the Ethereum network keeps a copy of all states on the Ethereum Virtual machine, including the data and code associated with every smart contract.

It is required to interact with one of these nodes to interact with the data and the code on the blockchain. This is because any node can broadcast a request for a transaction to be executed on the EVM. Then the job of a miner is to execute the transaction and propagate the resulting state change to the network. The transaction can be broadcasted in two ways:

1. Set up the node which runs the Ethereum blockchain software.
2. Use nodes provided by third-party services.

Why Use Third-party Services?

When third-party services are used there is no need to run a full node yourself. Setting up a new Ethereum node on the server can take much time. Moreover, more nodes need to be added to expand your infrastructure and the cost of storing the full Ethereum blockchain goes up as DApp scales.
The nodes one connects with to interact with the blockchain are often called “providers.”

• Ethereum provider (i.e. nodes) implements a JSON-RPC specification. This ensures that there’s a uniform set of methods when our frontend applications want to interact with the blockchain.
• One can read the state stored on the blockchain once connected to the blockchain through a provider. 
• But if one wants to write to the state before one can submit the transaction to the blockchain there’s one more thing that needs to be done and the thing is “sign” the transaction using the private key.
• Whenever the front end needs the user to sign a transaction, it calls on Metamask. Here Metamask plays the role of the signer. 

The role of Metamask in Dapp Architecture:-

• Metamask is a browser plugin that serves as an Ethereum wallet. we know that the Ethereum blockchain is a network and we need a special browser extension to connect that network.
• Metamask will allow us to connect the blockchain with our personal account and interact with the smart contract.
•  A user’s private keys are stored by Metamask in the browser, and when a user wants to write to the state, the user needs to “sign” the transaction using the private key.

• Metamask acts both as a provider and a signer because Metamask provides a connection to the blockchain (as a “provider”) and since it needs it to sign transactions that’s why it is also a signer.