The Collusion Conundrum: Preventing Collusion and Historical Rewrites on Private Blockchains

I’ll be honest. The very first time I heard of a permissioned blockchain network, I scratched my head. I fully understood the concept of a blockchain but a permissioned network didn’t make sense to me. Why would an organization not simply use a distributed database if there is central control anyway? Why would you need to use a rather slow and expensive database (like blockchain) to accomplish what can be done by battle-hardened distributed databases that provide sub-second transactional workload latency.

Note: There are several definitions for permissioned chains so it is worth defining how we think about it. Permissioned networks are essentially what are also referred to as Consortium networks, and a distinguishing feature of a permissioned network is that only a pre-determined set of nodes can join the network and access control is built into the network as a first-class citizen. A distinction can be drawn between permissioned networks and private networks. Private blockchains can be both public or permissioned but are distinguished by transaction privacy.

As I looked into it more, I quickly came to the realization that permissioned networks afford the enterprises some unique advantages. My first realization was a database that is shared between a list of known actors may still need the guarantees afforded by blockchain (i.e. known actors may still be adversarial or at least not trust each other to update the shared database). How many times have I heard (even within a single company), that a particular database can only be updated by a single person in the entire company to ensure that someone doesn’t modify it in a manner that impacts others in the company. The need for agility combined with the guarantees provided by a blockchain can only be fulfilled by a shared distributed database that exhibits the properties of a blockchain. Permissioned networks are thus suitable means to share data between known actors and ensure that the updates to the store are agreed upon and in compliance with a set of rules that the known actors have agreed upon.

The next natural question in my mind was about what kind of consensus makes sense in a permissioned network. Proof of Work wouldn’t work because it is only as good as the compute behind it and the reality is that permissioned networks do not have the same level of compute behind it. Additionally, in a permissioned network, the latency requirements are significantly more stringent. PoW type consensus doesn’t usually make sense in this setting. Alternate consensus mechanisms make more sense: both byzantine fault tolerant as well as simply crash tolerant algorithms. In either of these consensus algorithms though, given the actors are known and may sometimes be aligned on a desired outcome, it is possible for a significant number of these actors (or all of them) to collude and decide to rewrite the blockchain. This can be done by all parties in a consortium to reverse a transaction for the benefit of everyone and simply fork the chain from that point on. This is simply one of the attack vectors and there are several other attack vectors (malicious actors, spamming actors, censoring actors, etc.) but most of the other attack vectors can be addressed by the protocol design itself.

I started working on Kaleido with these questions in my mind. In the first few days of starting work at Kaleido, Jim Zhang and I discussed and came up with a logical approach to enhance immutability of the permissioned networks. We looked at a couple of different approaches and both of those approaches involved utilizing a larger public blockchain (which generally tends to have a much higher barrier to any given actor rewriting the history of a blockchain) to commit an irrefutable proof of the state of a permissioned network. This allows any party on the permissioned network (or an external party) to validate if the chain has had a fork because a significant number of known actors (or all of the known actors) have acted in concert to change the history for mutual benefit.

An approach that we discussed and quickly discarded involved a Layer 2 solution using Smart Contracts on the Ethereum Main-net and requiring all the known actors on a permissioned network to use contracts that inherit from the Main-net Smart Contract. While this approach is feasible, it seemed too cumbersome for the parties in a network and just didn’t seem to fit in with our overall objective of making everything radically simple. We ended up adopting an alternate approach that utilizes the same concept but instead of relying on layer 2 smart contracts, relies on an observer node in the network along with a smart contract on the Ethereum main-net for creating irrefutable proof of state of a permissioned network periodically. I encourage you to read through our paper that outlines the challenges and the design of this approach. Read our paper on Enhanced Immutability of Permissioned Blockchain Networks.

As we look forward, we know that there is a lot more work to be done in this area. There are likely additional scenarios that we need to address and there definitely is room to optimize our approach. We will be looking to work through and improve on this approach in the future. Your feedback and thoughts on this are highly appreciated.

Finally, we are thankful to the Ethereum community and the work being pioneered with Plasma. Our approach was inspired by the concepts outlined in the Plasma paper.