Smart Contracts: Privacy vs Confidentiality

I’ve worked on a few blockchain projects now and I find it surprising how many people haven’t taken into account one significant limitation into their planning…

Smart Contract transactions are not confidential. Everyone can access and see all information that is sent to and stored in a smart contract.

Up until today, this annoying problem has pretty much limited the usefulness of blockchain applications.

The usual responses I hear to this dilemma by projects are:

• We just won’t use blockchain for storing sensitive information. We’ll use an off-chain centralised datastore for private data and only use our blockchain application for storing public data.
• We will figure out a clever solution by the time we are ready to launch with new technology that that is yet to be developed— No seriously, this is written in some white papers.

My opinion on these two approaches are:

• Using a centralised database combined with a blockchain network in this manner is where many fail to understand how things should work in a decentralised world. What they are effectively building is another silo (see Google) where their business becomes the gatekeeper (and probably charges a fee for the service) of holding customer information.

What blockchain technology gives us is the ability for parties who do not necessarily trust each other to transact without requiring an intermediary.

So if a customer or another business entrusts you to hold their valuable data in order to execute a transaction then you probably don’t need a blockchain.

• And launching a project while you are waiting for new technology to be developed could be considered quite a risky approach.

But, I hear you say, are there not already solutions for blockchain privacy?

• Zero knowledge proofs (Z-Cash)
• State Channels (Lightning / Raiden)
• Encryption?

OK, is it really privacy you are looking for, confidentiality or a combination of both?

Many use “privacy” and “confidentiality” interchangeably, yet the two words – and “anonymity” – mean significantly different things.

Let’s unpack this a little…

What is privacy?

There are many definitions of privacy, from a legal viewpoint and a technological viewpoint.

To paraphrase these definitions:

Privacy is the individual’s right to keep their data to themselves and not to have their actions recorded or monitored.

With blockchain there are three methods to obtain privacy:

1. Being Anonymous — Do not reveal who you are.

• Zero Knowledge Proofs (ZKSnarks) — do this well by obscuring the addresses of the sender and recipient plus the value amount being transferred.

ZKSnarks hold a lot of promise and we are enthusiastic about future developments in this space. The limitation at the moment is that it doesn’t scale well for complex functions.

2. Just don’t post any sensitive transactions on the Blockchain.

• State Channels — This is where a set of transactions between one or more participants are executed and recorded off chain. A reference is then recorded on the blockchain once these set of transactions have successfully completed.

State Channels are useful for micro-payments where two parties are constantly sending payments back and forth. If it is a one off transaction for a large amount then it is not very useful.It also kind of defeats some of the great features of using a blockchain for transparency and traceability. If someone later, legitimately wanted to know what these transactions were, then there is no easy way to get hold of them. Also, there are no guarantees that they would have been retained.

3. Encryption — Encrypt the information so no one can read it.

Encryption is mainly used today for transmitting data over unsecure channels in order to keep messages private between two or more parties. However, is encryption a sound solution for storing data on a distributed ledger that is public and permanent for all time?

There is actually a lot you can learn from observing the various patterns of the encrypted data, such as the frequency it’s being recorded and the similarities in encrypted sets of data. Finally, there is always the option to decrypt the data by brute force if you really want to know what is in there.

The best security is just not to let anyone get their hands on the data in the first place.

This is kind of why companies have firewalls to keep sensitive data hidden behind technology infrastructure.

What is confidentiality?

Confidentiality refers to sensitive information that is shared between parties by consent.

Confidentiality is about controlling who has access to sensitive information.

In order to control access to data, we need a set of permissions that can be granted to the parties involved.

Almost all online businesses today have some sort of authorisation mechanism to grant permissions to users in order to access information.

Think Google Docs — You can create a document and then grant different users view and edit permissions.

So, can we actually have security like this for a smart contract?

Lightstreams

Not being satisfied with a sound solution out there we set out to design something that works best for the use cases we had in mind.

Lightstreams is modified version of the leading Ethereum client (Geth), but with some significant changes.

A standard Ethereum smart contract stores its state information on the blockchain along with the smart contract’s instruction code. Any state changes of the smart contract occurs by transactions being transmitted publicly to every node in the network.

What we did to change this standard behaviour was to create a protocol where a smart contract’s state information is stored in a distributed secure vault. Therefore, rather than broadcast a state changing message publicly on the blockchain network, only a reference address of that message which is recorded in the secure vault is transmitted.

Those that are granted read permissions to the smart contract are then authorised to access the full history of the smart contract’s state changes stored in the secure vault.

A walkthrough of the authorisation protocol of Lightstreams

So how did we design this distributed secure vault?

Well, we took a distributed file storage system called IPFS and modified it with a security layer for controlling access to data. Only authorised users are permitted access to the smart contract’s state changes.

The list of authorised user accounts is stored with the smart contract. So during the authorisation process the IPFS client will contact the Ethereum client on the same physical machine to verify that that account making the request is authorised to access the data.

The great thing about this design is that the list of authorised users can be changed throughout the lifetime of the smart contract and any new authorised user will then be able to access the full history of transactions. Likewise, when ownership changes hands, the new owner with inherit the full history of smart contract state changes.

The added bonus of this setup is that you can store any sized file with the smart contract state information without having to pay gas fees— Video, Music, Documents.

Roadmap

Since Lightstreams is a modified version of the native Ethereum client, we can easily keep our code synchronised with the main client and inherit all the new features, such as zkSnarks.

Initially, our project will be focussed on developing a protocol to enable the more simple use case of Content Publishing music, video, books etc. That is, when a user purchases content they are added to the smart contract’s authorisation list in order to then access the publisher’s content.

Once we have Lightstreams working well within the Content Publishing space, the bigger picture is to enable use cases that require more sophisticated smart contract security.

Lightstreams will be open network such that any developer can download our software take advantage of protocol and build their own services.

If you like anything that you have read… please clap so others can be informed. Thanks!

Follow us

If this is really interesting for you and would like to learn more, see our website or join our Telegram group to ask any questions.

Telegram Group

Who am I?

I have spent a number of years as a software developer and solution architect building real-time, distributed applications at firms such as Goldman Sachs, Credit Suisse, and the London Stock Exchange. My experience designing blockchain solutions, include the Open Mobility System for the Share & Charge blockchain project and I have won blockchain awards at the Citibank Mobile Challenge and the Consensus 2017 Hackathon.