[Unit 5]

Hyper ledger Fabric

 Blockchain for Enterprise:
 Various industries looking for some of the existing platforms
and some of the solution that were being built at the time in
terms of the potential of technology.
 But none of them were really well suited for enterprise
application.
 It did not have the kind of security and privacy that was
wanted, it did not have the kind of scalability throughput
requirements that are needed and many other enterprise
requirements which will discuss next…So
 Where the enterprise looking at about this technology?
 What is the need for Blockchain and Enterprise?
 What are some of the requirements and high level overview?
 From an enterprise stand point what the technology means for
industries?
 Blockchain for Enterprise:
 Blockchain for Enterprise:

 Bitcoin is just one application of the underlying Blockchain

technology itself and this technology is much more powerful
than just the bitcoin application.
 So overall opportunity for Blockchain expands to multiple
industries like for financial services, for supply chain, for
logistics, for health care like these are lots of application.
 All of this go much beyond just as cryptocurrency or Bitcoin
that is looking at.
 What really this means for enterprises?
 Blockchain for Enterprise:
 Let’s step back when the internet was really picking up.
At that time what the internet really did for enterprises was
that it really made communication extremely simple, it made
it easy for people to digitize and automate their processes
and it made communication between a organization very
simple.
 So we moved away from pep having to use paper and having
to use other physical mode of communication to mode digital
modes.
 So you could send message, you can have a protocol that part
is execute between themselves.
 Example: how the payment system works today with banks,
suppose today I want to send say 100 dollars to a bank in the
US.
 Blockchain for Enterprise:

 Then I instruct my bank in India to transfer that 100

dollars to my friend bank in US. And it is not really these
2 banks that are involved, what ends of happening there
are probably 5 or 6 hops in between and the money then
finally eventually reaches to my friend at other
destination.
 This becomes very inefficient, very expensive and is also
vulnerable because there could be failure along the way
and when they have these failures, have to then be
manually reconciled.
 Blockchain for Enterprise:
 So we are looking at these many point to point interactions that
are happening in the current enterprise echo systems. And this is
true even for the let say the supply chain industry, you can think
of it as there is a supply or who is supplying certain things let say
automobile parts to manufacturer and there may be another
logistics provider, there may be bank involved for finances, all of
this become point to point interaction in today’s world.
 Blockchain for Enterprise:
 And that becomes very inefficient and expensive. So we want to
move from this very complex interactions, point to point
interactions to this world where all of these enterprise users they
are all doing business with each other Today. We want to bring
them together into one common platform where they are able to
share information in a secure manner amongst all of these
participants. So this is where the blockchain really comes in.
 Blockchain for Enterprise:
 So what the blockchain provides?
 It is a mechanism by which multiple enterprises can come to a
common shared platform where they can exchange information
with one another. This is all business information, for executing
their business processes. They can exchange business information
amongst one another in a shared, secured manner.
 Blockchain for Enterprise:

 And what happens in everyone in this equal system whoever

you need to know about this piece of information,
 we will immediately get excess to this information so in
some sense every node in this blockchain network is going to
store replicate copy of all the information that is getting
transacted.
 So think of each exchange of information being a transaction
and this transaction is going to get recorded on the
blockchain.
 So all of this nodes are the participants of the blockchain
they are going to record it on what we call as ledger.
 Blockchain for Enterprise:
 So all of this participants in the equal system are going to store
these transaction in a completely immutable log, it is an append
only log so you can only add transactions to this ledger.
 You can not temper with these transactions. And how these
transactions get added on the ledger is through a notion of
consensus.
 Blockchain for Enterprise:
 The consensus is an important
notion here where all the parties
agree that this is a legitimate
transaction that needs to get
added to the ledger and they all
simultaneously in a consistent
manner add that transaction on
to the ledger.
This completely auditable, fully
immutable log gives you the provenance.
So you have a full log of every transaction that is happened in the
sequence system and everyone has its copy so no one can cheat
another party and say that this transaction did not happen or I did
not perform the transaction so none of that is possible it gives you a
 Blockchain for Enterprise:

sense of immutability.
 So no one can change this in the future and it is also gives you
finality so once the transaction is performed it is there forever,
everyone can see that the transaction was performed.
 So this is the overall system and this ensures that we can
significantly reduce some of the inefficiencies that exist in
multiple echo system today.
 so what are some of the key concepts?
i.e 1) Shared ledger amongst all the participants in the network.
so this is an append only distributed system of record of all
transaction that are being performed on the network by any
participant.
 Blockchain for Enterprise:
1) Shared ledger amongst all the participants in the network.
so this is an append only distributed system of record of all
transaction that are being performed on the network by any
participant. So this is the shared ledger. So this is the distributed
system concept. how this ledger is maintained in the consistent
manner across all the participants is through a notion of consensus.
 Blockchain for Enterprise:
 Blockchain for Enterprise:
1) Shared ledger:
so this is a protocol that all the participants will perform, it is an
exchange of messages and they all agree that this is a valid
transaction that can be added on to the network and apart from
these notions there is also a notion of security.
 Some of this notions are not there in the bitcoin blockchain.
 Where we want to ensure that only certain participants can see
certain piece of information or they can only perform certain
kind of transactions and all of this transactions can secure, they
are authenticated and verifiable.
 There are many other notions of privacy.
 This is auditable may be even a regulator can come in and see
that all of these transactions are performed by valid users, they
are all authenticated and proper transactions to be performed on
this business network.
 Blockchain for Enterprise:
They can admit these transactions. This is very different
from what bitcoin taught about blockchain.
Another aspect is the 2) Notion of smart contracts:
apart from exchanging information amongst participants in
the network we are also executing business processes, that
is the smart contract, so it is the logic or the piece of
code written in traditional programming languages perhaps
that you can execute in a decentralized fashion so all of the
nodes in the network will actually execute this transaction,
they will compute the output state and the output state will
then get recorded to the ledger, if this is a valid transaction.
 In the bitcoin world again just as a comparison, the bitcoin
executes a very static smart contract, this is exactly execute
one smart contract which does not have the ability
 Blockchain for Enterprise:
2) Notion of smart contracts: for you to embed your own smart
contract and that smart contract in bitcoin is just being able to
determine who the owner of a particular bitcoin is and who
transferred how many bitcoin to another persons.
So that is the asset management in transfer is the only kind of
thing that you can do in bitcoin where we are looking for much
more richer set of transactions and business logic that we want
to embed into some of these transactions and shared ledger, smart
contracts, consensus and security all of these put together is what
as called a blockchain and putting these together is really a big
acknowledgeable advancement that we have come up with
blockchain together as a community.
It helps to reduce time for executing some of these transactions,
what was previously very manual process, it can now be
automated across organizations.
 Blockchain for Enterprise:
 It helps reduce cost, it helps reduce risk and it also enables new
business models.
 When we talk about some of the solutions that have been
enabled by blockchain we will look at some of these new
business models.
 Blockchain for Enterprise:
 So now in perspective of bitcoin vs enterprise blockchain
application just think of right hand end of this spectrum which
is 100% centralized.
 This is typical old distributed systems where it is just one
organization that is executing the entire application or your
system.
 Blockchain for Enterprise:
 And it is a centralized system of records. So that is one end of
these spectrum.
 The other end of the spectrum where may be bitcoin or other
permission less system belongs to completely decentralized
anyone can join the network, anyone can execute the
transaction, anyone can see what is going on so that is on the
fully decentralized permission less side.
 But for enterprise application we need something in slightly in
the middle where we want some of the Decentralized benefits
but with certain security privacy features with better scale and
so on.
 Here is the distinction in the bitcoin world. It looking for
