UNIT- IV

Introduction To Hyperledger Fabric

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”.
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.

Example: Consider a situation when person X wants to buy medicine from person Y, who was
a doctor living in another country.
 As medicine requirement is one person’s private needs, they need to maintain the data
confidentially.
 But Dr. Y is selling medicine in the network to so many people, in the case of the
public blockchain, every transaction will get updated in the network to all the peers.
 That’s where hyperledger finds its significance. In the hyperledger, the parties are
directly connected and the concerned people’s ledger will be updated.
 Hence providing privacy and confidentiality.
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 Architecture

1. Consensus Layer:
 Creates an agreement on the ordering and confirms the accuracy of the transaction
database that comprises a block.
 The communication layer is used by the consensus layer to communicate with the client
and other network peers.
 Confirms that all transactions in a proposed block are correct according to approval and
consensus policies.
 Interfaces with the smart-contract layer and relies on it to validate the accuracy of an
ordered transaction database in a block.
 They’re also widely utilized to synchronize data across a decentralized network and
assure transaction consistency and transparency.
2. Smart Contract Layer:
 The smart contract layer verifies each transaction by guaranteeing that it adheres to the
transaction’s policy and contract and invalid transactions are denied and may be removed
from consideration for inclusion in a block.
 Smart contracts are classified into two types:
  installed smart contracts- Before the network is launched, installed smart
contracts implement business logic on the validators.
 On-chain smart contracts– On-chain smart contracts implement business rules
in the form of a transaction that is committed to the blockchain and then invoked
by subsequent transactions. The code that describes the business logic forms
part of the ledger with on-chain smart contracts.
 Responsible for executing transaction requests and determining transaction validity
through the use of business logic.
 In Hyperledger Fabric, a smart contract is a program known as chaincode. Chaincode
can be developed in Go, JavaScript (node. js), and, in the future, additional programming
languages such as Java that define a predefined interface. Chaincode is run in a secure
Docker container that is separate from the endorsing peer process.
3. Communication Layer:
 Communication Layer is in charge of peer-to-peer message transfer between nodes in a
shared ledger instance.
 The communication layer is used by the consensus layer to communicate with the client
and other network peers.
 The algorithm must function exactly like a single node system, executing each
transaction atomically one at a time.
 If communication does not fail, then each non-faulty node will finally get every
submitted transaction.
 TLS is used for secure communication among nodes in the Fabric. TLS communication
can employ both one-way (server only) and 2 different (server and client) authentication.
4. Data Store Abstraction:
 Allows other modules to use alternative data stores.
 the actual private data is kept in a private database on authorized organizations’ peer
nodes and accessed via chaincode on these authorized peers; and a hash of the secret data,
which has been endorsed, sorted, and recorded to the ledgers of every peer on the channel.
 As state databases, the Hyperledger fabric supports LevelDB and
CouchDB. LevelDB is the default state database integrated into the peer activity and stores
chaincode data as key-value pairs.
 CouchDB is an optional external state database that adds query capability when your
chaincode data is modeled as JSON, allowing for rich queries of the JSON content.
 When a deploy transaction succeeds, the chaincode is installed “on” the blockchain.
5. Crypto Abstraction:
 Allows for the substitution of alternative crypto techniques or modules without
disrupting other modules.
 Because Fabtoken, a new functionality in Hyperledger Fabric version 2.0 (alpha),
allows you to generate native cryptocurrencies or coins.
 Besu Hyperledger is a public Ethereum codebase that is open source and may run on
individual permissionless platforms or the Ethereum public network. The Ethereum Virtual
Machines (EVM), consensus mechanisms, user-facing APIs, and monitoring are all
included.
 CPU and GPU mining is supported by Hyperledger Besu and can be enabled using
command-line arguments. Ethminer with both the stratum+tcp and getwork schemes was
utilized for GPU mining support testing.
 It does not support cryptocurrencies such as bitcoin, but it functions by providing the
infrastructure and standards required for the development of various blockchain-based
applications and systems for industrial usage.
6. Identity Service:
 Allows for the formation of a trusted root during the configuration of a blockchain
instance, the enrolment and registration of identities or systems entities during network
operation, and the administration of changes such as drops, additions, and revocations. It
also offers authentication and permission.
 The smart contract layer employs the identity services layer to authenticate and approve
the entity requesting to execute the smart contract while processing the transaction.
 Hyperledger Fabric provides a personal identity service that handles user IDs and
authenticates all network participants to enable permissioned networks. Access control lists
can be utilized to add layers of permission by authorizing certain network actions.
 Certification Authorities are in charge of managing certificates (or CA). Fabric CA is
Hyperledger’s Certification Authority
7. Policy Service:
 Policy Services is in charge of policy management for the system’s numerous policies,
including the endorsement policy, consensus policy, and group management policy. It
communicates with and is dependent on another module to enforce the different policies.
 Fabric policies reflect the process through which members agree to approve or reject
changes to the network, a route, or a smart contract. Policies are agreed upon by channel
members when the channel is first set up, but they can also be changed as the channel
evolves.
 Policies are one of the features that distinguish Hyperledger Fabric from other
blockchains such as Ethereum or Bitcoin. Transactions in those systems can be generated
and confirmed by any node in the network.
8. API: It enables clients and applications to interface with blockchains. there are three types
of API used in hyperledger they are:
 Admin API: This class establishes a management link to a Hyperledger Composer
