Unit 3

Hyperledger Fabric
By-
Shrankhla Saxena
Assistant Professor
CSIT Dept.
About the Hyperledger Architecture Working Group

• The Hyperledger Architecture WG serves as a cross-project

forum for architects and technologists from the Hyperledger
community to exchange ideas and explore alternate architectural
options and trade-offs. Their focus is on developing a modular
architectural framework for enterprise-class distributed ledgers.
This includes identifying common and critical components,
providing a functional decomposition of an enterprise blockchain
stack into component layers and modules, standardizing
interfaces between the components, and ensuring interoperability
between ledgers.
HYPERLEDGER MODULAR UMBRELLA APPROACH
Consensus in Hyperledger Fabric
• Most of the blockchain frameworks like Ethereum are permission-
less frameworks with no trust among their peers. Thus, in order to
validate the transactions, there is a need for consensus algorithms like
proof of work, proof of elapsed time in Ethereum.
• Hyperledger Fabric on the other hand is a permissioned network with
a certificate authority that onboards every node with a specific digital
certificate. Thus, the purpose of consensus algorithms in Hyperledger
Fabric is completely different. Hyperledger Fabric follows a modular
approach wherein different consensus techniques can be plugged in as
per the requirement.
• Currently, Hyperledger Fabric uses Solo and Kafka to reach consensus,
which requires a node to validate a batch of transactions and add them
as a new block to the blockchain.
Consensus Properties
 Safety - Each node is guaranteed the same sequence of inputs and results in the
same output on each node. When the nodes receive an identical series of
transactions, the same state changes will occur on each node.
 Liveliness - Each non-faulty node will eventually receive every submitted
transaction.
Consensus Algorithm Used in Hyperledger Fabric

 Solo - It is a Hyperledger Fabric ordering mechanism most typically used

by developers experimenting with Hyperledger Fabric networks. SOLO
involves a single ordering node. It is not used in the production
environment.
 Kafka - In Kafka, only the leader does the ordering and only the in-sync
replicas can be voted as a leader. This provides crash fault-tolerance and
finality happens in a matter of seconds. While Kafka is crash fault-tolerant,
it is not Byzantine fault-tolerant, which prevents the system from reaching
an agreement in the case of malicious or faulty nodes.
Consensus in Hyperledger Fabric is broken out into
3 phases:
• Endorsement, Ordering, and Validation.
• • Endorsement is driven by policy (eg m out of n signatures)
upon which participants endorse a transaction.
• • Ordering phase accepts the endorsed transactions and agrees to
the order to be committed to the ledger.
• • Validation takes a block of ordered transactions and validates
the correctness of the results, including checking endorsement
policy and double-spending.
Hyperledger Fabric Architecture
Hyperledger Fabric Architecture-Flow of Actions

•1. Propose Transaction

•2. Execute Transaction
•3. Proposal Response
•4. Order Transaction
•5. Deliver Transaction
•6. Validate Transaction
•7. Notify
Hyperledger Fabric Architecture-Flow of
Actions
Hyperledger Fabric
• Hyperledger is an open-source community focused on developing a suite of stable frameworks,
tools, and libraries for enterprise-grade blockchain deployments.
• Hyperledger Fabric is an enterprise-grade, distributed ledger platform that offers modularity and
versatility for a broad set of industry use cases.
• The modular architecture for Hyperledger Fabric accommodates the diversity of enterprise use
cases through plug-and-play components, such as consensus, privacy, and membership services.
• 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.
• IBM is one contributor to code, IP, and development effort to Hyperledger Fabric, and the initial
version was released in July 2017.
Hyperledger Fabric - Features
• It will transform the business network in which an individual operates and creates a new level
of trust across organizations who want to do business together.
• It is a blockchain framework on which developers write their own chain code. It allows
developers to control where and how transactions get verified for better scaling and privacy
with higher transaction throughput. It has the ability to support large networks and with truly
private multi-party transactions.
• Model your business networks, talk about assets, participants, and transactions rather than low-
level developments, test, and exposed via APIs.
• Applications invoke transactions to interact with the business network.
• Integrate existing records such as other databases or other places where data is stored for
analytic, visualization, etc.
• Fully open and part of Linux Foundation Hyperledger.
Hyperledger Fabric - Components
• Membership Services:
• 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 users 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.
Hyperledger Fabric – Components (Contd.)
• 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.
• 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.
Hyperledger Fabric – Components (Contd.)
• 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.
Hyperledger Fabric – Components (Contd.)
• 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.
Hyperledger Fabric – Components (Contd.)
• Chaincode:
• There is a concept of Smart Contract called Chaincode in Fabric.
• Currently, three languages can program Fabric chaincode including Golang, Node.js, and Java. To
deploy a chaincode, a network admin must install the chaincode onto target peers and then
invoke an orderer to instantiate the chaincode onto a specific channel.
• While instantiating the chaincode, an admin can define an endorsement policy to the chaincode.
• Endorsement policy defines which peers need to agree on the results of a transaction before the
transaction can be added onto ledgers of all peers on the channel.
Hyperledger Transaction Flow
• 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.
Transaction Flow
Hyperledger Transaction Flow (Contd.)
• 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.
• In the end, the client receives an event, and it takes appropriate action based on the status of the
transaction.
Hyperledger Transaction Flow (Contd.)
• The client application submits a transaction request to the endorsing peers. These peers execute
the request, sign the output, and send it back to the client. This is part of the endorsement.
Once the client collects sufficient (the definition of sufficient is mentioned in the endorsement
policy) endorsements, it submits that transaction to the ordering services.
• The ordering service continuously receives transitions from multiple clients. It collects all the
transactions for a specific duration, constructs a block consisting of all the collected transactions,
and orders these transactions by executing an ordering algorithm. The ordering service ensures
that all of these transactions are fully ordered across all the ordering services nodes among the
participating organizations.
• Once the ordering is finished, then there is a notion of block validation. In the validation
procedure, the committing peers validate the individual transaction with the reference of
endorsement policy, mark these transactions valid or invalid, and append the block to the ledger.
Hyperledger Transaction Flow (Contd.)
• In the hyperledger fabric, the consensus is achieved in three steps: Endorsing peers endorses the
transactions, Ordering service order all the received transactions and construct a block,
and Committing peers to validate the entire block by referring to the endorsement policy of
individual transaction and commit the block into the ledger.
 Transaction Flow: Step 1/7: Client Proposed Transaction
