Web 3.0 Will Not Achieve Decentralization and Scale, Here’s Why

02-19-2022 Article by Fabio Manganiello Image by Ty Cooper

What was Web 3.0 Supposed to Mean Again?

The Semantic Web

The definition of “Web 3.0” has assumed different incarnations over the past few years, depending on whom you asked and when. We initially thought it would have been some kind of semantic web, with shared ontologies and taxonomies that described all the domains relevant to the published content. The Internet, according to this vision, will be a collective semantic engine driven by a shared language to describe entities and the way they connect and interact with one another. It will be easy for a machine to extract the “meaning” and the main entities of another page, so the Internet will be a network of connected concepts rather than a network of connected pages.

Looking at things in 2022, we can arguably say that this vision hasn’t (yet?) been realized. Despite being envisioned for at least the past 20 years, today approximately 1-2% of the internet domains contain or support the semantic markup extensions proposed by RDF / OWL. I still believe that there’s plenty of untapped potential in that area but, since there hasn’t been a compelling commercial use-case to invest tons of resources in building a shared Internet of meaning instead of an Internet of links, the discussion has gotten stranded between academia and W3C standards (see also the curse of protocols and shared standards).

The Web-of-Things

More recently, we envisioned Web 3.0 as the Internet of Things. According to this vision, IPv6 should have taken over within a few years, every device would have been directly connected to the Internet with no need of workarounds such as NAT (IPv6 provides enough addresses for each of the atoms on the planet), all the devices will ideally be talking directly to one another over some extension of HTTP.

Looking at things in 2022, we can say that this vision hasn’t (yet) become a reality either. Many years down the line, only one-third of the traffic on the Internet is IPv6. In countries like Italy and Spain, the adoption rate is less than 4-5%. So NAT-ting is still a thing, with the difference that it has now been largely delegated to a few centralized networks (mainly Google, Apple and Amazon and their ecosystems): so much for the dream of a decentralized Internet of things. And the situation on the protocols side isn’t that rosy either. The problem of fragmentation in the IoT ecosystem is well documented. The main actors in this space have built their own ecosystems, walled gardens, and protocols. The Matter standard should solve some of these problems, but after a lot of hype there isn’t much usable code on it yet, nor usable specifications (2022 should be the year of Matter though, that’s what everybody says).

Regardless of how successful the Matter project will be in solving the fragmentation that prevents the Internet of things from being an actual thing, it’s sobering to look back at how far we’ve come from the original vision.

We initially envisioned a decentralized web of devices, each with its own address, all talking the same protocols, all adhering to the same standards. We have instead ended up with an IoT run over a few very centralized platforms, with limited capabilities when it comes to talking to one another, and the most likely solution to this problem will be a new standard that hasn’t been established by academic experts, ISO or IEEE, but by the same large companies that run the current oligopoly. Again, so much for the dream of a decentralized Internet of things.

Crypto to the rescue?

Coming to the definition of Web 3.0 most popular in the last couple of years, we’ve got the Internet-over-Blockchain, a.k.a. crypto-web, a.k.a. dApps.

The idea is pretty straightforward: if Blockchain can store financial transactions in a decentralized way, and it can also run some code that transparently manipulates its data in the form of smart contracts, then we’ve got the foundations to build both data and code in a decentralized way.

To understand how we’ve got here, let’s take a step back and let’s ask ourselves a simple question.

What Problem is Web 3.0 Actually Trying to Solve?

What is wrong with the Web 2.0 that actually wants us to move towards a Web 3.0, with all the costs involved in changing the way we organize software, networks, companies, and whole economies around them?

Even if they envision different futures, the Semantic Web, the Web-of-Things, and the Crypto-Web have several elements in common. And the common trait to all those elements can be summarized by a single word: decentralization.

So why is Web 3.0, in all of its incarnations, so much into decentralization?

An obvious part of the answer is, of course, that Web 2.0 has become too much about centralization (of data, code, services, and infrastructure) in the hands of a few corporations.

The other part of the answer to the question is the fact that software engineering, in all of its forms, is a science that studies a pendulum that swings back and forth between centralization and decentralization (the most cynical would argue that this is the reason why information engineers will never be jobless). This common metaphor, however, provides only a low-resolution picture of reality. I believe that information technology has a strong center of mass that pulls towards centralization.

