How Hyperledger Fabric Works

by Content Team

13 January 2024

Blockchain

Complete Review of Hyperledger Fabric Architecture and Components

Outline

Background
Hyperledger Fabric Overview
Hyperledger Fabric Model
Blockchain Network
Identity
Membership Service Provider (MSP)
Policies
Peers
Smart Contracts and Chaincode
Ledger
The Ordering Service
Private Data
Summary
Resources

I. Background

In our previous article, we surveyed four generations of blockchain technology, followed by Hyperledger architecture and its components. We also introduced you to the Hyperledger ecosystem by reviewing its projects, tools, and libraries. In this article, we will look deeper into the Hyperledger family by only focusing on the Hyperledger Fabric project and its components. Along the way, we will introduce you to all Hyperledger Fabric components including peer, channel, and essential chaincodes for both building blockchain applications.

This article will help you to achieve the following practical goals:

Understand the major highlights of Hyperledger Fabric versus other blockchain development platforms
Discuss the role of Membership Service Providers, Certificate Authority and identifies in a Fabric permissioned network
Review the role of the ledger in a Hyperledger Fabric
Survey the main components of the Fabric network
Understand the roles that a peer plays in a Fabric network
Discuss mechanism through which transactions are processed by peers
Understand the role of private data and data collection in a Fabric permissioned network

II. Hyperledger Fabric Overview

Hyperledger Fabric comes with several unique features (as listed below) to make it stand out from the other distributed ledger technologies.

Permissioned architecture
Highly modular
Pluggable consensus
Open smart contract model — flexibility to implement any desired solution model (account model, unspent transaction output model, structured data, unstructured data, etc)
Low latency of finality/confirmation
Flexible approach to data privacy: data isolation using ‘channels’, or share private data on a need-to-know basis using private data ‘collections’
Multi-language smart contract support: Go, Java, JavaScript
Support for Ethereum Virtual Machine and Solidity
Designed for continuous operations, including rolling upgrades and asymmetric version sup-port
Governance and versioning of smart contracts
Flexible endorsement model for achieving consensus across required organizations
Queryable data (key-based queries and JSON queries)

In addition to the above features, the Hyperledger Fabric is supported by a growing community. As discussed in the previous article, there are many projects, libraries, and tools under the Hyperledger family, many of which are at the incubation stage while being maintained by its active community. The dedication of the Hyperledger community to Hyperledger’s constant improvement in the security, usability, robustness, performance, and feature set is another prominent factor for its success and adoption. Lastly, to the best of our knowledge, there are no other distributed ledger technology frameworks besides Hyperledger that enjoy the breadth of adoption by Cloud Service Providers such as AWS, Azure, IBM, Google, and Oracle.
We will discuss each of these features in more depth throughout this article. In the next section, we go over notable features of Hyperledger Fabric such as assets, privacy, and consensus, after which for the remainder of this article we discuss the important elements of the blockchain network such as smart contracts, orderers, policies, and identities.

III. Hyperledger Fabric Model

This section outlines the key design features embedded into Hyperledger Fabric that enable it to act as a comprehensive, yet customizable, enterprise blockchain solution:

Assets — Asset definitions enable the exchange of almost anything with monetary value over the network, from foods to antique cars to currency futures.
Chaincode — Chaincode execution is partitioned from transaction ordering, limiting the required levels of trust and verification across node types, and optimizing network scalability and performance.
Ledger Features — The immutable, shared ledger encodes the entire transaction history for each channel, and includes Standard Query Language-like query capability for efficient auditing and dispute resolution. A Hyperledger Fabric channel is a private “subnet” of communication between two or more specific network members, for the purpose of conducting private and confidential transactions.
Privacy — Channels and private data collections enable private and confidential multilateral transactions that are usually required by competing businesses and regulated industries that exchange assets on a common network.
Security & Membership Services — Permissioned membership provides a trusted blockchain network, where participants know that all transactions can be detected and traced by authorized regulators and auditors.
Consensus — A unique approach to consensus enables the flexibility and scalability needed for the enterprise.

Assets

Assets can range from the tangible (real estate and hardware) to the intangible (contracts and intellectual property). Hyperledger Fabric provides the ability to define and modify assets using chaincode transactions. Assets are represented in Hyperledger Fabric as a collection of key-value pairs, with state changes recorded as transactions on a channel ledger. Assets can be represented in binary and/or JSON format.

Chaincode