runtime. The link can then be used to Install BusinessNetworkDefinitions and deactivate
Business network definitions Refresh BusinessNetworkDefinitions and Ping the runtime to
confirm it is up and running and properly configured In the connection profile storage, save
a connection profile document.
 Common API: The Common API comprises the APIs that are used to access
information about the Business Network to which you are connected as well as to establish
new assets, participants, transactions, and events. It also offers APIs for obtaining
information about these resources.
 Runtime API: All transaction functions have access to the Runtime API. It provides
API access to build and issue queries, emit events, retrieve all forms of registries, get the
current participant, and get the serializer to produce resources from JavaScript objects. –
execute HTTP REST calls.
9. Interoperation:
 Allows separate blockchain instances to communicate with one another.
 Interoperability, supported by comprehensive data and transaction standards, is required
to capitalize on this powerful technology. The food industry, for example, has made
 tremendous progress in leveraging data standards to promote food safety and product
visibility use cases.
 Interoperability and integration are currently top-of-mind challenges in the blockchain
sector.
Benefits of Hyperledger Architecture
1. Productivity Enhancement: To accelerate project development, Hyperledger employs
the division of labor technique. It determines everyone’s strong suits and, based on that,
places them in specialized fields.
2. Handling Of Intellectual Property: Hyperledger functions as a blockchain greenhouse
by bringing vendors, developers, and consumers from all around the world together on a
single platform.
3. Data On A Need-To-Know Basis: Data partitioning on the blockchain allows for the
privacy of data pieces. It provides physical isolation of sensitive data. Hyperledger-
supported channels allow data to be distributed exclusively to people that need to know.
4. Rich Querying Capability: It is made up of a key-value database. CouchDB is also an
option. It is a document database that stores content in JSON format. This allows for simple
database queries. Its data model works with the current key/value programming approach.
5. Anonymity: The network only allows signature read-write sets to pass through. This
helps to ensure anonymity because only the users and peers committing the transactions
can see the transactions.

Limitations of Hyperledger Architecture

1. Lack of Developers: It lacks highly qualified programmers due to its origin, whereas
Ethereum has a greater number of developers because of its popularity.
2. Lack of use-cases: It has shown a lack of use cases such that more a lack of awareness
of technology and its possibilities, a scarcity of personnel and skill sets in IT and business.
3. Complex architecture: It has a sophisticated design, while Hyperledger, which is
backed by IT titans, is only focused on enterprise transaction-based [Link]
4. Minimum APK: API allows client apps to communicate with Hyperledger Fabric
blockchain network smart contracts, but with fewer APIs.
5. Less fault tolerance: The job of Byzantine fault tolerance is to ensure that each peer
has the same list of transactions on its ledger, however, it is not suited for network use.

Application of Hyperledger

1. Finance: Hyperledger can be used to streamline the settlement of transactions,

improved liquidity, and provide increased transparency by eliminating the need for
accounts on particular payment systems at a low cost.
2. Healthcare: Hyperledger can be utilized to cut expenses, improve patient care, and
increase data accessibility.
3. Supply Chain: Using Hyperledger, organizations may create initiatives that aim to
limit the prevalence of counterfeit goods while also tracing the provenance of components
and services.
4. Insurance: The Insurance firm can refer to the transaction data recorded in the ledger
using Hyperledger. Hyperledger Fabric may also use chain code to speed up claim
processing and automate payment.
5. Digital payment: Interledger and other Hyperledger applications have the potential to
set new standards in the finance sector. More importantly, it has the potential to
revolutionize two-party cross-border payments.

Hyperledger Technology Layers

Hyperledger uses the following key business components:
1. 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.
2. Smart layer: This layer is responsible for processing transaction requests and
authorizing valid transactions.
3. Communication layer: It takes care of peer-to-peer message transport.
4. Identity management services: these are important for establishing trust on the
blockchain.
5. API: It enables external applications and clients to interface with the blockchain.
How Does Hyperledger Work?
Hyperledger works in a way that a requirement for the contract can be initiated through an
application.
 The membership service involved in the network validates the contract.
 The concerned two-peer has to produce a result and then sent it to the consensus cloud.
 The generated result from both the peer has to be the same in order to validate the
contract.
 Once it is validated, then the transaction will happen between the affiliated peers and
their ledger will be updated.
 When a business requires confidentiality and a private network for its transaction to
happen without doing that in a single network, a hyperledger paves the way.
This can be summarized as the peers who are directly affiliated with the deal are connected and
only their ledgers will get updated about the deal. The third parties who help to carry out the
transaction will only get to know the exact and required amount of information with the help of
regulations levied on the network.
Let’s understand the concept with the help of an example.
 Suppose Alice decides to send the product to Bob on a hyperledger-based network.
 She looks at her app to locate her address of Bob on the network.
 The app in return queries the membership service and validates Bob’s membership.
 The hyperledger will connect both parties directly for the transaction affiliated with the
deal.
 Both parties will generate the result, which has to be the same for them to get validated.
 The result will be sent to the consensus cloud to be ordered and verified.
 Once the result is validated, Bob receives the product and the transaction is committed