completely censorship-resistant.
 Blockchain for Enterprise:
 So one should be able to prevent transaction from being
executed.
 So in a government or in regulatory authority should not be
able to say this transaction is not valid. So it were looking for
complete censorship-resistant.
 It were looking to scale to large number of nodes.
 So bitcoin today runs about 5000 or so and also looking for
one global blockchain i.e. one blockchain for entire world.
 In contrast for enterprise application we are interested in
security and privacy policies instead of scaling this many
number of nodes.
 And interested in the transaction throughput.
 The distinction is like if we take enterprise today it probably
 Blockchain for Enterprise:
 Blockchain for Enterprise:
in doing business with may be tens of other companies or
sometimes may be hundreds of other companies.
 It is very rarely that you are scaling even larger than that.
So we are looking to scale in the transaction throughput.
 We are looking at many interacting blockchain.
 Think of one blockchain entire world.
 Application for one blockchain network for particular
application and there is a different blockchain network for
another application and these two need to interact with each
other.
 So the requirements in some sense are very different so the
way we design these blockchain platforms going to be very
different from what bitcoin did but the overall underline
 Blockchain for Enterprise:
 properties remain same.
 It still want immutability, finality, consensus among all the
parties and want to run this in decentralized manner where no
single entity is in charge of managing the entire network.
 So the access is open in permission less setting to everyone in
the network.
 Whereas in Permissioned setting only looking for Permissioned
read write access where we can specify who can write a
particular piece of data, who can read the data that flexibility
is there.
 Permission-less VS Permissioned Blockchain :
Permission-less Permissioned
Access Open read/write access Permissioned
to database read/write access to database
Scale Scale to a large number Scale in terms of transaction
of nodes, but not in throughput, but to a large
transaction throughput number of nodes
Consen Proof of work/ proof of Closed membership consensus
sus stake algorithms
Identity Anonymous/pseudony Identities of nodes are known,
mous but transaction identities can
be private/
anonymous/pseudonymous
Asset Native assets Any asset/data/state
 Hyperledger Fabric :
 Hyperledger project is a new platform specially suited for
enterprise application.
 It is one of the fastest growing open source project under
Linux foundation.
 Hyperledger Fabric :
It involves 220 leading enterprise companies. The logos of all various
companies that are participate. Its includes large technological firms,
large financial companies, banks, healthcare companies and industries
specific companies who have joined these consortium to help promote
its mission in building enterprise grade blockchain platform.
 Hyperledger Fabric :
Hyperledger fabrics production grade was released in July 2017.
It has large number of organization contribution to it.
IBM is one of the largest contributor to it both in terms of code as
well as IP. There are many other projects that are also the part of this
Hyperledger consortium.
 Hyperledger Fabric :
 One of them is Hyperledger composer. This is gives you the set of
higher level abstraction for business users to come and develop
application on top of blockchain.
 So instead of being having to work with a details of blockchain
platform, work at higher level of abstraction where you can talk
about business concepts directly and encode that to run on
blockchain platform.
 It has many interesting features that you can model your business
network.
 You can talk about in terms of asset participants and transaction
rather than having to talk about low level variables & functions & so
on. And it is all exposed via APIs and can automatically generate
some of these APIs as well.
 Hyperledger Fabric :
 It also gives you the ability to integrate with the existing
systems of records.
 So blockchain in many of this enterprise application be just one
part of large application.
 So it might involve other database where you are storing data,
bring that on blockchain.
 Whatever is going to record on blockchain might want to
extract that out, your own analytics and visualization.
 So some of these capabilities are also pert of composer which is
fully open source, open governed.
 To see Hyperledger fabrics in deep, understand first some
of the actors in blockchain.
 Hyperledger Fabric :
 Some of the key concepts such as how the transaction is get
committed by all the peers in the blockchain network in a
consistent manner and everyone to be committing same
transaction in same order.
 Hyperledger Fabric :
 Hyperledger Fabric Architecture :
 The key components of the Hyperledger Fabric Architecture

 1) The membership service which is providing the notion of

identity for the users who are going to be transacting on the
blockchain so this identity is going to be the digital certificate
and users are going to use this digital certificate to sign that
transactions and submit them to blockchain and the benefit of
signing this transaction is
1) they authenticate with blockchain that they are legitimate users
2) They also ensures that they get right access privilege on
blockchain for the transaction they are performing.
 Hyperledger Fabric Architecture :
 Hyperledger Fabric Architecture :
 So from notion of access control, certain users are allowed to
perform certain transactions and if you do not have right access
then your transaction get rejected.
 So your certificate is having all that information about what
privilege you can have and what attributes you have and so on
and use that to transact on the blockchain.
 This certificate is comes from traditional certificate party.
 Fabric implements a certificate authority i.e. Fabric CA and
this certificate authority is optional.
 It issues the certificate with public key belongs to it having
this attributes and so on.
 Then the certificate authority is pluggable module so it is very
much possible for someone else to bring their own
 Hyperledger Fabric Architecture :
 certificate authority that issues the certificates.
 So bring External-CA(certificate Authority). If the internet
uses, CA for all the time whenever you have any secure
communication between to a website you are going to use
some notion of certificates.
 So this certificate authority can be external. There are large
number of organizations that provide these services and those
can be used as well and all of these relies on public key So you
do have public key and private key associated with you as a user
this private public key pair is used to authenticate with
Blockchain. Now the client application can be written in
absolutely any language of your choice and provide set of SDK
(Software Development Kit) to interact with blockchain.
 Hyperledger Fabric Architecture :
 So it is called as Hyperledger Fabric Client i.e. HFC and SDK
is available in multiple languages like python, JAVA node js etc.
so you can use any of those SDKs to perform your transaction
on blockchain.
 Peer is important component of blockchain so there can be
multiple organizations that are each running one or more peer.
 So it is possible that one organizations run multiple peers for
fault tolerance Reason.
 For just separating out different application and there are
multiple organizations that they are run in the network.
 There is ordering service also which can also be run by
multiple or one organization.
 The function provide by ordering service is to give totally
 Hyperledger Fabric Architecture :
 ordered set of transactions.
 So different peers might be submitting transactions to the
ordering service and ordering service over take this transactions
and put them in some order.
 This service is decentralized and transactions that are coming
in from the various peers need to be ordered by this ordering
service.
 So again it is possible that some of the peer running
organizations also have the own ordering service.
 So there might be the once, running some of these nodes, but
just for abstraction purposes, we have kept this separate
functions that any one perform.
 Peer is having many notions, the peer is going to maintain the
 Hyperledger Fabric Architecture :
 ledger, this is the leger of all the transactions where all the state
information is getting stored.
 It has the smart contract called as chain code, so this code is
running on blockchain itself.
 So every node in the network will be executing this chain codes.
 Once the transactions are getting committed on to the
Blockchain you can emit events those can be integrated with
existing system.
 Now peer itself can have each peer node. It can have one or
two functions so it can serves as endorser which is going to
execute the chain codes.
 With the copy of chain codes with it and by executing it signing
the output of that chain code.
 Hyperledger Fabric Architecture :
 Peer has identity on the Blockchain, it going to use its certificate
to sign this transaction saying that this is the output of this
transaction and I agree with this output. Once the ordering
Service comes back
with full order of
transactions then
each of this
Transactions need
to be committed on
to the blockchain
through this
committing function
of committer.
 Hyperledger Fabric Architecture :
 some peers are both endorser and committer whereas certain
other peers are only committers so might not execute the
transaction as such but whatever other peers have agreed as the
output of transaction will only commit.
 Some of the some of the roles that organization can take on is
