Hyperledger Fabric — Transaction Flow
Welcome Back! Hope you have gone through my previous posts about Hyperledger Fabric — Part 1 — Components and Architecture. If not I would recommend you to first go through these components for detail understanding about there functionality and role in Fabric Network.
Now, this article focuses more on fabric transaction flow. So let’s begin.
To start with, first, we’ll consider a full-fledged fabric network, production like. Let’s go through the network setup.
Network Setup
Consider a Hyperledger Fabric Multi organization network as shown above. This network is formed by three organizations. Org1 which has dedicated 5 peers, Org 2 with 4 peers and 1 orderer and Org 3 with 3 peers and 1 Orderer. We have channels formed by these organizations. Any transaction carried out by any of the organization is transparent to all 3 organizations. A channel has an instance of Smart Contract and channel policy which are defined in configtx.yaml, which we pass as an input during the creation of the channel.
By default, each peer has a role of Committer. In addition to this, a peer can possess multiple roles like Endorser, Leader or Anchor (To learn more about these roles you can refer to my previous posts here). All Peers are represented by a colored dot representing the set of roles a peer possess. A single peer can be set with all roles. Each peer possesses a ledger which consists of a blockchain and a World State. All peers who possess endorsing role has Smart contract installed in order to validate the transactions.
Each organization has its own CA authority. Since Fabric is a modular structure, we can have any CA authority like Comodo, DigiSign, etc. here in our network Organization 1 and 2 associated with Fabric CA and Organization 3 associated with Comodo CA.
Step 1: Client Initiates the transaction
Within a Hyperledger Fabric network, transactions carried out by a client application, sending transaction proposal, or, in other words, proposing a transaction to endorsing peers. Before sending the transaction to endorsing peer, client SDK needs to know the list of all Endorsing peers in the network. Here in our already defined network, we have 5 endorsing peers set as a blue dot. These endorsing peers are defined in configtx.yaml file and is set as an endorsement policy while creating it. Each endorsing peer has a chaincode installed and has a copy of ledger which is sync between all peers. Along with the list of endorsing peers, requesting peer learns about the rule for a number of endorsers required to achieve consensuses. Unless this rule is satisfied, the requesting peer does not send this message further to other peers. For Example, consider our network, where policy specifies that “at least one endorsing peer from Org 1 and Org 3 or all endorsing peers from Org2 and Org3”. Until this policy is not satisfied, requesting peer will not be able to send a message to other endorsing peer.
Step 2 — Endorsing peers verify signature & execute the transaction
Using this SDK a transaction proposal is constructed, it uses an SDK API to generate this transaction proposal. This proposal is nothing but a request to invoke a chaincode, in order to read or write in the ledger. The SDK is nothing but a process to bundle a request into a proper package which is accepted by the network which takes the clients cryptographic credentials to generate a signature for this transaction proposal. To invoke a transaction, the client sends a “PROPOSE” message to a set of endorsing peers of its choice. Some endorsers could be offline, others may object and choose not to endorse the transaction.
Once the transaction request is formed, it is now sent to all endorsing peers on the list to get a consensus that the transaction is valid. Upon receiving the message it’s a responsibility of each endorsing peer to follow predefined steps to validate the message as below.
Each endorsing peers will validate:
- If the proposal is well-formed
- Not been submitted in past
- Signature is valid
- The submitter(Client) is authorized to carry out the execution on the channel.
Each endorsing peer takes the transaction proposal inputs as arguments to invoke the chaincode function. Chaincode is then executed against the current state of the database to produce transaction results including response value, along with read and write sets, called RW Sets. These RW sets capture what was read from the current world state while simulating the transaction, as well as what would have been written to the world state had the transaction been executed. No updates are made in a 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. Now the requesting peer receives an Endorsement transaction response from all endorsing peer. It’s a list of endorsement responses. After receiving the list of endorsements, this list is validated based on the rule set in the endorsement policy and checks if it is satisfied or not.
Since an endorsement policy is specified for a specific chaincode, different channels can have different endorsement policies.
Step 3 — Proposal response are inspected
The application verifies the endorsing peer signature and compares the proposal response to determine if the proposal responses are the same. If the chaincode only queried the ledger, the application would inspect the query response and would not submit the transaction to the Ordering service. If the client application intends to submit the transaction of the Ordering service, the application identifies if the specified endorsement policy has been fulfilled before submitting.
Step 4 — Client assembles endorsements into a transaction
Once all Endorsement responses are validated and found suitable to deliver it to the Ordering service, these messages then start there journey to form a block. In our current network, we have two ordering services from Org 2 and Org 3. Usually, in production, we should set up multiple ordering services to make sure the network is fault tolerant. However, we can use Kafka which enables fault tolerance and also provides high-throughput, low-latency for real-time data feeds.
The SDK broadcasts the transaction proposals and response within transaction message to the Ordering service. This message contains a transaction which contains read/write sets, endorsing peer signature and channel ID. The Ordering service does not inspect every information in this message, it simply receives all transactions from all channels in the network, orders them chronologically and creates a block of transactions per channel. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.
The Ordering service, which is made up of a cluster of orderers, does not process transactions, smart contracts, or maintain the shared ledger. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger. The Fabric v1.0 architecture has been designed such that the specific implementation of “ordering” (Solo, Kafka, BFT) becomes a pluggable component. The default ordering service for Hyperledger Fabric is Kafka. Therefore, the ordering service is a modular component of Hyperledger Fabric.
Step 5: Disseminate the block to leader peers
Once the block is formed by arraigning the transactions in chronological order, the block is now ready to send to all leader peers in the network. Ideally, the network should have a leader peer, but it’s not mandatory. If there are no leader peers the orderer will need to make sure that the block is propagated to all committing peers, which could cause unnecessary tracking and network load. To avoid this, each organization nominates there own leader peer. There can be multiple leader peer per organization, in order to be fault tolerant. If an organization has only one leader peer and fails to respond, a voting mechanism takes place to nominate the leader peer from available active peers. The list of leader peers is known to all orderers via the channel.
The orderer sends this message block to all active leader peers.
Step 6: Transaction is validated and committed
Leader peers come only into the picture at this stage, to disseminate the block to other committing peers within the organization. The block is delivered to all peers on the channel using gossip protocol. The transactions within the block are validated 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 7 — Ledger update
Peers checks if the endorsement is valid according to the policy of the chaincode and also verifies the dependencies (RW sets) are not been violated. The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state. Specifically, that the Read data that existed when the endorsers simulated the transaction is identical to the current world state. When the committing peer validates the transaction, the transaction is written to the ledger, and the world state is updated with the Write data from the RW Set. Each peer appends the block to the channel’s chain, and for each valid transaction, the write sets are committed to the current state database. All valid transactions are marked as valid using setting the bitmask value as 1 and 0 for invalid.
Each peer possesses a single blockchain per channel and a peer can be associated with multiple channels, hence can have multiple blockchains.
Step 8 — Client notification
Lastly, the committing peers asynchronously notify the client application of the success or failure of the transaction. Applications will be notified by each committing peer.
These are the detailed steps of Fabric Transaction flow. I tried to cover as much as in detail. Hope you liked the technical article. Any feedback and suggestions are most welcome.
You can read my other blog related to Bitcoin
Thanks,
Sumit
Originally published at https://blog.clairvoyantsoft.com on November 25, 2019.
