The disruptions of the last year have prompted the acceleration of numerous emerging technologies, blockchain and distributed ledger technologies (DLTs) among them. While DLTs have been around for over a decade, the confluence of recent technological advancements with economic and societal forces confronts enterprises with renewed urgency to consider whether, when and how to deploy blockchain applications.
Distributed ledger technology, (e.g., blockchain) is an advancement in record-keeping in which transactions, authentications and interactions are recorded across and verified by a network rather than a single central authority. Although the term blockchain is used more frequently than (but often synonymously with) DLT, blockchains are but one type of distributed consensus structure.
DLT is best understood as an umbrella term that encompasses various distributed design paradigms and the technologies bundled therein. I'll examine two such paradigms that are critical for enterprise decision-making: permissionless vs. permissioned blockchains.
At the simplest level, the distinction lies in whether the design of the network is open for anyone to participate -- permissionless-- or limited only to designated participants, or permissioned. However, implementation decisions must take into consideration several other technological and market dynamics, summarized below and in the table.
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 that blockchains use to validate transactions and data. They are fully decentralized across unknown parties.
The key characteristics of permissionless blockchains are:
- full transparency of transactions;
- open source development;
- anonymity, with some exceptions;
- lack of a central authority; and
- 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 (AKA private blockchains or permissioned sandboxes) are closed networks in which previously designated parties, 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, as in permissionless blockchains. Tokens and digital assets are possible but less common than in permissionless.
The key characteristics of permissioned blockchains are:
- controlled transparency based on the goals of participating organizations;
- development by private entities;
- lack of anonymity; and
- 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.
- 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; attackers can't target a single repository and it is difficult to corrupt 51% of the network to disrupt consensus mechanisms
- 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.
- 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, because it allows diverse configurations, modular components and hybrid integrations
- Performance and scalability because fewer nodes manage transaction verification and consensus
- 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
While the table is intended to simplify DLT designs into two primary categories, businesses should be aware of various nuances in terminology and subsequent adoption implications. For instance, some people distinguish between private and consortium blockchain architectures. Here, private designates a single owner who invites others to join; consortium, 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 in their long-term planning. Hybrid is simply the notion that, as decentralized architectures scale across public, consumer, private, government entities and consortia, they will inevitably require and benefit from interoperability.
A hybrid world, in which some networks are necessarily smaller, tightly permissioned and optimized for discrete use cases, and 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
While 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:
- digital asset trading;
- crowdfunding and donations; and
- distributed file storage, such as blockchain storage.
Permissioned blockchains have enabled new applications that depend on privacy and security, including:
- supply chain provenance tracking;
- claims settlement; and
- 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 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; and
- streamline information portability across service providers, compliance adherence, insurance settlement, latency, cost reductions, even medical research efficiencies.
The organization is also aware of diverse risks involved in still-immature blockchain technology, unclear regulatory requirements, 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 is not 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 our current business, partner ecosystem, 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 clarity upstream will streamline downstream tool selection and configuration decisions.
Only once these areas are clearly defined for near term, and aligned for long term, should the organization begin to evaluate DLT infrastructures.
Common criteria include:
- Scalability and performance. Frequency and design of transactions and interactions with the ledger -- elasticity, consensus validation, security, risks of failure
- Power consumption. 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 contracts viability. Among business and regulatory stakeholders -- accountability and liability in cases of system compromise
- Tokens. These, which may or may 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 impact 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:
- transaction distribution;
- smart contract development environments;
- rules of validity and linkage;
- identity authentication and private keys;
- supervisory and regulatory nodes;
- built-in assets; and
- 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.
Distributed ledger technology is not 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.