Hyperledger Fabric Component Design

Hyperledger Fabric is a modular, open-source distributed ledger platform designed for enterprise-grade solutions. It is a framework for building blockchain applications that can be customized and extended to meet the specific needs of different industries and use cases.

Hyperledger Fabric is also known as smart contracts. It is one of the projects under the umbrella of the Hyperledger blockchain consortium, which is an effort by the Linux Foundation to advance cross-industry collaboration for developing blockchain technologies. Fabric is designed to support pluggable implementations of different components, including consensus and membership services, and it uses container technology to host smart contracts called “chaincode” that can be written in a variety of programming languages. Fabric is intended to be a foundation for developing applications or solutions with a modular architecture, allowing components such as consensus and membership services to be plug-and-play.

Hyperledger Fabric Infrastructure Components

One of the key design principles of Hyperledger Fabric is modularity and extensibility. The platform is composed of several components that can be customized and extended to meet the specific requirements of different applications and use cases. The following are some of the main components of Hyperledger Fabric and their roles in the platform:

Hyperledger Fabric Architecture

1. Peer Node

This is the main component of Hyperledger Fabric. It is responsible for managing the ledger, executing smart contracts, and participating in the consensus process. A peer node in Hyperledger Fabric is a server that runs the Hyperledger Fabric software and is part of a network of peer nodes that make up a Hyperledger Fabric blockchain. Each peer node stores a copy of the ledger and participates in the consensus process to validate and endorse transactions, as well as maintain the state of the ledger. Peer nodes can also run smart contracts, known as chaincode in Hyperledger Fabric, which define the business logic of the blockchain network. There are 5 types of Peer nodes:

• Full node: A full node is a peer node that maintains a complete copy of the blockchain, verifies transactions and blocks, and helps to secure the network by participating in the consensus process.
• Lightweight node: A lightweight node is a peer node that does not maintain a complete copy of the blockchain but relies on other full nodes to provide it with the necessary information to verify transactions and blocks.
• Supernode: A supernode is a peer node that has a high amount of computing power and bandwidth, and is responsible for processing and verifying a large number of transactions and blocks.
• Mining node: A mining node is a peer node that uses its computing power to solve complex mathematical problems and compete with other nodes to add new blocks to the blockchain.
• Validating node: A validating node is a peer node that is responsible for verifying the validity and authenticity of transactions and blocks, and ensuring that they adhere to the network’s rules and regulations.

2. Orderer

In Hyperledger Fabric, an orderer is a component that is responsible for ensuring the delivery of transactions to the appropriate peer nodes for validation and endorsement. The orderer maintains an ordered log of all transactions that have occurred on the network and provides a communication channel for the peer nodes to reach a consensus on the order in which transactions should be processed. The orderer does not validate or endorse transactions but rather acts as a mediator to facilitate communication between the different peer nodes. There are 5 types of Orderer:

• Solo orderer: A solo orderer is a single node that is responsible for maintaining the ledger and ordering transactions in the network. This type of orderer is typically used in small or test networks.
• Kafka orderer: A Kafka orderer is a cluster of orderer nodes that use the Apache Kafka distributed messaging system to order transactions and maintain the ledger. This type of orderer is typically used in large or complex networks.
• Raft orderer: A Raft orderer is a cluster of orderer nodes that use the Raft consensus algorithm to order transactions and maintain the ledger. This type of orderer is typically used in networks that require high performance and low latency.
• SNS orderer: An SNS orderer is a cluster of orderer nodes that use the Amazon Simple Notification Service (SNS) to order transactions and maintain the ledger. This type of orderer is typically used in networks that are hosted on Amazon Web Services (AWS).
• CouchDB orderer: A CouchDB orderer is a cluster of orderer nodes that use the Apache CouchDB database to store and order transactions in the network. This type of orderer is typically used in networks that require high availability and scalability

3. Membership service provider (MSP)

In Hyperledger Fabric, a Membership Service Provider (MSP) is a component that defines the rules for identity management and authentication within a Hyperledger Fabric network. MSPs are used to verify the identity of participants in the network, such as users, applications, and peer nodes. They do this by managing the certificates and cryptographic materials that are used to identify and authenticate entities on the network. MSPs play a crucial role in ensuring the security and integrity of the Hyperledger Fabric network by ensuring that only authorized entities can access the network and participate in transactions. There are several types of membership service providers (MSPs) in Hyperledger, including:

