How I Lost My Faith in Private Blockchains

Angus Champion de Crespigny is an advisor to various companies and projects on bitcoin, cryptocurrency and identity infrastructure. He spent 11 years at EY, with the last four consulting on blockchain and crypto assets until his departure in August.

Since 2015, while there has been a myriad of permissioned blockchain announcements from enterprises, questions have been raised as to the long-term viability of these projects. A common theme in the small number of projects that have gone live is a disconnect between an understanding of traditional industry and the technical understanding required has made the value difficult to define.

While there is most certainly a disconnect between business processes and the technology, rather than limiting the development of business cases, I believe it has in fact led to the opposite problem: unjustified beliefs and hype of what the technology can do. I also believe it remains to be proven if permissioned blockchains provide a real business benefit at all.

The reason I question whether there is a benefit is that I spent four years working with financial institutions who were trying to find it.

While in the first couple of years I was optimistic of their potential, as more and more use cases were objectively evaluated and failed against other technology, I objectively assessed the technology against alternatives and reevaluated my assumptions. What this led to is a shift to advising clients to leverage technology better suited to their problems, and a greater a focus on public blockchains and crypto assets.

The challenges I found in applying permissioned blockchains in industry came down to the following: definition, differentiation, process impact, and necessity.

Definition

The difficulty in describing the challenges with permissioned blockchains begins with the difficulty of defining what it is.

At its most basic level, a blockchain could be defined as a data structure, or simply a chain of blocks. However, this definition is rarely what people mean when they talk about blockchains.

Typically, discussions around blockchains talk about consensus and reconciliations, due to the original permissioned blockchains that were forks of bitcoin or ethereum being used in a private manner. As time went on, different consensus algorithms were introduced, as well as different ways to store data that no longer used blocks to share data globally, such as R3's Corda. Consequently, the term "distributed ledger technology" emerged, which people would put in the same bucket as blockchains.

Every few months, a government agency somewhere around the world tries to define blockchain or distributed ledger technology for regulatory reasons. A common theme, however, is they rarely define it in a way that differs from a distributed database or even more simply, Google Docs. And if it can't be differentiated in the definition, then it shouldn't be considered different at all.

So, to be as specific as we can, in this article I will be discussing technology that shares data with other parties in a way specifically designed to prevent central control. If you have the ability to centrally control, you have a database, and it should be assessed and compared as such.

No doubt there will still be nuances that this definition misses, but that is part of the problem of the industry: large claims of potential benefits are made, without defining the tool. And if we don't define the tool, how can we say that it's right or wrong?

Differentiation

Going with the above definition, a blockchain is typically touted as a beneficial system due to its ability to store and communicate data, with redundancy and protection from loss. The data is automatically reconciled across a large number of parties, allowing virtually instant data transfer and tracking. The data can never be changed and the data is fully transparent to prevent fraud.

Alternatively, if needed, you can encrypt the data so none of the other parties can see it. Finally, it allows you to run complex programs, perhaps even resembling legal agreements, that all parties can see and gain comfort that they will execute in a particular way.

The interesting thing here is that everything that has just been described is all achievable with a distributed database: technology that is widely used in industry, and was around for many years before bitcoin was released.

There is, however, one key difference between the two technologies that we've included in our definition: blockchains are specifically designed to prevent central governance.

This feature doesn't come for free, however.

In a blockchain, every node stores all data. Every node runs every program, and every transaction is sent to everyone across the network. To make changes to a blockchain, new blockchain software would need to be created and distributed to all participants who would need to install over their current version. Each of these requirements adds a non-trivial technology and governance cost to the deployment and ongoing operation of the blockchain.

By comparison, to make changes to a database, the administrator makes the changes in the master and they instantly propagate across all nodes. Computation, also, is optimized. In a distributed database where all participants can have a copy of this data and any applications running, they would be able to monitor and review for any unauthorized changes or updates.

It may, therefore, be easiest to think of a blockchain as a distributed database with the ability to administer it taken away.

