Hyperledger Fabric Transaction Flow

From nothing to a block, what is the big picture?

This is a short story about Hyperledger Fabric Transaction Flow. By knowing the transaction flow, it might help us debug and design our Hyperledger Fabric application.

What is the Transaction Flow?

Starts with an API request from the client — I want to write some data to the Blockchain

Ends with an API response to the client — the block is committed in the Blockchain for your data

Then, what do happen in the middle? Let’s open the black box.

The Black Box — There is No Magic

The following is a common transaction flow in Hyperledger Fabric.

The (One Possible) Transaction Flow

Assume that there is no error:

A Client, such as an iOS app, sends an API request to a Backend server with Hyperledger Fabric SDK — I want to write some data to the Blockchain The SDK sends a transaction proposal to the Peer(s) for the endorsement The Peer(s) endorses (signs) the transaction proposal and returns it to the SDK (, also, the Peer performs Chaincode / Smart Contract execution at this point, before endorsing the transaction proposal) The SDK sends a transaction to the Orderer (& Kafka) for the transaction ordering service The Orderer orders the transactions, forms block and broadcasts it to the Peers The Peer(s) notifies the SDK — the block is committed in the Blockchain for your data (, also, the Peer performs transactions validation and block commitment at this point, before notifying the SDK) The SDK (the Backend server) sends an API response to a client — the block is committed in the Blockchain for your data