In-depth on differences between public, private and permissioned blockchains
If you are looking into an application of blockchain or distributed ledger technology for business and enterprise blockchain solutions, then you have heard about private and permissioned blockchains. In this post, I will try to explain more in depth what are their properties, strengths, and weaknesses compared to the public blockchain solutions.
What public and private blockchains have in common?
- Both are decentralized peer-to-peer networks, where “each participant” maintains a replica of a shared append-only ledger of digitally signed transactions.
- Both maintain the replicas in sync through a protocol referred to as consensus.
- Both provide certain guarantees on the immutability of the ledger, even when some participants are faulty or malicious.
In short both from the point of architecture and main properties provide what we understand under blockchain or more in general distributed ledger platform.
This leads to the more interesting question on what puts them apart. We could give a simple answer that the difference is in who is allowed to participate in the network, execute the consensus protocol and maintain the shared ledger. Such definition is correct, but a bit high level to understand the potential of private distributed ledger platforms besides of requiring authentication and authorization to access the blockchain.
Let’s start first with the typical enterprise customer requirements.
Confidentiality
Confidentiality is the measure of ensuring that only entities participating in a particular transaction will have knowledge and access to it.
In consortium networks where potential competitors are participating it is essential to enable blockchain channels between peers that are not visible to all members of a consortium. It is not just about data confidentiality that can be potentially hidden using cryptography or more advanced zero-knowledge proof schemes. Just insight into a number of transactions between peers in the consortium could bring competitive advantage, and this might not be desired.
Implementing this requirement is quite hard on many blockchain platforms because they follow order-execute architecture where every member of network executes transactions in a block to sync its state. Some of the private and permissioned blockchain solutions like Hyperledger enable implementing confidentiality leveraging different architecture (execute-order-validate) and natively supporting private channels on a shared blockchain infrastructure.
Throughput
Throughput is measure of number of transactions processed by by period of time. In blockchain context is average number of transactions appended to blockchain (within blocks) per second.
Current solutions built around relational or distributed databases can achieve throughput in tens of thousands transactions per second. You might argue that lower performance is an acceptable compromise compared to trust, immutability, etc.. However, the business process you might want to migrate to blockchain will likely have some throughput requirements that must be met.
Majority of public blockchains are in an entirely different ballroom in this regard. Private blockchains provide orders of magnitude higher throughput compared to most of the public blockchains because their consensus design does not have to include incentives for miners, identities of members proposing blocks are known, and therefore potentially loss of credibility works as the incentive. Scalability focuses on throughput rather than the number of nodes.
Finality
Finality measures how long one has to wait to be given a reasonable guarantee the transaction written in blockchain is irreversible (will not be orphaned).
This is again significant property for business. Need to wait one hour like on blockchain network is not acceptable for a lot of the business processes. Most of the public blockchain use lottery based algorithms to select a node to propose a new block. This scales well as minimal information has to be exchanged over a network to achieve consensus, but leads to chain forks in the network and therefore longer time to finality.
Most of the private blockchains, therefore, go for voting based consensus algorithms. The block is finalized when the majority of nodes vote for it. It brings virtually immediate finality in exchange for lower scalability as consensus requires more messages to be exchanged. This typically is not such a big issue for private blockchains because the number of participants is orders of magnitude lower and there are deployed in WANs with low latencies and guaranteed throughput compared to general internet environment.
Let’s take this into a single picture.
The first important thing to understand that there is no strict border and different blockchains are positioned differently on the scale of validators anonymity and trust.
Public blockchain needs good scalability and strong resilience against malicious members along with an incentive model. This brings tradeoff in slow speed and high latency to finality along with the need of token to incentivize miners securing the network. The network is there as secure as the computational power behind it.
To address some of these weaknesses (especially energy consumption) Proof of Stake is being adopted by large-scale public blockchains like Ethereum. It improves speed and finality (still probabilistic because of the potential appearance of forks). It also increases resiliency against specific attack vectors but might suffer from “nothing at stake” and “rich get even richer” issues (nothing at stake being solved by slashing). Because these are public and permissionless native coin is included and economic model to safeguard the network is built in, and therefore some trade offs have to be made.
Much better fit for enterprise use cases are blockchains using BFT based consensus. In a semi-trustless environment where strong confidentiality is not a requirement, Federated BFT consensus (Ripple, Stelar) provides good performance and immediate finality thanks to voting. It also does not require a native token to prevent validators from malicious behavior.
If high confidentiality, transaction throughput, and immediate finality are required, then private permissioned blockchains are probably the best platform. The native token is not necessary as identities of participants are known and approved by notaries. Part of the blockchain security model is brought be the risk of losing identity credibility.
Private blockchain group includes different variants of BFT algorithms and also Proof-of-Authority available on Ethereum. In private blockchains, frequently requirement on resiliency against malicious behavior is lower. Therefore consensus can be designed without byzantine fault tolerance to achieve better throughput like Hyperledger Fabric using Kafka (still having the crash tolerance).
Different business cases have different requirements, and no solution would fit all the cases. Understanding properties of different platforms are vital to make the decision regarding blockchain platform and even evaluate if using blockchain to implement a business case make sense.
Sources
