Blockchain Private Channel is an Oxymoron
Private channels are the generic term used to describe a method of communicating using a blockchain ledger with a subset of network participants. The communication paradigm is the same a regular blockchain except the peer communication is encrypted over a TLS connection and decrypted at the endpoints.
In Quorum v2.0.2 those communications are called private transactions.² In Hyperledger Fabric v1.1 the same convention is called channels.¹
In theory private transactions are being made by nodes that are achieving a byzantine fault tolerant consensus. Quorum v.2.0.2 uses two separate consensus mechanisms that are selectable at deployment. The first is a Raft a consensus model and the second is Istanbul Byzantine Fault Tolerance (IBFT) which is a modified derivative of Practical Byzantine Fault Tolerance (PBFT).³ ⁶
Below are equations for the aforementioned consensus mechanisms. In these equations N is the total nodes and F are the number of included faulty nodes. For the value F the resulting value of N is the number of nodes required to achieve consensus.
PBFT Consensus Fault Tolerance Equation⁴
N = 3F +1
Raft Consensus Fault Tolerance Equation⁵
N = 2F +1
In practice, byzantine fault tolerance cannot be achieved by these channels due to a lack of participating nodes. In the average case the requirement for privacy means that there will only be two participating nodes in the private channel. If there is a single faulty node in a PBFT private channel there needs to be 4 participating nodes. Likewise, if there is a single faulty node in a Raft private channel there needs to be 3 participating nodes.
This same fallibility is detailed in the Castro-Liskov 99 paper where it states,
“The algorithm does not address the problem of fault tolerant privacy: a faulty replica may leak information to an attacker. It is not feasible to offer fault-tolerant privacy in the general case because service operations may perform arbitrary computations using their arguments and the service state; replicas need this information in the clear to execute such operations efficiently”.⁴
Therefore, there is no known way to achieve privacy at the consensus layer of a blockchain.
Defenders of the private channel schema will likely make reference to the check pointing techniques employed by Quorum. Check pointing measures are taken in private channels by inserting the block hash from a globally visible chain into the new private blocks and vice versa inserting the block hash of each new private block into a globally visible chain. The check pointing process ensures the provenance of the private chain is globally auditable.
The reason this technique is not an effective mitigation is the private channel can only append a new checkpoint to the global chain after the private consensus has been achieved. As stated before in the presence of a single faulty node a two-party private channel cannot achieve consensus.
Effective mitigation techniques include
1. Don’t use private channels for parties less than 4 for PBFT and 3 for Raft.
2. Add inert parties to the channel, such as a neutral observer from the global chain.
3. Don’t use private channels.
References
1. https://hyperledger-fabric.readthedocs.io/en/release-1.1/channels.html
2. https://github.com/jpmorganchase/quorum-docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf
3. https://github.com/jpmorganchase/quorum
4. http://pmg.csail.mit.edu/papers/osdi99.pdf
