If we can move the complexity to the infrastructure layer, making DApps should be much simpler.

Written by: w1nt3r.eth

Compiled by: TechFlow

Blockchain may live forever, but decentralized applications (dApps) are short-lived.

On Halloween 2024, I tried to open the dApps I used in 2021, and the results were horrifying: the domain name expired, the deployment was suspended, the page could not be found, and the service was unavailable.

Wait, aren’t these applications supposed to be decentralized? They’re supposed to be free-as-beer, free-as-speech, and censorship-resistant applications that don’t rely on centralized entities. They’re the applications that make Web3 the new internet.

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

Why does this happen? What’s the problem? And what can we do to change this situation?

So, what exactly is “dApp”?

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

"dApp" is short for "decentralized application". The concept is that you can make a web app using open technologies (such as HTML/CSS/JS) and host it on a decentralized and permissionless infrastructure (such as IPFS). dApp interacts with the blockchain through your wallet. You can get the latest data and send transactions without relying on a centralized company.

This makes dApps almost unstoppable. Free, permissionless, decentralized. This is the dream of those true punks.

Beautiful login page

However, most people don’t care about decentralization and permissionlessness. They care more about whether the application is useful (and whether the numbers go up).

Web3 developers quickly realized that they were competing for user attention with beautifully designed, fast, and engaging Web2 applications in the Web2 space, and decentralization did not give them much advantage in this battlefield.

Those who dig deep into the technology understand that blockchain is a true paradigm shift. But everything on the blockchain is “open source” and can be copied, so it becomes a commodity. There are no barriers to competition. 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. Across hundreds of millions of Uniswap deployments, users will choose what they trust (brand), is easily accessible (distribution), is used by everyone (network effects), and has a user-friendly interface (user experience).

Although I mentioned user experience last, it is not the least important. A bad user experience has negative consequences. Every e-commerce store owner knows that for every 100 milliseconds of latency you add, you risk losing 10% of your users. You can’t build a premium brand if your user experience is bad. You can’t retain users if your application is frustrating to use.

Deploying to Vercel is easier than deploying to IPFS

Doing good things is not easy

Even if most users aren’t interested in decentralization, true cypherpunks still care. Not because “everyone should be a fan of decentralization,” but because “it’s the right thing to do.” Decentralization empowers people and gives them autonomy, even when centralized entities become hostile or censored.

Here’s the thing. Making an app that is both decentralized and has a good user experience is not easy. But the reason it’s hard is because we (developers) have become lazy.

Dissecting BasePaint

Let's look at a typical "dApp" today and the technologies it relies on. I'll use my own development BasePaint as an example. In a sense, it should be a "Web3 dApp": it uses the blockchain (Base L2) and relies on the user's wallet to interact. But this is not enough to provide a good user experience, so I had to add some non-decentralized elements. In fact, a lot of them.

BasePaint's technical services

Here are the centralization techniques I had to adopt during development:

  • Domain name. I wanted it to be easy for users to find us and visit the website. Since browsers don't support ENS, I had to buy a domain name from a domain registrar and configure DNS to point to the right server.

  • Hosting service. I need to host the application (including HTML/CSS/JS files) somewhere and ensure that access is fast and stable. Although IPFS has great potential, most browsers do not support it, the gateway is slow, and the URL is not friendly.

(Have you ever tried typing QmRxM6Fz3jYBNLTNn59Whtj8uiFodC53Z5nEep6eSkwf8V on your phone?)

  • Databases. Blockchain is a good database in some cases, but not in all cases. For example, we store chat messages in a Postgres database because it is cheaper and faster. You can try to put it on the chain, but it will never be as fast as a centralized database.

  • Backend services. BasePaint also needs to perform some calculations that are not suitable for processing on Ethereum. For example, generating videos, synchronizing the cursor positions of multiple users, verifying chat permissions, etc. In addition, we also 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 the user's wallet. But that means users without a "Web3-enabled" browser won't be able to see anything. To complicate matters, there are subtle differences between different wallets' RPC providers. For example, QuickNode limits log queries to 10,000, while Alchemy uses its own compute units to limit requests. Using a wallet's 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 via the Painted event. You can reconstruct any canvas by querying the smart contract events. But imagine doing that on the BasePaint gallery page (we display hundreds of canvases!). To provide a smooth user experience, we run an indexer that tracks blockchain events and stores data in a way that facilitates fast querying.

  • Other services. We use Reservoir for secondary market data and cross-chain minting, Cloudflare as a CDN, R2 for video storage and caching, DataDog for logging, PostHog for analytics, and Neynar for looking up wallet addresses for Farcaster users. Each service has saved us weeks or even months of development time, but also made our application less decentralized. In addition, many tools lack sustainable business models and may shut down at any time.

  • Credit card. This question always makes me laugh. Did you know that most crypto SaaS products cannot be paid for with crypto? If my credit card balance is low or expired, my domains, databases, servers, RPC endpoints, and other SaaS products will go offline.