1) All can be doing is just committing all the transaction that
others are performing i.e.
1) Committing peer : It maintains the ledger and the state but it
does not execute any transaction and it does not hold the
smart contract themselves.
2) Endorsing peer: this is a specialize notion so beyond just
committing all the transactions coming up with the output &
then agreeing whether this is legitimate transactions or not.
 Hyperledger Fabric Architecture :
2) Endorsing peer: So while executing the transaction need to
hold the copy of smart contract and executing it.
3) ordering node: apart from peers, have an ordering node
which approve the inclusion of truncation into a particular
block.
So order this transaction across the network from multiple
peers and communicate to all the peers what is the order in
which transaction must be committed.
This is a specialize notion so beyond just committing all the
transactions coming up with the output and then agreeing
whether this is legitimate transactions or not.
So while executing the transaction need to hold the copy of
smart contract and executing it.
 Hyperledger Fabric Architecture :
3) ordering node: apart from peers, have an ordering node
which approve the inclusion of truncation into a particular
block. So order this transaction across the network from
multiple peers and communicate to all the peers what is the
order in which transaction must be committed.
So ordering service ensures that all the transactions are totally
ordered.
Every node in the network going to commit the same
transactions in the same order and ensures consistency across
entire network.
Ordering node does not hold the copy of ledger and not even
see what the contents of the transactions are, only order the
transactions in some manner to get same order.
 Hyperledger Fabric Architecture :
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 1) Client application submit the transaction to few peers and
this few peers execute the transaction and agree that the output
is same across all of them.
 So find the output of transaction and will add their sign to it.
 So that is the part of endorsement So Client Application has
to collect endorsement from multiple peers in the network to
 Hyperledger Fabric :
Consensus is achieved using following transaction flow:
say that this transaction is the valid transaction and all outputs
are the same.
 Once you collect the sufficient signature then you can submit
the transactions for ordering. So now multiple applications i.e.
multiple users might be submitting these transactions to
ordering and now the ordering service will be ensure that all
of them are fully ordered and totally ordered across all the
nodes.
 So that is the part of ordering service. So you have to order the
transactions and once you determine the order of all
transactions then do resolution of validation.
 Hyperledger Fabric :
Consensus is achieved using following transaction flow:
 Example: For instance according to double spending problem
should not perform two transactions simultaneously which
modify the same state.
 That is the validation. Suppose for any state I have state variable
value 100. there should not be two simultaneous transactions.
1) To change that 100 to 200 2) Another trying to change that
100 to 50. now if these two transactions going simultaneously,
only one of them can succeed and which one succeeds depends
on the ordering service.
 The 1st transaction which modify the data element is succeed,
every other transaction in that same block which are trying to
modify the same transaction will get invalidated. That is the
validation step.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
In detail, stepwise transaction flow is as follows.
Step 1) Propose Transaction: Client Application or users going to
propose a particular transaction by saying I have the identity on
the network and I want to invoke this particular function of
smart contract here is my transaction and here are the inputs to
that transaction and this client application will send it to multiple
endorsing peer.
 Then E0,E1,E2 it will only execute this transaction but not
commit it into the blockchain. They will say this is output and
here is my signature.
 So all these endorsing peers will execute this proposal part.
 Now to determine how many of these peers it is send to,
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 1) Propose Transaction: is determined by endorsement
policy. The endorsement policy is something that can defines
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 1) Propose Transaction: for each smart contract in your
network.
 Example: For instance policy might say I want to send to E0,
E1 and E2 to sign or in between E0 to E2 if any two can sign
then this is a valid transaction.
 So endorsement policy is prespecified along with smart
contract and Client Application has to satisfy that endorsement
policy.
 Then P3 and P4 are committed only nodes.
 In figure pink is shown for endorsement policy.
 So this is the 1st step of proposing a transaction.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 2) Execute Proposed Transaction:

All the endorsers have to execute the proposal or transaction

and each execution will capture the read and write set so
which date element were read, which date element were
written is captured by every node in this endorser set and
once they capture read and write set,
it is going to sign and it also be encrypted for security purpose.
That is the 2nd step of flow.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 2) Execute Proposed Transaction:
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 3) Proposal Response: The endorsers to communicate back the
fact that this is the output along with sign so the Client Application
or SDK is now going to receive this read write set and all of this is
happening in parallel i.e. synchronous.
Example: For instance E0 and E1 respond 1st whereas E2 takes little
bit more time to come back with the response. So all of these are
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 3) Proposal Response: happening synchronously so the information
that how many endorsements who signed this endorsement whether these
were valid endorsement will be checked later in the consensus.
So this is the 3rd step where the client receives the response from all the
endorsers that has communicated.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 4) Ordering : So once the client has received some sufficient
endorsements that satisfies the endorsement policy with sign on responses,
it is going to submit this transaction to ordering service. Now such
submission to ordering service can be happening from multiple user,
multiple Client Application simultaneously across the network. Now
anyone node will not know who all submitted transactions, who all
submitted other transaction at the same time, it is the ordering service that
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
Step 4) Ordering : will determine that so ordering service might be
getting many such transaction across the network. As shown all
transactions are submitting to ordering service and it determines how to
order these transactions and it will make sure everyone sees the same
order across the network.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 Step 5) Ordering : Now once the ordering service determines an order
it is going to deliver that ordered set of transactions which is called as
block to all the peers in the network.
 So ordering service forms the block with ordered set of transactions and
communicates that with all the peers and all of you can include this block
in your blockchain. Peers are architected in a way that it has hierarchy.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 Step 5) Ordering : One Peer in the organization takes the
responsibility for communicating with other peers. Ordering service is
pluggable component in Hyperledger fabric. The different ordering
algorithms available are
 A) SOLO order: Single node development- There is a dictator which is
just a single node that is going to dictate what the order should be and
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 Step 5) Ordering : A) SOLO order: the single node development-the
single node implements FIFO first in first out order.
 B) Kafka order: very popular event management service by apache. It
is open source and having crash fault tolerance consensus.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 Step 6) Validate Transaction : Now all of these peers have received a block
of transactions. Not all of these transactions may be valid. Reasons are
 1) Transactions has not got sufficient endorsement.
 2) Two transactions tried to update same data. So this sort of verifications
is being performed by all the peers in the network both the endorsing
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 Step 6) Validate Transaction : and committing peers will do the validation.
Now only the valid transaction will be updated in the world state.
All the invalid transaction will have no effect on state maintained by the
blockchain.
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 Step 7) Notify Transaction : In the final step now all the peers going to
commit the set of valid transaction, commit the block add the block into
blockchain and each of them will emit events. For each transaction in the
block whether it is valid or invalid, for both of them will get specific
transaction level events and it is also possible for Client Application to
embed events in the smart contract logic. So in this smart contract logic
 Hyperledger Fabric :
 Consensus is achieved using following transaction flow:
 Step 7) Notify Transaction : emit an event saying this variable was
modified so the business information can be embedded in an event are
called as chain code events and those are also part of the block and emit
along with the block events and transaction events. So this forms the
notification part of the whole transaction flow on peer to peer basis.
 Hyperledger Fabric Architecture:

 So in Hyperledger fabric architecture there is endorsement 1st,

then ordering and then validation.
 In many of the existing blockchain platforms actually have
ordering 1st then execution and validation of transactions.
 so it is an order and execute it is the traditional way of
blockchain application.
 Whereas Hyperledger fabric for very specific reason took a
deviation from that which do execution 1st then ordering and
validations.
The key benefits of that transaction flow are
1) Better reflect business processes by specifying who endorses
transactions : The notion of the endorsements gives a way to
specify who in the system needs to validate a particular
transaction.
 Hyperledger Fabric Architecture:

