Architecture of Decentralized Applications (dApps)

Decentralized applications (dApps) are transforming the digital landscape by offering users autonomy, security, and transparency. Unlike traditional applications that rely on centralized servers, dApps are (partly or entirely) built on decentralized technology. In this article, we’ll explore the full stack architecture of a dApp, encompassing the frontend, hosting, wallets, smart contracts, access to nodes, data storage, and other potential components. Each layer can fill out a full blog by itself, but we try to summarize the full stack comprehensively.

🖼 Frontend

The frontend (client) is the user interface (UI) of a dApp. As in web2 it is often built using popular web technologies like HTML, CSS, and JavaScript. Frameworks such as React, Angular, and Vue.js are commonly used to create responsive and dynamic UIs.

The frontend has to somehow communicate with the backend. For that purpose a connection to a node is required and communication is utilized by libraries. The most popular Javascript libraries are Web3.js and Ethers.js the most popular Python library is web3.py. While we see more and more Javascript libraries and packages, especially supporting React, being published, the Python ecosystem is less developed (Hint: there is an obvious gap you could fill 🙌). These libraries provide utilities for handling frontend logic, including signing transactions, retrieving account information, managing web3 wallets, and more.

dApps also require the frontend to connect to a blockchain node before sending requests to the dApp’s backend, which consists of smart contracts deployed on chain. While running blockchain nodes yourself might reduce your dependency on any provider, it is resource intensive. Providers like Alchemy, QuickNode, Tatum, Ankr or Infura offer suitable solutions.

Shoutout to our frens at Alchemy, especially Vitto, for building the npx package create-web3-dapp, including everything needed to start building a dApp super fast 🏎.

🌐 Hosting

Hosting refers to the process of storing and serving an application’s files, allowing users to access and interact with it over the internet. In traditional, centralized hosting, one or more dedicated servers are responsible for serving the application’s content. This approach typically relies on a single entity, a hosting provider. The vast majority of dApps today are using centralized hosting. That creates a potential single point of failure as well as potential for cencorship. Decentralized application hosting diverges from the centralized model by distributing the application’s files across a network of nodes, each contributing storage and bandwidth resources. Solutions like IPFS or Swarm could be used. If you want to start hosting your dApp decentralized, definitely check out Fleek. If you feel like decentralized hosting is an overkill, still check out Fleek (their team simply did a really cool job hehe).

🪪 Wallets

Wallets are used to manage users’ digital assets, authenticate users and sign transactions on the blockchain. In the context of dApps, wallets store users’ private keys and facilitate transactions with the underlying smart contracts. There are a lot of different opinions about what kind of wallets offer reasonable user experience, have low barrier to entry but most importantly offer high security for the users (unfortunately there is a way too large number of bad actors trying to steal private keys and get access to wallets through social engineering!)

2 different kind of wallets are on the one hand browser-built-in wallets vs browser extensions and custodial vs non-custodial wallets.

Some web browsers, such as Brave or Opera, come with built-in wallets that allow users to manage their digital assets and interact with dApps directly within the browser. Microsoft just recently announced they’ll also build in a native wallet into its Edge browser. Browser extension wallets, such as MetaMask or Trust Wallet, are separate add-ons that users can install in their preferred browser. These wallets are typically more versatile and support a wider range of cryptocurrencies and blockchain networks. While built-in wallets are often limited in the number of supported blockchains today, extensions are more vulnerable to attacks like phishing.

Custodial wallets are managed by third-party service providers, such as exchanges or wallet services, that maintain control over users’ private keys. Users access their wallets through the service provider’s platform, relying on them for security and asset management. Non-custodial wallets give users complete control over their private keys, allowing them to manage their digital assets without relying on a third party. Usually the wallets that can be used to interact with dApps are non-custodial, so users have to manage the private keys themselves. There are various different approaches to non-custodial wallets like Magic, Argent or Metamask.

🔌 Nodes

Nodes are individual servers that participate in the blockchain network by validating and relaying transactions. To interact with a dApp, the client/frontend must connect to a node within the blockchain network. However users can also interact with the dApp directly through a node or through another smart contract! This means your frontend is not the only way how users might be interacting with your backend if your smart contracts are deployed on a public blockchain.