Chaincode (also known as a smart contract) is software defining an asset or assets, and the transaction instructions for modifying the asset(s); that means, chaincode is the business logic behind a blockchain application. It automates and regulates the transactions or interactions among the players in a blockchain network. Chaincode enforces the rules for reading or altering key-value pairs or other state database information.

Ledger Features

The ledger is the sequenced, tamper-resistant, immutable record of all state transitions in the Fabric. State transitions are a result of chaincode invocations (‘transactions’) submitted by participating parties. Each transaction results in a set of asset key-value pairs that are committed to the ledger in the form of create, update, or delete instances.
The ledger consists of a blockchain to store the immutable, sequenced record in blocks along with a state database to maintain the current Fabric state. There is one ledger per Hyperledger Fabric channel.
Here are some of the features of a Fabric ledger:

Query and update ledger using key-based lookups, range queries, and composite key queries
Read-only queries using a rich query language (if using CouchDB as state database)
Read-only history queries — Query ledger history for a key, enabling data provenance scenarios
Transactions consist of the versions of keys/values that were read in chaincode (read set) and keys/values that were written in chaincode (write set)
Transactions contain signatures of every endorsing peer and are submitted to an ordering service
Transactions are ordered into blocks and are “delivered” from an ordering service to peers on a channel
Peers validate transactions against endorsement policies and enforce the policies
Prior to appending a block, a versioning check is performed to ensure that states for assets that were read have not changed since chaincode execution time
There is immutability once a transaction is validated and committed
A channel’s ledger contains a configuration block defining policies, access control lists, and other pertinent information
Channels contain Membership Service Provider instances allowing for crypto materials to be derived from different certificate authorities

Privacy

Hyperledger Fabric employs an immutable ledger on a per-channel basis along with chaincode that can manipulate and modify the current state of assets (i.e. update key-value pairs). A ledger exists in the scope of a channel — it can be shared across the entire network (assuming every participant is operating on one common channel) — or it can be privatized to include only a specific set of participants.
In the latter scenario, these participants would create a separate channel and thereby isolate/segregate their transactions and ledger. To bridge the gap between total transparency and privacy, chaincode can be installed only on peers that need to access the asset states to perform reads and writes (in other words, if a chaincode is not installed on a peer, it will not be able to properly interface with the ledger).
When a subset of organizations on that channel needs to keep their transaction data confidential, a private data collection (collection) is used to segregate this data in a private database, logically separate from the channel ledger, accessible only to the authorized subset of organizations.
Thus, channels keep transactions private from the broader network whereas collections keep data private between subsets of organizations on the channel. We discuss more on data collections later on.

Security & Membership Services

Hyperledger Fabric comes with a transactional network where all participants have known identities. Public Key Infrastructure is used to generate cryptographic certificates which are tied to organizations, network components, and end users or client applications. As a result, data access control can be manipulated and governed on the broader network and on channel levels. This “permissioned” notion of Hyperledger Fabric, coupled with the existence and capabilities of channels, helps address scenarios where privacy and confidentiality are of utmost concern. We cover identities and Membership Service Providers in more detail later on.

Consensus

Whether transactions take place among participants within a network or from participants outside of the network like customers or clients of network members, all transactions should be registered in the ledger in the order in which they occur. A blockchain uses a mechanism called consensus to process, approve, or reject its transaction. Since consensus plays a vital role on the health of a blockchain network, it has been a subject of thorough research in the blockchain and computer science community. We surveyed the most common consensus methods that are currently in use in article 1 while mentioned that each blockchain platform uses its own consensus method based on its architectural design. For instance, Hyperledger uses the PBFT (Practical Byzantine Fault Tolerance) consensus method which provides a mechanism for file replicas to communicate with each other to keep each copy consistent, even in the event of corruption.
Hyperledger Fabric has been designed to allow network designers to choose a consensus mechanism that best represents the relationships that exist among their network participants. Similar to privacy, there is a spectrum of requirements; from networks that are highly structured in their relationships to those that are more peer-to-peer.

IV. Blockchain Network

