How do transactions work in Hyperledger Fabric

Overview

Hyperledger Fabric is an open-source framework used to implement enterprise standard blockchain applications. It is a permissioned blockchain targeted toward enterprises. It contains modular components like a shared ledger, smart contract/chain code, certificate authority, and ordering service. We can add these components and personalize them according to the needs of the enterprise.

Transaction flow

Enterprises use the Hyperledger Fabric for a reliable and fast transaction flow. To achieve this, Hyperledger Fabric uses the execute-order-validate method to perform the transactions, unlike the order-execute-validate method used by the public blockchains. The execute-order-validate executes the transactions first, sometimes even in parallel, as requested. After being executed, these transactions are forwarded to an ordering service to be ordered. The details of the whole transaction process are given below.

STEP 1: The client initiates a transaction

The end user wants to perform a transaction. They use the client application to send the request to the SDK. SDK converts the transaction request into a transaction proposal signed by the end user's unique cryptographic signature. SDK then forwards the transaction proposal to peers responsible for endorsement according to the endorsement policy.

STEP 2: Endorsed peers verify the transaction and execute the transaction

The endorsed peers verify the transaction proposal first. The criteria for validity are as follows:

• The transaction proposal is well-formed.
• The transaction proposal has not been submitted in the past.
• The transaction proposal's signature is valid.
• The end user is authorized to perform the requested action on the channel/network.

If the transaction proposal is verified, the endorser peers invoke the chain code function specified by the transaction proposal and send the proposal input as arguments to the function. The function on the chain code is executed, but the changes are not made to the ledger yet. The output, consisting of response value, write set, and read set, is produced as a result of the execution. Lastly, the output and the signature of the endorsing peers are sent back to the SDK. SDK further parses the transaction response for the application.

STEP 3: Inspection of proposal responses

The proposal responses collected from all the endorsing peers are matched, and the application verifies their signatures. Now, the application checks the nature of the proposal. The transaction isn't submitted to the ordering service if the end user only queried some data. However, if the user didn't query the data, the applications ensure that the endorsement policy has been fulfilled.

STEP 4: Client broadcasts endorsements to be converted to a transaction

After ensuring that the endorsement policy has been fulfilled, the application broadcasts the transaction proposal and response to the ordering service. The ordering service receives the transactions from all the channels and arranges them chronologically.

STEP 5: Validation of transactions

A batch of transactions is delivered to all the peers on the channels in the form of a block. The transactions within the block are validated by ensuring the endorsement policy has been fulfilled, and no changes have been made to the ledger when the endorsing peer executed it. After that, the transactions are tagged as valid or invalid.

STEP 6: Update the ledger

After the transactions are validated, they are added to the ledger in the shape of a block. All the peers add the block to their ledger. Furthermore, the write sets broadcasted with the transaction response are committed to the state database, and lastly, an event is emitted to notify the end user.