Decentralized Application (dApp) Architecture Flashcards

A development team is building a dApp where the frontend is hosted on a decentralized storage network to maximize censorship resistance. However, they notice that large media files are loading slowly for users. Which of the following is the most direct and common architectural component used to address this issue in a decentralized manner without resorting to a centralized server?

Answer: Integrating a decentralized storage solution specifically designed for resilient and incentivized data delivery, such as Swarm or IPFS with Filecoin.

Decentralized storage solutions like IPFS and Swarm are designed to store and distribute content in a peer-to-peer fashion. [1] While IPFS itself doesn't guarantee data availability, combining it with an incentive layer like Filecoin encourages nodes to store and serve data. Swarm has built-in incentive mechanisms to ensure content availability and delivery. [17, 27] These systems are the appropriate architectural choice for resiliently serving large files in a dApp, directly addressing the slow loading issue without compromising decentralization. A centralized CDN introduces a single point of failure. Indexing solutions query on-chain data, they don't host or deliver off-chain files. Increasing gas price is irrelevant as file storage and retrieval happen off-chain.

In a typical dApp architecture, what is the primary role of a JavaScript library like ethers.js or web3.js?

Answer: To act as a bridge, translating frontend JavaScript calls into JSON-RPC requests that can be understood by an Ethereum node.

Libraries like ethers.js and web3.js are fundamental to dApp frontends. [21] They provide a convenient JavaScript interface for developers to interact with the Ethereum blockchain. [36] These libraries abstract away the complexity of the JSON-RPC protocol, which is the standard for communication with an Ethereum node. [36] They allow the frontend to read blockchain data, send transactions, and call smart contract functions by translating these actions into the appropriate JSON-RPC requests. [9, 21] They do not execute EVM logic, act as an IDE, or handle private key storage (which is managed by wallets like MetaMask).

A team is designing a dApp for a high-frequency trading game where thousands of interactions per second must occur between a small, defined group of players. Placing every interaction on the main Ethereum network would be prohibitively expensive and slow. Which architectural solution is best suited for this scenario?

Answer: A state channel, because it allows participants to conduct numerous off-chain transactions privately and settle only the final state on-chain.

State channels are a Layer 2 scaling solution ideal for applications with a high volume of interactions among a defined set of participants. [10, 23] Participants can transact off-chain nearly instantaneously and at a very low cost, as they are only updating the state among themselves. [15] Only two on-chain transactions are required: one to open the channel and lock the state, and one to close it and settle the final state. [7, 10] This makes it perfect for a high-frequency game. A sidechain would still have transaction fees and latency, and a centralized server defeats the purpose of decentralization. Sharding is a Layer 1 change, not a specific architectural choice for a single dApp.

Which of the following BEST describes the architectural difference between a dApp's backend and a traditional web application's backend?

Answer: A dApp's backend logic is encapsulated in smart contracts that run on a decentralized peer-to-peer network, whereas a traditional backend runs on centralized servers. [19, 22]

The fundamental architectural shift in a dApp is the backend. In a traditional web application, business logic runs on centralized servers (e.g., using Node.js, Python, Java) that the application owner controls. [2, 13] In a dApp, the core backend logic is codified into smart contracts and deployed on a decentralized blockchain network. [3, 19, 22] This means the backend is not controlled by a single entity but is executed by the network of nodes, providing transparency and censorship resistance. [14, 22]

A developer is building a dApp that needs to display a user's transaction history. Querying the blockchain directly for every page load is inefficient and slow. Which architectural component should be integrated to improve performance for reading and presenting on-chain data?

Answer: An off-chain indexing service like The Graph.

Directly querying historical data from a blockchain can be slow and resource-intensive. Indexing solutions, such as The Graph, solve this problem by processing blockchain data and storing it in a structured, easily queryable format. [5] They create indexed databases that allow dApps to make fast and efficient queries for on-chain data, which is ideal for functionalities like displaying transaction histories. IPFS is for file storage, MetaMask is for wallet interaction, and rollups are for scaling transaction throughput, not for optimizing data queries.

When designing a dApp, a developer decides to store user profile pictures and other large static assets on IPFS. What is the primary architectural reason for this decision?

Answer: To reduce transaction costs and avoid bloating the blockchain with large amounts of data.

Storing large files like images directly on a blockchain (e.g., Ethereum) is technically possible but extremely expensive due to the cost of block space (gas fees). [1, 33] Therefore, a standard architectural pattern for dApps is to store the core logic and state on-chain via smart contracts, while storing large, static assets off-chain. Decentralized storage solutions like IPFS or Swarm are used for this purpose. [3, 27] They are content-addressed and provide a decentralized way to store data, which is then referenced from the smart contract, thus avoiding the high costs and storage limitations of the blockchain itself.