Hyperledger

Nodes Scalability
Overview of Hyperledger Fabric
• Better reflect business processes by specifying who endorses transactions
• Support broader regulatory requirements for privacy and confidentiality
• Scale the number of participants and transaction throughput
• Eliminate non deterministic transactions
• Support rich data queries of the ledger
• Dynamically upgrade fabric and chaincode
• Support for multiple credential and cryptographic services for identity
• Support for ”bring your own identity”
Efficient processing
• Hyperledger Fabric assigns network roles by node type.
• To provide concurrency and parallelism to the network, transaction execution is separated
from transaction ordering and commitment.
• Executing transactions prior to ordering them enables each peer node to process multiple
transactions simultaneously.
• This concurrent execution increases processing efficiency on each peer and accelerates
delivery of transactions to the ordering service.
• the division of labor unburdens ordering nodes from the demands of transaction
execution and ledger maintenance, while peer nodes are freed from ordering (consensus)
workloads.
• This bifurcation of roles also limits the processing required for authorization and
authentication; all peer nodes do not have to trust all ordering nodes, and vice versa, so
processes on one can run independently of verification by the other
Endorsement, Ordering and
Validation
• Nodes and roles
Privacy and confidentiality
• Hyperledger Fabric enables competing business interests, and any
groups that require private, confidential transactions, to coexist on
the same permissioned network.
• Private channels are restricted messaging paths that can be used to
provide transaction privacy and confidentiality for specific subsets of
network members.
• All data, including transaction, member and channel information, on a
channel are invisible and inaccessible to any network members not
explicitly granted access to that channel.
What is an Digital Identity?
• Its a digital identity encapsulated in an X.509 digital certificate
• Determine the exact permissions over resources and access to
information that actors have in a blockchain network.
• Principal
• userIDs or groupIDs,
• the actor’s organization, organizational unit, role or even the actor’s specific
identity
• For an identity to be verifiable, it must come from a trusted authority
• A membership service provider (MSP) is how this is achieved in Fabri
Membership Service Provider
(MSP)
• MSP is a component that defines the rules that govern the valid
identities for this organization
• Default MSP implementation in Fabric uses X.509 certificates as
identities, adopting a traditional Public Key Infrastructure (PKI)
hierarchical model
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

There are four key elements to PKI:

• Digital Certificates
• Public and Private Keys
• Certificate Authorities
• Certificate Revocation Lists
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
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
• “integrity” means that cannot have been modified during its transmission
• Authentication mechanisms rely on digital signatures
• The unique relationship between a private key and the respective
public key is the cryptographic magic that makes secure
communications possible
Authentication, Public keys, and
Private Keys
Certificate Authorities
• 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
• CAs are a common part of internet security protocols
• Symantec (originally Verisign),
• GeoTrust,
• DigiCert,
• GoDaddy, and
• Comodo
Root CAs, Intermediate CAs and
Chains of Trust
• CAs come in two flavors: Root CAs and Intermediate Cas
• Root CAs (Symantec, Geotrust, etc) have to securely distribute hundreds of
millions of certificates to internet users
• Intermediate CAs have their certificates issued by the root CA
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.
Certificate Revocation Lists
CA knows to be revoked for one reason or another
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.
Membership
• 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
• through a combination of both.
• An MSP can identify specific roles an actor might play either within the
scope of the organization the MSP represents
• 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).
channel MSP
• 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).
Organizational Units and MSPs
• An organization is often divided up into multiple organizational units
(OUs) to reflect these separate lines of business
• ORG1-MANUFACTURING
• ORG1-DISTRIBUTION
• When a CA issues X.509 certificates, the OU field in the certificate
specifies the line of business to which the identity belongs.
Local and Channel MSPs(1/2)
• 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
• 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
• peer admins will not necessarily be channel admins, and vice versa
Local and Channel MSPs(2/2)-
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
• 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.
• Local MSPs are only defined on the file system of the node or user to which
they apply
Local and Channel MSPs
MSP Levels
• MSPs are mandatory at every level of administration — they must be
defined for the network, channel, peer, orderer, and users.
• MSPs at a higher level relating to network administration concerns
• MSPs at a lower level handle identity for the administration of private
resources.
MSP Levels
• 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
• Peer MSP: This local MSP is defined on the file system of each peer and there is a single MSP instance for
each peer
• Same as channel but only applies to the peer where it is defined
• Orderer MSP: defined on the file system of the node and only applies to that node
• owned by a single organization and therefore have a single MSP to list the actors or nodes it trusts.
MSP Structure
Identity management
• To enable permissioned networks, Hyperledger Fabric provides a
membership identity service that manages user IDs and authenticates
all participants on the network.
• Access control lists can be used to provide additional layers of
permission through authorization of specific network operations.
• For example, a specific user ID could be permitted to invoke a
chaincode application, but be blocked from deploying new chaincode.
Transaction and Identity Privacy
Enrollment Certificates, Ecerts
• Long term identity
• Can be obtained offline, bring-your-own-identity
Transaction Certificates, Tcerts
• Disposable certificates, typically used once, requested from Transaction CA
• Tcert derived from long term identity - Enrollment Certificate, Ecert
• Only Transaction CA can link Ecert and Tcert
Permissioned Interactions
• Users sign with either Ecerts or Tcerts
Membership Services
• Abstract layer to credential providers
Chaincode functionality
• Chaincode that defines parameters for a change of asset ownership, for
example, ensures that all transactions that transfer ownership are subject
to the same rules and requirements.
• Chaincode applications encode logic that is invoked by specific types of
transactions on the channel.
• System chaincode is distinguished as chaincode that defines operating
parameters for the entire channel.
• Lifecycle and configuration system chaincode defines the rules for the
channel;
• endorsement and validation system chaincode defines the requirements
for endorsing and validating transactions.
Modular design
• Hyperledger Fabric implements a modular architecture to provide
functional choice to network designers.

