Private Blockchain

Module - 5
 Topics to Cover 1. Introduction to Hyperledger
2. Tools and Frameworks
1. Key characteristics
3. Hyperledger Fabric
2. Need of Private Blockchain
4. Comparison between Hyperledger Fabric &
3. Smart Contract in a Private Environment
Other Technologies
4. State Machine Replication
5. Hyperledger Fabric Architecture
5. Consensus Algorithms for Private Blockchain -
PAXOS and RAFT 6. Components of Hyperledger Fabric: MSP,

6. Byzantine Faults: Byzantine Fault Tolerant Chain Codes, Transaction Flow

(BFT) and Practical BFT 7. Working of Hyperledger Fabric
8. Creating Hyperledger Network
9. Case Study of Supply Chain Management
using Hyperledger
 Introduction
● Private Blockchains are PRIVATE, as all permissions for the blockchain are kept
centralized.
● These are sort of Blockchains BANKS are testing with.
● Another name for Private Blockchain is Permissioned or Centralized Blockchain
● Private blockchains are “closed eco-system” where all participants are well-
defined.
● Only pre-approved entities can run nodes.
 KEY CHARACTERISTICS OF PRIVATE BLOCKCHAIN
● Private Blockchain are a great place to start in Business – to – Business Model.
● Here, the DEGREE of DECNETRALISATION and TRANSPARENCY are entirely up to the
company or companies running and configuring the blockchain
● There is NO ANNONYMITY.
● It does not require Mining or Validate Transactions or Execute Smart Contracts
● It does not require Crypto-Economic Incentive or Tokens for Miners
● The Private Blockchain is a CLOSED ENVIRONMENT consisting of set of nodes, which
knows each other, but they MAY NOT TRUST EACH OTHER.
● Before joining the blockchain network, the nodes have to go through some
AUTHENTICATION or PRE-AUTHORIZATION mechanism through which they can validate
themselves
KEY CHARACTERISTICS OF PRIVATE BLOCKCHAIN
 KEY CHARACTERISTICS OF PRIVATE BLOCKCHAIN
OPERATION:
✓ Only pre-approved participants can read and / or initiate transactions in a
private Blockchain.
✓ There is NO MINER, and so there is no INCENTIVISATION
✓ It is secured by a distributed consensus mechanism such as PAXOS, RAFT, BFT,
pBFT.
✓ It has BETTER SCALABILITY as high storage and computational power is not
required
✓ Also, the transaction speed is high as it just takes seconds to create a block.
 Need of Private Blockchain
● Private blockchains are used by individual hobbyists or by private enterprises or organizations with a
specific purpose (e.g., an NGO may like to keep a record of money spent in various schools).
● Organizations prefer using a private blockchain, if they would like to control:
○ who can use the system
○ who can write to the system
○ who can read the system.

● Besides, organizations need a solution with a mechanism to ensure users are added via process, and
user rights are created, changed, or deleted by an authorized user. These needs arose and gave birth
to a need for private blockchain. In addition, the solution needs faster transactions, proper audit trail,
interactions with the organization’s existing IT systems.
 Smart Contract in a Private Environment
● A SMART CONTRACT is a self-executing (auto-contract) in which the agreement
between the buyer and the seller is directly written into the lines of code.

Example: Execute a selling transaction when a specific condition is satisfied

 Smart Contract in a Private Environment
Example: Execute a selling transaction when a specific condition is satisfied

Assume you have a seller, a buyer and you have individual assets.
The contract makes a match with the buyer and the seller. When a purchase is made,
there are specific scripts that will be executed at the seller as well as buyer side.

Buyer’s side: If he has transferred the required money, the asset should be in his
hands within a specified duration. The moment the buyer transfers the money to
seller, the ownership of the asset goes from seller to buyer.

Seller cannot claim the ownership of the asset

This is the concept of smart contract, which can be executed in a closed

environment with the help of blockchain.
 DESIGN LIMITATIONS IN PERMISSIONED ENVIRONMENT
1. Denial-of-Service Attack
● In a typical environment, we execute transactions sequentially based on consensus.

● If a specific transaction is verified or gets committed, it will be executed first. The

transaction that is committed later on will be executed next. So, the request to the
applications(smart contracts) is carried out by the order of consensus

● This kind of sequential order gives a bound on effective Throughput since absolute
consensus has to be ensured.

● In permissionless model, the nodes use CHALLENGE-RESPONSE method to come to

a consensus.

● Throughput is inversely proportional to the commitment latency

 DESIGN LIMITATIONS IN PERMISSIONED ENVIRONMENT