2) Eliminate non deterministic transactions :

 If it is non deterministic means the fact that this transaction are
executed by all the peers or multiple peers in the network if all
are come with different answers then can lead to inconsistent
state across the network so eliminate it to maintain consistency
state at any point of time.
3) Scale the number of participants and transaction throughput :
You can have multiple parallel transaction going through the
system simultaneously.
This is the way Hyperledger fabric executes transaction and
achieve consensus across distributed set of application and users
were submitting transactions and decentralized set of nodes are
committing theses transactions.
 Hyperledger Fabric:
Channels:

 As ordering service is responsible for ordering sequence of

transactions into blocks and it is going to deliver these sequence
of totally ordered transactions to all the peers in the network.
 The communication with the service is via channels.
 Channels provides the notion of privacy or actually transaction
privacy between different ledgers.
 So the same set of peer nodes E0,E1 can actually be part of multiple
blockchain ledgers.
 Means can have E0,E1 and E2 be part of one ledger or one
blockchain. E0,E1 and E3 might be part of another blockchain.
 So these are two different chains of blocks. Each of them can have
a different ordering service if they want to.
It can have same as well.
 They all are going to maintain a different scoped ledger.
 Hyperledger Fabric : Channels:
 Each blockchain is going to maintain same ledger.
 In some sense channels is providing multi tendency like you can
have different application with the different set of peers executing
on each channel & notion of ledgers exist in the scope of channel.
 So each channel has its own ledger and the data in that ledger is
available for the peers in that channel. So all the peers in the
channel can see the data maintained by the ledger of that channel
and it available to all this.
 So all the peers in the network have accessed to the entire ledger.
 Hyperledger Fabric : Channels:
 It is possible that channels are permissioned for specific set of
participants. So you can have some subsets of the network from
the channels amongst themselves to execute transactions that are
private amongst them.
 Example: Let say a consortium of 20 banks that come together,
there is one channel that has all the 20 participants amongst
themselves, but some subset may be 2 banks or 5 banks might
come together to form a private channel that only they have
knowledge. For the other nodes in the
 Hyperledger Fabric : Channels:
 Network who are permissioned as part of that channel will not
even know the existence of other channel. So that sort of privacy
is possible and the notion of channels also segregates chain code.
 So the chain code is the smart contract and chain code is installed
on the peers that provide access to the world state. So the
installation of the chain code i.e. installing a piece of software
and that is done on peer to peer basis. On each peer you will have
to go and install the chain code.

channel
 Hyperledger Fabric : Channels:
 So a copy of the chain code is going to be running on each peer that
needs to run that chain code.
 But a chain code is installed for a specific channel or each channel.
Each peer is going to be running a copy of chain code that it needs
to run.
 Example: here there are two channels red and blue. E0 is the part
of both of these channels. E1 is the part of red channel. So this
chain code is running on E0 and E1. For E0 it needs the chain code
on both these channels whereas E1 needs this chain code only
on red channel because it does not know the existence of blue

channel
 Hyperledger Fabric : Channels:
 channel. So chain code has to be installed on each channel
specifically and the state maintained is the part of ledger and it
separate for each of the channel.
 so the chain code state in one channel is different from chain code
state in another channel. So these are kept private and separate.
 Peers can participate in multiple channels i.e. just one peer process
can be participating in multiple channels and this becomes very
useful when we are building application for easy segregation of
data and transactions across the nodes in the network itself.

channel
 Hyperledger Fabric : Channels:
 And this also alerts for concurrent execution for performance and
scalability. So say 20 nodes in a network, 5 of them can form a
private channels among themselves, 10 can form another private
channels among themselves and these two channels can execute
completely parallel with each other and that can help to improve
scalability of the entire network itself.
 So they can all executes transaction themselves without
interfering with each other. So that is the notion of channels.

channel
 Hyperledger Fabric : Channels:
 Example: Here is a network with just a single channel. Client
application is going to submit transaction to the network.
E0,E1,E2 and E3 are the endorsing peers in this network, there is
exactly one channel in this system and all the peers connects to
that channel i.e. blue channel.
 This channel is going to maintain sequence of blocks or sequence
of transactions. A and B are smart contract. So these are chain
codes that are deployed. So these chain codes are all installed on
 Hyperledger Fabric : Channels:
 Example: every node in the network and it are instantiated on that
channel so when transaction is submitted by certificate authority
on network i.e. invoking a particular function in smart contract A
then all the 4 peers E0,E1,E2 and E3 they are all going to be
executing same function across all the nodes and go through
ordering and the consensus and finally validation.
 Hyperledger Fabric : Channels:
 Example: so this is a single channel network where all the peers
are part of single channel. There could be multi channel network.
 Now there could be 2 different application.
 One application is transacting on red channel.
 Another application is transacting on blue channel and these
application may not even know the existence of other channel.
 Hyperledger Fabric : Channels:
 In this example E0 and E3 are only part of red channel and they
are only aware of smart contracts or chain codes that are deployed
on that channel.
 E1 and E2 are only part of blue channel and not known the
existence of red channel.
 So this completely disjoined channels in this network and they
actually using same ordering service.
 Hyperledger Fabric : Channels:
 It is possible that even ordering service is separate across the
channels. So the transactions on one channel are only ordered for
that channel, the transactions for other channels are kept separate.
 Endorsement policy also may be same or different on two
channels. For smart contract Y on red channel define particular
endorsement policy. For smart contract A on blue channel define
different endorsement policy.
 Hyperledger Fabric :
Membership Service Provider (MSP):
 Identities will be use to communicate with each other.
 Administrators managing this network themselves.
 Hyperledger Fabric : Membership Service Provider (MSP):
 Users are authenticating themselves by signing the transaction and
this sign is verified by the peer. So peer is going to validate this
signature provided by the user.
 Signing and insurance are possible because of security framework
of MSP.
 Hyperledger Fabric : Membership Service Provider (MSP):
 Supports different crypto standard with pluggable interface:
Different application might need different security properties that
might be provided by different certificate authorities or different
crypto standards.
 It includes TLS i.e. Transport Layer Security is used for
encrypting all Communication across the network
 Hyperledger Fabric : Membership Service Provider (MSP):
 i.e. communication among peers themselves, peer to order
communication, user to peer communication, peers and chain codes,
all of these are secured through TLS.
 Hyperledger Fabric : Identities :
 User Identities : Every user in network is going to be issued identity,
an enrollment certificate. Enrollment certificate has 2 parts:
1) Keystore: Private key to digitally sign transaction by user while
submitting onto network.
2) Signcert : which is public x.509 certificate in fabric implementation
 Hyperledger Fabric : Identities :
 User Identities : 2) Signcert : which includes this public key to
validate whether it was indeed this user who signed that transaction
and includes some attributes that certificate authority might provide
to the user.
 Optionally may also includes TLS credentials: peer needs TLS
credentials for communicating with other peers and orders in the
 Hyperledger Fabric : Identities :
 User Identities : network. All of this can be backed by Hardware
Security Module i.e. HSM where this keys are separately stored.
 HSM is used to sign transactions without anyone else or any
component in the system getting access to private keys.
 Hyperledger Fabric : Identities :
 Admin Identities : The admin identities is very similar in
concept to user identities.
 Hyperledger Fabric : Identities :
 Peer and ordered Identities : For instance an organization who is
running the peer can designate one of its users as an administrator.
 The specific function that administrator can do for instance joining
the peer to particular channel can only be performed by that
administrator user. If the regular user who is not an administrator
 Hyperledger Fabric : Identities :
 Peer and ordered Identities : tries to perform that transaction , it will