to the ledger.
Roles of Peers
In the hyperledger network, the peers are separated into three distinct roles at two-run times.
This distinct feature in this network makes notable changes as it allows a high degree of
personalization. The 3 peer roles are:
1. Committer: Appends validated transactions to their specific ledger. They only add the
transaction to the specific ledger once the transaction is returned by the consenter.
2. Endorser: Endorser nodes are responsible for simulating transactions specific to their
network and preventing unreliable and non-deterministic transactions. All endorsers act as
committers on the other hand committer may or may not be endorsers depending on
network restrictions.
3. Consenter: Their role is to validate the transaction by verifying the result produced by
the affiliated peers who want to proceed with a transaction. Their role is very specific and
runs on separate run times, unlike committers and endorsers who run on the same run time.
Their role is to decide which ledger the transaction be committed to.

Hyperledger Projects
There are numerous projects under hyperledger project itself. These projects include:
1. Hyperledger Fabric: Hyperledger Fabric is intended as a foundation for developing
applications and solutions with modular architecture. It provides many benefits like
permissioned networks, confidential transactions, etc.
2. Hyperledger Sawtooth: It is an open-source project and used as an enterprise-level
blockchain system used for creating and operating distributed ledger applications.
Hyperledger sawtooth supports a variety of consensus algorithms like PBFT, and PoET.
3. Hyperledger Indy: It is a project that is made for decentralized identity. It offers lots
of libraries, tools, and reusable components for creating decentralized identities.
4. Hyperledger Iroha: It is a blockchain platform designed for infrastructure projects that
need distributed ledger technology. It is used to build identity management platforms like
national IDs. It can integrate with Linux, macOS, and Windows platforms.
5. Hyperledger Burrow: It is a framework for executing smart contracts in permissioned
blockchains. The goal of Hyperledger burrow is to facilitate cross-industry applications for
smart contracts. It is built around the BFT consensus algorithm.
6. Hyperledger Caliper: It is a blockchain benchmark tool that allows users to measure
the performance of a blockchain implementation with a set of predefined use cases. It will
produce reports containing a number of performance indicators to serve as a reference when
using the blockchain solutions like Hyperledger Burrow, Hyperledger Fabric, Hyperledger
Iroha, and so on.
7. Hyperledger Cello: It serves as an operational dashboard for Blockchain that reduces
the effort required for creating, managing, and using blockchains. It provides an operational
console for managing blockchain efficiently.
8. Hyperledger Explorer: It is a user-friendly web application tool that is used to view,
invoke, deploy, or query blocks, associated data, and network information stored in the
ledger. It is regarded as an easy way that allows users to view the necessary network
information of the blockchain.
9. Hyperledger Besu: It is an Ethereum client designed to be enterprise-friendly for both
public and private blockchain network use cases. It offers many useful features like EVM,
several proof-of-authority protocols, a privacy transaction manager to ensure the privacy of
transactions, etc.
Transaction Flow in Hyperledger Fabric
Transaction in hyperledger fabric reflects the business activity in the fabric network. Due
ensure data immutability the transactions are kept inside the block and the chain structure is
used for protection. In hyperledger fabric, each node maintains a ledger and the consensus
mechanism is used to keep the ledger updated and identical at every node. The ledger at each
node is composed of two parts, a blockchain, and a world-state database. The article focuses on
discussing the transaction flow in Hyperledger Fabric.
Assumptions
There are a few assumptions to understand before beginning with the transaction flow in
Hyperledger Fabric.
 This transaction flow assumes that the channel is set up and running.
 The application user has been registered and enrolled with the organization’s Certificate
Authority (CA) Certification and received back necessary Protected cryptographic
material, which will be used to authenticate to the network.
  The chaincode containing a set of key representation value pairs is installed on the
peers and deployed to its current channel.
 The chaincode contains logic defining a set of active transaction instructions and the
agreed-upon price for a radish.
 An endorsement policy has also been set up for this chaincode, stating that both peer A
and peer B must endorse any transaction.

Transaction Flow in Hyperledger Fabric

Below are the steps in the transaction flow in the hyperledger fabric:

1. Client A initiates a transaction:

 Client A sends requests to Client B for purchasing radishes.

 The request targets peer A and peer B, who are representatives of Client A and Client
B.
 The endorsement policy states that both peers must endorse any transaction thus the
request goes to peer A and peer B.
 The transaction proposal which is a request to invoke chaincode function with the intent
to read/ update the ledger is constructed using SDK.
 The SDK takes the user’s cryptographic credentials to produce a unique signature for
the transaction proposal.
 The SDK submits the transaction proposal to the target peer and it will first forward the
transaction proposal to other peers for execution.

2. Endorsing peers verify the signature and execute the transaction:

The endorsing peers verify that:

 The transaction proposal is well-formed.
 It has not been submitted in the past for replay-attack protection.
 The signature is valid.
 The submitter (Client A) satisfies the channel’s Writers’ policy and is properly
authorized to perform the proposed operation on the channel.
The endorsing peers take the transaction proposal inputs as arguments to invoke the chaincode
function. The chaincode function gets executed and produces transaction results, response
value, write set, and read set. Till this point, there is no update being done to the ledger. The
set of these generated values along with the endorsing peer’s signature is sent to the target peer
as the proposal response.