Denial-of-Service Attack
● If the difficulty challenge is increased, the effective throughput will drop

● This can be source of possible attack on the smart contract platform.

● The attacker can introduce a contract, which will take long time to execute. If a specific
contract takes considerable time to execute, other contracts will not be able to execute
any further, since these can be taken up only when consensus for the previous contract
has been reached.

● Therefore, the serialized nature of the order of transactions prevents execution of the next
contract.

● If malicious contract is introduced in the system, it will take a considerable amount for
execution, thus launching a DENIAL – OF – SERVICE attack.
 DESIGN LIMITATIONS IN PERMISSIONED ENVIRONMENT
2. Implementation Language of Smart Contract
● The second problem is the identification of a suitable language for implementing a
smart contract.

● To implement a smart contract, we need to use a language that gives more power.
Bitcoin script is not a “Turing complete” language.

● For example, it does not support loops, and it has certain limitations in execution.
Therefore, developers use different types of suitable languages; one example is
Golang, which is widely used in the contract execution platform.
 DESIGN LIMITATIONS IN PERMISSIONED ENVIRONMENT
2. State Synchronization in Smart Contract
● Execution of Smart Contract is the 3rd design limitation

● State synchronization is required across all nodes. The contract is executed on one
node and after executing it, the state of the contract is broadcasted to the
neighbouring nodes, and that state is further propagated.

● In this way, every node in the system gets the same state of the contract.

● In case, if a node becomes FAULTY ( When system goes down and is unable to make any
progress ) then the concept of STATE MACHINE REPLICATION is used
 State Machine Replication
● The state machine replication helps us to achieve a consensus in a permission
model. We do not need to execute a smart contract to all the nodes.

● Rather, the selected subset of contract executor, executes it and propagates it with
other nodes to ensure the contract’s status is propagated to all the nodes uniformly
in the network, and they are on the same page.

● The distributed state machine replication technology ensures consensus in a

permission blockchain environment.
 State Machine Replication Consensus
● State machine replication-based consensus algorithm is used in Permissioned
Blockchain. This is because of;
○ Closed Network: When the network is closed, every individual node knows each other. Thus
state replication is possible among the known nodes. If you know your peers, you can always
replicate your state machine with the current state as that of your peers.

○ The state machine replication based scenario avoids the overhead of mining.

○ The consensus is still required on top of the state machine replication because the machines
can be faulty, or they can behave maliciously
 Faults in Distributed Consensus
● In a distributed environment, you can have primarily three types of fault:

1. Crash Fault : In this type of fault, a node crashes and is not able to send any message; it may
recover after some time and start sending messages again. This is called a Fail-stop
Behaviour. In a fail-stop behaviour, all the requested messages arrive, and all are considered
to be valid, and thus, problems are solved easily. This model does not consider the case where
the server itself may crash. Thus, this model is not very commonly used.

2. Network or Partition Fault : Here, because of a network fault, the network is partitioned, and
the message from one partition cannot be propagated to another partition

3. Byzantine Faults: A node starts behaving maliciously. It is a kind of fault that is very difficult
to handle as the node’s behavior is unpredictable. It also includes software and hardware
faults
The crash and network faults are expected and can be predicted using the probabilistic models. However,
Byzantine fault can be crafted with malicious intent. Thus, it isn’t easy to guess to apply suitable remedies.
So the consensus protocols have to deal with these three kinds of faults in the distributed ecosystem.
 Consensus for Three Processes
● Consensus is not required in Single – Node Process

● In the case of two nodes, if there is any fault in the network or if there is a network crash, or if
the node behaves maliciously, no consensus can be reached. Therefore, to reach a
consensus, more than two nodes are required.

● There is a need for consensus whenever specific decisions are to be taken conventionally by
multiple decision-makers.
Consider a three-node process. Before consensus is reached among the
three processes (P1, P2, and P3), each process can be in one of the
three states:
1. Undecided State
2. Communication State
3. Decided State.
In the undecided state, the process at the node has proposed a
specific value from a set of possible values. Every node has proposed
some value, and they are in an undecided state. Undecided State:
Proposed value (V1 , V2 , V3….Vn)
 Consensus for Three Processes
● In the communication state, the nodes exchange values among themselves. By exchanging
the values and then applying the consensus algorithm, they can reach the decision state.

● In the decided state, everyone in the network agrees on a particular variable.

 Requirements of a Consensus Algorithm
● There are three requirements for a consensus algorithm to work correctly. They are

