Consensus hyperledger

Page 1

Consensus in Hyperledger Fabric

Mohan Dhawan IBM Research, India


Hyperledger Fabric v/s Ethereum Characteristic

Hyperledger Fabric

Ethereum

Description of platform

Modular blockchain platform

Generic blockchain platform

Governance

Linux Foundation

Ethereum developers

Usage

Mission-critical managed enterprise applications

Anonymous “bitcoin-like” network optimized for “volume”, at the expense of managed governance

Mode of operation

Permissioned, private

Permissionless, public or private

Consensus

Broad understanding of consensus that allows multiple approaches

Mining based on Proof of Work (PoW) or Proof of Stake (PoS)

Transaction level

Ledger level

Identity

Participants declare who they are and their identities are confirmed

Anonymous

Network

“OPEN” by providing transparency of participants

“OPEN” to everyone anonymously

Trust

Trust in the parties

Transactions can be trusted; parties cannot be trusted as they are anonymous

Smart contracts

Smart contract code (e.g., Go, Java, JavaScript)

Smart contract code (e.g., Solidity)

Currency

None

Ether

Currency and tokens via chaincode

Tokens via smart contract

2


Hyperledger Fabric V1 Architecture ●

Ledger is a tamperproof record of transactions replicated across nodes in the network –

Chaincode is a program that typically handles business logic agreed to by members of the network, so it may be considered as a “smart contract” –

A blockchain is a decentralized and distributed digital ledger

Initializes and manages ledger state through transactions submitted by applications

Types of nodes –

Client ●

Peer ●

Submits an actual transaction-invocation to the endorsers, and broadcasts transactionproposals to the ordering service Commits transactions and maintains the state and a copy of the ledger. Besides, peers can have a special endorser role

Orderer ●

Runs the communication service that implements a delivery guarantee, such as atomic or total order broadcast

3


Hyperledger Fabric V1 Architecture Membership Services Provider

Peer Client Application

SDK (HFC)

Endorser Committer

O

O

Ledger Chaincode

O

O

Events

A A

B B

!

Ordering Service 4


Step 1/7 – Propose Transaction Application proposes transaction

P3

E0 A A

Client Application

S D K

P4 A A

B B

Endorsement policy: • “E0, E1 and E2 must sign” • (P3, P4 are not part of the policy)

D D

Client application submits a transaction proposal for Smart Contract A. It must target the required peers {E0, E1, E2}

E1 A A

O

B B

P

E2

O

O

Key:

Endorser

Ledger

Committing Peer

Application

O Ordering Node

A A

B B

Ordering-Service

Hyperledger Fabric

Smart Contract (Chaincode)

Endorsement Policy

5


Endorsement Policy ●

Describes the conditions by which a transaction can be endorsed –

A transaction can only be considered valid if it has been endorsed according to its policy

Each chaincode is associated with an Endorsement Policy

Examples of policies –

AND('Org1.member', 'Org2.member', 'Org3.member')

OR('Org1.member', 'Org2.member')

OR('Org1.member', AND('Org2.member', 'Org3.member'))

6


Step 2/7 – Execute Proposal Endorsers Execute Proposals

P3

E0 A A

Client Application

S D K

P4 A A

B B

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.

D D

Transactions can be signed & encrypted

E1 A A

O

B B

P

E2

O

O

Key:

Endorser

Ledger

Committing Peer

Application

O Ordering Node

A A

B B

Ordering-Service

Hyperledger Fabric

Smart Contract (Chaincode)

Endorsement Policy

7


Step 3/7 – Proposal Response Application receives responses

P3

E0 A A

Client Application

S D K

P4 A A

B B

D D

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)

E1 A A

O

B B

P

E2

O

O

Key:

Endorser

Ledger

Committing Peer

Application

O Ordering Node

A A

B B

Ordering-Service

Hyperledger Fabric

Smart Contract (Chaincode)

Endorsement Policy

8


