Blockchain for Business: An Introduction to Hyperledger Fabric

Hyperledger was started in December 2015, and Fabric was the first project that outgrew the incubator phase, launching v1.0 in July 2017. Its semi-centralized approach snubbed blockchain purists but elated corporate clients agonizing over Ethereum’s scalability issues. Besides the possibility of growing large networks around Fabric’s distributed ledger, Hyperledger’s first born offered significant privacy features for supply chains and other corporate use cases. However, the perk that is usually thrown around when talking about Fabric is its flexibility. A number of features can be toggled at the discretion of the network’s creator, including fundamental characteristics such as the ledger’s consensus algorithm.

Unfortunately, Fabric’s modularity leads to considerable complexity: As opposed to Ethereum that runs a single transparent main network, Fabric was conceived as an adaptive solution for individual private networks with varying requirements. For better understanding, we will illustrate the features and functionalities of Hyperledger Fabric with a use case example.

The Avocado Supply Chain with Fabric

Let’s imagine a supply chain with the following actors:

· Alice, the owner of an organic grocery in Copenhagen

· Bob, who grows Avocados in South Africa

· Acme Insurance providing the cargo insurance

· Acme Shipping that ships the Avocados

· Charles, Alice’s competitor, who also buys from Bob

The logistics sector was one of the first industries that became enchanted with distributed ledger technology. The promise of digitizing the shipping back office rendered blockchain extremely attractive to a wide range of companies: from small start-up ventures to global players like DHL, FedEx, and Maersk.

However, the original vision of blockchain as a decentralized, fully transparent transaction ledger presented businesses with two major problems: a lack of efficiency and insufficient privacy.

Hyperledger Fabric attempts to solve these deal-breaking issues with a set of the following features:

Private Networks

If the actors of our Avocado supply chain interact on a public blockchain they must share the blockchain’s capacity with all network participants. A private network created using Fabric handles only the transactions of the Avocado supply chain. Even large supply chains with numerous participants can be serviced fast and efficiently.

Identification of Participants

Alice, Bob, Charles, and the other actors in our Avocado supply chain have chosen to initiate the Avocado network, a private blockchain network using Hyperledger Fabric. When the members of the Avocado supply chain decided to move their transactions to Fabric, they jointly decided on a set of basic aspects for the Avocado network. In this process, they defined ownership, permissions, and administration rights for every component of the Avocado network in a set of policies. Using digital certificates, Fabric’s Membership Service Providers ensure that every participant of the network is, who he says he is, and does only what he’s allowed to do.

Such as in paper-based supply chains, providing false data can result in loss of trust and legal consequences. As this will not only affect an anonymous account but their businesses or organizations themselves, all parties have an interest in the validity of the network’s data.

Node Types

As noted above, the members of the Avocado supply chain clearly defined who owns and administers the various network components. For example, Alice provides two peer nodes, Acme Shipping four, and Bob one. The ordering nodes are usually run by an actor of the network that does not invoke applications. Let’s say that Acme Insurance is participating in the Avocado network only as an observer to assure the orderliness of the insured supply chain. In this case, Acme Insurance would be a potential provider of the ordering nodes that maintain consensus.

After having created the basic layout of the Avocado network, Alice, Bob, and Charles can finally start trading. In the next part of this introduction, we will look at Fabric’s transaction flow as Alice orders Avocados from Bob.

Buying Avocados with Fabric

Alice, our grocer from Copenhagen, has run out of Avocados and wants to order a new batch from Bob’s plantation in South Africa. To understand the complexity of how Alice’s order is processed on Fabric, it helps to visualize all cell phone infrastructure and service providers that would be involved if Alice were to call Bob with her order instead. Also in Fabric, a simple order of another crate of avocados kicks off a whole series of events behind the scenes. Fabric’s transaction system relies on an intricate framework of checks and balances, making sure that all necessary parties agree at every step of the way of Alice’s order.

Alice’s Application

As Alice orders Avocados from Bob, she is proposing a transaction to the network. In order to interact with the Avocado network, she uses an app on her tablet to place the order. Fabric calls these kinds of applications, that act as an interface between users such as Alice and the Fabric network, “client applications”. Like distributed apps on public blockchains, the backend of Alice’s application is stored on the network. If Alice orders a new batch of Avocados, she enters the required information such as the shipping address or the amount into her client application. However, the application merely forwards her input to a smart contract — let’s call it Alice’s Ordering Contract — that executes her information and processes her order on the Avocado network.

From the Application to the Peers

Above we have introduced the concept of peers: other devices on the network that execute and verify transactions. Alice’s application sends Alice’s transaction proposal to the peer nodes of the network. Which peers she sends her transaction proposal to, depends on the policy of the smart contract that executes the transaction. Let’s follow the course of Alice’s transaction to one of the peers specified in the policy of Alice’s Ordering Contract: a server at Acme Shipping.

The server at Acme Shipping receives the transaction proposal. The proposal invokes an instance of Alice’s Ordering Contract (aka “Chaincode” in Fabric) that is stored on the server. Based on a current copy of the Avocado network’s transaction ledger — every peer node keeps a copy of that ledger — Acme Shipping’s server executes Alice’s Ordering Contract. The result is then sent back to the application Alice used to propose her transaction.

From the Peers back to the Application

