Hyperledger Fabric: Unit-1

Hyperledger :
“Hyperledger is an open source collaborative effort created to advance cross-
industry blockchain technologies. It is a global collaboration, hosted by The Linux
Foundation, including leaders in finance, banking, Internet of Things, supply chains,
manufacturing, and Technology.”

Hyperledger Fabric is designed for use in enterprise-level applications, and it is

characterized by its modular architecture, permissioned network, and smart
contract functionality, known as “chaincode”.

Hyperledger Design Principles:

1. Modular: This principle states that all components of all frameworks should be
modular. Some of the components of hyperledger projects are as follows:

 Peer
 Channel
 chaincode
 Ledger

2. Highly secure: This principle is concerned with security, not just the crypto
abstraction, but also the communication between network components and the
framework that governs the permission nature of permissioned
[Link] architecture.

3. Interoperability: This principle addresses backward interoperability rather than

interoperability among the multiple hyperledger project-powered blockchain
systems. The parties connected through the network must be able to control the
business model. Peer-to-peer networks that enable application connectivity are
simple to manage.

4. Easy-To-Use APIs: This principle’s focus is on ensuring that blockchain systems

have access to corporate networks, new systems, and current participants while not
disclosing the intricacies of blockchain-powered business networks.

Overview of Hyperledger projects:

Below are some of the hyperledger projects:

1. Hyperledger Burrow
 Similar to the Ethereum Virtual Machine, Hyperledger Burrow offers a flexible
blockchain client with a permissioned blockchain-based interpreter. Monax
initially contributed and Intel co-sponsored.
 Burrow’s declared goal is to support the operation of permissioned networks
that are ‘open to the public.’ With Burrow’s permissions approach, there are
numerous shades of grey in terms of network involvement.
2. Hyperledger Iroha
 Hyperledger Iroha is focusing on mobile application development and
Sumeragi, a revolutionary chain-based Byzantine Fault Tolerant consensus
mechanism. Soramitsu, Hitachi, NTT Data, and Colu are working on this project.
 Hyperledger Iroha is a corporate blockchain platform built for distributed ledger
infrastructure initiatives. The Iroha platform can be used to create an identity
management system, such as national ID cards.
3. Hyperledger Indy
 Hyperledger Indy is a distributed ledger designed specifically for decentralized
identification. Evernym contributed the indy code base that he created to the
Sovrin foundation.
 It offers tools, frameworks, and reusable components for developing and
deploying autonomous digital identities based on blockchains or other
distributed ledgers. Hyperledger Indy is a distributed ledger designed
specifically for decentralized identity.
4. Hyperledger Fabric
 Hyperledger Fabric is led by IBM. Hyperledger Fabric is a plug-and-play
blockchain technology implementation with a configurable degree of
permissions. The Linux Foundation manages this private and confidential
blockchain framework.
 Hyperledger Fabric is a scalable, flexible architecture-based platform for
distributed ledger applications. It is designed to allow for pluggable versions of
various aspects and to manage the financial ecosystem’s complexities and
intricacies.
5. Hyperledger Grid
 The Hyperledger Grid is an ecosystem of technologies, frameworks, and libraries
that collaborate to allow application developers to choose which components
are most suited to their industry or market model. Cargill is spending resources
on the project’s development.
 The Hyperledger Grid platform is used to create supply chain solutions that
integrate distributed ledger components. It offers an expanding range of tools
that help to expedite the development of supply chain smart contracts and
client interfaces. This is not a distributed ledger or a client application
implementation.
6. Hyperledger Sawtooth
 Hyperledger Sawtooth is a flexible platform for developing, implementing, and
running distributed ledgers, and it features a revolutionary consensus
mechanism known as Proof of Elapsed Time. This consensus is suitable for large
distributed validator groups while consuming few resources.
 Intel is working on this project. Hyperledger Sawtooth is an open-source
industrial blockchain-as-a-service platform that can run customized smart
contracts without requiring knowledge of the core system’s underlying design.

Hyperledger Fabric Model:

Following are the key features of Hyperledger Fabric that fulfill its promise of
customizable enterprise Blockchain

 Assets: Enable the exchange of monetary value over the network

 Chaincode: Partitioned from transaction ordering, limiting the required levels
of trust and verification across node types, and optimizing network
scalability and performance
 Ledger Features: Encodes the entire transaction history for each channel, and
includes SQL-like query capability Privacy through
 Channels: Enable multi-lateral transactions with the high degrees of privacy
and confidentiality
 Security & Membership Services: In Permissioned membership participants
know that all transactions can be detected and traced by authorized
regulators and auditors
 Consensus: Allow network starters to choose a consensus mechanism that
