Transaction Flow in Hyperledger Fabric

Transaction in hyperledger fabric reflects the business activity in the fabric network. Due ensure data immutability the transactions are kept inside the block and the chain structure is used for protection. In hyperledger fabric, each node maintains a ledger and the consensus mechanism is used to keep the ledger updated and identical at every node. The ledger at each node is composed of two parts, a blockchain, and a world-state database. The article focuses on discussing the transaction flow in Hyperledger Fabric.

Assumptions

There are a few assumptions to understand before beginning with the transaction flow in Hyperledger Fabric. 

• This transaction flow assumes that the channel is set up and running. 
• The application user has been registered and enrolled with the organization’s Certificate Authority (CA) Certification and received back necessary Protected cryptographic material, which will be used to authenticate to the network.
• The chaincode containing a set of key representation value pairs is installed on the peers and deployed to its current channel. 
• The chaincode contains logic defining a set of active transaction instructions and the agreed-upon price for a radish. 
• An endorsement policy has also been set up for this chaincode, stating that both peer A and peer B must endorse any transaction. 

Transaction Flow in Hyperledger Fabric

Below are the steps in the transaction flow in the hyperledger fabric:

1. Client A initiates a transaction:

• Client A sends requests to Client B for purchasing radishes. 
• The request targets peer A and peer B, who are representatives of Client A and Client B. 
• The endorsement policy states that both peers must endorse any transaction thus the request goes to peer A and peer B.
• The transaction proposal which is a request to invoke chaincode function with the intent to read/ update the ledger is constructed using SDK. 

• The SDK takes the user’s cryptographic credentials to produce a unique signature for the transaction proposal.
• The SDK submits the transaction proposal to the target peer and it will first forward the transaction proposal to other peers for execution.

2. Endorsing peers verify the signature and execute the transaction: 

The endorsing peers verify that:

• The transaction proposal is well-formed.
• It has not been submitted in the past for replay-attack protection.
• The signature is valid.
• The submitter (Client A) satisfies the channel’s Writers’ policy and is properly authorized to perform the proposed operation on the channel.

The endorsing peers take the transaction proposal inputs as arguments to invoke the chaincode function. The chaincode function gets executed and produces transaction results, response value, write set, and read set. Till this point, there is no update being done to the ledger. The set of these generated values along with the endorsing peer’s signature is sent to the target peer as the proposal response.

3. Proposal responses are inspected: 

• In step, the target peer verifies the proposal responses. 
• Even if checking is not performed hyperledger fabric architecture is designed in such a way that the endorsement policy will still be checked and enforced when each peer validated transactions prior to committing them.

4. Target peer assembles endorsements into a transaction:

• The target peer broadcasts transaction messages containing transaction proposals and responses to the ordering service. This includes Channel ID, read/ write sets, and a signature for each endorsing peer.
• The ordering service receives the transactions, orders them, and creates blocks of transactions per channel. It will not inspect the entire content of the transaction.

5. Transaction is validated and committed:

• The blocks of transactions are delivered to all the peers on the channel and they validate the transactions within the block.
• The peers validate transactions to ensure the endorsement policy is fulfilled and there have been no changes to the ledger state for read set variables since the read set was generated by the transaction execution.
• They tag transactions in the block as valid or invalid.

7. Ledger updated:

• Each peer appends the block to the channel’s chain.
• For each valid transaction, the write set is committed to the current database.
• Each peer emits an event to notify the client application that the transaction is immutably appended to the chain and also sends the notification whether the transaction is validated or invalidated.