Blockchains are polarising the tech community. I have repeatedly criticized, that current Blockchain-based solutions are mostly hype and little substance. However, that is an oversimplification of the truth. Blockchains are an interesting technology and they do address a real existing problem.

However, I would argue that it is not the problem that people want to solve in the vast majority of cases where Blockchains are currently proposed.

Instead of blindly criticizing the hype, let us look at the actual promises that this technology holds, where it might be useful going forward, and which problems it does not solve by itself.

What Are Blockchains?

Other people have already done a better job than I could to describe the inner workings of Blockchains. Without going into the technical details, I still need to explain one central concept for this article: The idea of Byzantine Consensus.

Let us first consider what Consensus means. Consensus is a term used in the study of distributed systems describing a situation in which multiple distributed participants agree on a state without relying on central coordination. The only thing they have at their disposal to negotiate this shared state are messages that they send directly to each other.

Consensus protocols are messaging schemes that are designed to achieve consensus in distributed systems. The protocol that you need to adopt depends on the assumptions that you can make about your system. In a very simple system where participants can message each other freely and without limitations, a simple consensus mechanism could be for everyone to broadcast their belief of the state (their answer) and then for each participant to adopt the majority decision:

Here, after one broadcast, everyone would agree that the shared state is “burgers”.

Typically, distributed systems need to assume that messages can get lost on the way and a participant cannot be certain that their messages were received by the other party unless they receive an explicit acknowledgment. Another typical complication is that participants in the exchange may not have perfectly synchronized clocks – ruling out a range of approaches.

Consensus protocols like Paxos are designed to work in systems of this shape. (See Kleppmann’s “Designing Data Intensive Applications” for an in-depth treatment of the complications of distributed consensus.)

In the above discussion, we assumed that all participants would genuinely do their best to achieve consensus and follow the protocol. This is typically a reasonable assumption if all the participants are machines in a data center that you control. A Byzantine Consensus problem extends the scope: Here we need to assume that some actors actively try to cheat and to manipulate the system in their favor.

Imagine that instead of exchanging their food preference, the participants in the example above would exchange their current knowledge about the balance on Tom’s bank account. If Tom controls one of the machines participating in the exchange, we would need to assume that the numbers reported from his side are not entirely truthful.

A Byzantine Consensus protocol is designed to achieve consensus under these even more complex circumstances.

There are, of course, some limits to what a Byzantine Consensus protocol can achieve. If all actors except yourself collaborate to manipulate the system in some way, there is not much you can do. However, the technically very exciting part is that you can design systems and protocols that support a certain share of malicious actors without breaking.

This is where Blockchains come in. Blockchains are an instance of a Byzantine Consensus problem where the state that the participants need to agree on is a big list of things that is commonly called a ledger (you could also say “a chain of blocks”). This is done by exchanging messages designed to agree on what next element should be appended to the end of the list.

There are multiple different protocols out there that try to achieve this consensus, each with its own advantages and disadvantages. The brilliant idea underlying the most popular approaches is to couple participation in the network to an economic incentive. The best-known approach in this area is Proof of Work, the thing that famously causes the bitcoin network to have the energy consumption of a small country.

Without going into the details, the effect of Proof of Work is that it would be incredibly expensive for a malicious actor to manipulate the consensus: If you want to convince the network of an alternative reality in which you sent your coin from your right pocket to your left pocket instead of sending it to Judy after Judy has already given you a Pizza in exchange for your coins, you would be forced to spend an enormous amount on computational resources on the attack. (See for example the bitcoin paper for details.)

In the following sections, I want to briefly go into some of the applications that Blockchains are currently proposed for and how they fit into this picture.

Currencies

The first and best-known application of blockchains is currencies. Bitcoin or Etherum are famous examples.

Building a currency on top of a Byzantine Consensus protocol as the one described above requires two additional ingredients: First, we need to interpret the ledger which is being maintained by the system as a list of monetary transactions. “Tom pays Judy 80€” could be one entry, for example. From a list of transactions, you can always reconstruct the current balance.

The second ingredient that we need is a way for participants to authenticate themselves to the system and to prove the authenticity of a transaction. Only Bob can decide to initiate a payment from Bob’s account. The Bitcoin protocol achieves this through digital signatures, a technique much older than blockchains, which can be used in conjunction with distributed consensus.

In practice, proof of work Blockchain like Bitcoin or Ethereum (as well as proof of stake systems like Solana) deeply integrate the currency aspect into their protocol. It is used to provide monetary incentives without which the protocol would not function.

Smart Contracts

An interesting application of Blockchains is the ability to encode contracts as part of the chain.

There is nothing in the above protocol that says that blocks can only contain monetary transactions. We can make use of this flexibility by allowing small programs to be included inside these blocks. Such a message communicates to the rest of the network: “There is another participant you can interact with and this participant is not controlled by a person but by the following code…”

