What is Hyperledger Fabric?

It is a private and permissioned Blockchain system which means Unlike, in Permissionless(or

public network) systems that allow unknown identities to participate in the network, the
members enroll through Membership Service Provider (MSP).

It also offers the ability to create channels, allowing a group of participants to create a separate
ledger of transactions.

Since Fabric is the permissioned Blockchain it has some major advantages over other blockchain
systems.

Hyperledger Fabric is a permissioned blockchain framework, with a modular architecture (plug-

and-play). It leverages container technology to host smart contract (Chaincode) which contains
application logic.

This is a high-level transaction flow and basic components involved.

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.
Fabric consist of below major components

 Membership Service Provider(MSP)

 Client
 Peer
 Orderer

Membership Service Provider (MSP)

The membership service provider (MSP), is a component that defines the rules in which,
identities are validated, authenticated, and allowed access to a network. The MSP manages user
IDs and authenticates clients who want to join the network. This includes providing credentials
for these clients to propose transactions. The MSP makes use of a Certificate Authority, which is
a pluggable interface that verifies and revokes user certificates upon confirmed identity. The
default interface used for the MSP is the Fabric-CA API. However, organizations can implement
an External Certificate Authority of their choice. As a result, a single Hyperledger Fabric
network can be controlled by multiple MSPs, where each organization brings its own favorite.

There are two types of MSPs.

Local MSP: It defines users(Clients) and nodes(peers, orderers). It defines who has
administrative or participatory rights at that level.

Channel MSP: It defines administrative and participatory rights at the channel level.

Client
Clients are applications that act on behalf of a person to propose transactions on the network.
The client uses a Fabric SDK in order to communicate with the network. The client
communicates with the SDK in order to Read or Write the data in a Fabric blockchain and an in-
state DB. Even the client is issued with a certificate from the CA authority in order to make sure
that a valid client has initiated the transaction over the network.

Nodes
A ―Node‖ is only a logical function in the sense that multiple nodes of different types can run on
the same physical server. What counts is how nodes are grouped in ―trust domains‖ and
associated with logical entities that control them.
There are three types of nodes:

Client: A client that submits an actual transaction-invocation to the endorsers, and

broadcasts transaction-proposals to ordering service. In short, clients communicate with both
peers and the ordering service

Peer: A node that commits transactions and maintains the state and a copy of the ledger. A
peer receives ordered state updates in the form of blocks from the ordering service and maintains
the state and the ledger. Besides, peers can have a special endorser role. The special function of
an endorsing peer occurs with respect to a particular chaincode and consists in endorsing a
transaction before it is committed.

Ordering-service-node or Orderer: a node running the communication service that implements

a delivery guarantee, such as atomic or total order broadcast.

Types of Peers

Endorsing Peer: Endorsing peers is a special type of committing peers who have an
additional role to endorse a transaction. They endorse the transaction request which comes from
the client. Each endorsing peer possesses the copy of smart contract installed and a ledger. The
main function of Endorser is to simulate the transaction. It is executed based on the smart
contract on the personal copy of the ledger, and generates the Read/Write sets which are sent to
Client. Though during simulation, the transaction is not committed to the ledger.

Committing Peer: Peers who commit the block which is received from the Ordering
service, in their own copy of the blockchain. This block contains the list of transactions where
committing peer to validate each transaction and mark it as either valid or invalid and commits to
the block. All transaction either valid or invalid are all committed to blockchain for future audit
purpose.

Anchor Peer: As Fabric network can extend across multiple organization, we need some
peers to have communication across an organization. Not all peers can do this, but these are
special peers who are only authorized to do so which are nothing but Anchor peer. The anchor
peers are defined in Channel configuration.

Leading Peer: Leader peers are those who communicate or disseminate messages from
Ordering service to other peers in the same organization. These peers use Gossip protocol to
make sure that every peer receives the message. Leading peers cannot communicate across an
organization. If any Leading peer is not responding or is out of network, then we can select a
leading peer from available peer based on voting or randomly choose one.
Orderer
In a Blockchain network, transactions have to be written to the shared ledger in a consistent
order. The order of transactions has to be established to ensure that the updates to the world state
are valid when they are committed to the network. Unlike the Bitcoin blockchain, where ordering
occurs through the solving of a cryptographic puzzle, or mining. Hyperledger Fabric allows the
organizations running the network to choose the ordering mechanism that best suits that network.
This modularity and flexibility make Hyperledger Fabric incredibly advantageous for enterprise
applications.

