an open-source distributed operating system for permissioned blockchains · bitcoin blockchain 1.0...

© 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


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


Blockchain transactions and distributed applications

• Bitcoin transactions- simple virtual cryptocurrency transfers

4




• Transactions do not have to be simple nor related to cryptocurrency- Distributed applications- smart contracts (Ethereum) or chaincodes (Hyperledger Fabric)

5




• 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


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



8



2014Ethereum Blockchain 2.0

• Distributed applications (smart contracts) in a domain-specific language (Solidity)• Proof-of-work-consensus• Native cryptocurrency (ETH)• Permissionless blockchain system



9



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


Hyperledger Fabric – key requirements

No native cryptocurrency

Ability to code distributed apps in general-purpose languages

Modular/pluggable consensus

10


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

http://github.com/hyperledger/fabric

http://github.com/hyperledger/fabric


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




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





• Block Validation / Smart Contract Execution (every miner)

– Validating (executing) transactions in the payload

– Verifying hash of Block #27 < DIFFICULTY

14

#24… #25 #26


Block #27



Miner of block #27





• Block Validation / Smart Contract Execution (every miner)

– Validating (executing) transactions in the payload

– Verifying hash of Block #27 < DIFFICULTY

15

#24… #25 #26


Block #27



Miner of block #27

ORDER → EXECUTE architecture

Nodes execute smart-contracts after consensus (PoW)


Permissioned Blockchains

Nodes (participants) need a permission to participate in the blockchain network

16




Motivation─ business applications of blockchain and distributed ledger technology (DLT)─ Improving performance of public permissionless blockchains

17




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


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


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?


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


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


What are the issues with

ORDER → EXECUTE

architecture?

23


ORDER→EXECUTE architecture issues (Blockchain 2.0) Sequential execution of smart contracts

24



─ long execution latency blocks other smart contracts, hampers performance─ DoS smart contracts (e.g., infinite loops)

25



─ 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





Non-determinism

27





Non-determinism─ Smart-contracts must be deterministic (otherwise – state forks)

28





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







(Java, golang, etc)

Confidentiality of execution: all nodes execute all smart contracts

30







(Java, golang, etc)


Inflexible consensus: Consensus protocols are hard-coded

31







(Java, golang, etc)



Inflexible trust-model: Exposing low-level consensus assumptions

32


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)


HLF v1 architecture

OO

OO OO

OO

Ordering Service

ClientApplication

SDK (HFC)

MembershipServicesProvider

Peer

EndorserEndorser

Ledger

CommitterCommitter

AAChaincode BB

!Events

34


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


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


Endorsement Policy

Key:

E0E0

ClientApplication E1E1

E2E2

SDK

Ordering-Service

OO

OO OO

OOP

P4P4P3P3

AABB

AABB

AABB

AADD

Hyperledger Fabric

36


Step 3/7 – Proposal Response

Endorser Ledger

Committing Peer

Application

Ordering Node


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


Step 4/7 – Order Transaction

Endorser Ledger

Committing Peer

Application

Ordering Node


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


Step 5/7 – Deliver Transaction

Endorser Ledger

Committing Peer

Application

Ordering Node


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


Step 6/7 – Validate Transaction

Endorser Ledger

Committing Peer

Application

Ordering Node


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


Step 7/7 – Notify Transaction

Endorser Ledger

Committing Peer

Application

Ordering Node


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







(Java, golang, etc)



Inflexible trust-model: Exposing low-level consensus assumptions

42


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


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


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


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)


4

46


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


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


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


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


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


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)



4

Validate(readset)Validate(endorsement, chaincodeID, EP)

Validate(readset)Validate(endorsement, chaincodeID, EP)

52


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


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


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)


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

an open-source distributed operating system for permissioned blockchains · bitcoin blockchain 1.0...

Documents