3. Proposal responses are inspected:

 In step, the target peer verifies the proposal responses.
  Even if checking is not performed hyperledger fabric architecture is designed in such a
way that the endorsement policy will still be checked and enforced when each peer
validated transactions prior to committing them.

4. Target peer assembles endorsements into a transaction:

 The target peer broadcasts transaction messages containing transaction proposals and
responses to the ordering service. This includes Channel ID, read/ write sets, and a
signature for each endorsing peer.
 The ordering service receives the transactions, orders them, and creates blocks of
transactions per channel. It will not inspect the entire content of the transaction.

5. Transaction is validated and committed:

 The blocks of transactions are delivered to all the peers on the channel and they validate
the transactions within the block.
 The peers validate transactions to ensure the endorsement policy is fulfilled and there
have been no changes to the ledger state for read set variables since the read set was
generated by the transaction execution.
 They tag transactions in the block as valid or invalid.
7. Ledger updated:
 Each peer appends the block to the channel’s chain.
 For each valid transaction, the write set is committed to the current database.
 Each peer emits an event to notify the client application that the transaction is
immutably appended to the chain and also sends the notification whether the transaction
is validated or invalidated.

Membership and Identity Management

Membership
If you’ve read through the documentation on identity you’ve seen how a PKI can provide
verifiable identities through a chain of trust. Now let’s see how these identities can be used
to represent the trusted members of a blockchain network.
This is where a Membership Service Provider (MSP) comes into play — it identifies which
Root CAs and Intermediate CAs are trusted to define the members of a trust domain,
e.g., an organization, either by listing the identities of their members, or by identifying
which CAs are authorized to issue valid identities for their members, or — as will usually be
the case — through a combination of both.
The power of an MSP goes beyond simply listing who is a network participant or member of
a channel. An MSP can identify specific roles an actor might play either within the scope of
the organization the MSP represents (e.g., admins, or as members of a sub-organization
group), and sets the basis for defining access privileges in the context of a network and
channel (e.g., channel admins, readers, writers).
The configuration of an MSP is advertised to all the channels where members of the
corresponding organization participate (in the form of a channel MSP). In addition to the
channel MSP, peers, orderers, and clients also maintain a local MSP to authenticate member
messages outside the context of a channel and to define the permissions over a particular
component (who has the ability to install chaincode on a peer, for example).
In addition, an MSP can allow for the identification of a list of identities that have been
revoked — as discussed in the Identity documentation — but we will talk about how that
process also extends to an MSP.
We’ll talk more about local and channel MSPs in a moment. For now let’s see what MSPs do
in general.
Mapping MSPs to Organizations
An organization is a managed group of members. This can be something as big as a
multinational corporation or a small as a flower shop. What’s most important about
organizations (or orgs) is that they manage their members under a single MSP. Note that this
is different from the organization concept defined in an X.509 certificate, which we’ll talk
about later.
The exclusive relationship between an organization and its MSP makes it sensible to name
the MSP after the organization, a convention you’ll find adopted in most policy
configurations. For example, organization ORG1 would likely have an MSP called
something like ORG1-MSP. In some cases an organization may require multiple membership
groups — for example, where channels are used to perform very different business functions
between organizations. In these cases it makes sense to have multiple MSPs and name them
accordingly, e.g., ORG2-MSP-NATIONAL and ORG2-MSP-GOVERNMENT, reflecting
the different membership roots of trust within ORG2 in the NATIONAL sales channel
compared to the GOVERNMENT regulatory channel.
Two different MSP configurations for an organization. The first configuration shows the
typical relationship between an MSP and an organization — a single MSP defines the list of
members of an organization. In the second configuration, different MSPs are used to
represent different organizational groups with national, international, and governmental
affiliation.

Organizational Units and MSPs

An organization is often divided up into multiple organizational units (OUs), each of which
has a certain set of responsibilities. For example, the ORG1 organization might have
both ORG1-MANUFACTURING and ORG1-DISTRIBUTION OUs to reflect these separate
lines of business. When a CA issues X.509 certificates, the OU field in the certificate
specifies the line of business to which the identity belongs.
We’ll see later how OUs can be helpful to control the parts of an organization who are
considered to be the members of a blockchain network. For example, only identities from
the ORG1-MANUFACTURING OU might be able to access a channel, whereas ORG1-
DISTRIBUTION cannot.
Finally, though this is a slight misuse of OUs, they can sometimes be used by different
organizations in a consortium to distinguish each other. In such cases, the different
organizations use the same Root CAs and Intermediate CAs for their chain of trust, but
assign the OU field to identify members of each organization. We’ll also see how to
configure MSPs to achieve this later.
Local and Channel MSPs
MSPs appear in two places in a blockchain network: channel configuration (channel MSPs),
and locally on an actor’s premise (local MSP). Local MSPs are defined for clients (users)
and for nodes (peers and orderers). Node local MSPs define the permissions for that node
(who the peer admins are, for example). The local MSPs of the users allow the user side to
authenticate itself in its transactions as a member of a channel (e.g. in chaincode
transactions), or as the owner of a specific role into the system (an org admin, for example,
in configuration transactions).
Every node and user must have a local MSP defined, as it defines who has administrative
or participatory rights at that level (peer admins will not necessarily be channel admins, and
vice versa).
In contrast, channel MSPs define administrative and participatory rights at the channel
level. Every organization participating in a channel must have an MSP defined for it. Peers
and orderers on a channel will all share the same view of channel MSPs, and will therefore
be able to correctly authenticate the channel participants. This means that if an organization
wishes to join the channel, an MSP incorporating the chain of trust for the organization’s
members would need to be included in the channel configuration. Otherwise transactions
originating from this organization’s identities will be rejected.
The key difference here between local and channel MSPs is not how they function — both
turn identities into roles — but their scope.

