Is “permissioned” decentralized?
There are a lot of other options to choose from in DLTs: permissioned, private, enterprise, federated DLT, etc. And frankly, sometimes, it is not easy to distinguish between them. Therefore, for this level of discussion, let us compare just DLTs vs. blockchain.
A permissioned DLT and the mentioned variety thereof are not decentralized. There should not be any fallacy around this, as it might be fatal for a project. While some opponents to this statement might claim that decentralization can have a degree, and of course, permissionless blockchain is more decentralized.
Let us put it simply. If there is someone between two counterparties in a transaction, and you can do nothing about this, it is centralized. In a public blockchain, if an ordinary user does not want to rely on a miner for their transaction to be included in a block, they can draft their transaction, and mine a block themself. If the block is valid, the network will accept it. Of course, mining nowadays requires enormous computational resources, but there are no technical or formal barriers to it — you don’t need to seek permission to mine. In DLT, users of the network have different roles and authority, and ordinary users are not able to create and validate blocks. There is nothing wrong with having a centralized system; it is just a matter of understanding what you are dealing with.
Related: What is the difference between blockchain and DLT?
Permissioned DLTs can be decentralized only from one perspective, i.e., by having a consortium of independent members (organizations, companies, etc.) running the network with the exclusive authority to create blocks. Having a few affiliated companies controlled by one beneficiary will not make it decentralized.
And keep in mind, any consortium structure with independent members can be decentralized but only for these members — it will always be centralized for all those outside of the consortium.
Is DLT a cartel?
A consortium (private/permissioned) DLT can be considered a cartel. Sooner or later, an antitrust body may question this. A safe strategy would ensure that the terms and conditions of the consortium were built in compliance with the antitrust laws.
By the way, to be completely centralized system is much safer. But a centralized system will never achieve the same level of reliability and credibility that blockchain can. It will be vulnerable as any other centralized system is, and here is why.
A centralized DLT is not immutable. The ledger can be rewritten arbitrarily by the one (or more) who controls it or due to a cyberattack. Because of its open and competitive nature (mining, staking, etc.), any blockchain can achieve immutability and hence its records will be credible. Thousands of independent nodes can ensure an unprecedented level of resistance to any sort of attack.
Usually, it comes next after the discussion about immutability. How to correct a mistake? What if you need to change your smart contract? What if you lost your private key? There is nothing you can do retroactively — alteration in the blockchain is impossible. What’s done is done. In this regard, the DLT is usually the opposite of an alternative to blockchain. You will hear that DLTs can be designed so that those who control the network verify transactions on entry and therefore, non-compliant transactions are not allowed to pass through. But it would be a fallacy to think that censorship in the network will ultimately exclude all mistakes and unwanted transactions. There will always be a chance for a mistake. Then what? A retroactive change as the last resort? But if you can alter history, you undermine the whole idea of blockchain. No other technology can ensure such a level of the immutability of data. It is not one of the advantages of blockchain — this is its distinguishing advantage.
Related: Circling back to blockchain’s originally intended purpose: Timestamping
Nevertheless, immutability is perceived as something that impedes its legal application. Say, your circumstances changed, and you need to alter the smart contact. The answer to this is the proper design of an application that does not undermine the immutability of the ledger. The smart contract should be designed in a way that the user can attach a new transaction to reflect a change toward the previous one. Blocks are firmly chronological and only the latest transaction will reflect the current state of affairs, while all previous transactions will be a historical reference. You don’t need to change history. The blockchain is a public repository of evidence for everything that happened. There are different methods of designing applications that address all possible legal issues; for example, this and this academic paper proposed solutions to manage property rights in blockchain registries. These issues are also discussed in the series of articles that I published last year.
Permissioned is not blockchain
If anyone questions it regarding your system, they will be right. Further discussion about why permissioned is not a blockchain can be found in this academic paper, but in a nutshell: Not every chain of blocks is a blockchain. Connecting timestamped chunks of data with hashes was invented by Haber and Stornetta in 1991. But nobody has ever called it “blockchain” because blockchain is more than just a chain of blocks. It is about how these blocks are created and validated. Blocks that are created are the result of an open, decentralized and uncensored competition. This is the definition of blockchain and this is what Satoshi Nakamoto designed. Hence, anything that is centralized (permissioned, private, etc.) is whatever but not blockchain.
Unfortunately, anyone is free to attribute the word “blockchain” to any technology they want, as there is no legal copyright or any legal protection to this word. DLT proponents tried hard to erase the boundary between these concepts. But it is only a matter of time until a few high-profile knockdown hacks of private DLTs show the real difference between DLT and blockchain and dramatically change the situation. There is a big difference in how many nodes ensure the security of the network, i.e., a handful of known nodes in the DLT network, or thousands and anonymous nodes around the world in the blockchain network.
We can argue about this on the theoretical level, but when it comes to losing money due to vulnerabilities in the system, nobody will listen to enthusiastic speeches about DLT. People will start asking questions. If you use “private/permissioned,” you should be ready for this.
Related: Blockchain technology can change the world, and not just via crypto
If you still want permissioned
A safe strategy would be to use the word “DLT” in all communications. It might not address possible vulnerabilities, but you can then say: “We had never said it was blockchain.” By the way, ENISA (the European agency on cybersecurity) always uses “distributed ledger” instead of blockchain in their reports. Conversely, their colleagues in the National Institute of Standards and Technology in the United States used “blockchain” in their earlier report.
Do you want to create your own public blockchain network? It is not necessarily a good idea unless you have reliable technology and a robust plan. First, [permissionless] blockchain does not mean safe by default. To achieve a decent level of immutability and resistance to attacks (hence, credibility and a high capitalization of your coin), you need thousands of independent nodes all over the world. If you have enough resources to create your community on this hard path, your network will survive and you will reap the rewards. But what are the odds?
If you are still considering creating your private or permissioned network, think about how this infrastructure will be maintained. If this is solely your network, you can have a solution to this because its maintenance can be covered by the commercial applications that you develop on it. But you have to understand — the network maintenance is completely on your shoulders.
If you have a consortium of members, how do they redeem expenses on infrastructure? In a blockchain, there is a native mechanism to this — cryptocurrency. Independent nodes compete to mine coins. This is how the whole infrastructure is created and maintained. Those who develop applications on the blockchain need to worry about fees, not infrastructure.
But how about your DLT? Is your DLT only for private use among the members of the network? In this case, the end must justify the means, so the reason why independent players on the market created their own DLT network must cover the cost they bear to create and support it.
Consider another story about DLT by members who develop a network for outside users. Inevitably, you will need to design a viable economic model for the network members. No one will spend their resources for nothing or the resources will be applied unfairly — you will end up with a common tragedy. A possible solution to this is to create a native token of the network — say hello to cryptocurrency.
Private DLT o a blockchain?
Is a permissioned/private DLT better than a blockchain? This is not an appropriate question. They are different and their use depends on what you are trying to achieve. But it would be a fallacy to attribute the features of blockchain to a permissioned DLT.
Leading existing blockchains can provide you with reliable infrastructure for an application. The idea that immutability impedes the application of blockchain is a misconception. On the contrary, it is the major advantage as no other technology can provide such a level of credibility to records. Various methods exist to create mature applications without bumping up against the immutable ledger.
A solely controlled DLT is centralized and therefore requires as much attention to cybersecurity as any other centralized technology. A consortium DLT is decentralized for its members, but will always be centralized for outside users (if, of course, the DLT is designed for public use). At the same time, the use of such a DLT can be fruitful in a private application among independent members, but be careful with objectives as it can be considered a cartel and questioned by antitrust bodies.
The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.
Oleksii Konashevych is the author of the Cross-Blockchain Protocol for Government Databases: The Technology for Public Registries and Smart Laws. Oleksii is a Ph.D. fellow in the Joint International Doctoral Degree in Law, Science and Technology program funded by the government of the European Union. Oleksii has been collaborating with the RMIT University Blockchain Innovation Hub, researching the use of blockchain technology for e-governance and e-democracy. He also works on the tokenization of real estate titles, digital IDs, public registries and e-voting. Oleksii co-authored a law on e-petitions in Ukraine, collaborating with the country’s presidential administration and serving as the manager of the nongovernmental e-Democracy Group from 2014 to 2016. In 2019, Oleksii participated in drafting a bill on Anti-Money Laundering and taxation issues for crypto assets in Ukraine.