Private Blockchains Considered Harmful
Like the much maligned GOTO statement, the private blockchain, as a means to data privacy or tighter governance, should be considered harmful. (Although like the GOTO statement, it might still sometimes be a lesser evil.)
Why? Because the security properties of blockchains (and many other distributed data structures) rely on all transactions being visible to all participants. Once a system has enough participants to be useful, at least one of those participants will have included a compromised device.
Similarly, for blockchains to provide fair consistent processing of transactions, they rely on participants not colluding on a large scale. It is hard to stop participants colluding on a large scale if they all have to be uniformly managed for data privacy.
The normal corporate blockchain proof-of-concept within a single datacentre is logically running on a single computer. A realistic consortium chain will include a node running on a dusty PC under a desk in Tajikistan. The first is pointless. The other is unlikely to be confidential. Even if we had a consortium of a dozen high sophisticated and secure parties, the great value in having a blockchain based system is in extending it all the way down to individual flesh-and-blood user’s devices. It is by going down to this level that we can stop problems like the Bank of Bangladesh heist(link is external) from happening.
Decentralised applications, DApps in Ethereum speak(link is external), are not the same as traditional client-server model applications, and blockchains do not behave like servers. Under a client-server model, I, as a user, have an account with the server and the permissions of my account limit what data reaches my account.Within a DApp, my device is a participant in a chain. It can access the entire chain at will and must be able to do so to ensure the integrity of the information it is displaying to me.
Broadcasting confidential data to an entire network of devices is a bad idea. This does not mean that decentralised applications cannot support private transactions. It does mean that re-using traditional castle-and-moat security concepts won’t work and is counter-productive.
Let’s take a step back and look at what most blockchains do under the hood. Blockchains try to achieve a fair ordering of digitally signed inputs (or transactions). So I write a cheque to Sai Ying Pun Trading Limited and sign it digitally. Then I submit it to the blockchain and chain appends it to my bank account. Perhaps I write another for the same amount but my account only has dollars for one of them. Most likely the first will clear, perhaps the second, but no-one will see a state of the blockchain where my account is overdrawn.
Perhaps I want to be a sophisticated global trader. Say that this cheque shall be payable only after the 22nd of March against the transfer to me of a digital bill of landing for 22,000 plastic novelty Eiffel towers. That’s essencially all a smart contract is.
What is important to see here is that my cheque, the rules it should clear under, my digital signature and Sai Ying Pun Limited’s signature, all of this, exists independently of any blockchain. They could simply be emailed back and forth. The value the blockchain provides here is in establishing a public canonical ordering of these things. The digitally signature on the cheque is as valid whether it is on or off the chain.
The robust way to handle privacy in a blockchain environment is to presume that anything posted to the chain will become public and to confine private data to direct communication between participants. Direct communication still allows the inputs to signed, for participants to use smart contract code and so on. It just won’t be witnessed by a global network of computers. Which in most cases is the behaviour everyone wants, the global network would prefer not to process anything it does not have to.
This isn’t to say that having a globally available public database isn’t useful. Lots of things can be stored there to aid private transactions. For example, which of my 14 public keys represent me, which are compromised, which are lost, etc. Hashes of private agreements in case either party needs to prove the terms. Commitments to encumber an asset, like a mortgage, which need to be public to have any force.
The public blockchain isn’t a philosophical alternative to privately communicated transactions, it’s a compliment. It’s there for the bootstrap data needed to make everything work, and the final record needed to give it force.
It is worth noting that the Ethereum project does not simply consist of a blockchain. It is intended to be three systems: a global computer (implemented as blockchain), a private messaging network and a distributed file system(link is external). Often referred to as The Holy Trinity, these are intended to work together to allow any application to be built in a decentralised fashion without compromising privacy.
Ethereum will also soon have State Channels(link is external), which allow smart contracts to run within a private conversation. Think of them as private blockchains on-demand. (R3’s Corda(link is external) platform is essentially pure State Channels(link is external).)
With confidentiality out of the way, let’s look at two control issues that someone might try to solve with a private chain: 51% attacks and broken smart contracts.
In a mined public chain, in theory, if an attacker gained a majority of the hashing "power", they could re-arrange the ordering of past transactions, even undo-ing them entirely. But it’s important to note that they can’t fake the transactions themselves, and in a smart contracts system, those transactions can be conditional on previous state. So with sensible programming, that 51% attack would only allow re-orderings that the application developers considered unimportant. And that is, in theory, in reality the entire network would freeze up as clients are programmed to see the system rolling back for more than a few minutes (admittedly that can, and does, happen) as an error state.
If you are reading this, you are almost certainly aware of the $US55m failure of the TheDAO(link is external), due to a smart contract bug. The fix for this was a special patch to the underlying Ethereum client software itself which forced a new version of the TheDAO’s code. This was despite the authors of TheDAO having deliberately locked themselves out of their creation to avoid legal liability.
I would hold that TheDAO was a failure of cryptocurrency, not of smart contracts or public chains in themselves. Supposing TheDAO had not held cryptoassets. In that case, any unexpected behaviour would have been quickly noticed, and in the worst case, the maintainers of the software could have made a copy of TheDAO without the flaw and blessed it as the one true version. Admittedly, there would be the chance of defrauding some users while the bug was undetected, but the odds are that the consequences would be less severe than in a traditional centralised application.
Issues around versioning, correcting, naming, etc smart contract code should be dealt with at the smart contract level - not by monkey patching(link is external) the underlying protocol.
All this said, if I were asked tomorrow to put the Brazil land registry on the blockchain, I would still create a so-called private chain. Why?
- Faster Consensus - A permission (or rather, voting) chain with a dozen validators will converge in seconds. Not the 2-10 minutes that most mined public chains take.
- Smaller - The Ethereum blockchain requires 500MB/month of storage. This is not suitable for a smart phone.
- Avoid crypto tokens - Public chains require the use of crypto-currency to submit transactions. Many organisations would prefer to avoid this.
- Monkey patching - It should never be needed, but :-)
- Custom features - My chain might want to benefit from protocol-level features like quantum-resistent public keys or zk-SNARK(link is external) before a public chain was ready to release them.
But with the exception of (5), I should be able to simply copy my code to a public chain with the same underlying protocol and expect it to just work. Public vs private chains are deployment options. Nothing more.