Hyperledger Fabric provides three ordering mechanisms: SOLO, Kafka, and Simplified
Byzantine Fault Tolerance (SBFT), the latter of which has not yet been implemented in Fabric
v1.0.

SOLO
It is the Hyperledger Fabric ordering mechanism most typically used by developers
experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node. In this,
the transactions are ordered in chronological order to form a block.

Kafka
It is the Hyperledger Fabric ordering mechanism that is recommended for production use. This
ordering mechanism utilizes Apache Kafka, an open source stream processing platform that
provides a unified, high-throughput, low-latency platform for handling real-time data feeds. In
this case, the data consists of endorsed transactions and RW sets. The Kafka mechanism provides
a crash fault-tolerant solution to ordering service.

SBFT
It stands for Simplified Byzantine Fault Tolerance. This ordering mechanism is both crash
fault-tolerant and byzantine fault-tolerant, meaning that it can reach agreement even in the
presence of malicious or faulty nodes. The Hyperledger Fabric community has not yet
implemented this mechanism, but it is on their roadmap.

These three ordering mechanisms provide alternate methodologies for agreeing on the order of
transactions.

Other components which are part of the network and yet very important to understand are as
below
Channels

A fabric network can have multiple channels. Channels allow organizations to utilize the same
network while maintaining separation between multiple blockchains. Only members(peers) of
the channels are allowed to see the transaction created by any member in a channel. In other
words, channels partition the network in order to allow transaction visibility for stakeholders
only. Only the members of the channel are involved in consensus, while other members of the
network do not see the transactions on the channel. The peer can maintain multiple ledgers. And
peer can be connected to multiple channels.

Blue ledger is maintained by P1 and P3, whereas Orange Ledger is maintained by P2 and P4,
but black ledger is maintained by P1, P2, P3 and P4.

The configuration of the channel is maintained by configtx.yaml file. Using this file we generate
channel.tx file and then create a channel using it. Chaincode is installed on all participating peers
in a channel, where as chaincode is instantiated on a channel. A channel contains all the
configurations of communication between peers. It holds the list of peers along with who are
endorsing, anchor, leader peers. When a client communicates with the network using SDK, the
SDK first gets a list of all endorsing peers to which the transaction request needs to send. Using
this list the SDK sends transaction requests to peers. Peers that do participate in multiple
channels simulate and commit transactions to different ledgers. Orderers are also a part of
channels.

Identity
Each actors in a network peer, orderer, client, admin have some digital identity in the form of
certificate X.509. This identity is used to verify at each and every step of a transaction, in order
to check if the source of the transaction is from a valid source. In addition to the multitude of
endorsement, validity, and versioning checks that take place, there are also ongoing identity
verification happening during each step of the transaction flow.
 Policies
Policies reside in the Channel configuration, but in some cases, it resides in chaincode too. To
define, a policy is a function which accepts as input a set of signed data and evaluates
successfully or returns an error because some aspect of the signed data did not satisfy the policy.
More concretely, policies test whether the signer or signers of some data meet some condition
required for those signatures to be considered ‗valid‘.

There are two types of policies

Signature Policy: It is powerful and specifies policy as a combination of evaluation of rules for
MSP principles. It supports a combination of AND, OR and NOutOf.

Implicit Meta policy: This is less flexible and only valid in context for configuration. It
aggregates the result of evaluating policies deeper in the configuration hierarchy, which are
ultimately defined by SignaturePolicies.

Ledger
It is a current state of the business as a journal of transaction. A ledger consists of two different
parts, a world state, and a blockchain. A ledger is kept at all peers and, optionally, at a subset of
orderers. In the context of an orderer, we refer to the Ledger as to OrdererLedger, whereas in the
context of a peer we refer to the ledger as to PeerLedger. PeerLedger differs from the
OrdererLedger in that peers locally maintain a bitmask that tells apart valid transactions from
invalid ones.

Ledger consists of W-World State and B-Blockchain.

The two different part of Ledger are :

