Is DApp Dead? The Dilemma of Decentralization and User Experience in Web3 Applications

Original Title: "dApps Graveyard"

Author: w1nt3r.eth

Compiled by: Deep Tide TechFlow

Perhaps the blockchain will endure forever, but the lifespan of decentralized applications (dApps) is quite short.

On Halloween 2024, I tried to open the dApps I used in 2021, and the results were terrifying: domain names expired, deployments paused, pages not found, services unavailable.

Wait, shouldn’t these applications be decentralized? They were supposed to be applications that do not rely on centralized entities, free like beer, and as free and censorship-resistant as speech. They are the applications that make Web3 the new internet.

But these applications have almost all disappeared, and most of the ones I used two years ago no longer exist. Their "ghosts" may still linger somewhere on the blockchain, as long as you can find the right contract address and guess the correct call data.

Why did this happen? Where is the problem? What can we do to change this situation?

So, what exactly is a "dApp"?

Let’s flip through the ancient texts we found from prehistoric times (2016).

"dApp" is short for "decentralized application." The concept is that you can create a web application using open technologies (like HTML/CSS/JS) and host it on decentralized and permissionless infrastructure (like IPFS). dApps interact with the blockchain through your wallet. You can fetch the latest data and send transactions without relying on centralized companies.

This makes dApps almost unstoppable. Free, permissionless, decentralized. This is the dream that those truly pursuing the punk spirit aspire to.

Beautiful Landing Pages

However, most people do not care about the decentralized and permissionless features. They are more concerned with whether the application is practical (and whether the numbers can go up).

Web3 developers quickly realized that they were competing for users' attention with beautifully designed, fast, and engaging Web2 applications, and decentralization did not provide them with much of an advantage on this battlefield.

Those who understand the technology know that blockchain is a real paradigm shift. But everything on the blockchain is "open source" and can be copied, so it becomes a commodity. There are no competitive barriers. Anyone can deploy a Uniswap contract anywhere. In fact, anyone can create their own L2!

The real differentiators are brand, distribution channels, network effects, and user experience. Among the billions of Uniswap deployments, users will choose those they trust (brand), that are easily accessible (distribution), that everyone is using (network effects), and that have a user-friendly interface (user experience).

Although I mentioned user experience last, it is not the least important. A poor user experience can have negative effects. Every e-commerce store owner knows that every additional 100 milliseconds of delay can result in a 10% loss of users. If the user experience is poor, you cannot build a premium brand. If your application frustrates users, you cannot retain them.

Deploying to Vercel is easier than deploying to IPFS

Doing Good is Not Easy

Even if most users are not interested in decentralization, true crypto punks still care. It’s not that "everyone should be a decentralization fanatic," but because "it’s the right thing to do." Even when centralized entities become hostile or face censorship, decentralization empowers people and grants them autonomy.

That’s where the problem lies. Creating an application that is both decentralized and has a good user experience is not easy. But the reason for the difficulty is that we (developers) have become lazy.

Analyzing BasePaint

Let’s take a look at a typical "dApp" today and the technologies it relies on. I will use my own developed BasePaint as an example. In a sense, it should be a "Web3 dApp": it uses the blockchain (Base L2) and relies on users' wallets for interaction. But that alone is not enough to provide a good user experience, so I had to add some non-decentralized elements. In fact, I added quite a few.

Technical service composition of BasePaint

Here are the centralized technologies I had to adopt during development:

• Domain name. I wanted users to easily find us and access the website. Since browsers do not support ENS, I had to purchase a domain name from a registrar and configure DNS to point to the correct server.
• Hosting service. I needed to host the application (including HTML/CSS/JS files) somewhere and ensure fast and stable access. While IPFS has great potential, most browsers do not support it, the gateways are slow, and the URLs are not user-friendly.

(Have you tried typing QmRxM6Fz3jYBNLTNn59Whtj8uiFodC53Z5nEep6eSkwf8V on your phone?)

• Database. The blockchain is a decent database in some cases, but it is not suitable for all scenarios. For example, we store chat messages in a Postgres database because it is cheaper and faster. While it is possible to try to put it on-chain, it will never be as fast as a centralized database.
• Backend services. BasePaint also needs to perform some computations that are not suitable for handling on Ethereum. For instance, generating videos, synchronizing multiple users' cursor positions, verifying chat permissions, etc. Additionally, we need to protect some sensitive information, such as database connection credentials and private tokens.
• Ethereum JSON-RPC provider. In theory, we could access the blockchain through users' wallets. But this means that users without a "Web3-supported" browser will not see anything. More troublesome is that there are subtle differences between RPC providers for different wallets. For example, QuickNode limits log queries to 10,000 entries, while Alchemy uses its own computation units to limit requests. Using a wallet's RPC means dealing with these subtle differences.
• Indexer. Storing data on the blockchain is costly. BasePaint solves this problem by not storing pixels in the contract. Instead, it sends all necessary data through Painted events. You can reconstruct any canvas by querying smart contract events. But imagine doing this on the BasePaint gallery page (where we showcase hundreds of canvases!). To provide a smooth user experience, we run an indexer to track blockchain events and store data in a way that allows for quick querying.
• Other services. We use Reservoir to obtain secondary market data and perform cross-chain minting, Cloudflare as a CDN, R2 for video storage and caching, DataDog for logging, PostHog for analytics, and Neynar to find Farcaster users' wallet addresses. Each service saves us weeks or even months of development time, but it also makes our application less decentralized. Moreover, many tools lack sustainable business models and could shut down at any time.
• Credit card. This issue always makes me laugh and cry. Did you know that most crypto SaaS products cannot be paid for with cryptocurrency? If my credit card balance is insufficient or expired, my domain name, database, server, RPC endpoints, and other SaaS products will go offline.

