In this chapter, we'll explore decentralized applications, or DApps. They were born from Ethereum's vision of reinventing the web and creating a new world of DApps called web3. DApps go beyond smart contracts and aim to decentralize all aspects of an application like storage, messaging, and naming.
So, what are DApps in simple terms? They are applications that don't rely on a single authority but operate in a decentralized way. Instead of one company controlling everything, DApps use technologies like smart contracts and peer-to-peer networks to give users more control over their data and interactions on the internet.
Think of it like this: with DApps, you can store your data in a decentralized manner, communicate securely without intermediaries, and have your unique identity in the network. It's all about breaking free from centralized control and giving power back to individuals.
In the next sections, we'll dig deeper into how DApps work, their reliance on smart contracts and peer-to-peer technologies, and the amazing possibilities they bring to the digital world. Get ready to discover the exciting transformation happening in the realm of decentralized applications!
What is DApp?
A DApp is an application that is mostly or completely decentralized. This means that different parts of the application, such as the backend software, frontend software, data storage, message communications, and name resolution, can be decentralized to varying degrees.
Creating a DApp offers several advantages that a typical centralized application cannot provide:
- Resiliency: A DApp's backend is controlled by a smart contract and operates on a blockchain platform. This distribution ensures that the DApp remains available without any downtime as long as the platform is functioning.
- Transparency: The on-chain nature of a DApp allows anyone to inspect its code, promoting trust and certainty about its functionality. Additionally, all interactions with the DApp are permanently recorded on the blockchain.
- Censorship resistance: Users can interact with a DApp without interference from centralized control as long as they have access to an Ethereum node. Once a smart contract is deployed on the network, neither the service provider nor the contract owner can modify the code.
Currently, most DApps in the Ethereum ecosystem still rely on some centralized services and servers. However, in the future, we anticipate the possibility of operating every part of a DApp in a fully decentralized manner.
Backend (Smart Contract)
In a DApp, smart contracts are used to store the program code and state of the application. They replace the traditional server-side component in a regular application. However, there are some important differences to consider. Computation in smart contracts can be costly, so it's crucial to keep it minimal. It's also essential to identify which parts of the application require a trusted and decentralized execution platform.
With Ethereum smart contracts, you can create architectures where multiple smart contracts interact with each other, exchanging data and updating their own variables. The complexity is limited only by the block gas limit. Once you deploy your smart contract, other developers may use your business logic in the future.
There are two key considerations when designing smart contract architecture. First, once a smart contract is deployed, its code cannot be changed, except for complete removal if programmed with a specific opcode. It can be deleted if it is programmed with an accessible SELFDESTRUCT opcode, but other than complete removal, the code cannot be changed in any way.
Second, the size of the smart contract matters. Large monolithic contracts can be expensive to deploy and use, so some DApps choose to offload computation and use external data sources. However, relying on external data means users must trust those sources.
In summary, smart contracts are integral to DApps, but it's important to keep them efficient, plan for immutability, and carefully consider the use of external data sources for optimal DApp design.
Frontend (Web User Interface)
In a DApp, the part that users interact with can be built using normal web technologies like HTML, CSS, and JavaScript. This means that developers who are used to building websites can work on the user interface of a DApp without needing to learn new programming languages.
When it comes to communicating with Ethereum, like signing messages or making transactions, these actions can be done through a web browser using an extension called MetaMask. It helps in connecting the DApp with the Ethereum network.
Although it's possible to create DApps for mobile devices, there aren't many resources available to help developers build the user interface for mobile DApps. This is because there are limited mobile applications that can handle the specific requirements of DApps.
To connect the user interface with Ethereum, developers usually use a JavaScript library called web3.js. This library is included in the DApp's code and sent to the user's browser when they access the DApp.
In summary, building the user interface of a DApp is similar to creating a regular website using common web technologies. Interacting with Ethereum is facilitated through a browser extension like MetaMask. While mobile DApps are possible, there are fewer resources available for building their user interfaces. The web3.js library is commonly used to connect the DApp with Ethereum.
Data Storage
Smart contracts are not efficient for storing or processing large amounts of data due to high gas costs and the current low block gas limit. As a result, most DApps use off-chain data storage services. This means that instead of storing the data directly on the Ethereum blockchain, it is stored on a separate data storage platform.
There are two types of data storage platforms: centralized and decentralized. In centralized storage, data is stored on a typical cloud database, which is managed by a centralized entity. On the other hand, in decentralized storage, data is stored on a peer-to-peer (P2P) platform like IPFS (InterPlanetary File System) or Ethereum's own Swarm platform.
Decentralized P2P storage is particularly suitable for storing and distributing large static assets such as images, videos, and the resources used in the frontend of the DApp (HTML, CSS, JavaScript, etc.). These assets can be efficiently stored and accessed through decentralized storage platforms.
In the next sections, we will explore some of the options available for decentralized storage and how they can enhance the functionality and performance of DApps.
IPFS
IPFS, which stands for Inter-Planetary File System, is a decentralized storage system where files are distributed among peers in a peer-to-peer (P2P) network. It operates on a "content addressable" model, meaning that each file is given a unique hash that serves as its identifier. By using this hash, you can retrieve any file from any IPFS node in the network.
The goal of IPFS is to replace HTTP, the current protocol used for delivering web applications. Instead of storing a web application on a single server, IPFS allows the files to be stored across the network. This means that any IPFS node can serve the files, making the application more resilient and accessible.
In simpler terms, IPFS is like a giant, distributed storage system where files are identified by unique codes. You can retrieve any file by using its code, and the files are spread across many computers in a way that makes accessing them faster and more reliable. This technology aims to improve how web applications are delivered and make them more decentralized.
Swarm
Swarm is a content-addressable peer-to-peer (P2P) storage system that works similarly to IPFS. It was developed by the Ethereum Foundation as part of the Go-Ethereum suite of tools. With Swarm, you can store files that are then spread and replicated across various Swarm nodes in the network. Just like with IPFS, each file is identified by a unique hash, which allows you to access any specific file within Swarm.
The main purpose of Swarm is to enable decentralized and P2P access to websites and their associated files. Instead of relying on a central web server to host a website, Swarm allows you to access the website and its files through a decentralized network of nodes. This means that the website's content is distributed across multiple nodes, making it more resilient and ensuring that the website can be accessed even if some nodes are offline.
In simpler terms, Swarm is a technology that lets you store and access files in a decentralized way. It was created specifically to provide decentralized access to websites, so you don't have to rely on a single server. The files are spread across many nodes, ensuring better availability and reliability of the websites you visit.
Decentralized Message Communications Protocols
To communicate between different parts of an application or between users, we usually rely on a central server. However, there are decentralized alternatives that use peer-to-peer networks for messaging. One popular messaging protocol for decentralized applications is Whisper, developed by the Ethereum Foundation.
Another aspect that can be decentralized is name resolution. This means translating human-readable names, like domain names, into specific addresses on the internet. Efforts are being made to develop decentralized systems for name resolution, so we don't have to rely on a single central authority.
In simple terms, decentralized applications can communicate using peer-to-peer messaging protocols like Whisper, and there are ongoing developments to create decentralized systems for name resolution. These decentralized approaches offer alternatives to traditional centralized communication and naming systems.
The Ethereum Name Service (ENS)
When it comes to smart contracts, having a good interface for users is crucial. Just like the traditional internet uses the Domain Name System (DNS) to provide human-readable names for websites, the Ethereum blockchain has its own decentralized naming system called the Ethereum Naming System (ENS).
ENS solves the problem of translating human-readable names into specific addresses or identifiers on the Ethereum blockchain. For example, the Ethereum Foundation donation address, 0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359, can be represented as ethereum.eth in a wallet that supports ENS.
ENS is more than just a smart contract. It's a fully functional decentralized application (DApp) that provides a decentralized name service. It is supported by various DApps that handle registration, management, and auctions of registered names. ENS demonstrates how DApps can work together, serving other DApps and being embedded within them.
In this section, we will explore how ENS works. We'll learn how to set up your own name and associate it with a wallet or Ethereum address. We'll also discover how ENS can be integrated into other DApps and how it can be used to provide easier access to resources within a DApp.
In simple terms, ENS is like a decentralized phonebook for Ethereum, allowing users to associate human-readable names with addresses on the blockchain. It's a powerful tool that enhances the usability and accessibility of DApps.
History of Ethereum Name Services
Blockchain-based name registration was initially introduced by Namecoin, which was the first non-currency application of blockchains. The Ethereum White Paper also mentioned a similar name registration system as one of its example applications.
In the early versions of Geth and the C++ Ethereum client, there was a built-in contract for name registration (although it's no longer used). Several proposals and Ethereum Request for Comments (ERC) were made regarding name services. However, it was only when Nick Johnson joined the Ethereum Foundation in 2016 that serious work on a registrar for name services began.
The Ethereum Naming System (ENS) was officially launched on May 4, 2017, which is also celebrated as Star Wars Day. Initially, there was an attempt to launch it on Pi Day, which falls on March 15, but it was unsuccessful.
The ENS Specification
ENS is defined by three Ethereum Improvement Proposals (EIPs): EIP-137 outlines the core functionalities of ENS, EIP-162 describes the auction system for the .eth root domain, and EIP-181 specifies reverse resolution of addresses.
The design philosophy behind ENS follows a "sandwich" approach. At the bottom, there is a simple layer that provides basic functionality. Above that, there are layers of more complex code that can be replaced if needed. Finally, there is a simple top layer that keeps all the funds in separate accounts.
Bottom Layer: Name Owners and Resolvers
In the Ethereum Naming System (ENS), instead of directly working with human-readable names, the system operates on "nodes." To convert a human-readable name to a node, the "Namehash" algorithm is used.
At the base layer of ENS, there is a contract defined by ERC137, which is incredibly simple, consisting of less than 50 lines of code. This contract allows only the owners of nodes to manage information about their names and create subnodes, which are similar to subdomains in the traditional Domain Name System (DNS).
The core functions in the base layer of ENS are designed to enable node owners to set information about their nodes, such as the resolver (which specifies the address of the contract that handles the node's functionality), time to live (the duration for which the information is valid), and ownership transfer. Additionally, node owners can create new subnodes and specify their owners.
The Namehash Algorithm
Namehash is a recursive algorithm that can convert any name into a hash that identifies the name.
"Recursive" means that we solve the problem by solving a subproblem that is a smaller problem of the same type, and then use the solution to the subproblem to solve the original problem.
Namehash recursively hashes the components of a name to create a fixed-length string or "node" that represents the name.Namehash recursively hashes components of the name, producing a unique, fixed-length string (or “node”) for any valid input domain. For example, the Namehash node of subdomain.example.eth is keccak('<example.eth>' node) + keccak('<subdomain>'). The subproblem we must solve is to compute the node for example.eth, which is keccak('<.eth>' node) + keccak('<example>'). To begin, we must compute the node for eth, which is keccak(<root node>) + keccak('<eth>').
The root node is what we call the "base case" of our recursion, and we obviously can’t define it recursively, or the algorithm will never terminate! The root node is defined as 0x0000000000000000000000000000000000000000000000000000000000000000(32 zero bytes).
Putting this all together, the node of subdomain.example.eth is therefore keccak(keccak(keccak(0x0...0 + keccak('eth')) + keccak('example')) + keccak('subdomain')).
Thus, mastering-ethereum.eth will be processed as follows:
namehash('mastering-ethereum.eth')
⇒ sha3(namehash('eth') + sha3('mastering-ethereum'))
⇒ sha3(sha3(namehash('') + sha3('eth')) + sha3('mastering ethereum'))
⇒ sha3(sha3(('\0' * 32) + sha3('eth')) + sha3('mastering-ethereum'))
Conclusion
Decentralized applications are the ultimate goal of Ethereum's creators since the beginning. Nowadays, many applications claim to be decentralized, but most of them are not fully decentralized. However, it is already possible to create applications that are almost completely decentralized. As technology progresses, more and more of our applications can become decentralized, resulting in a stronger, more resistant to censorship, and liberated internet.
Top comments (2)
A captivating perspective! This piece seems set to explore how decentralized applications establish trust without relying on traditional intermediaries. Excited to uncover how these innovations are reshaping our digital interactions and fostering trust in a new era of technology.
I really enjoyed reading this blog post about decentralized applications (DApps) and how they bring trust in a trustless world. The article explains how DApps work and why they are important. It's fascinating to see how blockchain technology allows for transparent and secure applications without the need for intermediaries. The examples provided helped me understand the real-world applications of DApps. I appreciate the clear explanations that make it easier for people like me to grasp these concepts. This article has increased my understanding of decentralized applications, and I'm excited to see how they continue to shape our future!