Before all transactions are sent to Committer for verification and acceptance, they need to be sorted globally through the sorting service.
In the current architecture, the function of the ordering service is extracted and implemented as a separate fabric-orderer module, with the code mainly in the fabric/orderer directory.
Let's take Kafka as an example of a consensus plugin to explain the core process of the Orderer node.
working principle
The Orderer node ( Ordering Service Node, OSN ) acts as a proxy in the network. Multiple Orderer nodes will be connected to the Kafka cluster, and use the consensus function of Kafka to complete the sorting and packaging of transactions in the network into blocks.
The Fabric network provides a multi-channel feature. In order to support this feature and at the same time ensure data consistency on each Orderer node, the ordering service has been specially designed.
For each channel, the Orderer maps it to a topic (the topic name is the same as the channelID) in the Kafka cluster. Since Orderer does not currently use the multi-partition load balancing feature of Kafka Topic, by default, only one partition (partition 0) is created for each topic.
In addition, Orderer also locally maintains a ledger (blockchain) structure for each channel, where each block includes a set of sorted transaction messages and is divided into independent blocks.
Core process
The core process is shown below.
- The client (client) sends transaction information to the
Broadcast()interface of the Orderer node (OSN) through the gRPC connection . - After receiving the request, the Orderer node extracts the message for parsing (parse), checking (Validation), and encapsulating it as a Kafka message after checking, and sending it to the topic partition corresponding to the Kakfa cluster through the Produce interface . If the current number of messages is reached, the
BatchSize.MaxMessageCountmessage size is too large, or the timeout period is reachedBatchTimeout, the block message TTC-X is sent to Kafka. - The Kafka cluster maintains multiple topic partitions. Kakfa uses a consensus algorithm to ensure the consistency of messages written to the partition. That is, once the partition is written, any Orderer node sees the same message queue .
- After the Orderer node is started, it also monitors the Kafka partition data corresponding to the local ledger by default, continuously pulls (Consume) new transaction messages from Kafka , and processes the messages. When a certain strategy is met (TTX-C or configuration message is received), the message will be packaged into blocks.
Block decision
If the block message TTC-X is received, or the configuration transaction is received, the block message is divided into blocks.
The core principle and working process of Hyperledger Fabric ordering service