Decentralize Some of the Things

Three Things #164: April 6, 2025

As a builder, there’s a clear tension between centralization and decentralization. Decentralization is a powerful tool and it’s tempting to use, but its use comes at a heavy cost.

When I joined the blockchain space and learned about the concept of decentralization, my first instinct was to “Decentralize All the Things.” I even used this as the mantra for multiple projects, proudly wore the message on stickers and T-shirts, etc. It’s a tempting idea: decentralization is a powerful weapon, and when you first learn how to wield it, it’s natural to want to use it everywhere. To a decentralization hammer, everything looks like an overly-centralized nail.

To be clear, there are plenty of valid use cases for decentralization. One of the first ones on the Internet was file sharing via tools and technologies like Napster and Bittorrent. The other obvious use case is money, a la Bitcoin. The power to issue money, to control when and how and to whom it’s issued, to determine who gets to transact and on what terms, etc., shouldn’t be in the hands of any person or any single organization, or even any government. There’s a small list of other applications where powerful decentralization makes sense: property registers, DAO governance, maybe social media.

This issue is about all the other use cases, i.e., the ones where decentralization is a bad idea. Decentralization has its limits and its downsides. As I’ve learned over the years, there’s a time and a place for decentralization. It is a superpower, but like all superpowers, it must be used sparingly.

I still see far too many intelligent, well-intentioned people and teams making the mistake of trying to decentralize things that should never and can never be decentralized. Here are some of those things.

Thing #1: Storage 💾

I struggle to keep track of the number of decentralized file storage projects. These include Swarm, Sia, Storj, Filecoin, and Greenfield, to name but a few. These projects, especially Filecoin, raised massive amounts of money and spent years developing very complex protocols and infrastructure to support them, to varying degrees of success. None of these projects or protocols has achieved its stated goal, which is to compete with the likes of AWS, GCP, and Azure in the storage market. They collectively haven’t even put a dent in this market. By my admittedly rough estimation Filecoin, the largest network, currently has around 2% of the data stored by AWS. This number grew rapidly in the network’s earliest days, but it’s remained flat for the past year.

The latest project which announced it’s working on the problem is Walrus, from the Sui team. I haven’t followed the project very closely, mostly because I just can’t take seriously new attempts to solve this unsolvable problem, but I’ve spoken to experts about it and they assure me that Walrus, too, is bound to fail for the same reasons the other projects have. And they’ve just raised a cool $140M dollars which will inevitably go down the toilet. (Crypto never learns.)

Why is this such a hard problem? As with most of the examples here, the answer is actually very simple. Decentralized storage doesn’t work for the simple reason that reliability matters above all in file storage, and decentralized networks aren’t built for reliability. They’re unable to guarantee that a file, once stored, remains where it’s supposed to be, and can always be quickly and easily accessed thereafter. In my experience projects working on decentralized storage in spite of this tend to cloak their answers in smoke and mirrors rather than directly and honestly addressing this fundamental flaw in their design.

When you store a file on a cloud service like AWS, it gets written to a physical server somewhere. Then redundant backups are made and stored in other places, just in case something happens to the original copy. The provider can be certain that the file doesn’t move or disappear for the simple reason that they operate the infrastructure themselves.

Of course, decentralized networks are fundamentally different. Nodes naturally come and go, at unpredictable times and in unpredictable ways. Effective, useful decentralized networks therefore need to be Byzantine Fault Tolerant, which means they’re designed to accommodate these failures and abrupt, unpredictable changes in network topology. In practice what this means is that, once you write a file onto a storage node somewhere, you have no hard guarantees that it will still be there tomorrow.

This is where the complexity, and the smoke and mirrors begin. Various projects have all kinds of clever protocols for working around this problem. Filecoin requires data owners to sign long-term contracts with individual storage providers. Many of these networks have validators that periodically perform random checks that data is where it’s supposed to be, and they impose penalties on storage providers who fail to respond to these checks. These systems of economic checks and balances work up to a point, but they’re complex and fragile, and they still fail to address the fundamental disconnect: that, penalties or not, files can still disappear randomly, and the network can’t provide any hard guarantees to the contrary.

