Hyperledger Fabric
consensus
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.
10
High level Transaction lifecycle
Client application
SDK (HFC)*
1. Client
requests *HFC = Hyperledger Fabric
endorsement of Client
the proposal.
3. Endorsers send 4. Client 7. Peers emit
the proposal submits the notifications.
response. 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 block of transactions, and 6. Committing peers (all peers in the channel)
decide that the proposal validate each transaction in the block, and commit
sends it to all the peers in the
is valid. the block.
channel.
Endorse Order Validate
10
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.
10
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(‘[Link]', '[Link]’, ‘[Link]')
• Request one signature from either one of the two principals:
OR(‘[Link]', ‘[Link]')
• 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(‘[Link]', AND('[Link]', ‘[Link]'))
10
Endorse Step 1/7: Propose a
transaction
The application proposes a
transaction.
E0
A
B
Endorsement policy:
• “E0, E1, and E2 must
S sign”
C D
K
E1 The client application submits a
Client A
B transaction proposal for smart
contract A.
P It must target the required
E2 peers {E0, E1, and E2}
A
B
KEY
Endorser Ledger
Hyperledger Fabric Network Smart contract Endorsemen
(chaincode t policy
)
Application
10
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
B
these executions update the
ledger.
S Transactions can be signed
C D
K
E1
A
and encrypted.
Client B
P
E2
A
B
KEY
Endorser Ledger
Hyperledger Fabric Network Smart contract Endorsemen
(chaincode t policy
)
Application
10
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.
10
Endorse Step 3/7: Proposal
response
E0 The application receives
A
B responses.
RW sets are asynchronously returned
S to the application.
C D
K
E1
A
Client B
P
E2
A
B
KEY
Endorser Ledger
Hyperledger Fabric Network Smart contract Endorsemen
(chaincode t policy
)
Application
10
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
10
Order Who is involved
When submitting a transaction:
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.
10
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.
11
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:
O O • Three nodes minimum.
C1 • Odd number of nodes are preferred.
Ordering service
11
Order Step 4/7: Order
transaction
Responses are submitted for
ordering.
E0 The client submits endorsed
A responses as a transaction to be
B
ordered.
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 Endorsemen
(chaincode t policy
)
Orderin
Application
g node
(Other clients) 26
Order Step 5/7: Deliver the
transaction
The orderer delivers to the committing
E0 P3 P4 peers.
A
B
A
D
The ordering service collects
transactions for a channel into
S
proposed blocks for distribution to
C
Client
D
K
E1
A
* O O
peers. Blocks are delivered on a
channel basis.
Peers can deliver to other peers in
B
a hierarchy (not shown).
P
E2 O O
A
B
Ordering-Service KEY
Endorser Ledger
Hyperledger Fabric Network Smart contract Endorsemen
(chaincode t policy
)
Orderin
Application
g node
11
Transaction lifecycle: Order
Client application
SDK (HFC)*
*HFC = Hyperledger Fabric
1. Client Client
requests an
endorsement of
the proposal.
3. Endorsers send 4. Client
the proposal submits the
response. 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 block of transactions, and
decide that the proposal
sends it to all the peers in the
is valid.
channel.
Endorse Order
11
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.
11
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
11
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 Committin
A Endorser
B g peer
* Ordering service Smart contract Endorsemen
(chaincode t policy
)
Hyperledger Fabric Network Orderin
Application
g node
Ledger
11
Validate Step 7/7: Notify the
transaction
The committing peers notify the
!
E0 ! P3 ! P4 applications.
Applications can register to be
A A
B D notified when transactions succeed
or fail, and when blocks are added
S to the ledger.
C D ! ! E1
A O O
Applications are notified by each peer
to which they are connected.
Client K B
P
! E2 O O
KEY Committin
A Endorser
B g peer
Ordering-Service Smart contract Endorsemen
(chaincode t policy
)
Hyperledger Fabric Network Orderin
Application
g 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 4. Client 7. Peers emit
the proposal submits the notifications.
response. 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 6. The committing peers (all the peers in the
2. Endorsing peers the block of transactions, and channel) validate each transaction in the block, and
decide that the proposal commit the block.
sends it to all the peers in the
is valid.
channel.
Endorse Order Validate
11