best represents the relationships that exist between participants.

Q: Transaction lifecycle in Hyperledger?

 In Hyperledger Fabric, the transaction lifecycle involves multiple stages from

the submission of a transaction proposal to its final commitment to the
distributed ledger. Below is an overview of the typical transaction lifecycle in
Hyperledger Fabric:
 Transaction Proposal:
 Initiation: A client initiates a transaction by creating a transaction proposal.
This proposal includes details such as the target smart contract (chaincode),
the specific function to invoke, and any required input parameters.
 Endorsement: The client sends the transaction proposal to a set of endorsing
peers. These peers simulate the execution of the transaction and return an
endorsement (a signed statement confirming the validity of the proposed
transaction) to the client.
 Transaction Endorsement:
 The endorsing peers execute the smart contract and validate the transaction
proposal. If the proposal is valid, the endorsing peers sign an endorsement
and return it to the client.
 Multiple endorsements may be collected from different endorsing peers.
 Transaction Proposal Response:
 The client gathers the endorsements and packages them into a transaction
proposal response. This response includes the endorsed results,
endorsements, and other required information.
 The client then sends the transaction proposal response to the ordering
service.
 Ordering:
 The Ordering service collects transaction proposal responses from various
clients and orders them into blocks. The blocks consist of a set of transactions,
and they are broadcasted to all peers in the network.
 Transaction Distribution:
 Peers in the network receive the ordered blocks and validate them for
correctness and consistency. The endorsed transactions are then passed to the
commit phase.
 Transaction Commit:
 Peers validate the transactions again during the commit phase to ensure that
the endorsed results match the actual results.
 If validation is successful, the transactions are committed to the distributed
ledger, and the world state is updated accordingly.
 The transaction is now considered immutable and part of the ledger history.
 Event Notification:
 Optionally, the committing peers may generate and broadcast event
notifications to notify interested parties about the successful execution and
commitment of the transaction.
 Throughout this lifecycle, Hyperledger Fabric employs a modular architecture
that allows for the pluggability of consensus algorithms, endorsement policies,
and other components, providing flexibility and customization based on the
requirements of the blockchain network.
Hyperledger Fabric Architecture:-

Hyperledger Fabric is a permissioned blockchain platform that provides a framework

for developing decentralized applications (DApps) with a focus on enterprise use
cases. The architecture of Hyperledger Fabric is designed to address the specific
requirements of business networks, such as scalability, privacy, and modularity. Below
is an overview of the key components and architectural aspects of Hyperledger
Fabric:

Network Components:

Peer Nodes: These are the nodes that maintain the ledger and smart contracts,
known as chaincode. There are two types of peer nodes: endorsing peers and
committing peers. Endorsing peers simulate transactions and endorse the results,
while committing peers validate endorsed transactions and add them to the ledger.
Ordering Service: The ordering service is responsible for ordering transactions into
blocks, which are then distributed to the peer nodes. It ensures a consistent order of
transactions across all nodes in the network.

Certificate Authority (CA): Hyperledger Fabric uses a PKI-based membership

service to manage cryptographic identities of network participants. The Certificate
Authority issues X.509 certificates for clients, peers, and orderers to ensure secure
communication within the network.

Membership Service Provider (MSP): The MSP manages the identity of participants
in the network. It defines the rules for authenticating and authorizing network users,
establishing a permissioned blockchain.

Ledger:

World State: The world state is a database that holds the current values of all key-
value pairs. It represents the latest state of the blockchain.

Blockchain: The blockchain is a tamper-evident and immutable ledger that records all
transactions in a sequential order. However, unlike public blockchains, Hyperledger
Fabric allows for multiple blockchains (channels) within the same network, providing
privacy and confidentiality.

Chaincode:

Chaincode, also known as smart contracts, are the business logic of the network.
They define the rules for updating the ledger and are executed on endorsing peers
during the transaction validation process.

Channels:

Channels are private sub-networks within the overall blockchain network. They
enable multiple parties to have their own private view of the ledger, ensuring
confidentiality for specific transactions.

Consensus Mechanism:

Hyperledger Fabric supports pluggable consensus mechanisms. By default, it uses a

practical Byzantine Fault Tolerance (PBFT) algorithm for ordering transactions.
However, other consensus mechanisms can be implemented based on the network's
requirements.
Smart Contracts Lifecycle(Chaincodes):

Chaincode can be installed, instantiated, and upgraded using a defined lifecycle

process. This ensures that changes to the smart contracts are done in a controlled
and versioned manner.

Q: Different types of peers in Hyperledger Fabric?