• Specific algorithms for identity, ordering (consensus) and encryption,

for example, can be plugged in to any Hyperledger Fabric network.

• The result is a universal blockchain architecture that any industry or

public domain can adopt, with the assurance that its networks will be
interoperable across market, regulatory and geographic boundaries.
Hyperledger Fabric
Model
Hyperledger Fabric Model
Assets—Asset definitions enable the exchange of almost anything with
monetary value over the network, from
whole foods to antique cars to currency futures.
• Chaincode—Chaincode execution is partitioned from transaction
ordering, limiting the required levels of trust
and verification across node types, and optimizing network scalability
and performance.
• Ledger Features — The immutable, shared ledger encodes the entire
transaction history for each channel, and includes SQL-like query
capability for efficient auditing and dispute resolution.
Hyperledger Fabric Model
• Privacy — Channels and private data collections enable private and
confidential multi-lateral transactions that
are usually required by competing businesses and regulated industries
that exchange assets on a common network.
• Security & Membership Services — Permissioned membership
provides a trusted blockchain network, where
participants know that all transactions can be detected and traced by
authorized regulators and auditors.
• Consensus— A unique approach to consensus enables the flexibility
and scalability needed for the enterprise.
Ledger
• The ledger is the sequenced, tamper-resistant record of all state transitions
in the fabric. State transitions are a result of chaincode invocations
(‘transactions’) submitted by participating parties.
• Each transaction results in a set of asset key-value pairs that are committed
to the ledger as creates, updates, or deletes.
• The ledger is comprised of a blockchain (‘chain’) to store the immutable,
sequenced record in blocks, as well as a state database to maintain current
fabric state.
• There is one ledger per channel.
• Each peer maintains a copy of the ledger for each channel of which they are
a member.
Ledger Features (1/2)
• Query and update ledger using key-based lookups, range queries, and composite
key queries
• Read-only queries using a rich query language (if using CouchDB as state database)
• Read-only history queries— Query ledger history for a key, enabling data
provenance scenarios
• Transactions consist of the versions of keys/values that were read in chaincode
(read set) and keys/values that were written in chaincode (write set)
• Transactions contain signatures of every endorsing peer and are submitted to
ordering service
• Transactions are ordered into blocks and are “delivered” from an ordering service
to peers on a channel
Ledger Features(2/2)
• Peers validate transactions against endorsement policies and enforce
the policies
• Prior to appending a block, a versioning check is performed to ensure
that states for assets that were read have not changed since chaincode
execution time
• There is immutability once a transaction is validated and committed
• A channel’s ledger contains a configuration block defining policies,
access control lists, and other pertinent information
• Channels contain Membership Service Provider(MSP) instances allowing
for crypto materials to be derived from different certificate authorities
Privacy(1/2)
• Hyperledger Fabric employs an immutable ledger on a per-channel basis,
• The chaincode that can manipulate and modify the current state of assets (i.e. update key-value pairs).
• A ledger exists in the scope of a channel —
• it can be shared across the entire network or
• it can be privatized to include only a specific set of participants.
• in 2nd Scenairo participants would create a separate channel and thereby isolate/segregate their transactions
and ledger.
• In order to solve scenarios that want to bridge the gap between total transparency and privacy,
• chaincode can be installed only on peers that need to access the asset states to perform reads and writes
• (in other words, if a chaincode is not installed on a peer, it will not be able to properly interface with the ledger).
• When a subset of organizations on that channel need to keep their transaction data confidential, a private data
collection (collection) is used to segregate this data in a private database, logically separate from the channel
ledger, accessible only to the authorized subset of organizations.
• Thus,
• Channels keep transactions privatefrom the broader network
• Collections keep data private between subsets of organizations on the channel.
Privacy(2/2)
• To further obfuscate the data,
• Values within chaincode can be encrypted (in part or in total) using common
cryptographic algorithms such as AES before sending transactions to the
ordering service and appending blocks to the ledger.
• Once encrypted data has been written to the ledger, it can be decrypted only
by a user in possession of the corresponding key that was used to generate
the cipher text.
Security & Membership Services
• Hyperledger Fabric underpins a transactional network where all
participants have known identities
• Public Key Infrastructure is used to generate cryptographic certificates
which are tied to
• organizations,
• network components,
• and end users or client applications
• The Data access control can be manipulated and governed on the
broader network and on channel levels.
Consensus(1/3)
• Consensus is defined as the full-circle verification of the
correctness of a set of transactions comprising a block.
• Consensus is achieved ultimately when the order and results of a block’s transactions have
met the explicit policy criteria checks.
• These checks and balances take place during the lifecycle of a transaction, and include the
usage of endorsement policies to dictate which specific members must endorse a certain
transaction class, as well as system chaincodes to ensure that these policies are enforced
and upheld.

