Why I don’t believe in the Blockchain technology narrative

This is a kind-of, sort-of follow-up to “Why I don’t believe in the Web3 narrative”

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.

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).