Hyperledger Fabric allows organizations to collaborate in the formation of blockchain networks. For the remainder of this article, we review the main components of Hyperledger Fabric network like peer. Hyperledger Fabric architects, administrators or developers need to have an understanding of the major structure and process components in a Hyperledger Fabric blockchain network. For instance, to design a Fabric network, they should know what decisions that organizations need to make in order to establish the policies that control a deployed Hyperledger Fabric network. So let’s begin by discussing what a blockchain network?
A blockchain network is a technical infrastructure that provides ledger and smart contract (chaincode) services to applications. Primarily, smart contracts are used to generate transactions that are subsequently distributed to every peer node in the network where they are immutably recorded on their copy of the ledger. The users of applications might be end users using client applications or blockchain network administrators.
In most cases, multiple organizations come together as a consortium to form the network and their permissions are determined by a set of policies that are agreed by the consortium when the network is originally configured. Moreover, network policies can change over time subject to the agreement of the organizations in the consortium, as we will discuss later in this article.
Now that we know what a blockchain network is and what role it plays in a Hyperledger Fabric, we need to understand how privacy is woven into Fabric architecture. There are three types of blockchain networks: private (or premissioned), public (permissionless), and hybrid networks. Fabric uses the private or premissioned network.

Permissioned Network

Unlike other public blockchain platforms like Ethereum, Hyperledger holds privacy in high regard which has been embedded into its architectural design since its inception. The enterprise architecture of Hyperledger allows privacy in data sharing and network membership which is essential for conducting business operations. Specifically, when designing a Hyperledger network, the administrator should determine the members of its network whom they can access and interact with the network and its data. As such, the incorporation of privacy in Hyperledger blockchain network plays an important role in conducting business among the members of the network. Indeed, in place of an open permissionless system that allows unknown identities to participate in the network, the members of a Hyperledger Fabric network enroll through a trusted Membership Service Provider (MSP) this type of identities may be modified later depending on the new roles of the network. We will discuss it more later on in this article.
As a reminder, topics related to Hyperledger Fabric network such as how to design, run and manage a Fabric network (with single or multiple members like a consortium) as well as how to add and manage organizations or members within a Fabric channel are not covered in this article as they are typically related to Fabric system administration. So for learning more about network, visit the Hyperledger website at hyperledger.org

V. Identity

There are different actors in a blockchain network including peers, orderers, client applications, administrators, and more. Each of these actors has a digital identity encapsulated in an X.509 digital certificate. These identities really matter because they determine the exact permissions over resources and access to information that actors have in a blockchain network.
A digital identity furthermore has some additional attributes that Fabric uses to determine permissions, and it gives the union of an identity and the associated attributes a special name known as the principal. Principals are just like userIDs or groupIDs, but a little more flexible because they can include a wide range of properties of an actor’s identity, such as the actor’s organization, organizational unit, role or even the actor’s specific identity. When we talk about principals, they are the properties that determine their permissions.
For an identity to be verifiable, it must come from a trusted authority. A Membership Service Provider (MSP) is that trusted authority in Fabric. More specifically, an MSP is a component that defines the rules that govern the valid identities for an organization. The default MSP implementation in Fabric uses X.509 certificates as identities, adopting a traditional Public Key Infrastructure (PKI) hierarchical model. PKI can provide verifiable identities through a chain of trust.

VI. Membership Service Provider (MSP)

Because Fabric is a permissioned network, blockchain participants need a way to prove their identity to the rest of the network in order to transact on the network. Such identity verification involves Certificate Authority (CA) and MSP. Whereas Certificate Authorities generate the certificates that represent identities, the MSP contains a list of permissioned identities.

CA issues identities by generating a public and private key which forms a key-pair that can be used to prove identity. Because a private key can never be shared publicly, a mechanism is required to enable that proof which is where the MSP comes in. For example, a peer uses its private key to digitally sign, or endorse, a transaction. The MSP on the ordering service contains the peer’s public key which is then used to verify that the signature attached to the transaction is valid. The private key is used to produce a signature on a transaction that only the corresponding public key, which is part of an MSP, can match. Thus, the MSP is the mechanism that allows that identity to be trusted and recognized by the rest of the network without ever revealing the member’s private key.
Despite its name, the MSP does not actually provide anything. Rather, the implementation of the MSP requirement is a set of folders that are added to the configuration of the network and is used to define an organization both inwardly (organizations decide who its admins are) and outwardly (by allowing other organizations to validate that entities have the authority to do what they are attempting to do).
The MSP identifies which Root CAs and Intermediate CAs are accepted to define the members of a trusted domain by listing the identities of their members, or by identifying which CAs are authorized to issue valid identities for their members.
But the power of an MSP goes beyond simply listing who is a network participant or member of a channel. It is the MSP that turns an identity into a role by identifying specific privileges an actor has on a node or channel. Note that when a user is registered with a Fabric CA, a role of admin, peer, client, orderer, or member must be associated with the user. For example, identities registered with the “peer” role should, naturally, be given to a peer. Similarly, identities registered with the “admin” role should be given to organization admins.
MSPs occur in two domains in a blockchain network:

