02 - Introduction to Hyperledger Fabric

A Distributed Operating System For
Permissioned Blockchains
Intelligent Blockchain Engineering Lab
Department of Computer Science Engineering
Korea University
MPYANA MWAMBA MERLEC
January 2019

2
 Hyperledger Fabric is a modular and extensible open-source system
 For deployment and operating permissioned/private blockchains
 One of the Hyperledger projects hosted by the Linux Foundation – www.hyperleder.org
Hyperledger Projects Umbrella Strategy by the Hyperledger Architecture Working Group (HAWG)
Hyperledger Project Overview

3
 First truly extensible blockchain system for running distributed applications
 It runs Dapps written in standard, general-purpose programming languages
 Without systematic dependency on native cryptocurrency
 It supports modular consensus protocols
 Allowing the system to be tailored to particular use cases and trust models
 It realizes the permissioned model using a portable notion of membership
 Which may be integrated with industry-standard identity management (i.e. AD or LDAP)
For ﬂexibility, Fabric introduces an entirely novel blockchain design and reinvent the way blockchains cope
with nondeterminism, resource exhaustion, and performance attacks.
*Lightweight Directory Access Protocol
Introduction

4
 Blockchains depart for traditional State-Machine Replication (SMR)
 With Byzantine faults in important ways :
 To achieve these differences new designs are required !!!
Not only one, but distributed applications run concurrently
Applications may be deployed dynamically and by anyone
Application code is untrusted, potentially even malicious
(1)
(2)
(3)
Introduction

5
Order-Execute (OE) architecture in replicated services
 Many existing smart-contract blockchains’ implementations follow a SMR approach
 Known as “active replication”
(1) A protocol for consensus or atomic broadcast, first orders the transactions and propagated them to all peers
(2) Each peer executes the transaction sequentially and all transactions must be deterministic
Order-Execute Architecture for Blockchains

 Limits performance & scalability
 Complex measures are needed to
prevent DoS attacks
 Can be difficult to ensure programmatically  Since every SC runs on all peers
 Prohibits the dissemination of contract
code and state to subset of peers
6
 Prior permissioned Blockchains suffer from many limitations
 Adoption of the Order-Execute Architecture (OEV) with an additional transaction validation step
 No “one-size-fits-all” (BFT) consensus
protocols
 Determined by the consensus protocol
 Cannot be adapted to smart contracts or
apps’ requirements
 Fixes, non-standard or domain-specific
language
 Obstructs wide-spread adoption
 May lead to programming errors
Non-flexible trust model of
transaction validation
Consensus is hard-coded
within the platform
Smart Contracts
Programming Languages
Sequential execution of all
transactions
Transactions must be
deterministic
Confidentiality
Limitation of Order-Execute (OE) based Approach

8
 View as a Distributed Operating System For Permissioned Blockchains
 Proposed as a foundation for developing blockchain applications or solutions with a modular
architecture
 It allows components, such as consensus and membership services, to be plug-and-play
It’s a blockchain framework implementation and one of the
Hyperledger projects hosted by The Linux Foundation.
Hyperledger Fabric Overview

9
 Fabric typically executes transactions before reaching final agreement on their order
 Its design combines two well-known approaches to replication
Often used in distributed Databases
Middleware-based asymmetric update processing
Ported to untrusted environment with Byzantine
Faults
Passive or Primary-backup
Replication
Updates the ledger state only after reaching
consensus on a total order among transactions
 in a deterministic validation step executed by
each peer individually
 Allows Fabric to respect application-specific
trust assumptions according to the transaction
endorsement
Active Replication
In Fabric, every transaction is executed (endorsed) only by a subset of the peers, which allows for
parallel execution and addresses potential non-determinism, drawing on “execute-verify” BFT replication.
Hyperledger Fabric Overview

10
Source: Gaur, Nitin, et al. Hands-On Blockchain with Hyperledger: Building decentralized applications with Hyperledger Fabric and Composer. Packt Publishing Ltd, 2018.
Hyperledger Fabric Reference Architecture

 Fabric architecture follows a novel Execute-Order-Validate paradigm
 For distributed execution of untrusted code in an untrusted environment
 Separates transactions flow into 3 steps that can be run on different entities in a system
11
Execute-Order-Validate architecture of Fabric
Execute-Order-Validate Scheme

12
 Fabric is the first blockchain system that introduced pluggable consensus
 Previously, all blockchain systems, permissioned or not, came with a hard-coded consensus protocol
