Hyperledger Fabric v1 is a permissioned blockchain platform with a modular architecture made of a Membership Service Provider, peers (endorsing and committing), an ordering service, channels, chaincode and a ledger, and it processes transactions in an execute–order–validate flow.
Main components
- Membership Service Provider (MSP) and Fabric CA: issue X.509 certificates; every participant has a known identity, which makes the network permissioned.
- Clients / applications: use the Fabric SDK to submit transaction proposals.
- Peers: hold the ledger and chaincode.
- Endorsing peers simulate (execute) chaincode and sign the results.
- Committing peers validate blocks and update their ledger (every peer is a committer).
- Anchor peers let organisations discover each other's peers.
- Ordering service (orderers): puts endorsed transactions into a total order, packs them into blocks and delivers them to peers. In v1.x it was Solo or Kafka-based; Raft was added in v1.4.1.
- Channels: private sub-networks; each channel has its own ledger, visible only to its members.
- Chaincode: smart contracts written in Go, Java or Node.js; an endorsement policy states which organisations must sign.
- Ledger: the blockchain (hash-linked blocks, the history) and the world state (current key–value values in LevelDB or CouchDB).
Transaction flow (execute–order–validate)
- The client sends a signed transaction proposal to the endorsing peers named in the endorsement policy.
- Endorsers execute the chaincode on their copy of the world state (no update yet), produce a read–write set, sign it and return the endorsement.
- The client checks the endorsements match and sends the transaction to the ordering service.
- Orderers order transactions from all clients, create blocks and broadcast them to all peers on the channel. (Orderers do not execute transactions.)
- Each committing peer validates every transaction: endorsement policy satisfied, and no read–write conflicts (MVCC version check). Invalid transactions are marked invalid.
- The block is appended to the chain and the world state is updated with valid transactions; events notify the client.
Why this design: separating execution from ordering allows parallel execution, non-deterministic chaincode is caught before commit, confidentiality through channels, and pluggable consensus suited to enterprises.