Yes, redundant copies can be made. Decentralized storage networks can even do more sophisticated things like RAID-style striping of files, ensuring that if a single node goes offline, or even if multiple nodes go offline, the file can still be reconstructed from existing data. But if a node disappears, all of the data it stored needs to be redistributed across the network, which is an expensive and slow process.

There are probably a few niche use cases where decentralized storage might make sense, and might be competitive with centralized, cloud-based options. The Internet Archive and a few other organizations focused on preserving important data for the very long term use Filecoin for archival purposes. It might make sense for certain kinds of “cold storage” data which is low-value and accessed very infrequently, and for applications that are extremely cost-sensitive and okay with enormous latency.

But for the vast majority of data and for most applications, this sort of solution will never make sense, and we should give up trying. The applications I’m aware of that do attempt to build on decentralized storage networks inevitably end up building, or using, centralized storage layers on top of them to increase performance, which is hypocritical. Centralized cloud providers all offer storage that’s relatively cheap and works quite well. Use them, and if you care about things like redundancy or censorship resistance you can store your files in multiple places, or store them yourself.

Thing #2: Messaging 💬

Chat apps are another attractive target for decentralization. The logic seems simple enough: we use these apps more than just about any others, and each is run by a large, centralized, unaccountable, for profit company. They have access to all of our messages, and when they tell us their apps and services are E2E encrypted, we have to trust them since, with very few exceptions, we can’t see or audit the source code.

These companies and apps constantly engage in bad behavior such as unnecessarily censoring and deplatforming users, and when this happens they have no accountability and we have zero recourse. All of the data—our data—live within a walled garden, and if the apps have any APIs at all they tend to be extremely limited. In effect we can only access the data—our data—at their mercy. Perhaps worst of all, we’re forced to use a dozen different chat apps because the companies behind the apps have zero incentive to open up the data and APIs, to make them interoperable or allow other developers to do this.

Believe me, I would like nothing more than to decentralize apps like Telegram. But the problem is a hard one, much harder than most people realize. As with file storage, the reason is quite simple.

Messaging requires a few simple pieces of infrastructure. One is PKI: there needs to be a registry of users, usernames, and keys, such that users can find one another, and can know that the person they’re talking to is who they say they are. This is very straightforward to build in a centralized manner: just put all of the information in a single, centralized database table, and gate reads/writes/updates to this data with an API.

But doing this in a decentralized way is much harder. Decentralized table structures do exist, but they’re complex and prone to attack. Blockchains can help solve the PKI problem—after all, each blockchain is a list of accounts (public/private key pairs), and we now have human-readable names on blockchain as well—but blockchains are also slow and expensive, which severely harms the UX, including onboarding, which is critical.

An even harder problem is message delivery. This, too, is straightforward in a centralized network. You set up one or more servers, and shard user accounts across these servers. When a new message arrives, it’s routed to the home server for the user and saved there until the user comes online to download their new messages.

But what do you do in a decentralized network? In such a network, by definition, there are no servers. In the ideal topology every node is an identical peer. How, then, do you route a message from user A to user B? How does the network discover the route? And what happens if user B isn’t online when user A tries to message them—or, for that matter, if any intermediate node in the route goes offline? You can require or expect that nodes never go offline, i.e., that each user runs a server in the cloud, but the reality is that no one wants to run a server. What’s more, how do you incentivize nodes to behave honestly, to not censor messages, etc., and how do you prevent spam and sybil attacks?

There are answers to each of these questions, but they’re not simple. Each is an area of active research in distributed systems, and the unfortunate outcome is, once again, severely reduced UX. In my experience, decentralized networks are very, very slow and frustrating to use. It can take on the order of minutes to load messages. Different decentralized messaging networks and protocols including Matrix, Holepunch, and Waku have different approaches to solving the routing and storage problems, but they inevitably also introduce points of centralization, such as intermediate servers or relays that can fail, misbehave, censor messages, deplatform users, etc.