When the system has enough energy (for various reasons that we’ll investigate shortly) it flips towards decentralization, just to flip back to a centralized approach when the cost of running a system with an increasingly high number of moving parts becomes too high. At that point, most of the people are happy to step back and accept somebody providing them with infrastructure/platform/software-as-a-service®, so they can just focus on whatever their core business is. At that point, the costs and risks of running the technology themselves are too high compared to simply using it as a service provided by someone who has invested enough resources in commoditizing that technology leveraging an economy of scale.

The few companies that happen to be in that sweet spot in that precise moment during the evolution of the industry (an economist would call it the moment where the center of mass between demand and supply naturally shifts) are blessed with the privilege of monopoly or oligopoly in the industry for at least the next decade to come – which, when it comes to the IT industry, is the equivalent of a geologic eon. How long it will take until the next brief “decentralized revolution” (whose only possible outcome is the rising of a new centralized ruling oligarchy) depends on how much energy the system accumulates during their reign.

There is a simple reason why technology initially moves towards centralization unless a sufficient external force is applied, and I think that this reason goes often under-mentioned:

Most of the folks don’t want to run and maintain their own servers.

As an engineer and a hobbyist maker that has been running his own servers for almost two decades (starting with a repurposed Pentium computer in my cabinet a long time ago), as well as a long-time advocate of decentralized solutions, this is a truth that hurts. But the earlier we accept this truth, the better it is for our sanity – and the sanity of the entire industry.

The average Joe doesn’t want to learn how to install, run and maintain a web server and a database to manage their home automation, their communication with family and friends, or their news feed unless they really have to.

Just like most of the folks out there don’t want to run and maintain their own power generators, their own water supply and sewage systems, their own telephone cables, or their own gasoline refineries. When a product or a technology becomes so pervasive that most people either want it or expect it, then they’ll expect somebody else to provide it to them as a service.

However, people may still run their own decentralized solutions if it’s required. Usually, this happens when at least one of the following conditions apply:

1. A shortage occurs: think of an authoritarian government cutting its population out of the most popular platforms for messaging or social networks, prompting people to flock to smaller, often decentralized or federated, solutions.

2. The technology for a viable centralized solution isn’t out there yet: think of the boom of self-administered forums and online communities that preceded the advent of social networks and Web 2.0.

3. Some new technology provides many more benefits compared to those provided by the centralized solution: think of the advantage of using a personal computer compared to using an ad-hoc, time-slotted connection to a mainframe.

4. People don’t trust the centralized solutions out there: this has definitely been the case after the Cambridge Analytica scandal brought in the spotlight the fact that free online platforms aren’t really free, and that giving lots of your data to a small set of companies can have huge unintended consequences.

When one of these conditions apply, the industry behaves like a physical system that has collected enough energy, and it briefly jumps to its next excited state. Enough momentum may build up that leads to the next brief decentralized revolution that may or may not topple the current ruling class. However, once the initial momentum settles, new players and standards emerge from the initial excitement, and most of the people are just happy to use the new solutions as on-demand services.

Unlike an electron temporarily excited by a photon, however, the system rarely goes back to its exact previous state. The new technologies are usually there to stay, but they are either swallowed by new large centralized entities, packaged as commondified services, or they are applied in much more limited scopes than those initially envisioned.

How is Web 3.0 going to achieve decentralization?

The different incarnations of Web 3.0 propose different solutions to implement the vision of a more decentralized Web.

1. The Semantic Web proposes decentralization through presentation protocols. If we have defined a shared ontology that describes what an apple is, what it looks, smells, and tastes like, how it can be described in words, what are its attributes, and we have also agreed to a universal identifier for the concept of “apple”, then we can build a network of content where we may tag this concept as an ID in a shared ontology in our web pages (that may reference it as an image, as a word, as a description in the form of text or audio), and any piece of code out there should be able to understand that some parts of that web page talk about apples. In this ideal world, the role of a centralized search engine becomes more marginal: the network itself is designed to be a network of servers that can understand content and context, and they can render both requests and responses from/to human/machine-friendly formats with no middlemen required. Web crawling is not only tolerated and advised: it’s the way the Web itself is built. Machines can talk to one another and exchange actual content and context, instead of HTML pages that are only rendered for human eyes.