1. Termination : There are specific requirements of a consensus algorithm; you need to ensure
that eventually, each process sets the decision variable and terminates after setting the
decision variable. All processes must eventually agree on an output value before termination.

2. Agreement Property : The agreement property says that the decision value for all correct
processes should be the same; every correct node should reach a collective agreement.

3. Integrity : The third property is integrity. If the correct processes propose the same value, then
all processes in the decision state should choose that value. That is, if all correct processes
propose one value X, at the decision state, they should agree on the same value X.
 Consensus Algorithms for Private Blockchain - PAXOS
● It was the first consensus algorithm proposed by L. Lamport in 1989.

● The objective was to choose a single value under the crash or network faults.

Example
 Consensus Algorithms for Private Blockchain - PAXOS
Paxos: Types of Nodes

There are three types of nodes, the proposer, acceptor, and learner.
However, everyone is a learner in the network who learns what the
majority decision is.

● Proposer: The proposer proposes values, and the consensus

algorithm should choose the proposed values.

● Acceptor: They form the consensus and accept the values.

Whenever they hear a certain proposal from the proposer, the
acceptors either accept or reject the proposal.

● Learner: This learner will determine which value has been chosen
by each acceptor and collectively accept that particular value. –
Announces the Outcome
 Consensus Algorithms for Private Blockchain - PAXOS
Making a Proposal: Proposer Process
● The proposer initially proposes (with a proposal number). This proposal number
needs to be good enough to be accepted.
● The proposer prepares the proposal number and sends it to the acceptor
● The proposal number is formed based on the timeline, and the biggest number is
considered up to date.

Acceptor1
Prepare
Proposern (Proposal Number) Acceptor2

For example, there are two proposers P1 and P2, and

P1 and P2 proposed values are 100 and 200. The
acceptor always accepts a bigger proposal number, so
Acceptor3
in this case, it is P2 rather than P1.
 Consensus Algorithms for Private Blockchain - PAXOS
Making a Proposal: Acceptor’s Decision Making
● If the received proposal number is less or equal to the already seen or received proposal number,
then it rejects else it accepts. It means the acceptor compares the recently received proposal
number with the currently known values for all proposer’s received messages. If it gets the higher
number, then it accepts; otherwise, it rejects.
 Consensus Algorithms for Private Blockchain - PAXOS
Making a Proposal: Acceptor’s Message
● Acceptor prepares the response, including
○ accept or decline status,
○ biggest proposal number, and
○ accepted values.
The acceptor can either accept or reject a message based on the proposed algorithm. The
acceptor includes the biggest number that the acceptor has seen in the response message.
It also includes the values that the acceptor has accepted to inform the proposer.
 Consensus Algorithms for Private Blockchain - PAXOS
Accepting a value: Proposer’s Decision Making

Majority of YES
Update with latest
Proposern acceptors reject
proposal number
the proposal?

NO

Majority of
YES NO
Proposer’s value acceptors
Send accept message
can’t be chosen accept the
proposal?
 Consensus Algorithms for Private Blockchain - RAFT
● The RAFT is designed as an alternative to PAXOS. In the case of PAXOS, there is no leader
node, and so multiple proposers can propose the same thing simultaneously.

● The acceptors must accept one of the proposals and use the highest proposal number used
as a tie-breaking mechanism.

● A specific algorithm is embedded inside PAXOS to ensure that every proposal that is coming
from different proposers is unique.

● This updated version of PAXOS is known as RAFT Consensus Mechanism

 Consensus Algorithms for Private Blockchain - RAFT
● RAFT will first elect a leader, and once it has elected a leader, then the task of the leader is to
propose something. There would be a single proposer (leader), and all the accepters are
followers of the leader. When the leader is proposes, the acceptors (followers) may or may
not follow the leader

● The basic idea behind the RAFT consensus protocol is that the nodes collectively select a
leader, and the leader is responsible for state transition.
 Consensus Algorithms for Private Blockchain - RAFT

✓ Whenever the system starts up, it automatically has a set of follower nodes.

✓ The follower nodes check whether there is already a leader or not. If the node times out, that means there is
no leader in the system, and you start the election.

✓ In the election, you choose the candidates from among a group of volunteers who want to be a leader.
Servers select the leader through voting. Whoever wins the majority of the votes becomes the leader.

✓ The leader finds out the proposed value. Then either the followers can vote for the proposal coming from the
leader, or they can choose to go against the leader.
 RAFT Consensus in Transaction