The situation for decentralized messaging apps is thus quite similar to that of file sharing apps: lots of time and money have been spent building these networks, but basically no one is using them because the UX is so much worse than it is for the centralized alternatives. It’s hard enough to convince your grandma to use Whatsapp or iMessage, good luck convincing her to use your spiffy new blockchain-based messaging app.

I do believe that we’ll eventually figure this out, that we’ll eventually find the right tradeoff between UX and decentralization, but we’re not there yet, not even close. Delivering better UX will inevitably involve tradeoffs, and a purist approach simply won’t work. This is an area that needs a lot more exploration and research.

Thing #3: AI 🦾

It may sound contrarian coming from someone working full time for a project that’s focused on decentralized AI, but AI is another example of a technology that doesn’t lend itself well to decentralization, at least in its present form.

The most obvious example is model training. Training requires vast compute resources: it’s estimated that modern frontier models cost upwards of $100M to train. Most of that cost pays for compute running on powerful modern GPUs. Since the price tag is so astronomical and the resource demands are so high, it’s tempting to decentralize training. Rather than building a single, centralized facility, why not distribute training among thousands or even millions of GPUs around the world? Indeed, there are millions of GPUs connected to home computers, especially gaming rigs, that are underutilized. (We researched this topic at Spacemesh, which does exactly this for initialization.)

But most people fail to understand the challenges associated with decentralized training. For one, there’s bandwidth. GPUs in modern HPC datacenters are interconnected with bandwidth on the order of tens of terabits per second. This is around 10,000-100,000x more bandwidth than even the fastest home Internet connections, and the latency is also orders of magnitude lower. For another, there’s the fact that training algorithms are designed to run across homogeneous clusters of GPUs. While it’s true that there are millions of underutilized GPUs in the world, they’re a hodgepodge of different models and architectures, which also makes training difficult.

There are a number of projects that are trying to do decentralized training, using blockchain technology to manage incentives. But, on top of the bandwidth, latency, and hardware issues just outlined, blockchains are also incredibly poorly suited to AI tasks: they typically don’t even handle floating point operations, whereas AI requires computing massive arrays of floating point numbers. What’s more, blockchain requires computation to be deterministic, while AI isn’t designed to be deterministic. Ask the same question twice, request the same task twice, and you’ll get two very different answers. Train on the same data twice and you’ll get a different model. The GPUs used for training and inference, and the tools built on top of them, aren’t even designed to be deterministic!

Blockchain and decentralization aren’t well suited to HPC tasks for the same reason that they’re not well suited to decentralized storage: they’re designed to be slow, expensive, and robust. By contrast, these applications require infrastructure that’s extremely fast and cheap, and doesn’t need to be 100% accurate all the time. The impedance mismatch here is enormous. (To be fair, there have been some recent breakthroughs in decentralized training, and it may eventually actually work, but we’re not there yet.)

Okay, so if all of this is true, then why is NEAR becoming the “blockchain for AI” and why am I excited about decentralized AI? As with the other applications discussed above, there are specific use cases within AI where decentralization makes sense. While decentralized infrastructure isn’t very good for training, it’s a bit better at inference. Inference (i.e., interacting with models) is still compute intensive, but less so than training. And even if it is a bit slower and a bit more expensive than a centralized solution for inference, it has other big benefits, such as privacy and interoperability, that centralized solutions can’t offer. This certainly makes sense for specific applications. These are exactly the sorts of applications that NEAR AI infrastructure is targeting: things like agent hosting that’s private, secure, and verifiable. By running agents in a verifiable fashion, with proofs of faithful execution, the inference doesn’t need to be performed on chain.

Decentralization is a powerful tool, with equally large costs. We should be extremely thoughtful about how and when we apply it as a solution. Some questions you should ask yourself include: What specific problem are we solving, why does it require decentralization, are we sure that it’s possible with decentralization, and what price are we willing to pay for that decentralization?