• BTC $16464.64 -0.01 %
  • ETH $1205.81 -0.04 %
  • BCH $112.50 0.00 %
  • SOL $14.17 -0.14 %
  • XRP $0.40 -0.05 %
  • BNB $311.50 -0.03 %

Why I Don't Believe in the Blockchain Technology Narrative

Dirk Songuer· 10 min read

Because I work on and around the Metaverse, people often ask me about blockchains and are quite surprised when I dismiss them as extremely limited technology, surrounded by false narratives.

Why is Blockchain?

To explain my opinion, I won’t start with what a blockchain is, but why they exist in the first place.

Technology is all about decision making to create a solution optimized to solve a specific problem. It’s like cars, where decisions on power, driving behavior, space, range and so on create a targeted offering for a specific audience, as no product can provide everything for everybody. Some people buy supercars, some buy family saloons, based on preference, but mostly based on daily requirements they have and of course their budget.

Every design decision for a product thus excludes target audiences & use cases. So, by looking at the decision making that led to the existence of blockchains, we can also look at what they are good at and what they are bad at.

Blockchains were created to enable digital currencies without central banks:

We want a distributed, immutable ledger, holding financial data, which operates without central authority, and that everybody can participate in.

The way Ledger was interpreted is that a blockchain at its core is an append-only database, meaning that writing new data to it will always create a new record entry.

Immutable means that no participant can ever edit or delete data.

Financial data was deemed as small pieces of text.

Everybody participating was interpreted as an openly available distributed database and everybody has the same rights, including write-access.

No central authority means that participating nodes needed to be self-managing and find a way to verify the validity of the current state independently from each other.

And based on these decisions, you end up with the definition and the properties of a blockchain.

Cause and effect

Now let’s think about what these design decisions mean and why they disqualify the scale adoption of blockchains.

Append-only databases are great at certain things. They are good for keeping logs, but terrible if you need to work with the data in an efficient way. It means that your database size is always growing and since you need all the data at any given time to create all entries of a ledger for a complete individual record, it means it can never shrink (contrary to a rolling log). This is already a problem for some of the popular blockchains. The more a blockchain is used, the worse it gets. This is a technical problem.

Since you cannot ever delete or edit data, it means that individual user or system errors cannot be rolled back. Made a typo while entering data? Or while transferring some of your cryptocurrencies to another user? Well, too bad, it cannot be corrected, the data will be wrong, and the funds will be gone, forever.

This breaks with user expectations for digital products. Users expect digital systems and experiences to break immersion from time to time. This is an admittance that digital experiences can’t be perfect and that mistakes (from users or systems) need to be corrected by the operator of the experience: Made a typo during online banking? Call your bank and sort it out.

In the blockchain world this is not only impossible but seen as a feature: Since “Code is law” there can never be incorrect information since everything on chain must be the established truth. The typo is now law. This might be fine for a specific libertarian audience but is impossible to scale to society level. This is a social problem.

And there are many, many other effects, technical and social, that prevent blockchains from ever being able to scale. Here are some highlights:

  • Since all nodes in the blockchain need to be synchronized to have the same state and verify the state together, it means that blockchains are operating synchronously and blocking, meaning their speed is limited by the “tick” of the consensus mechanism. That makes them horrendously slow compared to other databases, to the point where it’s mathematically provable that they cannot scale.
  • Speaking of consensus mechanisms, these are either horribly inefficient to the point where the system requires the power equivalent to nation states to do 7 transactions per second, or they have economic or procedural issues. They are required to achieve a distributed system without central authority, but there is no way to make them efficient and fair at the same time.
  • Since all participants have the same access to all data and the same rights, there is no access control. There is no data privacy and since there is also no way to delete data, it means that personal data on chain can never be GDPR compliant.

To sum it up: The design decisions that make up a blockchain created a technology that is highly focused and not really suited for scale, widespread use cases. To stay with the car analogy, it’s a Pagani Zonda R: Something highly targeted, something highly specialized, that is amazing for this one thing, but really bad for everything else.

Blockchain-like, but not blockchain

Now, all these issues can be overcome. If you don’t like the negative effects of using an append-only database, you can just use a regular database and add a ledger log on the side. If you want error correction and fail-safe behavior, add some form of governance. If you want efficiency and speed, get rid of consensus by adding a form of network of trust. If you want access control and making sure only authorized entities have access to relevant data, use a traditional database model. If you want privacy, add user-level encryption (once the blockchain has an idea what the concept of a “user” is). All of that is not only possible, but how non-blockchain databases have operated for decades.

So, yes, you can make blockchain-like systems scale — if you get rid of the defining characteristics of a blockchain. It’s like exchanging the engine, tires, chassis, and body of that Zonda R with Ford Focus parts and still call it a Zonda.

Git for example is a distributed, decentralized version control system that also uses the same approach that blockchains use to validate blocks (Merkle Trees), but nobody would call Git a blockchain.

In other words, if your requirement is to be able to drive your kids to school in the morning, don’t buy a Pagani Zonda R.

You might also read about “Layer 2 technologies”. These are systems built on top of blockchains to alleviate some of these problems and get them to scale. But these are also not blockchains. This is the worst of both worlds: Not blockchains that are built on top of blockchains. This is a truck towing your Zonda R so you can drive your kids to school with it (somehow).

