FITE3011

Distributed ledger and blockchain

Lecture 3 Hyperledger Fabric
Agenda
› Order-Execute Architecture
› Execute-Order-Validate Architecture
› Hyperledger Fabric Key Roles
› Channels

1
 Many Blockchains follow the Order-Execute
Architecture

Order Execute Update State

Different blockchain After the transactions have

system may have a been ordered, each node in Execution of the
different “ordering” the system has to execute transaction causes
mechanism. We learnt them one-by-one to verify changes in world state.
PoW in Bitcoin. their validity.

2
Review Questions
› Who takes part in the “order” process in Bitcoin?
› Who takes part in the “Execute process in Bitcoin?
› Where is/are the “world state” stored?

› Additional Question:
› What is included in the world state?

3
Limitations of Order-Execute Architecture
› Sequential execution
› Confidentiality of execution

4
Hyperledger Fabric
› Fabric is a modular and extensible open-source system
for deploying and operating permissioned blockchains
– Maintained by the Linux Foundation
› Supports modular consensus protocols
› The first blockchain system that runs distributed
applications written in standard, general-purpose
programming languages, without systemic dependency on
a native cryptocurrency

5
Hyperledger Fabric
› In a public or permissionless blockchain anyone can
participate without a specific identity
› Public blockchains typically involve a native
cryptocurrency and often use consensus based on “proof
of work” (PoW) and economic incentives
› Permissioned blockchains, on the other hand, run a
blockchain among a set of known, identified participants.
– It provides a way to secure the interactions among a group of
entities that have a common goal but which do not fully trust
each other, such as businesses that exchange funds, goods, or
information.
6
Hyperledger Fabric Architecture
› Execute-Order-Validate

Source: Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains

7
Hyperledger Fabric Architecture

A Fabric network with federated MSPs and running multiple (differently shaded
and colored) chaincodes, selectively installed on peers according to policy.
8
Key Roles
› A Fabric blockchain consists of a set of nodes that form a
network
› As Fabric is permissioned, all nodes that participate in the
network have an identity, as provided by a modular
membership service provider (MSP)
› Nodes in a Fabric network take up one of three roles:
– Clients
– Peers
– Ordering Service Nodes (OSN)

9
Hyperledger Fabric Architecture
› Clients
– submit transaction proposals for execution, help orchestrate the
execution phase, and, finally, broadcast transactions for
ordering

10
Hyperledger Fabric Architecture
› Peers
– execute transaction proposals and validate transactions
– All peers maintain the blockchain ledger, an append-only data
structure recording all transactions in the form of a hash chain,
as well as the state, a succinct representation of the latest
ledger state
– Not all peers execute all transaction proposals, only a subset of
them called endorsing peers (or, simply, endorsers) does, as
specified by the policy of the chaincode to which the transaction
pertains

11
Hyperledger Fabric Architecture
› Ordering Service Nodes (OSN) (or, simply, orderers)
– collectively form the ordering service
– establish the total order of all transactions in Fabric, where each
transaction contains state updates and dependencies computed
during the execution phase, along with cryptographic signatures
of the endorsing peers
– are entirely unaware of the application state, and do not
participate in the execution nor in the validation of transactions

12
How Applications interact with the Ledger

Source: Fabric Explored A Technical Deep-Dive on Hyperledger Fabric

13
Flow of Hyperledger Fabric Transaction

14
 key version value
An transaction proposal contains:
Execute (1) chaincode function
(2) input to chaincode function
k1
k2
1
1
v1
v2
(3) Signature from the client k3 1 v3
k4 1 v4
Transaction proposal e.g., foo(3011)

chaincode world
Client SDK Endorser state

Proposal response
Simulate and endorse:
A proposal response:
Execute chaincode function,
(1) Response value
e.g., foo(3011)
(2) Read-Write Set as a result of the Simulation
(3) Signature from the Endorser
Read-Write Set:
T1: Read(k1,1), Write(k3, v3’)
Endorsed Transaction = transaction proposal + proposal response
15
Remarks
› If the chaincode only queried the ledger, the client would
inspect the query response and would typically not
submit the transaction to Ordering Service
› Fabric supports different endorsement policy. The SDK
determines if the specified endorsement policy has been
fulfilled before submitting
› For example, an endorsement policy may require valid
proposal responses from multiple endorsers

16
Order
› Clients submit their (endorsed) transactions to the
ordering service
› The order service can be provided a network of orderers
running some kind of consensus protocol
› The ordering service does not inspect the content of the
transaction; it only gives them an order and send these
blocks to all peers
› In practice, transactions are arranged into blocks, and the
orderer send the blocks of transactions to all peers

17
Validate
› When a new block is received, a peer node validates all
transactions within that block
› For each transaction, the peer node:
– Check that the endorsement policy is fulfilled
– Ensure that no changes to the world state for the read set of the
transaction (i.e., if the current version of k1 is 3, and the read set
of a transaction contains (k1, 2), then it is rejected since the
endorsement was generated based on a read of an “old” value)
– Transactions in the block are tagged as being valid or invalid

18
Which transaction(s) would be tagged invalid?
› Read-Write Set of 5 transactions in a key version value

new block k1 1 v1
k2 1 v2
– T1: Write(k1, v1’), Write(k2, v2’)
k3 1 v3
– T2: Read(k1,1), Write(k3, v3’)
k4 1 v4
– T3: Write(k2, v2’’)
– T4: Write(k2, v2’’’), Read(k2) world
– T5: Write(k5, v5’), Read(k4,1) state

Current world state

19
Update State
› For each valid transaction received in the new block,
update the world state according to its write set
› Note that the version number is also updated by each
write