However, Alice’s application receives not only the cryptographically signed response (aka “endorsed response” in Fabric) of Acme Shipping’s peer node, but the responses of all peers that are required to agree upon the result of Alice’s transaction proposal. Since all peers each have an identical copy of Alice’s Ordering Contract, the returned results should be similarly identical. In the rare case that the returned results are inconsistent, Alice’s application can ask deviating peers to execute Alice’s transaction again, since the problem might be caused by the peer executing Alice’s transaction based on an outdated copy of the Avocado network’s ledger. If the updated results remain inconsistent, the application can decide to discard all results and abort Alice’s transaction proposal.

From the Application to the Orderers

However, let’s assume that the results of Alice’s transaction proposal that were returned by the peers are consistent. The application then sends the collected responses to the second main actor in a Fabric network: the orderers.

In the Avocado network, the orderers provided by Acme Insurance have an easy job, since there are few network participants and the number of transactions is relatively low. If there were not only Alice, Bob, and Charles but other farmers, grocers, and authorities to tend to, the orderers would receive not only the collected returns from Alice’s transaction proposal, but those from numerous other participants of the network.

The orderers (aka “ordering service”) define an order for the incoming transactions and pack the ordered transactions of a pre-defined timeframe into a finalized, immutable block that is appended to the chain of immutable blocks that make up the network’s distributed ledger. The orderers send the finalized block to the peers of the network, such as the server at Acme Shipping.

From the Orderers to the Peers

We’re back with the peer node at Acme Shipping: Upon receiving the block of transactions from the orderers, the peer validates the block by checking whether all transactions were cryptographically signed (“endorsed”) by all required peers. This is to make sure that malicious or malfunctioning applications cannot add any data to the ledger that has not been approved by the necessary peers. After having validated the block of transaction from the orderers, Acme Shipping’s peer node appends the block to its copy of the network’s ledger. Finally, the peer notifies Alice’s application that her transaction proposal was approved.

So poor Alice simply wanted to buy Avocados and now she has to deal with all of this? Well, the troubles of understanding and setting up the Avocado network do eventually yield considerable advantages for her back office. Because within the integrative network of the Avocado supply chain Alice’s application can handle a whole range of tasks that used to be spread out across several accounts and communication channels. Ordering, payment, shipping, tracking and tracing, customs, and insurance processes can be more easily implemented, since the shared information on avocados and money changing hands and locations is continuously validated and kept in a standardized format.

Fabric preserves the reliability of blockchain technology and implements its concept within private networks with known participants. Fabric cuts down the redundancy of public blockchain consensus mechanisms while maintaining a largely decentralized system for validating information: The application validates peers, the orderers validate applications, the peers validate the orderers, and so forth.

Fabric further adds several features that complement the underlying distributed ledger technology. Channels, Gossip, and Private Data Collections are modular components that can contribute to data privacy and transaction speed of the network.

Channels

What if Alice wants to do business with Bob, but prefers Charles not to know the details of their agreement? Using Fabric, she can establish a channel with Bob and exchange transactions containing sensitive information. Her channel with Bob is governed by the policies only she and Bob decide upon and that are independent of the general network policies. If a smart contract contains sensitive information that Alice wants to keep from Charles, she can create a separate peer node that only interacts on her channel with Bob. That peer node and its local instances of the private smart contract cannot be accessed or read by Charles, since he is not on Alice’s channel with Bob.

Likewise, Bob maintains a channel with Charles. Bob runs only a single peer node on the network, and it interacts on both the channel with Alice as well as the one with Charles. With Fabric, peer nodes like Bob’s can keep several copies of different ledgers. Each ledger is valid for a certain channel and updated only according to the transactions of that channel.

Gossip

The Avocado network with its five participating parties is tiny in terms of Fabric’s capabilities. If it was not only Alice, Bob, and Charles on the network, but all of the world’s Avocado farmers and grocers, the network would be put under considerable strain. Particularly the orderers of the Avocado network would struggle under the enormous amount of peer nodes they would have to service when passing out new blocks.

With Fabric, the owners of the Avocado network can choose to implement a so-called “gossip protocol”. The gossip protocol constitutes a communication channel for the nodes of the network and can be used in many ways. In our case, it can take some of the workload of the orderers by letting trusted peers forward new blocks to other peers. As a result, orderers don’t have to send every new block to all the peer nodes, but only to designated peers, which in turn pass on the block to its connected peers.

Private Data Collections

Channels help to keep transactions between members of a Fabric network private. However, what if only part of the transaction data is private, but the transaction itself is something the whole network should be aware of? Bob might want to keep the price he agreed upon with Charles private, but at the same time he wants the amount of Avocados Charles has bought to be visible for Alice, so she’s incited to buy before Charles finishes Bob’s stocks.

With the release of v1.2 in July, 2018, Private Data Collections have been introduced to Fabric. When Charles orders Avocados from Bob using Private Data Collections, his transaction is sent only to the peers on the Avocado network that may know about the details of their trade. The peers send the sensitive data back to Bob and Charles using the gossip protocol. The peers further encrypt — using hashes — the sensitive data, before they send it as part of their endorsed responses back to the application. From there, the endorsed responses with the encrypted sensitive data follow the same path as in a conventional transaction. In this way, the details of Bob and Charles’ deal are documented and validated as part of the Avocado ledger, but only the parties involved can decrypt the actual information on the ledger.

Conclusion

Already now, Hyperledger Fabric is one of the most popular frameworks for private distributed ledger solutions. The project’s reliable development with its regular extensive updates intrigues more and more developers, founders, and investors. We at SICOS can support you in matching your use case with the right blockchain technology, whether it’s Ethereum, EOS, or Hyperledger Fabric. And if you’re already set on a platform, SICOS can help you establish the necessary infrastructure for a successful development, from financing, to legal advice, to project management. Contact us at hello@sicos.io!