Services like Alchemy and QuickNode provide access to remote nodes, allowing developers to focus on building their dApps without having to maintain their own infrastructure. For spinning up a dedicated node but still not managing yourself Chainstack is a viable solution. Alternatively, developers can run their own nodes using software like Geth (Ethereum) or Solana’s Validator.

Nodes support read and write operations. If your application only allows to read data from the blockchain no transaction fees need to be paid. If your dApp supports write operations transaction fees (= gas fees) need to be paid. Tatum for example not only provides nodes, but also provides a solution for the dApp developer to pay for the user’s gas fees, so users don’t have to pay the gas fee themselves (which subsequently ensures that your user can fully interact with your dApp even if their digital assets might not be sufficient to pay for gas.)

📜 Smart Contracts

Smart contracts are the backbone of any dApp, allowing to write to and read from a blockchain. Written in programming languages like Solidity (Ethereum) or Rust (Solana), smart contracts define the logic and rules governing the dApp’s operations.
In a typical smart contract, once deployed, its code cannot be changed, which can lead to difficulties when attempting to fix bugs or add new features. Upgradable (proxy) contracts approach this issue by separating the contract logic from the contract’s data storage. These contracts consist of two main components (basically 2 or more smart contracts):

1. Proxy Contract: The proxy contract acts as a middleman, forwarding incoming requests to the logic contract while maintaining the contract’s state. This contract remains unchanged during the upgrade process.
2. Logic Contract: The logic contract contains the actual code and business logic of the application. Developers can deploy new versions of the logic contract and update the proxy contract to point to the new logic, allowing seamless upgrades without affecting the contract’s data.

A dApp can not only utilize the smart contract developed inhouse but also connect with smart contracts (protocols) deployed by others. For example the popular dApp 1inch (a DEX aggregator) has developed smart contracts to interact with the smart contracts of various decentralized exchanges like Uniswap and Sushiswap.

A smart contract deployed on one chain (e.g. Ethereum) can not simply interact with another smart contract deployed on another chain (e.g. Polygon). Supporting multiple chains will help to address a larger user audience and might bring advanced functionalities like zero knowledge proofs or faster transaction throughput. The only way for such cross-chain interactions is to implement bridges like Wormhole or interoperability protocols like Cosmos into the dApp.

⚙️ Indexing Solutions

Indexing solutions play a vital role in the decentralized application (dApp) ecosystem by making blockchain data more accessible and queryable. As blockchains grow in size and complexity, retrieving specific data directly from the chain can be slow and resource-intensive. Indexing solutions address this challenge by creating structured, indexed databases that enable faster and more efficient data retrieval. Many indexing solutions offer real-time data synchronization, ensuring that dApps are instantly notified when relevant events occur. This allows dApps to trigger webhooks or actions in response to on-chain events quickly and accurately.

The most commonly known solution is The Graph, which is a decentralized indexing protocol, to develop subgraphs, but also many of the node providers like QuickNode offer indexing features today.

🗄 Data Storage

While the blockchain is suitable for storing transactional data, it is not ideal for large-scale data storage due to scalability and cost concerns. Decentralized storage solutions like IPFS or Filecoin are often used for storing dApp data off-chain, providing a more efficient and cost-effective storage option. These services employ encryption and sharding to ensure data privacy and integrity. Also centralized data storage can be used when building a dApp but it won’t be fully decentralized anymore (same as with the hosting discussed above)

🔮 Oracles

Smart contracts execute predefined logic based on the information available within the blockchain network. However, many use cases require data from external sources (e.g., weather, stock prices, or sports scores) to function effectively. Oracles fulfill this need by securely providing off-chain data to smart contracts. Popular oracles are Chainlink and UMA.

💡 Conclusion

The full stack of a decentralized applications consists of many layers and components and there are a number of different vendors or approaches that can be decided for implementation today. What is more, new tools are built at high speed and grow the functionality, complexity but also usability of dApps at even higher speed.

We are trying to keep up with the developments and available vendors and visualize them here. Please feel free to check it out and comment for improvement proposals:

At Blocktorch we are on a mission to give web3 builders superpowers. Our web3 observability platform provides end-2-end observability like real-time tracing, logging and monitoring for developers building decentralized applications and smart contracts. We support the full stack of any dApp.