2. The Web-of-Things proposes decentralization through network protocols, as well as scaling up the number of devices. If instead of having a few big computers that do a lot of things we break them up into smaller devices with lower power requirements, each doing a specific task, all part of the same shared global network, all with their own unique address, all communicating with one another through shared protocols, then the issues of fragmentation and lock-in effects of the economies of platforms can be solved by the natural benefits of the economies of scale. We wouldn’t even need a traditional client/server paradigm in such a solution: each device can be both client and server depending on the context.

3. The Crypto-Web proposes decentralization through distributed data and code storage. If Blockchains can store something as sensitive as an individual’s financial transactions on a publicly accessible decentralized network, and in a way that is secure, transparent and anonymous at the same time, and they can even run smart contracts to manipulate these transactions, then they are surely the tool we need to build a decentralized Web.

Why decentralization hasn’t happened before

We have briefly touched on in the previous paragraphs why decentralization usually doesn’t work in the long run. To better formalize them.

People don’t like to run and maintain their own servers

Let’s repeat this concept, even if it hurts many of us. Decentralization often involves having many people running their own services, and people usually don’t like to run and maintain their own services for too long, unless they really have to. Especially if there are centralized solutions out there that can easily take off that burden.

Decentralized protocols move much slower than centralized platforms

Decentralization involves coming up with shared protocols that everybody agrees on. This is a slow process that usually requires reaching consensus between competing businesses, academia, standards organizations, domain experts, and other relevant stakeholders.

Once those protocols are set in stone, it’s very hard to change them or extend them, because a lot of hardware and software has been built on those standards. You can come up with extensions, plugins, and patch versions, or introduce a breaking major version at some point, but all these solutions are usually painful and bring fragmentation issues. The greater the success of your distributed protocol, the harder it is to change because many nodes will be required to keep up with the changes.

The HTTP 1.1 protocol (a.k.a. RFC 2068 standard) that still largely runs the Web today was released in 1997, long before many of today’s TikTok celebrities were even born. On the other hand, Google developed and released gRPC within a couple of years. The IMAP and SMTP protocols that have been delivering emails for decades will probably never manage to implement official support for encryption, while WhatsApp managed to roll out support for end-to-end encryption to all of its users with a single app update. IRC is unlikely to ever find a standard way to support video chat, and its logic for sending files still relies on non-standard extensions built over DCC/XDCC, while a platform like Zoom managed to go from zero to becoming new standard de facto for the video chat within a couple of years.

The same bitter truth applies to the protocols proposed both by the semantic web and the IoT web. The push towards IPv6 has moved with the pace of a snail over the past 25 years, both for political reasons (the push, at least in the past, often came from the developing world, eager to get more IP addresses for their new networks, while the US and Europe, which hoarded most of the IPv4 subnets, often preferred to kick the can down the road), but, most importantly, for practical reasons. Millions of lines of code have been written over decades assuming that an IP address has a certain format and that it can be operated by a certain set of functions. All that code out there needs to be updated and tested, and all the network devices that run that code, from your humble smoke sensor all the way up to the BGP routers that run the backbone of the Internet, need to be updated. Even though most of the modern operating systems have been supporting IPv6 for a long time by now, there is a very long tail of user-space software that needs to be updated.

While the Internet slowly embraces a new version that allows it to allocate more addresses, companies like Google and Amazon have come in to fill that gap. We still need many devices to be able to transfer messages, but instead of communicating directly to one another, they now communicate with Google’s or Amazon’s clouds, which basically manage them remotely, and allow communication between two different devices only if both of them support their protocols. So yes, an Internet-of-Things revolution is probably happening already, but it’s unlikely to be decentralized, and it smells more like some cloud-based form of NAT.

A shared standard may also be on the way (after many years) in the form of Matter, but it’s a different standard than the open standards we are used to. It’s a standard agreed mainly by the largest platforms on the market, with little to no involvement from the other traditional actors (academia, standards organizations, other developers).