denied by the network. It also stores the public certificate of certificate
authority that it will recognize. So it need the public certificate of that
certificate authority to able to validate users who are connecting to this
peer. That is the part of cacerts.
 Hyperledger Fabric : Identities :
 Peer and ordered Identities : There are also certification revocation lists :
 This is important over a period of time to manage which are legitimate
users which are not. So hold your certificate for certain length of time &
revoke that certificate and have a new certificate for security purpose.
 Peers and orders receive channel MSP information to know which
channels they are connected to.
 Hyperledger Fabric : Endorsement Policy :
 Endorsement Policy :
 A subset of the peers executing chain codes on each channel and that
is governed by endorsement policy.
 So the endorsement policy states which peers have to execute or
endorse a certain transaction before it will be deemed as valid to be
added to the blockchain. So each chain codes defines an endorsement
policy and this can be different for each channel that chain code
belongs to.

 Now these are two important system chain codes:

 Hyperledger Fabric : Endorsement Policy :
 Endorsement Policy :
 System chain codes are the chain codes that are implemented internal to
fabric itself that performs certain important functions.
 This system chain codes also provides the notion of pluggability.
 ESCC: It is running within every endorsing peers. When a client submit
the transaction to the endorsing peer. It is invoking a particular function
that is in chain code and it first comes to ESCC.
 So the ESCC endorsement system chain codes is the one that will invoke
the chain codes will execute the transaction.
 It will compute the read write set of transactions.
 So what is the state information that was read in the chain code in that
 Hyperledger Fabric : Endorsement Policy :
 Endorsement Policy :
 Function and what is the state information that was written. All of that is
captured by the ESCC and it will then sign the proposal response.
 Example : It will say when I run this transaction, that is the read set, that
was the write set and here is my signature saying that I was the one who
run this and I endorse this. So this is done by every endorsing peer. And
this system chain codes does that signing part of it.
 Now client collects all these signatures from all the endorsements. It will
then submit that transactions to the order.
 The order will include it in the block, deliver it to the peer. And now all
committing peers will do certain functions so that where the validation
 Hyperledger Fabric : Endorsement Policy :
 VSCC: System chain codes comes. In which it is going to validate these
endorsements. So what dose the validation System chain codes do?
 It will look up the policy for this particular chain code. So this policy
might say organization 1, 2 and 3 in the network have to sign this
transaction.
 So it will then check whether these 3 signature are available. How the
system works for some of this policies is the part of it.
 The validation System chain codes does the job of going through the
endorsements that are available in the transaction, that has been
submitted with the transaction and seeing if that set of endorsements
satisfying the policy that was specified for the chain codes in that channel.
 Hyperledger Fabric : Endorsement Policy :
 VSCC: So that is the validation System chain codes.
 Now it is always possible that the endorsement you want to use, some
other logic the endorsements or for the validation you want to use, some
other logic for the validation or even you might want to implement that in
different language other than Golang.
 So all these possibilities exists. And this whole module is pluggable.
 You can bring your own implementation for these things based on your
application needs.
 But for most
application we
deemed that this
exiting
implementation of
endorsement system chain codes and validation System chain codes will be
sufficient for most application that is there in enterprise to give a
comparison with bitcoin.
 Hyperledger Fabric : Endorsement Policy :
 VSCC: The validation that System chain codes does in some sense is the
validation whether the validation is duplicate or not. That is UTXO
model for bitcoin.
 In Hyperledger fabric it is state based model. So the validation is based
on the state information. That we are sorting as a part of the ledger.
 One part of the validation is the validation of endorsement policy. So
this is different from what bitcoin has and this is very specific to
Hyperledger fabric. It is one of the differentiation of Hyperledger fabric.
 Hyperledger Fabric : Access Control :
 Model files describe the assets, participants and transaction in a business
network.
 Access control list defines rules for sharing and privacy.
 This rules automatically enforced by Hyperledger fabric composer run
time.
 How to define access control?
 It is possible to restrict who accesses what assets and what rights do they
have on that asset?
 Hyperledger Fabric : Access Control :
 Whether they are able to create that asset, Whether they are able to
modify that asset, call a particular function on that asset, Whether they
are able to read it, all of these can be defined by access control rules.
 It can be very simple, starting from everybody can read everything,
 Who are the participants – participants that follows it.
 What is the operation – it is everybody can read. So that is read
operation.
 What is the resources – all are resources.
 Hyperledger Fabric : Access Control :
 It is simple dot star and action is to allow. You can say deny
 i.e.You can say deny this particular user access to this recourse.
 It may have more complex access rules as well.
 It may say only the owner of a particular asset can do anything with it. It
can have read write modify everything. So owner has full access.
 The access here is to allow for every operation. Read write everything.
 Who is the participants – the participants that follows it.
 What is the resource – it is one particular asset.
 Hyperledger Fabric : Access Control :
 And specify condition there. Let say owner is participant. So whoever is
invoking it is actually the owner. So if the condition is satisfied, they will
be allowed to perform that transaction according to access control rules.
 It may also have credentials. Based on the user secret that you are using
you can ensure that only certain users are authorized to perform certain
transaction.
 Writing smart contract using Ethereum :

 Code as Law means the code that execute & fulfills some
terms of a contract and that code can not altered or
influenced by any outside 3rd party or system.
 With Ethereum, blockchain can actually deploy code onto
blockchain and execute it.

 Smart contract is a program run on the blockchain.

 Blockchain is decentralized distributed computing system

where state changes are allowed only after achieving
consensus of a majority of participating nodes.
 Writing smart contract using Ethereum :

 It is immutable (unchangeable) so to change a smart contract

to edit the code, would actually have to make changes across
the entire blockchain.
 It provides high level of security as have to take care in
developing smart contracts as once deployed to the
blockchain can not be changed.
 Smart contract can be written in a number of different
languages Rust, Go, JavaScript, Vyper, Yul, etc
 We are focusing on Solidity as most popular language.
 It has designed specifically for use in Smart contract by
some of the code contributors of Ethereum.
 Writing smart contract using Ethereum :
 Smart contract IDEs and Tools:

 Remix online editor really useful for sort of doing rapid

prototype development, testing out ideas, deploying and
testing code quickly.
 Solidity is strongly typed language so always declare the
type of variable such as string and declare axis modifier
public –means this is accessible to anybody and everyone
 Example: Write simple contract with input, output and going
to create and return a greeting as hello with your name.
 Example: Hello Dr. Shilpa
 Define greeting prefix so that get a name with greeting prefix
 Ctrl save to save this program
 Writing smart contract using Ethereum :
 SPDX-License-Identifier: MIT
 Declare what kind of license are present in solidity with
SPDX-License-Identifier:
 MIT is just open source license with no restriction –
anybody can use, copy and replicate this code.
 MIT license which is free software license originating at the
Massachusetts Institute of Technology (MIT).
 MIT is one of the many free licenses available in the SPDX
license list.
 Data collection may be storage or memory for constructor.
 In solidity all your variables with exception of instance
variable can be stored in different ways of any of the 3 types
 Writing smart contract using Ethereum :

 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 1) 1st line indicates the Software Package Data Exchange
(SPDX) license the code can be used under.
// SPDX-License-Identifier: MIT
 2) next line is to tell compiler the version of Solidity to use for
compiling the code. This is important because each version of
Solidity might deprecate some functionality and may introduce
new build-in functions.
 Using the right version of Solidity allows the user to use these
