news

Permissioned vs. permissionless blockchains: Key differences

Spread the love

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;
  • consensus;
  • smart contract development environments;
  • rules of validity and linkage;
  • immutability;
  • 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.