For example, a program could implement the following logic: As soon as the account balance of the contract exceeds 100€, it distributes the money equally to Tom’s and Judy’s respective accounts. This program is now a virtual participant in the system and as soon as Judy transfers the necessary money to that contract, the new state of the system needs to take into account the program execution:

You could for instance imagine a Kickstarter-like setup in which a contract promises that if a certain funding goal is reached, the money contributed for a cause will go to the account of the project. If the funding goal is not reached, the contributors are guaranteed to get their money back. This is guaranteed by the contract stored on the chain rather than through a legal contract.

Note that this way it is easy to express relationships between things that are managed inside the same ledger. It is much less evident to extend these contracts to objects outside of the scope of the blockchain as we will discuss below.

A good source on the details of how these contracts work is the very readable ethereum white paper.

DAOs

Once you accept the idea that contracts can be part of the chain, we can take things one abstraction level higher: Smart contracts can be used to implement organizational structures such as membership management and voting. In the blockchain world, these are called Decentralized Autonomous Organizations (DAOs). In a typical DAO, the way to become a member is to acquire “tokens”, giving access to a vote weighted proportionally to the number of tokens you hold. So in these models, “shareholder” might be a better analogy than “member”.

The voting mechanism is itself a smart contract. Note in particular that motions that relate to objects on the chain can be executed automatically when the vote succeeded. This includes spending the organization’s funds in a certain way and even modifying the code of the smart contract on which the organization runs.

This enables the creation of legal structures and governance mechanisms enforced by code in the bounded universe of the blockchain.

Votes that do not relate to objects on the chain cannot be enforced automatically – but the record of the vote and the result is permanently recorded on the ledger and hard to falsify.

I have also seen DAOs take on a different meaning, decoupled from the underlying technology: Many proponents see them as a new form of organization that is participative because becoming a member means becoming a shareholder, which has very strict transparency requirements and that has very easy access to fundraising tools. All of these qualities are interesting. They also could be achieved without Blockchain technology – but maybe Blockchain technology happened to be the most straightforward stepping stone at this point in history.

NFTs

Non Fungible Tokens (NFTs) are another blockchain application that made the headlines in recent months. NFTs are about storing ownership claims. In a sense, a currency is also an ownership claim: A certain state of the Bitcoin network might represent the fact that I own 20€ worth of Bitcoin. With normal coins, however, it does not matter which ones I possess specifically, all that matters is their quantity.

In contrast, an NFT is a unique token and the Blockchain conveys my ownership of exactly that unique token.

With the smart contract system described above, implementing such tokens is conceptually simple: It suffices to build a contract that stores the information “Anne owns the Mona Lisa” and that can transfer this ownership if the appropriate amounts of money have been exchanged.

This transaction is then part of the blockchain and can serve as irrefutable proof that the transaction has taken place.

If this token relates to entities that exist outside of the blockchain (like the Mona Lisa), interpreting what ownership of a token really means becomes a tricky exercise as we will see later. However, ownership of the token itself can be irrefutably proven thanks to the immutable nature of the Blockchain.

What Are Blockchains, Really?

It would not be too far off to look at the blockchain as a database with one additional property: You don’t need to trust a central entity to manage and guarantee the integrity of that database.

All of the above applications could technically be achieved by a simple shared database controlled by an entity that the participants trust: The ledger of a currency could be on the database of a trusted party that assures that all transactions are booked correctly. Let us call this entity a “bank”.

Nothing would stop such an entity from also accepting contracts with precise definitions of what should happen in a given situation. You could also imagine a central repository that contains properties associated with different people as a simple alternative to NFTs. Land title registers work that way, for example.

So when considering Blockchain-based solutions, this is what any proposal needs to be measured against: What do we gain over the simpler alternative of resorting to a trusted entity?

I need to address one more point because I am sure that Blockchain proponents would bring it up: Blockchains also provide inherent protection against tampering. It is not easily possible to manipulate a transaction after the fact. Even if we trusted a central entity in principle, there could be a malicious actor with access to that entity who could manipulate the central database without anyone noticing.

While this is a valid point and potentially an important criterion for applications in which traceability is a factor, this can nevertheless not be counted as a unique feature of Blockchains. Blockchains have this property, but the techniques used in Blockchains (Merkle trees) can also be used to establish the same guarantees in a setup with a central trusted party.

This article describes a procedure that uses these techniques with a centralized log to generate proofs of validity and to allow for easy auditing.

The Oracle Problem and the Enforcement Problem

An important limitation of Blockchain-based solutions is the difference between objects inside the chain and objects outside of the chain. Smart contracts and NFTs work in the bounded world of everything that is inside the blockchain. If you want these to extend out of this bounded realm into the real world, you would need an entity to make that link and to enforce what is encoded on the chain.

