Block chain Basic Knowledge Series second lesson block chain consensus algorithm

The consensus algorithm solves the process of agreeing on a proposal (proposal). PBFT (Byzantine fault-tolerant) algorithm-fabric 0.6 adopts

Five stages: request, pre-preparation (Pre-prepare), preparation (prepare), and confirmation (commit), reply

Steps:

1. From the full network node to elect a master node (Leader), the new area block by the main node responsible for generation
2.pre-prepare: Each node sends the transaction from the client to the whole network broadcast, the main node 0 will collect from the network to need to put in the new area the multiple trades sorted after the list, and will broadcast this list to the whole network, spread to 123
3.Prepare: After each node receives a list of transactions, the transactions are executed according to the sort simulation. After all transactions have been executed, the hash summary of the new zone block is computed based on the transaction result and broadcast to the whole network, 1->023,2->013,3 because the outage cannot broadcast
4.Commit: If a node receives a summary of 2f (f is a tolerable number of Byzantine nodes) that the other node sends, it broadcasts a COMMIT message to the whole network.
5.Reply: If a node receives a 2f+1 commit message, it can submit a new block and its transaction to the local block chain and state database.

Byzantine fault tolerance accommodates nearly 1/3 of error node errors, and the IBM-created version of Hyperledger 0.6 uses the algorithm as a consensus algorithm (version 1.0 has been deprecated, using Kafka).

Fabric1.0 adopts consensus algorithm for solo, Kafka

1.Solo orderer:the Solo Orderer is intended to be a extremely easy to deploy, Non-production orderer. It consists of a single process which serves all clients, so no ' consensus ' is required as there are a single Rity. There is correspondingly no high availability or scalability. This is makes solo ideal for development and testing, but not deployment. The Solo Orderer depends on a backing orderer ledge

Order-solo mode as a single node communication mode, all messages received from peer in this node to sort and generate data blocks, detailed process see the following figure: (for development mode)

Order-solo Process Analysis: Peer (client) to initiate communication through GRPC, after the successful connection with Orderer, you can send a message to the orderer. The Orderer receives messages sent over the peer via the Recv interface, Orderer generates data blocks from the received message, and stores the data blocks in Ledger,peer to obtain the data blocks from deliver through the Orderer interface.

2.Kafka orderer:  the Kafka Orderer leverages the Kafka pubsub system to perform the ordering, but wraps this in T He familiar Ab.proto the peer of Orderer client code does not to be written specifically for Kafka. In real world deployments, it would is expected that Kafka proto Service would bound locally in process, as Kafka has Its own robust wire protocol. However, for testing or novel deployment scenarios, the Kafka orderer of May is deployed as a network service. Kafka is anticipated to are the preferred choice production deployments which demand high throughput and high availability But do not require Byzantine fault tolerance. The Kafka Orderer does not utilize a backing orderer ledger because it is handled by the Kafka brokers.

Orderer-kafka analysis (for the formal environment) Broadcast:broadcast mainly receive peer data and generate a series of data blocks in Orderer, the main process is shown in the following figure: Broadcast Process Analysis: Peer (client) to initiate communication through GRPC, after the successful connection with Orderer, you can send a message to the orderer. Orderer receives the message sent over the peer via the Recv interface and pushes the message to Kafka. At the same time, the orderer connected with Kafka through the consumer instance consumes the message on Kafka, the message of consumption is sorted (order), and after sorting is completed, the condition of generating block (two 1: The next data block timer expires, The timer sends the timer message to the Orderer to Kafka, and then achieves the timing effect by Kafka consumption. 2: Each consumption of a real data, the trigger to determine whether to achieve a new block condition generated by the current data blocks to be generated by the total size and number of records determined, and create a new data block (Createnextblock), The success is created by writing the Block to Ledger (WriteBlock) deliver process analysis:

Peer through the GRPC and Orderer to establish communications, after the successful connection, through the deliver interface to initiate the acquisition of data requests. Orderer receives requests for data acquisition through the Recv interface, parsing request parameters (Seekinfo_start:1, seekposition_oldest: Getting from the first block of data. 2, Seekposition_newest: Starting from the latest block of data to get 3, seekposition_specified: From the specified number of blocks of data obtained. Orderer gets the data block iterator entry from the ledger, the loop iterator gets all the blocks of data, returns each chunk of data to the peer at the same time, knows all the blocks are fetched, and finally returns to peer for a successful state.

Content reference to: https://zhuanlan.zhihu.com/p/25358777