functionalities in their code. pragma solidity ^0.8.17;
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 3) contract Greeting {
 The third line of real Solidity code declares a contract and
gives it a name.
 This name is used as an identifier when compiling and
deploying code.
 A Solidity contract can be considered like a service.
 The public components of the contract can be called from
outside the contract and may result in some value being
returned
to the
caller.
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 3) contract Greeting {
 string public name;
 string public greetingPrefix = "Hello ";
 //define contract with word greeting. Declare state variables
name and greetingprefix that will stored
on the blockchain for calling smart contract code.
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 4) constructor(string memory initialName){
 name= initialName; }
 Declare constructor function by word constructor & add
name argument with its type as initialname which is
different from our state variable name under this function
use common pattern of setting state variable through the
argument initialname.
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:

 4) constructor(string memory initialName){

 name= initialName; }
 function SetName (string memory newName) public
 { name= newName; }
 now set name with intial constructor for future use.
use function setname with argument list (string with
newname) to differentiate it from other two.
 Declare it as public so that it can be called by any other
function in smart contract
 // define it as name= newname
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 5) function getGreeting () public view returns (string
memory) {return string(abi.encodePacked(greetingPrefix,
name));
 function getgreeting which not taking any parameter it just
for returning some information from smart contract.
 write it as public view returns with declare return type as
string. view means this function not going to change any
data on blockchain only to read data.
 return should have concatenation of greetingprefix and name
ex. hello student. But string concatenation unfortunately is
not straightforward in solidity. as smart contract is generally
for sending transaction and deciding logic behind id so use
helper function abi.encodepacked with concatenated string
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 // SPDX-License-Identifier: MIT
 pragma solidity ^0.8.17;
 contract Greeting {
 string public name; //define contract with word greeting. declare
state variables name and greetingprefix that will stored
 string public greetingPrefix = "Hello "; //on the blockchain for
calling smart contract code
 constructor(string memory initialName){
 name= initialName; // declare constructor function by word
constructor & add name argument with its type as initialname
 } // which is different from our state variable name
 // under this function use common pattern of setting state variable
through the argument intial name
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:
 //now set name with intial constructor for future use. use function
setname with argument list (string with newnwme) to differentiate
it from other two. declare it as public so that it can be called by any
other function in smart contract define it as name= newname
 function SetName (string memory newName) public {
 name= newName; }
 // function getgreeting which not taking any parameter it just for
returning some information from smart contract.
write it as public view returns with declare return type as string.
view means this function not going to change any data on
blockchain only to read data. return should have concatenation of
greetingprefix and name ex. hello student.
 Writing smart contract using Ethereum :
 How to write simple contract with Greeting message:

 But string concatenation unfortunately is not straightforward in

solidity. as smart contract is generally for sending transcation and
deciding logic behind id so use helper function abi.encodepacked
with concatenated

 function getGreeting () public view returns (string memory) {

 return string(abi.encodePacked(greetingPrefix, name));
 }
 }
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 When paper money came into being, people started carrying
money in what can be called wallets.
 With the advent of digital and cryptocurrencies, wallets no
longer need to be physical. You can carry your information
on your cards, on your phones and watches, and in your
cryptocurrency wallets live in the cloud.
 One example of this, is the Ethereum wallet - “applications
that let you interact with your Ethereum account”.
 It lets you check your balance and send transactions.
 Smart contracts are programs which govern the behavior of
accounts within the Ethereum state.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 1) 1st line indicates the Software Package Data Exchange
(SPDX) license the code can be used under.
// SPDX-License-Identifier: MIT
 2) next line is to tell compiler the version of Solidity to use for
compiling the code. This is important because each version of
Solidity might deprecate some functionality and may introduce
new build-in functions.
 Using the right version of Solidity allows the user to use these
functionalities in their code. pragma solidity ^0.8.10;
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 3) contract EtherWallet {
 The third line of real Solidity code declares a contract and
gives it a name.
 This name is used as an identifier when compiling and
deploying code.
 A Solidity contract can be considered like a service.
 The public components of the contract can be called from
outside the contract and may result in some value being
returned to the
caller.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 4) address payable public owner;
 the type “address” as on the Ethereum blockchain, every
account and smart contract has an address.
 The address is needed to send and receive “Ether” from
another account.
 This address identifies the contract on the blockchain.
 It is like a bank account for a user.
 Just like a person needs bank account information of another
person to send money to their account (unless you use
Interact e-transfer), an address is needed to send Ether to a
contract.
 An address is assigned to a contract when the contract is
deployed on the blockchain.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 4) address payable public owner;
 “payable” keyword makes it possible for the address to
receive Ether.
 If this keyword
is not used, the
contract won’t
be able to receive
Ether and anyone trying to send Ether to the contract will
receive an Exception.
 Next on the line is the keyword “public”.
 This keyword makes a variable or a function accessible from
outside the contract, in other words public.
 The last word on this line “owner”, is the name of the variable.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 5) constructor() { owner = payable(msg.sender); }
 The constructor is the function that gets called when an
instance of the contract is created.
 It generally includes statements that initialize variables or
sets them up with valid values.
 In Solidity, there are certain globally available special
variables that can be accessed to extract useful information.
One such variable is “msg”.
 The “msg” variable has a property called “sender”.
 This property can be accessed to derive the address that
called this contract. When a contract is deployed, the sender
property is the address of the deployer.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 5) constructor() { owner = payable(msg.sender) ; }
 Hence setting the address in the msg.sender, stores the
address of the deployer in the owner variable.

 This a smart way of storing the address of the deployer (or

the owner) of the contract so it can later be used to compare
with addresses calling this contract.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 6) receive() external payable {}
 In order for a contract to receive Ether, the contract must
have one of two type of functions:
 1. A receive() external payable function; or
 2. A fallback function
 The receive() external payable function is called when a
contract is sent Ether, but no call data.
 In the case of this wallet, it will be called each time the
contract is sent Ether.
 The Ether will get added to the address where this contract
is deployed.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 6) receive() external payable {}
 An “external” function is a part of the contract interface.
 An external function cannot be called internally within the
contract.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 7) function withdraw(uint _amount) external {
 This “external” function can be called from outside this
contract to withdraw “Ether” and send it from this wallet to
the recipient.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 7) function withdraw(uint _amount) external {
 require(msg.sender == owner, “caller is not owner”);
 The first line of this function checks to make sure the sender
of this message is the owner of the contract.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 7) function withdraw(uint _amount) external {
 require(msg.sender == owner, “only the owner can call
this method”);
 Obviously, it would not be appropriate to allow just anybody
to withdraw from a wallet. Only the owner of the wallet
should be able to withdraw.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 7) function withdraw(uint _amount) external {
 require(msg.sender == owner, “only the owner can call this
method”);
 payable(msg.sender).transfer(_amount); }
 The second line is what makes the transfer.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 8) function getBalance() external view returns (uint) {
 there is a function in the contract to check the balance.
 This function can be called from outside the contract only
due to the “external” keyword.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 8) function getBalance() external view returns (uint) {
 return address(this).balance; }
 It returns the current balance of the contract.
 Technically, it
returns the
balance of the
address at which
the contract is
deployed, but
conceptually, it’s
the balance of the
contract.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:

 VM is virtual memory blockchain

rather than real one. While executing
the owner account have slightly less
than 100 ether i.e. balance goes down
as anything you do on Ethereum
blockchain costs gas which means
there is cost to execute any type of
code on blockchain.

 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:

 VM is virtual memory blockchain

rather than real one. While executing
the owner account have slightly less
than 100 ether i.e. balance goes down
as anything you do on Ethereum
blockchain costs gas which means
there is cost to execute any type of
code on blockchain.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 VM is virtual memory blockchain rather than real one.
 While executing the owner account have slightly less than
100 ether i.e. balance goes down as anything you do on
Ethereum blockchain costs gas which means there is cost to
execute any type of code on blockchain.
 As this is just test environment so it cost very small fraction
