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. As Nick Szabo points out, this 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,
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
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
The inability of smart contracts to execute on all nodes within a
Sexy Database or Intranet Redux?
Will
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.”.
However, perhaps a better analogy was made by Marc Andreessen when he
[…] it’s helpful to ascertain beforehand whether such courses are geared toward permissionless or permissioned (private) blockchains. The resource list below includes […]