Permissioned vs. permissionless blockchains: Key differences

What is permissionless blockchain and what are its key characteristics?

Permissionless blockchains, also known as trustless or public blockchains, are open networks available to everyone to participate in the consensus process blockchains use to validate transactions and data. They are fully decentralized across unknown parties.

The key characteristics of permissionless blockchains are the following:

• Full transparency of transactions.
• Open source development.
• Anonymity, with some exceptions.
• Lack of a central authority.
• Heavy use of tokens and other digital assets as incentives to participate.

What is permissioned blockchain and what are its key characteristics?

In contrast, permissioned blockchains -- also known as private blockchains or permissioned sandboxes -- are closed networks in which previously designated parties, who are sometimes members of a consortium, interact and participate in consensus and data validation. They are partially decentralized in the sense of being distributed across known participants rather than unknown participants. Tokens and digital assets are possible but less common than in permissionless blockchains.

The key characteristics of permissioned blockchains are the following:

• Controlled transparency based on the goals of participating organizations.
• Development by private entities.
• Lack of anonymity.
• Lack of a central authority, but a private group authorizes decisions.

Pros and cons of permissionless blockchain

The open, highly decentralized nature of permissionless blockchains has certain advantages and disadvantages.

Pros

• Broader decentralization that extends access across more network participants than in permissioned blockchains.
• A high degree of transparency, which speeds reconciliation across unknown parties.
• Resistance to censorship, thanks to broad accessibility and participation across locations and nationalities.
• Strong security, since attackers can't target a single repository, and it's difficult to corrupt 51% of the network to disrupt consensus mechanisms.

Cons

• Poor energy efficiency due to the resource-intensiveness of network-wide verification of transactions.
• Lower performance and scalability from the strain this verification process puts on computing resources.
• Less privacy and user control over information.

Pros and cons of permissioned blockchain

Being closed to outsiders gives permissioned blockchains clear advantages, but there are downsides.

Pros

• Decentralization can be incremental, which allows multiple businesses to participate without all the risks of highly centralized models.
• Strong privacy because permission is needed to access transaction information.
• Customizability for specific uses, since it enables diverse configurations, modular components and hybrid integrations.
• Performance and scalability because fewer nodes manage transaction verification and consensus.

Cons

• Increased risk of corruption and collusion because there are fewer participants than in a permissionless blockchain.
• Consensus is more easily overridden because the owners and operators can change the rules of consensus, immutability and mining.
• Less transparency to outside oversight because the number of participants is limited and the network's operators determine privacy requirements.

Although this article places DLT designs into two primary categories, businesses should be aware of various nuances in terminology and their implications for adoption. For instance, some people distinguish between private and consortium blockchain architectures. Here, private designates a single owner who invites others to join, while consortia -- sometimes called semiprivate architectures -- are governed by a group rather than a single entity.

Zooming out from these distinctions, organizations should also incorporate hybrid architectures into their long-term planning. Hybrid is simply the notion that, as decentralized architectures scale across consortia as well as public, consumer, private and government entities, they'll inevitably require and benefit from interoperability.

A hybrid world in which some networks are necessarily smaller, tightly permissioned and optimized for discrete use cases, while others are open, transparent platforms that also integrate into vertical networks, will ultimately enable what many envision long-term as a "blockchain of many blockchains," similar to the "internet of many intranets."

Permissioned vs. permissionless blockchain: Use cases

Although both permissionless and permissioned blockchain architectures enable similar value propositions, their distinct differences make each one more suitable for certain uses and less suitable for others.

Permissionless blockchains tend to be used in applications with a strong financial component or that require highly decentralized blockchains, such as the following:

• Digital asset trading.
• Crowdfunding and donations.
• Distributed file storage, such as blockchain storage.

Permissioned blockchains have enabled new applications that depend on privacy and security, including the following:

• Supply chain provenance tracking.
• Claims settlement.
• Identity verification.