So, the best way to scale a blockchain is to not use a blockchain at all. And that is likely the way forward: Salvage the thing for individual parts and forget they ever were connected.

Lies, damned lies and blockchain narratives

The issue I have is that the narrative treats blockchains as this breakthrough that is going to change everything — even the way the Internet works!

In actuality, the only scale use cases that worked in the last 14 years since blockchains were invented are negative sum unregulated financial speculation and ransomware payments (or providing blockchain analytics services to prosecute both).

But for some reason, individuals and organizations have tried to push various use cases for blockchains, claiming they would revolutionize the consumer, enterprise, and industrial landscape. 

Here is a summary of what these use cases are trying to achieve and where they go wrong:

  • They try to decentralize something that is clearly more efficient through economies of scale. Just because a blockchain is decentralized doesn’t mean it’s the most efficient way to approach business processes. Micro-warehouses sound like a clever idea until you think about the nightmare that is coordination, logistics, safety, and fraud-prevention. Decentralized, interoperable digital ecosystems in gaming or “The Metaverse” seem like a promising idea until you realize that they are not desirable.
  • They try to add monetary incentives to behavior. This is a social anti-pattern where incentivization to act normally makes people behave differently. Meta paying users for engagement means that engagement data is worthless since users will tend to change their activities to maximize profit. Play to Earn does not make sense and has lots of negative externalities.
  • They try to put personal data on a blockchain. Until you realize that you might not want your medical records, payment history, possessions, and other personal activities publicly visible to everybody without the ability to ever delete them.
  • They think that code should be law. Just because a blockchain is temper-proof doesn’t mean that the content is correct. Using blockchains in supply chain does not mean that you have a verifiable record of what happened, but of what somebody said happened. It doesn’t prevent people from lying.
  • It’s actually an unregulated financial product, dressed up as something else. Blockchains are good at unregulated financial speculation. Some talk about “Play to earn as driver for Metaverse economics” as they clearly describe a financial product, made for speculation, dressed up as a spaceship.
  • They try to replicate existing technology stacks that have been optimized for decades. Just because blockchains are all the rage right now does not mean they are better at everything. Arguing that blockchains will be great for tickets and membership programs ignores that we have had such systems already for decades and that these systems have centralized endpoints anyway, meaning an actual event or company. This is also true for every use case you now want to invent for NFTs — which are just fancy talk for “UUID with a link”.

Repeat after me: There are no scale use cases for blockchains outside negative sum unregulated financial speculation and ransomware payments (or providing blockchain analytics services to prosecute both).

Prove it

Don’t believe me? Well, then show me a case study where blockchains worked at scale. Just one. What you will produce are either absurd cases like using “600 virtual machines (VMs) to securely store and manage data points for only thousands of transactions per day” or a list of long dead proof of concepts. There is also the blockchain study that “finds 0.00% success rate and vendors don’t call back when asked for evidence.”

Or please describe a use case in-depth, end-to-end, including the challenges to overcome, edge cases and why blockchain is a superior solution. Most advocates just use buzzwords and vague ideas, while struggling to go into any depth — with hilarious results when they do. Like, really funny. My favorite was the argument that: “Sure, it doesn’t work NOW, but it could work if everybody would just rebuild the entire industry based on my first principles.”

There is a reason Amazon, Microsoft, IBM and others quietly shut down their blockchain services: No business.

Ninety-nine percent of the narratives around blockchains are futures hallucinations, claiming that they solve some problem without understanding or addressing the underlying issues. All this is performativity to drive your narrative for personal gain. Stop it.

Want to buy a Zonda R?

You might now think that I say that blockchains are completely useless (ignoring, you know, ponzi schemes and extorsion). Well, no. If you find a use case that requires the specific properties of a blockchain, they can be quite effective.

Let’s look at those properties again:

  • A database that is append only, write-once and the content can’t be changed once written
  • Every participant has access to all data in the database
  • You assume bad actors in the network of participants with write access

To put that into a business context:

  • Is there a business process that crosses trust boundaries?
  • Do multiple business parties share data and is there a need to make the data temper-proof once verified?
  • And ideally: Is this verification currently done by a third party / intermediary?

If all those attributes are true, then a blockchain might make sense to eliminate the need for the intermediary — at the cost of doing your own data verification attached to the consensus mechanism (on and off the blockchain).

As Microsoft puts it when they shut their Azure Blockchain Service: “The only scenario where you need a blockchain (.. vs a traditional database..) is when the parties performing the writes are not trusted.”

Look, a Pagani Zonda R is amazing at what it was designed for. But let’s be clear of what it is and what it is not: It’s a track-focused hypercar that isn’t even road-legal. There is a market for a car like that, but there is no world in which you can turn it into a mass market product, no matter the amount of marketing and VC money you throw at the narrative.

And herein lies the problem: The narrative does not describe the opportunity. There are just not many scenarios where a blockchain is the best solution. There is some innovation in finance, telecommunications, supply chain, but it is very, very confined, extremely focused, highly customized.

Bottom line: Blockchains can be useful, but they are not a scale business, let alone a revolutionary paradigm shift.

All Comments