How Transaction Flow Works in Hyper-Ledger Fabric

One very important aspect of the business which is as unexplored and interesting as the Internet itself is creating various forms of business models. These topics always keep me off the edge as I have grown a particular interest towards it over time.

BlogSaays already features a series of articles surrounding IBM Hyperledger and Blockchain services which allow business teams to develop business models. Be it deploying .bna files to creating Blockchain queries for your business, you’ll find it all on this blog.

My previous posts connected to IBM services include the following 4 articles.

• How to deploy a Business Network Archive (.bna) file to your IBM Blockchain Platform
• How to build a small blockchain application using the IBM BLUEMIX
• How to setup an MSP channel using the IBM Hyperledger fabric
• How to create effective Blockchain queries using IBM Hyperledger

So the newest addition to this growing list of posts revolves around transactional mechanics that take place during a standard asset exchange. Through this post, I will give you an easy to understand yet comprehensive guide about every simple and key aspects that outline the same.

What is Transaction Flow?

Starting with the crux of this guide, “What is Transaction flow?” In simple words, a transaction flow basically outlines the mechanics that take place during a standard asset exchange between usually two or more clients.

Let us work with a very basic scenario involving two clients, A and B, who are buying and selling mobiles. They send their transactions and interact with the ledger a peer on the network.

Basic assumptions

Every business model in the world whether online or offline, technical or mechanical, initiates with a set of assumptions. The transactional flow model for standard asset exchange works with the same principle as well. Before the key assumptions, there are 4 basic or minor assumptions that are kept in mind.

1. The first assumption of the flow is that a channel is set up and running.
2. 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.
3. The chaincode is installed on the peers and instantiated on the channel.

A chaincode simply contains a set of key value pairs representing the initial state of the market (Mobile market in this case). These contain logic defining a set of transaction instructions and the agreed upon price for a mobile (ie; Product/Service).

4. An endorsement policy has also been set for this chaincode, stating that both peerA and peerB must endorse any transaction.

Key assumptions

Once you are through with the basic assumptions, we get on with the main or key assumptions revolving around transaction flow model.

1. Client A initiates a transaction

Initiation of transaction

The initiation of the trade begins with Client A sending a request to purchase mobiles. peerA and peerB, who are respectively representative of Client A and Client B are the request targets. The request goes to peerA and peerB since the endorsement policy states that both peers must endorse any transaction.

Transaction proposal is constructed

Simply so that data can be read and/or written to the ledger, the proposal is a request to invoke a chaincode function. In technical terms it is an application leveraging a supported SDK (Node, Java, Python) utilizes one of the available API’s which generates a transaction proposal. The transaction proposal is then packaged into the properly architected format by this SDK which then takes the user’s cryptographic credentials to produce a unique signature for this transaction proposal.

2. Endorsing peers verify signature & execute the transaction

The final execution of the endorsement process requires the endorsing peers to verify that

• The transaction proposal is well formed.
• It has not been submitted already in the past, to satisfy the replay-attack protection.
• The signature is valid (using MSP).
• The submitter (Client A) is properly authorized to perform the proposed operation on that channel. This implies that each endorsing peer ensures that the submitter satisfies the channel’s Writers policy.

The transaction proposal inputs are taken as arguments to the invoked chaincode’s function by the endorsing peers. The chaincode is then executed to produce transaction results against the current state database. These typically include a response value, read set and write set.

It is further made sure that no updates are made to the ledger at this point. The SDK then parses the payload for the application to consume after the set of these values, along with the endorsing peer’s signature is passed back to them as a “proposal response”.

PLEASE NOTE:

• All the transaction requests arriving from clients are verified by the MSP peer component so they can sign the representative endorsements.
• The Writing policy is defined during the channel creation time. It simply outlines which user is entitled to submit a transaction to that channel.

3. Proposal responses are inspected

Next up is the inspection of proposal responses. The proposal responses are compared to determine if the proposal responses are the same after the application verifies the endorsing peer signatures. The application would inspect the query response if the chaincode only queried the ledger and would not submit the transaction to Ordering Service in a typical situation.

The application determines if the specified endorsement policy has been fulfilled before submitting, if the client application intends to submit the transaction to Ordering Service to update the ledger. This simply means it cross checks with the server whether peerA and peerB both endorsed.

4. Client assembles endorsements into a transaction

The transaction proposal and response is broadcasted by the application within a “transaction message” to the Ordering Service. This transaction will contain the endorsing peer’s signatures, the read/write sets and the Channel ID.

https://youtu.be/2_RgCfjunEU

The primary function of the Ordering Service is to receive transactions from all channels in the network. Furthermore the service orders them chronologically by channel and rather than inspecting the entire content of a transaction in order to perform its operation, creates blocks of transactions per channel.

5. Transaction is validated and committed

Every transaction in the block is tagged as being valid or invalid. The transactions within the block are validated to ensure endorsement policy is fulfilled which are then “delivered” to all peers on the channel. Since the read set was generated by the transaction execution, this process also ensures that there have been no changes or altering made to the ledger state for read set variables.

6. Ledger updated

As mentioned earlier, for each valid transaction the write sets are committed and executed to current state database to make sure that each peer appends the block to the channel’s chain.

Next up and finally, the client application is notified that the transaction has been immutably appended to the chain by an event that is emitted to notify them. The client application is further notified of whether the transaction was validated or invalidated.