Locally on an actor’s node (local MSP)
In channel configuration (channel MSP)

The key difference between local and channel MSPs is not how they function – both turn identities into roles – but their scope. Each MSP lists roles and permissions at a particular level of administration.

VII. Policies

At its most basic level, a policy is a set of rules that define the structure for how decisions that are made and specific outcomes are reached. To that end, policies typically describe a who and a what, such as the access or rights that an individual has over an asset. We can see that policies are used throughout our daily lives to protect assets of value to us, from car rentals, health, our homes, and many more.
For example, an insurance policy defines the conditions, terms, limits, and expiration under which an insurance payout will be made. The policy is agreed to by the policyholder and the insurance company and defines the rights and responsibilities of each party.
Whereas an insurance policy is put in place for risk management, in Hyperledger Fabric, policies are the mechanism for infrastructure management. Fabric policies represent how members come to an agreement on accepting or rejecting changes to the network, a channel, or a smart contract. Policies are agreed to by the consortium members when a network is originally configured, but they can also be modified as the network evolves. For example, they describe the criteria for adding or removing members from a channel, change how blocks are formed, or specify the number of organizations required to endorse a smart contract or a transaction. All of these actions are described by a policy that defines who can perform the action. In a plain text, everything you want to do on a Fabric network is controlled by a policy.

VIII. Peers

A blockchain network consists primarily of a set of peer nodes (or, simply, peers). Peers are a fundamental element of the network because they host ledgers and smart contracts. As discussed, a ledger immutably records all the transactions generated by smart contracts (which in Hyperledger Fabric are contained in a chaincode). Smart contracts and ledgers are used to encapsulate the shared processes and shared information in a network, respectively. These aspects of a peer make them a good starting point to understand a Fabric network.
In Hyperledger Fabric, while all peers are the same, they can assume multiple roles depending on how the network is configured. Here are 4 roles that a peer can undertake:

Committing peer. Every peer node in a channel is a committing peer. It receives blocks of generated transactions, which are subsequently validated before they are committed to the peer node’s copy of the ledger as an append operation.
Endorsing peer. Every peer with a smart contract can be an endorsing peer if it has a smart contract installed. However, to actually be an endorsing peer, the smart contract on the peer must be used by a client application to generate a digitally signed transaction response. An endorsement policy for a smart contract identifies the organizations whose peer should digitally sign a generated transaction before it can be accepted onto a committing peer’s copy of the ledger.
Leader peer. When an organization has multiple peers in a channel, a leader peer is a node that takes responsibility for distributing transactions from the orderer to the other committing peers in the organization. A peer can choose to participate in static or dynamic leadership selection.
Anchor peer. If a peer needs to communicate with a peer in another organization, then it can use one of the anchor peers defined in the channel configuration for that organization. An organization can have zero or more anchor peers defined for it, and an anchor peer can help with many different cross-organization communication scenarios.

Note that a peer can be a committing peer, endorsing peer, leader peer and anchor peer all at the same time. Only the anchor peer is optional, so for all practical purposes there will always be a leader peer and at least one endorsing peer and at least one committing peer.
Peers can be created, started, stopped, reconfigured, and even deleted. They expose a set of APIs that enable administrators and applications to interact with the services that they provide.

Generating and Accepting Transactions

As discussed, there are two different kinds of peer nodes; those which host smart contracts and those which do not. In a simple Fabric network, every peer may host a copy of the smart contract, but in larger networks, there will be many more peer nodes that do not host a copy of the smart contract. A peer can only run a smart contract if it is installed on it, but it can know about the interface of a smart contract by being connected to a channel.
You should not think of peer nodes that do not have smart contracts installed as being somehow inferior. It’s more the case that peer nodes with smart contracts have a special power that allows them to generate transactions. Note that all peer nodes can validate and subsequently accept or reject transactions onto their copy of the ledger. However, only peer nodes with a smart contract installed can take part in the process of transaction endorsement which is central to the generation of valid transactions.

IX. Chaincode

Chaincode is a program (or programs) that runs on top of the Hyperledger Fabric blockchain to implement the business logic of how applications interact with the ledger. It is currently written in Go, Node.js, and eventually will be written in other programming languages, such as Java, that implement a prescribed interface. When a transaction is invoked, it triggers the chaincode that decides what state change should be applied to the ledger. Chaincode is typically considered a smart contract. A state created by a chaincode is restricted in scope to that chaincode and can’t be accessed directly by another chaincode. And like all components in Fabric is another module on the architecture.

