Blockchain in-depth: Part 2

Unit 05

IBM Skills Academy

V1.0, July 2018

Learning objectives

Consensus overview

Hyperledger Fabric
consensus

Summary
What you should be able to do

Upon completion of this unit, you should be able to:

• Explain the need for consensus.

• Describe the role of the ordering service.

• List the steps of consensus.

• Explain how transaction endorsement and validation works in Hyperledger Fabric.

3
Learning objectives

Consensus overview

Hyperledger Fabric
consensus

Summary
Consensus: The process of maintaining a consistent
ledger
Before After

ABC DEF ABC ABC

CONSENSUS

ABC JKL ABC JKL

Peer

• Keep all peers up-to-date. Ledger

• Fix any peers in error.
• Ignore all malicious nodes.
5
Some examples of consensus algorithms

Proof of work Proof of stake Solo /

No-ops

Kafka / Proof of Practical

Zookeeper elapsed time Byzantine Fault
Tolerance-based

6
Consensus algorithms have different strengths and
weaknesses
Requires validators to solve difficult cryptographic puzzles.
Pros: Works in untrusted networks.
Cons: Uses much energy, and slow to confirm transactions.
Proof of work Example usage: Bitcoin and Ethereum

Requires validators to hold currency in escrow.

Pros: Works in untrusted networks.
Cons: Requires intrinsic (crypto)currency, and the ”Nothing at stake” problem.
Proof of stake Example usage: Nxt

Wait time in a trusted execution environment randomizes block generation.

Pros: Efficient.
Proof of
Cons: Requires processor extensions.
Elapsed Time Example usage: Hyperledger Sawtooth

7
Consensus algorithms have different strengths and
weaknesses
Validators apply received transactions without consensus.
Pros: Quick, and suited to development.
Cons: No consensus, which can lead to divergent chains.
Solo /
No-ops

Practical Byzantine Fault Tolerance (PBFT) implementations

Pros: Reasonably efficient and tolerant against malicious peers.
Cons: Validators are known and connected.
PBFT-based

Ordering service distributes blocks to peers.

Pros: Efficient and fault-tolerant.
Cons: Does not guard against malicious activity.
Kafka /
Zookeeper

8
Consensus tradeoffs: Latency versus scalability

9
Consensus tradeoffs: Permissioned versus
permissionless

10
Consensus tradeoffs: Support for smart contracts
Smart contracts and consensus algorithms co-operate to build trust among the blockchain network. Supporting smart contracts
has important implications on consensus.

Trust model:
• May be determined by the consensus protocol.
• May be driven by the requirements of the smart contracts.
• Trust in development may be required.

Confidentiality: Consensus should allow the dissemination of contract code and the state to a subset of peers in the network.

Performance:
• Limit execution to sequential paradigms.
• Alternatively, support parallelism.

Determinism:
• Limit the programming model to ensure that peers do not diverge.
• Alternatively, handle determinism at the consensus level.

11
Learning objectives

Consensus overview

Hyperledger Fabric
consensus

Summary
Hyperledger consensus design principles
All Hyperledger projects follow a modular, token-neutral approach, with a focus on interoperability and security:
• Consensus may be implemented in different ways to target different network requirements.
• A generalized reference architecture for consensus is used. It can be used by any Hyperledger project.

The assumption is that business blockchain networks operate in an environment of partial trust, that is, there are no anonymous
miners.

Consensus must depend on smart contracts for transaction validation.

Hyperledger frameworks reach consensus by logically separating two activities:

• Ordering of transactions
• Validating transactions

By logically separating these activities:

• Any Hyperledger framework can work with any Hyperledger consensus module.
• Separation of concerns enables better performance and scalability of the network.

13
Hyperledger Fabric consensus implementation

Consensus is achieved by using the following transaction flow:

Endorse Order Validate

• Simulate transactions. • Order transactions. • Validate endorsements.
• Collect results. • Create blocks. • Eliminate invalid
• Collect endorsements. • Broadcast blocks. transactions.
• Update the ledger.

14
Transaction lifecycle
Client application

SDK (HFC)*
1. Client requests
endorsement of *HFC = Hyperledger Fabric Client
the proposal.
3. Endorsers send the 4. Client submits 7. Peers emit notifications.
proposal response. the transaction.

Peer 1 Peer 2 Peer 3 O O Peer 1 Peer 2

…
Peer n
Endorser & Endorser & Endorser & Endorser & Endorser & Committer
committer committer committer committer committer
Endorsing peers for O O Peer network
smart contract
5. Ordering service creates the
2. Endorsing peers decide block of transactions, and sends 6. Committing peers (all peers in the channel) validate
that the proposal is valid. it to all the peers in the channel. each transaction in the block, and commit the block.

Endorse Order Validate

15
Endorse Who is involved

Before submitting a transaction…

S
C D
K
Clients propose the transaction to the peers and collect their
endorsement signatures on a specific policy.

Endorsing peers receive a transaction proposal for endorsement,

execute the proposal, and respond granting or denying endorsement.
Endorsing peers must hold smart contracts.