Money runs the world, not protocols and technologies

Things at these scales often move only when loads of money and human resources are poured into a field. No matter how good the new way of doing things is, or how bad the current way of doing thing is. The semantic web and its open protocols haven’t really taken off because they were pursued mostly by academia, standards organizations and Tim Berners-Lee. It didn’t really pick up momentum in the rest of the industry because at some point solutions like Google came up.

Why would you radically change the way you build, present and distribute your web pages, when Google already provides some black magic to infer content and context and search for anything you want on the Web? When Google already fills that gap somehow, it doesn’t matter anymore whether the solution is centralized or not: most folks only care that it works well enough for their daily use.

The vision of a semantic web where content is exposed in a form that is both human-readable and machine-readable, where web crawling becomes a structural part of the new experience, would jeopardize the very reason why the world needs services like the Google search engine.

The idea of a semantic web, at least as it was proposed by the W3C, is amazing on paper, but it’s hard to monetize. Why would I make my website easier for another machine to scrape and extract content from? We can arguably say that the Web has gone in the opposite direction in the meantime. Many sites have paywalls to protect their precious content from unpaid access. Many have built barriers against robots and scrapers.

Many even sue companies like Google for ripping them (through Google News) of the precious profits that come from people dropping their eyeballs on the ads running on their websites. Why would a for-profit website want to invest time to rewrite its code in a way that makes its content easier to access, embed and reuse on other websites, when the whole Internet economy basically runs on ads that people can see only if they come to your website?

No matter how good the technological alternatives are, they will never work if the current economic model rewards walled gardens or those that run ads that are seen by the highest number of people, especially if the system is already structurally biased towards centralization.

Will the crypto-web succeed where others have failed?

The crypto-web tries to solve some of the hyper-centralization issues of the Web 2.0 by leveraging the features of Blockchain. Here are some of the proposed solutions:

1. Monetization problem: the issue is addressed by simply making money a structural part of the architecture. Your digital wallet is also the holder of your identity. You can pay and get paid for the content on the platform by using one of the virtual currencies it supports. The currency, the ledger of transactions, and the platform are, basically, one single entity. So we have a digital currency at the core, and enough people who agree that it has some form of value, but very few ways to make use of that value – unless you live in El Salvador, you probably don’t use Bitcoins to pay for your groceries. For that reason, most of the cryptocurrencies have been, over the past years, mainly instruments for investment and speculation, rather than actual ways to purchase goods and services. The new vision of Web 3.0 tries to close this loop, by creating a whole IT ecosystem and a whole digital economy around the cryptocurrencies (the most cynical would argue that it’s been designed so those who hoarded cryptocurrencies over the past years can have a way of cashing their assets, by artificially creating demand around a scarcely fungible asset). If cryptocurrencies were a solution looking for a problem, then we’ve now got a problem they can finally solve.

2. Identity: a traditional problem in any network of computers is how to authenticate remote users. Web 2.0 showed the power of centralization when it comes to identity management: if a 3rd-party like Google, Facebook or Apple can guarantee (through whatever identification mechanism they have implemented) that somebody is really a certain person, then we don’t have to reinvent the authentication/authorization wheel from scratch on every different system. We delegate these functionalities to a centralized 3rd-party that owns your digital identity through mechanisms like OAuth2. By now, we also all know the obvious downsides of this approach – loss of privacy, single-point of failure (if your Google/Facebook account gets blocked/deleted/compromised then you won’t be able to access most of your online services), your digital identity is at the mercy of a commercial business that doesn’t really care a lot about you, Big Button Brother effect (no matter what you visit on the Internet, you’ll always have some Google/Facebook button/tracker/hidden pixel somewhere that sees what you’re doing). The crypto-web proposes a solution that maintains the nice features of federated authentication while being as anonymous as you can get. Your digital wallet becomes a proxy to your identity. If you can prove that you are the owner of your wallet (usually by proving that you can sign data with its private key), then that counts as authentication. However, since your wallet is just a pair of keys registered on the Blockchain with no metadata linked to you as a physical person, this can be a way to authenticate you without identifying you as a physical person. An interesting solution is also provided for the problem of “what if a user loses their password/private key/the account gets compromised?” in the form of social recovery. In the world of Web 2.0, identity recovery isn’t usually a big deal. Your digital identity is owned by a private company, which also happens to know your email address or phone number, or it also happens to run the OS on your phone, and they have other ways to reach out to you and confirm your identity. In the world of crypto, where an account is just a pair of cryptographic keys with no connection to a person, this gets tricky. However, you can select a small circle of family members or friends that have the power to confirm your identity and migrate your data to a new keypair.