X. Ledger

The ledger is the sequenced, immutable, entire historical record of all state transactions that take place in a blockchain network. All the transactions that are performed will be added to the ledger in order in which they received and accepted. We can find the entire transaction history for each channel. A Fabric blockchain ledger has two types of data: a world state and a blockchain transaction ledger. The world state is stored in a database whose data is mutable. The default world state database for Hyperledger Fabric is LevelDB which can be changed to CouchDB. World database has a version number that keeps incrementally updated when the state changes. On the contrary, the ledger data is immutable while being stored as a file. It records transaction data block information, which contains a sequence of transactions. Like a normal ledger in a blockchain, each block’s header includes a hash of the block’s transactions.

XI. Ordering Service

The ordering service, or an orderer, builds a shared communication channel between clients and peers. It automatically broadcasts messages containing transactions to peers to be committed. All peers receive the same block of transactions in the same order. The ordering service orders transactions on a first-come, first-serve basis for all channels on the network. After a transaction is ordered, the records of the committed are grouped and assigned as part of the block for that communication channel.

XII. Private Data

In cases where a group of organizations on a channel need to keep data private from other organizations on that channel, they have the option to create a new channel comprising just the organizations that need access to the data. However, creating separate channels in each of these cases creates additional administrative overhead (maintaining chaincode versions, policies, MSPs, etc), and doesn’t allow for use cases in which you want all channel participants to see a transaction while keeping a portion of the data private.
That’s why Fabric offers the ability to create private data collections, which allow a defined subset of organizations on a channel the ability to endorse, commit, or query private data without having to create a separate channel. A collection consists of two elements:

The actual private data, sent peer-to-peer via gossip protocol to only the organization(s) authorized to see it. This data is stored in a private state database on the peers of authorized organizations, which can be accessed from chaincode on these authorized peers. The ordering service is not involved here and does not see the private data. Note that because gossip distributes the private data peer-to-peer across authorized organizations, it is required to set up anchor peers on the channel, and configure CORE_PEER_GOSSIP_EXTERNALENDPOINT on each peer, in order to bootstrap cross-organization communication.
A hash of that data, which is endorsed, ordered, and written to the ledgers of every peer on the channel. The hash serves as evidence of the transaction and is used for state validation and can be used for audit purposes.

Collection members may decide to share the private data with other parties if they get into a dispute or if they want to transfer the asset to a third party. The third party can then compute the hash of the private data and see if it matches the state on the channel ledger, proving that the state existed between the collection members at a certain point in time.
In some cases, you may decide to have a set of collections each made of a single organization. For example, an organization may record private data in their own collection, which could later be shared with other channel members and referenced in chaincode transactions.

When to use a collection within a channel vs. a separate channel

Use channels when entire transactions (and ledgers) must be kept confidential within a set of organizations that are members of the channel.
Use collections when transactions (and ledgers) must be shared among a set of organizations, but when only a subset of those organizations should have access to some (or all) of the data within a transaction. Additionally, since private data is disseminated peer-to-peer rather than via blocks, use private data collections when transaction data must be kept confidential from ordering service nodes.

XIII. Summary

In this article, we learned about the features and components of Hyperledger Fabric. We started off by reviewing the key features of Hyperledger Fabric such as assets, privacy, and consensus, after which we discussed the following important elements of the blockchain network: identities, Membership Service Provider, policies, peers, smart contracts and chaincode, ledger, the Ordering Service, and private data. Understanding of Fabric Network and how its components interact with one another is essential for building blockchain applications in Hyperledger Fabric. We hope that by now you have developed a good foundation for building your first blockchain application in Fabric. Indeed, this article gave you a high-level review of all parts that usually work in conjunction with one another in an enterprise Fabric blockchain application.
In brief, in all previous articles, we moved from a high-level of hierarchy to lower one by covering the concepts of blockchain, Hyperledger Family, and Hyperledger Fabric step-by-step. Now that we have covered all practical concepts, we will proceed with coding from the next article forward. Thus, in the next article, we will start doing hands-on coding by building the first chaincode or Fabric smart contract.

XIV. Resources

Free Webinars on Blockchain

Here is the list of our free webinars that are highly recommended:

Free Courses

Here is the list of our 10 free self-paced courses that are highly recommended:

Self-Paced Blockchain Courses

If you like to learn more about Hyperledger Fabric, Hyperledger Sawtooth, Ethereum or Corda, taking the following self-paced classes is highly recommended: