Transaction Flow

Transactions in an active Hyperledger Fabric network should pass a number of steps before being committed to a ledger. These steps are part of what is called a transaction flow.

1. A client application initiates a transaction. A client application submits a transaction proposal to invoke a chaincode function to endorsing peers. The transaction proposal is generated by a supported SDK (e.g., Hyperledger Fabric Node.js SDK). The SDK packages the transaction proposal into the proper format (i.e., protocol buffer over gRPC) and takes the user’s cryptographic credentials to produce a unique signature for the proposal.

2. Endorsing peers verify the transaction proposal and simulate the transaction. Endorsing peers verify that the transaction proposal is composed correctly and has not been submitted already in the past. Using MSPs, endorsing peers validate the proposal signature and check that a submitter is authorized to perform a proposed operation on the channel (namely, each endorsing peer ensures that a submitter satisfies channel’s writers policy). After the verification, endorsing peers locally simulate transaction execution taking the transaction proposal inputs as chaincode arguments. As a result, read and write sets are composed. A read set is a number of key-value pairs used by the chaincode during the simulation. A write set represents assets to create or update after the transaction execution. No updates are made to a ledger at this point. Finally, read and write sets and a response value along with endorsing peers’ signatures are returned back as a “proposal response” to the SDK, which prepares the payload for the application to consume.

3. Proposal responses are inspected by the client application. The client application assembles endorsements into a transaction. The application verifies the endorsing peers’ signatures and compares the proposal responses to determine if they are the same. If the endorsement policy is satisfied, the client application submits a transaction proposal and response to an ordering service within a “transaction message”. If the application tries to forward a faulty or unendorsed transaction, the endorsement policy will still be enforced by peers and upheld at the commit validation phase. The transaction will contain the read/write sets, the endorsing peers’ signatures and the channel ID. An 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.

4. The transaction is validated and committed. The blocks of transactions are delivered to all peers on the channel. The transactions within the block are validated to ensure the endorsement policy is fulfilled, and the data that was read during chaincode execution has not changed since endorsement time. If the read set has been changed by another transaction, the transaction in the block is marked as invalid.

5. The ledger is updated. Each peer appends the block to the channel’s chain, and for each valid transaction the write set is committed to the state database. The client application is notified about the validity of the transaction and can handle an error if a transaction is invalid.