Local and channel MSPs. The trust domain (e.g., the organization) of each peer is defined by
the peer’s local MSP, e.g., ORG1 or ORG2. Representation of an organization on a channel
is achieved by adding the organization’s MSP to the channel configuration. For example, the
channel of this figure is managed by both ORG1 and ORG2. Similar principles apply for the
network, orderers, and users, but these are not shown here for simplicity.
You may find it helpful to see how local and channel MSPs are used by seeing what happens
when a blockchain administrator installs and instantiates a smart contract, as shown in
the diagram above.
An administrator B connects to the peer with an identity issued by RCA1 and stored in their
local MSP. When B tries to install a smart contract on the peer, the peer checks its local
MSP, ORG1-MSP, to verify that the identity of B is indeed a member of ORG1. A
successful verification will allow the install command to complete successfully.
Subsequently, B wishes to instantiate the smart contract on the channel. Because this is a
channel operation, all organizations on the channel must agree to it. Therefore, the peer must
check the MSPs of the channel before it can successfully commit this command. (Other
things must happen too, but concentrate on the above for now.)
Local MSPs are only defined on the file system of the node or user to which they apply.
Therefore, physically and logically there is only one local MSP per node or user. However,
as channel MSPs are available to all nodes in the channel, they are logically defined once in
the channel configuration. However, a channel MSP is also instantiated on the file system
of every node in the channel and kept synchronized via consensus. So while there is a
copy of each channel MSP on the local file system of every node, logically a channel MSP
resides on and is maintained by the channel or the network.
MSP Levels
The split between channel and local MSPs reflects the needs of organizations to administer
their local resources, such as a peer or orderer nodes, and their channel resources, such as
ledgers, smart contracts, and consortia, which operate at the channel or network level. It’s
helpful to think of these MSPs as being at different levels, with MSPs at a higher level
relating to network administration concerns while MSPs at a lower level handle identity
for the administration of private resources. MSPs are mandatory at every level of
administration — they must be defined for the network, channel, peer, orderer, and users.

MSP Levels. The MSPs for the peer and orderer are local, whereas the MSPs for a channel
(including the network configuration channel) are shared across all participants of that
channel. In this figure, the network configuration channel is administered by ORG1, but
another application channel can be managed by ORG1 and ORG2. The peer is a member of
and managed by ORG2, whereas ORG1 manages the orderer of the figure. ORG1 trusts
identities from RCA1, whereas ORG2 trusts identities from RCA2. Note that these are
administration identities, reflecting who can administer these components. So while ORG1
administers the network, [Link] does exist in the network definition.
 Network MSP: The configuration of a network defines who are the members in the
network — by defining the MSPs of the participant organizations — as well as which of
these members are authorized to perform administrative tasks (e.g., creating a channel).
 Channel MSP: It is important for a channel to maintain the MSPs of its members
separately. A channel provides private communications between a particular set of
organizations which in turn have administrative control over it. Channel policies
interpreted in the context of that channel’s MSPs define who has ability to participate in
certain action on the channel, e.g., adding organizations, or instantiating chaincodes. Note
that there is no necessary relationship between the permission to administrate a channel
 and the ability to administrate the network configuration channel (or any other channel).
Administrative rights exist within the scope of what is being administrated (unless the
rules have been written otherwise — see the discussion of the ROLE attribute below).
 Peer MSP: This local MSP is defined on the file system of each peer and there is a
single MSP instance for each peer. Conceptually, it performs exactly the same function as
channel MSPs with the restriction that it only applies to the peer where it is defined. An
example of an action whose authorization is evaluated using the peer’s local MSP is the
installation of a chaincode on the peer.
 Orderer MSP: Like a peer MSP, an orderer local MSP is also defined on the file
system of the node and only applies to that node. Like peer nodes, orderers are also owned
by a single organization and therefore have a single MSP to list the actors or nodes it
trusts.

MSP Structure
So far, you’ve seen that the most important element of an MSP are the specification of the
root or intermediate CAs that are used to establish an actor’s or node’s membership in the
respective organization. There are, however, more elements that are used in conjunction with
these two to assist with membership functions.

The figure above shows how a local MSP is stored on a local filesystem. Even though
channel MSPs are not physically structured in exactly this way, it’s still a helpful way to
think about them.
As you can see, there are nine elements to an MSP. It’s easiest to think of these elements in a
directory structure, where the MSP name is the root folder name with each subfolder
representing different elements of an MSP configuration.
Let’s describe these folders in a little more detail and see why they are important.
 Root CAs: This folder contains a list of self-signed X.509 certificates of the Root
CAs trusted by the organization represented by this MSP. There must be at least one Root
CA X.509 certificate in this MSP folder.
 This is the most important folder because it identifies the CAs from which all other