World State: Each chaincode has its own World state and blockchain. It is a DB that holds the
current state of the ledger state. These states are expressed as key-value pairs. It holds the fact of
a business object. It can be created, update and delete. When application submits the transaction,
and when it comes to committing the valid transaction, it first commits in the World state and
then it is updated in ledger. State also has a version number. This version number changes each
time the state is updated. When a ledger is created the world state is empty, as any transaction
which represents a valid change in world state is recorded in blockchain too. This means world
state can be generated at any time from the blockchain. The state is maintained by Peers only.

Blockchain: A transaction log that records all the changes that have resulted in the current
world state. Its data structure is different as once written cannot be removed. It is immutable. It is
a historical record of facts about how the objects arrived at the current state. It is structured as a
sequential log of interlinked blocks, where each block contains a sequence of transactions, each
transaction representing a query or update to the world state.

Each block header includes a hash of blocks transactions, as well as a copy of a hash of the
previous block‘s header. Blockchain is always implemented as a file, not like that of the world
state which uses database. The first block in the chain is the genesis block. Though this is a
starting point of the ledger. It does not contain any transaction details. Instead, it contains
configuration transaction details containing initial state of the network channel.

Blockchain, the previous block is referenced by the current block.

Block‘s main sections.

Header: This consists of 3 fields

Block number: An integer starting from 0, the genesis block, and incremented by 1 for
each new block appended.

Current Block Hash: Hash of all transactions contained in a block

Previous Block Hash: Hash of the previous block.

Data: This consists of a list of transactions arranged in order.

Metadata: It contains time when the block was written, certificate, public key and
signature of block writer. A block committer also adds a valid/invalid indicator for every
transaction. This information is not included in the hash of the block

Each Transaction in a block consists of

Header: Contains essential metadata about the transaction. For example, Name of relevant
chaincode and its version.

Signature: Contains cryptographic signature created by the client application. It is used to

check if the transaction details have not been tampered and require application private key to
generate it.

Proposal: Encodes input parameters supplied by application to the smart contract which
creates proposed ledger update. When the smart contract runs, this proposal provides a set of
input parameters, which, in combination with the current world state, determines the new world
state.

Response: It captures before and after values of world state as Read/Write (RW) set. It is the
output of the smart contract.

Endorsement: This is the list of signed transaction responses from each required organization
sufficient to satisfy the endorsement policy. So here for one transaction proposal, we have
multiple endorsement responses.
Chaincode
A smart contract defines the transaction logic that controls the lifecycle of a business object
contained in the world state. It is then packaged into the chaincode which is deployed to the
blockchain network. Smart contracts are defined within chaincode. Multiple smart contracts can
be defined within a single chaincode. When a chaincode is deployed, all smart contracts
available within the chaincode is made available to the application. We can see that a smart
contract is a domain specific program which relates to specific business processes, whereas a
chaincode is a technical container of a group of related smart contracts for installation and
instantiation. Every chaincode has endorsement policy attached to it, which applies to every
smart contract defined within it. This identifies which organization must sign a transaction
generated by Smart contract, in order to consider it valid. So, in short, every smart contract has
an endorsement policy attached to it. A smart contract can call other smart contracts within a
channel or across different channels.

Cloud Computing
Cloud computing transforms IT infrastructure into a utility: It lets you ‗plug into' infrastructure
via the internet, and use computing resources without installing and maintaining them on-
premises.

What is cloud computing?

Cloud computing is on-demand access, via the internet, to computing resources—applications,
servers (physical servers and virtual servers), data storage, development tools, networking
capabilities, and more—hosted at a remote data center managed by a cloud services provider (or
CSP). The CSP makes these resources available for a monthly subscription fee or bills them
according to usage.

Compared to traditional on-premises IT, and depending on the cloud services you select, cloud
computing helps do the following:
Lower IT costs: Cloud lets you offload some or most of the costs and effort of purchasing,
installing, configuring, and managing your own on-premises infrastructure.

Improve agility and time-to-value: With cloud, your organization can start using enterprise
applications in minutes, instead of waiting weeks or months for IT to respond to a request,
purchase and configure supporting hardware, and install software. Cloud also lets you empower
certain users—specifically developers and data scientists—to help themselves to software and
support infrastructure.

Scale more easily and cost-effectively: Cloud provides elasticity—instead of purchasing

excess capacity that sits unused during slow periods, you can scale capacity up and down in
response to spikes and dips in traffic. You can also take advantage of your cloud provider‘s
global network to spread your applications closer to users around the world.