• Prior to commitment, the peers will employ these system chaincodes to make sure that
enough endorsements are present, and that they were derived from the appropriate
entities.
Consensus(2/3)
• Versioning check will take place during which the current state of the
ledger is agreed or consented upon, before any blocks containing
transactions are appended to the ledger.

• This final check provides protection against double spend operations

and other threats that might compromise data integrity, and allows
for functions to be executed against non-static variables.
Consensus(2/3)
• Access control lists are implemented on hierarchical layers of the
network (ordering service down to channels), and payloads are
repeatedly signed, verified and authenticated as a transaction
proposal passes through the different architectural components.

• Consensus is the verifications that take place during a transaction’s

journey from proposal to commitment.
Consensus(3/3)
• Versioning check will take place during which the current state of the
ledger is agreed or consented upon, before any blocks containing
transactions are appended to the ledger.

• This final check provides protection against double spend operations

and other threats that might compromise data integrity, and allows
for functions to be executed against non-static variables.
Blockchain network
What is a blockchain network?
• A blockchain network is a technical infrastructure that provides ledger
and smart contract (chaincode) services to applications.
• The users of applications might be end users using client applications
or blockchain network administrators.
• Multiple organizations come together as a consortium to form the
network and their permissions are determined by a set of policies
that are agreed by the consortium when the network is originally
configured.
• Network policies can change over time subject to the agreement of
the organizations in the consortium,
The sample network
• Four organizations, R1, R2, R3 and R4 set up Hyperledger Fabric network.
• R4 has been assigned to be the network initiator – it has been given the power to set up the initial version of
the network.
• R4 has no intention to perform business transactions on the network.
• R1 and R2 have a need for a private communications within the overall network, as do R2 and R3.
• Organization R1 has a client application that can perform business transactions within channel C1.
• Organization R2 has a client application that can do similar work both in channel C1 and C2.
• Organization R3 has a client application that can do this on channel C2.
• Peer node P1 maintains a copy of the ledger L1 associated with C1.
• Peer node P2 maintains a copy of the ledger L1 associated with C1 and a copy of ledger L2 associated with C2.
• Peer node P3 maintains a copy of the ledger L2 associated with C2.
• The network is governed according to policy rules specified in network configuration
• NC4, the network is under the control of organizations R1 and R4. Channel C1 is governed according to the
policy rules specified in channel configuration CC1; the channel is under the control of organizations R1 and R2.
The sample network
• Channel C1 is governed according to the policy rules specified in channel
configuration CC1; the channel is under the control of organizations R1 and
R2.
• Channel C2 is governed according to the policy rules specified in channel
configuration CC2; the channel is under the control of organizations R2 and
R3.
• There is an ordering service O4 that services as a network administration
point for N, and uses the system channel.
• The ordering service also supports application channels C1 and C2, for the
purposes of transaction ordering into blocks for distribution.
• Each of the four organizations has a preferred Certificate Authority.
The sample network
Creating the Network
Creating the • Creating the Network
Network
Ordering service comprising a single
node, O4, is configured according to a
network configuration NC4, which gives
administrative rights to organization R4.
At the network level, Certificate Authority
CA4 is used to dispense identities to the
administrators and network nodes of the R4
organization.
Certificate Authorities
• CA4 plays a key role in our network because it dispenses X.509
certificates that can be used to identify components as belonging to
organization R4.
• Certificates issued by CAs can also be used to sign transactions to
indicate that an organization endorses the transaction result – a
precondition of it being accepted onto the ledger
• Aspects of a CA
• Identify themselves to each other as being from a particular organization
Creating the • Adding Network Administrators
Network
Organization R4 updates the network configuration to make organization R1 an
administrator too.
After this point R1 and R4 have equal rights over the network configuration.
R1 as an administrator – R1 and R4 now have equal rights over the network.
We can also see that certificate authority CA1 has been added – it can be used to
identify users from the R1 organization.
After this point, users from both R1 and R4 can administer the network.
Although the orderer node, O4, is running on R4’s infrastructure, R1 has shared
administrative rights over it, as long as it can gain network access.
It means that R1 or R4 could update the network configuration NC4 to allow the R2
organization a subset of network operations.
In this way, even though R4 is running the ordering service, and R1 has
full administrative rights over it, R2 has limited rights to create new consortia.
Ordering services are usually multi-node, and can be configured to have different
nodes in different organizations. we might run O4 in R4 and connect it to O2, a
separate orderer node in organization R1. In this way, we would have a multi-site,
multi-organization administration structure
Creating the • Defining a Consortium
Network
A network administrator defines a consortium X1 that
contains two members, the organizations R1 and R2.
This consortium definition is stored in the network
configuration NC4, and will be used at the next stage of
network development.

CA1 and CA2 are the respective Certificate Authorities for