• Local MSP: This type of MSP is designed for development and testing purposes and is used to manage the identities of local users and applications.
• File-based MSP: This type of MSP uses a file system to store the identity information of users and applications.
• Certificate Authority-based MSP: This type of MSP uses a certificate authority (CA) to issue and manage the digital certificates that are used to identify users and applications.
• Database-based MSP: This type of MSP uses a database to store the identity information of users and applications.
• External Identity Provider-based MSP: This type of MSP uses an external identity provider, such as a corporate LDAP server or an external CA, to manage the identities of users and applications.

4. Ledger

In Hyperledger Fabric, the ledger is a distributed database that records all of the transactions that occur on the network. Each peer node maintains a copy of the ledger, and the ledger is updated whenever a new transaction is endorsed and committed to the network. The ledger is composed of two parts: the world state, which stores the current state of all assets on the network, and the transaction log, which stores a record of all transactions that have occurred on the network. The ledger is used to provide an immutable record of all transactions and to ensure the consistency and integrity of the data on the network.  There are several types of ledgers in Hyperledger, including:

• Fabric: This is a permissioned blockchain platform that uses a modular architecture to support pluggable components, such as consensus algorithms, membership services, and smart contract languages.
•  Sawtooth: This is a permissioned blockchain platform that uses a unique consensus algorithm called “Proof of Elapsed Time” (PoET) to ensure efficient and secure transaction processing.
•  Iroha: This is a simple and easy-to-use blockchain platform that is designed for the rapid development and deployment of applications.
•  Indy: This is a decentralized identity platform that uses blockchain technology to provide individuals and organizations with a secure and verifiable way to manage their digital identities.
•  Besu: This is an open-source Ethereum client that can be used to build and deploy decentralized applications on the Ethereum public blockchain.

5. Chaincode

In Hyperledger Fabric, chaincode is the term used to refer to smart contracts. Chaincode is written in Go and defines the business logic of a Hyperledger Fabric network. It specifies the rules for updating the ledger and determines which transactions are valid. When a transaction is submitted to the network, it is sent to the appropriate peer nodes for endorsement. The chaincode is then executed on the endorsing peer nodes, and the endorsed transaction is sent back to the client for ordering and finally commit to the ledger. Chaincode is an important part of the Hyperledger Fabric architecture, as it allows users to define the specific rules and functionality of their blockchain network.
In Hyperledger, chaincode refers to the smart contract code that is written in a programming language, such as Go or Java, and deployed on the blockchain network. There are two types of chaincode in Hyperledger Fabric:

• System chaincode: This type of chaincode is deployed and managed by the network administrator and is used to manage the operations of the blockchain network, such as adding new members or modifying the network configuration.
• User chaincode: This type of chaincode is deployed and managed by the users of the network and is used to implement the business logic of the applications that run on the network.

6. Consensus Algorithm

In Hyperledger Fabric, the consensus algorithm is the mechanism by which the peer-ordering service nodes in a network reach an agreement on the order and validity of transactions. The consensus algorithm is an important part of the overall architecture of a Hyperledger Fabric network, as it ensures the integrity and consistency of the ledger by ensuring that all peer nodes have a consistent view of the state of the network. Hyperledger Fabric supports several different consensus algorithms, including the Practical Byzantine Fault Tolerance (PBFT) algorithm and the Kafka-based consensus algorithm. The specific consensus algorithm used by a Hyperledger Fabric network can be configured and customized to meet the needs of the specific application.

