top of page

Public vs. Permissioned Blockchains

By Adam Krellenstein

A blockchain is an architectural pattern for building globally consistent decentralized systems, and for running smart contracts---stateful, decentralized applications. There are two primary categories of blockchains: public blockchains and permissioned (sometimes “private”) blockchains. In public blockchains, anyone on the Internet can connect to a node, download a copy of the transaction history and start participating in transactions. In permissioned blockchains, only particular identities may even establish network connections and participate in the consensus protocol (ordering and approving transactions). Indeed, the difference is within the consensus protocol, and it’s generally possible to take other parts of a blockchain (for instance a virtual machine) and migrate them between consensus systems.

This isn’t as useful as one might expect. These two classes of blockchains find themselves with very different kinds of adoption. As I recently discussed in a piece for CoinDesk, public blockchains are great for creating global, uncensorable payment schemes like Bitcoin and Monero. Permissioned blockchains, by contrast, are much better suited for applications involving smart contracts as compared to platforms like Ethereum or Cardano. They’re also much better for use by enterprise, especially within institutional finance, because of the many performance, scalability, efficiency, regulatory and security advantages that these have over public networks.

Symbiont Assembly, for one, is a permissioned blockchain platform. At least for Symbiont’s customers, the above qualities are extremely important. They simply wouldn’t be able to use a public blockchain platform in production for any of their use cases, even if those platforms had the necessary feature set. In fact, all public blockchains will, for the foreseeable future, completely lack support for transaction level privacy outside of the simplest payment systems, immediately precluding them from meaningful adoption. Public blockchains, by the simple fact that they have to allow for anonymous network participation, need to make a number of significant trade-offs in their designs that make them unsuitable for enterprise use.

Footnote: permissioned blockchains do not necessarily have transaction privacy! When people talk about “privacy support” in a blockchain, they mean that not everyone in the network can see all of the network data. Permissioned network participation adds another layer of security, because you have to be approved to join the network in the first place, but that in itself does not provide the levels of confidentiality required for enterprise blockchain deployments.

One distinctive feature of all public blockchains is their integration of a cryptocurrency, which must exist even if for no other reason than to incentivize participation by the network’s members in the consensus process. Indeed, every decentralized network requires some kind of voting system by which the users collectively decide which transactions are included in the global transaction log. In a network with anonymous users, votes can’t be allocated to real-world identities, so they’re allocated to the otherwise wasteful consumption of real-world resources, and users are rewarded in the cryptocurrency in proportion with their resource commitment. Traditionally, this resource is computational power (for “proof-of-work” systems); with “proof-of-stake”, the resource destruction is in the locking up of large amounts of capital in the cryptocurrency for long periods of time, with associated currency risk and loss of potential investment income. By contrast, within a permissioned network, the cost of operating the node is de minimis and usually trivially outweighed by the business value associated with being part of the network.

Inefficiency is a relatively widely known limitation of public blockchains (even if the costs associated with proof-of-stake systems are papered over), however, one that dramatically affects the security and correctness of the blockchain system is that of blockchain reorganizations. A blockchain reorganization is a rewriting of recent network history because of a temporary network split or consensus break. Whereas a (well-designed) permissioned blockchain will “fail safe” and halt progress in such circumstances, public networks often have “confirmed” transactions removed from blockchain and effectively reversed. Indeed, in a “51% attack”, a malicious node could theoretically overwrite the entire network’s history! Surprisingly, permissioned blockchains are actually even more immutable than public ones. Once a transaction is in the Symbiont Assembly log, it’s there forever---no exceptions.

Because of the way that public blockchains have to allocate votes by resource consumption, the performance and scalability of these networks is also very poor. This has unfairly given all blockchains a reputation for slowness, and while they’ll probably never be as fast as traditional centralized databases, permissioned blockchain consensus algorithms can easily handle tens of thousands of transactions per second with latency on the order of hundreds of milliseconds. By contrast, the transaction latency in Bitcoin is approximately one hour, and in Ethereum it is around a minute. Another way to think about this is to approach it from the perspective that the consensus protocols for permissioned blockchains are actually much closer to the consensus protocols for traditional distributed databases (e.g. Paxos or Raft), which are also highly performant. Unfortunately it’s not possible to just use Paxos or Raft for a blockchain platform if you really care about security, because these protocols are merely crash fault-tolerant, which means they can only tolerate nodes shutting themselves down gracefully when anything goes wrong. The consensus protocol used in Assembly, by contrast, is Byzantine fault-tolerant, which means it is designed to handle arbitrary failures, including malicious behavior and collusion.

Finally, beyond the merely technical challenges that come with using a public blockchain, there are a number of other practical difficulties. With a public blockchain, the governance of that network is extremely hard to manage. Hard forks and protocol upgrades are nearly impossible to implement safely without proper governance. This is an especially important consideration for Symbiont’s clients, who need to maintain some level of control over the future of their mission-critical software systems, even in the face of an angry Internet mob wanting to fork a network. Similarly, regulatory restrictions on governments and corporations prevent them from using public blockchains for compliance reasons, where for instance a transaction fee paid might unintentionally go to a miner on the OFAC list. Together, these factors create significant operational risk for those relying on blockchains for supporting entire business models or even just key processes, including unpredictable transaction costs and abrupt changes in functionality or performance.

The argument exists for simply using public blockchains for all decentralized applications. You could... but should you? There is a common perception that with enough innovation, you can make a public blockchain look like a permissioned one. It’s theoretically possible with enough magical cryptography, but completely impractical for the foreseeable future. As it stands, none of the major public blockchain smart contracts systems even has notable privacy support. For major institutions that are beginning to utilize this technology for enterprise applications, the advantages of permissioned blockchains are clear. Symbiont Assembly, as the first ever permissioned blockchain for smart contracts, lets institutions create efficiencies, eliminate manual data replication and reconciliation processes, and enable real-time data sharing with complete privacy.

bottom of page