these organizations.
NC4 is configured, only R1 or R4 can create new consortia
Creating the • Creating a channel for a
Network consortium
A channel C1 has been created for R1 and R2 using the
consortium definition X1.
The channel is governed by a channel configuration CC1,
completely separate to the network configuration.
CC1 is managed by R1 and R2 who have equal rights over C1.
R4 has no rights in CC1 whatsoever.
it is for transaction processing between R1 and R2.
R4 also allowed R1 to create channels.
R3 and R4 have no permissions in this channel.
R3 and R4 can only interact with C1 if they are added by R1 or R2
to the appropriate policy in the channel configuration CC1.
the data in a channel is completely isolated from the rest of the
network, including other channels.
Peers and Ledgers
• A peer node P1 has joined the channel C1.
• P1 physically hosts a copy of the ledger L1.
• P1 and O4 can communicate with each other using channel C1.
• L1 as being physically hosted on P1, but logically hosted on the channel C1.
• A key part of a P1’s configuration is an X.509 identity issued by CA1 which associates P1 with organization R1.
• Once P1 is started, it can join channel C1 using the orderer O4.
• When O4 receives this join request, it uses the channel configuration CC1 to determine P1’s permissions on this channel.
• CC1 determines whether P1 can read and/or write information to the ledger L1
Applications and Smart Contract chaincode
• A smart contract S5 has been installed onto P1.
• Client application A1 in organization R1 can use S5 to access the ledger via peer node P1.
• A1, P1 and O4 are all joined to channel C1, i.e. they can all make use of the communication facilities provided by that
channel.
• It might now appear that A1 can access the ledger L1 directly via P1, but in fact, all access is managed via a special
• program called a smart contract chaincode, S5.
• S5 as defining all the common access patterns to the ledger; S5 provides a well-defined set of ways by which the ledger L1
can be queried or updated
client applicationA1 has to go through smart contract S5 to get to ledger L1!
Installing a smart contract
• An administrator in organization R1 must install it onto peer node P1
• P1 has full knowledge of S5 and see the implementation logic of S5
• S5 interface describes the inputs and outputs of S5, without regard to
its implementation
• When an organization has multiple peers in a channel, it can choose
the peers upon which it installs smart contracts; it does not need to
install a smart contract on every peer.
Instantiating a smart contract
• An administrator in organization R1 must instantiate S5 on channel C1
using P1.
• Although every component on the channel can now access S5, they
are not able to see its program logic.
• installing a smart contract shows how we think of it being physically
hosted on a peer, whereas
• instantiating a smart contract shows how we consider it logically
hosted by the channel
Endorsement policy
• It describes which organizations must approve transactions before
they will be accepted by other organizations onto their copy of the
ledger.
• In sample network, transactions can only be accepted onto ledger L1 if R1 or
R2 endorse them.
Invoking a smart contract
• Once a smart contract has been installed on a peer node and
instantiated on a channel it can be invoked by a client application.
• Client applications do this by sending transaction proposals to peers
owned by the organizations specified by the smart contract
endorsement policy
• The transaction proposal serves as input to the smart contract, which
uses it to generate an endorsed transaction response, which is
returned by the peer node to the client application.
Network completed
R2 has added peer node P2, which hosts a copy of ledger L1, and chaincode S5.
P2 has also joined channel C1, as has application A2.
A2 and P2 are identified using certificates from CA2.
All of this means that both applications A1 and A2 can invoke S5 on C1 either using peer node P1 or P2.
Generating and accepting
transactions
• A peer can only run a smart contract if it is installed on it, but it can
know about the interface of a smart contract by being connected to a
channel.
• The peer nodes with smart contracts have a special power – to help
generate transactions
• Note that all peer nodes can validate and subsequently accept or
reject transactions onto their copy of the ledger L1.
• Only peer nodes with a smart contract installed can take part in the
process of transaction endorsement which is central to the
generation of valid transactions.
Types of peers
• Committing peer.
• Every peer node in a channel is a committing peer.
• It receives blocks of generated transactions, which are subsequently validated before they are committed to
the peer node’s copy of the ledger as an append operation.
• Endorsing peer.
• Every peer with a smart contract can be an endorsing peer if it has a smart contract installed.
• The smart contract on the peer must be used by a client application to generate a digitally signed transaction
response.
• Leader peer
• node which takes responsibility for distributing transactions from the orderer to the other committing peers in the
organization
• static or dynamic leadership selection
• Anchor peer
• to communicate with a peer in another organization
• An endorsement policy for a smart contract identifies the organizations whose peer should digitally
sign a generated transaction before it can be accepted onto a committing peer’s copy of the ledger.
Install not instantiate
• The organizations must install smart contract S5 onto its peer node
• The peer node must has a physical copy of the smart contract and the
ledger
• Instantiation only needs to happen once;
• Smart contract really exist in a physical manner on the peer nodes,
and a logical manner on the channel
• gossip protocol – will accommodate a large number of peer nodes in
support of such topologies.
 Peers
A blockchain network is comprised primarily of a set of peer
nodes (or, simply, peers). Peers are a fundamental element
of the network because they host ledgers and smart
contracts.
Multiple Ledgers
• A peer is able to host more than one ledger, which is helpful because
it allows for a flexible system design.
• The simplest configuration is for a peer to manage a single ledger, but
it’s absolutely appropriate for a peer to host two or more ledgers
when required
Multiple Chaincodes
• An example of a peer hosting multiple chaincodes. Each ledger can
have many chaincodes which access it.
• Peer P1 hosts ledgers L1 and L2, where L1 is accessed by chaincodes
S1 and S2, and L2 is accessed by S1 and S3. We can see that S1 can
access both L1 and L2.
Applications and Peers
• applications interact with peers to access the ledger
• Ledger-query interactions involve a simple three-step dialogue between an
application and a peer;
• ledger-update interactions are a little more involved, and require two extra steps
• The Fabric Software Development Kit (SDK) makes this easy for programmers
• its APIs enable applications
• to connect to peers,
• invoke chaincodes to generate transactions,
• submit transactions to the network that will get ordered
• and committed to the distributed ledger,
• and receive events when this process is complete
Applications and Peers
Peers and Channels
 Peers and Organizations

