Shulou(Shulou.com)06/01 Report--

This article mainly shows you the "sample analysis of Raft consensus plug-ins in hyperledger fabric", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and study the "sample analysis of Raft consensus plug-ins in hyperledger fabric".

1. The basic concept of consensus

The consensus algorithm can make the cluster work together, and can tolerate the failure of some member hosts. Usually when we mention the failure of the host, we will distinguish between two situations: Byzantine failure and non-Byzantine failure.

Bitcoin was the first decentralized system to solve the Byzantine problem by using workload proof consensus (POW). In a system with Byzantine failure, not only the host crash will occur, but also some members may have malicious behavior to affect the decision-making process of the whole system.

If a distributed system can handle Byzantine failures, it can tolerate any type of error. Common consensus algorithms that support Byzantine failures include PoW, PoS, PBFT, and RBFT.

Raft can only handle non-Byzantine failures, which means that the Raft consensus can tolerate failures such as system crashes, network outages / delays / packet losses. Common consensus algorithms or systems that support non-Byzantine failures include Raft, Kafka, Paxos, and Zookeeper.

So why doesn't Hyperledger Fabric use a consensus mechanism that can tolerate Byzantine failures? Isn't that safer?

One reason lies in the compromise between the complexity of the system and the design of security. Assuming that n nodes in a system may have Byzantine failures at the same time, then Byzantine fault tolerance requires the system to have at least 3n+1 nodes. For example, to deal with 100 potentially malicious nodes, you need to deploy at least 301 nodes. This makes the system more complex. On the other hand, Raft only needs 2n+1 nodes to deal with potential n-node non-Byzantine failures, which is obviously less complex and costly. Therefore, some distributed systems are more inclined to Raft, especially considering that in the licensed federation chain environment such as Hyperledger Fabric, security mechanisms such as digital certificates are usually used to enhance security, so there is little possibility of malicious nodes.

2. The basic principles of Raft consensus.

Raft is a distributed crash fault tolerance consensus algorithm, which can ensure that the system can still process client requests when some nodes in the system have non-Byzantine faults. Technically, Raft is a consensus algorithm for managing replication logs (Replicated Log), which are part of the replication state machine (RSM:Replicated State Machine).

Replication state machine is a relatively basic architecture for building distributed systems. Its main components include a node log containing a command sequence, a consensus module (such as Raft), and a state machine.

The replication state machine works as follows:

The client sends a request containing a command to the master node (Leader Node)

The master node appends the received request to its log and sends the request to all Follower Node. The following node also appends the request to its own log and returns a confirmation message.

Once the host node receives most of the confirmation messages from the following node, it submits the command log to the state machine it manages. Once the master node commits the log, the following node also submits the log to its own managed state machine

The master node returns the response result to the client

So, what role does Raft play in replication stateful rack architecture?

The role of Raft is to ensure that the log of the following node is consistent with that of the master node (that is, log replication), so that the behavior of the entire distributed system seems to be consistent, even if some nodes fail.

Another question is, does the client need to know which is the dominant node?

The answer is NO, the client can send a request to any node, if the node is the master node, then it will process the request directly, otherwise, the node will forward the request to the master node.

3. Basic characteristics of Raft consensus 3.1 Raft node status

For the Raft algorithm, each node can only be in one of three states:

Follow state: in the initial case, all nodes are in the follow state, that is, all follow nodes. Once a following node does not communicate properly, it transitions to a candidate state (Candidate), that is, to become a candidate node. The log of the following node can be rewritten by the master node.

Candidate status: the node in the candidate state initiates an election and transitions to the dominant state if it is approved by the majority of the members of the cluster.

Dominant state: processes client requests and ensures that all following nodes have the same log copy. The master node cannot rewrite its own log.

If the candidate node finds that the dominant node has been selected, it will return to the follow state. Similarly, if the dominant node finds that the term of office (Term) of the other dominant node is higher, it will also fall back to the follow state.

Term is a monotonously increasing integer value that identifies the management cycle of the dominant node. Each term begins with an election until the next term.

3.2 the election of the Raft dominant node

Raft uses the heartbeat mechanism to start the election of the leading node. When a node enters the follow state after startup, it will remain in the follow state as long as it can receive a valid RPC heartbeat message from the host node or candidate node. The dominant node periodically sends heartbeat messages (AppendEntries RPC messages without log entries) to all the following nodes to maintain their dominant position. If a follower node does not receive a heartbeat message for a period of time, an election timeout occurs, and the node assumes that there is no dominant node and initiates an election to select a new dominant node.

To start an election, the following node increments its current term value and transitions to the candidate state. The node first votes for itself, and then sends a message requesting a vote (RequestVote RPC message) to other nodes at the same time.

The candidate node remains in the candidate state until the following events occur:

The node won the election.

Other nodes win the election.

No node wins the election.

If the node receives the approval of most of the nodes, it can win the election, then the node will transition to the dominant state and become the new dominant node. Note: only one vote can be cast per node.

If at the same time other nodes declare themselves to be the dominant node and have a higher term value, then the node with the high term value becomes the new dominant node:

If the votes of multiple candidate nodes are the same, then there is no winning node.

To avoid this, you can reinitialize the election and ensure that the election timeout for each node is random to avoid following the node into the candidate state at the same time.

3.3 Log replication

Once the master node is selected, it begins to process the client's request. The request contains commands that need to be executed by the replication state machine. The master node appends the command to its own log and then sends AppendEntriesRPC messages to all the following nodes in parallel to copy the new log entry. When the new log entry is safely copied, the master node executes the commands in the log entry on its own state machine and returns the results to the client.

If the following node crashes, runs slowly, or a packet loss occurs on the network, the master node will infinitely retry sending the AppendEntries RPC message (even if it has returned the response result to the client) until all the following nodes finally get a consistent copy of the log.

When sending an AppendEntries RPC message, the master node sends both the sequence number and the expiration value of the preordered log entry of the new log entry. If the following node does not find the same sequence number and expiration value in its own log, it will reject the new log entry. So if the pendEntries returns successfully, the master node knows that the log of the following node is exactly the same as its own.

When an inconsistency occurs, the master node forces the following node to copy its own log.

4. Implementation of Raft sorting service of Hyperledger Fabric.

The Raft-based sorting service replaces the previous Kafka sorting service. Each sort node has its own Raft replication state machine to submit logs. The client uses Broadcast RPC to send a deal offer. The Raft sorting node generates a new block based on consensus, and when the peer node sends Deliver RPC, it sends the block to the peer node.

The workflow of the Raft sort node is as follows:

Transactions (such as proposals, configuration updates) should be automatically routed to the current master node of the channel

The master node checks whether the configuration serial number of the transaction verification is consistent with the current configuration serial number, performs the verification if it is inconsistent, and rejects the transaction after the verification fails. After verification, the master node passes the received transaction into the Ordered method of the block cutting module to create the candidate block.

If a new block is generated, the dominant sorting node applies it to the local Raft finite state machine (FSM)

The finite state machine will attempt to copy to a sufficient number of sort nodes to submit blocks

The block is written to the local ledger of the receiving node

Each channel runs a separate instance of the Raft protocol. In other words, a network with N channels has N Raft clusters, and each Raft cluster has its own dominant sorting node.

5. Hyperledger Fabric Network practice based on Raft consensus

We use the BYFN component to show how the raft consensus module is used. The BYFN contains five sort nodes, two organizations, four peers, and an optional CouchDB. The configuration of the Raft sorting service is given in the configtx.yaml file.

Start the default go chain code and raft consensus with the following script command, which automatically generates the necessary cryptographic data:

Cd fabric-samples/first-network./byfn.sh up-o etcdraft

View the sorting service:

Docker logs-f ordrer3.example.com

Now let's verify the fault tolerance of Raft.

First stop the Node3:

Docker stop orderer3.example.com

Then stop Node5:

Docker stop orderer5.example.com

Now that we verify the validity of the system, we can see that the system can still respond normally to the client's request:

The above is all the content of the article "sample Analysis of Raft consensus plug-ins in hyperledger fabric". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.