Hyperledger Fabric Sorting Service core principle and working process

Hyperledger source code Analysis of Fabric

The sorting service plays a very central role in the Super Ledger Fabric network. All transactions need to be sorted globally before they are sent to committer for validation acceptance.

In the current architecture, the function of the sorting service is extracted, as a separate Fabric-orderer module to implement, the code is mainly in the Fabric/orderer directory.

The following Kafka as a consensus plug-in as an example, explain the core process of orderer node. Working principle

The Orderer node (ordering Service node,osn) acts as an agent in the network, and multiple orderer nodes connect to the Kafka cluster, and use the Kafka consensus function to complete the sorting of transactions in the network and to pack the work into blocks.

Fabric Network provides multi-channel characteristics, in order to support this feature, while ensuring the consistency of data on each orderer node, sorting service has some special design.

For each channel, orderer maps it to a topic in the Kafka cluster (topic name is the same as Channelid). Because Orderer currently does not use Kafka Topic's multiple-partition load Balancing feature, each Topic creates only one partition (partition No. 0) by default.

In addition, Orderer maintains a local ledger (block chain) structure for each channel, each of which includes a set of sorted transaction messages and is divided into separate blocks. Core Process

The core process is shown below.

The client sends transaction information through the GRPC connection to the broadcast () interface of the Orderer node. After the Orderer node receives the request, the extraction message is parsed, checked, encapsulated as a KAFKA message through the check, and sent through the produce interface to the topic partition of the KAKFA cluster. When the current number of messages reaches Batchsize.maxmessagecount or the message size is too large, or the timeout time reaches BatchTimeout, a block message is sent Ttc-x to Kafka. The Kafka cluster maintains multiple topic partitions. KAKFA the 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 starts, it also defaults to the local ledger corresponding to the Kafka partition data monitoring, constantly from Kafka pull (consume) new transaction messages, and the message processing. When a certain policy is met (TTX-C or configuration messages are received) the message is also packaged as a block. Block decision-making

If you receive a block message ttc-x, or you receive a configuration transaction, the Shard message is a chunk.

===== about Techfirst Public number =====

Focus on financial technology, artificial intelligence, cloud computing, large data-related areas of hot technology and forward-looking direction.

Send keywords (such as block chain, cloud computing, large data, containers), get popular comments and technical dry goods.

Welcome to contribute.