Module 4: Permissioned Blockchain:

Hyperlegder Fabric
-By
Asst. Prof. Rohini M. Sawant
Hyperledger
 Hyperledger
• Hyperledger acts as an umbrella project that contains multiple
blockchain tools and frameworks. It helps companies build
blockchain systems easily using standard components.

• Key points
● Open-source blockchain platform
● Supports development of enterprise blockchain applications
● Provides tools, libraries, and frameworks
Hyperledger Frameworks
 Hyperledger Frameworks
Hyperledger contains
multiple frameworks, each
designed for different
purposes.

Major Projects

Key points

Different frameworks solve

different business
problems.
Hyperledger Frameworks
Hyperledger Frameworks
 Hyperledger Frameworks
Hyperledger Fabric
● Most widely used framework
Hyperledger Frameworks
Hyperledger Frameworks
Hyperledger Tools
Hyperledger Tools
Hyperledger Tools
Hyperledger Tools
Hyperledger Tools
Hyperledger Tools
Hyperledger Tools
Architecture of Hyperledger Fabric
 Architecture of Hyperledger Fabric
Key Components of Hyperledger Fabric: The key components of HF that make up its architecture are as
follows:

Peer Nodes:

Peer nodes serve as the primary execution environment within a Fabric network. They maintain a copy of the
distributed ledger and execute smart contracts, known as chain codes. Each organization participating in the
network typically has one or more peer nodes. Peer nodes are the instances of the Hyperledger Fabric
runtime that maintain a copy of the shared ledger and smart contracts (chaincode). They are distributed
across the network and communicate with other peers to maintain consensus and ensure the validity of
transactions.

Types of Peer Nodes:

● Endorsing Peers: These peer nodes receive transaction proposals from clients, execute the chaincode,
and return the results along with an endorsement signature. Endorsing peers don't update the ledger
but are critical for achieving transaction endorsement.
● Committing Peers: After receiving the endorsed transaction, committing peers validate the
endorsements and ensure the correctness of the endorsements before committing the transaction to
the ledger.
● Anchor Peers: These are specific peers in each organization that maintain communication with peers in
other organizations. They are used to facilitate cross-organization communication.
 Architecture of Hyperledger Fabric
Membership Services Provider (MSP):
The MSP manages the identity and access control policies for participants in the network. It authenticates and authorizes network
participants, ensuring secure interactions. MSPs enable flexible membership models, such as Certificate Authorities (CAs) and
token-based systems. It is a module within HF that manages identities, certificates, and cryptographic materials for the
participants of the network. It is responsible for authenticating and authorizing network entities, such as peers, orderers, clients,
and administrators.

Identity Management: MSP handles the creation, issuance, and revocation of digital certificates that serve as the identity
credentials for network participants. These certificates are used to prove the authenticity and authority of an entity to access the
network and interact with other peers.

Certificate Authorities (CAs): MSP relies on Certificate Authorities to issue certificates to network participants. There are two
types of CAs in Hyperledger Fabric:

1. Registration Authority (RA): RA is responsible for authenticating users and clients and registering their identities with the
CA. It verifies the identity of the entity requesting the certificate.
2. Intermediate Certificate Authority (Intermediate CA): Intermediate CAs are used to issue certificates on behalf of the root
CA. They are often deployed to create a hierarchical structure for certificate issuance, enhancing security and
manageability.

Hyperledger Fabric allows the creation of multiple MSPs within a single network, each representing a distinct organization. This
enables multi-organization consortium networks with separate identity management for each organization.
 Architecture of Hyperledger Fabric
Orderer Nodes:
Orderer nodes manage the consensus mechanism in Hyperledger Fabric. They receive endorsed transactions
from peer nodes, package them into blocks, and establish a total order of transactions across the network.
Fabric supports multiple consensus algorithms, including Kafka, Raft, and others. Orderer nodes are responsible
for receiving transaction proposals from clients, ordering them into blocks, and delivering the blocks to the
endorsing and committing peers in the network. They establish a consistent transaction order and ensure that
all peers have a synchronized view of the blockchain ledger.

Channels:
Channels in Fabric allow for the segregation of network participants into smaller, private subgroups. Each
channel has its own ledger and chaincode, ensuring data confidentiality. Channels enable secure collaboration
between specific parties without revealing information to the entire network. Channels in Hyperledger Fabric are
private subnetworks within a larger blockchain network. They allow a subset of network participants to create a
separate communication and transaction layer, ensuring privacy and confidentiality for the transactions and data
shared within the channel. They are particularly useful in scenarios where multiple organizations need to
collaborate while maintaining data privacy. They are commonly used in supply chain management, financial
networks, and any other scenario that requires selective data sharing among participants.
 Architecture of Hyperledger Fabric