How to Achieve Decentralization in Applications?

As a Web3 developer, the options I currently see are:

• Abandon centralized technologies and build a hardcore dApp that relies entirely on decentralized services. While this may work for projects like Tornado Cash, it poses user experience barriers for ordinary consumer products, potentially deterring most users.
• Retain the centralized application while developing a simplified dApp that relies solely on a decentralized tech stack. This means maintaining two separate applications, increasing engineering workload and costs.
• Adopt a "progressive enhancement" strategy. Start with a simplified dApp and use the server to enhance speed if available. This requires strict management and does not save much time compared to the second option.
• Open source the code and let users run it themselves (this is the direction we chose). But in reality, launching the entire system requires considerable software engineering skills, which is much more complex than loading a page from IPFS.

All of the above options require significant effort and are not the default choice. Looking at any dApp tutorial or template, these issues are rarely mentioned. In fact, developing decentralized applications does not have to be this difficult. If we can shift the complexity to the infrastructure layer, creating dApps should be much simpler.

Perhaps we should tackle those tricky problems?

We can try to achieve decentralization at the infrastructure level. For example, integrating ENS support into getaddrinfo so that all browsers can natively support IPFS and improving IPFS's speed to match the current state-of-the-art CDNs. We can also enhance Ethereum's JSON-RPC to make it more practical for decentralized applications (dApps). But that’s just the simple part.

To replace centralized databases and servers, we need to develop a series of technologies that currently do not exist. Perhaps we need a distributed computing system based on zero-knowledge proofs (ZK) that rewards users for running code, or a super Ethereum capable of efficiently executing general x86 instructions.

Additionally, we need to find decentralized solutions for all services built around cryptocurrencies. We need to design new incentive mechanisms—who will pay for these computing resources? In a truly decentralized system, existing SaaS business models will not work. (But hopefully, the costs of these services can be paid with cryptocurrency, without the need for credit cards.)

Beyond that, we must ensure that the development experience of this new system is at least as good as current centralized platforms. Those platforms have invested billions of dollars in engineering time to refine and have spent heavily on marketing to flood the web with tutorials, trying to convince everyone that their solutions are optimal.

Does it really matter?

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." — From "Jurassic Park"

But does the application layer really need decentralization?

Nouns show us that perhaps just the decentralization of the blockchain is sufficient. Nouns have a thriving application ecosystem, all applications interact with the same contract. You can vote through Camp or Agora; it doesn’t matter, you just need to choose the interface you prefer.

To attract billions of users, cryptocurrencies may need to become a seamlessly integrated component of existing systems. This means that the ideal crypto experience is one where users don’t even know they are using cryptocurrency because it has been abstracted to an inconsequential level. For example, just tapping your phone to buy coffee, whether using USDC or the Visa network, is irrelevant to the user.

The market has found a local optimum:

• The blockchain as a foundational layer is decentralized, ensuring the security of trillions of dollars in assets and providing strong support for ownership and censorship resistance.
• The application layer is centralized. Companies develop centralized applications to provide the best user experience. Their closed-source systems create barriers to competition, yet these applications still interact with the same blockchain.

Missing Tools

I hope this balance can tilt more towards decentralization. I wish it could be as simple as clicking a link to run my own local version of Nouns Camp or Agora. I hope we can have tools that make building these decentralized applications simple without compromising user experience.

BasePaint is stunning. It is a self-sustaining ecosystem: artists create works, collectors buy and profit in the secondary market, and owners can influence daily affairs through voting. This model works, and we have distributed over a million dollars to creators through this method.

However, the weakest link in the entire system is our team. Maintaining the application requires a lot of effort, such as fixing bugs and improving user experience. At the same time, we are also working to make the system more decentralized, such as making the application easier to self-host and abandoning permission controls instead of setting barriers.

Conclusion

Decentralized applications (dApps) seem to have lost their vitality because the advantages of "decentralization" are not currently what users care about, so developers need to make adjustments. We have stopped developing tools aimed at making applications decentralized.

Fortunately, the underlying infrastructure of blockchain is more robust than ever. The foundational technologies are solid, and the development roadmap is promising. We actually have the opportunity to build a global computing platform.

However, regrettably, discussions on how to enhance user interfaces have not received enough attention. The concept of dApps has been temporarily shelved…