Why Permissioned Blockchains Fail

Most people, when they first start exploring blockchain technology and cryptocurrencies, operate under the assumption that blockchains are universally decentralized ledgers with immutability, and are censorship resistant. However, it is important to note that blockchains can be; permissioned or permission-less, centralized or decentralized. Their use and type are specific to the kind of vision the protocol developers or the institutions hosting the blockchain have.

Are permissioned blockchains real blockchains? Do they have a role too?

Permissioned blockchains are blockchains, sure. What they are not is open blockchains or permissionless blockchains. They are blockchains, they just don’t have any of the interesting features we find in open blockchains.

Some of the features that people ascribe to blockchains, are not features of all blockchains. They are features of open, decentralized blockchains. For example, immutability is about recording something and having a guarantee that it cannot be changed later, even if verifiers are coerced into changing it.

Bitcoin is a system that provides the immutability guarantee. Even if 100% of the miners wanted to change the blockchain, or were being coerced to do so, they still must expend the proof-of-work energy, or risk their blocks being invalidated by the rest of the system. There is no shortcut.

Proof-of-work, and the decentralized nature of the consensus algorithm, creates immutability. If you have a system of federated signers, you have a permissioned or private blockchain. Let’s say you have a group of sixteen signers: sixteen members of a coalition, the largest participants in a stock market or bank transfer network – they are all federated signers.

If you serve a subpoena to all sixteen of them and say, “You must change this transaction,” or “Make sure this transaction never happens,”

“This transaction back in January was paid to WikiLeaks and we don’t like that.”

“Here is a court order that says the transaction never happened. Please amend your blockchain.”

The federated signers can do that; if they can do that, then under the law they must do that. It is no longer immutable, no longer censorship resistant, no longer neutral, no longer borderless. These federated signers are subject to the jurisdiction of whichever state they are in. They can’t open it up.

It is no longer permissionless because they must vet every participant. The issue here is, once you take out the decentralized nature of validation in the consensus algorithm, then a lot of the things you think blockchains do – giving you censorship-resistant, neutral, permissionless, immutable transactions – go away.

What you have is a distributed database for recording transactions, if the federated signers want to allow it; something that is not immutable, censorship-resistant, neutral, borderless, or permissionless anymore.

Is that thing useful? It depends on what you are trying to achieve. If the application you’re trying to achieve doesn’t need censorship resistance, neutrality, borderless access, or immutability, then maybe it is useful. Of course, you will have other challenges.

In an environment of federated signing, you have the problem that the signers are usually competitors.

Therefore they will try to tweak the system to give themselves maximum advantage. In a decentralized blockchain, the self-approach (where everyone is assumed to act purely in their self-interest) is the basis of the game theory that makes it secure.

As long as everybody acts in their best interest, the system is actually fair, predictable, and secure. That is how proof-of-work works. It assumes that everyone will act purely in their self-interest, but because they’re constrained by the rules of the system, they are forced to operate it honestly. Honesty is in their best interest.

However, in a permissioned system, if the federated participants are acting in their own self-interest, you have a problem because they can be identified and coerced. They have to participate in a collaborative manner while being competitors, so the incentives are misaligned. You can see this every time you look at an industry trying to create common standards by committee. They may start off with good intentions.

”Let’s make a new standard for how we do financial exchange protocols.”

As the participants get together, each one has a vision of what will be in their best interest, and try to add that to the standard. The standard gradually becomes more complex because of this jockeying for position.

In the end, it is not really a standard, but a wishlist collection and kitchen sink ‘bikeshedding’ that happens. These standards don’t get applied in the real world because they’re too complex. There is too much opportunity for one party to take advantage of another.

A classic thing you see in protocol development is big companies coming together to build a common standard, while their lawyers are in the background filing patents for those same things, in order to gain an unfair advantage. This happens all the time. You see, over decades of attempts to [make common standards in banking, this continue to collapse.

Whenever the standard is designed by committee, all this jockeying for position results in a mess. Theoretically, permissioned blockchains with federated signing based on a common standard would bring the industry together, create more collaboration, allow banks to have faster and fairer networks for transactions. In practice, they never get there because of squabbling and jockeying for position internally. They end up creating either a terrible standard that doesn’t serve anyone’s needs, or a standard that nobody uses because they feel they will be at a disadvantage because the standard mostly expresses somebody else’s interests.

We have seen this again and again, most recently with R3 and their efforts to create standardized financial services blockchains. Again, all the prototype implementations have not succeeded. We saw this with internet protocols too. TCP/IP was not the obvious winner. Today, it is clear that the internet is TCP/IP. But back in the early ’90s, the conversation was very different. People said TCP/IP would be an interesting – but edge – case of the information superhighway, which would be primarily based on robust enterprise protocols like the ISO, OSI, TP4 for example.

Protocols like ATM and those proposed by IBM, Microsoft, and other companies. TCP/IP was a small corner of the information superhighway, mostly used by academics.

TCP/IP wasn’t really suitable for enterprise because it didn’t have enough features that enterprise wanted. Where did we end up? The “information superhighway” is a silly term that people laugh at today. The internet is TCP/IP. You have probably never heard of the other protocols, TP for an ATM and the OSI stack. You probably don’t run ISDN. Those were proposed by the telecom companies.

All of these things went to the wayside. Why?

The value of the internet came from open, interoperable protocols where no one had a distinct advantage. We will see the same thing happen with blockchains.


About 10 years after Satoshi Nakamoto shared the white paper for the world’s first decentralized, peer-to-peer network sharing protocol and digital currency, there have spawned numerous different blockchain protocols and cryptocurrencies in the market. Decentralization, along with immutability and censorship resistance were the key defining features of the Bitcoin protocol, and set the standard of thought when it came to blockchain technology. However, there was no hard and fast rule that future protocols should follow the same rules of consensus as Bitcoin’s blockchain.

Private blockchains are more restrictive when it comes to who is allowed to make changes to the ledger. They are generally used by private enterprises that leverage the network for their internal business operations.

This article is a transcription of Andreas Antonopoulos’ explanation on Why Permissioned Blockchains Fail.

Want to share your thoughts on this?