https://www.techtarget.com/searchcio/tip/Permissioned-vs-permissionless-blockchains-Key-differences
The disruptions of the last year have prompted the acceleration of numerous emerging technologies, blockchain and other distributed ledger technologies (DLTs) among them. Although 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.
DLT 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. We'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 (permissioned). However, implementation decisions must take into consideration several other technological and market dynamics, summarized below.
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:
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:
The open, highly decentralized nature of permissionless blockchains has certain advantages and disadvantages.
Being closed to outsiders gives permissioned blockchains clear advantages, but there are downsides.
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."
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:
Permissioned blockchains have enabled new applications that depend on privacy and security, including the following:
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:
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.
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:
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:
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.
18 May 2023