1. How to elect a Leader: The first part of the Raft is to elect a leader, and for that, there
should be some leader candidates. The nodes sense the network, and if there is no leader
candidate, then one of the nodes will announce that I want to be a leader. The leader
candidate requests the votes. This voting request contains 2 parameters:
1. Term Parameter: Just like PAXOS, the RAFT algorithm also runs in rounds. In every round, you need to
take a decision. The term parameter denotes the particular round you are currently in. Assuming the old
term is numbered as (20), the new term (21) is calculated by adding one to the old term (20).
{The last calculated number known to candidate + 1.}

2. Index Parameter: Committed transactions available to the candidate.

2. Failure of the Current Leader:

RAFT: Leader candidate request for votes to nodes : Term Check

RAFT: Leader candidate request for votes to nodes : Term & Index Check
RAFT: Majority voting check
 RAFT Consensus in Transaction
2. Failure of the Current Leader: Assume a leader has three followers, the
current term is 10, and the committed index is 100
A new leader needs to be elected with the new term 11, which is the old term
number plus one; that means you need to move from Round 10 to Round 11.
NEW

At this particular time, let us say

Leader
the old leader recovers

Case 1 arises

FAILED
Case 1 (Diagrammatic Representation)
 Case 2 (Diagrammatic Representation)
Case 2 arises when two nodes (Leader Candidate 1 and Leader Candidate 2) send the
request for vote message at the same time. The entire system currently stays in Term
10. Therefore, at the Term 10, there are two leader candidates who send a request vote
for round 11. Voting happens, and they look for the majority voting.
Committing Entry Log
● Once the leader election is done, the leader has the
task to propose a new transaction.

● Every node is now at Round 11; that means Term 11

and the last committed transaction index is 100.
Now if the leader wants to propose a new
transaction, it acts as an entry log with Term 11, the
current term where everyone is, and the new
transaction index has index 101.

● Therefore, this particular entry is done in the index

log of the leader. Then the leader sends a message
called append entries (11,101) to all the followers

● Once this particular transaction log is broadcast to all

the followers, the followers collectively vote either for
the transaction or against the transaction
● If the leader receives majority votes for the transaction 101, it means that a majority
of the nodes are okay with committing that particular log (101). The leader sends an
accept message based on the majority voting to all the individual followers.
Therefore, the followers update the committed index to 101.
 Byzantine Faults: Byzantine Fault Tolerant (BFT)
● The byzantine fault came from a new problem called byzantine general problem

● If the leader behaves in a byzantine way (strange way), that is, if the leader proposes
a transaction only to a selective number of nodes among all followers, the PAXOS
and the RAFT protocol may not help.

● In that case, we need to have a strict class of consensus algorithm that can tolerate
the byzantine fault, and that consensus algorithm is called as byzantine fault
consensus algorithm
In byzantine fault, a node (leader) starts behaving maliciously; it sends different
messages to different peers (followers). The general (leader) sends an attack message
to one troop, whereas he sends a retreat message to another troop. If the general
(leader) becomes faulty, then it becomes difficult for a system to determine what to do.
Therefore, we will try to develop a fault-tolerant architecture, where the system will be
able to tolerate this kind of byzantine faults.
Three Byzantine Problem

Lieutenant Faulty
Three Byzantine Generals Problem: Commander Faulty
Four Byzantine Generals Problem: Lieutenant Faulty
Four Byzantine Generals Problem: Commander Faulty
 Byzantine Generals Model
● If we look into the usual byzantine general problem with an f-number of faulty nodes,
then we need to ensure that there is a minimum of 2f + 1 number of correct
lieutenants in total in the system to correctly apply the majority voting principle and
find out the byzantine nodes in the system.

● Moreover, if the commander is faulty, the consensus is decided based on the

majority value proposed by the lieutenants using the four byzantine generals model.
If there are N number of processes out of which at most f number of the processes
can be faulty, it has to be ensured that we have 2f + 1 number of lieutenants in the
system. The receiver always knows the identity of the sender.

● This is a closed model and in the context of blockchain technology, this model helps
us to design an algorithm for the permissioned blockchain environment. The system
is fully connected, the communication is reliable, and the system is synchronous.
 Practical BFT
● Miguel Castro and Barbara Liskov at the MIT Laboratory introduced practical
Byzantine Fault Tolerance (pBFT) for Computer Science in 1999. It is considered as
one of the potential solutions to the Byzantine Generals’ Problem.

● Here, the goal is to decide whether to accept a piece of information submitted to

the blockchain or not.

● It tolerates “byzantine faults” based on the assumption that the number of