• The key components are mentioned in the below
diagram with different color square boxes such as
Endorser, Committing Peer, ORdering Node, Smart
Contract or Chaincode, Application and
Endorsement Policy.
• 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: Step 2/7: Execute Proposed Transaction

• These peer nodes E0, E1 & E2 will

execute the transaction
independently. However, none 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: 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: Step 4/7: Order 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: 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. The hierarchy
structure means that only a peer communicates to other organization peers within an organization. However,
there might be multiple peers within an organization and are responsible for endorsing and committing
functionalities. 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
• Hyperledger fabric architecture is architected so that each component can be upgraded or replaced with
others based on the requirements without affecting other components. Currently, it supports SOLO, Kafka,
and Raft algorithms.
Transaction Flow: Step 5/7: Deliver Transaction
 Transaction Flow: 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.
 Transaction Flow: 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.
Hyperledger Fabric SDK – Ordering Service
• The ordering service packages transactions into blocks and to be
delivered to all the peers across the network, and the communication
with the service is via channels. The ordering service and its
configuration has to be included in the geneses block of the
blockchain.
• There are different configuration options for the ordering service
include:
• SOLO, Single node for development
• Kafka: Crash fault-tolerant consensus
• 3 Nodes per minimum
• Odd number of nodes
• Raft:
Hyperledger Fabric SDK – Channels
• The same set of peer nodes such as endorsers
and committers can be part of multiple
blockchain ledgers, and this is achieved using
the channels. The channels provide transaction
privacy among the different ledgers. Multiple
parallel blockchain services can be executed
and managed for better utilization of hardware
resources and scalability of the entire network
through the channels.
• We can run the multiple blockchain services
using the same set of peer nodes or selected
peer nodes set for a blockchain service and
another set of peer nodes for another
blockchain service. So, the Hyperledger fabric
platform provides flexibility to host multiple
blockchain services using different mix and
matches of peer nodes.
Hyperledger Fabric SDK– Channels Contd…
• It means the same set of peer nodes can part of multiple blockchain ledgers. In the above
example: E0, & E1 are part of one blockchain service whereas, E0 is also a part of another
blockchain service. These blockchain services may have the same or different ordering services,
but each service maintains a different ledger.
• The ledgers exist in the scope of a channel. These channels can be shared across an entire
network of peers or can be permissioned for a specific set of participants such that a subset of
peers can form a channel among themselves to execute private transactions.
• Chaincode is installed on peers that provide access to the world state, and these are
instantiated on specific channels.
• Peers can participate in multiple channels, and the state maintained by the chaincode is part
of the ledger and separate for each channel. It means the chaincode state of one channel is
different compared to another channel. So, these are kept private and separate.
• When the same peers can be part of multiple channels, the concurrent execution provides
higher performance and scalability and better utilization of hardware resources.
Hyperledger Fabric SDK– Channels: Single
Channel Network Contd…
• All the peers are part of the same system channel in the single-channel network, having the same
chaincode and maintaining the same shared distributed ledger.
• In this setup, the client is connected to the endorsing peer E0, and E0, E1, E2 & E3 are the
endorsing peers in the network, and there is an ordering service and exactly one channel in the
network. All the peers connect to the same system channel and maintain a sequence of blocks of
transactions, i.e., shared ledger. There are chain codes deployed at each peer in the network and
instantiated on a particular channel.
• When a transaction, consisting of function calls of the chaincode or smart contract with input
parameters, is submitted by the client application to the network. Then all peers execute the
same function across the network, and the client receives endorsements from all the peers
asynchronously. The client submits a transaction to the ordering service, and the service achieves
consensus and then final validation by peer nodes across the network. So this is an example of a
single-channel network.
Hyperledger Fabric SDK– Channels: Multi-Channel
Network Contd…
• Multiple parallel blockchain services can be executed in the multi-channel network to access the
entire network, and the services will be completely disjoint.
• There are two different applications in this setup: one application is transacting on the red
channel, and another is on the blue channel. These applications may not even know the existence
of the other channel. There are two sets of peers that are part of two different channels.
However, having a common ordering service is quite possible to set up a completely separate
ordering service across the channels. If a common ordering service is used, then the ordering for
the two channels is kept separate along with a separate or the same endorsement policy depends
on the requirements. The ordering service configuration is stored in the genesis block of each
ledger of the channel.
Hyperledger Fabric SDK– Peers
• Peer is a special kind of node responsible for endorsement, verification, and adding a new block into
the ledger. Each peer can connect to one or more channels, and these channels are completely disjoint
from each other. It means one channel’s information will not mix with another channel and has its own
ledger and blockchain, and these are all kept separate.
• A peer is associated with three channels in the below diagram, and each channel has a separate ledger
and world state. This peer has two chain codes, and these chaincode runs as processes. However, it is
safe to run inside Docker containers for security reasons or to contain the vulnerabilities associated
with chaincode, if any.
• It may be possible that all the channels require both chaincode A and B or only a specific chaincode.
This chaincode will be initiated separately in both cases, and initialization output data will be stored as
a transaction inside the ledger separately for each channel. However, for a single chaincode, a single
process will run inside a docker container and serve all the channels as it does not keep state
information or is a stateless process. So this way, we don’t need to run multiple processes for a single
chaincode if it is associated with multiple channels.
• Chaincode runs inside a Docker container as a stateless process.
• Multiple channels initiated chaincode instances but used the same chaincode process runs inside
the container.
• State information is stored inside the ledger of individual channels.
Hyperledger Fabric SDK– Peers Contd..
• There is a communication between the
peer and chaincode, and peer and ledger,
and all these happens using google
remote procedure call (GRPC). These
components, such as peer, chaincode, and
ledger, are pluggable and written
in golang. However, it can be rewritten in
any other language if it supports GRPC.
• Individual peer has the identity (PKI), and
the identity is managed by the local
membership services provider (MSP) on
the network. The individual peers use
their identities when communicating with
peers or with the ordering service or
client application. The events submitted
by the peer are signed by the certificate
that the peer has.
Hyperledger Fabric SDK – Client Applications
• The high-level role and responsibility of the client application are to compose a transaction request
and submits it to the peer nodes. Peer nodes send the endorsements asynchronously. After receiving
sufficient endorsements that satisfy the endorsement policy, it submits the transaction to the ordering
service. In the end, it receives the acknowledgment from the peer nodes about the status of a
transaction as an event to trigger external applications, if any.
• The client application is developed by using the SDK provided by the Hyperledger Fabric. Currently, it
supports major programming languages such as Python, Java, and Golang. So, the client application
can be developed using the supported languages by SDK.
• Each client application can work with multiple channels, and these channels are kept separate. Each
channel is associated with a particular set of peer nodes across the network. It receives events from
multiple channels. The SDK needs to be connected to the local membership service provider to
facilitate all the crypto-related operations required by the client application.
Hyperledger Fabric SDK– Client Applications
• The client application may have to communicate to the same or different ordering services based on
the initial setups based on the channels. So the client application has to be aware of the ordering
services, and all this information is available in the genesis block of the individual channel’s shared
ledger. The genesis block transaction possesses lots of information, such as who the peers in the
channel are: the ordering service nodes, the ordering service algorithm, etc.
• The peers in the channel can also be dynamic, which means peers can enter or leave channels
dynamically. So one peer may leave the channel at some point, and another peer joins the channels.
However, this information will be recorded as transactions on the blockchains, and these transactions
are called channel configuration transactions. These are maintained in a decentralized fashion, similar
to any other block. Once a new peer joins a channel, it synchronizes the ledger and starts receiving
updates. Also, crypto relation information will be updated and recorded as a transaction inside a block.
Hyperledger Fabric SDK– Fabric Certificate
Authority
• Fabric Certificate Authority (Fabric-CA) issues the identity to users, peers, ordering service nodes,
and all the other components, which requires identity across the network. There are many ways
to implement the certificate authority, and one of the ways is a Fabric-CA, and another way is
called IDE mixer.
• The fabric CA is attached to the root certificate authority, and it may have multiple hierarchical
levels. A database is used for high availability, and it supports high availability characteristics such
that if one part goes down still, it will be functional. It can also be connected to other identity
management mechanisms like LDAP (Lightweight Directory Access Protocol) .
• By default, certificate authority within fabric network issues long team identity (Ecerts) to all the
components, and associated private keys are stores securely using hardware service modules.
Hyperledger Fabric –Organisations
• In the enterprise world, organizations can be considered legal entities which manage businesses.
These organizations are recognized with identities, and these identities are valid across the
fabric blockchain network. Each organization defines the following entities:
• Membership services provider (MSP): Manages users, peers, and administrator identities.
• Administrator(s): Manages peers, chaincode, etc.
• Users: Initiate transactions.
• Peers: Manage endorsement and validation of transactions.
• Orderers (optional): Manager ordering of transactions.
• The organization may have multiple peers, and these peers may be endorsing and committing
peers or both. There are ordering services. However, setting up ordering services within an
organization is optional for one or more channels. Each organization can participate in one or
more channels in the blockchain network, and all this information will be captured in the
network itself. It means each channel configuration is stored into the genesis block at the initial
setup, or subsequent blocks, when modified, are stored into the blockchain ledger.
• The network can include many organizations, and it could be a consortium. For example, a group of three
banks forms a consortium, and each bank can be represented as an organization with a unique identity on
the hyperledger fabric network. Each organization hosts at least one MSP for managing the identities of the
entities along with the different types of users, peers and might be ordering services.
• In the above diagram, there are three organizations in this consortium, and the first and the third
organizations are the ones that are running peer nodes. In contrast, the second organization provides only
the ordering service. So, there are various ways to set up the consortium to solve a certain business
process. In this setup, first and third organizations manage two channels means two different types of
blockchain services, with having a single peer at each channel and installed and initiated different
chaincode for different channels. However, the ordering service is common among the channels which the
second organization hosts.
Hyperledger Fabric – Membership Service
Provider
• There are a set of entities in the distributed fabric network, and each entity must be associated
with a unique identity. These identities can be issued by Fabric Certificate Authority (Fabric-CA)
or an external CA, and the Membership Service Provider (MSP) manages these identities across
the entire network. The identities are issued by the CA, along with the CA signature on it, is
called a certificate, and one of the predominated certificate formats is x.509.
• The benefits of having all these identities are to use for authentication, validation, signing, and
issuance.
• Whenever two entities initiate a communication, there should be proper
authentication, and usually, it is done based on the identity. However, malicious
entities can impersonate someone else identity. That the reason the entities trust on
root CA. Whenever someone claims their identity, another party verifies the
certificate to ensure whether an entity is claiming the correct identity or not.
• Every time a user transacts on the blockchain, they authenticate themselves by
signing the transaction. The signature is verified by the peer or any other
receiving entity on the blockchain network. It means any entity that is not a
registered user cannot perform transactions, read blockchain, or channels, etc.,
so none of this information will be available to that entity.
Hyperledger Fabric – Membership Service
Provider Contd..
• These are various entities such as peers, orderers, client applications, and administrators in the
blockchain network, and only the authorized entities can perform the operations. For example,
the user will sign a transaction send it to the peer, and the peer will execute the transaction, and
when it endorses, it is actually signed the endorsement. In the same way, the ordering service
when it creates a block and sends it to the peers. Each block is going to be signed by the ordering
service.
• The MSP can support different crypto standards, and it is a pluggable interface. Different
applications might need different security properties provided by the different CAs or different
crypto standards.
• A network can have multiple MSPs; however, it is recommended to have one MSP per
organization. So based on the number of organizations, the entire network have that many
MSPs.
Hyperledger Fabric – Membership Service
Provider Contd..
• Each entity must have a local MSP, and it is used to store credentials, such as
private keys, securely using hardware modules provided by hardware platforms.
• The entire communications among the different entities are secured through TLS
(Transport Layer Security). TLS provides the following:
• Cryptographic protocols that provide communications security over a computer
network.
• Provides privacy and data integrity
• Symmetric cryptography is used to encrypt the data transmitted (privacy)
• Public-key cryptography is used to authenticate the identities of the communicating
parties.
• Include message integrity check to prevent loss or alteration of the data.
• All component communication is Fabric secured using TLS (client-peer,peer-
peer, peer-orderer, and orderer-orderer)
Hyperledger Fabric – User Identities
• Every user in the network received an identity and an enrollment certificate. The enrollment
certificate has two parts, one is a private key, and the private key is private to a particular user
and used for digitally signing the transactions that will submit onto the network. The private key is
stored securely using a hardware security module provided by the computer hardware platform.
The second part is a signcert, which is a public x.509 certificate in the fabric implementation. The
public key includes a public key and other attributes provided by the certificate authority (CA).
However, other crypto standards can also be used.
• A signcert includes various attributes, including organization details, certain roles, authorization,
and other information. For instance, if this is a user’s certification from the supply chain
blockchain network, the user role may be an exporter or trader. So these kinds of attributes can
also be embedded within a certificate, and these attributes can be used to authorize
transactions on the network.
Hyperledger Fabric: Peer and Orderer Identities

