Share this post:

A new paper, from the IBM scientists behind many of the thousands of lines of code in Hyperledger Fabric, reveals the rationale and the thought process for the architecture, for the first time.

It all started about two years ago with late night calls between Zurich and the US. IBM researchers were bouncing ideas off each other in search of ways to create a more resilient, extensible and scalable blockchain platform suitable for enterprises. What began with brainstorming in the wee hours of the night for the Zurich team, has evolved into a whole new architecture for permissioned blockchains that includes an ordering service, identity and membership, scalable dissemination, smart contract execution and ledger maintenance.

The end result is a flexibly-designed blockchain system that breaks away from a one-size-fits-all premise so it can be tailored to particular use cases and trust models.

Hosted by the Linux Foundation, Hyperledger Fabric is a permissioned blockchain platform, which means that all participants are, to an extent, identified and that it comes with a proper governance to resolve issues. Hyperledger Fabric enables secure interactions among a set of known, identified participants who have a common goal, but do not fully trust each other. By relying on the identities of peers, a permissioned blockchain like Hyperledger Fabric can use traditional Byzantine-fault tolerant (BFT) consensus as opposed to Proof-of-Work (PoW) consensus algorithms.

While it’s important to note that a permissioned service doesn’t have to share every part of the identity, it’s vastly different when compared to a permissionless blockchain, where anyone can join a network, invoke transactions, participate in consensus, and write new blocks into the chain. Consensus in permissionless blockchains also requires investing substantial computational power for “mining,” a process that is guzzling enormous amounts of energy today.

Breaking out of the box

Traditional blockchain platforms, permissionless and permissioned ones, follow a sequential execution style, whereby transactions on smart contracts are typically executed after consensus or entwined with it and where all participants execute all contracts. This order-execute architecture (Figure 1) limits the scalability, requires sequential execution of transactions, and endorsement by all peers.

Hyperledger Fabric was devised to use a different architecture that supports scalability and flexible trust assumptions. By rethinking the notion of permissioned blockchains, Hyperledger Fabric introduces a novel approach that revamps the way blockchains cope with non-determinism and security issues such as resource exhaustion or performance attacks.

Hyperledger Fabric uses a new execute-order-validate architecture, which lets transactions execute before the blockchain reaches consensus on their place in the chain, as illustrated in Figure 2.

Furthermore, it supports modular consensus protocols and lets distributed applications be written in standard programing languages. Hyperledger Fabric is the first blockchain system that runs distributed applications written in general-purpose programming languages (such as Go, Java, Node.js), without systemic dependency on a native cryptocurrency. This is a significant advancement to existing blockchain platforms, which require code to be written in a domain-specific language that requires specific training.

The execute-order-validate architecture departs radically from the order-execute paradigm in that it separates the transaction flow into modular building blocks and includes elements of scalable replicated databases. Fabric pioneers a hybrid replication approach, combining passive and active replication in the Byzantine model. Fabric’s replication is passive in the sense that every transaction is executed or endorsed by a subset of peers only, which allows for parallel execution and non-determinism. And because the effects of transactions on the ledger state are written only after a consensus is reached on their order, Fabric also uses active replication.

Essentially, this hybrid replication design supports a flexible endorsement policy in any given smart contract and simultaneously allows Fabric to respect application-specific trust assumptions according to the transaction endorsements. In other words, the transactions don’t have to be constructed all in one order, as long as they are consistent with each other and come together at the right time. Since the consensus is modular, its implementation can be tailored to the assumption of a specific deployment. This adds a great deal of flexibility and lets the system rely on well-established toolkits and protocols for CFT (crash fault-tolerant) or BFT (Byzantine-fault tolerant) ordering.

After fleshing out their initial ideas and creating a design document on the “consensus architecture,” the researchers convinced their colleagues in the community of open-source developers behind Fabric to adopt this model. It took about 18 months from the initial drafts until version 1.0 of Hyperledger Fabric was released in July 2017 and materialized their approach.

Advantages in a nutshell

Due to its innovative architecture, Hyperledger Fabric has the ability to deliver unique network capabilities such as enhanced privacy and confidentiality, efficient processing, scalability, standard programming languages, and a modular structure that can be customized for individual deployments. Such capabilities make Fabric a suitable blockchain platform for businesses.

The flexibility is almost endless. One could even apply an additional layer of permission through the platform’s identity management service. As an example, a specific user ID could be permitted to invoke a smart contract application but be blocked from deploying a new one.

Evaluating Fabric

The research paper also reports on benchmarks and performance optimizations of Hyperledger Fabric. For evaluating the blockchain in a way that is comparable to a cryptocurrency and other smart-contract platforms, a data structure modelling token-transfer transactions was created.

The performance numbers obtained show that Hyperledger Fabric deployed in a single cloud data center achieves an end-to-end throughput of more than 3,500 transactions per second with latency less than one second. While the research team refrains from making any direct comparisons to the other systems, the benchmarking effort has given the team valuable insight in the behavior of Fabric.

While Hyperledger Fabric today does not currently support tokenization, we recognize that tokens have strong applicability to certain use cases. We are open to leveraging appropriate tools and capabilities to address the growing needs of enterprise clients.

It also must be noted that Hyperledger Fabric is a complex distributed system and that its performance depends on many parameters, ranging from choice of the distributed application to transaction size to consensus implementation to the hardware. We take this work as a starting point to further evaluate and optimize Hyperledger Fabric, but this benchmark already demonstrates that the platform is extremely robust.

Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains, Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolić, Sharon Weed Cocco, Jason Yellick, https://arxiv.org/abs/1801.10228v1