The term ‗cloud computing‘ also refers to the technology that makes cloud work. This includes
some form of virtualized IT infrastructure—servers, operating system software, networking, and
other infrastructure that‘s abstracted, using special software, so that it can be pooled and divided
irrespective of physical hardware boundaries. For example, a single hardware server can be
divided into multiple virtual servers.

Virtualization enables cloud providers to make maximum use of their data center resources. Not
surprisingly, many corporations have adopted the cloud delivery model for their on-premises
infrastructure so they can realize maximum utilization and cost savings vs. traditional IT
infrastructure and offer the same self-service and agility to their end-users.

Cloud computing services

IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service) , and SaaS (Software-as-a-
Service) are the three most common models of cloud services, and it‘s not uncommon for an
organization to use all three. However, there is often confusion among the three and what‘s
included with each:
SaaS (Software-as-a-Service)
SaaS—also known as cloud-based software or cloud applications—is application software that‘s
hosted in the cloud and that you access and use via a web browser, a dedicated desktop client, or
an API that integrates with your desktop or mobile operating system. In most cases, SaaS users
pay a monthly or annual subscription fee; some may offer ‗pay-as-you-go‘ pricing based on your
actual usage.

In addition to the cost savings, time-to-value, and scalability benefits of cloud, SaaS offers the
following:

Automatic upgrades: With SaaS, you take advantage of new features as soon as the provider adds
them, without having to orchestrate an on-premises upgrade.

Protection from data loss: Because your application data is in the cloud, with the application, you
don‘t lose data if your device crashes or breaks.

SaaS is the primary delivery model for most commercial software today—there are hundreds of
thousands of SaaS solutions available, from the most focused industry and departmental
applications, to powerful enterprise software database and AI (artificial intelligence) software.

PaaS (Platform-as-a-Service)
PaaS provides software developers with on-demand platform—hardware, complete software
stack, infrastructure, and even development tools—for running, developing, and managing
applications without the cost, complexity, and inflexibility of maintaining that platform on-
premises.

With PaaS, the cloud provider hosts everything—servers, networks, storage, operating system
software, middleware, databases—at their data center. Developers simply pick from a menu to
‗spin up‘ servers and environments they need to run, build, test, deploy, maintain, update, and
scale applications.
Today, PaaS is often built around containers, a virtualized compute model one step removed
from virtual servers. Containers virtualize the operating system, enabling developers to package
the application with only the operating system services it needs to run on any platform, without
modification and without need for middleware.

Red Hat OpenShift is a popular PaaS built around Docker containers and Kubernetes, an open
source container orchestration solution that automates deployment, scaling, load balancing, and
more for container-based applications.

IaaS (Infrastructure-as-a-Service)
IaaS provides on-demand access to fundamental computing resources–physical and virtual
servers, networking, and storage—over the internet on a pay-as-you-go basis. IaaS enables end
users to scale and shrink resources on an as-needed basis, reducing the need for high, up-front
capital expenditures or unnecessary on-premises or ‗owned‘ infrastructure and for overbuying
resources to accommodate periodic spikes in usage.

In contrast to SaaS and PaaS (and even newer PaaS computing models such as containers and
serverless), IaaS provides the users with the lowest-level control of computing resources in the
cloud.

IaaS was the most popular cloud computing model when it emerged in the early 2010s. While it
remains the cloud model for many types of workloads, use of SaaS and PaaS is growing at a
much faster rate.

Serverless computing
Serverless computing (also called simply serverless) is a cloud computing model that offloads all
the backend infrastructure management tasks–provisioning, scaling, scheduling, patching—to the
cloud provider, freeing developers to focus all their time and effort on the code and business
logic specific to their applications.
What's more, serverless runs application code on a per-request basis only and scales the
supporting infrastructure up and down automatically in response to the number of requests. With
serverless, customers pay only for the resources being used when the application is running—
they never pay for idle capacity.

FaaS, or Function-as-a-Service, is often confused with serverless computing when, in fact, it's a
subset of serverless. FaaS allows developers to execute portions of application code (called
functions) in response to specific events. Everything besides the code—physical hardware,
virtual machine operating system, and web server software management—is provisioned
automatically by the cloud service provider in real-time as the code executes and is spun back
down once the execution completes. Billing starts when execution starts and stops when
execution stops.