• Each peer and ordered are having a private, public key, and sign certificate from CA. A local MSP
is attached to the peer who holds these identities. In addition, the peer and MSPs can identify
authorized administrators. So it can have one or more administrators. Each administrator has
the following artifacts:
• admincert: A list of administrator certificates.
• cacerts: The CA public cert for verification. As peers and orderers deal with transactions
and transactions are generated and signed by different users from different organizations.
So it includes multiple CA public certificates for verification of requests.
• crls: List of revoked certificates.
• For instance, an organization running the peer can designate one of its users as an
administrator. The administrator will be included in the admincerts, and there will be specific
functions defined that only the administrator can do.
• The peer and orderers receive channel MSP information since the channel also has
an MSP. The peers and orderers will know which channels they are connected to.
Hyperledger Fabric: Channels MSP
• Channels include additional organizational MSP information, such as which peers and orderers
are joining or leaving the channel, and these are dynamic in nature. For instance, some peers
may join the channel later in time, and other peers might leave the channel. All this information
will be dynamically configured in the channel MSP, and this information is queryable.
• So a new peer joining the channel can query the channel MSP to find out which other peers are
participating in this channel. It also determines which client applications can connect to this
channel and can perform transactions on this channel. It also stores all the configuration blocks
in the ledger like any new peers or orderers joining the channel are configured as transactions on
the blockchain. The channel MSP includes:
• admincerts: Any public certificates for administrators.
• cacerts: The CA public certificate for this MSP.
• crls: List of revoked certificates.
• It does not include any private keys for identity. The channel information is all public. For
example, who are the administrators, peers, and orderers. However, the channel does not hold
any private information.
Hyperledger Fabric: Example
• Permission users sign all transactions within a Hyperledger Fabric network, and the receiving
entities validate those signatures. The user signs transactions with their private key, which are
securely stored in their local MSP. In contrast, the receiving entities such as peers must have the
public key of that particular user and the CA certificates to validate transactions.
• The entire transaction goes like this, the user signs the proposal and submits it to the peer. The
peer validates the signature, executes the transaction, signs the response, and sends it back to
the user. The user receives the response, validates the endorser signature. Then, the client signs
the entire endorsed transaction and sends it to the ordering service. The ordering service
validated the client signature, ordered the transactions received from multiple clients,
constructed a block, signed the block, sent it to peers, etc.
Hyperledger Fabric: Network Setup
• Each organization set up a membership service provider (MSP) and associated certificate
authority (CA) at the initial step. Then, creates administrator accounts, and these accounts will be
associated with different entities, such as ordering nodes, peer nodes, etc., to manage each
individual.
Hyperledger Fabric: Network Setup: Step 1/6:
Configure & Start Ordering Service
• The first step is to set up an ordering
service; this is the main component
determining how transactions are
ordered in the network. There could
be a single solo ordering node
hosted by an organization or a
distributed set of nodes hosted by
the different participating
organizations. It may run any
pluggable consensus algorithms,
such as Kafka or Raft or PBFT, or any
other, based on the requirements or
availabilities.
Hyperledger Fabric: Network Setup: Step 2/6:
Configure and Start Peer Nodes
• Once the ordering service is up, the next
step is to configure and start peer nodes.
Mostly, we have multiple organizations
that are part of the blockchain network.
Each of these organizations could run
one or more peers. Each organization
must have MSP and fabric CA or
external CA to manage the identities of
peers.
• A peer can be configured as an endorser
or committer in the network. However,
both the peers have different roles but
can also be set up in the same system
and run as different services. These are
done using the CLI commands once the
required software is installed properly.
 Hyperledger Fabric: Network Setup: Step 3/6:
Install Chaincode
• Once the peer nodes are up within an organization or
across the organizations by the system administrators,
the next important task is to set up or install one or
more chaincode on these endorsing peers.
• The chaincode contains the business logic, and mostly
these are runs independently inside the docker
containers for many reasons. However, one of the
reasons is that to contain the vulnerabilities, if any.
Further, the chaincode only installs on the endorsing
peers, which gives privacy that only a subset of peer
nodes across the organizations have the business logic.
Also, this can be easily managed rather than having the
chaincode installed on all the peers.
• These nodes are not connected until now, so the next
step is to set up channels among the entities across the
blockchain network.
 Hyperledger Fabric: Network Setup: Step 4-5/6:
Create & join Channels
• The ordering service is where these channels are configured. There could be individual ordering services for
each channel or have the same ordering service for all the different channels. It totally depends on the
requirements and purposes. We have considered only a single distributed ordering service across the
network that serves multiple channels in our example.
• After configuring these channels with the ordering service, the next task is to join the set of peers with the
channels across the organizations. For example,
• E0 and E1 are part of the red channel.
• E0, E1, E2, and P3 are part of the blue channel.
• E2 and P3 are part of the yellow channel.
• The subset of nodes joins different channels, and the channel provides a notion of privacy across the
different transactions and the different states maintained in the network. So the same peer can be part of
multiple channels. The uses applications get the identity from the fabric CA or external CA and join the
channels.
 Hyperledger Fabric: Network Setup: Step 6/6:
Instantiate Chaincode in Channel
• The next step is to instantiate the chaincode with endorsement policy on the channel and map the
chaincode to the channel. Each channel has there own ledger, and whenever the ordering service generates
a new block, it goes to the appropriate ledger of the channel in the blockchain network.
• What we have seen that there is a lot of flexibilities to configure the system. It starts with the configuration
of the channel and then which peers or which organization will be part of that channel. Then define which
chaincode will be the part of which channel and all these are segregated separately. Each chaincode state is
separate from another in each channel, and all the chaincode states across the peers in a channel are
consistent. All the states will be maintained consistently using the pluggable consensus algorithms. More of
the entities are pluggable, which gives the flexibility to easy to customize and manage.
Hyperledger Fabric: Endorsement Policies
• An endorsement policy describes the conditions by which a transaction can be endorsed. A
transaction can only be considered valid if it has been endorsed according to its policy.
• We have seen that the endorsement policy governs a subset of peers executing the chaincode on
each channel. The endorsement policy states which peers have to execute and endorse a
transaction before being considered valid and added to the blockchain.
• Each chaincode defines an endorsement policy, and this can be different for each channel that the
chaincode belongs to. A few important system chain codes are implemented internally to the
fabric itself and perform certain important functionalities. These are pluggable, which gives the
flexibility to easy to manage. In this note, we discussed only two important chain codes, and
these are as follows:
• Endorsement System ChainCode (ESCC)
• Validation System ChainCode (VSCC)
Hyperledger Fabric: Endorsement Policies
• This chaincode runs within every endorsing peer. So, when a client submits a transaction to the
endorsing peer. It is the ESCC that receives and validates the signature of the user. Then, the
actual transaction invokes a particular function from the business logic chaincode. The output of
the execution of the transaction, read-write set, will be captured by the ESCC, and it will sign the
proposal response.
• The client receives all the endorsements from different peers, consolidates the response, signs,
and submits it to the ordering service. The orderer will include it in the block, signs it, and delivers
it to peers.
• All the committing peers validate endorsement operations with the help of VSCC. The VSCC looks
up the policy for a particular chaincode, and if it satisfies, then commit it to the ledger.
 What is chain code?
• Chain code is a piece of code that is written in one of the supported languages such as Go
or Java.
• It is installed and instantiated through an SDK or CLI onto a network of Hyperledger
Fabric peer nodes, enabling interaction with that network’s shared ledger.
• Chain code is a program, written in Go, node.js, or Java that implements a prescribed
interface.
• Chain code runs in a secured Docker container isolated from the endorsing peer process.
Chain code initializes and manages ledger state through transactions submitted by
applications.
• A chain code typically handles business logic agreed to by members of the network, so it
may be considered as a “smart contract”.
• State created by a chain code is scoped exclusively to that chain code and can’t be
accessed directly by another chain code. However, within the same network, given the
appropriate permission a chain code may invoke another chain code to access its state.
Aspects to chaincode development
There are three aspects to chaincode development:

• Chaincode Interfaces
• APIs
• Chaincode Responses
Chaincode interfaces
A chaincode implements the Chaincode Interface that supports two methods:

•Init

•Invoke
Init()

•Init is called when you first deploy

your chaincode. As the name
implies, this function is used to do
any initialization your chaincode
needs.
Invoke()

•Invoke is called when you want to call

chaincode functions to do real work (i.e.
read and write to the ledger). Invocations are
captured as transactions, which get grouped
into blocks on the chain. When you need to
update or query the ledger, you do so by
invoking your chaincode.
 Dependencies
The import statement lists a few dependencies for the
chaincode to compile successfully.
•fmt – contains Println for debugging/logging.
•errors – standard go error format.
•shim – contains the definitions for the chaincode
interface and the chaincode stub, which are required to
interact with the ledger
.
 Chaincode APIs
When the Init or Invoke function of a chaincode is called, the fabric passes the
stub shim.ChaincodeStubInterface parameter and the chaincode returns a pb.Response.
This stub can be used to call APIs to access to the ledger services, transaction context,
or to invoke other chaincodes.
The current APIs are defined in the shim package, and can be generated with the
following command:
godoc github.com/hyperledger/fabric/core/chaincode/shim
However, it also includes functions from chaincode.pb.go (protobuffer
functions) that are not intended as public APIs. The best practice is to look
at the function definitions and comments in interfaces.go and
the examples directory.
Response
• The chaincode response comes in the form of a protobuffer.
message Response {

// A status code that should follow the HTTP status codes.

int32 status = 1;

// A message associated with the response code.

string message = 2;

// A payload that can be used to include metadata with this response.

bytes payload = 3;

}
The chaincode will also return events.
Message events and chaincode events.
• messageEvent {
• oneof Event {
• //Register consumer sent event
• Register register = 1;
• //producer events common.
• Block block = 2;
• ChaincodeEvent chaincodeEvent = 3;
• Rejection rejection = 4;
• //Unregister consumer sent events
• Unregister unregister = 5;
• }}
• messageChaincodeEvent {

• string chaincodeID = 1;
• string txID = 2;
• string eventName = 3;
• bytes payload = 4;

•}
•Once developed and deployed, there are two
ways to interact with the chaincode - through an
SDK or the CLI.
Command Line Interfaces
• To view the currently available CLI commands, execute the following:
•# this assumes that you have correctly set the
GOPATH variable and cloned the Fabric codebase
into that path
• cd /opt/gopath/src/github.com/hyperledger/fabric
• build /bin/peer
•The peer command supports several
subcommands and flags. To facilitate its use in
scripted applications, the peer command always
produces a non-zero return code in the event of
command failure. Upon success, many of the
subcommands produce a result on stdout as
shown in the table below:
Command stdout result in the event of success

version String form of peer.version defined in core.yaml

node start N/A

node status String form of StatusCode

node stop String form of StatusCode

chaincode deploy The chaincode container name (hash) required for subsequent chaincode invoke and
chaincode query commands

chaincode invoke The transaction ID (UUID)

chaincode query By default, the query result is formatted as a printable

channel create Create a chain

channel join Adds a peer to the chain

