The first rule of blockchain is: You do not talk about the blockchain
The first rule actually is: “Don’t talk about “the” blockchain, unless you mean the bitcoin blockchain,” but I shortened it for the Fight Club reference. “The blockchain”, as a term, is being used in the same meaningless way as “the cloud”. Putting data “on the blockchain” has become shorthand for making data trustworthy, infalsifiable and censorship-resistant. All these attributes apply to the bitcoin blockchain and very few others: open source projects with open blockchains and a battle-tested consensus mechanism. They do not, however, automatically apply to all data architectures that call themselves “blockchain”.
Putting data in a block and forging the blocks into a chain doesn’t make data immutable, and it certainly doesn’t make data “true” or trustworthy. A blockchain that exists on a single computer, or on any number of computers controlled by a single party, can easily be manipulated. The true innovation in bitcoin is not the blockchain in itself, but the “open consensus mechanism”. That is: the mechanism that achieves consensus (about the state of the blockchain) between all participants, even when the identity of participants is unknown and participants can freely enter and exit the system.
A blockchain is just a data structure. It is not inherently safe or trustworthy, nor is it inherently slow or resource intensive. To know which of these attributes are applicable, one has to know at least two things: who runs the nodes and what is the consensus mechanism.
The second rule of blockchain is: Don’t use a blockchain unless you really, really need one
There is, of course, another way to reach consensus on the state of (data in) a network: put someone in charge. A system with a central authority will (mathematically) always be more efficient than fully decentralised, peer-to-peer systems. This is why we have stock exchanges, distribution hubs and eBay, not because the poor people of the twentieth century lacked the technology to build distributed systems.
Therefore, valid use cases for distributed ledger technology (blockchains) are logically limited to situations where there can not or should not be a central authority. With bitcoin, this was the explicit design goal: bitcoin was to be ‘a peer-to-peer electronic cash system’ and bitcoin is arguably the most decentralised blockchain project there is.
Apart from electronic cash, there is a case to be made for the use of blockchains in (online) industries with large network effects and, therefore, large economies of scale. These industries are winner-takes-all, or what economists call natural monopolies. Using blockchain technology, it could be possible to stimulate competition in these markets without destroying value¹.
Also, there is a use case for distributed ledgers in situations where network partners have a need for a common data platform. In many cases, using a common platform is to be preferred to using the platform of the dominant party or a third party provider². But of course there are more ways to create a common platform. SWIFT, for instance, the interbank communications platform, is a cooperative society under Belgian law and is owned and controlled by its shareholders, the participating banks. It is a central authority and a common platform at the same time. SWIFT does not use blockchain, because when there is a central authority, you don’t need blockchain.
Which brings us to rule number three.
The third rule of blockchain is: If a business problem is yours, and yours alone, blockchain is probably not the solution
A blockchain is a tool to reach consensus in situations were there is no central authority. Unless you are schizophrenic, or very confused, internal blockchain applications make no sense.
The fourth rule of blockchain is: Whatever happens on the blockchain, stays on the blockchain
Blockchains are forever. Past entries can not be edited or deleted. This is a security risk in itself. Maybe your transaction is anonymous now, but an attacker has forever to put the pieces together. And there are other risks. Legislation may change in time in a way that makes your censorship-resistant data illegal (GDPR!). Breakthroughs in cryptography or computing may render your encryption obsolete (quantum computing!).
It is probably safe to say that an open blockchain should contain as little data as possible, and instead use (hash) pointers to data stored in places that someone actually has control over. But that doesn’t go well with being censorship-resistant and a “shared single source of truth”.
On a side note: what goes for data also goes for smart contracts. They are out there until the end of times waiting for someone to exploit them, so you better make sure you double check the code.
The fifth rule of blockchain is: The code is only half the blockchain
Every blockchain and every cryptocurrency consists of two parts. There is the code, and there is the decision making process on everything that is not governed by the code, including updates to the code. This second part, let’s call it governance, varies a lot between projects. Bitcoin is quite extreme in its governance model. The anonymous creator gave his project to the world and vanished. Since then no-one owns the project and all changes to the code basically have to be made by consensus. Very time consuming, very conservative. But also completely consistent with the idea of being distributed and having no central authority.
Most other cryptocurrencies have some kind of governing body that decides on changes to the code. Sometimes this governing body holds a large part of the (pre-mined) currency and / or runs some or all of the nodes that verify the transactions. This is of course a serious detraction from the idea of a distributed and trustless currency. Personally, I’d rather trust a bank than some shady entity, typically based in the Caymans or some other place outside the reach of the ECB and the SEC.
Governance is also an underexposed part in many permissioned blockchain projects. Maintenance of the code can be outsourced, but there has to be a protocol for the entry and exit of participants, the assignment of rights, the addition of new functionalities and the resolution of conflicts.
This can all be neatly organised. But there is a paradox here. If there is an entity that you trust with the governance of your blockchain, why use a blockchain in the first place?
This article was written by Ronald Mulder and originally published here.
The article was republished under Creative Commons Attribution 4.0 International (CC BY 4.0)