The key question to ask then, is what are the reasons an enterprise would prefer to sacrifice many measurable metrics – transactions per second, disk space, speed and efficiency of computation, cost of maintenance – and opt instead for deploying a technology that is harder to administer?

Process impact

At this point, the argument that is typically used is that the removal of central governance is beneficial when doing business with entities who you do not trust. I am skeptical of this argument.

Businesses conduct transactions with other entities all the time, and they establish contracts for these purposes. A blockchain is not going to remove the need for a contract, and there's been little evidence to suggest that such contracts can be encoded with all the nuances required of the law.

Another argument raised is that decentralizing the ownership can allow a shared capturing of value. A recent tweetstorm by Alex Rampell, Partner at Andreesen Horowitz, expressed this sentiment, where he hypothesized that the banks would not have lost the upside of the Visa business and fallen behind had they deployed it as a decentralized ledger.

Why could the same upside not have been captured by the banks by simply maintaining stock in the spun-off business, and allowing the business to grow in the most efficient way possible? A distributed ledger hypothetically may have allowed the banks to maintain a hold on Visa, but I believe it's worth taking note of the other side of this coin: the technology would have restricted it from being the most technically efficient business it could be.

A somewhat different view I have heard is that blockchain technology is the future, and therefore while we cannot quantify the benefits, it is worthwhile moving to the new paradigm to stay ahead of the curve.

Putting aside the obvious risks of attempting to predict the future, the trouble with this logic is that it assumes that "blockchain" is one big nebulous technology, and that moving to a blockchain is the key component, rather than what that future actually looks like and adjusting your product to fit that future.

Without knowing the shape of that future, it is a significant technology investment and sacrifice onto a closed network that may or may not pay off.

Is this really necessary?

Let's say the decision is made to go ahead with a permissioned blockchain project. To implement the technology, the entities need to define the rules of the blockchain. To do this, a project typically progresses as follows:

• Decide to develop a blockchain application
• Establish a consortium of interested parties to centralize investment and coordinate decision making
• A trusted central party has now been created to govern the development of the blockchain.

When stage three is reached, there is now a trusted central party that will define the rules of the blockchain and define how updates are made and distributed, and all interested parties will accept the outputs of that trusted party.

If all entities trust a central party to define standards and distribute updates, what is the benefit of a blockchain over a distributed database managed by the trusted central party? The members of the consortium have a legal relationship with the trusted central party and are accepting any necessary maintenance by default: why not use a far more efficient data management system?

This comes back to one of the key value propositions that people are sold on: that this technology can help multiple parties coordinate on a problem with many data points. Where this falls down, however, is that coordination is a human problem, not a technology problem.

By the time coordination with all involved parties has taken place, the major problem is typically already solved. Consequently, additional technology is not needed, and certainly not technology that's incredibly costly in its enforcement of that goal.

You can't force decentralization

What much of this comes down to, is the fact that you can never be half decentralized: any level of centralization will end up with the system coalescing around that central point of management.

The business and legal worlds operate from an aspect of centralized entities, and while that remains the case, any forced attempts at decentralization are likely to come short. While it is possible that in the future we may see decentralized businesses, they are far more likely to come from the public blockchain world where they are able to grow organically in an entirely new paradigm.

In the meantime, institutions and individuals should be evaluating permissioned blockchains like any other technology: it isn't magic, and it should be assessed like one would assess any other. The benefits of a technology should never be assumed based on buzzwords, hype or fear that "everyone else is doing it so why shouldn't I?"

Instead, benefits should be assessed by asking what is the business problem, what are the different technology options available, and what are the quantifiable costs and benefits of each. There is no reason why an institution should change its technology selection approach for the sole purpose of blockchain projects: they need to be discerning and choose the technology that can demonstrably solve the problem for the lowest cost.

To date, I have not seen such an analysis undertaken.

Smart businesses will evaluate whether their problem can be solved and at lower cost on a database or a public blockchain, and press those selling the technology for a demonstrable burden of proof.

Stained glass image via Shutterstock