Public v. Permissioned Blockchains
It’s not a binary choice!
You will often hear blockchains classified as either public (sometimes referred to as permissionless) or permissioned (sometimes referred to as private). However, classifying blockchains as either public or permissioned has a tendency of polarising debate about the use of blockchain, thus missing the point that a blockchain is ultimately a tool or methodology or mindset for solving particular types of problems.
In reality, the differences you find in the blockchains is a continuum between permissioned and public. It is not a simple dichotomy.
I am using the term ‘blockchain’ loosely but to fully appreciate that the differences, it is necessary to distinguish blockchain as a piece of technology and blockchain as a way we deploy technologies to solve a problem, and for want of a better term, I shall call such problems ‘blockchain use cases’.
If you were to examine blockchain technology, at its heart, it is essentially a distributed computing system supporting something akin to the Remote Procedure Call (RPC) protocol. In distributed computing, an RPC is where instructions are sent from a computing node (typically known as a client) to one or more nodes (servers) for processing aka the client-server model.
In the blockchain domain, RPC instructions (more commonly known as transactions) are typically cryptographically signed. The nodes receiving such transactions rely on such signatures to verify their source and determine if they are worthy of execution.
In a multi-node computing system, where there are multiple clients and servers, transactions can originate from multiple sources and may be processed by multiple servers. In this scenario, sequencing of these transactions is needed to ensure that all servers maintain a consistent state of the world — i.e. all servers produce the same computed outcome in a given time frame. In the blockchain domain, this sequencing for transactions is referred to as consensus (also commonly referred to as mining or ordering).
A unique feature of a blockchain system is that way transactions are packed into blocks and the blocks are then ordered by a series of cryptographically signed links. This is to ensure that historical records of transactions are immutably stored.
Just like RPC, blockchain technologies rely on code installed on servers to execute incoming instructions. The code used to process these instructions is typically referred to in the blockchain domain as a smart contract.
Figure 1 provides an overview of the blockchain technology stack (i.e black coloured boxes).
A question worth asking about blockchain as a technology is this. How does blockchain differ from existing distributed systems and what problem is blockchain meant to solve?
Broadly speaking, the blockchain use case is one where parties transacting with each other but do not want to have an intermediary to ensure that all parties have a common view of the world. This scenario is where each party in a network retains control over its own node or nodes. All parties are able to issue transactions to other parties. All parties process transactions independently but must produce the same outcome in a given time frame as others to maintain a shared view. Also, all parties to the transactions must record these transactions in an immutable manner.
Let’s imagine that there is a clear divide between public and permissioned blockchains. The question is, what makes a blockchain public or permissioned?
Public blockchain
At one extreme, when we speak of a public blockchain, such as the Ethereum network, we are referring to nodes where all aspects of the stack are open to other nodes without restrictions.
If you refer to Figure 1, this includes the infrastructure/networking layer where any node that is discoverable on the internet has the potential to send transactions to each other via IP address. No single party curates access to the network through mechanisms such as IP whitelisting or subnetting.
Any node hosted on a publicly accessible IP address (i.e Geth) can receive transactions from any client (Web3j) without restriction. This applies to smart contracts too, where all nodes in the network are obliged to install these when they are issued. All nodes must also hold transactions history regardless of their relevance to them.
At the user level, interacting with the client, in a public mode, any users are permitted to interact with it. Transactions issued by users via a client are disambiguated cryptographic keys that are used to sign the transactions. There is no authentication or authorisation or access control mechanism to identify users. A user generates his/her own keys and he/she can start transacting.
Permissioned blockchain
Permissioned blockchains, on the other hand, are curated at various levels of the stack.
At the network level, parties in the form of a consortium decide if they permit their nodes to connect to each other. The parties can also curate transactions by deciding collectively who can see what transactions. Hyperledger Fabric uses channels, which are analogous to subnet, to curate transactions amongst nodes. In this particular mechanism, nodes in one channel can see each others’ transaction but not transactions in other channels.
At the contract level, not all nodes are permitted to host a particular smart contract or execute a particular contract. Fabric and Sawtooth require every node owner to consciously decide to install/activate the contract[1]. In this case, only nodes with contracts installed are able to perform the necessary computation associated with a transaction. Contrast this with an Ethereum based public network. When you install the contract in one Ethereum node, the network will replicate the contract to all participating nodes without prejudice. All nodes must perform computation regardless of whether it is relevant to it.
Finally, at the application level, not all users may be permitted to issue transactions from a particular node. It is worth noting that on a supposedly public network, you could also configure an application level client to permit only certain users to submit transactions.
An extreme form of permissioned blockchain is one where all levels are curated in some way. Other less extreme forms might only have certain aspects curated, for example, having a client node that will accept transactions without curation from any users but the blockchain and infrastructure level could be curated.
Wait. You might be asking, does this means permissioned blockchain requires a centralized party to curate activities in the network? If yes, won’t it make invalid the point of blockchain as the basis for a decentralised system?
The answer is no. In a permissioned blockchain, nodes are decentralised much like nodes in a public blockchain. There is no centralised party “filtering” transaction in the network. Every party in the network retains control over its own node or nodes. The parties in the network will individually decide by configuring their nodes (e.g. via contracts) in a way that will permit certain parties to transact. All transactions are processed by all participating and permitted nodes in a decentralised manner.
Public versus permissioned is a matter of degree
In reality, the public/permissioned divide is a false dichotomy. Consider the case of Ethereum. From a technological perspective, there is nothing inherent that makes Ethereum based technology public. You can configure Ethereum technology such as Geth to connect in a private network or to the main Ethereum network.
Likewise, with Hyperledger based technology, whilst often viewed as a permissioned blockchain, it could be configured to work in a manner not dissimilar to Ethereum’s public or main net. Hyperledger Sawtooth, in particular, could be made discoverable on the Internet and any other nodes without discrimination.
The differences between a blockchain technology for a public or permissioned setting is largely dependent on how easily, out-of-the-box, it can be configured. However, if you plan to use Hyperledger Fabric for a public setting, its design is such that you will need to do lots of work to make it possible. The point is it is not impossible to do so but you will have to do it mostly by modifying the source code.
Sawtooth, as compared to Fabric, is a lot easier, out-of-the-box, to facilitate a public network. However, the out-of-the-box consensus engine (currently Proof of Elapsed Time) might not have the capacity to cope with a network involving as much traffic as that expected of say one based on Proof of Work used in Ethereum. Also, Sawtooth supports so-called runtime consensus where you can dynamically replace one with another without the need to manipulated at the source code level.
Conversely, using Geth in a permissioned setting presents challenges too, especially the need to deal in cryptocurrencies or gas, which limits complex operations such as having to determine if transactions are permitted or not.
If you were to consider blockchain from a use case perspective, proponents of the public network believe that a proper blockchain would be one where no intermediaries are involved in curating transactions. In some cases, where there is a requirement for censorship proof transactions (i.e. where clients don’t rely on a single server) a public blockchain might be useful. Since all server on the network shares the same state of the world, a client can easily switch from one server to others to fulfil the transactions.
However, the vast majority of use cases, even if there is a reason to eliminate intermediaries to reduce friction amongst transacting parties, some degree of privacy is needed. Not everyone wants to have their transactions exposed to all parties in a single network. On a public network such as Ethereum, you will find evidence of parties building solutions that conceal aspects of transactions from disinterested parties — e.g. public blockchain is used to confirm a transaction has been finalised whilst the actual data related to the transaction is sent securely via encryption. This complicates engineering task to address such a use case. A permissioned blockchain might have lessened the engineering tasks.
Not all aspects of a public network, such as Ethereum, are completely permissionless. For instance, if a forked (a process akin to upgrading to a different version) is needed to be instituted, it can’t be done without permission from all owners of the mining nodes.
It is worth noting that blockchain nodes are themselves code that is written by people with the necessary expertise. Whilst public network nodes such as Ethereum are open source and community driven, not every contribution will necessarily find its way into the final product. At this level, some semblance of governance is needed and permission for a feature to be incorporated into a node.
In conclusion, there is no dichotomy between public and permissioned blockchain. From a technological perspective, the differences amongst the offerings, available as of the publication of this blog, depends on the extent to which they are designed to operate, out-of-the-box, to support a public or permissioned configuration.
The differences from a use case perspective is a continuum with varying degrees of permission configured at the different levels of blockchain stacks. The principal determinant of the permissions instituted is driven by parties acting as a consortium. In the case of Ethereum network, permission to fork and incorporate features into the nodes are delegated to the Ethereum foundation. Beyond that level, parties to the network have no significant means to restrict each other except through smart contracts. Parties can create contracts that will only enable to particular parties to fulfilled. Nevertheless, they cannot stop disinterested parties from viewing the contracts created.
Hyperledger based technologies rely on Hyperledger Foundation as the governing body for the way the technology is developed not unlike the way the Ethereum Foundation functions. However, Hyperledger itself does not maintain a ready-to-use network. It is left for the originators of a network to form one and institute their own governance model for the operations of the network.
If you plan to use blockchain to solve a pain-point, the starting point is to decide if the problem you wish to solve requires a decentralised solution and then decide the extent of privacy you wish to institute. This should drive the governance model you need for your blockchain use case. The starting point is not a choice between a public or permissioned network.
Notes:
[1] Sawtooth’s approximate equivalent of a smart contract is a transaction processor and Fabric’s equivalent is a chaincode. Sawtooth’s transaction processor is unique in that it can be implemented as a native application like a Linux/Windows/Mac executable or act as a virtual machine to host specialised contract languages such as DAML.
