Decentralized Web: Building a DWeb that Requires No Permission from the Ground Up to the Front End

Author: Chloe, IOSG Ventures

This article is original content from IOSG and is intended for industry learning and communication purposes only. It does not constitute any investment advice. If you need to quote it, please indicate the source, and for reprints, please contact the IOSG team for authorization and reprint instructions.

Introduction

On August 8, the U.S. Treasury announced sanctions against the mixing protocol Tornado Cash. This sanction affected numerous Ethereum addresses, and even the official website of Tornado Cash was not spared, being banned as well. The U.S. government's actions have sparked much controversy within the crypto community, including questioning the vision of "decentralization" in Web 3.0. If all front-end websites that interact directly with crypto projects and users can be so easily banned, then how meaningful are the advantages of "permissionless" and "censorship-resistant" that decentralization of the underlying infrastructure brings? Coincidentally, just two days after the Tornado Cash incident, the decentralized exchange Curve Finance suffered a domain attack, resulting in a theft of $570,000. Curve stated that the issue primarily stemmed from the name server, where hackers redirected users or their transactions to another malicious website, causing financial losses. The vulnerabilities of the web once again stirred the nerves of the crypto community. In fact, discussions about the Decentralized Web have been ongoing for a long time. People envision a decentralized system composed of interconnected personal computers to provide private, secure, and censorship-resistant access to information and services.

So what are the limitations of the existing Centralized Web, how is the Decentralized Web constructed, and how far are we from Dweb? This article will introduce these aspects to the readers.

Cweb

HTTP and Client-server model

Before discussing the Centralized Web, let’s briefly understand the interaction model of the internet. Most of you may have heard of the TCP/IP and HTTP protocols, which are widely used foundational protocols of today’s internet and are closely related to our lives. TCP/IP is a transport layer protocol that is responsible for packaging data and addressing it, transferring data from one computer to another. HTTP, on the other hand, is an application layer protocol built on top of TCP/IP, which specifies how each segment of data should be formatted to be understood by another computer. Computers under HTTP have different roles, mainly divided into two types: servers and clients. Hosts that provide services on the Internet are called servers, such as major portal websites and social platforms; hosts that access servers to obtain useful information are called clients, such as various home computers and smartphones.

Today, the vast majority of centralized web pages adopt this server-client master-slave architecture. For example, when we want to check cryptocurrency prices on CoinMarketCap, our computer and web browser act as the client, while CoinMarketCap's computer, database, and application serve as the server.

When our browser requests access to CoinMarketCap, the server will retrieve the webpage information from the database, compile it into a webpage, and finally return it to our browser. It can be seen that this master-slave architecture is highly dependent on the server, which is responsible for the main data processing and storing user access data and user information. The advantages of this structure are straightforward: it allows for simple and quick deployment with low maintenance costs, thus being widely adopted and contributing significantly to the prosperity of the internet today. However, its drawbacks are also quite evident, with a high probability of single points of failure or single point attacks, resulting in relatively low security.

Domain Names and DNS

As mentioned earlier, the internet is built on the TCP/IP protocol, so we need to use IP addresses to address servers. An IPv4 address is a 32-bit binary number, usually divided into four 8-bit binary numbers. For example, the IP address of the CoinMarketCap webpage is 108.160.165.139, and we need to send requests to the server using this IP address. However, this string of numbers is too difficult to remember; memorizing the IP addresses of all the websites we frequently visit is no easier than memorizing an entire phone book. Thus, the concept of a Domain Name emerged. Domain names provide human-readable addresses for any available web server on the internet. Just as we may not remember our friends' phone numbers but will not forget their names, with domain names, we can access CoinMarketCap without entering the IP address, simply by typing coinmarketcap.com into the browser.

Therefore, DNS (Domain Name Service) acts like a phone book query tool, primarily converting host domain names into IP addresses. When people want to establish their own websites, the first thing they often do is purchase a domain name, making it easier for other computers to contact them. Many readers may wonder why domain names sound like a public good rather than a commodity. Who do we pay when we purchase a domain name? Before answering this question, let’s first understand the management organization behind domain names. The organization responsible for managing the operation of the domain name system is called ICANN, which is the highest management body for domain names worldwide. ICANN assigns different suffixes to different regions, countries, and operators for operation and maintenance.

For example, the .cn suffix is managed by CNNIC, the .com suffix by Verisign, and the .mo suffix by the Macao Registry. Suffixes are generally priced based on the operator's costs plus reasonable profits, and suffixes like .cn, .jp, and .hk are priced by their respective regions. A portion of the fees paid by users for domain names goes to ICANN, while another portion goes to the service provider. ICANN is headquartered in California, USA, and was originally a non-profit organization under the U.S. Department of Commerce. Therefore, the claim that the U.S. government controls domain names worldwide is not without basis. In 2016, the U.S. government announced that ICANN would no longer be under the Department of Commerce but would become a self-managed independent organization. However, it is evident that the U.S. government still has absolute influence over it. This brings us back to the topic at the beginning of the article: why can the U.S. government ban the official website of Tornado Cash? The simplest way is to block the domain name, preventing ordinary people from accessing the website through the domain. The hackers who attacked Curve also tampered with the domain name, redirecting visitors to a malicious website.

