Permissioned blockchains are a dead end
Don’t do it, the combinatorial complexity is going to kill you
When I’m having discussions with corporate people who are thinking about how to set up a blockchain use case, I hear a lot of concerns about public ledgers: The technology is not mature enough, it’s too slow, we need to protect our proprietary data. I feel like there are a couple of misconceptions though and a key drawback of permissioned ledgers that people underestimate: Combinatorial complexity. So I’d like to stick up for public ledgers and share my 2 cents about the topic.
Blockchain technology has no doubt become one of the most promising drivers of innovation in the past few years. There are serious business use cases, around 2.000 projects listed on coinmarketcap developing solutions for different problems, and already some 80+ industry pilots publicly announced, and probably many times that being worked on. Gartner and PWC anticipate that blockchain-focused initiatives will generate some 3 trillion dollars in business value annually by 2030.
When setting up any new blockchain project, one of the first questions is always about the base layer technology, and whether a permissioned or a public ledger should be used. The key difference between the two is that in public ledgers anybody is allowed to participate in the network. If participation is permissioned, participants are selected in advance and access to the network is restricted to these only.
There are already several blockchain-as-a-service (BaaS) offerings on the market to set up and operate a permissioned blockchain on behalf of clients. IBM is the current market leader with 32%, followed by Microsoft with 19% market share. But also e.g. AWS, Oracle, and SAP have BaaS offerings.
Now let’s have a look at potential benefits and disadvantages of the two models. In my opinion, complexity is the most critical aspect, but I’ll elaborate on that one last, just stick with me for a little.
Regarding throughput (i.e. transaction volumes or TPS), permissioned ledgers are ahead right now. Hyperledger Fabric can process up to 10k TPS, compared to Stellar’s 2k and Ethereum’s 20. This is temporary though: Protocols such as Zilliqa are designed for high TPS from the start, updates to Ethereum (e.g. Caspar, Plasma) will increase volumes, as will layer 2 solutions. So I think it’s fair to say, this will not be a bottleneck anymore soon.
There’s a lot of misconception about privacy. The only privacy that a permissioned network grants per se is from non-participants. Considering that blockchain networks only make sense if there are multiple participants — potentially competitors — there’s little benefit from being private from non-participants. Privacy needs to be solved differently anyway, e.g. through payload data encryption or zero-knowledge transaction. And here, permissioned ledgers actually aren’t that good compared to projects such as Enigma or Tezos.
Control is a tricky one, as the question is who you trust more: Your competitors to play fair or a machine-coded incentive system to work as intended. If you use a permissioned network for monetary value exchange, you might actually loose in case of a participant’s bankruptcy since there are no publicly tradable tokens. A public ledger on the other hand is at risk of being hacked. Let’s call it a draw on this one.
It’s similar when it comes to maintenance of the system. Since it’s not practical to set up and run a network by your own, the decision is between having your permissioned network run by a technology service provider (BaaS) or a public network run by a non-profit organization and a self-governed community. A draw again, it’s a bit like deciding between commercial and open-source software.
The ecosystem aspect refers to further development of the base layer protocols and solutions that are being built on top of it. Since big technology firms focus on permissioned systems, the solutions are more focused on enterprise use. Public ledgers have the much bigger ecosystem though and start to increase their enterprise focus with quite a few exciting solutions.
The most critical aspect though is complexity: Managing the number of networks, and managing updates to networks. If everyone builds a permissioned network with their partners and suppliers, we’ll have a combinatorial explosion of different networks for which each firm would have to manage its membership. And every time a new member needs to be added to a network or a member leaves a network, agreements would have to be updated with the other participants; multiply that by the number of networks. In public networks those aren’t problems, just business as usual.
In my opinion, permissioned networks are dead end, maybe except for very specific niches. I suppose people didn’t notice its biggest drawbacks yet, since almost no projects has moved beyond pilot stage. There is a lot of talk about throughput & privacy, even though that doesn’t really make a difference. Most other considerations such as control, maintenance, and the ecosystem are rather fairly balanced. The key argument though is complexity: In the long run, the combinatorial complexity of permissioned systems is going to be devastating.
Hybrid public / permissioned approaches might be a way out, integrating both permissioned and public systems with one public ledger (e.g. as being built by Aergo). If complexity is managed through the main ledger, you could decide on a case-by-case basis which way to go, having the best of both worlds. Until this is there, better stick with public networks!