• Proof of Work (PoW): This is the most well-known consensus algorithm, and it is used by cryptocurrencies like Bitcoin and Ethereum. In a PoW system, nodes (also known as miners) compete to solve complex mathematical puzzles to validate transactions and create new blocks on the blockchain.
• Proof of Stake (PoS): In a PoS system, nodes are selected to validate transactions and create new blocks based on their “stake” in the network. This typically means that the more cryptocurrency a node holds, the more likely it is to be selected to validate transactions.
• Practical Byzantine Fault Tolerance (PBFT): PBFT is a consensus algorithm designed to be used in distributed systems with non-trustworthy nodes. In a PBFT system, nodes communicate with each other to reach an agreement on the order of transactions.
• Federated Byzantine Agreement (FBA): FBA is similar to PBFT, but it is designed for use in large-scale, decentralized networks. In an FBA system, nodes are organized into groups, and each group reaches consensus independently before combining their results to reach a final consensus.
• Delegated Proof of Stake (DPoS): In a DPoS system, nodes elect a group of representatives (known as “delegates”) to validate transactions and create new blocks on the blockchain. This allows for faster transaction times and higher scalability than other consensus algorithms.

7. Channels

In Hyperledger Fabric, a channel is a private “subnet” within a Hyperledger Fabric network that allows a group of participants to execute transactions and confidentially share data. Each channel has its separate ledger, and the participants on a channel can only see the transactions that are submitted to that channel. This allows different groups of participants within a Hyperledger Fabric network to have their own private, confidential interactions without revealing sensitive information to the other participants on the network. Channels provide an additional layer of security and privacy within a Hyperledger Fabric network. In Hyperledger Fabric, there are three types of channels:

• Application channels: These channels are created by the organizations that are part of a consortium on the network. They are used for conducting transactions and sharing data among the members of the consortium.
• System channels: These channels are created by the network administrator and are used for deploying and updating the network’s shared ledger and other system-level components.
• Private channels: These channels are created by members of the consortium and are used for conducting private transactions between two or more specific organizations. Private channels allow organizations to maintain the confidentiality of their transactions while still being able to take advantage of the security and immutability of the shared ledger.

8. HyperLedger Fabric Certification Authority(CA)

• It provides issuance of Enrollment Certificates.
• It does certificate renewal and revocation.
• It consists of both server and client components. 
• It provides registration of identities or connects to LDAP as the user registry.

9. Client 

Represents the end user or client applications that trigger blockchain events. Clients are software programs that propose transactions on a network on behalf of a person. Clients communicate with peers and ordering services.
The Client interacts with the network using a Fabric SDK. When reading or writing data from a Fabric blockchain the clients interact with the SDK. To ensure that a legitimate client has started the network transaction, the CA authority issues a certificate to the client as well.  

These components work together to provide a modular, extensible platform for building blockchain applications. By customizing and extending these components, developers can create applications that are tailored to the specific requirements of different industries and use cases.

Transaction Work Flow

1. A participant/client in the organization initiates a transaction request.
2. The transaction invocation request is broadcasted to endorser peers by the client application.
3. The transaction is now validated by the endorser reviewing the Certificate details and others, and then according to the chainCode’s logic, the endorser approves or rejects the transactions.
4. After the approval, the transaction is now sent by the client to the committer peer to properly order & add it to the block.
5. The transaction block is then sent to order servicing nodes by the committer to add them to the blockchain.
6. The order servicing nodes verify the block with the consensus protocol and then commit to the Ledger.

Example:

The below example shows how the components of Hyperledger Fabric work together to build a blockchain application:

1. A group of participants, such as banks or other financial institutions, form a consortium to create a blockchain network for a specific use case, such as trade finance.
2. The participants deploy peer nodes on their respective networks and join the consortium. The peer nodes are connected to the ordering service, which generates blocks of transactions and propagates them to the network.
3. The membership service provider (MSP) manages the identities of the participants and enforces the access control policies of the consortium.
4. The participants deploy a smart contract, or chaincode, on the network that defines the business logic of the application, such as the rules for creating, modifying, and settling trade finance transactions.
5. The participants interact with the network by submitting transactions to the ledger. The peer nodes execute the transactions and update the state of the network according to the rules defined in the smart contract.
6. The consensus algorithm ensures the integrity and consistency of the ledger across the network. It ensures that the transactions are processed fairly and consistently and that the ledger is replicated across the network for availability and reliability.

In this example, the components of Hyperledger Fabric work together to create a decentralized, secure, and transparent platform for trade finance applications. By customizing and extending these components, the consortium can create a blockchain network that is tailored to the specific requirements of the trade finance industry.