© 2018 IBM Corporation
Hyperledger Fabric:
an Open-Source Distributed Operating System for Permissioned Blockchains
Mohan Dhawan, IBM Research – India
August 18th 2018
(Some slides borrowed from Marko Vukolić, IBM Research - Zurich)
© 2015 IBM Corporation© 2018 IBM Corporation
What is a Blockchain?• A chain (sequence, typically a hash chain) of blocks of transactions
- Each block consists of a number of (ordered) transactions- Blockchain establishes total order of transactions
2
© 2015 IBM Corporation© 2018 IBM Corporation
What is a Blockchain?• A chain (sequence, typically a hash chain) of blocks of transactions
- Each block consists of a number of (ordered) transactions- Blockchain establishes total order of transactions
3
#24 #25 #26…#1#0
Genesis block
Node A Node E
Node B Node D
Node C
Node F
Ledger
Ledger
Ledger
Ledger
Ledger
Ledger
Consensus protocol ensures ledger replicas are identical*
datastructure
Network of untrusted nodes
© 2015 IBM Corporation© 2018 IBM Corporation
Blockchain transactions and distributed applications
• Bitcoin transactions- simple virtual cryptocurrency transfers
4
© 2015 IBM Corporation© 2018 IBM Corporation
Blockchain transactions and distributed applications
• Bitcoin transactions- simple virtual cryptocurrency transfers
• Transactions do not have to be simple nor related to cryptocurrency- Distributed applications- smart contracts (Ethereum) or chaincodes (Hyperledger Fabric)
5
© 2015 IBM Corporation© 2018 IBM Corporation
Blockchain transactions and distributed applications
• Bitcoin transactions- simple virtual cryptocurrency transfers
• Transactions do not have to be simple nor related to cryptocurrency- Distributed applications- smart contracts (Ethereum) or chaincodes (Hyperledger Fabric)
A smart contract is an event driven program, with state, which runs on a replicated, shared ledger and which can take custody over assets on that
ledger. [Swanson2015]
6
© 2015 IBM Corporation© 2018 IBM Corporation
Blockchain evolution (2009-present)
2009Bitcoin Blockchain 1.0
• A hard-coded cryptocurrency application w. limited stack-based scripting language• Proof-of-work-consensus• Native cryptocurrency (BTC)• Permissionless blockchain system
7
© 2015 IBM Corporation© 2018 IBM Corporation
Blockchain evolution (2009-present)
8
2009Bitcoin Blockchain 1.0
• A hard-coded cryptocurrency application w. limited stack-based scripting language• Proof-of-work-consensus• Native cryptocurrency (BTC)• Permissionless blockchain system
2014Ethereum Blockchain 2.0
• Distributed applications (smart contracts) in a domain-specific language (Solidity)• Proof-of-work-consensus• Native cryptocurrency (ETH)• Permissionless blockchain system
© 2015 IBM Corporation© 2018 IBM Corporation
Blockchain evolution (2009-present)
9
2009Bitcoin Blockchain 1.0
• A hard-coded cryptocurrency application w. limited stack-based scripting language• Proof-of-work-consensus• Native cryptocurrency (BTC)• Permissionless blockchain system
2014Ethereum Blockchain 2.0
• Distributed applications (smart contracts) in a domain-specific language (Solidity)• Proof-of-work-consensus• Native cryptocurrency (ETH)• Permissionless blockchain system
2017Hyperledger
FabricBlockchain 3.0
• Distributed applications (chaincodes) in different general-purpose languages (e.g., golang, Java) • Modular/pluggable consensus• No native cryptocurrency• Multiple instances/deployments• Permissioned blockchain system
© 2015 IBM Corporation© 2018 IBM Corporation
Hyperledger Fabric – key requirements
No native cryptocurrency
Ability to code distributed apps in general-purpose languages
Modular/pluggable consensus
10
© 2015 IBM Corporation© 2018 IBM Corporation
Hyperledger Fabric – key requirements
No native cryptocurrency
Ability to code distributed apps in general-purpose languages
Modular/pluggable consensus
11
Satisfying these requirements required a complete overhaul of the (permissioned) blockchain design!
end result
Hyperledger Fabric v1http://github.com/hyperledger/fabric
© 2015 IBM Corporation© 2018 IBM Corporation
We will skip many details
Membership Service Provider (and CAs)
Chaincode details
Gossip
Ledger design
Channels
http://hyperledger-fabric.readthedocs.io/en/latest/
Focus of this talk is on
system architecture and distributed systems aspects
12
© 2015 IBM Corporation© 2018 IBM Corporation
Permissionless Blockchains
• PoW Consensus • Block “mining”
• Block #27 propagation to the network (gossip)
13
#24… #25 #26
A =hash of block #26 B = Root hash of Merkle tree of tx hashesC = nonce
Block #27
Transactions(payload)
• Validating (executing) transactions in the payload• Finding nonces such that h = hash of Block #27 = SHA256(A||B||C) < DIFFICULTY
Miner of block #27
© 2015 IBM Corporation© 2018 IBM Corporation
Permissionless Blockchains
• PoW Consensus • Block “mining”
• Block #27 propagation to the network (gossip)
• Block Validation / Smart Contract Execution (every miner)
– Validating (executing) transactions in the payload
– Verifying hash of Block #27 < DIFFICULTY
14
#24… #25 #26
A =hash of block #26 B = Root hash of Merkle tree of tx hashesC = nonce
Block #27
Transactions(payload)
• Validating (executing) transactions in the payload• Finding nonces such that h = hash of Block #27 = SHA256(A||B||C) < DIFFICULTY
Miner of block #27
© 2015 IBM Corporation© 2018 IBM Corporation
Permissionless Blockchains
• PoW Consensus • Block “mining”
• Block #27 propagation to the network (gossip)
• Block Validation / Smart Contract Execution (every miner)
– Validating (executing) transactions in the payload
– Verifying hash of Block #27 < DIFFICULTY
15
#24… #25 #26
A =hash of block #26 B = Root hash of Merkle tree of tx hashesC = nonce
Block #27
Transactions(payload)
• Validating (executing) transactions in the payload• Finding nonces such that h = hash of Block #27 = SHA256(A||B||C) < DIFFICULTY
Miner of block #27
ORDER → EXECUTE architecture
Nodes execute smart-contracts after consensus (PoW)
© 2015 IBM Corporation© 2018 IBM Corporation
Permissioned Blockchains
Nodes (participants) need a permission to participate in the blockchain network
16
© 2015 IBM Corporation© 2018 IBM Corporation
Permissioned Blockchains
Nodes (participants) need a permission to participate in the blockchain network
Motivation─ business applications of blockchain and distributed ledger technology (DLT)─ Improving performance of public permissionless blockchains
17
© 2015 IBM Corporation© 2018 IBM Corporation
Permissioned Blockchains
Nodes (participants) need a permission to participate in the blockchain network
Motivation─ business applications of blockchain and distributed ledger technology (DLT)─ Improving performance of public permissionless blockchains
In business applications─ Participant often need ability to identify other participants─ Participants do not necessarily trust each other
Examples: Kadena, Tendermint, Ripple, Symbiont, Hyperledger Fabric, etc.
18
© 2015 IBM Corporation© 2018 IBM Corporation
Permissionless vs. Permissioned Blockchain
19
Permissionless Permissioned
Consensus Proof of Work (Bitcoin, Ethereum,...) BFT state machine replication (Ripple, Hyperledger, …)
User IDs(Sybil attack)
Decentralized, Anonymous(Decentralized protection by PoW compute/hash power)
Centralized, all Nodes know all other Nodes (Centralized identity management protects against Sybil attacks)
Scalability(no. of Nodes)
Excellent, >100k Nodes Verified up to few tens (or so) NodesCan scale to 100 nodes with certain performance degradation(scalability limits not well explored)
Scalability(no. of Clients)
Excellent Excellent
Latency Poor, up to 1h (Bitcoin)From 9-10 mins (Ethereum)
Depends on the implementation/deployment (order of ms)
Peak Throughput
3 to 7 tx/sec (Bitcoin)10 to 30 tx/sec (Ethereum)
>10k tx/sec with existing implem. in software [<10 nodes]
Power efficiency
>1 GW (Bitcoin) Good (commodity hardware)
Temporary forks in blockchain
Possible (leads to double-spending attacks)
Not possible
Consensus Finality
No Yes
© 2015 IBM Corporation© 2018 IBM Corporation
Permissionless vs. Permissioned Blockchain
20
Permissionless Permissioned
Consensus Proof of Work (Bitcoin, Ethereum,...) BFT state machine replication (Ripple, Hyperledger, …)
User IDs(Sybil attack)
Decentralized, Anonymous(Decentralized protection by PoW compute/hash power)
Centralized, all Nodes know all other Nodes (Centralized identity management protects against Sybil attacks)
Scalability(no. of Nodes)
Excellent, >100k Nodes Verified up to few tens (or so) NodesCan scale to 100 nodes with certain performance degradation(scalability limits not well explored)
Scalability(no. of Clients)
Excellent Excellent
Latency Poor, up to 1h (Bitcoin)From 9-10 mins (Ethereum)
Depends on the implementation/deployment (order of ms)
Peak Throughput
3 to 7 tx/sec (Bitcoin)10 to 30 tx/sec (Ethereum)
>10k tx/sec with existing implem. in software [<10 nodes]
Power efficiency
>1 GW (Bitcoin) Good (commodity hardware)
Temporary forks in blockchain
Possible (leads to double-spending attacks)
Not possible
Consensus Finality
No Yes
Open research problem:Given the use case, network, no. of nodes
What is the most suitable and scalable Blockchain technology/protocol?
© 2015 IBM Corporation© 2018 IBM Corporation
Permissioned Blockchain 2.0 architecture
21
Node A (leader)
Node BNode C
Node D
Tx1
Tx2
Tx3
Tx4
Seq #24View no
… #21 #22 #23 Tx1
Tx2
Tx3
Tx4
Seq #24View no
Execute tx
© 2015 IBM Corporation© 2018 IBM Corporation
Permissioned Blockchain 2.0 architecture
22
Node A (leader)
Node BNode C
Node D
Tx1
Tx2
Tx3
Tx4
Seq #24View no
… #21 #22 #23 Tx1
Tx2
Tx3
Tx4
Seq #24View no
Execute tx
Active state machine replication [Schneider90]• ORDER → EXECUTE architecture• Inputs to the state machine (smart contract txs) are totally ordered• Executed in sequence, after consensus (ordering)• ALL permissioned blockchains are architected like this (incl Hyperledger Fabric v0.6), until Fabric v1
© 2015 IBM Corporation© 2018 IBM Corporation
What are the issues with
ORDER → EXECUTE
architecture?
23
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
24
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)
25
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
26
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
Non-determinism
27
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
Non-determinism─ Smart-contracts must be deterministic (otherwise – state forks)
28
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
Non-determinism─ Smart-contracts must be deterministic (otherwise – state forks) ─ How Blockchain 2.0 copes with it:
• Enforcing determinism: Solidity DSL, Ethereum VM• Cannot code smart-contracts in developers favorite general-purpose language
(Java, golang, etc)
29
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
Non-determinism─ Smart-contracts must be deterministic (otherwise – state forks) ─ How Blockchain 2.0 copes with it:
• Enforcing determinism: Solidity DSL, Ethereum VM• Cannot code smart-contracts in developers favorite general-purpose language
(Java, golang, etc)
Confidentiality of execution: all nodes execute all smart contracts
30
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
Non-determinism─ Smart-contracts must be deterministic (otherwise – state forks) ─ How Blockchain 2.0 copes with it:
• Enforcing determinism: Solidity DSL, Ethereum VM• Cannot code smart-contracts in developers favorite general-purpose language
(Java, golang, etc)
Confidentiality of execution: all nodes execute all smart contracts
Inflexible consensus: Consensus protocols are hard-coded
31
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
Non-determinism─ Smart-contracts must be deterministic (otherwise – state forks) ─ How Blockchain 2.0 copes with it:
• Enforcing determinism: Solidity DSL, Ethereum VM• Cannot code smart-contracts in developers favorite general-purpose language
(Java, golang, etc)
Confidentiality of execution: all nodes execute all smart contracts
Inflexible consensus: Consensus protocols are hard-coded
Inflexible trust-model: Exposing low-level consensus assumptions
32
© 2015 IBM Corporation© 2018 IBM Corporation
HLF v1 architecture in one slide
Existing blockchains’ architecture
ORDER → EXECUTE (input tx) (tx against smart contracts)
Hyperledger Fabric v1 architecture
EXECUTE → ORDER → VALIDATE
(tx against smart contracts) (versioned state updates) (versions, execution attestations)
33
Application developers specify two application components:● Chaincode (execution code)● Endorsement policy (validation code)
© 2015 IBM Corporation© 2018 IBM Corporation
HLF v1 architecture
OO
OO OO
OO
Ordering Service
ClientApplication
SDK (HFC)
MembershipServicesProvider
Peer
EndorserEndorser
Ledger
CommitterCommitter
AAChaincode BB
!Events
34
© 2015 IBM Corporation© 2018 IBM Corporation
Application proposes transaction
Endorsement policy:• “E0, E1 and E2 must sign”• (P3, P4 are not part of the
policy)
Client application submits a transaction proposal for Smart Contract A. It must target the required peers {E0, E1, E2}
Step 1/7 – Propose Transaction
Endorser Ledger
Committing Peer
Application
Ordering Node
Smart Contract(Chaincode)
Endorsement Policy
Key:
E0E0
E1E1
E2E2
ClientApplication
SDK
Hyperledger Fabric
Ordering-Service
OO
OO OO
OOP
P4P4P3P3
AABB
AABB
AABB
AADD
35
© 2015 IBM Corporation© 2018 IBM Corporation
Step 2/7 – Execute ProposalEndorsers Execute Proposals
E0, E1 & E2 will each execute the proposed transaction. None of these executions will update the ledger
Each execution will capture the set of Read and Written data, called RW sets, which will now flow in the fabric.
Transactions can be signed & encrypted
Endorser Ledger
Committing Peer
Application
Ordering Node
Smart Contract(Chaincode)
Endorsement Policy
Key:
E0E0
ClientApplication E1E1
E2E2
SDK
Ordering-Service
OO
OO OO
OOP
P4P4P3P3
AABB
AABB
AABB
AADD
Hyperledger Fabric
36
© 2015 IBM Corporation© 2018 IBM Corporation
Step 3/7 – Proposal Response
Endorser Ledger
Committing Peer
Application
Ordering Node
Smart Contract(Chaincode)
Endorsement Policy
Key:
Application receives responses
RW sets are asynchronously returned to application
The RW sets are signed by each endorser, and also includes each record version number
(This information will be checked much later in the consensus process)
E0E0
ClientApplication E1E1
E2E2
SDK
Ordering-Service
OO
OO OO
OOP
P4P4P3P3
AABB
AABB
AABB
AADD
Hyperledger Fabric
37
© 2015 IBM Corporation© 2018 IBM Corporation
Step 4/7 – Order Transaction
Endorser Ledger
Committing Peer
Application
Ordering Node
Smart Contract(Chaincode)
Endorsement Policy
Key:
Application submits responses for ordering
Application submits responses as a transaction to be ordered.
Ordering happens across the fabric in parallel with transactions submitted by other applications
E0E0
E1E1
E2E2 OO
OO OO
OOP
ClientApplication
SDK
Ordering-Service
P4P4P3P3
AABB
AABB
AABB
AADD
Hyperledger Fabric
(other applications)38
© 2015 IBM Corporation© 2018 IBM Corporation
Step 5/7 – Deliver Transaction
Endorser Ledger
Committing Peer
Application
Ordering Node
Smart Contract(Chaincode)
Endorsement Policy
Key:
Orderer delivers to all committing peers
Ordering service collects transactions into proposed blocks for distribution to committing peers. Peers can deliver to other peers in a hierarchy (not shown)
Different ordering algorithms available:
• Solo (Single node, development)• Kafka (Crash fault tolerance)
E0E0
E1E1
E2E2 OO
OO OO
OOP
ClientApplication
SDK
Ordering-Service
P4P4P3P3
AABB
AABB
AABB
AADD
Hyperledger Fabric
39
© 2015 IBM Corporation© 2018 IBM Corporation
Step 6/7 – Validate Transaction
Endorser Ledger
Committing Peer
Application
Ordering Node
Smart Contract(Chaincode)
Endorsement Policy
Key:
E0E0
E1E1
E2E2 OO
OO OO
OOP
ClientApplication
SDK
Ordering-Service
P4P4P3P3
* * *
*
*
AABB
AABB
AABB
AADD
Hyperledger Fabric
Committing peers validate transactions
Every committing peer validates against the endorsement policy. Also check RW sets are valid for world state.
Validated transactions are applied to world state and retained on the ledger.
Invalid transactions are also retained on the ledger but do not update world state.
40
© 2015 IBM Corporation© 2018 IBM Corporation
Step 7/7 – Notify Transaction
Endorser Ledger
Committing Peer
Application
Ordering Node
Smart Contract(Chaincode)
Endorsement Policy
Key:
Committing peers notify applications
Applications can register to be notified when transactions succeed or fail, and when blocks are added to the ledger
Applications will be notified by each peer to which they are connected
E0E0
AABB
E1E1
AABB
E2E2
AABB
OO
OO OO
OOP
ClientApplication
SDK
Ordering-Service
P3P3
AADD
P4P4
!
!
!
!
! !
Hyperledger Fabric
41
© 2015 IBM Corporation© 2018 IBM Corporation
ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts
─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)─ How Blockchain 2.0 copes with it:
• Gas (paying for every step of computation))• Tied to a cryptocurrency
Non-determinism─ Smart-contracts must be deterministic (otherwise – state forks) ─ How Blockchain 2.0 copes with it:
• Enforcing determinism: Solidity DSL, Ethereum VM• Cannot code smart-contracts in developers favorite general-purpose language
(Java, golang, etc)
Confidentiality of execution: all nodes execute all smart contracts
Inflexible consensus: Consensus protocols are hard-coded
Inflexible trust-model: Exposing low-level consensus assumptions
42
© 2015 IBM Corporation© 2018 IBM Corporation
Challenge #1: Sequential execution of smart-contracts
Goal─ Preventing that slow smart-contracts delay the system
Hyperledger Fabric v1 approach─ Partition execution of smart-contracts─ Only a subset of peers are endorsers for a given smart-contract (chaincode)
43
© 2015 IBM Corporation© 2018 IBM Corporation
What about DoS, resource exhaustion?
HLF v1 transaction flow is resilient* to non-determinism
Hence, endorsers can apply local policies (non-deterministically) to decide when to abandon the execution of a smart-contract─ No need for gas/cryptocurrency!
* EXECUTE→ORDER→VALIDATE:
non-deterministic tx are not guaranteed to be live
ORDER→EXECUTE
non-deterministic tx are not guaranteed to be safe (forks can occur)
44
© 2015 IBM Corporation© 2018 IBM Corporation
Challenge #2: Non-Determinism
Goal─ Enabling chaincodes in golang, Java, … (can be non-deterministic)─ While preventing state-forks due to non-determinism
Hyperledger Fabric v1 approach─ Execute smart contracts before consensus─ Use consensus to agree on propagation of versioned state-updates
45
© 2015 IBM Corporation© 2018 IBM Corporation
Hyperledger Fabric v1 Transaction flow
client (C)endorsingpeer (EP1)
endorsingpeer (EP2)
endorsingpeer (EP3)
Ordering service (consen sus)
orderers
Simulate/Execute txSign TX-ENDORSED
Collect “sufficient” no. of TX-ENDORSED Msgs into an endorsement
broadcast(endorsement)
1
2
4
3
1 <PROPOSE, clientID, chaincodeID, txPayload, timestamp, clientSig>
2 <TX-ENDORSED, peerID, txID, chaincodeID, readset, writeset>
3 BROADCAST(blob)
4 DELIVER(seqno,prevhash,block)
Total order semantics (HLF v1)
(committing)peer (CP4)
(committing)peer (CP5)
4
46
© 2015 IBM Corporation© 2018 IBM Corporation
On readset and writeset
Readset─ Contains all keys, read by the chaincode, during execution─ Along with their monotonically increasing version numbers
Writeset (state updates)─ Contains all keys written by the chaincode─ Along with their new values
Eventual application of writeset is conditional on readset being (still) valid in the Validation phase
47
© 2015 IBM Corporation© 2018 IBM Corporation
Challenge #3: Confidentiality of execution
Goal─ Not all nodes should execute all smart contracts
Hyperledger Fabric v1 approach─ Partition execution of smart-contracts─ Only a subset of peers are endorsers for a given smart-contract (chaincode)
48
© 2015 IBM Corporation© 2018 IBM Corporation
Challenge #4: Consensus modularity/pluggability
Goal─ With no-one-size-fits-all consensus:─ Consensus protocol must be modular and pluggable
Hyperledger Fabric v1 approach─ Fully pluggable consensus (was present in v0.6 design as well)
HLF v1 consensus (ordering service) implementations, Nov 2017─ Centralized! (SOLO, mostly for development and testing)─ Crash FT (KAFKA, thin wrapper around Kafka/Zookeeper)─ Proof of concept BFT
Many more to come (TBC)─ SGX Consensus (TU Braunschweig, Eurosys 2017), Honeybadger BFT (UIUC,
CCS’16), XFT (IBM, OSDI’16)
49
© 2015 IBM Corporation© 2018 IBM Corporation
Challenge #5: Smart-contract trust flexibility
Goal─ Preventing low level consensus trust assumptions (e.g., “f out of 3f+1”)
propagate to the application
Hyperledger Fabric v1 approach─ Let smart-contract developers specify application trust assumption─ Trust assumption captured within endorsement policy
50
© 2015 IBM Corporation© 2018 IBM Corporation
HLF v1 Endorsement Policies
Deterministic programs used for validation
Executed by all peers post-consensus
Examples─ K out of N chaincode endorsers need to endorse a tx─ Alice OR (Bob AND Charlie) need to endorse a tx
Cannot be specified by smart-contract developers
51
© 2015 IBM Corporation© 2018 IBM Corporation
Hyperledger Fabric v1 Transaction flow
client (C)endorsingpeer (EP1)
endorsingpeer (EP2)
endorsingpeer (EP3)
Ordering service (consen sus)
orderers
Simulate/Execute txSign TX-ENDORSED
Collect “sufficient” no. of TX-ENDORSED Msgs into an endorsement(to satisfy endorsement Policy (EP))
1
2
4
3
1 <PROPOSE, clientID, chaincodeID, txPayload, timestamp, clientSig>
2 <TX-ENDORSED, peerID, txID, chaincodeID, readset, writeset>
3 BROADCAST(blob)
4 DELIVER(seqno,prevhash,block)
Total order semantics (HLF v1)
(committing)peer (CP4)
(committing)peer (CP5)
4
Validate(readset)Validate(endorsement, chaincodeID, EP)
Validate(readset)Validate(endorsement, chaincodeID, EP)
52
© 2015 IBM Corporation© 2018 IBM Corporation
HLF v1 Endorsement Policies and Execution Flow
Endorsement Policy can, in principle, implement arbitrary program
Hybrid execution model
EXECUTE → ORDER → VALIDATE approach of HLF v1
Can be used to split execution in two
EXECUTE (smart-contracts) → can be non-deterministic
VALIDATE (endorsement policy) → must be deterministic
HLF v1 mixes
passive and active replication
into hybrid replication
53
© 2015 IBM Corporation© 2018 IBM Corporation
Why we re-architected Hyperledger Fabric?
Hyperledger Fabric requirements─ Run smart contracts (chaincodes) in general-purpose language(s)─ No native cryptocurrency─ Modular consensus (unlike other permissioned blockchains)
All permissioned blockchains (incl. HLF up to v0.6)
order → execute
pattern
This is problematic:─ Sequential execution (limits throughput, DoS transactions)─ All nodes execute all smart contracts (at odds with confidentiality)─ Non-deterministic execution (hinders consistency, may create “forks”)
54
© 2015 IBM Corporation© 2018 IBM Corporation
Why we re-architected Hyperledger Fabric?
HLF v1 approach in one line:
execute → order → validate
Permissioned blockchain architecture – overhauled
Modular/pluggable consensus─ There is no one-size-fits-all consensus (performance, trust flexibility)
Execute (chaincode) → Order (state updates) → Validate (endorsement policies)─ Chaincodes are no longer executed sequentially (performance, scalability)─ Not all peers execute all chaincodes (helps with confidentiality, scalability)─ Chaincode non-deterministic execution is not an issue (consistency)
Hybrid execution model (combining passive and active replication)
© 2015 IBM Corporation© 2018 IBM Corporation
Making blockchain real for business with over 400 engagements and multiple active networks
Trade Finance Pre and Post Trade Complex Risk Coverage
Identity/ Know your customer (KYC)Unlisted Securities/ Private Equity
Funds Loyalty Program
Medicated Health Data Exchange Fraud/ Compliance Registry Distributed Energy/ Carbon Credit
Supply Chain Food Safety Provenance/ Traceability
56
©2018 IBM Corporation
Thank You!