Building a private blockchain on the Ethereum public blockchain

Posted August 14, 2015 by Jonathan Brown ‐ 4 min read

Retrieved from the Wayback Machine.

I first became aware of the concept of private blockchains several months ago when I watched a presentation by Preston Byrne of Iris Industries. Vitalik Buterin (inventor of Ethereum) was also presenting in that session, although not about private blockchains. I must admit I was very sceptical of the whole concept. The entire purpose of having a blockchain is so that no one can be prevented from putting a valid transaction on the ledger. With a private blockchain only an agreed list of people can create transactions. The problem, unlike on a public blockchain, is that it is very easy for a majority of participants to get together and prevent another from creating a transaction. The participants and the verifiers are the same people.

A few days ago it was announced that Brian Fabian Crain would be joining Iris Industries, so I decided to spend some time re-evaluating the whole concept of private blockchains.

I realized there is value in having a private blockchain instead of just using some other message passing / database technology. People want to be able to interact with a fixed set of people they don't trust with fixed, known rules, and in private. With an Ethereum smart contract it is possible to have access control so only specific accounts can change the state, the rules are defined in the contract, and as it is on the public blockchain it is imposible to prevent another participant from creating a transaction. The disadvantage is that a smart contract on a public blockchain can only operate on public data. This is the primary reason why it is attractive to have a private blockchain. Another advantage of a private chain is that a transaction fee doesn't have to be paid.

A few days later, Vitalik published a fantastic blog post On Public and Private Blockchains.

In his list of advantages of private blockchains he says "The validators are known, so any risk of a 51% attack arising from some miner collusion in China does not apply". I think the opposite risk is true. If the participants and the validators are the same people, they can (and will) collude. On the public blockchain, collusion is much harder.

I came up with a hybrid solution that could be the best of both worlds.

The idea is to have a contract on the public Ethereum blockchain that serializes encrypted transactions for a private blockchain. It has a permissions system so only permitted users can add a transaction.

Any participant who needs to know the current state can download any transactions from the blockchain that they do not have yet, decrypt them and apply them to their copy of the private blockchain.

This hybrid technique removes the problem of participants colluding to prevent transactions being confirmed. The smart contract on the public ledger is the authority of what transactions are on the private ledger. Previously, participants could have colluded and created the longest chain. This is no longer possible. The disadvantage is participants need to pay a transaction fee.

I have implemented this private ledger in Solidity.