Require validators to solve difficult
cryptographic puzzles.
PROS:
- Works in public/untrusted networks
CONS:
- High energy consumption,
- Slow transactions confirmation
e.g. : Bitcoin, Ethereum, EOS
Require validators to hold currency in escrow
PROS:
- Works in public/untrusted networks
CONS:
- Requires intrinsic (crypto)currency
- “Noting at stake” problem
e.g. : Corda, PeerCoin, Nxt
Validators apply received transactions without
consensus
PROS:
- Very Quick; suitable for development
CONS:
- Nos consensus (single node, development)
- Can lead to divergent chains
e.g. : Hyperledger Fabric V1
Practical Byzantine Fault-Tolerance imple
mentations
PROs:
- Reasonable efficient
- Tolerant against malicious peers (n > 3f peers)
CONS:
- Validators should be known and totally connected
e.g. : Hyperledger Fabric V 0.6
Wait time in a trusted execution environment
randomizes block generation
PROS:
- Efficient
CONS:
- Currently tailored towards one vendor
e.g. : Hyperledger Sawtooth
Ordering service distributes blocks to peers
PROS:
- Efficient and Crash Fault tolerant
CONS:
- Doesn’t guard against malicious activity
e.g. : Hyperledger Fabric V1
Adaptive Consensus Protocols

13*KVS – Key Value Store
Hyperledger Platform Layer Architecture Peer Node Layer Architecture
Hyperledger Fabric – Peer Node

 Fabric architecture novelty lies on a hybrid replication design approach
 mixes passive replication in Byzantine model and execute-order-validate paradigm
 Contains modular building blocks for each of the following components:
14
Ordering
Service
 Automatically broadcasts state updates to peers and establishes consensus on the order of
transactions.
Membership
Service (MSP)
 Responsible for associating peers with cryptographic identities.
 It maintains the permissioned nature of Fabric.
P2P Gossip
Service
 Disseminates the blocks output by ordering service to all peers.
Smart Contracts  SCs in Fabric run within container environment for isolation.
 Can be written in standard programming languages
 Don’t have direct access to the ledger state
Ledger  Maintained by each peer locally in form of the append-only blockchain and as a snapshot of
the most recent state in a key-value store
Fabric Architecture Overview

15
A Fabric Network with Federated MSPs and Running Multiple (differently shared and colored) Chaincodes,
Selectively installed on peers according to policy
 Fabric architecture novelty lies on a hybrid replication design approach
 mixes passive replication in Byzantine model and execute-order-validate paradigm
Source: Androulaki, Elli, et al. "Hyperledger fabric: a distributed operating system for permissioned blockchains." Proceedings of the Thirteenth EuroSys Conference. ACM, 2018.

16
Hyperledger Fabric V1.0 System Architecture
*HFC – Hyperledger Fabric Client
Events – Creates notifications of significant operations on
the blockchain (e.g. a new block), as well as
notifications related to smart contracts

17Source: https://youtu.be/rmf04ylI2K0
 Chaincode (a.k.a Smart Contract) Fabric run within container environment for isolation
Chaincode Execution Environment

18Source: Gaur, Nitin, et al. Hands-On Blockchain with Hyperledger: Building decentralized applications with Hyperledger Fabric and Composer. Packt Publishing Ltd, 2018.
Typical 3-Layer Architecture of a Fabric App.

19
World State Examples:
myCar.vin = 1234
myCar.owner = Merlec
myCar.make = Kim
…
Smart contact implementation :
setOwner(Car, newOwner) {
set Car.owner = newOwner
}
Transaction submitted input :
invoke(myContract, setOwner,
myCar, Merlec)
How Applications interact with the ledger

20
https://jira.hyperledger.org/projects/FABN/issues/FABN-692?filter=allissues
Network, Gateway and Smart Contracts

22
Source : https://github.com/LennartFr/Blockchain-at-Galvanize
Hyperledger Fabric Working Principle

24Fabric High Level Transaction Flow
Invocation Chaincode
execution1 Endorsement
collection2
Ordering
Broadcast/Delivery3 4 Validation5 Commit
5
55
5
Execution Phase

25
Step 1/7 – Proposal Transaction

26
Step 2/7 – Execute Proposal

27
Step 3/7 – Proposal Response

28
Step 4/7 – Order Transaction

29
Step 5/7 – Deliver Transaction

30
Step 6/7 – Validate Transaction

31
Step 7/7 – Notify Transaction

