CN111404928A - A blockchain node consensus method suitable for real-time transaction scenarios - Google Patents

Abstract

The invention discloses a block chain node consensus method suitable for real-time transaction scenarios. By analyzing and quantifying the attributes of each node device in the block chain in the network, a set of multi-level and weighted node trustworthiness is set The quantification method obtains the quantified value through the vector and matrix methods, and elects the primary master node accordingly, which reduces the possibility of failure of the primary master node of the blockchain, thereby effectively reducing the frequency of view changes and reducing the delay. Stability and large transaction throughput; by setting up multiple broadcast and response mechanisms in the process of each node communicating and responding to each other, and ensuring that normal nodes are ineffective or tolerated by the blockchain system in multiple links Above the number of malicious nodes, its overall security, real-time performance, and stability are suitable for severe scenarios such as finance.

Description

A blockchain node consensus method suitable for real-time transaction scenarios

technical field

The invention relates to the technical field of blockchain, in particular to a blockchain node consensus method suitable for real-time transaction scenarios.

Background technique

The blockchain originated from Bitcoin. Its essence is a distributed decentralized database, which can be vividly compared to a shared ledger. It has the characteristics of decentralization, non-tampering, full traces, traceability, collective maintenance, and openness and transparency. . Blockchain is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. Generally speaking, the blockchain system consists of application layer, contract layer, consensus layer, network layer and data layer.

The blockchain consensus layer mainly encapsulates various consensus algorithms of network nodes. How to efficiently reach consensus in a distributed system is an important research problem in the field of distributed computing. One of the core advantages of blockchain technology is that it enables nodes to efficiently reach consensus on the validity of block data in a decentralized system with highly decentralized decision-making power. The early Bitcoin blockchain adopted a Proof of Work (PoW) mechanism that highly relied on the computing power of nodes to ensure the consistency of the distributed accounting of the Bitcoin network.

However, the PoW consensus mechanism requires difficult proofs and is not suitable for scenarios that require real-time transactions such as finance. Although the traditional Practical Byzantine Fault Tolerance (PBFT) algorithm can be used as an alternative to PoW, there are still problems that cannot be ignored. : When selecting the master node, it is selected by polling, and the selected node may be unstable or dishonest, which will lead to the problem of triggering frequent view changes.

SUMMARY OF THE INVENTION

In view of the above deficiencies in the prior art, a blockchain node consensus method suitable for real-time transaction scenarios provided by the present invention solves the problem that the existing blockchain node consensus mechanism including the traditional PBFT algorithm is not suitable for finance, etc. Questions for scenarios that require real-time transactions.

In order to achieve the above purpose of the invention, the technical solution adopted in the present invention is: a blockchain node consensus method suitable for real-time transaction scenarios, comprising the following steps:

S1, elect the Primary master node;

S2. Initiate an m request to the Primary master node through the Client client, and receive the m request through the Primary master node;

S3. Assign the sequence number n to the request m through the Primary master node, form a Pre-prepare message, broadcast the Pre-prepare message to all follower nodes in the blockchain, and save the Pre-prepare message in the log of the Primary master node in the log;

S4. Verify the Pre-prepare message through all follower nodes;

S5. Save the verified Pre-prepare messages in the log logs of all follower nodes, and broadcast the Prepare messages through all follower nodes;

S6. Verify the Prepare message received by each node, and adjust the working state of the node that has passed the verification to the Prepared state;

S7. By broadcasting the Commit message through the node that has reached the Prepared state, and verifying the reception and execution of the Commit message, the client client transaction confirmation is realized.

Further, the step S1 includes the following steps:

S11. Establish a tuple model according to the characteristics of the blockchain network and financial mathematics, and obtain the attribute vector x={x ₁ , x ₂ , ... xN} of each node, where x ₁ , x ₂ , ... x _N is the node attribute, N is the total number of attributes, and its value is an integer not less than 1;

