Part 2/2: How Blockchain Protects Your Transactions Data?

[This is part two of a two-part reflection on the topic of Blockchain Technology and Data Protection.]

Last night, I dreamed of the Indirection Oracle. Like Ulysses returning to Ithaca, I tried not to listen to her prophetic predictions, fearing she wanted to lure my ship on to the rocks of this centralized computing system called the cloud... Alright, enough already sharing with you what happens sometimes during my wildest nights where, sound asleep, my brain turns Homer’s masterpiece into a strange version of the Odyssey, Satoshi Nakamoto style.

Now has come the time to address the elephant in the room, and I can assure you that it’s not a small one…

Fact: One of the core benefits of a Blockchain network is that it’s a distributed system, which means that all the nodes in the network are inter-connected and store the exact same data, which is viewable by all the parties involved in the network. Thus, Blockchain brings full on transparency.

Does it mean that on a private Blockchain, where each participant (client) has its own node, all the transactions that have been executed and validated can be viewed by everyone and not just the participant to whom the transactions pertain? If this is true, what are the implications?

Private Blockchain and Transactions: The Nightmare Scenario

The scenario: Company XYZ is a supplier that has created and distributed to Client 1 and Client 2 a decentralized application that runs on a private Blockchain network. Client 1 trades with Company XYZ via the execution of smart contracts, and so does Client 2. In other words, Client 1 and Client 2 are competitors that use the same supplier, Company XYZ.

The scenario applied to a private Blockchain network: All transactions are validated and recorded in every single node of the private Blockchain network. What does it mean? Each stakeholder had its own node: Company XYZ, Client 1, Client 2 as well as any other appropriate participant (a financial institution for example). When Client 1 and Company XYZ engage in a transaction, the data that pertain to the execution of the smart contract between both entities is stored inside the Blockchain, more precisely inside each node of the network. So, not only can Company XYZ and Client 1 view the data, but it also enables Client 2 and all the other participants to view it too.

The seriousness of the scenario above revisited: Will Client 2 see a field with the name “Client 1” clearly mentioned for a given transaction inside its private Blockchain node? Of course not. Client 2 won’t even know which parties have been transacting. And all elements inherent to the transaction will be encrypted. Still, each node (including Client 1’s and Client 2’s) will store the encrypted information, and that may be perceived in terms of business practice as bad, unethical, compromising, you name it.

Does the solution consist in storing proprietary/sensitive information inside a centralized system like a cloud and, consequently, only keep in the Blockchain a minimal volume of data? If that’s the case, so much for investing in a decentralized network! Moreover, at what point does minimal start…?

Best-Case Scenario: A Pretense of Solution?

Instead, how about two pretenses of solution as best-case scenario? Or, could they even be viable?

Solution #1: Keep the data off the chain: Company XYZ adds a new record pertaining to the shipping of merchandise to Client 1. How does Client 1 get access to this information?

• Step 1: The record is stored inside Company XYZ’s ERP system, before being pushed to a cloud-based database that Company XYZ owns. Moreover, a hashed reference to the information is posted to a private Blockchain. This hashed reference includes that Client 1 is allowed to view the information.

• Step 2: The hashed reference that was just posted to the Blockchain triggers a smart contract that grants Client 1 access permission to the data.

• Step 3: The Blockchain confirms that access was granted to Client 1 for this specific piece of information by pushing simultaneously a notification to Client 1 and to Company XYZ’s cloud-based database.

• Step 4: Client 1 accesses the date inherent to the shipping of merchandise from a user interface that talks to Company XYZ’s cloud-based database.

What is the role of the private Blockchain in this structure? It solely serves as an entity that governs and grants access to data stored off the chain. The data is stored off the chain, in the cloud. It is consequently highly vulnerable to hacking. Client 2 and all the other stakeholders will solely view the hashed reference inside their respective node.

Pretense of Solution #2: Smart contract state is known to and validated by only parties to the contract and approved third parties, like regulators: Company XYZ adds a new record pertaining to the shipping of merchandise to Client 1. How does Client 1 get access to this information? Company XYZ has set up one distinct private Blockchain network for each one of its clients. The data pertaining to the shipping of merchandise is stored inside each stakeholder’s node; here, Company XYZ’ and Client 1’s. When a smart contract that solely involves Company XYZ and Client 1 is triggered and then executed, only those two stakeholders can view all the elements that have led to the execution of the smart contract. Thus, Client 1’s node is totally independent from Client’s 2 node or any other entity’s node for that matter. The issue here is that it completely alters what Blockchain is all about: each stakeholder has its own node and the data stored in one node is replicated in all the other nodes for transparency purpose.

Let’s End the Pretense: Comes in the Indirection Oracle

The Indirection Oracle (I bet you were anxiously wondering when I’d finally refer to it? To her…?) is a one-time ID that’s used for authentication in the execution of a transaction.

Let’s take the same example as earlier. Company XYZ pushes to the Blockchain a new record pertaining to the shipping of merchandise to Client 1. How can this confidential piece of information be known solely to Client 1, while being stored in every single node of the network, including Client 2’s? Storing this data triggers a smart contract to which a one-time ID is associated. But the way the ID is generated is what makes the indirection oracle very interesting. This ID is generated off chain and multiple times. In other words, the initial ID is known to Client 1. The indirection oracle changes this ID several times, let’s say twenty times. The 20th ID is then stored inside the Blockchain in all the nodes. No one can figure out what the 20th ID is all about. Thus, Blockchain’s DNA is fully preserved.

To Conclude: What Would a Best-Case Scenario Look Like?

I’m afraid it’s way too early to truly be able to describe a best-case scenario, simply because at the moment there is no regulation around the use of private Blockchains. Once regulators are ready, they will outline the framework of tomorrow’s network. Today, the specificities of a given private Blockchain network are based on the requirements that stakeholders bring to the table. And one major requirement is that one stakeholder’s data cannot be viewed by another. The indirection oracle does bring a potent solution to the problem.

By the way, you won’t find any literature out there about the indirection oracle. So, feel free to drop the name in a nonchalant way, while flipping steaks on the grill at your Memorial Day barbecue party, in front of an audience in total awe...