I am often quoted as being quite against private blockchains, and have on occasion called them mockchains. Guilty as charged – there is a fair bit of bias in this here decentralization radical.
But I'd like to note that the main reason I make fun of private blockchains is because they're generally easy targets – well over 90% of them are proposed because of good marketing on the part of mockchain vendors, or bad planning. I'd like to fully clarify my position in this post and explain when it does or does not make sense to use private chains.
On Private Chains
Consortium chains or private chains are blockchains shared between a few entities, and generally not accessible to the public. They are often a PoA (Proof of Authority) setup, which means a set of whitelisted entities is allowed to produce blocks. New entities are then added through a model of governance which can range from completely offchain, to sudo (revoke someone's access from a central decision point) to on-chain voting (example: Substrate governance).
Consortium chains are usually aimed at enterprises and businesses that have privacy, security, customizability, or scalability worries:
- Privacy – companies are often worried about exposing their business data to competitors or the public. This is often a moot concern and implies bad planning of the business architecture, as blockchains should be used for provenance and timestamping, not data storage.
- Security – some consortia may believe that they are likely to endure more threats than a public chain, or at least that the threats that will wipe out the chain are threats that will also wipe out the consortium itself. This is debatable because while a public chain has a much bigger attack sufrace, it also has much more resilience.
- Scalability – public blockchains can get clogged up with sudden market movements or popular applications and the confirmation times and costs or transactions can rise dramatically. This is a valid concern.
- Customizability – when the functionality of a chain is found to be lacking, a custom application-specific version makes sense.
When not to use a private chain
When an ahead-of-time arrangement of participating parties is known – whether those parties trust each other or not – it is much cheaper and easier to build a shared database with proper permissions which can then be modified by governance mechanisms built into the database itself. This approach also allows for a great degree of customizability.
If historical logging in the style of blockchains is desired, an event sourcing database is not only more compact and more performant, but also easier to use to reproduce a database from scratch from backup diffs.
If data leaks are a concern, the database can be encrypted. When decrypted, blockchain data isn't immune to leaks either, so blockchains provide no immediate benefits in this case.
Additionally, if the participant (a.k.a. block-producer) count is low and there is a chance of it dropping lower, the chain becomes extremely vulnerable to control by a single party. See “When to connect” below.
When to use a private chain
When the state-changer (block-producer) set has the tendency to change and is unknown to its fullest extent ahead of time, using a private chain makes sense. The onboarding process of new entities is then made trivial – be voted in and whitelisted, then download a node, plug in your key, done.
When the actual logic of the state transitions needs to be verified – i.e. it's not a simple append operation with no rules, running a private chain makes sense. Entities coordinating about warehouse status do not need a blockchain because an event sourced database can adequately register changes and append them. A “-1” to inventory on item X becomes -1 for all participants, and using events it's easy to always see who issued a request, when, and in which order.
However, in scenarios when STF logic has certain restrictions, i.e. a game where simple appends would allow for cheating (e.g. an entity adds 1000 gold coins to their name), this logic needs to be verified by all or most participating entities before being accepted into the state.
Systems in which speed is not of the essence are also much more adequate for blockchains, given that blockchains cannot by definition be faster than one critical decision every few seconds.
When to connect a private chain to Kusama or Polkadot
Private chains do not have to stay data-islands. Isolation seems like a benefit at first, but when the need arises to talk to external systems, connectivity can be worth much more than high quality oracles doing translation of data between chains. As such, connecting a private chain to a relay chain like in Kusama or Polkadot has the benefit of additionally securing the chain with virtually no downsides other than added engineering time.
Connecting the private chain to such an ecosystem also allows it to directly consume information from other chains and issue commands across the ecosystem without relying on oracles, and without exposing any sensitive data. Their participation in the ecosystem remains as private as if they weren't there.
However, this carries additional cost. Parachains are expensive, and parathreads aren't fast. As such, connecting only makes sense when added security and cross-chain communication is desired, and/or when there is a chance – however slim – that the number of participants in that chain might drop to a number low enough to threaten a chain hijacking by a single party.
Private chains make sense when scalability or customizability are an issue. IRT scalability, one could argue that in such high TX needs transactions can be exectued rather well off-chain and only the result of these calculations can be stored on chain, state-channel or off-chain-worker style.
A valid use case is when the state change has some very rigid rules and limitations and when all participants need to agree on the legality of those changes relative to the state of the entire system, i.e. consensus is needed, especially if that consensus is custom so an app-specific blockchain is needed.
In other cases, I believe a well engineered event sourcing database, or just plain old replicated database, are a much better solution.