The Transaction flow in fabric consists of the blow mentioned actors:
- Ordering Service (OS)
- Committing Peer (CP)
- Endorsing Peer (EP)
The transaction flow in fabric covers certain steps those steps are mentioned below:
Step1: Transaction Proposal
In this step the Client proposes the transaction to the Endorsing Peers for endorsement. This proposal is done with the help of the SDK.
Step2: Endorsing Peers Verify Signature & Execute Transaction
The EP verifies the below:
- Transaction proposal is well formed.
- Replay-attack protection (it has not been submitted already in the past).
- The signature is valid (using the MSP).
- 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
The set of these values (read/write set), along with the endorsing peer’s signature is passed back as a “proposal response” to the Client by the Endorsing Peer. The SDK here parses the payload to the Client so that it can get consumed.
Step4: Proposal Responses are Inspected
- The Client application verifies the endorsing peer signatures and compares the proposal responses to determine if the proposal responses are the same.
- 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.
- 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
- The Client application with the help of SDK “broadcasts” the transaction proposal and response within a “transaction message” to the ordering service.
- The transaction will contain the read/write sets, the endorsing peers signatures and the Channel ID.
- 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.
- 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
- Ordering service distribute/ delivered the block to the committing peers using peer-to-peer network and gossip protocol .
- 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.
- Transactions in the block are then tagged as being valid or invalid.
- Each peer appends the block to the channel’s chain, and for each valid transaction the write sets are committed to current state database.
- 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.