Decentralization has become one of the most misunderstood concepts in the blockchain world. As one of the key elements in the first blockchain killer app – Bitcoin – the term has taken on a life of its own. For many, the concept of decentralization has become a holy mantra that must be applied to all aspects of a “good” blockchain solution.
Part of the problem with the term “decentralization” is that in the blockchain world, it can apply to multiple aspects of a solution. In each, its meaning and consequences are different. And, depending on the application, the appropriateness of decentralization in each of its aspects can vary. In contrast to widespread beliefs of many blockchain enthusiasts, decentralization is not good in its own right. It is a valuable tool to mitigate particular risks that may apply to blockchain solutions.
I will describe the various ways that decentralization can be applied to mitigate risk blockchain solutions and discuss when and where it is appropriate below. But first, it is important to recognize that:
The essence of a blockchain solution is centralization.
The role of a blockchain solution is to create a single source of truth that can be trusted by all of its participants. While this single source of truth may be replicated in hundreds of places, it remains a single (and, thereby, centralized) source.
With this basic understanding, let’s look at the various ways that decentralization can be applied to mitigating risk in blockchain solutions. I posit that there are at least three separate problems for which decentralization may be a viable risk mitigation technique in a blockchain solution:
1. Hegemony
2. Single Point of Failure
3. Single Source of Vulnerability
We discuss each of these separately below.
Hegemony
The most important problem that decentralization can solve is hegemony. In the Libertarian tradition that seems to be at the heart of the blockchain movement, there is a resistance to having any single entity control the application. This is likely an element of human nature. We are wont to cede control of things that are vital to us, if it can be avoided.
Bitcoin is an excellent example. Bitcoin enthusiasts typical herald the independence of Bitcoin from the political agenda that can play a strong part in the valuation of fiat currencies controlled by a sovereign nation. When the US Federal Reserve wants to foster employment in the US, it can devalue the dollar (e.g., by reducing the interest rate paid on dollar-denominated funds held overnight). Investors in the dollar are thus vulnerable to this loss in value based solely on actions of the sovereign owner of the currency.
Such hegemony is not limited to cryptocurrencies. As we have been witnessing in the banking industry, there has been much jockeying for control of interbank payment applications under development. Because of the concerns that control of such an application would confer too much power on the owner of the application, banks are allying with partners to have some say in a collaborative solution in which control of the application is decentralized among the alliance members. But because each member, ultimately is seeking advantage, alliances, such as R3 and the Enterprise Ethereum Alliance, have experienced ongoing membership churn and varying levels of commitment by their members.
In the pharmaceutical industry where a blockchain application may prove to be a powerful solution to compliance with the US Drug Supply Chain Security Act (DSCSA), industry members first solution requirement is that any solution not be controlled by either a single company or even a group of companies (e.g., an alliance of distributors).
The reasons that potential participants cringe at the potential of hegemony manifests itself in three ways:
1. Data ownership
2. Data validation
3. Market manipulation
Data ownership
If a single entity (e.g., a sovereign nation, a business enterprise, or an alliance of businesses that doesn’t comprise the full membership of the user community) controls the blockchain, those members not in control fear abuse by the application owner. This abuse can come from the owner exploiting competitive intelligence gained from omniscient access to the data (because the owner may by privy to the identifiers assigned to the other users).
In a stock or bond trading application, the owner may use the data to front-run other trading partners. That is, the owner may place himself into the middle of trades between other trading partners, exacting a markup on each trade.
Data validation
If a single entity controls the validation of blockchain transactions, their ability to create false transactions that serve their own interests becomes available. Or they could change the time ordering of transactions to allow them to “past post” certain transaction to cover for their exploitation of their information advantage.
Sticking with a stock market example, if a large buy order comes in with a limit of 53 when an asset is currently trading at 51, they may buy up the asset at 51 and only after moving the market through such purchases, resell it to the true buyer at 53.
Market manipulation
Exercising control over the application, the owner may place its own interests above those of the other users. For example, the owner of an application for matching and clearing stock or bond transactions may limit the matching of bids only to their own trading desk. They may even go so far as to arbitrarily raise or lower the price of an asset to better exploit their proprietary trading positions in certain assets.
The owner may choose to unilaterally alter the rules that govern the blockchain application. Raising transaction fees once other partners have committed substantial investments in use the system would be one example. Or they may place limits on the ability of some users to freely transact. They might also change the prioritization of certain transaction.
Another manipulation technique would be to delay reporting of current prices in order to exploit the changes in prices that may occur during the gap. This is similar to “past posting” in horse racing. If the owner delays information on the price of an asset, he can transact without risk knowing that the market is moving in a particular direction while other members are unaware of this movement.
Decentralizing ownership of the application can resolve each of these problems. But decentralization need not imply that the blockchain is public. A permissioned blockchain in which all members have a say in the governance of the blockchain can provide sufficient decentralization to address the hegemony issues.
Single Point of Failure
A centralized solution – one in which there is only a single copy of “the truth” is always vulnerable to the failure of the system. Failures such as power shortages or natural disasters can cause a centralized solution to fail. Even if the solution is governed by a large number of users, failure to decentralize the servers and the data themselves, subjects the solution to significant risk. In a solution for which the infrastructure is centralized within a particularly country or region, it may be subject to being shut down by political action or acts of war.
By decentralizing the infrastructure and the data and distributing it both geographically and internationally, much of this failure risk can be reduced. But this can be done with a single owner data file or by a file shared among a small group of “permissioned” members. Many enterprises today maintain multiple copies of critical data that a geographically dispersed to ensure that they can continue to run their business even when one or more sites suffers from a disaster — be it man-made of an act of nature. While the argument can be made that “more is better” and that distributing data to every possible user is safer than maintaining only a handful of copies, the risk is diminished only negligibly after a handful of copies are deployed, and the support costs rise arithmetically with each new instance. Even though no central owner has to pay these costs, there is a cost to the owners of each copy for storing the data, the network link to keep it up to date, the computing power to read and write the data, and the electricity to run the node.
Single Source of Vulnerability
Data security is a critical element of most blockchain applications. The value of having a single source of truth is negated if the truth can be manipulated by adversaries out for their own gain. Even organizations with some of the strongest data security processes have been compromised by such adversaries. If the blockchain ledger is held in one location, a determined adversary is likely to be able to gain access to it and could alter it, compromising its value as a source of truth.
By distributing copies of the continuously updated ledger to many locations, adversaries have to penetrate each location and alter multiple copies of the data structure in real time in order to falsify records. The more copies of the current data that exist, the more difficult is the task of an adversary seeking to falsify the records.
The Single Source of Vulnerability problem is similar to the Single Point of Failure problem. Both benefit from maintaining multiple copies of the data in different locations. The difference is that the security employed to keep adversaries out of different nodes is different, further reducing the vulnerability of the data to tampering. Because most nodes are independent of one another, they often use different computing systems, with different operating systems, and employ different security techniques. This increases the difficulty of manipulating data on multiple blockchain nodes. The adversary has to be able to penetrate each node with their different defenses and still be able to alter the data on at least 51% of them at the same point in time. This is very difficult when the nodes are independent of one another and use different hardware and software.
The task becomes a bit easier, however, if a large percentage of the validating nodes are using similar equipment. Because adversaries need only alter 51% of the nodes to alter the blockchain, there may enough of one type of security infrastructure in use that it could be done. But more important is the fact that this “defense-in-depth” — the use of different security tools and procedures at different points in a system — could be deployed by a private blockchain as well. If a blockchain owner (individual or group) elected to distribute the hosting of their validating nodes on a variety of clouds (e.g., Amazon, Microsoft, IBM, Oracle, etc.) they could create a similar level of protection. Arguably, such a system may be more secure because the major cloud service providers each employ strong security to protect their clients and their reputation. Validating nodes on permissionless blockchains may be much easier to penetrate — even if there are more of them.
Jeff Stollman is Principal Consultant at Rocky Mountain Technical Marketing, Inc. He has been working in the blockchain space for over three years, assessing the technology, designing enterprise blockchain solutions, and developing go-to-market strategy and white papers for other blockchain projects. He has four patents pending in the blockchain arena.