3. Protocols and standards: they are replaced by the Blockchains. Blockchains are ledgers of transactions, and the largest ones (such as Bitcoin and Ethereum) are unlikely to be going anywhere because a lot of people have invested a lot of money into them. Since Blockchains can be used as general-purpose storage for data and code, then we’ve got the foundations for a new technology that doesn’t require us to enforce new protocols that may or may not be adopted.

4. Scalability: decentralized systems are notoriously difficult to scale, but that’s simpler for Blockchains. Everybody can run a node, so you just add more nodes to the network. If people don’t want to run their nodes, then they can use a paid service (like Infura, Alchemy) to interact with the Blockchain.

So far so good, right? Well, let’s explore why these promises may be based on a quite naive interpretation of how things work in reality.

Blockchains are Scalability Nightmares

Let’s first get the elephant out of the room. From an engineering perspective, a Blockchain is a scalability nightmare. And, if implemented in its most decentralized way (with blocks added by nodes through proof-of-work), they are environmental and geopolitical disasters waiting to happen. This is because the whole assumption that anybody can run their own node on a large Blockchain is nowadays false.

Running a Blockchain is a dirty business

In the early days of the crypto-mania, anybody could indeed run a small clusters of spare Raspberry Pis, mine Bitcoins and make some money on the side. Nowadays, big mining companies have installed server farms in the places where energy is the cheapest, such as near Inner Mongolia’s hydroelectric dams, near Xinjiang’s coal mines or leveraging Kazakhstan’s cheap natural gas.

The author of the post on Tom’s Hardware mentions that in February 2021 he made $0.00015569 after running mining software on his Raspberry Pi 4 for 8 hours. His hash rate (the number of block hashes added to the Blockchain per unit of time) varied from 1.6 H/s to 33.3 H/s. For comparison, the average hash rate of the pool was 10.27 MH/s. That’s 3-4 million times more than the average hash rate of a Raspberry Pi.

The examples I mentioned (Inner Mongolia, Xinjiang and Kazakhstan) are not casual. At its peak (around February 2020) Chinese miners contributed more than 72% of the Bitcoin hashes. The share hovered between 55% and 67% until July 2021, when the government imposed a nationwide crackdown on private crypto-mining. The motivations, as usual, are complex, and they obviously include the government’s efforts of creating a digital yuan. However, the fact that private miners scoop up a lot of cheap energy before it can get downstream to the rest of the grid, especially during times of energy supply shortages and inflationary pushes on the economy, has surely played a major role in Beijing’s decisions.

The fall of Beijing in the crypto market left a void that other players have rushed to fill in. The share of Bitcoin hashes contributed by nodes in Kazakhstan has gone from 1.42% in September 2019 up to 8.8% in June 2021, when China announced its crackdown on crypto. Since then, it climbed all the way up to 18% in August 2021 – and that’s the latest available data point on the Cambridge Bitcoin Electricity Consumption Index. From more recent news, higher demand for Kazakh gas, mixed with the high inflation, pushed energy prices up, triggering mass protests and the resignation of the government.

The curse of the proof-of-work

Why do decentralized Blockchains consume so much energy that they can impact the energy demand and production of whole countries, as well as destabilize whole geopolitical landscapes?

The Bitcoin Blockchain processes less than 300 thousand transactions per day. For comparison, as of 2019, the credit card circuits processed about 108.6 million transactions per day in the US alone.

We, therefore, have a proposed new approach whose underlying infrastructure currently processes less than 0.28% of the transactions processed in the US alone. Interestingly, the volumes of transactions processed by Visa and Mastercard have never caused geopolitical instabilities nor drained the energy supply of whole countries. How come?