Chaincode lifecycle
• In some scenarios, multiple entities must agree on a chaincode before it can be used. Each entity
must be able to review the source code of the chaincode and sign it to prevent tampering. The
package format used to pass around the chaincode implementation is called
ChaincodeDeploymentSpec, which includes the source code, the policies for instantiating (setting
up and running) the chaincode application, and the list of entities that have agreed on the
chaincode.
• Once a chaincode has been properly endorsed, it can be installed and instantiated on Peers in the
network. During the instantiation process, the Peer uses Docker to run a container with the
chaincode inside. The Peer is responsible for managing the chaincode container’s lifecycle and
networking.
Chaincode Swimlanes
Deploy a chaincode
•[WIP] - the CLI commands need to be refactored
based on the new deployment model. Channel
Create and Channel Join will remain the same.
System Chaincode
• There’s a special kind of chaincode that follows a different lifecycle. System chaincode runs as
part of the Peer process, not in a separate container. It’s used to implement low-level ledger
features like the endorser system, query system, and validation system. Because these features
are so fundamental, the system chaincodes that implement them are deployed when the Peer
starts (instead of being dynamically added later like other chaincodes).
Hyperledger Composer Tool
• Hyperledger Composer is an extensive, open development toolset and framework to make
developing blockchain applications easier. Our primary goal is to accelerate time to value, and
make it easier to integrate your blockchain applications with the existing business systems.
Composer can be used to rapidly develop use cases and deploy a blockchain solution in weeks
rather than months. Composer allows to model business network and integrate existing systems
and data with your blockchain applications.
• Hyperledger Composer supports the existing Hyperledger Fabric blockchain infrastructure and
runtime, which supports pluggable blockchain consensus protocols to ensure that transactions
are validated according to policy by the designated business network participants.
• Everyday applications can consume the data from business networks, providing end users with
simple and controlled access points.
• Hyperledger Composer can be used to quickly model current business network, containing your
existing assets and the transactions related to them; assets are tangible or intangible goods,
services, or property. As part of your business network model, you define the transactions which
can interact with assets. Business networks also include the participants who interact with them,
each of which can be associated with a unique identity, across multiple business networks.
Hyperledger Composer Tool
• For an example of a business network in action; a realtor can quickly model their business
network as such:
• Assets: houses and listings
• Participants: buyers and homeowners
• Transactions: buying or selling houses, and creating and closing listings
• Participants can have their access to transactions restricted based on their role as either a buyer,
seller, or realtor.
• The realtor can then create an application to present buyers and sellers with a simple user
interface for viewing open listings and making offers.
• This business network could also be integrated with existing inventory system, adding new houses
as assets and removing sold properties. Relevant other parties can be registered as participants,
for example a land registry might interact with a buyer to transfer ownership of the land.
Hyperledger Composer Tool : Components
• Hyperledger Composer includes the following main components:
1) Business Network Archive: Capturing the core data in a business network, including the business
model, transaction logic and access controls, the Business Network Archive packages these
elements up and deploys them to a runtime.
2) Composer Playground: This Web- based tool allows developers to learn Hyperledger Composer,
model out their business network, test that network and deploy that network to a live instance of a
blockchain network. Composer playground offers a repository of sample business networks that can
provide a base for building your own business network.
3) REST API support and integration capabilities: A LoopBack connector for business networks has
been developed that exposes a running network as a REST API which can easily be consumed by
client applications and integrate non-blockchain applications.
Hyperledger Composer Tool : Key Concepts
• Blockchain State Storage
• All transactions submitted through a business network are stored on the blockchain ledger,
and the current state of assets and participants are stored in the blockchain state database.
The blockchain distributes the ledger and the state database across a set of peers and
ensures that updates to the ledger and state database are consistent across all peers using a
consensus algorithm.
• Connection Profiles
• Hyperledger Composer uses Connection Profiles to define the system to connect to. A
connection profile is a JSON document the is part of a business network card. These profiles
are usually provided by the creator of the system they refer to and should be used to create
business network cards in order to be able to connect to that system.
Hyperledger Composer Tool : Key Concepts
• Assets
• Assets are tangible or intangible goods, services, or property, and are stored in registries. Assets
can represent almost anything in a business network, for example, a house for sale, the sale
listing, the land registry certificate for that house, and the insurance documents for that house
may all be assets in one or more business networks.
• Assets must have a unique identifier, but other than that, they can contain whatever properties
you define. Assets may be related to other assets or participants.
• Participants
• Participants are members of a business network. They may own assets and submit transactions.
Participant types are modeled, and like assets, must have an identifier and can have any other
properties as required. A participant can be mapped to one or multiple identities.
• Identities
• An identity is a digital certificate and private key. Identities are used to transact on a business
network and must be mapped to a participant in the business network. A single identity is stored
in a business network card and if that identity has been mapped to a participant, it allows the
user of that business network card to transact on a business network as that participant.
Hyperledger Composer Tool : Key Concepts
• Business Network cards
• Business network cards are a combination of an identity, a connection profile, and metadata, the
metadata optionally containing the name of the business network to connect to. Business
network cards simplify the process of connecting to a business network, and extend the concept
of an identity outside the business network to a 'wallet' of identities, each associated with a
specific business network and connection profile.
• Transactions
• Transactions are the mechanism by which participants interact with assets. This could be as
simple as a participant placing a bid on a asset in an auction, or an auctioneer marking an auction
closed, automatically transferring ownership of the asset to the highest bidder.
 Hyperledger Composer Tool : Key Concepts
• Queries
• Queries are used to return data about the blockchain world-state. Queries are defined within a
business network, and can include variable parameters for simple customization. By using queries,
data can be easily extracted from your blockchain network. Queries are sent by using the
Hyperledger Composer API.
•
• Events
• Events are defined in the business network definition in the same way as assets or participants. Once
events have been defined, they can be emitted by transaction processor functions to indicate to
external systems that something of importance has happened to the ledger. Applications can
subscribe to emitted events through the composer-client API.
 Hyperledger Composer Tool : Key Concepts
