Four levels of decentralization

The recent Facebook outage has made many web2 users realize how fragile the foundation of their core Internet services is.

Most web2 services are centralized by default, but Facebook’s operations have proven to be centralized, so that when one part of the system fails, engineers are blocked from everything—even debugging tools.

In the incident report released by a member of the Facebook engineering team, there is a particularly persuasive paragraph:

…When our engineers worked hard to figure out what happened and why it happened, they faced two huge obstacles: First, they could not access our data center through our normal means due to their network failure, and secondly, DNS was completely The loss prevents us from using many of the internal tools normally used to investigate and resolve such outages.

The Internet is not always like this. In the early days, it was more decentralized. Since there is no AWS, Azure or Google Cloud platform, most of the websites run on a separate server. This means that a single outage cannot interrupt millions of services in one fell swoop, and a rule change from one provider cannot enforce a large-scale review.

Today, Google, Microsoft, and Amazon co-host 60% of the Internet, and Amazon alone accounts for 33%, including the most popular and most dependent web2 services such as Netflix, Spotify, Twitch, Facebook, Slack, and Reddit—not to mention Talk about important services such as Internet banking and government portals.

Why does it become like this? Developers are taught to do things in a centralized way-using the APIs of these companies to deploy AWS. Centralized services are tools for making money, and they have the greatest marketing influence.

Developers can choose whether to contribute to the continued monopoly of our Internet, or to seek new options to prevent downtime, resist censorship, and capture the original spirit of the Internet. In this article, we will learn about some popular web2 and web3 architectures, and how they achieve or fail to achieve decentralization.

Everything is centralized

When both the back-end and the front-end of an application are centralized, it has the most failure points of any architecture in the list. Both the back-end and the front-end use a server, even if they remain online, if the API it depends on fails, the entire application may go down.

An example: Stripe . Its PHP is hosted on AWS and connects to the Google authentication API to log in.

Centralized server for storing data on Arweave

Arweave can be run like any other database-it can even be queried using graphQL or ardb, which makes it easy for applications to quickly load what they need from the complete history of blockweave transactions. If the centralized application server that stores data on Arweave fails, the application data can still be queried from Arweave as if its API is still running.

An example: ArDrive . The main back-end data is stored on Arweave, and some services and front-ends are provided by Google Cloud and Fastly.

Decentralized backend, centralized frontend

When the back-end of the application is served by the blockchain, even if the front-end is a point of failure, it will not go wrong. Whether it is vulnerable to attack simply because it is hosted on a centralized server, or because the entity hosting it can respond to deletion requests or censor it in other ways, it can still be said that it is still a “suffocating throat “. This arrangement Uniswap common DeFi and other applications.

An example: Uniswap . Earlier this year, Uniswap Labs changed the front end to hide about 100 tokens, making headlines. In this case, the front-end is easier to rescue than the back-end, and since Uniswap and other web3 applications often use smart contracts for this purpose, permanent network archivists are able to clone the previous user interface of Uniswap and host it permanently on Arweave .

Decentralized backend, decentralized frontend

Applications with smart contract backends and frontends stored on Arweave are one of the most powerful and censorship-resistant architectures. The Arweave network is composed of hundreds of incentive nodes, never downtime, and reliably hosts a large number of front-ends, from popular DeFi applications to our own permanent podcasts and permanent blogs.

ArGo got special praise here because it provides a user-friendly way to continuously deploy the front-end from the GitHub repository and attach HNS and DNS domain names.

An example: permablog , its entire back end is run by the SmartWeave contract, and the front end can also be accessed through its txid and a beautiful DNS ( There is also an HNS domain name to provide additional flexibility.

Other incentives

Handshake domain name. Handshake (HNS) is “a decentralized, permissionless domain name protocol in which each peer is verifying and is responsible for managing the root DNS domain name zone.” Although it describes itself as an experiment, the results are already visible and verifiable.

Multiple/dedicated gateways. Gateway is the last ongoing project on the scale of Arweave. A popular project may (accidentally) perform a DDoS attack on a single gateway-we cover this here-but this can be avoided by using any of the following methods:

  • Arweave Multihost provides a way for applications to switch to a backup gateway in the event of a failure
  • Tools like Vatex can start a dedicated gateway for your project.

Meson network. As part of the CDN and global cache layer supported by Arweave, Meson provides the functionality of more than 40,000 nodes.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Leave a Reply