1. Committer peer: Commits transactions, maintains ledger and state

2. Endorsing peer: Receives a transaction proposal for endorsement,
responds granting or denying endorsement
3. Ordering peer: Approves the inclusion of transaction blocks into the
ledger and communicates with peer and endorsing peer nodes

Endorsing Peers:

Role: Endorsing peers simulate the execution of transactions to check their validity
and endorse them with their digital signatures.

Functionality: They execute smart contracts (chaincode) and return the results to the
client. The client collects these endorsements and sends them to the ordering
service.

Ordering Peers (Orderer Nodes):

Role: Ordering peers or nodes order transactions into blocks and ensure their
consistency across all peers in the network.

Functionality: They create blocks of endorsed transactions and broadcast them to all
peers in the network. Each peer receives the same set of ordered transactions,
ensuring consistency.

Committing (Validating) Peers:

Role: Committing peers validate blocks and commit them to the ledger.

Functionality: After receiving ordered blocks, committing peers validate the

transactions within the block, check the endorsements, and update the ledger. They
store the committed transactions and respond to queries from other peers.
Leader Peers :

This peer node always receives a new block from the orderer and shares it with the
other peers using the Gossip protocol. There are 2 types of leaders can be set up

within an organization,

Dynamic Leader — Other peers in the organization select the leader peer on run time,

so in this case, any peer can receive the new block from the orderer.

Static Leader — Only the fixed peer/s will act as leaders within an organization

network.

Anchor Peers :

One organization’s peers are known to other organizations so that these peers can
communicate with each other using a Gossip protocol, these peers called Anchor
peers. Those peers are not discoverable by other organizations called Non-Anchor
peers.

Role: Anchor peers are specific peers in an organization that serve as connection
points for communication with peers in other organizations.

Functionality: They help establish cross-organizational communication and are used

during the endorsement and validation phases of transactions involving multiple
organizations.
Q: PBFT(Practical Byzantine Fault Tolerance):
PBFT, or Practical Byzantine Fault Tolerance, is a consensus algorithm designed for
achieving consensus in a distributed system, particularly in the context of a
blockchain network. The primary goal of PBFT is to provide a robust and secure
consensus mechanism even in the presence of malicious nodes (Byzantine faults).

Types of Byzantine Failures:

There are two categories of failures that are considered. One is fail-stop(in which
the node fails and stops operating) and other is arbitrary-node failure. Some of the
arbitrary node failures are given below :
 Failure to return a result
 Respond with an incorrect result
 Respond with a deliberately misleading result
 Respond with a different result to different parts of the system

PBFT Algorithm:

Request and Pre-Prepare Phase:

A client sends a transaction request to all nodes in the network.

Each node, upon receiving the request, broadcasts a "pre-prepare" message to all
other nodes, containing the proposed transaction and a view number.

Prepare Phase:

Nodes receive pre-prepare messages from other nodes.

Upon receiving 2f+1 pre-prepare messages (where f is the maximum number of

faulty nodes the algorithm can tolerate), a node sends a "prepare" message to
others, indicating that it has seen sufficient support for the proposed transaction.

Commit Phase:

Nodes collect prepare messages from other nodes. Upon receiving 2f+1 prepare
messages, a node sends a "commit" message to others, signifying its commitment to
the proposed transaction.

Once a node receives 2f+1 commit messages, it considers the transaction as

committed.

Response to Client:
Once a node commits a transaction, it executes the transaction and sends a response
to the [Link] response assures the client that the transaction is finalized and will
be included in the next block.

Example:
Let's consider a simple example with three nodes (n1, n2, n3) in a PBFT network. The
network can tolerate one faulty node (f=1).

Request and Pre-Prepare:

Client C sends a transaction request to n1, n2, and n3.

Each node broadcasts a pre-prepare message with the proposed transaction.

Prepare:
Upon receiving pre-prepare messages, each node waits until it has received 2f+1
pre-prepare messages (in this case, 2) for the same transaction. Once a node has
sufficient pre-prepare messages, it broadcasts a prepare message.

Commit:

Nodes wait until they have received 2f+1 prepare messages for the same transaction.
Once a node has sufficient prepare messages, it broadcasts a commit message.

Response to Client:
Nodes wait until they have received 2f+1 commit messages for the same transaction.
Once a node has sufficient commit messages, it executes the transaction, includes it
in the ledger, and sends a response to the client.

Conclusion:
PBFT ensures that all honest nodes agree on the order and validity of transactions,
even in the presence of malicious nodes or faults. It's important to note that PBFT
requires a synchronous network assumption, meaning that there is a known upper
bound on the time it takes for messages to be delivered.