of ether to deploy our contract.
 Now to send some ether 1st check with getbalance i.e. should
be 0.
 Receive function allows contract to receive ether.
 Receive is invoked when ether is sent in to contract and
there is no calldata.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 To send some ether select ether
form Wei button and put 25 in value
now and choose another account as
we said that anyone can actually
deposit funds into wallet then from
low level interaction calldata
 hit transact and check balance as
2500000000 now, group of o’s in 25
because default is wei which is sub
denomination of ether so withdraw
is also be in wei.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:

 Receive function allows contract to receive ether.

 Receive is invoked when ether is sent in to contract and
there is no calldata.
 To send some ether select ether form Wei button and put 25
in value now and choose another account as we said that
anyone can actually deposit funds into wallet then from low
level interaction calldata
 hit transact and check balance as 2500000000 now, group of
o’s in 25 because default is wei which is sub denomination
of ether so withdraw is also be in wei.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 So use Ethereum unit converter. So new account is with
74.9999 Now just to test that only owner should be able to
withdraw from contract so put 1500000 in withdraw & click
withdraw so getting error msg of only owner can call this
method.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 So go back to 1st account try to withdraw greater amount than
exists in contract say 35000000 click on withdraw again error
msg to say called function should be payable if value send
should be less than current balance so contract take care of
transaction if we requesting more money than contract
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 currently holds so change it to 150000 and click withdraw so
in owner account now 99+15=114 ether in balance.
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 So we started with 25, withdraw 15 so balance is 25-15=10
 Writing smart contract using Ethereum :
 How to Build a Simple Ethereum Wallet:
 in owner button just make sure that address matches with
current address.
 Overview of Ripple :
 Blockchain networks or distributed ledger network that are all
payment network.
 First is seller network which is global network.
 It is actually decentralised hybrid blockchain platform with open
membership.
 It means anyone can join this network, run a seller node and
participate in this network, execute transactions and store the state
of payments or accounts in this network.
 Another interesting project is ripple protocol and the associated
network, actually ripple was the first one that came out in terms
of being creating such a payment network after bitcoin.
 So it is a protocol that instead of looking end users, they actually
look at banks, they target banks to help banks to do clearing and
settlement of payments and it is done in decentralised manner.
 Overview of Ripple :
 They have their own consensus algorithm. It allows exchanges
and remittance to happen.
 They have similar transaction clearance.
 They have about 5 seconds to to run their transaction but
important thing is thing there is no mining in this case unlike
bitcoin.
 Bitcoin has proof of work and it involves mining but here they are
only looking to create that network among the set of permission
entities or banks.
 They have a custom protocol but that protocol unfortunately no
one has validated it for correctness and fault tolerance.
 Overview of Ripple :
 So it is still being debated whether it is a good protocol to use.
 They have again similar to seller, they have gateway nodes to
convert currencies from flat currencies like US dollar or EURO to
ripple.

 And for ripple it is the XRP that is the cryptocurrency that use and
there are market makers that help convert one currency to another.

 Ripple has a centralised governance model so ripple controls who
joins the network, how is this created and they also hold large
fraction of the cryptocurrencies still.
 Overview of Ripple :
 Overview of Corda :
 What is Corda?
 Very much similar to blockchain, Corda is a distributed
ledger platform designed to record, manage and
automate contract based legal agreements between two
or more parties.
 Well known for its application in business deals.
 Targeted towards the world's largest financial
institutions, but potential for application exceeds beyond
that.
 It offers a unique approach to privacy, security, and takes
care of the scalability issues that Dapps face.
 Overview of Corda : What is Corda?
 Corda is an open-source enterprise-based blockchain designed
to offer interoperability.
 It is a platform that is intended to record, manage, and
synchronize agreements and transfer anything valuable.
 It allows enterprises to communicate and transact directly
while maintaining transparency and without worrying about
privacy and to integrate Blockchain across their operations
immediately and efficiently.
 Moreover, Corda offers timestamping services to order
transactions temporally and ignore disputes.
 It has a smart contract logic, which specifies constraints that
ensure state transitions are valid as outlined in contract code.
 Overview of Corda :
 How Corda works?
 As in Blockchain which embodies the Distributed
Ledger Technology (DLT), the data are stored in all the
nodes in the blockchain making it highly secure.
 This means that an individual or any entity outside the
block can never change the data for their own agenda.
 This makes it highly secure but at the same time raises
the issue of the number of files and the space it takes up.
 Overview of Corda :
 Smart contracts play a vital role in blockchain, i.e. the
contract would be transparent and accessible by everyone in
the block.
 But the main difference with Corda, is that the smart
contract can be permission based.
 Only the two or more parties involved in the transaction
would have access to the smart contract.
 Also with the consensus of the parties involved, a
regulatory or a legal body can be given access and brought
into the network as an observer to verify the contract.
 Overview of Corda : Highlights
 Smart contracts in Corda are executed taking into account
the following features :
 Regulating and streamlining the workflow between
decentralized firms
 Recording and managing the evolution of financial
agreements and other shared data between two or more
identifiable parties in a way that is grounded in existing
legal constructs and compatible with existing and emerging
regulation
 Inclusion of supervisory and regulatory nodes just as
observers

 Overview of Corda : Highlights
 Smart contracts in Corda are executed taking into account
the following features:
 Consensus algorithms and levels are between two firms
involved and not global
 Access of the data within the agreement is only limited and
entitled or logically privileged to the Permissioned parties
involved
 Acts as a bridging between the usual hard contract with
mart contracts by recording the links
 Validation of the transaction solely between the two parties
involved
 Overview of Corda :
 Why choose Corda?
 Due to following features:
 Data privacy and security
 Native tokenization and interoperability
 Settlement finality
 Sustainability
 Multi-tenancy
 Regulatory complaint
 Writing smart contract using Hyperledger Fabric :

 From an application developer’s perspective, a smart

contract, together with the ledger, form the heart of a
Hyperledger Fabric blockchain system.
 Whereas a ledger holds facts about the current and historical
state of a set of business objects, a smart contract defines
the executable logic that generates new facts that are added
to the ledger.
 A chain code is typically used by administrators to group
related smart contracts for deployment but can also be used
for low level system programming of Fabric.
 Before businesses can transact with each other, they must
define a common set of contracts covering common terms,
data, rules, concept definitions, and processes.
 Writing smart contract using Hyperledger Fabric :
 Taken together, these contracts lay out the business
model that govern all of the interactions between transacting
parties.

 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.
 Writing smart contract using Hyperledger Fabric :

 Using a blockchain network, we can turn these contracts into

executable programs to open up a wide variety of new
possibilities.
 That’s because a smart contract can implement the
governance rules for any type of business object, so that they
can be automatically enforced when the smart contract is
executed.
 For example, a smart contract might ensure that a new car
delivery is made within a specified timeframe, or that funds
are released according to prearranged terms, improving the
flow of goods or capital respectively.
 Writing smart contract using Hyperledger Fabric :

 Most importantly however, the execution of a smart contract

is much more efficient than a manual human business
process.
 We can see how two organizations, ORG1 and ORG2 have
defined a car smart contract to query, transfer and update cars.
 Applications from these organizations invoke this smart
contract to perform an agreed step in a business process, for
example to transfer ownership of a specific car
from ORG1 to ORG2.
 Terminology: Hyperledger Fabric users often use the
terms smart contract and chain code interchangeably. In
general, a smart contract defines the transaction logic that
controls the lifecycle of a business object contained in the
 Writing smart contract using Hyperledger Fabric :
 world state.
 It is then packaged into a chain code which is then deployed