malicious nodes in the network cannot simultaneously equal or exceed ⅓ of the
overall nodes in the system in a given window of vulnerability.
 Practical BFT
● It works on the format of the Byzantine Generals’ Problem, where all “generals” (nodes) are
considered equal and take their work instruction from the “leader” node.

● The leader node is the primary node, and all other nodes are called secondary or backup nodes.

● The leader is selected at random in a round-robin fashion. A node “client” sends a request for a
change or transaction to the leader. The leader, in turn, broadcasts it to all the backup nodes.

● The leader and backup nodes will use the message with their internal state to run computation and
transmit the decision result to all the client nodes.

● The final decision of acceptance or rejection of the transaction is arrived at based on the agreement
of the majority.

● A high hash rate is not required as pBFT relies on the minimum number of backup nodes to confirm
trust, namely (f + 1), where f represents the maximum number of faulty nodes. Hence it is not
computationally intensive, and therefor results in substantial energy saving.
 Practical BFT - Disadvantages
1) Small group sizes – Due to the amount of communication required between all the
nodes, this model works best with small group networks for better response times.

2) Sybil attacks – A single party can assume some identities or nodes and manipulate
the network. This is mitigated with larger network sizes, but scalability and
throughput will be compromised.

3) Stellar, Ripple, and Hyperledger are some blockchains that use variants of the Pbft
consensus mechanism algorithm.
Introduction to Hyperledger
● Hyperledger is an open-source project under the Linux Foundation where people can
come and work on the platform to develop blockchain-related use cases.

● According to Brian Behlendorf, executive director of Hyperledger, “Hyperledger is an

open source community of communities to benefit an ecosystem of hyperledger based
solution providers and users focused on blockchain related use-cases that will work on
variety of industrial sectors”.
Introduction to Hyperledger
● Hyperledger is an umbrella of open source projects and tools which is managed by
Linux foundation which started in December 2015.

● Hyperledger provides the platform to create personalized blockchain services

according to the need of business work.

● Unlike other platforms for developing blockchain-based software, Hyperledger has

the advantage of creating a secured and personalized blockchain network.
● It is created to support the development of blockchain-based distributed ledgers.
● It includes a variety of enterprise-ready permissioned blockchain platforms.
● It is a global collaboration for developing high-performance and reliable blockchain and
distributed ledger-based technology frameworks.
Why Do We Need Hyperledger?
Below are some of the reasons stating the need for a hyperledger project:
• To enhance the efficiency, performance, and transactions of various business
processes.
• It provides the necessary infrastructure and standards for developing various
blockchain-based systems and applications for industrial use.
• It gets rid of the complex nature of contractual agreements, as the legal issues
are taken care of.
• Hyperledger offers the physical separation of sensitive data.
• It decreases the need for verification and enhances trust, thus optimizing network
performance and scalability.
Hyperledger Technology Layers
Hyperledger uses the following key business components:

● Consensus layer: It takes care of creating an agreement on the order and

confirming the correctness of the set of transactions that constitute a block.
● Smart layer: This layer is responsible for processing transaction requests and
authorizing valid transactions.
● Communication layer: It takes care of peer-to-peer message transport.
● Identity management services: these are important for establishing trust on the
blockchain.
● API: It enables external applications and clients to interface with the blockchain.
Hyperledger Frameworks
1. Hyperledger Fabric: Hyperledger Fabric is a permissioned Blockchain infrastructure
that features a modular architecture wherein there’s a delineation of roles between the
nodes in the infrastructure, the execution of smart contracts, along with configurable
consensus and membership services. Fabric was the result of a joint venture of IBM and
Digital Asset. It was primarily developed as an integration framework for developing highly
scalable Blockchain apps with DLT.

In a Fabric network, the “peer nodes” execute chaincode (smart contracts), access ledger
data, endorse transactions, and interface with applications, whereas the “orderer nodes”
handle the consistency of the Blockchain and deliver the approved transactions to the
peers of the network.
Hyperledger Frameworks
2. Hyperledger Burrow
Burrow is a Hyperledger Project hosted by the Linux Foundation. It allows a modular Blockchain
client to develop permissible smart contract machine that has the specification of EVM
(Ethereum Virtual Machine).

Thanks to its proof-of-stake consensus engine, Burrow promises to deliver high transaction
throughput and transaction finality. The components of Burrow include a consensus engine,
smart contract application, application Blockchain interface, application binary interface, and
API gateway.
Hyperledger Frameworks
3. Hyperledger Indy
Hyperledger Indy is a distributed ledger that was designed with a decentralized identity in mind.
It includes a range of libraries, reusable components, and tools that let you create digital
identities on a Blockchain network.