20
 key version value

Update State (2) k1

k2
1
1
v1
v2

› If an incoming block contains the k3 1 v3

following transactions, how would the k4 1 v4

world state change? old world state

– T1: Write(k1, v1’), Write(k2, v2’)

– T2: Read(k1,1), Write(k3, v3’)
– T3: Write(k2, v2’’) key version value
k1 2 v1’
– T4: Write(k2, v2’’’), Read(k2)
k2 3 v2’’
– T5: Write(k5, v5’), Read(k4,1)
k3 1 v3
k4 1 v4
k5 1 v5’
new world state
21
Advantages of the Execute-Order-Validate
Architecture
› Pluggable Consensus
› Flexible Trust Model
– Different transactions can be validated according to a specific
endorsement policy (i.e., chaincode can have its own
endorsement policy)
› Flexible smart contract language
› Concurrent execution of all transactions
– Different endorsers to simulate different transaction proposals
– A peer node only need to verify digital sigantures

22
Advantages of the Execute-Order-Validate
Architecture
› Support non-deterministic execution at endorser
› Confidentiality of chaincode
– Chaincode is deployed and executed only at specific endorser
– Can hide business logic

23
 The Fabric Blockchain A
Client
Application

E N Blockchain
S
Network
P1 P2 P3
A1 L L L
P Peer node

O L Ledger
A2
P4 P5 P6
L L E O Endorser /
L
N Orderer

S Smart Contract
 Transactions Recording (1) A
Client
Application

E N Blockchain
S
PTx1
Network
P1 P2 P3
A1 L L L
P Peer node

O L Ledger
A2
P4 P5 P6
L L E O Endorser /
L
N Orderer

S Smart Contract
1. Client submits a transaction proposal to its endorser (P1)
 Transactions Recording (2) A
Client
Application

E N Blockchain
S
res1
Network
P1 P2 P3
A1 L L L
P Peer node

O L Ledger
A2
P4 P5 P6
L L E O Endorser /
L
N Orderer

S Smart Contract
2. Endorser P1 executes PTx1 and endorse it. The proposal
response is returned to A1. The endorsed transaction, Tx1,
is formed by A1 from the transaction proposal and its response.
 Transactions Recording (3) A
Client
Application

E N Blockchain
S
Network
P1 P2 P3
A1 L L L
P Peer node
Tx1

O L Ledger
A2
P4 P5 P6
L L E O Endorser /
L
N Orderer

S Smart Contract
3. A1 submits the endorsed transaction Tx1 to the orderer, P4.
 Transactions Recording (4) A
Client
Application

E N Blockchain
S
Network
P1 P2 P3
A1 L L L
P Peer node
B B
B

O L Ledger
A2
B
P4 P5 P6
L L E O Endorser /
L
N Orderer
B

S Smart Contract
4. P4 group endorsed transactions sequentially into a block, B
and sends it to ALL peer nodes. Tx1
Tx2
Tx3
 Transactions Recording (5) A
Client
Application

E N Blockchain
S
Network
P1 P2 P3
A1 L’ L’ L’
P Peer node

O L Ledger
A2
P4 P5 P6
L’ L’ E O Endorser /
L’
N Orderer

S Smart Contract
5. Each peer validates the newly received block and updates its
ledger accordingly.
A Note on Endorser (1)
› Different chaincode will have different endorser, or a
different set of endorsers
› Peer node validate transactions in the validation phase
based on the endorsement policy.
– A typical endorsement policy allows the chaincode to specify the
endorsers;
– It uses a monotone logical expression on sets, such as three-
out-of-five or (P1 and P2) or P3)
› In order words, transactions validation relies on the trust
placed on the endorsers

30
A Note on Endorser (2)
› Endorser only check that the execution of the chaincode is
correct with respect to the current state of its local
blockchain
› The order of transactions may affect its validity
› The endorser “simulate” the execution of the transaction,
using the current state of the ledger, and produce an
endorsed transaction together with a read-write set (i.e. rw-
set)
› Readset contains all “variables” that have been read during
the execution of the transaction, together with the version of
the variable being read
› Writeset contains all “variables” that have been modified,
together with the new values
A Note on Orderer
› The orderer does not verify anything about the endorsed
transactions. It purely assembles them into blocks and
give them an order
› The order of the transactions may affect whether they
pass the validation by the peer node
› Integrity of the Fabric blockchain relies on the
consistency of the orderer
› What if an orderer give different peer nodes different
blockchains?
A Note on Peer Node
› A peer node may not have the chaincode
› Correct execution of the transaction relies on the trust of
the endoser
› The peer node validates each transaction means
– Check that the transaction satisfies the endorsement policy (e.g.
sufficient endorsers endorsed the transaction)
– Check that there is not read-write conflict with respect to the
peer node’s local copy of the ledger
Roles are logical
› Each peer node may play multiple roles
– Endorser of some chaincode
– Orderer
› Each role may be played by several peer node
– The endorsement policy of a chaincode like Two out of three of
peer node 1, 2 and 3 (in this case peer node 1 , 2, 3 are all
endorser of the chaincode)
– There may be multiple orderers (or ordering service nodes,
OSN). They together design the total order of all transactions
› Separation of the trust placed on “correctness of
transactions” (trust the endorsers) and “ordering of
transactions” (trust the orderers)
34
Membership Service Provider (MSP)
› The above architecture requires each node to have an
identity
› MSP identifies which Intermediate Certificate Authority
and Root Certificate Authority are trusted for defining the
members of a trusted domain
Channels
› In Hyperledger Fabric, a channel is a separate ledger.
This means a separate blockchain, and separate world
states
› A peer may join multiple channels

36