certificates must be derived to be considered members of the corresponding organization.
 Intermediate CAs: This folder contains a list of X.509 certificates of the
Intermediate CAs trusted by this organization. Each certificate must be signed by one of
the Root CAs in the MSP or by an Intermediate CA whose issuing CA chain ultimately
leads back to a trusted Root CA.
An intermediate CA may represent a different subdivision of the organization
(like ORG1-MANUFACTURING and ORG1-DISTRIBUTION do for ORG1), or the
organization itself (as may be the case if a commercial CA is leveraged for the
organization’s identity management). In the latter case intermediate CAs can be used to
represent organization subdivisions. Here you may find more information on best
practices for MSP configuration. Notice, that it is possible to have a functioning network
that does not have an Intermediate CA, in which case this folder would be empty.
Like the Root CA folder, this folder defines the CAs from which certificates must be
issued to be considered members of the organization.
 Organizational Units (OUs): These are listed in
the $FABRIC_CFG_PATH/msp/[Link] file and contain a list of organizational
units, whose members are considered to be part of the organization represented by this
MSP. This is particularly useful when you want to restrict the members of an organization
to the ones holding an identity (signed by one of MSP designated CAs) with a specific OU
in it.
Specifying OUs is optional. If no OUs are listed, all the identities that are part of an MSP
— as identified by the Root CA and Intermediate CA folders — will be considered
members of the organization.
 Administrators: This folder contains a list of identities that define the actors who
have the role of administrators for this organization. For the standard MSP type, there
should be one or more X.509 certificates in this list.
It’s worth noting that just because a actor has the role of an administrator it doesn’t mean
that they can administer particular resources! The actual power a given identity has with
respect to administering the system is determined by the policies that manage system
resources. For example, a channel policy might specify that ORG1-
MANUFACTURING administrators have the rights to add new organizations to the
channel, whereas the ORG1-DISTRIBUTION administrators have no such rights.
Even though an X.509 certificate has a ROLE attribute (specifying, for example, that a
actor is an admin), this refers to a actor’s role within its organization rather than on the
blockchain network. This is similar to the purpose of the OU attribute, which — if it has
been defined — refers to a actor’s place in the organization.
The ROLE attribute can be used to confer administrative rights at the channel level if the
policy for that channel has been written to allow any administrator from an organization
(or certain organizations) permission to perform certain channel functions (such as
instantiating chaincode). In this way, an organizational role can confer a network role.
 Revoked Certificates: If the identity of an actor has been revoked, identifying
information about the identity — not the identity itself — is held in this folder. For
X.509-based identities, these identifiers are pairs of strings known as Subject Key
Identifier (SKI) and Authority Access Identifier (AKI), and are checked whenever the
X.509 certificate is being used to make sure the certificate has not been revoked.
This list is conceptually the same as a CA’s Certificate Revocation List (CRL), but it also
relates to revocation of membership from the organization. As a result, the administrator
of an MSP, local or channel, can quickly revoke a actor or node from an organization by
advertising the updated CRL of the CA the revoked certificate as issued by. This “list of
lists” is optional. It will only become populated as certificates are revoked.
 Node Identity: This folder contains the identity of the node, i.e., cryptographic
material that — in combination to the content of KeyStore — would allow the node to
authenticate itself in the messages that is sends to other participants of its channels and
network. For X.509 based identities, this folder contains an X.509 certificate. This is the
certificate a peer places in a transaction proposal response, for example, to indicate that
the peer has endorsed it — which can subsequently be checked against the resulting
transaction’s endorsement policy at validation time.
This folder is mandatory for local MSPs, and there must be exactly one X.509 certificate
for the node. It is not used for channel MSPs.
 KeyStore for Private Key: This folder is defined for the local MSP of a peer or
orderer node (or in an client’s local MSP), and contains the node’s signing key. This key
matches cryptographically the node’s identity included in Node Identity folder and is
used to sign data — for example to sign a transaction proposal response, as part of the
endorsement phase.
This folder is mandatory for local MSPs, and must contain exactly one private key.
Obviously, access to this folder must be limited only to the identities of users who have
administrative responsibility on the peer.
Configuration of a channel MSPs does not include this folder, as channel MSPs solely
aim to offer identity validation functionalities and not signing abilities.
 TLS Root CA: This folder contains a list of self-signed X.509 certificates of the Root
CAs trusted by this organization for TLS communications. An example of a TLS
communication would be when a peer needs to connect to an orderer so that it can receive
ledger updates.
MSP TLS information relates to the nodes inside the network — the peers and the
orderers, in other words, rather than the applications and administrations that consume the
network.
There must be at least one TLS Root CA X.509 certificate in this folder.
 TLS Intermediate CA: This folder contains a list intermediate CA certificates CAs
trusted by the organization represented by this MSP for TLS communications. This
folder is specifically useful when commercial CAs are used for TLS certificates of an
organization. Similar to membership intermediate CAs, specifying intermediate TLS CAs
is optional.
 For more information about TLS, click here.
If you’ve read this doc as well as our doc on Identity), you should have a pretty good grasp
of how identities and membership work in Hyperledger Fabric. You’ve seen how a PKI and
MSPs are used to identify the actors collaborating in a blockchain network. You’ve learned
how certificates, public/private keys, and roots of trust work, in addition to how MSPs are
physically and logically structured.
Identity