The first subcategory of issues in this category is the Oracle problem: If you want a smart contract to trigger rules based on information available outside of the blockchain (e.g. the USD price of a barrel of oil), you need an entity that encodes this data on the chain. This is problematic for a system designed around zero trust as this entity might have an incentive to misrepresent this information.

The second issue exists around enforcing ownership claims and legal bonds that relate to objects not managed on the chain:

An NFT may be tamper-proof evidence of you owning a piece of art. However, this piece of art exists outside of the blockchain. If I decided to ignore this ownership claim and replicate or sell that piece of art, you would need to find an entity that enforces your ownership claim against me.

Similarly, we described above a Kickstarter-like DAO which allocates funds if the funding objective is reached. The allocation of funds happens inside the bounded world of the blockchain. However, the contract cannot guarantee that the receiving party will actually use the funds for the intended purpose as this purpose will (likely) be outside of the blockchain.

Thus, in summary, if you want to break out of the bounded universe of the blockchain and make statements about the real world, you still have to rely on a trusted entity for this link.

This begs the question: If you already trust a central entity for enforcement, wouldn’t you also trust that same entity to handle the information in the first place?

One of the fundamental ideas behind the crypto movement is the principle of marrying economic incentives to algorithm design. I do not want to rule out that incentive structures can be found to solve the oracle problem and the enforcement problem. Potentially solutions that come to mind (“a smart contract that automatically rewards armed vigilantes for enforcing the claim”) sound pretty dystopian. At the very least I think it is fair to say that we are still pretty far from a system that can function without any trust in a central entity.

What Is The Downside of Using Blockchains?

If Blockchains simply lift a constraint – the need for a trusted entity – without downsides you could make the case that for any application that requires some form of ledger, they are strictly superior to centralized approaches.

However, just as with every technology choice, these decisions are trade-offs and the benefit of the Blockchain does not come for free.

Firstly, there is the overhead of running a consensus algorithm. I am not even that worried about the commonly criticized ridiculous energy consumption of the proof of work system as I am confident, that the more efficient approaches currently under development can be worked out far enough to be a viable alternative.

However, even a simple, non-Byzantine consensus protocol is known to add significant coordination overhead over simpler, centralized applications. Byzantine consensus is a much harder problem, still which means that there will be overhead linked to consensus-building that will never go away.

Secondly, the blockchain adds a layer of complexity which will be reflected in the overall cost of the project. More moving parts are also a security concern as it means more potential points of attack.

Thirdly, when it comes to more complex blockchain scenarios that involve DAOs and smart contracts, we run into several unresolved issues as these structures clash with both the current understanding of how software is built and our current understanding of the functioning of legal frameworks:

From an engineering perspective, smart contracts are programs that are very hard to modify once they are out there. If the same smart contract was on a central system of a trusted party, that trusted party could apply bug fixes and security updates as necessary. Applying a bug fix on a smart contract is a lengthy procedure and while the procedure is in progress, a known security vulnerability is potentially out in the open and waiting to be exploited. Not great for a tool primarily used for financial applications.

From a legal perspective, our current legal system foresees room for interpretation. That is why we have courts. The very mechanical understanding of a contract means that we cannot tell the difference between a transaction that abides by the rules and one that exploits a bug in the system, respecting the letter of the law but not its spirit.

What I Like About Blockchain Technology

I want to reiterate that my criticism is not about the technology itself but about the fact that it is promoted as a silver bullet for problems where other, more appropriate alternatives exist. The technology itself is fascinating and full of interesting ideas. One of the big things that I like about Blockchain is the idea of including monetary incentives in algorithm design and user interactions.

Inventing a completely new currency may have been a necessary prerequisite that enabled experimentation which such algorithms: It could be seen as a way of avoiding the checks and balances of our current financial system. I could see a lot of potentially interesting applications coming out of these experiments, even without the overly strict zero-trust assumption.

Conclusions

Blockchains do address a real problem: Keeping track of a record without access to a shared trusted party. I do think that there are applications where this property could be useful. For example, this could be used on an international level to establish a record of transactions even though the two parties cannot agree politically on one shared entity to keep track of these records.

However, it also casts serious doubts on Blockchain projects which require central trusted entities anyway. Do you need a central entity for enforcement? Do you need a trusted entity to distinguish a legit use from a scam? Blockchain projects launched by state actors for the benefit of their own population seem particularly dubious in this respect.

Furthermore, an important consequence of this discussion is the following: If anyone tries to sell you a Private Blockchain, run! This person, either by incompetence or by malice, likely will not act in your best interest. Private Blockchains are a contradiction in terms where you get all the complexity of Byzantine Consensus but none of its benefits as it is nevertheless centralized around a trusted party. There is almost certainly a better approach for your use case.

For further reading, I recommend the following very balanced article of the promises and problems of the web3 ecosystem written by people much more knowledgeable on the topic than myself.