Indeed, the key to adoption success lies in aligning use case criteria with the broader market dynamics and the range of DLT configuration options. This approach simultaneously demands that companies take a longer, strategic view to avoid piecemeal implementations, especially on top of legacy systems. The objective is to develop a vision and prioritize incremental steps to build, test, validate and evolve toward the vision.

To illustrate, let's consider a scenario and the key considerations that ensue from it.

A large healthcare organization with several subsidiaries and ecosystem partners is evaluating the case for DLT. Decentralizing health records represents several value propositions for the organization, its employees, patients, partners and medical research. Distributing this information can do the following:

• Lower the risk of data tampering, fraud, human error and singular attack-point vulnerability.
• Improve records integrity, access, privacy and auditability.
• Streamline compliance adherence, insurance settlement, latency, information portability across service providers, cost reductions and even medical research efficiencies.

The organization is also aware of diverse risks involved in still-immature blockchain technology, unclear regulatory requirements, as well as cultural and political objections involving sensitive information, business models and stakeholder adoption -- not to mention the risk of failure. Despite having a broad grasp of potential applications, the organization isn't ready to choose architecture.

Permissioned vs. permissionless: Determine which suits your project

Here's how this healthcare organization could prepare to make these difficult choices.

First, define the strategic purpose. How do distributed health records, in this case, align with the organization's broader strategy and role in the ecosystem? Resist the temptation to start with a blockchain "strategy," and instead evaluate the ways in which the organization can serve as a platform to simultaneously contribute value to and extract value from the broader ecosystem.

Second, prioritize use cases and initiatives in context, not in a vacuum. Given the current business, partner ecosystem, and regulatory, cultural and technological contexts -- and given the trajectory of each -- what are three initial areas to pilot? What is the health and economic value associated with each, across stakeholders and when interconnected? What metrics would determine success: access, speed, having a "single source" of truth, wait times, patient outcomes? These will evolve, but upstream clarity will streamline downstream tool selection and configuration decisions.

Only when these areas are clearly defined for the near term and aligned for the long term should the organization begin to evaluate DLT infrastructures.

Common criteria include the following:

• Scalability and performance. The frequency and design of transactions and interactions with the ledger -- including elasticity, consensus validation, security, risks of failure -- make up this criterion.
• Power consumption. This criterion includes computational and environmental costs associated with consensus and how transactions and interactions are validated.
• Roles and governance. This includes how organizations and stakeholders allocate power, make decisions, set permissions, collaborate on code, etc.
• Privacy and anonymity. Established across stakeholders and aligned with regulatory regimes and business parameters, it also informs the permission framework.
• Technology landscape. This includes incumbent systems, as well as requirements for cloud, edge, power consumption, etc.
• Smart contract viability. Among business and regulatory stakeholders, smart contracts determine accountability and liability in cases of system compromise.
• Tokens. These, which might or might not be relevant, can offer powerful incentives for participation and behavioral economics associated with distributed applications.
• Talent. Access to technical, design and legal resources can affect other investments, such as levels of complexity managed internally versus outsourced.
• Culture. From leaders to builders to consumers, blockchain adoption is only as viable as humans' trust and willingness to change.

Approach DLT functionality for maximum flexibility. Just as organizations should understand permissioned vs. permissionless blockchain in the longer context of hybrid architectures, so too is it important to simultaneously understand a DLT's various à-la-carte component functions, including the following:

• Transaction distribution.
• Consensus.
• Smart contract development environments.
• Rules of validity and linkage.
• Immutability.
• Identity authentication and private keys.
• Supervisory and regulatory nodes.
• Built-in assets.
• Integration mechanisms.

There are a variety of constantly evolving approaches within each of these. Instead of conforming use cases and criteria to the technology, organizations should approach DLT as a menu from which to select and customize different combinations, in different flavors, for different business problems, all while accounting for different legacy environments.

DLT isn't a panacea or solution for all IT inefficiency. Buyer beware of blockchain hype and experimentation for experimentation's sake. Rather, businesses should view DLT as a series of technological modules and concepts to be selectively chosen and applied.