What is an Identity?
The different actors in a blockchain network include peers, orderers, client applications,
administrators and more. Each of these actors — active elements inside or outside a network
able to consume services — has a digitial identity encapsulated in an X.509 digital
certificate. These identities really matter because they determine the exact permissions
over resources and access to information that actors have in a blockchain network.
A digital identity furthermore has some additional attributes that Fabric uses to determine
permissions, and it gives the union of an identity and the associated attributes a special name
— principal. Principals are just like userIDs or groupIDs, but a little more flexible because
they can include a wide range of properties of an actor’s identity, such as the actor’s
organization, organizational unit, role or even the actor’s specific identity. When we talk
about principals, they are the properties which determine their permissions.
For an identity to be verifiable, it must come from a trusted authority. A membership
service provider (MSP) is how this is achieved in Fabric. More specifically, an MSP is a
component that defines the rules that govern the valid identities for this organization. The
default MSP implementation in Fabric uses X.509 certificates as identities, adopting a
traditional Public Key Infrastructure (PKI) hierarchical model (more on PKI later).
A Simple Scenario to Explain the Use of an Identity
Imagine that you visit a supermarket to buy some groceries. At the checkout you see a sign
that says that only Visa, Mastercard and AMEX cards are accepted. If you try to pay with a
different card — let’s call it an “ImagineCard” — it doesn’t matter whether the card is
authentic and you have sufficient funds in your account. It will be not be accepted.
Having a valid credit card is not enough — it must also be accepted by the store! PKIs and
MSPs work together in the same way — a PKI provides a list of identities, and an MSP says
which of these are members of a given organization that participates in the network.
PKI certificate authorities and MSPs provide a similar combination of functionalities. A PKI
is like a card provider — it dispenses many different types of verifiable identities. An MSP,
on the other hand, is like the list of card providers accepted by the store, determining which
identities are the trusted members (actors) of the store payment network. MSPs turn
verifiable identities into the members of a blockchain network.
What are PKIs?
A public key infrastructure (PKI) is a collection of internet technologies that provides
secure communications in a network. It’s PKI that puts the S in HTTPS — and if you’re
reading this documentation on a web browser, you’re probably using a PKI to make sure it
comes from a verified source.

The elements of Public Key Infrastructure (PKI). A PKI is comprised of Certificate

Authorities who issue digital certificates to parties (e.g., users of a service, service provider),
who then use them to authenticate themselves in the messages they exchange with their
environment. A CA’s Certificate Revocation List (CRL) constitutes a reference for the
certificates that are no longer valid. Revocation of a certificate can happen for a number of
reasons. For example, a certificate may be revoked because the cryptographic private
material associated to the certificate has been exposed.
Although a blockchain network is more than a communications network, it relies on the PKI
standard to ensure secure communication between various network participants, and to
ensure that messages posted on the blockchain are properly authenticated. It’s therefore
important to understand the basics of PKI and then why MSPs are so important.
There are four key elements to PKI:
 Digital Certificates
 Public and Private Keys
 Certificate Authorities
 Certificate Revocation Lists
Let’s quickly describe these PKI basics, and if you want to know more details, Wikipedia is a
good place to start.
Digital Certificates
A digital certificate is a document which holds a set of attributes relating to the holder of the
certificate. The most common type of certificate is the one compliant with the X.509
standard, which allows the encoding of a party’s identifying details in its structure.
For example, Mary Morris in the Manufacturing Division of Mitchell Cars in Detroit,
Michigan might have a digital certificate with a SUBJECT attribute
of C=US, ST=Michigan, L=Detroit, O=Mitchell Cars, OU=Manufacturing, CN=Mary Morri
s /UID=123456. Mary’s certificate is similar to her government identity card — it provides
information about Mary which she can use to prove key facts about her. There are many
other attributes in an X.509 certificate, but let’s concentrate on just these for now.

A digital certificate describing a party called Mary Morris. Mary is the SUBJECT of the
certificate, and the highlighted SUBJECT text shows key facts about Mary. The certificate
also holds many more pieces of information, as you can see. Most importantly, Mary’s public
key is distributed within her certificate, whereas her private signing key is not. This signing
key must be kept private.
What is important is that all of Mary’s attributes can be recorded using a mathematical
technique called cryptography (literally, “secret writing”) so that tampering will invalidate
the certificate. Cryptography allows Mary to present her certificate to others to prove her
identity so long as the other party trusts the certificate issuer, known as a Certificate
Authority (CA). As long as the CA keeps certain cryptographic information securely
(meaning, its own private signing key), anyone reading the certificate can be sure that the
information about Mary has not been tampered with — it will always have those particular
attributes for Mary Morris. Think of Mary’s X.509 certificate as a digital identity card that is
impossible to change.
Authentication, Public keys, and Private Keys
Authentication and message integrity are important concepts in secure communications.
Authentication requires that parties who exchange messages are assured of the identity that
created a specific message. For a message to have “integrity” means that cannot have been
modified during its transmission. For example, you might want to be sure you’re
communicating with the real Mary Morris rather than an impersonator. Or if Mary has sent
you a message, you might want to be sure that it hasn’t been tampered with by anyone else
during transmission.
Traditional authentication mechanisms rely on digital signatures that, as the name suggests,
allow a party to digitally sign its messages. Digital signatures also provide guarantees on the
integrity of the signed message.
Technically speaking, digital signature mechanisms require each party to hold two
cryptographically connected keys: a public key that is made widely available and acts as
authentication anchor, and a private key that is used to produce digital signatures on
messages. Recipients of digitally signed messages can verify the origin and integrity of a
received message by checking that the attached signature is valid under the public key of the
expected sender.
The unique relationship between a private key and the respective public key is the
cryptographic magic that makes secure communications possible. The unique
mathematical relationship between the keys is such that the private key can be used to
produce a signature on a message that only the corresponding public key can match, and only
on the same message.

