Web 3.0 Is Too Complicated

For a truly decentralized future, we have to resist the temptations of instant user interface gratification and extremely simple API integrations that depend on data centers.

AccessTimeIconJan 3, 2022 at 4:57 p.m. UTC
Updated Jun 14, 2024 at 4:13 p.m. UTC

One of the most important goals and benefits of the Web 3.0 revolution is for the world’s information technology ecosystems to re-decentralize. The internet, when it started, was a highly decentralized system. Centralized systems have, in time, layered themselves very successfully across this decentralized ecosystem.

The economics of the software business and the power of network effects is the foundation for the centralization of the Web 2.0 era, and they are helped along by liberal use of dark patterns on users as well (i.e. Web 2.0 tricks to get people to give up personal data). If we are not careful, we risk repeating some of the same patterns in the Web 3.0 era.

Paul Brody is EY’s global blockchain leader, and a CoinDesk columnist.

I see two major risks to a sustainably decentralized future. The first, and by far the biggest, is the immense complexity that’s involved in building good blockchain interaction tools. Interacting with distributed systems is complicated, all the more so when you layer in additional requirements like managing multiple signatures or using zero knowledge proofs to maintain privacy.

The easiest way to manage that complexity today, is to do so through an application programming interface (API). Want to mint a token? There’s an API for that. Want to get some transaction history? There’s an API for that, too. Those APIs, in turn, write to and from the blockchain, handling all the complexity that is involved. APIs simplify building blockchain tools, but nearly all of them rely upon centralized software and infrastructure. In other words: Extensive use of APIs will lead to the centralization of many critical blockchain functions.

EY blockchain infrastructure is no different, and it not only makes heavy use of API-based services from other companies, but also offers services as APIs to enterprise users that would otherwise find all that complexity too much to manage. While I know that APIs will certainly have a role to play in the future, especially when it comes to interfacing the Web 3.0 world with the Web 2.0 world, I’d prefer to see a future where many applications run and interact natively in the blockchain ecosystem. We have our own ongoing priority inside of EY to keep putting more genuinely decentralized infrastructure in our blockchain business, and I hope our peers do, too.

To avoid excessive centralization through dependency on APIs and SaaS (software as a service) applications, the most important work is for developers to build libraries and tools that make it easy to access Web 3.0 ecosystems directly and keep code up to date without having to rely upon APIs. That sounds easy but it is actually very hard. I have discovered in my career how fiendishly difficult it is to manage the distribution of software and how easy it is to maintain control and consistency through a software-as-a-service API. Some projects like Stereum, funded in part by the Ethereum Foundation, are a good start because they make starting and running your own node at home as easy as installing any other piece of package software.

A second big concern I have is that in our efforts to build Web 3.0 offerings that run and perform just like Web 2.0 offerings, we’re going to end up centralizing Web 3.0 to a high degree. Protocols that support “decentralized” compute and file storage are designed to reward the participants with the most highly available, high-performing systems. Those are usually located in centralized data centers run by large companies.

This is essential if we want Web 3.0 applications to be as fast and responsive as Web 2.0 applications. But is that a useful objective? The most successful new technologies address new workloads rather than migrating old ones on to new platforms. Web 3.0 is better at some very specific things, like moving value with tokenization and enabling complex integrations with smart contracts.

Perhaps we can leave the synchronous interactions and instant user interface gratification to the Web 2.0 world? The “30″ in “net 30″ on a corporate invoice refers to days, not milliseconds. For most enterprises, business and financial applications, a cycle time of a few minutes to a day is more than adequate. Maybe we should leave gaming and virtual reality for Web 2.0?

If we want a truly distributed and decentralized future, we will have to resist the twin temptations of instant user interface gratification, the kind that can be delivered only by always-on data centers, and extremely simple API integrations. The payoff will be a fairer, more competitive and more resilient financial and technology ecosystem.

The views reflected in this article are my own and do not necessarily reflect the views of the global EY organization or its member firms.


Please note that our privacy policy, terms of use, cookies, and do not sell my personal information has been updated.

CoinDesk is an award-winning media outlet that covers the cryptocurrency industry. Its journalists abide by a strict set of editorial policies. In November 2023, CoinDesk was acquired by the Bullish group, owner of Bullish, a regulated, digital assets exchange. The Bullish group is majority-owned by Block.one; both companies have interests in a variety of blockchain and digital asset businesses and significant holdings of digital assets, including bitcoin. CoinDesk operates as an independent subsidiary with an editorial committee to protect journalistic independence. CoinDesk employees, including journalists, may receive options in the Bullish group as part of their compensation.

Paul Brody

Paul Brody is Global Blockchain Leader for EY (Ernst & Young). Under his leadership, EY is established a global presence in the blockchain space with a particular focus on public blockchains, assurance, and business application development in the Ethereum ecosystem.

Read more about