To answer this question, we have to understand how Blockchains (or, at least, the most popular decentralized flavor initially proposed by Natoshi Sakamoto’s paper) work under the hood.

We have often heard that a Blockchain is secure by design, and it allows the distributed creation of a ledger of transactions among peers that don’t necessarily trust one another. This is possible through what is commonly known as proof-of-work. Basically, any node can add new blocks to the distributed chain, provided that the operation satisfies two requirements:

1. The new blocks are cryptographically linked to one another and consistent with the hashes of the previous latest block. A Blockchain is, as the name suggest, a chain of blocks. Each of these blocks contains a transaction (e.g. the user associated to the wallet ABC has paid 0.0001 Bitcoins to the user associated to the user associated to the wallet XYZ on time t), and a pointer with the hash of the latest block in the chain at the time t. Any new added blocks must satisfy this contraint: basically, blocks are always added in consecutive order to the chain, they cannot be removed (that would require all the hashes of the following blocks to be updated), and this is usually a good way of ensuring temporal consistency of events on a distributed network.

1. In order to add new blocks, the miner is supposed to solve a numeric puzzle to prove that they have spent a certain amount of computational resources before requesting to add new blocks.

This puzzle is defined in such a way that:

2.1. It’s hard to find a solution to it (or, to be more precise, a solution can only be found through CPU-intensive brute force);

2.2. It’s easy to verify if a solution is valid (it usually involves calculating a simple hash of a string through an algorithm like SHA-1).

The most popular approach (initially proposed in 1997 by Hashcash to prevent spam/denial-of-service, and later adopted by Bitcoin) uses partial hash inversions to verify that enough work has been done by a node before accepting new data from it. The network periodically calibrates the difficulty of the task by establishing the number of hash combinations in the cryptographic proofs provided by the miners (on Bitcoin, this usually means that the target hash should start with a certain number of zeros).

This is tuned in such a way that the block time (i.e. the average time required to add a new block to the network) remains constant. If the only way to find a solution to the riddle is by brute-forcing all the possible combinations, then you can tune the time required to solve the riddle by changing the total number of combinations that a node should explore. If a lot more powerful mining machines are added to the pool, then it’ll likely push down the block hashing time, and therefore at some point, the network may increase the difficulty of the task by increasing the number of combinations a CPU is supposed to go through.

Miners are usually rewarded for their work by being paid a certain fee of the amount of the processed transaction. It’s easy to see how early miners who invested the unused power of a laptop or a Raspberry Pi to mine Bitcoins managed to make quite some money on the side, while making a profit out of mining nowadays, given how high the bar has moved over the past years, is nearly impossible unless you invest on some specialized boards that suck up a lot of power.

The proof-of-work provides a secure mechanism to process information among untrusted parties. A malicious actor who wants to add invalid data to the chain (let’s say, move one Bitcoin to their wallet from another wallet that hasn’t really authorized the transfer) will first have to crack the private key of the other wallet in order to sign a valid transaction, then invest enough computational power to add the block – and this usually means being faster in average than all the nodes on the Blockchain, which already sets a quite high bar on large Blockchains. The new block needs to be accepted through shared consensus mechanisms from a qualified majority of the nodes on the network, and usually, long chains are more likely to be added than short ones – meaning that you have to either control a large share of the nodes on the network (which is usually unlikely unless you have invested the whole GDP of a country on it), or build a very long chain, therefore spending more power in average than all the other nodes on the network, to increase the chances that your rogue block gets included.

But the new rogue block needs to be cryptographically linked to all the previous and next transactions in the ledger. So the rogue actor will basically have to forever run a system that is faster than all the other nodes in order to “keep up” with the lie. This is, in practice, impossible. In some very rare cases, rogue blocks may eventually be added to the Blockchain. But, when that happens, the network can usually spot the inconsistency within a short time and fork the chain (i.e. cut a new chain that excludes the rogue block and any successive blocks).

This also means that rogue nodes are implicitly punished by the network itself. An actor who tries to insert invalid nodes will eventually be unable to keep up their lie, but they will have wasted the energy required to calculate the hashes necessary to add those blocks. This means that they’ll have wasted a lot of energy without being rewarded in any way.