33https://cdn-images-1.medium.com/max/880/1*0HyKsOag1W68z5aJOahcBA.gif
Hyperledger Fabric Transaction Flow illustration

34
Blockchain Network Integration with Existing Systems — Source: IBM Code Tech Talk
Hyperledger Integration with Existing Systems

35
Hyperledger Blockchain Overview

36
Source : http://hyperledger-fabric.readthedocs.io/en/release-1.2/ledger/ledger.html
A ledger contains the current state of a business
as a journal of transactions.
 A blockchain ledger consists of two distinct, though related,
parts – a world state and a blockchain.
 Ledger states are by default, expressed as key-value pairs.
- Transaction log recording all the changes
that determine the world state.
 It is an immutable sequence of blocks,
each of which contains a set of ordered
transactions.
- Database holding the current values of
a set of ledger states (e.g. Key/Value).
Blockchain Ledger Structure

37
Block Header
 Block number: An integer starting at 0 (the genesis block)
 Increased by 1 for every new block appended to the BC
 Current Block Hash: contains the hash of all the transactions.
 Previous Block Hash: a copy of the hash of previous block in
the chain.
Block Data : contains a list of transactions arranged in order.
 It is written when the block is created
Block Metadata: contains the time when the block was written
 the certificate, public key and signature of the block writer
Block Structure

38
Header : captures some essential metadata about the transaction.
 e.g. the name of the relevant chaincode and its version.
Signature: contains a cryptographic signature, created by the client app.
 It is used to check that the transaction details have not been tampered
with, as it requires the application’s private key to generate it.
Proposal: encodes input parameters supplied by an app. to the chaincode
which creates the proposed ledger update.
Response: captures before and after values of the world state, as a Read
Write set (RW-set).
Endorsements: is a list of signed transaction responses from each
required organization sufficient to satisfy the endorsement policy.
A transaction captures changes to the world state.
It contains following fields :
Transaction Structure

39
Blockchain is a transaction log, structured as interlinked blocks,
 where each block contains a sequence of transactions,
 each of which represents a query or update to the world state.
Blockchain Structure

40
The ledger is maintained by each peer node in a file system.
• The chaincode is allowed access to the shared state by well-defined ledger APIs.
Blockchain Ledger Structure

41
Applications and Peers
Source: https://hyperledger-fabric.readthedocs.io
Interactions between Applications and Peers

43
[1] Androulaki, Elli, et al. "Hyperledger fabric: a distributed operating system for permissioned blockchains." Proceedings of the Thirteenth EuroSys
Conference. ACM, 2018. https://dl.acm.org/citation.cfm?id=3190538
[2] Cachin, Christian. "Architecture of the Hyperledger blockchain fabric." Workshop on Distributed Cryptocurrencies and Consensus Ledgers. 2016.
[3] Design Philosophy and ConsensusBob Dill, David Smits, Zero to Blockchain, IBM Redbooks course, 2017
[4] LinuxFoundationX: LFS171x Blockchain for Business - An Introduction to Hyperledger Technologies, edx MOOC 2017
[5] Hyperledger Architecture, Volume 1: Introduction to Hyperledger Business Blockchain Design Philosophy and Consensus
https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf
[6] Hyperledger Architecture, Volume 2: Smart Contracts - https://www.hyperledger.org/wp-content/uploads/2018/04/Hyperledger_Arch_WG_Paper_2_SmartContracts.pdf
[7] https://www.hyperledger.org/resources/publications#presentations
[8] http://hyperledger-fabric.readthedocs.io/en/master/index.html | https://hyperledger-fabric.readthedocs.io/en/release-1.2/membership/membership.html
[9] https://developer.ibm.com/code/wp-content/uploads/sites/118/2017/09/Marbles_BlockChain_Tech_Talk1.pdf
[10] https://www.altoros.com/blog/hyperledger-fabric-v1-0-to-bring-improved-transactions-and-a-pluggable-data-store/
[11] https://github.com/yeasy/hyperledger_code_fabric/blob/master/README.md
[12] https://fabric-sdk-node.github.io/
[13] https://developer.ibm.com/blockchain/ | https://www.ibm.com/developerworks/cloud/library/cl-blockchain-basics-intro-bluemix-trs/
References

Q & A
44
mlecjm@korea.ac.kr mlecjm

02 - Introduction to Hyperledger Fabric

More Related Content

What's hot (20)

Similar to 02 - Introduction to Hyperledger Fabric (20)

Recently uploaded (20)

02 - Introduction to Hyperledger Fabric