“Don’t pretend you know the answers. Experiment; get feedback.”
—Stephen J. Dubner, co-author of Think Like a Freak

In late 2016, our team began following an open source blockchain development project known as the “Hyperledger Project,” which was started by the Linux Foundation earlier that year. We learned Hyperledger encourages cross-industry collaboration on blockchain and distributed ledger platforms.¹ The project, according to its website, “welcomed two business blockchain framework codebases into incubation.” One of these, named Hyperledger Fabric, would become the platform for the next phases of our project.

The Tech Stack: Hyperledger Fabric v0.6

Hyperledger Fabric, the open source project spearheaded by IBM along with 27 other organizations, sought to create a modular, enterprise-level architecture, where components can be easily swapped out without affecting other parts of the system.² Importantly, Fabric also includes a membership service that requires prospective participants to prove their identity and be granted access before inclusion into the network. These and other features offered an improved value proposition over the available Ethereum options based on the Boston Fed use case.

However, at this point in Hyperledger’s development cycle, the Fabric project was still considered in the “incubation” phase. A project under the Hyperledger umbrella does not graduate to “active” until certain criteria, including documentation requirements, defect tracking, and infrastructure support, are in place.³ We would be among the first to use code intended as a “preview” for developers. Nevertheless, we were eager to begin.

In the winter of 2016 – 2017, the team installed the necessary components on AWS to build a Hyperledger Fabric blockchain.

These components included:

• Docker and Docker Compose (a computer program that enables “containerization”)⁴
• Chaincode/ smart contract (a small program that runs on the blockchain platform)
• Golang (programming language used for smart contract/chaincode)
• Hyperledger Fabric REST API

The project goals, use case and requirements, user interface built using Spring MVC and Angular 1, and Ubuntu remained the same during this trial.

Hyperledger Fabric v0.6 Results

Through native membership services, Hyperledger Fabric version 0.6 (v0.6) solved one of the core challenges the team encountered during the Ethereum trial, but it was more difficult to deploy. Specifically, though documentation was available, there simply wasn’t any support beyond basic implementation—in other words, when any customization was needed. (This wasn’t wholly unexpected, given the code was still in the preview stage.) But with hours of watching instructional YouTube videos and some false starts, our team was able to build the necessary knowledge and create a simple, functioning architecture. The difficulty with setup, however, was worth the effort because the more robust permissioned capabilities showed promise.

Interestingly, before we had done much testing on v0.6, Fabric version 1.0 (v1.0) was launched in spring 2017. This version implemented many solutions to the challenges the team had encountered with v0.6, such as adding the ability to create privacy among participants.

The team migrated from v0.6 to v1.0 in the second quarter of 2017.

The Tech Stack: Hyperledger Fabric v1.0

Though it retained some of the basic building blocks of v0.6, such as Docker, Golang, and chaincode, our team needed to make several updates. First was the removal of the REST API in v1.0, which required the team to pick a Software Development Kit (SDK) to utilize. The Java SDK was not yet as mature as the Node SDK, so we installed the Node Server and Node SDK and also modified the web applications service layer to communicate with the Node SDK, rather than directly with the Fabric network.

In addition, the Hyperledger Fabric development team re-architected the consensus model in v1.0. The Bitcoin blockchain uses a proof of work consensus method to determine which node in the network “wins” the right to add a valid block to a chain. Because the system is intended to enable nodes that do not know or trust each other to participate in the network together, a mechanism to reach agreement and affirm the validity of the chain as the canonical record is essential. The protocol for consensus must provide participants with reasonable assurance that the block is valid.

In a private, permissioned blockchain environment, access to the network is controlled through the membership service and established through some kind of authority, agreement, or business rule. Thus, though consensus is necessary to ensure all of the nodes within the network agree on the state of the canonical ledger, the method to arrive at agreement does not need:

• an incentive structure to reward “miners” for validation and the addition of a block to the chain
• multiple nodes in competition to “win” the right to add a block

This means different options are available to keep the network synced and compliant with specified protocols.