Indy provides a robust and secure ecosystem for private digital identity. Instead of storing a
user’s private data on the ledger, Indy uses Blockchain technology to allow third parties to
validate that trusted organizations have issued private credentials or identities. By doing so,
Indy gives more control to users of their private data, thereby safeguarding their information
from malicious attacks and data breaches.
Hyperledger Frameworks
4. Hyperledger Sawtooth
Sawtooth is a Hyperledger project that was initially contributed by Intel. It is an enterprise
blockchain platform designed for developing distributed ledger networks and applications. Its
design is such that it isolates the core system from the app domain, thereby ensuring the
complete safety of smart contracts. A unique feature of Sawtooth is its dynamic consensus
feature that facilitates hot-swapping consensus algorithms in a running network. Sawtooth
supports Ethereum Contract Compatibility with Seth (Sawtooth-Ethereum integration project).

Sawtooth has an advanced parallel scheduler that divides transactions into parallel flows. By
executing transactions in parallel, Sawtooth prevents double-spending while also allowing
different modifications to the same state. Furthermore, parallel transaction execution delivers
better performance than serial execution.
Hyperledger Frameworks
5. Hyperledger Grid
Grid is Hyperledger’s supply-chain solution. Since the supply chain is one of the best use
cases for DLT, Grid was designed to solve supply chain challenges. Interestingly enough,
Grid is not a Blockchain framework or an application. In essence, it is an ecosystem of
frameworks, libraries, and technologies that allow developers to choose appropriate
components for building specific business models.

Grid features shared capabilities to boost the development process of distributed ledgers
for cross-industry supply chain solutions. It provides reference implementations of supply
chain-based data types, smart contract-based business logic, and data models that uphold
the best industry practices and standards.
Hyperledger Tools
1. Hyperledger Caliper: Caliper is a Blockchain tool hosted by the Linux Foundation. It
lets you compute the performance of specific Blockchain implementations by leveraging a set
of predefined use cases. Caliper can also generate reports on different performance factors,
including resource utilization, transaction latency, and transactions per second (TPS).

2. Hyperledger Cello: Cello is a Blockchain module toolkit. It is essentially an on-demand

“as-a-service” deployment model developed for the Blockchain ecosystem. Cello provides a
multi-tenant chain service that can work on top of multiple infrastructures, including container
platforms and virtual machines. It reduces the efforts required to build, maintain, and
terminate blockchains.
Hyperledger Tools
3. Hyperledger Explorer: Hyperledger Explorer is a Blockchain module explicitly designed
for developing user-driven web applications. It can be used for viewing, deploying,
invoking/querying blocks, network information, transaction data, chaincodes, and other
relevant data that is stored in a Blockchain ledger.

4. Hyperledger Composer: Composer is both a development framework and toolkit designed

to make the development of Blockchain applications and smart contracts more seamless and
convenient. You can use Composer to develop and deploy Blockchain applications rapidly. It
leverages tools like Node.js, CLI, NPM, etc., to provide business-focused abstractions, sample
apps, and easy-to-test DevOps processes.
Hyperledger Tools
5.Hyperledger Quilt: Quilt is a one of the business Blockchain tools that aims to facilitate
interoperability between ledger systems by implementing the Interledger protocol (ILP),
which is a payments protocol used for moving value across both distributed and non-
distributed ledgers. Thanks to ILP, Quilt can also enable atomic swaps between a single
account namespace for accounts and ledgers.

6. Hyperledger Ursa: Ursa is a shared cryptographic library that prevents the replication of
cryptographic work, thereby increasing the overall security of the Blockchain network. The
two primary components of Ursa are the Base-Crypto library and Z-Mix.
Hyperledger Fabric
● Hyperledger Fabric is a permissioned blockchain framework, intended for
developing applications or solutions with a modular architecture.

● Hyperledger Fabric allows components, such as consensus and membership

services, to be plug-and-play. Its modular and versatile design satisfies a broad
range of industry use cases. It offers a unique approach to consensus that enables
performance at scale while preserving privacy.

● Hyperledger Fabric is release under the Linux Foundation. It is a collaborative

effort to advance blockchain technology by identifying and addressing important
features for a cross-industry open standard for distributed ledgers that can
transform the way business transactions are conducted globally.
Hyperledger Fabric – Transaction Flow

