If we can shift complexity to the infrastructure layer, creating DApps should be much simpler.

Written by: w1nt3r.eth

Compiled by: Deep Tide TechFlow

Perhaps 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 pursued by those who truly embody the punk spirit.

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 user 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 what they trust (brand), what is easily accessible (distribution), what everyone is using (network effects), and what has 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 high-end 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.

This is 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 some 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 incorporate 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, gateways are slow, and 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 example, 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 can access the blockchain through users' wallets. But this means that users without a "Web3-supporting" 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 wallet RPC means dealing with these subtle differences.
• Indexer. Storing data on the blockchain is expensive. 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 display 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. Additionally, many tools lack sustainable business models and could shut down at any time.
• Credit cards. 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, which may deter 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 leverage servers to enhance speed when available. This requires strict management, and the time saved is not much 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 quite a high level of software engineering capability, which is much more complex than loading a page from IPFS.

All of the above options require considerable 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 complexity to the infrastructure layer, creating dApps should be much simpler.

Maybe 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 speed to match 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 range 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 cryptocurrency. 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 for with cryptocurrency, without the need for credit cards.)

Furthermore, we must ensure that the development experience of this new system is at least as good as that of 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.

Is This Really Important?

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

But does the application layer really need to be decentralized?

Nouns show us that perhaps mere decentralization of the blockchain is sufficient. Nouns has a thriving application ecosystem where 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, cryptocurrency may need to become a seamlessly integrated component of existing systems. This means the ideal crypto experience is one where users don’t even realize they are using cryptocurrency because it has been abstracted to an inconsequential degree. For example, being able to buy coffee with just a tap on your phone, regardless of whether it’s USDC or the Visa network being used, is not a concern for the user.

The market has found a local optimum:

• The blockchain serves as a decentralized foundational layer, 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 version of Nouns Camp or Agora locally. 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 purchase 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 in this way.

However, the weakest link in the entire system is our team. Maintaining the application requires a significant amount of effort, such as fixing bugs and enhancing 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 thresholds.

Conclusion

Decentralized applications (dApps) seem to have lost their vitality because the advantages of "decentralization" are not currently a concern for users, and thus developers need to make adjustments. We have stopped developing tools aimed at decentralizing applications.

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

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。