Ordering Service

Many distributed blockchains, such as Ethereum and Bitcoin, are not permissioned, which means that any node can participate in the consensus process, wherein transactions are ordered and bundled into blocks. Because of this, these systems rely on probabilistic consensus algorithms that eventually guarantee ledger consistency to a high degree of probability, being still vulnerable to divergent ledgers (also known as a ledger “fork”). Thus, different participants in the network have a different view of the accepted order of transactions.

Hyperledger Fabric works differently. It features a node called an orderer (also known as an ordering node) that does this transaction ordering, forming an ordering service with other nodes. Because the Hyperledger Fabric design relies on deterministic consensus algorithms, any block a peer validates as generated by an ordering service is guaranteed to be final and correct. Ledgers cannot fork the way they do in many other distributed blockchains.

In addition to promoting finality, separating the endorsement of chaincode execution (which happens at the peer level) from ordering gives Hyperledger Fabric advantages in performance and scalability. This also eliminates bottlenecks that can occur when execution and ordering are performed by the same nodes.

An ordering service also enforces basic access control for channels, restricting who can read and write data, as well as configure channels. Configuration transactions are also processed by an orderer. An orderer processes the configuration update to make sure that a requester has the proper administrative rights. If so, the orderer validates the update request against the existing configuration, generates a new configuration transaction, and packages it into a block that is broadcasted to all peers on the channel. Peers then process the configuration transactions in order to verify that the modifications approved by the orderer do satisfy the policies defined in the channel.