A problem that wasn’t originally addressed by the Hashcash proposal (and wasn’t addressed by earlier cryptocurrencies either) was that of double-spending. This has been addressed by Bitcoin by basically implementing a P2P validation where a distributed set of nodes needs to reach consensus before a new block is added to the chain, and temporal consistency of transactions is enforced by design with a double-linked chain of nodes.

The proof-of-work is a proof-of-concept that was never supposed to scale

Now that we know how a Blockchain manages to store a distributed ledger of transactions among untrusted parties, it’s easy to see why it’s such a scalability nightmare. Basically, the whole system is designed around the idea that its energy consumption increases with the number of transactions processed by the network.

Since the whole algorithm for adding new blocks relies on a massively CPU-intensive brute-force logic to calculate a hash that starts with a certain number of leading zeros, the amount of CPU work (and, therefore, electricity usage) is basically the underlying currency of the network.

If the average block hashing time decreases too much, then the likelihood of success for rogue actors who want to add invalid transactions and invest enough in hardware resources increases. We, therefore, need to keep the cost of mining high so that it’s technically unfeasible for malicious actors to spoof transactions.

As engineers, we should be horrified by a technical solution whose energy requirements increase linearly (or on even steeper curves) with the amount of data it processes per unit of time. Managing the scale of a system so that the requirements to run it don’t increase at the same pace as the volumes of data that it processes is the cornerstone of engineering, and Blockchains basically throws this principle out of the window while trying to convince us that their solution is better. Had the “Blockchain revolution” happened under other circumstances, we’d be quick to dismiss its proposals as hype in the best case and outright scam in the worst case. In an economy that has to increasingly deal with a limited supply of resources and increasingly tighter energy constraints, a solution that basically requires wasting CPU power just to add a new block (a system where the amount of electric energy spent is the base currency used to reward nodes) is not only unscalable: it’s immoral.

The requirement to keep a block mining time constant means that, by design, the network can only handle a limited amount of transactions. In other words, we are capping the throughput of the system by design in order to maintain the system secure and consistent. I’m not sure how anybody with any foundation of logical reasoning can believe that such a system can scale to the point that it replaces the way we do things today.

Proof-of-stake to the rescue?

The scalability issues of the proof-of-work mechanism are well-known to anybody who has any level of technical clue. Those who deny it are simply lying.

In fact, Ethereum is supposed to migrate during 2022 away from proof-of-work and towards a proof-or-stake mechanism.

Under such a mechanism for distributed consensus, miners don’t compete with one another to add new blocks, and they aren’t rewarded on the basis of the electric energy consumed. Instead, they have a certain amount of tokens that represent votes that they can use to validate transactions added to the network. Under the newly proposed approach, for example, a node would have to spend 32 ETH in order to become a validator on the network (invested stake).

Whenever a node tries to add a new transaction to the network, a pool of validating nodes is chosen a random. The behaviour of a validator determines the value of its stake – in other words, rogue nodes would be punished by karma:

1. Nodes are rewarded (their stake is increased) when they add/validate new valid transactions.

2. Nodes can be punished (their stake is decreased), for example, when they are offline (as it is seen as a failure to validate blocks), or when they add/validate invalid transactions. Under the worst scenario (collusion), a node could lose its entire stake.

On paper, this approach should guarantee the same goal as proof-of-work (reaching a shared consensus among a distributed network of untrusted parties), without burning up the whole energy budget of the planet in the process. Why don’t we just go all-in on the proof-of-stake then?

Well, one reason is that it’s a system that is definitely less tested on wide networks compared to proof-of-work. PoW works because it leverages physical constraints (like the amount of consumed energy) to add new blocks. PoS removes those constraints, it proposes instead a stake-based system that leverages some well-documented mechanisms of reward and punishment from game theory, but once the physical constraint is removed there are simply too many things to take into account, and different ways a malicious actor may try and trick the system.

A common problem of PoS systems is that of a 51% attack. An attacker who owns 50%+1 of the share of stakes of a currency can easily push all the transactions that they want – consensus through a qualified majority is basically guaranteed. The risk for this kind of attack is indeed very low in the case of Ethereum – one Ethereum coin is expensive, buying such a large share of them is even more expensive, and anyone who invests such a large amount has no interest in fooling the Blockchain, cause a loss of trust and therefore erode the value of their own shares. However, this risk is still very present in smaller Blockchains. PoS is a mechanism that probably only works in the case of large Blockchains where it’s expensive to buy such a large share of tokens. On smaller Blockchains with a lower barrier to buying a majority stake, it can still be a real issue.

