[Part-6]Blockchain Simplified Notes NPTEL
By: Divya Goyal
Tags: Blockchain, Cryptocurrency, Hyperledger, Tutorial, Bitcoin

Transaction Flow in Hyperledger Fabric.

In Hyperledger Fabric, consensus is made up of three distinct steps:

Transaction endorsement

Ordering

Validation and commitment

Step I: Propose Transation

Within a Hyperledger Fabric network, transactions start out with client applications sending transaction proposals, or, in other words, proposing a transaction to endorsing peers.

Client applications are commonly referred to as applications or clients, and allow people to communicate with the blockchain network. Application developers can leverage the Hyperledger Fabric network through the application SDK.

Step II: Execute Proposed Transaction

Each endorsing peer simulates the proposed transaction, without updating the ledger. The endorsing peers will capture the set of Read and Written data, called RW Sets. These RW sets capture what was read from the current world state while simulating the transaction, as well as what would have been written to the world state had the transaction been executed. These RW sets are then signed by the endorsing peer, and returned to the client application to be used in future steps of the transaction flow.

Endorsing peers must hold smart contracts in order to simulate the transaction proposals.

Steps III: Proposal Response

The application then submits the endorsed transaction and the RW sets to the ordering service. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.

Step IV: Order & Deliver Transaction

The ordering service takes the endorsed transactions and RW sets, orders this information into a block, and delivers the block to all committing peers.

The ordering service, which is made up of a cluster of orderers, does not process transactions, smart contracts, or maintains the shared ledger. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger.

The Fabric v1.0 architecture has been designed such that the specific implementation of ‘ordering’ (Solo, Kafka, BFT) becomes a pluggable component. The default ordering service for Hyperledger Fabric is Kafka. Therefore, the ordering service is a modular component of Hyperledger Fabric.

Step V: Validate Transaction

The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state. Specifically, that the Read data that existed when the endorsers simulated the transaction is identical to the current world state. When the committing peer validates the transaction, the transaction is written to the ledger, and the world state is updated with the Write data from the RW Set.

If the transaction fails, that is, if the committing peer finds that the RW set does not match the current world state, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the world state will not be updated.

Committing peers are responsible for adding blocks of transactions to the shared ledger and updating the world state. They may hold smart contracts, but it is not a requirement.

Step VI: Notify Transaction

Lastly, the committing peers asynchronously notify the client application of the success or failure of the transaction. Applications will be notified by each committing peer.

Important Points To Remember: