Project Hyperledger is hosted by the Linux Foundation and deals with blockchain implementation and related tooling projects. The focus is mainly on private and permissioned blockchain systems. The project was launched at the end of 2015 and quickly attracted the attention of several large companies that were early adopters of distributed ledger technologies at that time. This has resulted in a number of project proposals that have been adopted as incubators since 2016. In most cases, an existing code base has already been submitted with the respective proposals. This includes the well-known projects Fabric and Sawtooth.
Today, the Hyperledger project consists of a very active community. More than 220 organizations now support the initiative. In the largest projects, there are more than 100 contributors and about 5000 commits each (as of March 2018). Among blockchain enthusiasts, the project is already considered highly significant.
The Hyperledger subprojects
But what is each project about? What applications are they intended for? These have been the most frequently asked questions recently. The Hyperledger project website contains little information. Some solutions are also insufficiently documented, but are mentioned in reports on interesting projects. That situation requires a rough overview.
Let us take a look at the names Fabric, Sawtooth, Burrow, Indy and Iroha. These occur in conjunction with fundamentally different implementation approaches for blockchain solutions. We will also briefly discuss the projects that build tools for the ecosystem. Here you can find Composer, Explorer and Cello.
Fabric – The flexible approach
Fabric is the most active of the projects and at the same time it is designed to be used for all kinds of blockchain applications. It was the first of the project proposals that turned the Incubator status into an active project. The latest version 1.0 is described as stable and version 1.1 is already in the starting blocks with many improvements.
The Fabric platform is so flexible because all components are ‘plug and play’. Fabric represents an organizational structure consisting of any number of organizations. All of them operate network nodes, so-called peers. Peer nodes can have different roles, allowing networks to be orchestrated as needed. In addition, the consensus algorithm can be freely defined or implemented. The role of certificate authorities in the network, knowing all identities involved, can also be fulfilled by different implementations. For the fulfillment of different areas of privacy in the network, channels can be created. All organizations and participants are usually together in one big channel. However, if an organization needs to handle private transactions with another one, channels can be used to create a kind of subnet. If required, completely individual code can be deployed on channels. Ultimately, you enjoy the most freedom when implementing business logic. The code that exists for this purpose and that can be installed individually in the channels is called chain code and can be developed in Go, Node.js or Java.
“Fabric is the granddaddy of the other projects,” says Brian Behlendorf (Executive Director of Hyperledger, also known for the Apache web server as well as foundation member of the Apache Software Foundation).
Sawtooth – Trust in Software Guard Extensions
Sawtooth is also an already active project and since January 2018 also available in the stable version 1.0. It also leverages a modular architecture that enables private blockchain networks between partners who do not trust each other. Sawtooth was suggested by Intel, so that also the first code base was submitted by the same company. Intel is still very interested in the project and Hyperledger in general.
According to Behlendorf, Sawtooth is a grandson of Fabric. However, it is based on a completely different code base. It was written mostly in Python instead of Go. The unique selling point of Sawtooth is a different concept for the consensus mechanism (What actually is a consensus mechanism?). This consensus mechanism is not variable as with Fabric. If you decide to use Sawtooth, you choose this consensus algorithm. It is probably the reason why you choose Sawtooth in the first place.
The consensus algorithm is called “Proof of elapsed time” and actually wants to improve what we know as a Proof of Work (also called “mining”) especially from the world of cryptocurrencies. PoET implements a hardware-based random number generator that selects which network node is allowed to close the next block of the Blockchain. The hardware requirements for this are the Software Guard Extensions (Intel SGX). This is an extended x86 CPU architecture that provides a particularly protected memory area for processes. The tedious puzzle process at the PoW is therefore abbreviated by a quick draw about the SGX at the PoET. This creates a much more scalable and energy-saving consensus mechanism. Unfortunately, this mechanism is heavily dependent on the hardware, which in turn depends on Intel. Ideologically, the PoET is questionable because consensus could be controlled by a central authority. The required SGX architecture also makes homogeneous blockchain networks difficult to manage because all nodes depend on the right physical machines.
The use of Sawtooth makes sense in some contexts. Nevertheless, one should know exactly on what technical conditions the consensus is based and how it can be manipulated. After all, an untrustworthy consensus undermines the entire effort required for blockchain usage.
Burrow – A relative of the Ethereum Virtual Machine
Burrow is currently in Incubator status and version 0.17 as of March 2018. The goal of Burrow is to build a technological bridge to the Ethereum blockchain. This is because many organizations behind project Hyperledger have also joined the Ethereum Enterprise Alliance. They are therefore interested in both ecosystems and want to benefit from them. What Burrow already offers at its early stage is a simple Blockchain architecture. This consists of three components, which (as with Fabric and Sawtooth) must be distributed redundantly over the built private blockchain network.
One of Burrow’s components is responsible for building consensus on the network, implementing Proof of Stake using the Tendermint protocol. On the subject of Proof of Stake you can hear a lot about Casper from the ranks of the Ethereum project. Casper and Tendermint differ in their approaches to implementing PoS, and there is a very informative article on Medium that explains and compares both of them.
The second component is the implementation of the Ethereum Virtual Machine (EVM). With this, Burrow actually doesn’t want to deviate very far from the EVM specification. Rather, identities are added to it. Specific authorizations can be defined for each identity. Thus, Burrow turns the normal Public Ethereum VM into a VM for a permissioned blockchain.
The third component is the API gateway, which provides the state from the local ledger of a node and the state of the distributed ledger via REST and JSON-RPC to the outside world.
The choice of Burrow is therefore particularly interesting if existing smart contracts from the Ethereum world are to be used in a private or permissioned blockchain. The Solidity programming language is also used in the development of smart contracts at Burrow. The reality of Proof of Stake as an experimental consensus mechanism should also be included in a decision.
Iroha – The nebulous light variant
Iroha is also an active project that is currently working on version 1.0. The initial work on the project came from the Japanese companies Hitachi, Soramitsu, Colu and NTT Data. The principles of Iroha are very similar to Fabric, but based on a different codebase. Iroha is developed in C++, using a modern codebase and clean design. The project therefore sees its unique selling points in a high performance and simplicity of the architecture. It is aimed at applications in which fast synchronous transactions with small payloads are required. For this purpose, decentralized backends of mobile applications are considered a valid use case.
Business logic is also achieved as chain code in Iroha, usually written in Java. The resulting artefact is executed in a sandboxed JVM on each node. Aspects such as currencies and communication with mobile devices are, however, already features of Iroha. This means that you do not have to implement separate chain code for each application.
According to Brian Behlendorf, Iroha has not yet found its true niche. In addition, it is difficult to estimate for which applications the use of Iroha could make the most sense. Anyone who is considering using it should experiment extensively with it beforehand.
Indy – Decentralized identity management
Hyperledger Indy is also still in incubator status and represents another implementation of a private blockchain node. The project’s mission is to manage unique identities for global use. The identities are managed in a separate distributed ledger and are also to be made usable outside the private blockchain network via interfaces. The Sovrin Foundation’s identity tool “Sovrin” uses Indy and contributes significantly to development in this way.
The heart of Indy has another name: Plenum. It implements features similar to those in Fabric (organizations, participants and related identities), but specifically for the use case of identity management, which is different from Fabric’s general approach. This document provides a helpful overview of Plenum and its integration with Indy. Plenum implements the Redundant Byzantine Fault Tolerance (RBFT) protocol.
Indy is interesting for permissioned blockchain consortia who want to manage unique identities between each other in a trustworthy way. These can optionally be consumed by other groups or even publicly. The project is technically of a high quality and fully concentrates on the needs of this one use case. Therefore, use for decentralized identity management is recommended. Indy’s tools can also be combined with other platform solutions, so that an individual identity blockchain network is not required at all cost for its usage.
Hyperledger Tools: Composer, Explorer und Cello
The tools from the Hyperledger project are each aimed at one of the presented platforms. They can generally not be used with each other or across several solutions.
Composer: This is the most actively developed and powerful tool. One could call it a framework for Hyperledger Fabric. The use of Composer brings along simpler concepts for Fabric, called Business Network Definitions. These are sourcecode packages that define a business network. This includes permissions, queries, participants, assets, and transaction definitions, as well as the implementation of the different transaction types. A packaged BND is to be deployed to all nodes of a Fabric network. Thus, we see a Fabric network under use with Composer only as a platform and infrastructure. We don’t have to use most of Fabric’s low-level concepts any more. The use of Composer definitely makes sense if Fabric is already in use.
Explorer: The name of this tool is already very meaningful. The Explorer can also be used in conjunction with Fabric. It is to be configured for one or multiple channels in a Fabric network. From then on, a web interface can be used to make the state and history visible in the distributed ledger. The tool is therefore suitable for different needs under the use of Fabric, e. g. if parties are supposed get a simple view of data in the blockchain or as a tool for administrators and auditors.
Cello: This name can also be easily understood after short explanation. Cello is a tool to efficiently provision and manage blockchain networks. It can also handle homogeneous infrastructure: bare metal, virtual clouds, and container orchestration clusters such as Kubernetes and Docker Swarm. It can manage multiple blockchain networks, not just one. The status of the systems is also displayed via a dashboard. This means that resources can also be scaled and managed. So far only Fabric 1.0 networks are supported in Cello. As a short summary, Cello is meant to bring DevOps approaches and practices to the Hyperledger platform projects.
The Hyperledger project pursues several approaches for the implementation of private and permissioned blockchain applications. The largest and most active subprojects are the platforms presented. Fabric seems to be considered the most mature and active of them.
They provide binaries and Docker images to place the partially different node roles in the network. These nodes can be configured to meet and work together. It is also possible to develop business logic and install it on the node of the network. Each platform provides clients for different programming languages and frameworks, so that any application (web and app frontends as well as backend systems) can communicate with the resulting blockchain network.
In addition to the platforms, there is a layer of tools whose quantity is still very clear. These tools simplify the use of the platforms or add new functionalities. The number of tools is likely to increase significantly in the future as there is still a number of questions to be answered regarding the automation, migration and deployment of individual platforms.
For the beginning, however, this was an overview of Hyperledger, which should help to roughly understand the individual projects. Since the platforms provide different approaches for different scenarios, the overview can help you make a decision for the right platform.
However, the most extensive and flexible project, designed with the widest range of use cases in mind, is Fabric. The biggest tool from the project, Composer, can be seen as a framework for Fabric. It facilitates the development and modeling of business networks. Cello and Explorer can also be used with Fabric. This shows that Fabric is working hard on good tooling. Fabric is currently the best choice for most applications.
Our article series “blockcentric” discusses blockchain-related technology, projects, organization and business concerns. It contains knowledge and findings from our 20% time work, but also news from the area.