Dweb

It can be summarized that the centralization of the Centralized Web is reflected to some extent in the master-slave structure of the Client-Server under HTTP, as well as in the centralized management of domain names. Of course, there are many factors contributing to the centralization of the Centralized Web, and this article will focus on the two aspects of transmission protocols and domain names. In Web 3.0, we have already seen some solutions to these two issues—IPFS and decentralized domains.

IPFS versus HTTP

IPFS was born in the Protocol Labs, a protocol laboratory founded by Stanford University computer master's student Juan Benet, which focuses on the research, development, and deployment of network protocols. Similar to HTTP, IPFS is also an application protocol based on TCP/IP. However, unlike HTTP, IPFS is a p2p protocol based on content rather than address.

So what impact does this difference have on our usage? As mentioned earlier, the working principle of HTTP is to map content to IP addresses, where the IP address points to a specific server at a specific location that contains the resources needed by the visitor. For example, when we want to play a video on YouTube, our browser finds the location where the video is stored among Google's many servers and returns the video to us. To speed up this return process, we have also established CDNs (Content Delivery Networks) to bring servers closer to the physical location of users. However, CDNs also have geographical limitations and are of limited use in developing countries with relatively underdeveloped infrastructure.

Imagine that there are 100 students sitting in a classroom watching the same YouTube video simultaneously, with each student's client sending requests to the YouTube server. The above process needs to be repeated a hundred times, causing significant congestion and resource waste. So how does IPFS solve this problem? The "address" in IPFS is actually a hash generated based on the content. When students want to watch a video, their computers do not query the IP address of a centralized server but search for the content across the entire P2P network. If a student’s computer in the classroom has the video stored, they will retrieve it from each other, ensuring that the data comes from the nearest source.

Image source: https://blog.csdn.net/shuoyue0723/article/details/119042236

It can be seen that IPFS is a content transmission protocol built on a P2P network, where there is no hierarchical division between servers and clients; each node acts as both a client and a server. It is evident that IPFS has many advantages brought by "decentralization." First, IPFS avoids the problem of single points of failure, enhancing the scalability and flexibility of the network. It also has higher performance, allowing user requests to be processed more quickly. So why hasn’t IPFS, with its numerous advantages, been widely adopted? This is a common problem faced by P2P networks, which is that the operational and maintenance costs are extremely high. For example, if there is an issue with my node, I may not have the ability to resolve it. Secondly, there is the issue of coordination; nodes in a P2P network act independently and do not communicate with each other, making it difficult to achieve collective collaborative tasks. Therefore, considering the cost/benefit ratio, IPFS may not necessarily benefit all organizational structures.

Decentralized Domain Name Service

Compared to IP addresses, the hashes used for content retrieval are more complex, so we also need a decentralized DNS to translate hashes into names that are easy for humans to understand and remember. How should we understand decentralization here? Let’s first understand how the existing DNS operates in a centralized manner. Currently, DNS operates in a tree structure, with only 13 Root DNS servers holding the highest authority globally. When the top-level DNS server in this hierarchical structure goes down, the subordinate servers under it will also stop functioning, causing widespread network paralysis.

Against this backdrop, the concept of decentralized domains has been proposed, and blockchain-based DNS is currently the most promising solution. Combining the organizational structure and server architecture mentioned earlier regarding DNS, I can propose two requirements for decentralized domains: 1. The ownership/registration/use rights of decentralized domains should not be controlled by any centralized force. 2. The operation of decentralized domains should not rely on a few centralized servers but should operate in a decentralized manner on the blockchain.

Although decentralized domain services are still in their early stages, we have already seen several projects building towards this goal. For example, Namecoin was one of the first projects, released as early as 2011, but it has not seen widespread adoption. Handshake is another interesting project, positioned as a "decentralized domain naming and issuance authority." The two most prominent projects at this stage are likely Unstoppable Domains and ENS. Their decentralized domains have already achieved high sales, but they have not yet been widely used (mainly referring to mapping with IPFS's CID), primarily existing as NFTs symbolizing DID in wallets.

Conclusion

Technology itself is neutral, but the invention of a technology implies humanity's vision and aspiration for a better future. Dweb possesses characteristics such as censorship resistance, making it difficult for centralized forces to deprive others of their rights to exist and express themselves on the internet through the banning of IP addresses or domain names. I have two additional thoughts on this: the infrastructure itself does not have a value orientation, so censorship resistance is a characteristic rather than an advantage. How to utilize the censorship-resistant nature of Dweb determines whether this technology brings progress or disaster. Extreme content such as bloodshed and violence cannot be well controlled, which will inevitably lead to ethical and moral conflicts.

Secondly, we are still a long way from the maturity of Dweb. The maintenance and coordination costs mentioned in the article have not been resolved, and IPFS may not necessarily become the foundational protocol for Dweb. Although decentralized domains have already entered the market, the underlying domain service system has yet to be established. At the same time, the lack of web development tools like WordPress makes building Dweb very challenging. Nevertheless, IOSG remains hopeful for the future of Dweb.