Hyperledger Fabric runtime architecture
Now that we've looked at the reference architecture, let's consider the runtime architecture for Hyperledger Fabric:
![](https://epubservercos.yuewen.com/76C6D0/19470380908820406/epubprivate/OEBPS/Images/73fd6b03-d170-4c8d-9caa-915e683e2973.png?sign=1738926611-2ES3F6jhmtX0napMjD85uXM9M4xcTeEI-0-0d7d84f29fa27725a5db5af76d6b9b49)
The following outline demonstrates a Hyperledger Fabric runtime transaction processing flow:
- Transaction proposal (application SDK):
- Transaction proposal is submitted by application SDK
- It receives a transaction proposal response back (includes ReadWrite set) post endorsement
- It submits the transaction (includes ReadWrite set) to the ordering service
- Transaction endorsement:
- The transaction is sent to the counter-parties represented by endorsing peers on their channel
- Each peer executes the transaction by calling the specified chaincode function and signs the result, which becomes the read-write-set of the transaction
- Each peer may participate in multiple channels, allowing concurrent execution
- Transaction submitted to the ordering service:
- The ordering service accepts endorsed transactions and orders them according to the plug-in consensus algorithm, and then delivers them on the channel
- Peers on the channel receive transactions and validate before committing to the ledger
- Transaction validation:
- Validates each transaction and commit block
- Validates the endorsement policy
- Validates ReadSet versions in state DB
- Commits the block to blockchain
- Commits the valid transaction to state DB