Blockchain technology emerged with Bitcoin in 2009, at first as a solution for decentralized digital currencies.

It quickly became clear that Bitcoin’s main contribution, namely the fact that it allows the trustless maintenance of a replicated ledger of transactions, even in the presence of malicious network participants, was useful for many other applications. These include enterprise application, in which collaborating companies need to track assets in a common infrastructure, without fully trusting each other.

However, enterprise solutions are often very different in nature to public applications, such as cryptocurrencies.

This has led to two fundamentally different types of blockchains: public blockchains and permissioned blockchains. The latter are often called consortium blockchains since participants are authenticated members of a group of collaborating enterprises. The former are, as the name suggests, completely public and allow any node running the correct software to join the network.

Both types of platforms share some commonality but cater for very different use cases.

Before diving into more technical details, let’s discuss the conceptual differences between the two models and their applications.

Public Blockchains

Public blockchain use cases include situations in which the goal is to connect a large number of participants in a decentralized and transparent way. Anyone can partake in the network and make use of the platform.

Cryptocurrencies and other tokenized assets are a perfect example of this. When Bitcoin was created, the creator (or creators) envisaged a completely open network, on top of which a digital cash system would allow anyone to exchange value in a secure manner without trusted third parties.

Therefore, anyone is allowed to connect to the network and submit transactions. To make the network secure, anyone can participate in the consensus protocol and compete to be the next block producer. In addition, all participants can see and verify all transactions. The system is completely transparent, although real identities are abstracted away in the form of public keys and addresses, providing a degree of anonymity.

Subsequent public blockchains, such as Ethereum, share this model, which leads us to the following definition of a public blockchain:

“A public blockchain is a distributed ledger implemented on top of a peer-to-peer network open for anyone.”

Importantly, in a public blockchain, the participating nodes are neither known nor authenticated. Depending on the consensus algorithm used, any participant can have an influence on block generation and transaction verification.

Delegated proof of stake systems may relax this requirement, in order to trade performance for a certain degree of centralization, but even in these systems, participants can influence block generation by delegating transaction validations through voting.

Permissioned Blockchains

Public blockchains are great for cryptocurrencies and many other applications that are meant to be accessible to the general public.

After the emergence of Bitcoin, it did not take long for businesses to realize that some of the blockchain’s properties are very useful for certain inter-organizational applications. These properties include immutability of the ledger, auditability, protocol-level built-in trust, and data integrity.

However, other properties, including complete transparency and lack of authentication and authorization mechanisms are at odds with enterprise requirements.

Enterprise applications have to comply with certain security policies and regulatory requirements. They may also have requirements regarding transaction throughput, transaction latency, and transaction cost. In general, a consortium of enterprises building on a blockchain requires to strictly control who can connect to the network, in which role and with access to which data.

Let’s look at a supply chain application as an example, as this is often mentioned as a typical enterprise blockchain use case. Items are to be traced as they make their way across a network of companies that form the supply chain. Thus, it makes sense to represent these items and the transactions involved in a consortium blockchain in which all members of the supply chain participate.

However, it does not seem logical to open up this application to the wider public, so only authenticated and authorized nodes should participate. Furthermore, it may be a good idea to make an item’s location visible to all participating parties, but the actual financial transactions and information on pricing and other contractor conditions should be private to the two parties involved in the transaction. After all, some participants might actually be competitors.

There are also external reasons for enterprise applications to require privacy features. Data protection regulations, such as the European Union’s General Data Protection Regulation (GDPR) place very stringent conditions on how data has to be handled.

These requirements have led to the emergence of a number of frameworks that adapt blockchain technology to be more suitable for enterprise consortia. A blockchain built with such a framework is known as a consortium blockchain or permissioned blockchain. The following is our definition of a permissioned blockchain:

“A permissioned blockchain is a distributed ledger implemented on top of a peer-to-peer network formed by known and authenticated nodes with a permission control system.”

Technical Nuances

The above definitions of public and permissioned blockchains may differ only in the participation model, but this difference has far-reaching consequences that lead to important differences in the technical implementation details of public and permissioned blockchains:

Authentication and Authorization:

The fact that permissioned blockchains require authentication and permissions may be obvious, but this requires some technical support. Nodes wishing to join the network must be authenticated when connecting to the network, and an authorization service is usually charged with implementing a role- or capability-based permissioning system.

This also introduces an issue of governance. A system must be in place to decide which nodes may join the system, and in which capacity.

Consensus:

In public blockchains, the number of potential block producers is unknown. Furthermore, all block producers are anonymous entities that may have very different motivations for participating in the consensus protocol.

