Author: Mark Bruton

For those of you that are familiar to blockchain, or the distributed ledger technology (DLT) sphere in general, it is quite likely that you’ve encountered the debate over what the best DLT solution is: permissioned or permissionless?

The purpose of this article is not to get stuck in the weeds when it comes to why one should implement one type of network over the other, but rather to highlight some of key differences that differentiate these two DLT design paradigms. Specifically, this article will discuss some of the advantages associated with the use of an up and coming blockchain based and permissionless DLT system, known as Leep, over the better known Hyperledger Fabric blockchain framework — a permissioned network design hosted by the Linux Foundation. Before going into a comparison, let’s take a couple of minutes to go over both blockchain solutions at a high level and consider some of their more noteworthy features.

Leep Network

Leep network is an up and coming permissionless (public) DLT start-up that aims to deliver a truly scalable and secure blockchain network, without any of the negative environmental or economic impacts associated with inefficient consensus mechanisms, such as Bitcoin’s Proof of Work mining.

The design philosophy driving the development of the Leep network places an emphasis on the importance of a well-constructed and transparent governance model, where major network decisions or the reversal of errors are decided by popular vote. The objective of this approach is to enhance trust in the network by limiting the degree to which developers can impose changes to the network that may be motivated by ill-informed or misguided intentions.

Leep employs a novel Directed Acyclic Graph (DAG) data structure that must satisfy a mathematical property known as “closure” before it can be committed to a lightweight and semi-private blockchain. The requirement of closure allows for a fully deterministic database solution, where network security and data integrity are bolstered by the immutability and tamper resistant properties of blockchain.

Instead of using blockchain as a direct source for the storage of potentially sensitive information, Leep combines distributed cloud storage technologies and data encryption techniques with blockchain, allowing the chain to act like an access control mechanism for the secure allocation of permissions. This little bit of ingenuity effectively separates the data layer from the control layer and has the advantage of drastically off-loading the “Light Chain”, without taking away from the security benefits offered by the blockchain itself. Moreover, since data is not actually stored on-chain, data transactions can be referenced and validated without revealing the raw informational content of stored data (semi-private) and so Leep’s solution conforms to GDPR and data privacy/protection laws.

Leep’s proposed network implementation is unhindered by the typical scalability limitations that hold conventional blockchain DLT networks back. Within Leep’s proposed system architecture, significant network bottlenecks are removed through use of a unique closure-based consensus mechanism, several distinct node types/roles and security protocols, which together allow for the parallelization of the transaction validation process. Much like the concept of database sharding, where load is spread across multiple shards of a single database, Leep’s network supports parallel transaction processing and so the network transaction throughput is proportional to the size of the network itself. This means that the number of transactions that the network can process every second, or Transactions per Second (TPS), will continually increase as the network gets larger or gains greater adoption.

Unlike current efforts to implement sharding in a blockchain network, however, Leep’s proposed architecture achieves scalability without impacting on the network’s security model. The means by which Leep’s network design accomplishes this feat is outside the scope of this article but if this passage happens to pique your interest, you can read more about Leep’s network security in “Leep Network: Scalability and Security through DAG Closure” [1].

Hyperledger Fabric

Hyperledger Fabric is an open-source and permissioned blockchain-based DLT framework, which makes up a part of the larger Hyperledger umbrella project hosted by the Linux Foundation. It comprises a modular architecture where network components, such as consensus and membership services, use a plug-and-play design.

Fabric differs from more traditional permissionless blockchain systems in a number of ways. Firstly, node roles are separated and split between chaincode execution (chaincode is Fabric’s equivalent to smart contract code) and block ordering services (consensus). This approach actually bears some similarities to the separation of node roles in Leep’s architectural design and can be viewed as a noteworthy innovation in both blockchain frameworks. The segregation of node roles removes the need for the sequential execution of certain tasks, as different subsets of peers can execute unrelated transactions in parallel, and all network nodes no longer have to process every single network transaction. This has obvious benefits in terms of total network transaction throughput and performance.

Secondly, the modular nature of Fabric’s architecture introduces a significant degree of flexibility and the ability to customize your blockchain solution. Depending on the trust assumptions/model associated with a given business use case, less stringent/higher performing consensus protocols can be implemented or swapped out with slower, more secure alternatives with relative ease.

When it comes to privacy, permissioned frameworks reign supreme. The design of Fabric’s framework enables data partitioning on the blockchain, where sensitive data can be contained within specific channels that can only be accessed by a closed group of permitted (permissioned) participants. This privacy feature is an important one for many business use-cases, where data protection laws and regulations are concerned. Certain industries are held to higher standards than others and so there are some specific business cases where permissioned or private solutions are the only feasible DLT option.

There exists no native blockchain token within the Fabric framework, since incentive systems are not used to secure the network. This is an important distinction that can be made between many permissioned blockchain solutions and their permissionless counterparts, as it effectively limits their application to private corporate use and more centralized, trust-based scenarios.