Here when clients submit the transaction proposal through the Fabric SDK, this proposal is sent to all
Endorsing Peers. These endorsing peers check the transaction verifies and executes and generate the
Read and Write set as output. Now, this response is again sent to the client. The client collects all
responses from all endorsing peers, and send them to Orderer. Now, Orderer sees all transactions and
orders them in ascending order and form a block. Now, this block is sent to all committers which checks
the transaction and add a new block in their own copy of the ledger.
Hyperledger Fabric Architecture
Provides identity to users who are going to be
transacting on blockchain. This identity is going
Client to be a digital certificate, which is used by users
applications to sign transaction
are provided Issues Issues
Fabric implements
with SDK’s to Digital Digital
Certificate Certificate
interact with
blockchain

Endorsing
peers endorses the
transactions

Committing
peers to validate
the entire block by
referring to the
endorsement policy
Ordering service order all the received of individual
transaction and
transactions and construct a block commit the block
into the ledger.
 Components of Hyperledger Fabric
MSP, Chain Codes, Transaction Flow
● Membership Service Provider (MSP): It manages the identities of users within an
organization, which includes the generation of public and private key pairs, assigning of credentials
based on the roles, getting the public key identity signed certificate (Digital Signature) from the
Certificate Authority (CA), revocation of users, and secure storage of keys, etc. These digital
certificates are used by the uses and peers node to sign the transactions and submit them to the
blockchain. The advantage of signing these transactions is that they are legitimate users first, and
second, they have proper access privilege to perform the operations.

● Certificate Authority: It issues certificates (x.509) to the users. There are two ways to manage
Certificate Authority in the hyperledger fabric. The first is to use an inbuilt CA service called Fabric-
CA. The second way is to link the external CA. The CA facilitates the Membership services module
to manage certificates, which includes signing and revocation of certificates.
 Components of Hyperledger Fabric
MSP, Chain Codes, Transaction Flow
● Client Application: The client application initiates a transaction request and submits it to the peer
nodes. The client application can be written in any language of developer choice. However, it uses
SDK to communicate with hyperledger fabric, and the SDK is usually called hyperledger fabric client.

● Ordering Service: The ordering service receives transaction records from the clients, collects all the
transactions for a certain duration, orders these transactions based on the ordering algorithm, and
constructs a block. Later, this block will be sent to all the connected peer nodes for verification and
permanent addition to the shared ledger of hyperledger fabric.

○ Ordering Node: Approves the inclusion of transaction blocks into the ledger and communicates
with committing and endorsing peer nodes. However, it does not hold any smart contracts and
ledger. The ordering nodes ensure that all the transactions are totally ordered. Every node in the
network commits the same transactions in the same order and maintains consistency across the
entire network.
 Components of Hyperledger Fabric
MSP, Chain Codes, Transaction Flow
● Peer: A Peer node represents a computer server type of system, which runs hyperledger fabric
packages, and performs specific operations. The entire permissioned blockchain network
consists of multiple organizations, and individual organizations may run multiple peers. The
major advantage of running multiple peers within an organization to handle fault
tolerance. There are mainly two types of peer nodes, endorsing and committing peer. However,
it may be possible that some peer nodes have both the endorsing and committing functionalities,
while others may have just a committing functionality.

• Committing Peer: It verifies the block received from the ordering service node and commits to
the ledger. It maintains the ledger and the state but does not execute any transactions but may
hold smart contracts or chaincode.

• Endorsing Peer: A specialized peer who receives a transaction proposal for endorsement
responds granting or denying endorsement, and it must hold the smart contract.
Working of Hyperledger Fabric
● The client application creates a new transaction request, signs it, submits it to the
connected endorsing peers.

● The endorsing peers receive the transaction request, validate the signature, execute
the smart contract or chaincode only if the signature is valid, put their signature on
the execution result, i.e., read-write set, and send it to the client application.

● The endorsing peers must possess smart contracts and endorsement policy. These
artifacts will be fed during the setup of the hyperledger fabric network.

● The client receives endorsements from peers. It checks the policy, and if the policy
satisfies, it sends the transaction to the ordering service in the same format in which
it accepts. An example of a policy for acceptance criteria, out of five endorsers
minimum of three endorsers’ results must be the same.
Working of Hyperledger Fabric
● The ordering service collects all the transactions from the different clients for a
certain duration which resides across the entire blockchain network. Runs the
ordering algorithm and puts received transactions into an order. However, it
does not validate the transactions. Later, the ordering service signs the newly
generated block and sends it to all the committing peers across the network.