Step 4/7 – Order Transaction Application submits responses for ordering

P3

E0 A A

Client Application

S D K

A A

B B

E1 A A

O

B B

P

E2

P4

O

D D

O

Application submits responses as a transaction to be ordered. Ordering happens across the fabric in parallel with transactions submitted by other applications

Key:

Endorser

Ledger

Committing Peer

Application

O Ordering Node

A A

B B

Ordering-Service

Hyperledger Fabric (other applications)

Smart Contract (Chaincode)

Endorsement Policy

9


Step 5/7 – Deliver Transaction Orderer delivers to all committing peers

P3

E0 A A

Client Application

S D K

A A

B B

O

B B

P

E2

D D

Different ordering algorithms available: • Solo (Single node, development) • Kafka (Crash fault tolerance)

E1 A A

P4

Ordering service collects transactions into proposed blocks for distribution to committing peers. Peers can deliver to other peers in a hierarchy (not shown)

O

O

Key:

Endorser

Ledger

Committing Peer

Application

O Ordering Node

A A

B B

Ordering-Service

Hyperledger Fabric

Smart Contract (Chaincode)

Endorsement Policy

10


Step 6/7 – Validate Transaction Committing peers validate transactions

P3

E0 A A

*

Client Application

S D K

*

B B

A A

O

B B

P

E2 *

A A

D D

*

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.

E1 *

P4

Every committing peer validates against the endorsement policy. Also check RW sets are valid for world state.

O

O

Key:

Endorser

Ledger

Committing Peer

Application

O Ordering Node

A A

B B

Ordering-Service

Hyperledger Fabric

Smart Contract (Chaincode)

Endorsement Policy

11


Step 7/7 – Notify Transaction Committing peers notify applications

!

E0 A A

Client Application

S D K

!

!

O

B B

P

E2

! A A

B B

E1 A A

!

P3

!

O

P4

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

D D

O

Key:

Endorser

Ledger

Committing Peer

Application

O Ordering Node

A A

B B

Ordering-Service

Hyperledger Fabric

Smart Contract (Chaincode)

Endorsement Policy

12


Ordering Service ●

Packages transactions into blocks to be delivered to peers

Communication with the service is via channels

Different configurations for the ordering service include –

Solo: Single node for development

Kafka: Crash fault tolerant consensus ●

3 nodes minimum, Odd number of nodes recommended

O

O

O

O

Ordering-Service

13


Channels ●

Separate channels isolate transactions on different ledgers –

Concurrent execution for performance and scalability

Peers can participate in multiple channels

Ledgers exist in the scope of a channel –

Can be shared across an entire network of peers

E0 E1

O

O

O

O

Ordering-Service

14


Single Channel Network

Client Application

S D K

E0

• All peers connect to the same system channel (blue). • All peers have the same chaincode and maintain the same ledger • Endorsement by peers E0, E1, E2 and E3

E2 A A

O

B B

A A

O

B B

P

O

E1 A A

O

Ordering-Service B B

Hyperledger Fabric

Key:

E3 A A

Endorser

Ledger

Committing Peer

Application

B B

Ordering Node

Smart Contract (Chaincode)

Endorsement Policy

15


Multi Channel Network • Peers E0 and E3 connect to the red channel for chaincodes Y and Z Client Application

S D K

E0

E2 Z Z

O

Y Y

Client Application

S D K

B B

P

O

E1 A A

A A

O

P

• Peers E1 and E2 connect to the blue channel for chaincodes A and B

O

Ordering-Service B B

Hyperledger Fabric

Key:

E3 Y Y

Endorser

Ledger

Committing Peer

Application

Z Z

Ordering Node

Smart Contract (Chaincode)

Endorsement Policy

16


Thank You

www.ibm.com/blockchain developer.ibm.com/blockchain www.hyperledger.org

© Copyright IBM Corporation 2017. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. Any statement of direction represents IBM's current intent, is subject to change or withdrawal, and represents only goals and objectives. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

17


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.