S12, quantify the reliability of each attribute in the attribute vector x ₌ {x ₁ , x ₂ , .

S13. According to the importance of each attribute of the blockchain node, establish the attribute weight vector w={w ₁ , w ₂ , . . . , w _N } of each node;

S14, according to the credibility matrix R of each node and the attribute weight vector w, calculate the credibility vector v of each node;

S15. According to the credibility vector v of each node, each node of the blockchain is divided into trusted nodes, general nodes and untrusted nodes, and the trusted nodes are added to the primary master node candidate set;

S16. Take each M consensus of the blockchain as a cycle, within a cycle, switch the view to replace the primary master node, and poll the primary master node candidate set to select the primary master node.

为N×3矩阵，其第i行元素中：r_i1表示该节点属性向量x＝{x₁，x₂，…，x_N}中x_i属性的可信隶属度；r_i2表示该节点属性向量x＝{x₁，x₂，…，x_N}中x_i属性的一般可信隶属度；r_i3表示该节点属性向量x＝{x₁，x₂，…，x_N}中x_i属性的不可信隶属度，i∈[1，N]。Further, the reliability matrix of each node in the step S12

is an N×3 matrix, in the i-th row element: r _i1 represents the credible membership degree of the x _i attribute in the node attribute vector x={x ₁ , x ₂ ,..., x _N }; r _i2 represents the node attribute Vector x={x ₁ , x ₂ ,...,x _N } The general credible membership degree of x _i attribute; r _i3 represents x i in the node attribute vector x={x ₁ , x ₂ ,..., x _{N }} The untrusted membership of the attribute, i ∈ [1, N].

Further, the calculation expression of the step S14 is:

Among them, v ₁ is the credible membership degree of the node, v ₂ is the general credible membership degree of the node, and v ₃ is the unreliable membership degree of the node.

Further, the step S4 includes: performing signature verification on the Pre-prepare message; verifying whether the Pre-prepare message is a message of the view where the current follower node is located; verifying whether the current follower node receives the current view in the current view. Messages other than sequence number n; verify that the Pre-prepare message is within the current receive window.

Further, the step S6 includes: verifying whether there is a Pre-prepare message in the log log of the current node; verifying whether the current node has received 2f Prepare messages from other nodes, where f is invalid or malicious that the blockchain system can tolerate number of nodes.

Further, the step S7 includes the following steps:

S71. Broadcast the Commit message through the nodes that have reached the Prepared state;

S72, through the node that has received the Commit message sent by the 2+1 nodes and has broadcast the Commit message itself, executes the Commit message, and sends feedback to the Client;

S73, determine whether the number of feedbacks received by the Client client within the valid time is greater than f, if so, end, if not, jump to step S74;

S74, broadcast the m request to all nodes through the Client client;

S75, forward the m request of the Client client to the Primary master node by the non-Primary node receiving the m request, where the non-Primary node is a node other than the Primary master node in the blockchain;

S76, determine whether the non-Primary node that has forwarded the m request to the Primary main node has received the response of the Primary main node within the valid time, if so, jump to step S3, if not, then jump to step S77;

S77 , in the primary primary node candidate set, the primary node polls and selects the next node as the primary primary node, and switches the view view, and the client retransmits the request m in the current view.

The beneficial effects of the present invention are as follows: by analyzing and quantifying the attributes of each node device in the blockchain in the network, a set of multivariate and weight-considering node credibility quantification methods are set, and the quantified values are obtained through vector and matrix methods. , and elect the primary master node accordingly, which reduces the possibility of failure of the primary master node of the blockchain, thereby effectively reducing the frequency of view changes and reducing the delay, with higher stability and greater transaction throughput; In the process of mutual communication and response of each node, multiple broadcast and response mechanisms are set, and in multiple links, it is ensured that normal nodes are above the number of invalid or malicious nodes that the blockchain system can tolerate, and its overall security, Real-time performance and stability are suitable for severe scenarios such as finance.

Description of drawings

FIG. 1 is a schematic flowchart of a blockchain node consensus method suitable for real-time transaction scenarios.

Detailed ways

The specific embodiments of the present invention are described below to facilitate those skilled in the art to understand the present invention, but it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes Such changes are obvious within the spirit and scope of the present invention as defined and determined by the appended claims, and all inventions and creations utilizing the inventive concept are within the scope of protection.

As shown in Figure 1, in one embodiment of the present invention, a blockchain node consensus method suitable for a real-time transaction scenario includes the following steps:

S1. Elect the primary master node. The specific steps include:

S11. Establish a tuple model according to the characteristics of the blockchain network and financial mathematics, and obtain the attribute vector x={x ₁ , x ₂ , ... x _N } of each node, where x ₁ , x ₂ , ... x _N is the The attributes of the node, N is the total number of attributes, and its value is an integer not less than 1.

The blockchain system of this embodiment has a total of 7 nodes. According to the network attributes and application environment where they are located, the node attribute vector in the established model includes 3 attributes: effective bandwidth, the number of reliable nodes connected to the node, and the completion of the node. transaction situation.

为N×3矩阵，其第i行元素中：r_i1表示该节点属性向量x＝{x₁，x₂，…，x_N}中x_i属性的可信隶属度；r_i2表示该节点属性向量x＝{x₁，x₂，…，x_N}中x_i属性的一般可信隶属度；r_i3表示该节点属性向量x＝{x₁，x₂，…，x_N}中x_i属性的不可信隶属度，i∈[1，N]。S12 , quantify the reliability of each attribute in the attribute vector x ₌ {x ₁ , x ₂ , . The reliability matrix of each node

is an N×3 matrix, in the i-th row element: r _i1 represents the credible membership degree of the x _i attribute in the node attribute vector x={x ₁ , x ₂ ,..., x _N }; r _i2 represents the node attribute Vector x={x ₁ , x ₂ ,...,x _N } The general credible membership degree of x _i attribute; r _i3 represents x i in the node attribute vector x={x ₁ , x ₂ ,..., x _{N }} The untrusted membership of the attribute, i ∈ [1, N].

S13. According to the importance of each attribute of the blockchain node, establish the attribute weight vector w={w ₁ , w ₂ , . . . , w _N } of each node.

S14: Calculate the credibility vector v of each node according to the credibility matrix R and the attribute weight vector w of each node. The calculation expression is:

Among them, v ₁ is the credible membership degree of the node, v ₂ is the general credible membership degree of the node, and v ₃ is the unreliable membership degree of the node.

After the calculation, the credibility vectors of the seven nodes in this embodiment are obtained as:

node 1: (1, 0, 0);

Node 2: (0.4211, 0.4566, 0.1223);

Node 3: (0.1835, 0.5000, 0.3165);

node4: (0.2770, 0.4566, 0.2664);

Node 5: (0.4812, 0.4130, 0.1057);

Node 6: (0.1686, 0.3856, 0.4559);

Node 7: (0.0949, 0.1771, 0.7280).

S15. According to the credibility vector v of each node, each node of the blockchain is divided into a trusted node, a general node and an untrusted node, and the trusted node is added to the primary master node candidate set. The trust conditions of the 7 nodes are:

Trusted nodes (node 1, node 5);

General trusted nodes (node 2, node 3, node 4);

Untrusted nodes (node 6, node 7).

S16. Take each M consensus of the blockchain as a cycle, within a cycle, switch the view to replace the primary master node, and poll the primary master node candidate set to select the primary master node.

Select node 1 and node 5 as the primary primary node candidate node set, and poll the primary primary node from the set.

S2, initiate an m request to the Primary master node through the Client client, and receive the m request through the Primary master node.

S3. Assign the sequence number n to the request m through the Primary master node, form a Pre-prepare message, broadcast the Pre-prepare message to all follower nodes in the blockchain, and save the Pre-prepare message in the log of the Primary master node in the log.

S4. Verify the Pre-prepare message through all follower nodes. The verification content includes: verifying the signature of the Pre-prepare message; verifying whether the Pre-prepare message is a message in the view view of the current follower node; verifying whether the current follower node receives a message other than sequence number n in the current view view ; Verify that the Pre-prepare message is within the current receive window.

S5. Save the verified Pre-prepare messages in the log logs of all follower nodes respectively, and broadcast the Prepare messages through all follower nodes respectively.

S6. Verify the Prepare message received by each node, and adjust the working state of the node that has passed the verification to the Prepared state. The verification content includes: verifying whether there is a Pre-prepare message in the log log of the current node; verifying whether the current node receives the message. To 2 Prepare messages from other nodes, where f is the number of invalid or malicious nodes that the blockchain system can tolerate.

S7. By broadcasting the Commit message through the node that has reached the Prepared state, and verifying the reception and execution of the Commit message, the client client transaction confirmation is realized. Specifically include the following steps:

S71. Broadcast the Commit message through the nodes that have reached the Prepared state;

S72, through the node that has received the Commit message sent by the 2+1 nodes and has broadcast the Commit message itself, executes the Commit message, and sends feedback to the Client;

S73, determine whether the number of feedbacks received by the Client client within the valid time is greater than f, if so, end, if not, jump to step S74;

S74, broadcast the m request to all nodes through the Client client;

S75, forward the m request of the Client client to the Primary master node by the non-Primary node receiving the m request, where the non-Primary node is a node other than the Primary master node in the blockchain;

S76, determine whether the non-Primary node that has forwarded the m request to the Primary main node has received the response of the Primary main node within the valid time, if so, jump to step S3, if not, then jump to step S77;

S77 , in the primary primary node candidate set, the primary node polls and selects the next node as the primary primary node, and switches the view view, and the client retransmits the request m in the current view.

By analyzing and quantifying the attributes of each node device in the blockchain in the network, the present invention sets a set of multi-dimensional and weight-considering node credibility quantification methods, obtains quantified values through vector and matrix methods, and selects them accordingly. The primary master node reduces the possibility of failure of the primary master node of the blockchain, thereby effectively reducing the frequency of view changes and reducing the delay, with high stability and large transaction throughput; responds by communicating with each other at each node Several broadcast and response mechanisms are set up in the process, and in multiple links, normal nodes are guaranteed to be above the number of invalid or malicious nodes that the blockchain system can tolerate, and its overall security, real-time, and stability. Both are suitable for severe scenarios such as finance.

Claims (7)

1. A blockchain node consensus method applicable to real-time transaction scenarios, characterized in that, comprising the following steps: S1, elect the Primary master node; S2. Initiate an m request to the Primary master node through the Client client, and receive the m request through the Primary master node; S3. Assign the sequence number n to the request m through the Primary master node, form a Pre-prepare message, broadcast the Pre-prepare message to all follower nodes in the blockchain, and save the Pre-prepare message in the log of the Primary master node in the log; S4. Verify the Pre-prepare message through all follower nodes; S5. Save the verified Pre-prepare messages in the log logs of all follower nodes, and broadcast the Prepare messages through all follower nodes; S6. Verify the Prepare message received by each node, and adjust the working state of the node that has passed the verification to the Prepared state; S7. By broadcasting the Commit message through the node that has reached the Prepared state, and verifying the reception and execution of the Commit message, the client client transaction confirmation is realized. 2. The blockchain node consensus method suitable for a real-time transaction scenario according to claim 1, wherein the step S1 comprises the following steps: S11. Establish a tuple model according to the characteristics of the blockchain network and financial mathematics, and obtain the attribute vector x={x ₁ , x ₂ , ... x _N } of each node, where x ₁ , x ₂ , ... x _N is the The attributes of the node, N is the total number of attributes, and its value is an integer not less than 1; S12, quantify the reliability of each attribute in the attribute vector x ₌ {x ₁ , x ₂ , . S13. According to the importance of each attribute of the blockchain node, establish the attribute weight vector w={w ₁ , w ₂ , . . . , w _N } of each node; S14, according to the credibility matrix R of each node and the attribute weight vector w, calculate the credibility vector v of each node; S15. According to the credibility vector v of each node, each node of the blockchain is divided into trusted nodes, general nodes and untrusted nodes, and the trusted nodes are added to the primary master node candidate set; S16. Take each M consensus of the blockchain as a cycle, within a cycle, switch the view to replace the primary master node, and poll the primary master node candidate set to select the primary master node. 3. The blockchain node consensus method suitable for real-time transaction scenarios according to claim 2, wherein the reliability matrix of each node in the step S12

is an N×3 matrix, in the i-th row element: r _i1 represents the credible membership degree of the x _i attribute in the node attribute vector x={x ₁ , x ₂ ,..., x _N }; r _i2 represents the node attribute Vector x={x ₁ , x ₂ ,...,x _N } The general credible membership degree of x _i attribute; r _i3 represents x i in the node attribute vector x={x ₁ , x ₂ ,..., x _{N }} The untrusted membership of the attribute, i ∈ [1, N]. 4. The blockchain node consensus method suitable for a real-time transaction scenario according to claim 2, wherein the calculation expression of the step S14 is:

Among them, v ₁ is the credible membership degree of the node, v ₂ is the general credible membership degree of the node, and v ₃ is the unreliable membership degree of the node. 5. The blockchain node consensus method applicable to a real-time transaction scenario according to claim 1, wherein the step S4 comprises: performing signature verification on the Pre-prepare message; verifying whether the Pre-prepare message is the current follower The message of the view view where the follower node is located; verify whether the current follower node receives a message other than sequence number n in the current view view; verify whether the Pre-prepare message is in the current receiving window. 6. The blockchain node consensus method suitable for a real-time transaction scenario according to claim 5, wherein the verification operation in step S6 comprises: verifying whether there is a Pre-prepare message in the log log of the current node ; Verify whether the current node has received 2f Prepare messages from other nodes, where f is the number of invalid or malicious nodes that the blockchain system can tolerate. 7. The blockchain node consensus method suitable for a real-time transaction scenario according to claim 6, wherein the step S7 comprises the following steps: S71. Broadcast the Commit message through the nodes that have reached the Prepared state; S72, through the node that has received the Commit message sent by the 2f+1 nodes and has broadcast the Commit message itself, executes the Commit message, and sends feedback to the Client; S73, determine whether the number of feedbacks received by the Client client within the valid time is greater than f, if so, end, if not, jump to step S74; S74, broadcast the m request to all nodes through the Client client; S75, forward the m request of the Client client to the Primary master node by the non-Primary node that receives the m request, where the non-Primary node is a node other than the Primary master node in the blockchain; S76, determine whether the non-Primary node that has forwarded the m request to the Primary master node has received the response of the Primary master node within the valid time, if so, jump to step S3, if not, jump to step S77; S77 , in the primary primary node candidate set, the primary node polls and selects the next node as the primary primary node, and switches the view view, and the client retransmits the request m in the current view.

Images