The ordering service is responsible for receiving the executed transactions from peers, combining them into blocks, and broadcasting them to other peers on the same channel. The peers receiving the transaction blocks then validate it before committing it to their ledger. It is the responsibility of the ordering service to not mix the blocks intended for one channel on another channel.

In version 1.0 of Hyperledger Fabric, the peers would send a transaction (keys and associated values, along with the read/write set) to the ordering service. Thus, the ordering service had visibility into all data associated with transactions, which had implications from a confidentiality standpoint. In version 1.1 of Hyperledger Fabric, the client can send hashes of the transaction data (input and read/write set) to the ordering service while transferring the data associated with a transaction directly to the relevant peers.

Presently, the ordering service is implemented using Kafka and is crash fault tolerant (CFT), but not Byzantine Fault Tolerant (BFT). But this is a point in time statement as HyperLedger is purported to be pluggable that includes the consensus service. Pluggability implies that in future other consensus models may be available.

Although now shown in the diagram depicting Hyperledger Fabric architecture, peers, orderers, and fabric use a pluggable cryptography service provider, which allows them to plug in new crypto algorithms as well as hardware security modules (HSMs) (https://en.wikipedia.org/wiki/Hardware_security_module) for managing crypto keys.