The Web 3.0 architecture is not only decentralized but also modular

Author: Xiang, W3.Hitchhiker

1. Web 2.0 Architecture

Taking the decentralized exchange Binance as an example, Binance allows users to trade various tokens.

Binance is a Web 2.0 application; the architecture sounds simple, but in reality, a lot of work is required during development.

Users need to connect their devices to the internet through a network operator, then open a browser, enter Binance's domain name, and access Binance's website via the HTTP protocol.

Binance requires users to register and log in to the platform using their mobile phone or email.

Then, Binance itself needs a place to store basic data such as user registration information, trading limits, transaction history, and open orders. This requires setting up a database for storage and continuous updates.

Secondly, the backend programming languages (like Node.js, Java, or Go) determine all of Binance's business logic. A server needs to be set up to deploy the backend and run the backend logic. For example, what happens when a new user registers, trades, or places an order?

Additionally, frontend programming languages (JavaScript, HTML, and CSS) determine Binance's UI logic. A server needs to be set up to deploy the frontend and run the frontend interaction logic. For example, what does the website look like? What happens when users interact with each button on the page?

When you write a trade on Binance, all these elements integrate and interact. You interact with its frontend, the frontend interacts with the backend, and the backend interacts with its database. All this code is hosted on a centralized server and is fed back to users through internet browsers, with all control of the centralized server in the hands of Binance.

This is a simple summary of how most Web 2.0 applications work today, though the reality is more complex.

2. Web 3.0 Architecture

Taking Uniswap as an example, Uniswap is a decentralized exchange that allows users to freely add and trade various tokens.

Uniswap is a Web 3.0 application; the architecture sounds complex, but the actual development implementation is quite simple.

First, users need to connect their devices to the internet through a network service provider, similar to telecom or mobile services. (Decentralized network service providers, IoT: Helium)

Then, users access the application through a browser or operating system (Decentralized browsers or operating systems: Brave).

Users interact with the server through the browser, which requires support from protocols (traditionally HTTP, but can be replaced by IPFS through content addressing).

Uniswap requires users to log in using a private key and wallet (**similar plugins and wallets: Metamask, Tokenpocket, Math, *Brave Wallet), and a unified DID is also a future direction (similar to ENS, etc.*).

Wallets need to connect to blockchain nodes, which requires node servers to provide them. This means needing corresponding blockchain nodes or using professional node service providers like Infura/Alchemy. (Decentralized node service providers are also a trend: Pocket)

What does the Uniswap website look like, and what happens when users interact with each button on the page? Again, JavaScript, HTML, and CSS are used to implement Uniswap's UI logic.

However, Web3 does not require setting up servers to deploy and run frontend interaction logic. This frontend data can be stored in decentralized storage networks (like Filecoin, SWARM, AR, etc.).

Here is the official IPFS link for Uniswap; this solution does not require setting up a frontend server, and users can still use it normally.

ipfs://bafybeiagkgmmhux6fswdoedmwqqsvt5arjivl35wuk25jljb2yqgn7njgu/#/swap

The above link starts with ipfs://, so a browser that supports IPFS resolution is needed to open it (Brave, Opera).

Moreover, this link is not human-readable, so a domain service is needed to map the corresponding domain to this link, such as uniswap.eth. (Decentralized domain services: IPNS, ENS, etc.)

Of course, IPFS only supports access through HTTP-compatible gateways.

When website traffic is high, a more flexible bandwidth market is needed ------ CDN acceleration networks. (**CDN services, IPFS, *Filecoin retrieval market*)

Uniswap's business logic is determined by blockchain smart contract languages like Solidity. Since it runs in the EVM environment, Uni does not need to set up servers to deploy backend business logic (blockchains supporting smart contracts, ETH, etc.).

However, what exchanges need to display is not just business logic; they also need to show historical price curves, trading volumes, etc. This historical data cannot be obtained through smart contracts. If the project team needs to display it, they still need to set up servers, run a node, and filter the data from the blockchain to save it in Uni's own database. Therefore, Web3 needs a solution for indexing chain data. (Chain data indexing platform: The Graph)

The Graph provides a chain data indexing solution that allows users to query data easily. In The Graph, you can define which smart contracts need to be indexed, which events and function calls need to be listened to, including the state at the time of calling and generating, and you can specify how to convert incoming events into frontend logic that can be processed.

On-chain data will be saved by dedicated Graph indexing mining nodes, which will provide APIs for user page calls. The project team does not need to set up servers; only the indexing nodes need to set up servers to run indexing data mining nodes.

By indexing blockchain data, The Graph allows us to query on-chain data in application logic with almost no latency.

For example, the presentation of Uniswap trading information is generated through The Graph.

If Uniswap wants to present more, it needs to bridge off-chain price data to on-chain data, which requires a bridge between off-chain and on-chain data (decentralized oracles: Chainlink).

According to the above development logic, Uniswap has effectively launched a Web 3.0 application, but the actual implementation cost is much lower than that of developing a Binance exchange because:

1. Uniswap does not require users to bind an email or phone; they can log in directly through a wallet, and Uni itself does not need to store this information.
2. Uniswap does not need to set up a frontend server; users can access the frontend page through IPFS or AR storage.
3. No need to set up a backend server. The backend logic runs on smart contracts.
4. No need to set up a database; historical data and database operations are implemented through The Graph.

Professionals do professional things; Uniswap only needs to design and implement its own logic, while other logic is supported by modular Web3 infrastructure.

Thus, Uniswap not only achieves complete decentralization but also serves as a simple application case of Web3 modularization.

The core of Web3 is trustless interaction of value. Modular development can not only achieve trustlessness but also improve operational efficiency; the trend of modularization will be applied across various industries.

What has been mentioned earlier is the modularization of the Web3 network architecture, which enhances the generative efficiency of Web3. Now, how can we improve the efficiency of Web3 production relations (Web2's production relations are mainly company-based, Web3's generative relations are DAOs, and the modularization of DAOs is also a future trend). DAOs rely on blockchains, which are also moving towards modularization, and similarly, the metaverse, games, etc., are following suit.

The arrival of the modularization era will bring higher efficiency and better services. W3Hitchhiker will continue to follow the modularization path of crypto.