Now that we've looked at the reference architecture, let's consider the runtime architecture for Hyperledger Fabric:

 

The following outline demonstrates a Hyperledger Fabric runtime transaction processing flow:

• Transaction proposal (application SDK):
  1. Transaction proposal is submitted by application SDK
  2. It receives a transaction proposal response back (includes ReadWrite set) post endorsement
  3. It submits the transaction (includes ReadWrite set) to the ordering service
• Transaction endorsement:
  1. The transaction is sent to the counter-parties represented by endorsing peers on their channel
  2. Each peer executes the transaction by calling the specified chaincode function and signs the result, which becomes the read-write-set of the transaction
  3. Each peer may participate in multiple channels, allowing concurrent execution

• Transaction submitted to the ordering service:
  1. The ordering service accepts endorsed transactions and orders them according to the plug-in consensus algorithm, and then delivers them on the channel
  2. Peers on the channel receive transactions and validate before committing to the ledger
• Transaction validation:
  1. Validates each transaction and commit block
  2. Validates the endorsement policy
  3. Validates ReadSet versions in state DB
  4. Commits the block to blockchain
  5. Commits the valid transaction to state DB