● The committing peers validate the signature on the received block. If valid, then
these peers verify each transaction from the received block by referring to the
respective transaction endorsement policy. These peers verify each of the
transactions and mark them as valid or invalid. This helps the event service
routing to trigger or inform the client about the transaction status rather than
removing invalid transactions from the block. Later, these peers commit the new
block to the ledger of hyperledger fabric.
Working of Hyperledger Fabric
● The ordering service collects all the transactions from the different clients for a
certain duration which resides across the entire blockchain network. Runs the
ordering algorithm and puts received transactions into an order. However, it
does not validate the transactions. Later, the ordering service signs the newly
generated block and sends it to all the committing peers across the network.

● The committing peers validate the signature on the received block. If valid, then
these peers verify each transaction from the received block by referring to the
respective transaction endorsement policy. These peers verify each of the
transactions and mark them as valid or invalid. Later, these peers commit the
new block to the ledger of hyperledger fabric.

● In the end, the client receives an event, and it takes appropriate action based on
the status of the transaction.
Transaction Flow In Hyperledger
● Example: There are five peer nodes in this example, and an application submits a
transaction proposal for Smart Contract A. The endorsement policy says three
peers must sign the transaction output, and the results must be the same. The
client can consider that transaction as valid and forward it to the ordering service.

The key components are mentioned in the below

diagram with different color square boxes such as
1. Endorser,
2. Committing Peer,
3. Ordering Node,
4. Smart Contract or Chaincode,
5. Application and Endorsement Policy.
Transaction Flow In Hyperledger
Step 1/7: Client Proposed Transaction

In this step, a client proposes a transaction by

mentioning its identity, appropriate function
name(s) with input parameters to be executed
from a particular smart contract, and send it to
all the endorsing peer nodes. The smart
contracts will be available with all the endorsing
peer nodes. In this example, E0, E1 & E2 are
endorsing peers.
Transaction Flow In Hyperledger
Step 2/7: Execute Proposed Transaction

These peer nodes E0, E1 & E2 will

execute the transaction independently.
However, non of these executions will
update the ledger. The execution will
capture the set of Read, and Written data,
called RW set, and these RW sets will be
signed by each endorser.
Transaction Flow In Hyperledger
Step 3/7: Proposal Response

The endorses securely communicate back

to the client with payload as the RW set,
signature, and other metadata. The client
receives these responses asynchronously,
which means the response may arrive in
any random order. This information will
be checked much later in the consensus
process.
Transaction Flow In Hyperledger
Step 4/7: Deliver Transaction
The client application checks the
responses received from the endorsing
peers and tries to check the satisfaction
criteria of the endorsement policy. For
example, in this case, the policy says E0,
E1, & E2 all must endorse, and their RW
set must be the same. If it satisfies, then
the client submits the transaction to the
ordering service. These kinds of
submissions can happen simultaneously
from multiple client applications across
the network.
Ordering happens across the fabric in parallel with transactions submitted by other
applications. The ordering service orders these transactions and ensures that
every peer node in the network sees the same order.
Transaction Flow In Hyperledger
Step 5/7: Deliver Transaction
The ordering service delivers an ordered
set of transactions called a block to all the
committing peers across the network. It
works as follows: The peer nodes will
deliver to other peers in a hierarchy. We
can say that ordering service broadcasts
the newly formed block to the entire
network in a simple term.

There are different ordering algorithms available such as

•SOLO (Single node, development)
•Kafka (Crash Fault Tolerance)
•Practical Byzantine Fault Tolerance Algorithm
•Raft Algorithm
Transaction Flow In Hyperledger
Step 6/7: Validate Transaction

All of these committing peers have received a block of transactions from the ordering services,
but all of these transactions may not be valid for the following reasons:
• By mistake, the client is malicious or, by mistake, submitted a transaction that hasn’t
received sufficient endorsements from the endorsing peers.
• Two transactions simultaneously trying to update or refer to the same state variable within a
block may create inconsistency.
Every committing peer validates against the endorsement policy. Also, check RW sets are still
valid for the current world state. The validated transactions are applied to the world state and
retained on the ledger. However, the invalid transactions are also retained on the ledger but do
not update the world state.
Step 6/7: Validate Transaction
Transaction Flow In Hyperledger
Step 7/7: Notify Transaction
Once a newly created block is verified successfully by the committing peers and appended into
the blockchain, the committing peers notify client applications. Every client receives the
notification. However, clients can configure the notification setting according to the needs.
These events notification can be configured for block-level or individual transaction level by the
clients.

Even specific event notification mechanisms can be written in smart contracts, which gives
more flexibility to the users to integrate hyperledger fabric applications into the external
processes.
Step 7/7: Notify Transaction