16
 Endorse Endorsement policies

An endorsement policy describes the conditions by which a transaction can be trusted. A transaction can be
considered valid only if it is endorsed according to its policy. Endorsement policies are defined at chaincode
instantiation on a specific channel.

Examples of policies:
• Request one signature from all three principals:
AND(‘Manufacturer.member', 'Regulator.member’, ‘Leasing.member')
• Request one signature from either one of the two principals:
OR(‘Manufacturer.member', ‘Leasing.member')
• Request either one signature from a member of the Manufacturer MSP, or one signature from a member of the
Regulator MSP and one signature from a member of the Authority MSP:
OR(‘Manufacturer.member', AND('Regulator.member', ‘Leasing.member'))

17
Endorse Step 1/7: Propose a transaction
The application proposes a transaction.

E0 Endorsement policy:
A • “E0, E1, and E2 must sign”
B

S The client application submits a

C D
K
E1
A
transaction proposal for smart contract
A. It must target the required peers {E0,
Client B
E1, and E2}.

P
E2
A
B
KEY
Endorser Ledger

Hyperledger Fabric Network Smart contract Endorsement

(chaincode) policy

Application

18
Endorse Step 2/7: Execute the proposal
The endorsers execute the proposals.

E0 E0, E1, and E2 each execute the

A proposed transaction. None of these
B
executions update the ledger.

S Transactions can be signed and

C D
K
E1
A
encrypted.
Client B

P
E2
A
B
KEY
Endorser Ledger

Hyperledger Fabric Network Smart contract Endorsement

(chaincode) policy

Application

19
 Endorse Inside the endorsing peer
Endorsing peer

Chaincode ESCC
Sign

Propose - Execute - Respond

Each execution captures the set of read and written data, which is called the RW set, which now flows
in Hyperledger Fabric.

Endorsement System Chaincode (ESCC) signs the proposal response on the endorsing peer.

The RW sets are signed by each endorser, and also include each record’s version number.

20
Endorse Step 3/7: Proposal response

E0 The application receives responses.

A
B

RW sets are asynchronously returned to

S
the application.

C D
K
E1
A
B
Client

P
E2
A
B
KEY
Endorser Ledger

Hyperledger Fabric Network Smart contract Endorsement

(chaincode) policy

Application

21
Transaction lifecycle: Endorse
Client application

SDK (HFC)* *HFC = Hyperledger Fabric Client

1. Client requests
an endorsement
of the proposal.
3. Endorsers send
the proposal
response.

Peer 1 Peer 2 Peer 3

Endorser & Endorser & Endorser &
committer committer committer
Endorsing peers for
smart contract

2. Endorsing peers decide

that the proposal is valid.

Endorse
22
Order Who is involved

When submitting a transaction:

S
C D
K
Clients submit the transactions to orderers to broadcast them to the
peers.

Orderers or ordering-service nodes receive transactions from

clients, form blocks, and deliver them to the peers.

23
 Order The ordering service

The ordering service packages transactions into blocks to be delivered to peers while ensuring the following:
• Agreement: A block is delivered with the same sequence number to all peers.
• Hash chain integrity: For all peers, the current block contains the hash of the previous one.
• Sequential Delivery: Each block is delivered sequentially to every peer. No block is skipped or missed.
• No transaction creation: Blocks are composed only of transactions that are broadcast by clients.
• Eventual validity: If a client broadcasts a transaction, it eventually is delivered in a block.

The ordering service is run by specialized nodes that:

• Do not hold smart contracts.
• Do not hold endorsement policies.
• Do not need to store the world state to work.
• Do not update the ledger by themselves.
• Can see all transactions by default, but do not need to inspect the details of a transaction.

The ordering service may perform access control to check whether clients are allowed to broadcast a
transaction on the channel.

24
 Order The ordering service: Consensus protocols

Different configuration options for the ordering service

include:
C0 O O • SOLO: Single node for development
• Kafka: Crash fault tolerant consensus:
• Three nodes minimum.
O O
C1 • Odd number of nodes are preferred.
Ordering service

25
 Order Step 4/7: Order transaction

Responses are submitted for ordering.

E0 The client submits endorsed responses

A as a transaction to be ordered.
B

Ordering happens across the

S Hyperledger Fabric in parallel with
C D
K
E1
A O O
transactions that are submitted by other
applications.
Client B

P
E2 O O
A
B
Ordering service KEY
Endorser Ledger

Hyperledger Fabric Network Smart contract Endorsement

(chaincode) policy

Ordering
Application
node

(Other clients) 26
 Order Step 5/7: Deliver the transaction

The orderer delivers to the committing peers.

E0 P3 P4
A
B
A
D
The ordering service collects transactions
for a channel into proposed blocks for
distribution to peers. Blocks are delivered
S
C
Client
D
K
E1
A
B
* O O
on a channel basis.

Peers can deliver to other peers in a

hierarchy (not shown).

P
E2 O O
A
B
Ordering-Service KEY
Endorser Ledger

Hyperledger Fabric Network Smart contract Endorsement

(chaincode) policy

Ordering
Application
node

