In this note, we will try to understand how do transactions flow in the hyperledger fabric. First, we will see the high-level overview without going into the nitty-gritty of individual steps. However, later in this note, we try to understand all the steps in detail.
A high-level overview of transaction flow
- The client application creates a new transaction request, signs it, submits it to the connected endorsing peers.
- The endorsing peers receive the transaction request, validate the signature, execute the smart contract or chaincode only if the signature is valid, put their signature on the execution result, i.e., read-write set, and send it to the client application. The endorsing peers must possess smart contracts and endorsement policy. These artifacts will be fed during the setup of the hyperledger fabric network.
- The client receives endorsements from peers. It checks the policy, and if the policy satisfies, it sends the transaction to the ordering service in the same format in which it accepts. An example of a policy for acceptance criteria, out of five endorsers minimum of three endorsers’ results must be the same.
- The ordering service collects all the transactions from the different clients for a certain duration which resides across the entire blockchain network. Runs the ordering algorithm and puts received transactions into an order. However, it does not validate the transactions. Later, the ordering service signs the newly generated block and sends it to all the committing peers across the network.
- The committing peers validate the signature on the received block. If valid, then these peers verify each transaction from the received block by referring to the respective transaction endorsement policy. These peers verify each of the transactions and mark them as valid or invalid. This helps the event service routing to trigger or inform the client about the transaction status rather than removing invalid transactions from the block. Later, these peers commit the new block to the ledger of hyperledger fabric.
- In the end, the client receives an event, and it takes appropriate action based on the status of the transaction.
The client application submits a transaction request to the endorsing peers. These peers execute the request, sign the output, and send it back to the client. This is part of the endorsement. Once the client collects sufficient (the definition of sufficient is mentioned in the endorsement policy) endorsements, it submits that transaction to the ordering services.
The ordering service continuously receives transitions from multiple clients. It collects all the transactions for a specific duration, constructs a block consisting of all the collected transactions, and orders these transactions by executing an ordering algorithm. The ordering service ensures that all of these transactions are fully ordered across all the ordering services nodes among the participating organizations.
Once the ordering is finished, then there is a notion of block validation. In the validation procedure, the committing peers validate the individual transaction with the reference of endorsement policy, mark these transactions valid or invalid, and append the block to the ledger.
In the hyperledger fabric, the consensus is achieved in three steps: Endorsing peers endorses the transactions, Ordering service order all the received transactions and construct a block, and Committing peers to validate the entire block by referring to the endorsement policy of individual transaction and commit the block into the ledger.
Transaction Flow
We will try to understand transaction flow with an example. There are five peer nodes in this example, and an application submits a transaction proposal for Smart Contract A. The endorsement policy says three peers must sign the transaction output, and the results must be the same. The client can consider that transaction as valid and forward it to the ordering service.
Step 1/7: Client Proposed Transaction
The key components are mentioned in the below diagram with different color square boxes such as Endorser, Committing Peer, ORdering Node, Smart Contract or Chaincode, Application and Endorsement Policy.
In this step, a client proposes a transaction by mentioning its identity, appropriate function name(s) with input parameters to be executed from a particular smart contract, and send it to all the endorsing peer nodes. The smart contracts will be available with all the endorsing peer nodes. In this example, E0, E1 & E2 are endorsing peers.
Step 2/7: Execute Proposed Transaction
These peer nodes E0, E1 & E2 will execute the transaction independently. However, non of these executions will update the ledger. The execution will capture the set of Read, and Written data, called RW set, and these RW sets will be signed by each endorser.
Step 3/7: Proposal Response
The endorses securely communicate back to the client with payload as the RW set, signature, and other metadata. The client receives these responses asynchronously, which means the response may arrive in any random order. This information will be checked much later in the consensus process.
Step 4/7: Order Transaction
The client application checks the responses received from the endorsing peers and tries to check the satisfaction criteria of the endorsement policy. For example, in this case, the policy says E0, E1, & E2 all must endorse, and their RW set must be the same. If it satisfies, then the client submits the transaction to the ordering service. These kinds of submissions can happen simultaneously from multiple client applications across the network.
Ordering happens across the fabric in parallel with transactions submitted by other applications. The ordering service orders these transactions and ensures that every peer node in the network sees the same order.
Step 5/7: Deliver Transaction
The ordering service delivers an ordered set of transactions called a block to all the committing peers across the network. It works as follows: The peer nodes will deliver to other peers in a hierarchy. The hierarch structure means that only a peer communicates to other organization peers within an organization. However, there might be multiple peers within an organization and are responsible for endorsing and committing functionalities. We can say that ordering service broadcasts the newly formed block to the entire network in a simple term.
There are different ordering algorithms available such as
- SOLO (Single node, development)
- Kafka (Crash Fault Tolerance)
- Practical Byzantine Fault Tolerance Algorithm
- Raft Algorithm
Hyperledger fabric architecture is architected so that each component can be upgraded or replaced with others based on the requirements without affecting other components. Currently, it supports SOLO, Kafka, and Raft algorithms.
Step 6/7: Validate Transaction
All of these committing peers have received a block of transactions from the ordering services, but all of these transactions may not be valid for the following reasons:
- By mistake, the client is malicious or, by mistake, submitted a transaction that hasn’t received sufficient endorsements from the endorsing peers.
- Two transactions simultaneously trying to update or refer to the same state variable within a block may create inconsistency.
Every committing peer validates against the endorsement policy. Also, check RW sets are still valid for the current world state. The validated transactions are applied to the world state and retained on the ledger. However, the invalid transactions are also retained on the ledger but do not update the world state.
Step 7/7: Notify Transaction
Once a newly created block is verified successfully by the committing peers and appended into the blockchain, the committing peers notify client applications. Every client receives the notification. However, clients can configure the notification setting according to the needs. These events notification can be configured for block-level or individual transaction level by the clients.
Even specific event notification mechanisms can be written in smart contracts, which gives more flexibility to the users to integrate hyperledger fabric applications into the external processes.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
541 total views, 1 views today
