The Compute Monopoly
Global workloads need resilient, low-latency, energy-aware infrastructure. Instead we have a handful of providers, a handful of regions, and billions of idle devices doing nothing. The case for a mesh where every device is a node, and the hard problems in the way.
Vie Team
There is more compute in the world than the world is using.
It sits in phones on bedside tables, laptops closed on desks, consoles between sessions, and on-premise servers provisioned for a peak that arrives twice a year. Billions of devices, idle most of the time, most of them within a few milliseconds of someone who needs something computed.
Meanwhile the work queues up inside a small number of buildings owned by a small number of companies, and the industry treats that as its natural shape rather than as an accident of how it developed.
What centralisation costs
Price is the usual complaint and the least interesting one.
The bigger problem is correlated failure. When a region degrades, the damage is not contained to one company’s product. It spreads through everything built on that region, which by now is a large share of the internet. We have concentrated correlated risk into a handful of physical locations and built the world’s infrastructure on top of them. Redundancy inside a provider stops helping once the provider is the component that fails.
Centralisation also puts a floor under latency. If the computation happens in a distant region, the round trip is bounded by that distance, and no amount of engineering inside the data centre buys it back. For inference, for interaction, for anything with a person waiting at the end, that floor is increasingly the dominant term.
It raises the barrier to entry too. Capital-intensive infrastructure favours whoever already has capital. A market where participation costs a data centre has a small and fixed number of participants, and the returns go to the position rather than to the innovation. Compute is a commodity priced like a differentiated service, and whoever owns the buildings captures the difference.
Then there is sovereignty. Where data lives decides who can compel access to it, under which jurisdiction, on what notice. Centralisation makes that question easy to answer and hard to influence.
And it wastes. Somewhere near you a device with a capable processor is drawing power to display a lock screen. That capacity is not stored for later. Every idle cycle is spent whether or not anyone uses it.
A living digital nervous system
The alternative is a mesh: every device a node, compute as a shared resource instead of a controlled commodity.
Any device can participate, from a smartphone to an enterprise server, given the right security model. Capacity then grows with adoption rather than with construction, which inverts the economics. A conventional provider has to build ahead of demand and carry the cost of the gap. A mesh gains capacity from the same event that creates the demand.
The network routes work to whichever node suits it, weighing energy, latency, and capability. That is not a fixed scheduler applying a fixed policy. It is a population of agents continuously re-deciding, closer to how a body distributes resources, pushing supply toward wherever it is being drawn without any single part holding the whole plan.
Energy-aware scheduling is worth dwelling on, because it is available here and structurally unavailable in a data centre. Once workloads are portable across a global pool, the scheduler can prefer nodes whose power is currently cleanest. Carbon intensity becomes a term in the routing function instead of a line in an annual report.
Decentralisation also removes the region you can lose. Data can stay at the edge, near the person it concerns, under the control of whoever holds the device, which combines an on-premise security posture with public cloud elasticity. Today that combination is a trade.
The hard parts
Three problems stand between this and a working network.
Trust. Running work on hardware you do not own means you cannot naively believe the result. Verification, redundant execution, and confidential computing all cost something, and the design question is which workloads absorb that overhead and still come out ahead. Not all of them can. Enough of them can.
Reliability. Nodes leave. A phone is unplugged, a laptop closes, a connection drops in the middle of a computation. The scheduler has to treat churn as the normal condition rather than the exception, which rules out a class of workloads and demands a different fault model for the rest.
Incentives. A device owner contributes capacity only when the return beats the cost in battery, bandwidth, and heat. Get that wrong in either direction and there is no supply, or no economics.
These are the reasons the mesh does not exist yet, and they are where the engineering is.
Why it is worth it
What we want at the end is a compute market that behaves like one. Prices set by an open pool of supply rather than by three firms. Resilience from having no centre, rather than from replicating one. Latency bounded by proximity, which you can improve, rather than by geography, which you cannot.
Centralised cloud is superbly run, and that is not the objection. The objection is that a critical resource routed through a few chokepoints is a fragile arrangement, and we would rather not learn how fragile the hard way.