Solving Blockchain's Privacy Problem

This article was originally published on International Business Times. Read the original article.

Richard Gendal Brown, the chief technology officer at R3, believes IBM should adopt Corda, the shared ledger platform his engineering team has built for its 80-plus member banks.

Brown, who was formerly executive architect for banking and financial markets at IBM and worked there for over 15 years before joining R3, does not make this statement lightly; it follows a close examination of the latest version of Hyperledger Fabric, the open source consortium platform which is IBM's preferred blockchain.

Asked directly about IBM's position in the blockchain space, Brown said: "I think they are actually exercising their strategy pretty well. From a strategic perspective, I think they are doing all the right things. It may well not succeed but it's hard to fault them on that.

"I just don't think the technology is the right architecture. Fabric's design works for some things but actually it's fundamentally flawed in other areas. What they should do of course is adopt Corda; and we will happily work with them on that."

First generation enterprise blockchains have taken the underlying design of Bitcoin and Ethereum and been met with the thorny problem of data privacy. Brown says there are basically two distinct ways to solve this.

One is the Corda approach, which is doing data distribution on a case by case basis—individual deal, trade, balance, loan agreement etc—sent only to those who need to receive it. "You send the data to them and just that amount of history that's needed for them to verify to their own satisfaction that everything is correct. It's atomic, precise, narrow; you just send those pieces."

The other approach is to layer on some additional privacy. Fabric arrives at private data sharing between two or more participants via its privacy channels, a method which Hyperledger says still allows "the veracity and the integrity benefits of writing things to a chain".

In Brown's analysis, adding additional privacy channels, might work for a platform such as Slack, but it isn't an elegant solution for industrial grade financial requirements.

He said: "Rather than having one blockchain where everyone sees everything, there are lots of different ones where each person can see everything in the channel, but nobody else can.

"On its face, it seems quite sensible and could work, and for some scenarios it absolutely can. But only if you know that the data you are collaborating on will only ever be between that fixed set.

"The question is what happens if there is something that we have collaborated on—we have done some deal—and I want to step out of that deal and bring someone else in. How do you do that?

"I can't just let that person into that channel. Sure they would see our deal and the history of it, but they would see everything else as well. All the other stuff we worked on, all our other private deals would suddenly be visible to this person."

Potential solutions, such as arranging for assets to cancelled in one channel and reissued somewhere else are cumbersome, noted Brown. "We considered this architecture and chose not to go with it. While it undeniably does solve some of the problems of full broadcast blockchains, when you actually look at how you would complete asset transfers or complex netting scenarios for example, it begins to struggle."

Another issue flagged up is Fabric's choice to use noSQL databases as a default. R3 has spent a lot of time optimising Corda for integration with the existing systems used by financial entities. "That's why we run on the Java platform," said Brown. "It's why our interfaces are well documented and easy to use; we stream information out for people who want real time updates. It's why we use things like message queues because that's what enterprises use to get data in and out."

He pointed out that a node in the future will become the authoritative record for many of the deals a firm has done. "So what do you do with your authoritative records? You need to query them, you need to aggregate them, join them with other data.

"The gold standard is relational databases. It just seemed obvious to us as we worked through the requirements that Corda should store its data in a relational database and allow the information to be queriable and joinable.

"We considered NoSQL databases—key-value stores or document stores, but the requirement to use one just didn't emerge. Say I store all my data in one of these NoSQL stores—if the first thing I have to do is extract it all and put it somewhere else to query with my main data, it doesn't feel like a step forward."

An argument sometimes levelled at Corda's truncation of blockchain broadcasting is that this forgoes some kind of system wide integrity; if nodes dropped off or went down, for instance, there would be no blockchain record to refer to if only counterparties to a transaction have a copy of that transaction.

"There seems to be a belief—a mistaken one in my opinion—that blockchains are also a backup solution, or a disaster recovery solution," said Brown. "So if I put my data on this blockchain, then there's no need for me to worry about high availability or backup.

"Of course, that seems obvious to anyone who has ever played with Bitcoin. However, if you speak to anybody operating an exchange, anybody operating any kind of service on that network: they have got their own private data and customer records, impending orders all that kind of information.

"The blockchain is just a subset of the overall data they manage and the fact that some of it is on the public blockchain in no way obviates the need to make sure their own private data is being properly looked after.

"And it's the same in the enterprise blockchain space. If you and I enter into a deal; you've got a copy, I have got a copy. If my node goes away, I can get the data back from you; or from the consensus cluster and so forth if that's how you want to configure your network.

"Backing up my shared state in the same way as I back up everything else is really no hardship. The criticism I hear of Corda that the data is only held by these people and therefore it has low resilience - I just don't accept that argument."

R3's ongoing work with Intel's Software Guard Extensions technology (SGX) has resulted in another way to deal with the contradiction between privacy and verification at the heart of distributed ledgers.

SGX allows software to compute on private, encrypted data without revealing that data to the owner of the hardware. You can send someone data you don't want them to see, they can run a computation on that data, and they obtain only the result but not the inputs.

Corda's transaction verification layer has been engineered to run in SGX. The verification function is the inner sanctum of the platform, which looks at a transaction or a chain of transactions and says 'yes', the business logic has been executed correctly.

Only the verify function needs to run in SGX, everything else can run on normal chips, without those constraints, said Brown. In terms of engineering, to build this is not a trivial undertaking; it requires deep knowledge of operating systems and hardware architecture.

"We have got a full java virtual machine running in SGX, validating and verifying Corda transactions, and that's no mean feat; we are very proud of it."