How to achieve decentralization of applications?

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

  • Abandoning centralized technology and building a hardcore dApp that relies entirely on decentralized services. While this may be feasible in projects such as Tornado Cash, for ordinary consumer products, this will bring user experience barriers that may deter most users.

  • Keeping the centralized application while developing a simplified dApp that relies only on the decentralized technology stack. This means maintaining two separate applications, increasing engineering effort and costs.

  • Adopt a "progressive enhancement" strategy. Start with a simplified dApp, and if the server is available, use it to increase speed. This requires strict management, and the time savings compared to the second option are not much.

  • Open source code, let users run it themselves (this is the direction we chose). But in fact, launching the entire system requires quite high software engineering capabilities, which is much more complicated than loading a page from IPFS.

All of the above options require considerable effort and are not the default choice. Look at any dApp tutorial or template and there is little mention of these issues. Decentralized application development doesn’t have to be this difficult. If we can move the complexity to the infrastructure layer, making dApps should be much simpler.

Maybe we should tackle those tough problems?

We can try to decentralize at the infrastructure level. For example, we could integrate ENS support into getaddrinfo, make IPFS natively supported in all browsers, and make IPFS as fast as the most advanced CDNs. We could also improve Ethereum's JSON-RPC to make it more useful for decentralized applications (dApps). But that's just the easy part.

To replace centralized databases and servers, we need to develop a range of technologies that don’t exist yet. Perhaps a distributed computing system based on zero-knowledge proofs (ZK) that rewards people for running code, or a super Ethereum that can efficiently execute general x86 instructions.

Additionally, we need to find decentralized solutions for all the services built around cryptocurrencies. We need to design new incentives — who will pay for these computing resources? In a truly decentralized system, the existing SaaS business model will not work. (But hopefully these services can be paid for in cryptocurrencies without a credit card.)

Beyond that, we must ensure that the developer experience for this new system is at least as good as that of the current centralized platforms, which have invested billions of dollars in engineering time and heavily invested in marketing to fill the web with tutorials trying to convince everyone that their approach is optimal.

Does this really matter?

"Your scientists are so focused on the feasibility of technology that they don't stop to consider whether it's appropriate to do so." - From (Jurassic Park)

But does the application layer really need to be decentralized?

Nouns shows us that maybe the decentralization of blockchain alone is enough. Nouns has a thriving ecosystem of apps that all interact with the same contracts. You can vote through Camp or Agora, it doesn’t matter, you just choose the interface you prefer.

In order to attract billions of users, cryptocurrency 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 the point of being irrelevant. For example, users can buy coffee with just a tap of their phone, and they don’t care whether it is USDC or the Visa network.

The market has found a local optimal solution:

  • Blockchain is decentralized as a base layer, secures trillions of dollars in assets, and provides 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 form a barrier to competition, but these applications still interact with the same blockchain.

Missing tools

I wish the balance would tip more toward decentralization. I wish it were as easy as clicking a link to run my own version of Nouns Camp or Agora locally. I wish we had tools that made it easy to build these decentralized apps without sacrificing user experience.

BasePaint is amazing. It's a self-sustaining ecosystem: artists create work, collectors buy it and profit on the secondary market, and owners can influence day-to-day affairs through voting. This model works, and we've distributed over a million dollars to creators this way.

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

in conclusion

Decentralized applications (dApps) seem to have lost their life because the advantages of "decentralization" are not currently what users care about, so developers need to adapt. We have stopped developing tools that are designed to make applications decentralized.

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

Unfortunately, however, the discussion on how to enhance the user interface has not received enough attention. The concept of dApp has been put on hold for the time being…