to a blockchain network. Think of smart contracts as
governing transactions, whereas chain code governs how
smart contracts are packaged for deployment.
 A smart contract is defined within a chain code. Multiple
smart contracts can be defined within the same chain code.
When a chain code is deployed, all smart contracts within it
are made available to applications.
 In the diagram, we can see a vehicle chain code that contains
three smart contracts: cars, boats and trucks.
 We can also see an insurance chain code that contains four
smart contracts: policy, liability, syndication and
securitization.
 Writing smart contract using Hyperledger Fabric :
 In both cases these contracts cover key aspects of the business
process relating to vehicles and insurance. In this topic, we
will use the car contract as an example.
 We can see that a smart contract is a domain specific program
which relates to specific business processes, whereas a chain
code is a technical container of a group of related smart
contracts.
 Writing smart contract using Hyperledger Fabric:
 Ledger : At the simplest level, 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.
 A get typically represents a query to retrieve information
about the current state of a business object.
 A put typically creates a new business object or modifies an
existing one in the ledger world state.
 Writing smart contract using Hyperledger Fabric:
 Ledger : A delete typically represents the removal of a
business object from the current state of the ledger, but not its
history.
 Development: Smart contracts are the focus of application
development, and as we’ve seen, one or more smart contracts
can be defined within a single chain code.
 Deploying a chain code to a network makes all its smart
contracts available to the organizations in that network.
 It means that only administrators need to worry about chain
code; everyone else can think in terms of smart contracts.
 At the heart of a smart contract is a set of transaction
definitions.
 Writing smart contract using Hyperledger Fabric :
 For example, look at assetTransfer.js here, where you can see
a smart contract transaction that creates a new asset:
 Writing smart contract using Hyperledger Fabric :
 Running a Fabric Application : We will look into introduction
to how Fabric applications interact with deployed blockchain
networks. Use sample programs built using the Fabric Gateway
client API to invoke a smart contract, which queries
& updates
the ledger
with the
smart
contract
API-
described in
detail in
Deploying a
smart contract
to a channel.
 Two Principle parts:

2. Run the sample application to interact with the smart contract.

Use the asset Transfer smart contract to create, query, and update
assets on the ledger. We will step through the code of the
application and the transactions it invokes, including creating
some initial assets, querying an asset, querying a range of assets,
creating a new asset, and transferring an asset to a new owner.
 Writing smart contract using Hyperledger Fabric :
 Set up the blockchain network : If you’ve already run through
Using the Fabric test network and have a network up and
running, will bring down your running network before bringing
up a new one, to ensure you start with an empty ledger.
 Launch the
blockchain
network
 Navigate to
the test-
network
Subdirectory
within your
local clone of
the fabric-samples repository.
 Deploy the smart contract: A smart contract can describe an
almost infinite array of business use cases relating to
immutability of data in multi-organizational decision making.
 Endorsement
 Associated with every chain code is an endorsement policy
that applies to all of the smart contracts defined within it.
 An endorsement policy is very important; it indicates
which organizations in a blockchain network must sign a
transaction generated by a given smart contract in order
for that transaction to be declared valid.
 Endorsement
 Every smart contract has an endorsement policy associated
with it.
 This endorsement policy identifies which organizations must
approve transactions generated by the smart contract before
those transactions can be identified as valid.
 An example endorsement policy might define that three of
the four organizations participating in a blockchain network
must sign a transaction before it is considered valid.
 All transactions, whether valid or invalid are added to a
distributed ledger, but only valid transactions update the
world state.
 If an endorsement policy specifies that more than one
organization must sign a transaction, then the smart contract
 Endorsement
 must be executed by a sufficient set of organizations in
order for a valid transaction to be generated.
 In the example above, a smart contract transaction to
transfer a car would need to be executed and signed by
both ORG1 and ORG2 for it to be valid.
 Endorsement policies are what make Hyperledger Fabric
different from other blockchains like Ethereum or Bitcoin.
 In these systems valid transactions can be generated by any
node in the network.
 Hyperledger Fabric more realistically models the real
world; transactions must be validated by trusted
organizations in a network.
 Endorsement
 For example, a government organization must sign a valid
issue Identity transaction, or both the buyer and seller of a
car must sign a car transfer transaction.
 Endorsement policies are designed to allow Hyperledger
Fabric to better model these types of real-world interactions.
 Finally, endorsement policies are just one example of policy.
 Other policies can be defined to identify who can query or
update the ledger or add or remove participants from the
network.
 In general, policies should be agreed in advance by the
consortium of organizations in a blockchain network.
 Indeed, policies themselves can define the rules by which
they can be changed.
 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.
 Examine the car transfer transaction.
 You can see a transaction t3 for a car transfer between
ORG1 and ORG2. See how the transaction has input
{CAR1, ORG1, ORG2} and output
{CAR1.owner=ORG1, CAR1.owner=ORG2},
representing the change of owner from ORG1 to
ORG2.
 Valid transactions

 These signatures were generated by using each actor’s

private key and mean that anyone in the network can
verify that all actors in the network are in agreement
about the transaction details.
 A transaction that is distributed to all peer nodes in the
network is validated in two phases by each peer.
 Firstly, the transaction is checked to ensure it has been
signed by sufficient organizations according to the
endorsement policy.
 Valid transactions
 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.
 In our example, t3 is a valid transaction, so the owner of
CAR1 has been updated to ORG2.
 Valid transactions
 However, t4 (not shown) is an invalid transaction, so while it
was recorded in the ledger, the world state was not updated,
and CAR2 remains owned by ORG2.
 Channels:
 Hyperledger Fabric allows an organization to simultaneously
participate in multiple, separate blockchain networks via
channels.
 By joining multiple channels, an organization can participate
in a so-called network of networks.
 Channels provide an efficient sharing of infrastructure while
maintaining data and communications privacy.
 Channels:
 They are independent enough to help organizations
separate their work traffic with different counterparties
but integrated enough to allow them to coordinate
independent activities when necessary.
 While the smart contract code is installed inside a chain
code package on an organizations peers, channel members
can only execute a smart contract after the chain code has
been defined on a channel.
 The chain code definition is a struct that contains the
parameters that govern how a chain code operates.
 Channels:
 These parameters include the chain code name, version,
and the endorsement policy.
 Each channel member agrees to the parameters of a chain
code by approving a chain code definition for their
organization.
 When a sufficient number of organizations (a majority by
default) have approved to the same chain code definition,
the definition can be committed to the channel.
 The smart contracts inside the chain code can then be
executed by channel members, subject to the
endorsement policy specified in the chain code definition.
 Channels
 The endorsement policy applies equally to all smart contracts
defined within the same chain code.
 In the example above, a car contract is defined on the
VEHICLE channel, and an insurance contract is defined on the
INSURANCE channel.
 The chain code definition of car specifies an endorsement
policy that requires both ORG1 and ORG2 to sign
transactions before they can be considered valid. The chain
code definition of the insurance contract specifies that only
ORG3 is required to endorse a transaction.
 ORG1 participates in two networks, the VEHICLE channel
and the INSURANCE network, and can coordinate activity
with ORG2 and ORG3 across these two networks.
 The chain code definition provides a way for channel
members to agree on the governance of a chain code before
they start using smart contract to transact on the channel.
 Building on the example above, both ORG1 and ORG2 want
to endorse transactions that invoke the car contract. Because
the default policy requires that a majority of organizations
approve a chain code definition, both organizations need to
approve an endorsement policy of AND{ORG1,ORG2}.
 Otherwise, ORG1 and ORG2 would approve different chain
code definitions and would be unable to commit the chain
code definition to the channel as a result.
 This process guarantees that a txn from the car smart
contract needs to be approved by both organizations.