for simplicity, an orderer node is not shown in this

diagram.
Peers and Identity
Peers and Identity
• The mapping of identity to organization is provided by a component called a Membership
Service Provider (MSP)
• it determines how a peer gets assigned to a specific role in a particular organization and
accordingly gains appropriate access to blockchain resources
• everything that interacts with a blockchain network acquire their organizational identity
from their digital certificate and an MSP
• Peers, applications, end users, administrators and orderers must have an identity and an
associated MSP if they want to interact with a blockchain network
• We give a name to every entity that interacts with a blockchain network using an identity
— a principal.
• where the peer is physically located — it could reside in the cloud, or in a data centre
owned by one of the organizations, or on a local machine—it’s the identity associated
with it that identifies it as being owned by a particular organization
Peers and Orderers
• An update transaction is quite different from a query transaction
because a single peer cannot, on its own, update the ledger
• Updating requires the consent of other peers in the network
• Peers will notify their connected applications that the ledger has been
updated
• Applications that want to update the ledger are involved in a 3-phase
process
Update the ledger -3-phase process
• In the first phase,
• applications work with a subset of endorsing peers, each of which provide an
endorsement of the proposed ledger update to the application, but do not
apply the proposed update to their copy of the ledger.
• In the second phase,
• these separate endorsements are collected together as transactions and
packaged into blocks.
• In the final phase,
• these blocks are distributed back to every peer where each transaction is
validated before being applied to that peer’s copy of the ledger.
Phase 1: Proposal
Phase 2: Ordering and
packaging transactions into
blocks
• The second phase of the transaction workflow is the packaging phase.
The orderer is pivotal to this process —
• It receives transactions containing endorsed transaction proposal
responses from many applications, and orderes the transactions into
blocks.
Phase 3: Validation and commit
Phase 3: Validation and commit
• It’s also worth noting that not every peer needs to be connected to an orderer—peers can
cascade blocks to other peers using the gossip protocol
• Upon receipt of a block, a peer will process each transaction in the sequence in which it
appears in the block
• each peer will verify that the transaction has been endorsed by the required organizations
according to the endorsement policy of the chaincode which generated the transaction.
• In case the application violates the endorsement policy by sending wrong transactions, the
peer is still able to reject the transaction in the validation process of phase 3
• If a transaction has been endorsed correctly, the peer will attempt to apply it to the ledger.
• Failed transactions are not applied to the ledger, but they are retained for audit purposes, as
are successful transactions.
• Peer blocks are almost exactly the same as the blocks received from the orderer, except for a
valid or invalid indicator on each transaction in the block.
Smart Contracts and Chaincode
• a smart contract, together with the ledger, form the heart of a
Hyperledger Fabric blockchain system
• a smart contract defines the executable logic that generates new facts that are added
to the ledger
• A chaincode is typically used by administrators to group related smart contracts for
deployment, but can also be used for low level system programming of Fabric
• Hyperledger Fabric users often use the terms smart contract and chaincode
interchangeably
• Smart contract defines the transaction logic that controls the lifecycle of a business
object contained in the world state.
• It is then packaged into a chaincode which is then deployed to a blockchain network
• chaincode governs how smart contracts are packaged for deployment
 Smart contract
A smart contract defines the rules between different organizations in
executable code.
Applications invoke a smart contract to generate transactions that are
recorded on the ledger.
 Smart Contracts and Chaincode

A smart contract is defined within a chaincode. Multiple