• Queries
• Queries are used to return data about the blockchain world-state. Queries are defined within a
business network, and can include variable parameters for simple customization. By using queries,
data can be easily extracted from your blockchain network. Queries are sent by using the
Hyperledger Composer API.
•
• Events
• Events are defined in the business network definition in the same way as assets or participants. Once
events have been defined, they can be emitted by transaction processor functions to indicate to
external systems that something of importance has happened to the ledger. Applications can
subscribe to emitted events through the composer-client API.
 Hyperledger Composer Tool : Key Concepts
• Access Control
• Business networks may contain a set of access control rules. Access control rules allow fine-grained
control over what participants have access to what assets in the business network and under what
conditions. The access control language is rich enough to capture sophisticated conditions
declaratively, such as "only the owner of a vehicle can transfer ownership of the vehicle".
Externalizing access control from transaction processor function logic makes it easier to inspect,
debug, develop and maintain.

• Historian registry
• The historian is a specialised registry which records successful transactions, including the
participants and identities that submitted them. The historian stores transactions as HistorianRecord
assets, which are defined in the Hyperledger Composer system namespace.
Hyperledger Composer Tool : Architecture
• With the help from Hyperledger Composer sample application, any developer or architect can
easily create a fully functioning blockchain network.
• For example, REST API for connecting mobile or web applications to any blockchain business logic,
any kind of business logic that runs on the blockchain, integration of existing enterprise database
with the new decentralized solution, etc.
• In the Hyperledger Composer architecture, there are a total of eight high-level component’s that
you need to know about. Let’s see what they are –
• Execution Runtimes
• REST Server
• Command Line Interface
• JavaScript SDK
• VSCode and Atom editor plugins
• Yeoman code generator
• Playground Web User Interface
• LoopBack Connector
 Hyperledger Composer Tool : Architecture
• Execution Runtimes
• In the Hyperledger Composer sample application, it offers different pluggable runtimes. Moreover, it now
has mainly three implementations of runtime –
• Hyperledger Fabric v1.2. Here, the state storage is on the distributed ledger.
• Embedded runtime implementation. Here, the runtime executes within a Node.js process. However, this
one is mainly suited for unit testing of business logic. Moreover, the State is in the in-memory key-value
store.
• Web runtime implementation. Here, it executes in a web page and mainly works in Playground.
Moreover, here, the State is in the local browser history.
• Connection Profiles
• In reality, the connection profiles mainly help to determine how to link up with the execution runtime.
Furthermore, there is plenty of configuration for every type of execution runtime.
• For example, if you use the Hyperledger Fabric vs. 1.2 runtimes, then it will have TCP/IP ports and
addresses of the Fabric peers. Moreover, it would also have cryptographic certificates and many more.
• As you already know that Connecting profiles are a part of Business network card and Hyperledger
Composer sample application.
 Hyperledger Composer Tool : Architecture
• JavaScript SDK
• Within the Hyperledger Composer sample application, there’s JavaScript SDK. In reality, the JavaScript
SDK is a set of different Node.js APIs. These APIs help developers to create new applications that can
interact and manage the created business network.
• The APIs are usually divided into two npm modules –
• Composer-admin: Here, it manages the business network such as upgrading, starting, or installing.
• Composer-client: This one mainly performs read, delete, create, and update operations on participants
and assets. Additionally, it also submits transactions on the business network.
 Hyperledger Composer Tool : Components of
sample application
• Composer-client
• In reality, this module is basically installed on the local dependency of any application. With its help, you
can connect to participants, assets, or submit transaction of a business network. So, this module is
extremely necessary.
• When your network would be in production, you would need this module to add a direct dependency of
that application.

• Composer-admin
• Anyhow, the admin module would follow the same footsteps as client one, but here it would be installed
on the administrative application. Using this module, anyone can create or deploy business networks or
change their definition.
 Hyperledger Composer Tool : Components of
sample application
• Command Line Interface
• The Command-line tool will help administrators or developers to manage or deploy business network definitions.
Thus, it’s also an important part of Hyperledger Composer sample application.

• REST Server
• Well, the REST server basically generates an Open API or Swagger REST API for the business network. The whole
process of generating it happens automatically. Moreover, the REST server would convert the composer model for the
business network using an Open API definition.
• Anyhow, the runtime mainly reads, deletes, updates and creates participants and assets, which allows transactions to
be processed or submitted.
 Hyperledger Composer Tool : Components of
sample application
• LoopBack Connector
• Basically, the REST server uses the LoopBack Connector. However, many integration tools can use it in
standalone is those support LoopBack natively. Additionally, the LoopBack tools can also use it for a more
advanced level of customization of REST APIs.
•
• Playground Web User Interface
• This one is relatively important in architecture. In reality, it’s a web user interface for testing and defining
business networks. Moreover, it ensures that a business analyst would prototype or sample business logic
that runs on the Fabric runtime or web.
 Hyperledger Composer Tool : Components of
sample application
• Yeoman Code Generators
• The Yeoman Code generator is an open-source framework that generates the skeleton of any project such
as –
• js application
• Angular web application
• Skeleton business network
•
• VSCode and Atom Editor Extensions
• Editor extensions of VSCode and Atom are actually the contribution of the vast Composer community.
Anyhow, the VSCode is a super powerful extension that can validate ACL files or Composer models. It can
also offer syntax highlighting, snippet support, and error detection.
• On the other hand, the Atom plugin is more of a basic level and can only highlight syntax.