Hyperledger Fabric comes with several unique features (as listed below) to make it stand out from the other distributed ledger technologies.
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.
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 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 (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.
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:
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.
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.
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.
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.
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
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.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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:
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.
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.
Here is the list of our free webinars that are highly recommended:
Here is the list of our 10 free self-paced courses that are highly recommended:
If you like to learn more about Hyperledger Fabric, Hyperledger Sawtooth, Ethereum or Corda, taking the following self-paced classes is highly recommended:
If you want to master Hyperledger Fabric, Ethereum or Corda, taking the following live classes is highly recommended:
If you like to learn more about blockchain, reading the following articles and tutorials is highly recommended:
We offer private custom tutoring classes both online and in DC, MD and VA for almost all of our courses or bootcamps. Give us a call or email us to discuss your needs.
$50 Limited OfferREGISTER NOW