smart contracts can be defined within the same chaincode.
When a chaincode is deployed, all smart contracts within it
are made available to applications
Ledger
• A blockchain immutably records transactions which update states in a
ledger
• A smart contract programmatically accesses two distinct pieces of the
ledger –
• a blockchain, which immutably records the history of all transactions, and
• a world state that holds a cache of the current value of these states, as it’s
the current value of an object that is usually required.
• Smart contracts primarily put, get and delete states in the world
state, and can also query the immutable blockchain record of
transactions.
Development
• Smart contracts are the focus of application development
• Deploying a chaincode to a network makes all its smart contracts
available to the organizations in that network.
• It means that only administrators need to worry about chaincode;
everyone else can think in terms of smart contracts.
• smart contract is a set of transaction definitions
async createCar(ctx, carNumber, make, model, color, owner) {
const car = {
color,
docType: 'car',
make,
model,
owner, };
await [Link](carNumber,
Endorsement
Valid transactions
• When a smart contract executes, it runs on a peer node owned by an
organization in the blockchain network.
• The contract takes a set of input parameters called the transaction proposal
and uses them in combination with its program logic to read and write the
ledger.
• Changes to the world state are captured as a transaction proposal response
which contains a read-write set with both the states that have been read,
and the new states that are to be written if the transaction is valid.

• Notice that the world state is not updated when the smart contract is
executed!
Valid transactions
• When a smart contract executes, it runs on a peer node owned by an
organization in the blockchain network.
• The contract takes a set of input parameters called the transaction proposal
and uses them in combination with its program logic to read and write the
ledger.
• Changes to the world state are captured as a transaction proposal response
which contains a read-write set with both the states that have been read,
and the new states that are to be written if the transaction is valid.

• Notice that the world state is not updated when the smart contract is
executed!
Valid transactions
• transaction that is distributed to all peer nodes in the network is
validated in two phases
• Firstly, the transaction is checked to ensure it has been signed by sufficient
organizations according to the endorsement policy.
• Secondly, it is checked to ensure that the current value of the world state
matches the read set of the transaction when it was signed by the endorsing
peer nodes; that there has been no intermediate update

• If a transaction passes both these tests, it is marked as valid. All

transactions are added to the blockchain history, whether valid or
invalid, but only valid transactions result in an update to the world state.
Channels
• Hyperledger Fabric allows an organization to simultaneously
participate in multiple, separate blockchain networks via channels.
• Channels provide an efficient sharing of infrastructure while
maintaining data and communications privacy
• An administrator defines an endorsement policy for a chaincode
when it is instantiated on a channel, and can change it when the
chaincode is upgraded
Channels-Example
Intercommunication
• Smart Contracts are able to call to other smart contracts both within
the same channel and across different channels.
• It this way, they can read and write world state data to which they
would not otherwise have access due to smart contract namespaces.
System chaincode
• The smart contracts defined within a chaincode encode the domain
dependent rules for a business process agreed between a set of
blockchain organizations.
• chaincode can also define low-level program code which corresponds
to domain independent system interactions, unrelated to these smart
contracts for business processes
Types of system chaincodes
• Lifecycle system chaincode (LSCC) runs in all peers to handle package
signing, install, instantiate, and upgrade chaincode requests.
• Configuration system chaincode (CSCC) runs in all peers to handle changes
to a channel configuration, such as a policy update.
Query system chaincode (QSCC) runs in all peers to provide ledger APIs
which include block query, transaction query etc. You can read more about
these ledger APIs in the transaction context topic.
• Endorsement system chaincode (ESCC) runs in endorsing peers to
cryptographically sign a transaction response.
• Validation system chaincode (VSCC) validates a transaction, including
checking endorsement policy and readwrite set versioning.
Ledger
• A ledger is a key concept in Hyperledger Fabric; it stores important
factual information about business objects; both the current value of
the attributes of the objects, and the history of transactions that
resulted in these current values.
• Ledger states are, by default, expressed as key-value pairs
World State
• The world state holds the current value of the attributes of a business
object as a unique ledger state.
• It would be cumbersome to traverse the entire blockchain to calculate
an object’s current value
• The key design point is that only transactions that are signed by the
required set of endorsing organizations will result in an update to the
world state
World State database options
• Options for the world state database currently include LevelDB and
CouchDB.
• LevelDB
• default and is particularly appropriate when ledger states are simple key-value pairs.
• closely co-located with a network node –
• it is embedded within the same operating system process.
• CouchDB
• particularly appropriate choice when ledger states are structured as JSON document
• supports the rich queries and update of richer data types often found in business
transactions.
• runs in a separate operating system process, but there is still a 1:1 relation between a
peer node and a CouchDB instance. All of this is invisible to a smart contract
Blockchain
Blocks
Transactions
Example Ledger: fabcar
The Ordering Service
• What is ordering?
• Fabric’s design relies on deterministic consensus algorithms
• any block a peer validates as generated by the ordering service is
guaranteed to be final and correct.
• Ledgers cannot fork the way they do in many other distributed
blockchains
• In addition to promoting finality, separating the endorsement of
chaincode execution from ordering gives Fabric advantages in
performance and scalability, eliminating bottlenecks which can occur
when execution and ordering are performed by the same nodes
Orderer nodes and channel
configuration
• In addition to their ordering role, orderers also maintain the list of
organizations that are allowed to create channels
• Orderers also enforce basic access control for channels, restricting
who can read and write data to them, and who can configure them
• The process the configuration transactions in order to verify that the
modifications approved by the orderer do indeed satisfy the policies
defined in the channel.
Orderers and the transaction
flow
• Phase one: Proposal
• a client application sends a transaction proposal to a subset of peers that
will invoke a smart contract to produce a proposed ledger update and then
endorse the results
• The endorsing peers do not apply the proposed update to their copy of the
ledger at this time
• Instead, the endorsing peers return a proposal response to the client
application
• The endorsed transaction proposals will ultimately be ordered into blocks in
phase two, and then distributed to all peers for final validation and commit
in phase three.
Orderers and the transaction
flow
• Phase two: Ordering and packaging transactions into blocks
• application clients submit transactions containing endorsed transaction proposal
responses to an ordering service node
• The ordering service creates blocks of transactions which will ultimately be
distributed to all peers on the channel for final validation and commit in phase three.
• Ordering service nodes receive transactions from many different application clients
concurrently.
• These ordering service nodes work together to collectively form the ordering service
• Its job is to arrange batches of submitted transactions into a well-defined sequence
and package them into blocks
• These blocks will become the blocks of the blockchain!
Orderers and the transaction
flow
Phase three: Validation and
commit
• Orderer distributing blocks to all peers connected to it
• It’s also worth noting that not every peer needs to be connected to an
orderer— peers can cascade blocks to other peers using the gossip
protocol,
• Each peer will validate distributed blocks independently, but in a
deterministic fashion, ensuring that ledgers remain consistent
Phase three: Validation and
commit
Ordering service
implementations
• Several different implementations for achieving consensus on the strict ordering of
transactions between ordering service nodes.
• Solo
• it features only a single ordering node
• it is not, and never will be, fault tolerant
• cannot be considered for production, but they are a good choice for testing applications
• Raft
• Raft is a crash fault tolerant (CFT) ordering service based on an implementation
• follows a “leader and follower” model
• a leader node is elected (per channel) and its decisions are replicated by the followers
• Raft ordering services should be easier to set up and manage than Kafka-based ordering
services,
• Design allows different organizations to contribute nodes to a distributed ordering service.
Ordering service
implementations-Kafka
Apache Kafka is a CFT implementation that uses a “leader and follower” node configuration

Kafka utilizes a ZooKeeper ensemble for management purposes

The Kafka based ordering service has been available since Fabric v1.0, but many users may find the additional administrative overhead of managing a Kafka cluster
intimidating or undesirable

Kafka and Zookeeper are not designed to be run across large networks

They are designed to be CFT but should be run in a tight group of hosts

Practically speaking you need to have one organization run the Kafka cluster

Kafka uses a pool of servers (called “Kafka brokers”)

Admin of the orderer organization specifies how many nodes they want to use on a particular channel
Raft concepts
• log consistent if a majority (a quorum, in other words) of members
Log entry. agree on the entries and their order, making the logs on the various
orderers replicated

• The ordering nodes actively participating in the consensus mechanism

Consenter set. for a given channel and receiving replicated logs for the channel.
• This can be all of the nodes available or a subset of those nodes

Finite-State • Every ordering node in Raft has an FSM and collectively they’re used to
ensure that the sequence of logs in the various ordering nodes is
Machine (FSM). deterministic
Raft concepts

• minimum number of consenters that need to affirm

a proposal so that transactions can be ordered.
• For every consenter set, this is a majority of nodes.
• In a cluster with five nodes, three must be available

Quorum for there to be a quorum.

• If a quorum of nodes is unavailable for any reason,
the ordering service cluster becomes unavailable
for both read and write operations on the channel,
and no new logs can be committed.
Raft concepts
• Leader.
• at any given time, a channel’s consenter set elects a single node to be
the leader
• The leader is responsible for ingesting new log entries, replicating
them to follower ordering nodes, and managing when an entry is
considered committed.
• This is not a special type of orderer.
• It is only a role that an orderer may have at certain times, and then
not others, as circumstances determine.
• Follower.
• followers receive the logs from the leader and replicate them
deterministically, ensuring that logs remain consistent.
• The followers also receive “heartbeat” messages from the leader.
• In the event that the leader stops sending those message for a
configurable amount of time, the followers will initiate a leader
election and one of them will be elected the new leader.
Raft in a transaction flow
• Every channel runs on a separate instance of the Raft protocol, which allows each instance to elect
a different leader.
• This configuration also allows further decentralization of the service in use cases where clusters
are made up of ordering nodes controlled by different organizations
• While all Raft nodes must be part of the system channel, they do not necessarily have to be part
of all application channels
• Channel creators (and channel admins) have the ability to pick a subset of the available orderers
and to add or remove ordering nodes as needed
• While this configuration creates more overhead in the form of redundant heartbeat messages and
goroutines, it lays necessary groundwork for BFT.
• Transactions are automatically routed by the ordering node that receives the transaction to the
current leader of that channel
• Peers and applications do not need to know who the leader node is at any particular time. Only
the ordering nodes need to know.
Raft Architectural- How leader
election works in Raft
• Raft nodes are always in one of three states: follower, candidate, or leader
• All nodes initially start out as a follower
• they can accept log entries from a leader (if one has been elected), or cast votes for leader
• If no log entries or heartbeats are received for a set amount of time nodes self-promote to
the candidate state
• In the candidate state, nodes request votes from other nodes. If a candidate receives a
quorum of votes, then it is promoted to a leader.
• The leader must accept new log entries and replicate them to the followers
• [Link]
• [Link]
• Raft uses a process called “snapshotting”, in which users can define how many bytes of
data will be kept in the log
Kafka
• Kafka uses the same conceptual “leader and follower” configuration
used by Raft
• The management of the Kafka cluster, including the coordination of
tasks, cluster membership, access control, and controller election,
among others, is handled by a ZooKeeper ensemble and its related
APIs
• Kafka clusters and ZooKeeper ensembles are notoriously tricky to set
up,
• [Link]
• [Link]
[Link]
What is private data?
• Fabric offers the ability to create private data collections, which allow
a defined subset of organizations on a channel the ability to endorse,
commit, or query private data without having to create a separate
channel.
What is a private data
collection?
• A collection is the combination of two elements:
• The actual private data, sent peer-to-peer via gossip protocol to only
the organization(s) authorized to see it
• This data is stored in a private state database on the peers of
authorized organizations “SideDB”
• which can be accessed from chaincode on these authorized peers.
• Private data peer-to-peer across authorized organizations
• it is required to set up anchor peers on the channel, and configure
• CORE_PEER_GOSSIP_EXTERNALENDPOINT on each peer
What is a private data
collection?
• A hash of that data, which is endorsed, ordered, and written to the
ledgers of every peer on the channel.
• The hash serves as evidence of the transaction and is used for state
validation and can be used for audit purposes.
• A hash of that data, which is endorsed, ordered, and written to the
ledgers of every peer on the channel
• Collection members may decide to share the private data with other
parties if they get into a dispute or if they want to transfer the asset
to a third party
Hyperledger Fabric
Composer
Setting up an ordering node

• Broadly, this topic will involve a few interrelated steps:

• Creating the organization your ordering node belongs to (if you have
not already done so)
• Configuring your node (using [Link])
• Creating the genesis block for the orderer system channel
• Bootstrapping the orderer
Create an organization
definition
• An organization that must be created before the orderer itself is
created
• This organization has a definition encapsulated by a
Membership Service Provider (MSP) that is created by a Certificate
Authority (CA) dedicated to creating the certificates and MSP for the
organization.
Configure your node

• The configuration of the orderer is handled through a yaml filed called [Link].
• The FABRIC_CFG_PATH environment variable is used to point to an [Link] file you’ve
configured, which will extract a series of files and certificates on your file system.
• LocalMSPID — this is the name of the MSP, generated by your CA, of your orderer organization.
This is where your orderer organization admins will be listed.
• LocalMSPDir — the place in your file system where the local MSP is located.
• # TLS enabled, Enabled: false. This is where you specify whether you want to enable TLS. If you set
this value to true, you will have to specify the locations of the relevant TLS certificates. Note that
this is mandatory for Raft nodes.
• GenesisFile — this is the name of the genesis block you will generate for this ordering service.
• GenesisMethod — the method by which the genesis block is created.
• This can be either file, in which the file in the GenesisFile is specified,
• If you are depland provisional, in which the profile in GenesisProfile is used.
• Other Sections: Kafka section, cluster of Raft nodes
Generate the genesis block of
the orderer
• Once you have built the images, created the MSP, configured your
[Link], and created the genesis block, you’re ready to start your
orderer using a command that will look similar to:
docker-compose -f [Link] up -d --no-deps [Link]
Updating a Channel
Configuration
• What is a Channel Configuration
• Channel configurations contain all of the information relevant to the
administration of a channel.
• Most importantly, the channel configuration specifies which
organizations are members of channel, but it also includes other
channel-wide configuration information such as channel access
policies and block batch sizes.
• This configuration is stored on the ledger in a block, and is therefore
known as a configuration (config) block
Configuration blocks
• Configuration blocks contain a single configuration.
• The first of these blocks is known as the “genesis block” and contains
the initial configuration required to bootstrap a channel
• Latest configuration block representing the current channel
configuration
• Orderers and peers keep the current channel configuration in
memory to facilitate all channel operations such as cutting a new
block and validating block transactions.
• pdating a config happens through a process called a “configuration
transaction”
Editing a Config

• Updating a config is a process of pulling the config, translating into a format that
humans can read, modifying it and then submitting it for approval.

• Batch Size. These parameters dictate the number and size of transactions in a block.
• No block will appear larger than absolute_max_bytes
• max_message_count transactions inside the block
• If it is possible to construct a block under preferred_max_bytes, then a block will be cut
prematurely, and transactions larger than this size will appear in their own block. {
"absolute_max_bytes": 102760448,
"max_message_count": 10,
"preferred_max_bytes": 524288
}
Batch Timeout.
• The amount of time to wait after the first transaction arrives for
additional transactions before cutting a block.
• Decreasing this value will improve latency, but decreasing it too much
may decrease throughput by not allowing the block to fill to its
maximum capacity. { "timeout": "2s" }
Channel Restrictions.
• The total number of channels the orderer is willing to allocate may be
specified as max_count.
• This is primarily useful in pre-production environments with weak
consortium ChannelCreation policies.
{
"max_count":1000
}
Channel Creation Policy.
• Defines the policy value which will be set as the mod_policy for the Application group
of new channels for the consortium it is defined in.
• The signature set attached to the channel creation request will be checked against the
instantiation of this policy in the new channel to ensure that the channel creation is
authorized. Note that this config value is only set in the orderer system channel.
{"type": 3,
"value": {
"rule": "ANY",
"sub_policy": "Admins"
}
}
Kafka brokers.
• When ConsensusType is set to kafka, the brokers list enumerates
some subset (or preferably all) of the Kafka brokers for the orderer to
initially connect to at startup. Note that it is not possible to change
your consensus type after it has been established (during the
bootstrapping of the genesis block).
{
"brokers": [
"kafka0:9092",
"kafka1:9092",
"kafka2:9092",
"kafka3:9092"
]
}
 Anchor Peers Definition. Defines the location of
the anchor peers for each Org.
{ "host": "[Link]", "port": 9051 }
Hashing Structure.

• The block data is an array of byte arrays.

• The hash of the block data is computed as a Merkle tree.
• This value specifies the width of that Merkle tree.
• For the time being, this value is fixed to 4294967295 which
corresponds to a simple flat hash of the concatenation of the
block data bytes.

{ "width": 4294967295 }
 Hashing Algorithm. The algorithm used for computing the hash values encoded
into the blocks of the blockchain. In particular, this affects the data hash, and the
previous block hash fields of the block. Note, this field currently only has one valid
value (SHA256) and should not be changed.

{ "name": "SHA256" }
Block Validation. This policy specifies the signature requirements for a block to be
considered valid. By default, it requires a signature from some member of the ordering org.

{ "type": 3, "value": { "rule": "ANY", "sub_policy": "Writers" } }

Orderer Address. A list of addresses where clients may invoke the
orderer Broadcast and Deliver functions. The peer randomly chooses among
these addresses and fails over between them for retrieving blocks.

{ "addresses": [ "[Link]" ] }