Hyperledger Fabric v1.0 defines consensus as “a broader term overarching the entire transactional flow, which serves to generate an agreement on the order and confirm the correctness of the set of transactions constituting a block.”⁵ Because neither incentive nor competition is needed to achieve consensus, the design of Fabric allows users to define the conditions under which a transaction can occur. These conditions are created as part of the smart contract using “chaincode.” The chaincode is the program establishing the basic environment and business rules transactions must follow. It is the smart contract. These business rules are then used to “confirm correctness.”

Several components in Fabric v1.0 work together.⁶ A “peer” is a node in the network which can have various roles. Peers can also be removed, or their roles can be changed according to need. A peer node houses both a ledger and the chaincode logic. It also commits a block to the chain. A peer may also endorse a transaction based on the business rules or “policy” established as part of the smart contract.

In addition, the ordering service—or “orderer” in Fabric—batches and broadcasts transactions to peers and contains the core “system chain” with information about who belongs to the network and what rules they will all follow. There can be a number of orderers, but in our case, we needed only a single orderer (“Solo”) responsible for receiving transactions and broadcasting them to the appropriate peer in the network to perform the commitment functions, which then adds a block to the chain.

Further, the endorsing peer receives the transaction as a proposal and affirms whether a particular transaction is valid according to the required logic. Once endorsed, the result is sent back for validation to the client application—the originator of the transaction. The client application then sends the endorsed transaction to the ordering service, which batches it and sends it to the committing peer. The committing peer appends the endorsed transaction to the appropriate ledger, which—as we will discuss shortly—may not be viewable for all participants in the network.

While major changes were made from v0.6 to v1.0, the two of greatest interest for our use case were the improvement in the methodology around correctness and agreement and the creation of “channels” for transaction privacy. With the ordering service and separation of responsibilities among peers, greater efficiency, flexibility, and resilience are possible. We thought the channel architecture would address the challenge of protecting confidential data, which was impossible in v0.6 and the native Ethereum environment.

Effectively, Hyperledger Fabric v1.0 enables each participant in the network to transact with any other participant in the network without exposing confidential information to others who are not parties to that particular transaction. So, when a peer node commits a transaction, it is only committing that transaction to the ledgers of the participants privy to that particular event.

Therefore, we set up channels for representative “banks” simulating (on a much reduced scale) client accounts our general ledger reconciliation case would support.

Hyperledger Fabric v1.0 Results

In our implementation, we elected to keep the structure simple. The project goals did not include specifically testing the throughput of the network, latency, or resilience. Because we were seeking to understand the technology, we hoped to better define additional testing or proof of concept efforts while we monitored the technology as it matured. To that end, this trial delivered exceptional results.

Based on our experiments overall, setting up a basic environment was relatively straightforward. We performed each of the functions we outlined in our proof of concept goals, so Hyperledger Fabric clearly shows promise as one of multiple platforms for further experimentation.⁷

The results also prompted us to initiate a relationship with the Linux Foundation and join Hyperledger working groups. Not only did our project help us ask better questions about how this technology can be used, it fostered a commitment to extend our learning into the community.

Along with the benefits, we found some clear challenges. For instance, building a proof of concept architecture in a rapidly evolving open source development environment carries inherent complications. When one must install new or updated versions of tools repeatedly, the risk of having to repeat the learning process or materially revise code is high. Additionally, the volunteer-based, open source community was not always available and the advice was not always high quality. We experienced this with Ethereum, and the same was true for Hyperledger Fabric, both before and after the launch of v1.0.

Another important insight about the channel architecture introduced by Hyperledger Fabric v1.0 was that while the channels do appear to enable privacy among participants, the channel setup was complicated and they did not scale well.

In sum, though Hyperledger Fabric is the most mature of the Hyperledger projects, it may not be ready for primetime when mission-critical systems are involved.

The views expressed in this report are those of the authors and do not necessarily represent positions of the Federal Reserve Bank of Boston or the Federal Reserve System.