In the example above, Mary uses her private key to sign the message. The signature can be
verified by anyone who sees the signed message using her public key.

Certificate Authorities
As you’ve seen, an actor or a node is able to participate in the blockchain network, via the
means of a digital identity issued for it by an authority trusted by the system. In the most
common case, digital identities (or simply identities) have the form of cryptographically
validated digital certificates that comply with X.509 standard and are issued by a Certificate
Authority (CA).
CAs are a common part of internet security protocols, and you’ve probably heard of some of
the more popular ones: Symantec (originally Verisign), GeoTrust, DigiCert, GoDaddy, and
Comodo, among others.

A Certificate Authority dispenses certificates to different actors. These certificates are

digitally signed by the CA and bind together the actor with the actor’s public key (and
optionally with a comprehensive list of properties). As a result, if one trusts the CA (and
knows its public key), it can trust that the specific actor is bound to the public key included in
the certificate, and owns the included attributes, by validating the CA’s signature on the
actor’s certificate.
Certificates can be widely disseminated, as they do not include either the actors’ nor the
CA’s private keys. As such they can be used as anchor of trusts for authenticating messages
coming from different actors.
CAs also have a certificate, which they make widely available. This allows the consumers of
identities issued by a given CA to verify them by checking that the certificate could only
have been generated by the holder of the corresponding private key (the CA).
In a blockchain setting, every actor who wishes to interact with the network needs an
identity. In this setting, you might say that one or more CAs can be used to define the
members of an organization’s from a digital perspective. It’s the CA that provides the
basis for an organization’s actors to have a verifiable digital identity.
Root CAs, Intermediate CAs and Chains of Trust
CAs come in two flavors: Root CAs and Intermediate CAs. Because Root CAs (Symantec,
Geotrust, etc) have to securely distribute hundreds of millions of certificates to internet
users, it makes sense to spread this process out across what are called Intermediate CAs.
These Intermediate CAs have their certificates issued by the root CA or another intermediate
authority, allowing the establishment of a “chain of trust” for any certificate that is issued by
any CA in the chain. This ability to track back to the Root CA not only allows the function of
CAs to scale while still providing security — allowing organizations that consume
certificates to use Intermediate CAs with confidence — it limits the exposure of the Root
CA, which, if compromised, would endanger the entire chain of trust. If an Intermediate CA
is compromised, on the other hand, there will be a much smaller exposure.

A chain of trust is established between a Root CA and a set of Intermediate CAs as long as
the issuing CA for the certificate of each of these Intermediate CAs is either the Root CA
itself or has a chain of trust to the Root CA.
Intermediate CAs provide a huge amount of flexibility when it comes to the issuance of
certificates across multiple organizations, and that’s very helpful in a permissioned
blockchain system (like Fabric). For example, you’ll see that different organizations may use
different Root CAs, or the same Root CA with different Intermediate CAs — it really does
depend on the needs of the network.

Fabric CA
It’s because CAs are so important that Fabric provides a built-in CA component to allow you
to create CAs in the blockchain networks you form. This component — known as Fabric
CA is a private root CA provider capable of managing digital identities of Fabric participants
that have the form of X.509 certificates. Because Fabric CA is a custom CA targeting the
Root CA needs of Fabric, it is inherently not capable of providing SSL certificates for
general/automatic use in browsers. However, because some CA must be used to manage
identity (even in a test environment), Fabric CA can be used to provide and manage
certificates. It is also possible — and fully appropriate — to use a public/commerical root or
intermediate CA to provide identification.
Certificate Revocation Lists
A Certificate Revocation List (CRL) is easy to understand — it’s just a list of references to
certificates that a CA knows to be revoked for one reason or another. If you recall the store
scenario, a CRL would be like a list of stolen credit cards.
When a third party wants to verify another party’s identity, it first checks the issuing CA’s
CRL to make sure that the certificate has not been revoked. A verifier doesn’t have to check
the CRL, but if they don’t they run the risk of accepting a compromised identity.

Using a CRL to check that a certificate is still valid. If an impersonator tries to pass a
compromised digital certificate to a validating party, it can be first checked against the
issuing CA’s CRL to make sure it’s not listed as no longer valid.
Note that a certificate being revoked is very different from a certificate expiring. Revoked
certificates have not expired — they are, by every other measure, a fully valid certificate. For
more in-depth information about CRLs, click here.
Now that you’ve seen how a PKI can provide verifiable identities through a chain of trust,
the next step is to see how these identities can be used to represent the trusted members of a
blockchain network. That’s where a Membership Service Provider (MSP) comes into play
— it identifies the parties who are the members of a given organization in the
blockchain network.