27
Transaction lifecycle: Order
Client application

SDK (HFC)*
*HFC = Hyperledger Fabric Client
1. Client requests
an endorsement
of the proposal.
3. Endorsers send the 4. Client submits
proposal response. the transaction.

Peer 1 Peer 2 Peer 3 O O Peer 1 Peer 2

…
Peer n
Endorser & Endorser & Endorser & Endorser & Endorser & Committer
committer committer committer committer committer
Endorsing peers for O O Peer network
smart contract
5. Ordering service creates the
2. Endorsing peers decide block of transactions, and sends
that the proposal is valid. it to all the peers in the channel.

Endorse Order
28
Validate Who is involved

When receiving a new block…

Committing peers (including endorsing peers) run validation and

update their copy of the blockchain and world state.
Committing peers may hold smart contracts, but they do not execute
them at this stage.

...after transaction validation…

S
C D
K
Clients who registered are notified about any new blocks and
transactions that are delivered on the channel.

29
 Validate Inside the committing peer

On every committing peer, Validation System Chaincode (VSCC):

• Validates the endorsements against the endorsement policy.
• Checks that the RW sets are still valid for current world state.

Validated transactions are applied to the world state and retained on the ledger.
Invalid transactions are also retained on the ledger, but do not update world state.

Committing peer

VSCC Ledger
Policy
P Validate - Commit

30
 Validate Step 6/7: Validate the transaction

Committing peers validate transactions.

E0 P3 P4
A A
B D
* * *
S

C D
K E1
A O O
Client B
*

P
E2 O O
KEY Committing
A Endorser
B peer
* Ordering service Smart contract Endorsement
(chaincode) policy
Hyperledger Fabric Network Ordering
Application
node

Ledger

31
Validate
Validate Step 7/7: Notify the transaction

The committing peers notify the applications.

!
E0 ! P3 ! P4 Applications can register to be notified
A A
B D when transactions succeed or fail, and
when blocks are added to the ledger.
S

C D
K
! ! E1
A O O
Applications are notified by each peer to
which they are connected.
Client B

P
! E2 O O
KEY Committing
A Endorser
B peer
Ordering-Service Smart contract Endorsement
(chaincode) policy
Hyperledger Fabric Network Ordering
Application
node

Ledger

32
Transaction lifecycle: Validate
Client application

SDK (HFC)* *HFC = Hyperledger Fabric Client

1. Client requests
an endorsement
of the proposal.
3. Endorsers send the 4. Client submits 7. Peers emit notifications.
proposal response. the transaction.

Peer 1 Peer 2 Peer 3 O O Peer 1 Peer 2

…
Peer n
Endorser & Endorser & Endorser & Endorser & Endorser & Committer
committer committer committer committer committer
Endorsing peers for O O Peer network
smart contract
5. The ordering service creates the 6. The committing peers (all the peers in the channel)
2. Endorsing peers decide block of transactions, and sends it validate each transaction in the block, and commit the
that the proposal is valid. to all the peers in the channel. block.

Endorse Order Validate

33
Hyperledger Fabric consensus: Putting it all together

https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf
34
Learning objectives

Consensus Overview

Hyperledger Fabric
consensus

Summary
Unit summary
This unit described consensus algorithms and the Hyperledger Fabric approach to consensus:

• The objective of consensus algorithms is to maintain a consistent ledger.

• Different consensus algorithms have pros and cons; there is no “one-size-fits-all”.

• The Hyperledger approach to consensus is modular and focuses on enterprise blockchain.

• The key steps in Hyperledger Fabric Consensus are endorse, order, and validate.

• The key elements that are involved in a transaction are clients, peers, orderers, smart contract, and
endorsement policies.

• Transactions are executed by peers only after the transaction proposals are submitted for
endorsement.

• Specialized nodes take care of ordering transactions and creating blocks.

• Validation is based on a read/write set and endorsement signatures.

36
Exercise objectives

During this exercise, you will apply Hyperledger Fabric network concepts to:

• Start a sample.
• Review the existing organizations and channels.
• Add an organization and peer.
• Add a peer to an existing channel.
• Install and instantiate the Hyperledger Fabric chaincode.
• Review the changes by querying the existing data on the ledger before adding the new peer.
• [Optional] Deploy the whole network on IBM Cloud by using Kubernetes.

37
References
For more information about the topics that are covered in this unit, see the following resources:
• Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains
• Hyperledger Architecture Paper, Volume 1
• http://hyperledger-fabric.readthedocs.io/en/release-1.1

• https://developer.ibm.com/courses/all/ibm-blockchain-foundation-developer/

• https://developer.ibm.com/academic/resources/blockchain-educator-guide/

• https://allquantor.at/blockchainbib/pdf/vukolic2015quest.pdf

• https://arxiv.org/abs/1801.10228v1.pdf

• https://www.youtube.com/watch?v=8kRc2895uMY

• https://www.youtube.com/watch?v=DqtzxJP6Y9k

• https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf

38
Thank you.
IBM Skills Academy

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.
 © Copyright IBM Corporation 2018. 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.