Ordering Service

Introduction

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. Hyperledger Fabric works differently, as transaction ordering is handled by a so-called Ordering Service. An Ordering Service is an entity that governs transaction ordering for one or more Channels through its nodes, called orderers or orderer nodes.

Ordering Services exist independent of the peer processes and orders transactions on a first-come-first-serve basis for all channels on the network.

In basic scenarios, a single Ordering Service is defined to handle transaction ordering for all Channels in the Network. However, Hyperledger Fabric supports multiple Ordering Services for one Network, even with different Consensus Protocols.

At the moment, the only consensus algorithm available on the platform is Raft. Raft offers a generic way to distribute a state machine across a cluster of computing systems, ensuring that each node in the cluster agrees upon the same series of state transitions. With the next updates, you will also find Kafka.

Configuration

Double click on the Ordering Service to edit it.

Settings

• Name: defines the Ordering Service’s name (Ordering Service Name must be set);

• Consensus Type: defines which implementation will be used by this Ordering Service to determine Consensus (the Consensus Type can be “Raft” or “Kafka”);

• Add Policy: custom policy setting is not yet implemented. It will be implemented in the coming updates (Policies for this Ordering Service must be set).

• Organization: defines to which Orderer Organization this Ordering Service belongs (Organization must be set).

Notes:

• “Orderers” defines the number of Orderer Nodes belonging to this Ordering Service (Orderer Nodes must be set).

• The Ordering Service must be assigned to a Channel.

• Names must contain only alphanumeric characters or '_' and be 20 characters at most.

For higher crash/fault tolerance and redundancy, it is advised that an Ordering Service is defined with at least 2 Orderer Nodes. Since Ordering Services might be serving multiple Channels, one should also consider scaling the amount of Orderer Nodes to match this eventuality.