What Is A Permissioned Blockchain?

What if you could have your very own blockchain? One in which you set the parameters as to who could join. Where detailed information about every transaction could be accessed and exchanged between companies, and where financial institutions – not miners – validate these transactions. That is, more or less, the premise behind permissioned blockchains.

In essence, it’s blockchain technology as favored by centralized organizations, and as such, it’s the current darling of established tech and financial service companies. Particularly the latter, as it makes complying with Anti-Money Laundering and Know Your Client laws much easier. However, any consortium of companies may create a private blockchain. And far larger and more diverse private blockchains are beginning to emerge as well.

The Desire for Control

Financial institutions who seek to implement permissioned blockchains simply want to “have their cake and eat it too”. That is, they desire all the advantages that blockchain technology offers – namely fast, cheap, and immutable transactions – without the anonymity afforded to node owners (transaction validators). Instead, these institutions typically replicate existing structures where a trusted intermediary exists (they just can’t let go!). As blockchain pioneer Nick Szabo notes,

“[Bank] bureaucracies are so heavily invested in the expertise and importance of local regulations and standards that it’s extremely difficult for them to cut the Gordian knot and implement seamless global systems. So they keep trying to re-inject points of control, and thus points of vulnerability, into blockchains, e.g. through ‘permissioning’; but this nullifies their main benefits, which come from removing points of vulnerability”.

Alas, the desire for more control is ultimately counterproductive. Which, as Nick Szabo points out is ironic, given that the auditors, accountants, and others who currently serve as financial controls are already decentralized. But that’s missing the point, Nick argues, as the blockchain is meant to move us past the “mutually untrusting national silos” that currently exist. Banks that fail to embrace this mindset will simply be duplicating the “centralized payments networks we have right now, without the benefit of the network effect of bitcoin” (Jon Matonis).

Unique Security Concerns

By their very nature, permissioned blockchains are perceived as being more secure than any public (permissionless) blockchain. After all, as these companies reason, its now under their control. Unfortunately, it’s this very sense of internal control that makes a permissioned blockchain far less secure. In general, permissioned blockchains are prone to a variety of security vulnerabilities.

Collusion: Given the scenario above, for instance, transaction blocks can easily be altered after the fact – and without approval from the other nodes. Such alterations would be relatively easy to make in permissioned blockchains operated by small consortia.

As MIT professor Christian Catalini notes,

“If the nodes collude, or nodes are compromised, you can just rewrite history. So if you’re a regulator, maybe you wouldn’t want a set of banks or a set of financial institutions to be able to collude and rewrite the ledger. It’s not even a 51% attack – they already have the keys to the dataset, so you may not even need the majority to fool the system.“

As with any closed system, governance over security protocols is prone to arbitrary decision-making. And, as history has shown, collusion among financial institutions is always a risk when survival is at stake.

Insider Threats: Another serious risk is malicious behavior from the holder of the Administrator Certificate. He or she typically has free reign over the blockchain. And with this authority, they can add or revoke access, blacklisting certain identities, and manipulate the amount and type of access a given identity has to the blockchain.

Lax security: Unlike a fully decentralized blockchain, a permissioned blockchain is prone to conventional network attacks. In the Hyperledger fabric network, for instance, Membership Service Providers (MSPs) provide the credentials to access a permissioned blockchain. Clients use these credentials to authenticate their transactions, and peers use these credentials to authenticate transaction processing results. However, MSPs are prone to a DNS attack when creating such identities.

Likewise, MSPs that improperly store private keys are vulnerable to private key leakage. With a private key, a bad actor has unlimited access to the blockchain, allowing for secondary attacks to occur. In addition, private key leakage can “lead to more serious attacks, such as man-in-the-middle

attacks, replay attacks, message tampering attacks, and identity

leakage attacks” (Davenport). Being that MSPs are a centralizing aspect of an otherwise decentralized system, they significantly weaken security within a permissioned blockchain network.

A Word About Smart Contracts: Smart contracts serve as another vulnerability point in permissioned blockchains. Since the latter rely on asynchronous Byzantine Fault Tolerance replication protocols to establish consensus, they reveal their low-level trust assumptions ( 3f + 1 consensus formula) to smart contract applications. Unfortunately, few smart contracts are set up to reason about such assumptions.

The inability for smart contracts to execute on all nodes within a permissioned blockchain is another serious problem. Ultimately , any smart contract that fails to execute properly is, in effect, mounting a denial of service (DoS) on the blockchain network.

Sexy Database or Intranet Redux?

Will permissioned blockchains thrive, or even survive? For now, the technology continues to be mentioned in breathless headlines. And with big money comes staying power. Nonetheless, critics continue to assert that the technology doesn’t even merit the blockchain label.

Still, others suggest that the technology is merely an exercise in sexy packaging, a gussied-up alternative to the company database. As Asheesh Birla, product head at Ripple stated “I’ve seen a lot of use cases out there to use permissioned blockchains and when I look at the problem they’re trying to solve, I feel like, wow, there’s a company out there that can solve that problem. That company is Oracle.”.