For this reason, public blockchains require consensus protocols with strict guarantees that make cheating difficult and, importantly, counter-productive. Proof-of-work consensus, for instance, incentivizes miners to produce correct blocks. It is generally not of interest for a miner to act maliciously.

In contrast, consensus in permissioned blockchains can be handled very differently. The fact that all the nodes are authenticated means that validators are known entities that have gone through some vetting process. This in its own means that for many applications they can be trusted more than the block producers in a public blockchain.

Therefore, trusted nodes can be chosen as potential block producers and no proof of work is usually required to secure the network. As the number of validators is known and of a reasonable size, efficient voting algorithms can be used. Practical Byzantine Fault Tolerance (PBFT) is one well-known distributed systems consensus algorithm that has been rediscovered in the context of permissioned blockchains.

Scalability:

Public blockchains are designed to work with a very large number of nodes. In fact, this type of blockchain tends to be more secure with growing numbers of potential block producers. Therefore, public blockchains need to scale well in terms of the number of nodes.

Permissioned blockchains, on the other hand, tend to prioritize transaction throughput instead. These different prioritizations are additional criteria for the choice of consensus protocols used.

Transaction Finality:

Another consequence of the different consensus models is the way transactions are considered as “confirmed”.

Most public blockchains are based on a probabilistic model. In Bitcoin and Ethereum, for example, blocks can be produced by different miners at approximately the same time, leading to forks in the chain. These “stale blocks” are discarded after a while. The longer the wait, the lower the probability that a transaction is undone.

However, this uncertainty introduces a latency before transactions can be considered final in practice. In Bitcoin, six block generation events are typically quoted as a safe waiting period. With an average block generation time of ten minutes, this means a one-hour wait.

For many enterprise applications, block finality is a requirement. This means that once a transaction is included in a block, it will never be undone. The consensus protocols implemented in permissioned blockchains usually provide such finality guarantees.

Incentive Schemes:

Public blockchains originate from cryptocurrency applications and they still rely on cryptocurrencies. A lot of research has been done on the subject, but, so far, financial incentives have proven the most effective in motivating miners or validators to maintain the blockchain and to discourage fraudulent behaviors.

In contrast, permissioned blockchains usually center on a specific application, in which participants have an interest. Therefore, the incentive to keep the system operational tends to be a given.

Whilst permissioned blockchains tend to provide the basic primitives to implement cryptocurrencies, they do not usually implement such an asset at the protocol level. They also do not have mechanisms to pay block rewards to validators.

Transaction Fees:

In order to prevent denial of service attacks characterized by flooding the network, public blockchains normally impose transaction fees. Each transaction is associated with a fee that has to be paid by the invoking node. Transaction fees are usually dynamic and calculated as a function of network load. The busier the system, the more expensive a transaction.

In permissioned blockchains, transaction fees are neither required nor desired in most cases. Therefore, transactions tend to be free.

Privacy

There are no technical reasons for permissioned blockchains to require more data privacy than public blockchains. However, the need for privacy in permissioned blockchains arises as a consequence of typical use cases in enterprise applications, as discussed above.

Thus, platforms for permissioned blockchains tend to provide a range of privacy features. For instance, Hyperledger Fabric, one of the most popular frameworks, provides three distinct privacy layers:

Data channels are essentially separate ledgers that allow groups of related participants to communicate in complete privacy. At a finer granularity, private transactions are a way for members of a channel to engage in confidential interactions between the two parties. Zero-knowledge proofs are cryptographic primitives that allow proving certain aspects of a secret without revealing the actual secret. Hyperledger has big plans for zero-knowledge proofs but, at the time of writing, it only implements anonymous authentication through zero-knowledge proofs.

Other platforms, such as Quorum, an Ethereum version optimized for permissioned blockchains, also provide privacy features aimed at enterprise applications.
Crossover In this article, we have looked at the main differences between public and permissioned blockchains. While doing so, we have focused on the general case.

In reality, not all distinctions are that clean-cut. There are some overlap and crossover between the two types of blockchains.

For instance, public delegated proof-of-stake blockchains often leverage consensus protocols associated with permissioned blockchains to achieve high transaction throughput between a known subset of nodes. There are also public blockchains focusing on privacy for enterprise applications.

As with all engineering, blockchain architects have to choose the right tools for each use case.

In a future article, we will look at different blockchain platforms and provide meaningful comparisons.

This analysis was brought to you by the Blockchain team at Swish. We work on all aspects of blockchain and apply them to businesses. Interested in equipping your business with blockchain? We can help. Let’s talk.

Read more about what the Swish Blockchain team has been up to here.