I'm currently researching the practicalities of implementing a blockchain ledger whereby the company I work for, our competitors, our clients, our clients users (who we service indirectly) and an industry regulator would all need access to some of the information contained in the chain.

The crucial piece of information would be an asset which changes hands multiple times over it's short lifecycle. Publicly the asset would list the owner and would also detail other users who would be listed as having a legitimate interest in the details of the asset. The Owner of the asset would be able to make predefined changes to the asset depending on their role, e.g. client issues asset to user, regulator would approve asset, after regulator verification we (or our competitor) perform an action and would terminate the useful life of the asset in the blockchain.

Would you need to set up a private side chain that interacts with the public ethereum chain to store sensitive information? And would it be possible to restrict access to the information depending on which parties are listed as having permission to view asset details.

My initial thoughts on a design would be to create a distributed database such as the BigchainDB or to use the Openchain project which would store sensitive info and then these would interact with the Ethereum blockchain which lists an asset owner and interested parties. My boss is drawn to the Openchain project but I think a completely private system would lose the benefit of the networks power, which helps prevents fraudulent activity and helps to prevent the existence of there being a single-point-of-failure in the system.

Sorry if this is too broad a question, and I will be doing a lot more reading to try and make my vision a reality that I can implement, but if I'm missing something crucial or am suggesting something that just isn't possible I'd like to know in advance! :/

Thanks in advance to anyone who can help guide me!


2 Answers 2


Just today, Oraclize released an update to support Encrypted Queries, which allow private information to be stored publicly.

To fully understand what is happening here, you have to understand the purpose Oraclize serves.

Let's say you want to get a random number on the blockchain. Or you want to get the weather in San Francisco right now. When every individual on the blockchain executes this, there can never be consensus. I get a random number, it gives me 3. Then you go get a random number, it gives you 4. I get the weather, it says its 61F and sunny. You get it an its 60 and sunny.

Oraclize solves this by essentially taking data that is offchain and putting it on the chain once so that everyone reaches the same answer. Instead of asking "what's the weather" on the chain, you would ask Oraclize what the weather was and it would respond "It's 61F and sunny" and the 61F and sunny is stored on the chain.

Their update today takes that one step further. Instead of putting

"My SSN is: 738-94-0293" on the blockchain, you would encrypt it and then Oraclize would use it's private key to decrypt it.

You would store the encrypted version of my SSN, and whenever you needed to know my SSN you would query Oraclize to decrypt it, and then you would do whatever with it.


  • Encrypted data is more expensive (uses more gas) than unencrypted because it has more bits

  • You have to trust Oraclize that (1) they hold the only private key and (2) that private key never gets stolen, misplaced, etc. ever. Even if it's in 10 years, if that private key becomes public, anyone can access all the data stored in that format on the chain. There is no way to remove that data from the chain either. This is the reason they use API keys & answers to trivia questions in their examples, not SSNs or other truly secret information. It's not the end of the world if the answer to the trivia question gets stolen. It kind of is if 5000 SSNs get decrypted.

Your actual questions ;)

It's hard to give you a good answer. I can tell you this:

  • If the information is sensitive enough that in 1 year, 5 years, or 10 years the private information become public would be detrimental to businesses, people's lives, etc. then a private sidechain or something you control 100% would be better.

  • It doesn't necessarily mean that you must keep everything on a private blockchain or private servers, it just means that the sensitive information needs to be able to be deleted in case of a breach of private keys.

  • Other security precautions should be taken on your end to prevent a more typical hack/breach/etc. of your traditional servers/database.

  • I would recommend that you stick verification or tracking-styling information on the blockchain, anything sensitive would be off-chain. Saying "Mary says she picked object #123 up" is much different than "Mary Holland, SSN: 469-23-9484, address: 1234 5th Street Los Angeles CA 90123, picked up 5oz. of cocaine from Joseph Burr, SSN: 764-18-2393, at 54321 18th Street Compton CA 90321 at 3:34pm on 5/4/2016."

Would it be possible to restrict access to the information depending on which parties are listed as having permission to view asset details.

This deserves a question of it's own.

You could use public key cryptography (like Orcalize is doing, but on your own) in order to issue private keys to necessary parties that would allow them to decrypt the information when they need to. It would take some orchestration and the encryption of the data would need to be done offchain as well, but it's doable. I don't have enough knowledge to say the best procedure for this but essentially each user would have a key to decrypt and therefore they could successfully decrypt any data what was encrypted using their key. Again, breaches of these keys could be detrimental and the more people who have a key floating around, the more likely it will be that the key gets lost/stolen/publicly posted/etc. Especially if you are dealing with a "normal" user like Mary who just knows she has to press this button when X happens, not how the underlying architecture works.

  • 1
    Thanks @tayvano. It's interesting to read and helps me get a better view of the beast that I will be wrestling with! Almost certainly I will need to use a side chain, at least, one for us and one for each of our competitors which would store both business sensitive and end-user sensitive information. The data that would need to be stored on the blockchain, I believe, would be simply the asset, something to identify the owner and the value of it. So that the regulator can easily approve it's validity and will have assurance of the record being immutable. There's certainly a lot to ponder! Commented May 9, 2016 at 8:37
  • @tayvano - I'm in sort of the opposite situation from Michael, in that I have this use case but it WOULD be acceptable for the data to be leaked in 1-10 years. In our use case the data just needs to be private for a while, and even if it's leaked it's not the end of the world. You mention we could use private key cryptography on our own - would that be encrypting off chain and then building logic to release the private keys at a certain point? Where would the private keys be stored in that case - offchain as well? Interested in hearing your thoughts on that! Commented Sep 20, 2017 at 20:20

Do you actually need anything blockchain-like for the sensitive data?

The obvious way to do this is to store versions of the data off-chain, either encrypted or in a private database, then store the hashes of these documents on the blockchain to manage which version current ledger is currently using.

To get more specific than that we'd need a bit more detail, starting with. Is all the confidential information visible to all the "insider" participants, or is it limited to different subsets? When and who writes it? Does it need to be secure even if current encryption methods get cracked in future? Do you need to be able to irretrievably delete data?

  • The main issues with regards to sensitive information concerns business secrets such as keeping our list of clients as secret as reasonably possible from our competitor, but more importantly, our clients will also want to ensure that their information isn't identifiable as being theirs by their own competitors, of which there are many more. So data being cracked a in the future may not be an issue as by then it may be obsolete and of no advantage. The key to the system will be the regulator being able to quickly and easily verify legitimate assets regardless of who they relate to. Commented May 9, 2016 at 8:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.