Chaincode:
Chaincode (smart contracts) is the executable code that defines the rules and logic for the interactions and transactions within the
Hyperledger Fabric network. It encapsulates the business logic of an application and determines how transactions are processed
and the state of the ledger is updated. It can be written in various programming languages, such as Go, JavaScript, and Java. And
chaincode runs in a distributed manner across multiple endorsing peers in the network. Each endorsing peer executes the
chaincode independently and validates the transactions based on the defined logic.

Ledger:
The distributed ledger in Fabric maintains a tamper-proof record of all transactions executed within the network. It is implemented as a
combination of the world state and the transaction log. The world state represents the latest values of assets, while the transaction log
ensures immutability and transparency.

Types of Ledger:

Hyperledger Fabric maintains mainly two types of ledgers that are as follows:

1. Transaction Log (Blockchain): This ledger contains an immutable, ordered log of all the transactional data, organized into blocks.
Each block contains a batch of transactions.
2. World State: The world state ledger maintains the current state of the blockchain network after applying all the transactions. It
represents the most recent state of all assets and data within the network.
 Transaction Lifecycle in Hyperledger Fabric
Every transaction in Fabric follows a clearly defined lifecycle:

1. Proposal Submission:
A client application sends a transaction proposal to endorsing peers.
2. Endorsement Phase:
Endorsing peers simulate the transaction and sign results without updating the ledger.
3. Ordering Phase:
The ordering service sequences endorsed transactions into blocks using the consensus
mechanism.
4. Validation and Commit:
Peers validate endorsements against policies, then append the block to the ledger and update the
world state.
This process ensures that transactions are deterministic, verifiable, and efficiently validated across
distributed nodes.
 CONSENSUS MECHANISMS
●
 CONSENSUS MECHANISMS
1. Execution Phase:
● Transaction Proposal: The transaction flow begins when a client initiates a transaction by creating a transaction proposal. The proposal
includes the details of the requested operation and input data. The client interacts with the Fabric network through an application or SDK.
● Endorsement: The client sends the transaction proposal to endorsing peers in the network. The endorsing peers simulate the transaction by
executing the proposed operation using the smart contract (chaincode) associated with the transaction. They then endorse the transaction
by signing the results.
● Endorsement Policy: The endorsement policy specifies the required number of endorsements for a transaction to be considered valid. The
policy can be customized based on the network's requirements, such as requiring endorsement from a majority of peers or a specific set of
organizations.

2. Ordering Phase:
● Transaction Assembly: After obtaining the required endorsements, the client assembles the endorsed proposals into a transaction.
● Broadcast to Ordering Service: The client broadcasts the transaction to the ordering service, which is responsible for collecting and ordering
transactions from various clients.
● Consensus: The ordering service uses a consensus algorithm to agree on the order of the transactions and create a block containing the
ordered transactions. Consensus ensures that all participating ordering service nodes reach an agreement on the transaction order.

3. Validation Phase:
● Block Distribution: Once the block is created by the ordering service, it is distributed to all peers in the network.
● Transaction Validation: Upon receiving the block, each peer independently validates the transactions within the block. Validation includes
verifying the digital signatures, checking for policy violations, and ensuring that endorsing peers is legitimate.
● State Update: Valid transactions go through the state update process, where peers execute the transactions and update their copy of the
ledger accordingly. The ledger maintains a complete history of all valid transactions.
● Consensus Verification: Peers participate in a consensus protocol to ensure that all valid transactions have been executed correctly. This
verification process ensures that all peers have the same view of the ledger and that the transactions comply with the consensus rules.
 CONSENSUS MECHANISMS
● Consensus mechanisms are essential components of blockchain networks, ensuring that
transactions are validated and added to the ledger in a consistent and agreed-upon manner.
● Hyperledger Fabric, a popular permissioned blockchain platform, supports various consensus
mechanisms, each with its advantages and limitations.
● In Hyperledger Fabric, consensus is achieved through a pluggable mechanism, which allows
different consensus algorithms to be implemented and chosen according to the specific
requirements of the network.
 CONSENSUS MECHANISMS
Solo-based Consensus

● Solo is a simple, non-production consensus mechanism intended for development and testing purposes. It
is not crash fault-tolerant and should not be used in production environments.
● Solo provides a single, centralized ordering service, making it suitable for small-scale deployments and
testing environments.
● Its primary advantage lies in its simplicity, as it requires minimal configuration and setup.
● The Solo implementation of the ordering service is intended for test only and consists only of a single
ordering node.
● It has been deprecated and may be removed entirely in a future release. Existing users of Solo should
move to a single node Raft network for equivalent function.
 CONSENSUS MECHANISMS