There is another issue, commonly known as nothing-at-stake. This kind of issue can occur when a Blockchain forks – either because of malicious action or because two nodes actually propose two blocks at the exact same time, therefore making temporal causality tricky.

When this happens, it’s in the interest of the miners to keep mining both chains. Suppose that they keep mining only one chain, and the other one is eventually the one that picks up steam: the miner’s revenue will sink down. In other words, mining all the forks of a chain maximizes the revenue of a miner.

Suppose now that an attacker wants to attempt a double-spending attack. They may do so by attempting to create a fork in the Blockchain (for example, by submitting two blocks simultaneously from two nodes that they own) just before spending some coins. If the attacker only keeps mining their fork, while all the other miners act in their self-interest and keep mining both the forks, then the attacker’s fork eventually becomes the longest chain, even if the attacker only had a small initial stake.

A simpler version of this attack is the one where a validator cashes out their whole stake but the network does not revoke their keys. In this case, they may still be able to sign whatever transactions that they wish, but the system may not be able to punish them – the node has nothing at stake, therefore it can’t be punished by slashing their stake.

Ethereum proposes to mitigate these issues by linking the stake onto the network to an actual financial deposit. If an attacker tries to trick the system, they may lose real money that they have invested.

There is, however, a problem with both the mitigation policies proposed by Ethereum. Their idea is basically to disincentivize malicious actors by increasing the initial stake required to become a validator. The idea is that, if the stake you lose is higher than the money you can make by tricking the system, you’ll think twice before doing it. What this means is that, in order for the system to work, you need to increase the initial barriers as the value of your currency (and the number of transactions it processes) increases.

So, if it works, it’ll basically turn the Blockchain into a more centralized system where a limited amount of nodes can afford to pay the high cost required to validate new blocks (so much for the decentralization dream). As of now, the entry fee to become a validating node is already as high as 32 ETH – more than $100k. As the system needs to ensure that the stake a node loses for rogue behavior is higher than the average gain they can make from tricking the system, this cost is only likely to go up, making the business of becoming a validating node on the Blockchain very expensive. If it doesn’t, if the value of the cryptocurrency plunges and the perceived cost of tricking the system gets lower, then there’s nothing protecting the system from malicious actors.

In other words, proof-of-stake is a system that works well under some very well-defined assumptions – and, when it works, it’s probably doomed to swing towards a centralized oligarchy of people loaded with money anyways.

How about data storage scalability?

Another scalability pain point of Blockchains is on the data storage side. Remember that any mining/validating node on the network needs to be able to validate any transaction submitted to the network. In order to perform this task, they need a complete synchronized snapshot of the whole Blockchain, starting with its first block all the way up to the latest one.

If 300k blocks per day are submitted, and supposing that the average size of a block is 1 KB, this translates into a data storage requirement of about 100 GB per year just to store the ledger of transactions.

As an engineer, suppose that you have a technological system that requires thousands of nodes on the network to process about 0.2% of the volumes of transactions currently processed by Visa/Mastercard/Amex in the US alone. The amount of nodes required on the network increases proportionally with the number of transactions that the network is able to process because we want the process of adding new blocks to be artificially CPU-bound.

Moreover, each of these nodes has to keep an up-to-date snapshot of the whole history of the transactions, and it requires about 100 GB for each node to store a year of transactions. Since every node has to keep an up-to-date snapshot of the whole ledger, you can’t rely on popular scalability solutions such as data sharding or streaming pipelines.

Adding a new block to this “decentralized filesystem” requires that you run some code that wastes CPU cycles in order to solve a stupid numeric puzzle with SHA hashes. How would you scale up such a system to manage not only the number of financial transactions currently handled by the existing solutions, but run a whole web of decentralized apps on it? I think that most of the experienced engineers out there would feel either uncomfortable or powerless if faced with such a scalability challenge.