Transaction flow in Hyperledger Fabric
Two clients, A and B, who are buying and selling radishes. They each have a peer on the network through which they send their transactions and interact with the ledger.
- This flow assumes that a channel is set up and running.
- The application user has registered and enrolled with the organization’s certificate authority (CA) and received back necessary cryptographic material, which is used to authenticate to the network.
- The chaincode (containing a set of key value pairs representing the initial state of the radish market) is installed on the peers and instantiated on the channel.
- The chaincode contains logic defining a set of transaction instructions and the agreed upon price for a radish.
- An endorsement policy has also been set for this chaincode, stating that both peerA and peerB must endorse any transaction.
Step 1: Client A initiates a transaction
Client A wants to send a Client Brequest to purchase radishes.
The request targets peerA and peerB, who are respectively representative of Client A and Client B. The endorsement policy states that both peers must endorse any transaction, therefore the request goes to both peerA and peerB.
First,the transaction proposal is constructed using SDK.
The proposal is a request to invoke a chaincode function so that data can be read and/or written to the ledger (i.e. write new key value pairs for the assets).
Step 2: Endorsing peers verify signature & execute the transaction
The endorsing peers verify that:
1. the transaction proposal is well formed
2. it has not been submitted already in the past (replay-attack protection), 3. whether the signature is valid (using MSP)
4. whether the submitter (Client A, in the example) is properly authorized to perform the proposed operation on that channel (namely, each endorsing peer ensures that the submitter satisfies the channel’s Writers policy).
The endorsing peers take the transaction proposal inputs as arguments to the invoked chaincode’s function.
The chaincode is then executed against the current state database to produce transaction results including a response value, read set, and write set.
No updates are made to the ledger at this point.
The set of these values, along with the endorsing peer’s signature is passed back as a “proposal response” to the SDK which parses the payload for the application to consume.
Note:The MSP is a peer component that allows peers to verify transaction requests arriving from clients and to sign transaction results (endorsements). The writing policy is defined at channel creation time and determines which users are entitled to submit a transaction to that channel.
Step 3: Proposal responses are inspected
The application verifies the endorsing peer signatures and compares the proposal responses to determine if the proposal responses are the same. Note: If the chaincode only queried the ledger, the application would inspect the query response and won’t be submitting the transaction to Ordering Service.
In our scenario,Client A proposed a new value in the transaction and therefore it will submit the transaction to Ordering Service to update the ledger.But before submitting,the application determines if the specified endorsement policy has been fulfilled(i.e. did peerA and peerB both endorse).
Even though if an application chooses not to inspect responses and just forwards an unendorsed transaction to ordering service, the endorsement policy will still be enforced by peers and upheld at the commit validation phase.
Step 4: Client assembles endorsements into a transaction
The application “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.
Step 5: Transaction is validated and committed
The ordering service broadcasts the blocks of transactions to all peers on the channel.
The transactions within the block are validated by the peers to ensure 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 tagged as being valid or invalid.
Step 6: Ledger updated
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, 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.