Solo-based Consensus

Nonetheless, Solo has significant drawbacks that limit its applicability in real-world
deployments:

● Centralization: Solo relies on a single ordering service, creating a single point of

failure and making the system susceptible to attacks or service disruptions.
● Lack of Fault Tolerance: Solo cannot recover from node crashes or network failures,
making it unsuitable for production environments.
 CONSENSUS MECHANISMS
Raft-based Consensus
Raft is a consensus algorithm designed for simplicity and understandability. A crash
fault-tolerant (CFT) algorithm provides strong consistency guarantees, ensuring that
transactions are replicated across all nodes in the same order.

Raft follows a “leader and follower” model, where a leader node is elected (per channel) and its
decisions are replicated by the followers.

Raft ordering services should be easier to set up and manage than Kafka-based ordering services,
and their design allows different organizations to contribute nodes to a distributed ordering
service.
 CONSENSUS MECHANISMS
Raft-based Consensus

Raft has emerged as the preferred consensus mechanism for many Hyperledger Fabric deployments, as it
offers several advantages:

● Simplicity: Raft is easier to understand, implement, and debug compared to other consensus
algorithms like Paxos.
● Scalability: Raft can scale to accommodate many nodes, making it suitable for large-scale
deployments.
● Quick Leader Election: In case of a leader failure, Raft can quickly elect a new leader, ensuring
minimal disruption to the network.
● Safety: Raft guarantees that the system will remain consistent even in the face of network failures
or node crashes.

However, Raft does have some limitations, such as its vulnerability to network partitioning and the potential
for degraded performance in high-latency networks.
 CONSENSUS MECHANISMS
Kafka-based Consensus

● Kafka is a crash fault-tolerant (CFT) consensus mechanism based on Apache Kafka, a distributed streaming
platform.
● Kafka provides strong consistency guarantees by replicating transactions across multiple nodes and ensuring that
they are committed in the same order.
● Kafka was the default consensus mechanism for earlier versions of Hyperledger Fabric but has since been
replaced by Raft as the recommended CFT consensus algorithm.
● Similar to Raft-based ordering, Apache Kafka is a CFT implementation that uses a “leader and follower” node
configuration
● Kafka offers several benefits, such as high throughput, fault tolerance, and scalability. However, it also has some
drawbacks:
● Complexity: Kafka's architecture and configuration can be complex, making it difficult to set up, manage, and
troubleshoot.
● Dependencies: Kafka relies on external components like Apache ZooKeeper, which introduces additional
points of failure and maintenance overhead.
 Hyperledger Challenges: Interoperability
Interoperability Challenge:

A significant obstacle in Hyperledger development is integrating blockchain technology with existing legacy systems. Businesses
often have complex infrastructure built on traditional databases. In many cases, existing systems were not designed with
blockchain in mind. This makes the integration process particularly challenging.

Solution:

A strategic approach to integration significantly reduces the friction of adopting Hyperledger. It is crucial to establish clear
integration requirements. Ensuring that communication protocols between systems are well-defined is essential. Middleware or
adapter layers help bridge the gap between blockchain and legacy systems. Comprehensive testing is also necessary to ensure
that the systems communicate effectively and efficiently. Here’s what you can do:

● Focus on interoperability during the design phase.

● Use middleware solutions or API bridges to connect the blockchain network with existing infrastructure.
● Collaborate with Hyperledger blockchain development services providers to design adaptable interfaces and communication protocols.
● Test rigorously to ensure compatibility and smooth data flow across systems.
 Hyperledger Challenges: Scalability
Challenge:

As transaction volumes grow, performance and scalability become important considerations in Hyperledger
blockchain development. While Hyperledger is designed for enterprise use, it still faces challenges when
handling large amounts of data. Hyperledger Fabric, for instance, is designed for high performance. However, as
the transaction volume increases, the system may slow down, affecting overall efficiency. Hyperledger relies on
consensus mechanisms such as the "endorsement policy." This requires multiple peers to validate transactions.
As the network grows, this process results in bottlenecks, hindering the speed of transaction processing.

Solution:

Several measures help optimize performance. Partner with a Hyperledger development company that fine-tunes
network configurations and allocates resources efficiently. Optimizing consensus mechanisms is another
strategy. Load balancing and parallel transaction processing help improve scalability in Hyperledger networks.
Additionally, adopting off-chain solutions eases the burden on the blockchain network, improving overall
performance.