Devon Allaby

The Trust Trade-Off: Permissioned vs Permissionless Blockchains

By Devon Allaby, Business Designer at Fjord Australia.

As the media frenzy surrounding Bitcoin fades from the front page, the enthusiasm for Blockchain has remained stalwart. However, the transition from Blockchain as a conceptual topic to a technology with a solid developer community and production ready deployments has given birth to some interesting design debates – one of which is the permissionless vs the permissioned Blockchain model.

What’s the Difference?

If you’ve heard people talking about Blockchain in a general sense, most likely they were talking about a permissionless Blockchain. This model is what general public are familiar with because the most famous Blockchain projects (Bitcoin and Ethereum) are permissionless Blockchains – meaning that anybody can create an address and begin interacting with the network. The other reason this model is the more widely discussed of the two is because the characteristics of a permissionless Blockchain (decentralised, anonymous and equally accessible to anyone with a computer) are the characteristics that aligned remarkably with political movements that began to gain serious ground after the Global Financial Crisis in 2008.

In contrast, the permissioned Blockchain is a closed and monitored ecosystem where the access of each participant is well defined and differentiated based on role. They are built for purpose, establishing rules for transaction that align with the needs of an organisation or a consortium of organisations. The permissioned Blockchain isn’t looking to overthrow the political system, or remove the need for established financial institutions. Instead it leverages some of the other core elements of Blockchain architecture (immutability, ability to grant granular permissions, automated data synchronisation, rigorous privacy and security capabilities, process automation) to create efficiencies, reduce cost, and open up opportunities for new data-driven business models

The Trust Trade-Off

So what’s the deal? Which is better, and why?

There are benefits and drawbacks to each approach, but all these considerations boil down to one fundamental design trade-off: the ability to create trust and the ability to scale.

The more valuable it is for the Blockchain to create trust amongst participants, the more computational power is required to support that trust. The Bitcoin network is a fantastic example of a situation where Blockchain was valuable precisely because it was able to create trust in a naturally distrustful situation. In exchange for the privacy assurances granted by the technology, a transaction fee accompanies the transaction to reward the miner that solved the cryptographic proof which allows the transaction to be committed to the ledger. For an individual user making the occasional transaction, the transaction fee is very small amount that is happily exchanged for the benefits offered by a Bitcoin transaction. However, if you look at the aggregate consumption of the network, the computational power required to cryptographically verify and synchronise every individual node in the network is staggering. The total power used to conduct these verifications on the Bitcoin network is currently greater than the energy consumption of Ireland.

So what if we want to implement a Blockchain where a governing authority provides inherent level of trust between participants? Let’s imagine that a group of financial institutions that have entered into a partnership decide to implement a Blockchain based infrastructure to manage its debits/credits between themselves. A permissionless Blockchain could help one participant in Australia to keep track of assets lent to a partner institution in North America, but the governing authority would have to pay the transaction fee on millions of transactions to manage exchanges of value between participants who should inherently trust each other due to offline relationships. In this scenario, the use of heavy computation to create trust is not just redundant, but commits the even more serious crime of being expensive. To make things worse, the computational power per transaction on a basic value transfer is nothing compared to execution of smart contracts, which execute an entire program for each transaction. As the use cases become more sophisticated, the impact on cost, speed and throughput become untenable.

Enter the permissioned Blockchain. The inherent trust enables design decisions surrounding cryptographic difficulty and the use of a partial vs a full distributed ledger to reduce the amount of computational power required. Authority and trust created outside of the networks ensures that participants trust what is committed to the ledger, while almost all of the logistical issues (cost, speed, throughput and contract sophistication ceilings) with creating trust artificially disappear. The managing body can ensure data access so that only participants that are party to a transaction can see sensitive details, a feature deemed rather important according to modern enterprise security standards. Additionally, automation of labour intensive business processes can be built-in using smart contracts.

What does the Future Look like?

When it comes to examining permissioned vs permissionless Blockchains, it’s not a matter of which is “better”. For many enterprise use cases, a permissioned Blockchain can meet business requirements that are simply impossible to meet with a permissionless Blockchain. In contrast, some of the incredible use cases for industry disruption, disintermediation and social infrastructure by nature require an open, public Blockchain. Accordingly, presumption to evaluate either in the absence of a well-defined use case is a fruitless exercise.

Luckily, it is highly unlikely that at some point we will have to choose between these two models. The reality is that the future will be one of many chains – with as many different characteristics as there are use cases. The decision between a permissionless and a permissioned model will be only one of plethora of design decisions around consensus mechanisms, smart contract language, integrations with existing information sources and more.

The real challenge will trying to underpin all these differences with common code. The Blockchain community is well aware of the fact that without interoperability standards it will be difficult for any platforms to truly gain traction within established industries. The rapid establishment of multiple consortiums to examine governance and standards in Blockchain development are evidence that efforts towards this goal are underway. Although the industry is still in its infancy, I would bet on a future where we don’t have to choose between our aspirations for decentralised connectivity and enterprise efficiency.

Devon Allaby

More Stories from Fjord