Transaction Flow in Hyperledger Fabric

The Transaction flow in fabric consists of the blow mentioned actors:

  1. Client
  2. SDK
  3. Ordering Service (OS)
  4. Committing Peer (CP)
  5. Endorsing Peer (EP)

The transaction flow in fabric covers certain steps those steps are mentioned below:

Step1: Transaction Proposal

Step2: Endorsing Peers Verify Signature & Execute Transaction

  1. Transaction proposal is well formed.
  2. Replay-attack protection (it has not been submitted already in the past).
  3. The signature is valid (using the MSP).
  4. Check policy of submitter over the channel (writer policy) like whether the submitter Client is allowed to perform the proposed operation over the channel.

The endorser is constructing a list of data (key & values) or we can say read/write set that are read from the ledger (by the Chaincode).

Now at this step no updates are made to the ledger.

Step3: Proposal Response

Step4: Proposal Responses are Inspected

  1. If the chaincode is only querying the ledger, the application would only inspect the query response and would typically not submit the transaction to the ordering service.
  2. If the client application intends to submit the transaction to the ordering service to update the ledger, the application determines if the specified endorsement policy has been fulfilled before submitting.

Step5: Broadcast & Order Transaction

  1. The transaction will contain the read/write sets, the endorsing peers signatures and the Channel ID.
  2. The ordering service does not need to inspect the entire content of a transaction in order to perform its operation, it simply receives transactions from all channels in the network, orders them chronologically by channel, and creates blocks of transactions per channel.
  3. This step can be described as a request for the proposed and endorsed transactions to get into block and get broadcasted.

Step6:Deliver & Validate Transactions

  1. The transactions within the block are then validated by committing peers to ensure if endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution.
  2. Transactions in the block are then tagged as being valid or invalid.

Step7:Ledger Update

  1. An event is emitted by each peer to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as notification of whether the transaction was validated or invalidated.