WO2022111109A1

WO2022111109A1 - Fork resistance detection method and apparatus for blockchain

Info

Publication number: WO2022111109A1
Application number: PCT/CN2021/123806
Authority: WO
Inventors: 刘杨; 常庆安; 彭木根; 关建峰; 陈宇杰; 李辉忠; 张开翔; 范瑞彬; 李成博
Original assignee: 深圳前海微众银行股份有限公司; 北京邮电大学
Priority date: 2020-11-25
Filing date: 2021-10-14
Publication date: 2022-06-02
Also published as: CN112532713A; CN112532713B

Abstract

Disclosed are a fork resistance detection method and apparatus for a blockchain. The method comprises: acquiring a consensus task; dividing nodes of a blockchain to be subjected to detection, so as to determine a first node cluster and a plurality of second node clusters; controlling, according to the consensus task, the first node cluster to selectively perform a fork attack on the plurality of second node clusters; determining ledger states on which consensus is achieved by the nodes in the blockchain; and determining whether the ledger states on which consensus is achieved by the nodes in the blockchain are consistent, and if not, determining that the blockchain does not have a fork resistance characteristic. Some nodes are controlled to selectively perform a fork attack on other node clusters, and the occurrence of a fork is then determined by observing the ledger states of the nodes subjected to the attack, thus achieving detection of the fork resistance characteristic of a blockchain. There is no need to use massive block data to detect the fork resistance performance of the blockchain in a production environment, so that the overheads of a system can be reduced, and the burden on a blockchain network can be reduced.

Description

Anti-fork detection method and device for blockchain

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the priority of the Chinese patent application filed on November 25, 2020 with the application number 202011334160.1 and the application name "An anti-fork detection method and device for blockchain", the entire contents of which are approved by Reference is incorporated in this application.

technical field

The invention relates to the technical field of financial technology (Fintech), and in particular, to a method and device for anti-fork detection of a block chain (Block Chain).

Background technique

With the development of computer technology, more and more technologies are applied in the financial field, and the traditional financial industry is gradually transforming into financial technology. However, due to the security and real-time requirements of the financial industry, there are also higher requirements for technology. In the blockchain technology in the financial field, the performance detection of the blockchain is an important issue.

Most of the current blockchain anti-fork security verification methods need to be directly deployed in the production environment, and the possibility of fork occurrence is predicted in real time through massive block data or node network status information, both in terms of computational and communication costs. Adds a lot of burden to the blockchain network.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide a method and device for anti-fork detection of a blockchain, so as to improve the detection efficiency of anti-fork of a blockchain, save system overhead, and reduce the burden on a blockchain network.

In a first aspect, an embodiment of the present invention provides an anti-fork detection method for a blockchain, including:

Get consensus tasks;

Divide each node of the blockchain to be detected, and determine a first node cluster and a plurality of second node clusters;

According to the consensus task, control the first node cluster to selectively conduct a fork attack on the plurality of second node clusters, and determine the ledger state after consensus of each node in the blockchain;

Determine whether the state of the ledger after the consensus of each node in the blockchain is consistent, if not, it is determined that the blockchain does not have the anti-fork feature.

In the above technical solution, by controlling some nodes to selectively attack other node cluster house type forks, and then by observing the ledger status of each node after the attack to judge the occurrence of the fork, so as to realize the anti-fork feature of the detection block chain. , because there is no need to test the anti-fork performance of the blockchain through massive block data in the production environment, it can save the system overhead and reduce the burden of the blockchain network.

Optionally, the nodes of the blockchain to be detected are divided, and a first node cluster and a plurality of second node clusters are determined, including:

Select a plurality of nodes that meet the consensus fault tolerance number from each node of the blockchain to be detected, and determine it as the first node cluster;

The plurality of second node clusters are obtained by evenly dividing the nodes in each node of the blockchain except the nodes in the first node cluster according to a first preset ratio.

Optionally, according to the consensus task, controlling the first node cluster to selectively perform a fork attack on the plurality of second node clusters includes:

Controlling the first node cluster to send consensus synchronization information to a second node cluster selected from the plurality of second node clusters according to a second preset ratio.

Optionally, the controlling the first node cluster to send consensus synchronization information to a second node cluster selected from the plurality of second node clusters according to a second preset ratio includes:

A master node is determined from the first node cluster, a plurality of third node clusters are determined from the plurality of second node clusters according to the second preset ratio, and the plurality of second node clusters are A node cluster other than the plurality of third node clusters is determined as a fourth node cluster;

In the pre-preparation stage, controlling the master node to broadcast a first broadcast message to each node in the first node cluster and each node in the plurality of third node clusters;

In the preparation stage, controlling the master node to broadcast a second broadcast message to each node in the first node cluster and each node in the plurality of third node clusters;

In the confirmation phase, the master node is controlled to broadcast a confirmation message to each node in the first node cluster and each node in some third node clusters in the plurality of third node clusters.

Optionally, the consensus task is a Byzantine consensus task.

In a second aspect, an embodiment of the present invention provides an anti-fork detection device for a blockchain, including:

The acquisition unit is used to acquire consensus tasks;

The processing unit is used to divide each node of the blockchain to be detected, and determine a first node cluster and a plurality of second node clusters; according to the consensus task, control the first node cluster to selectively send to the A plurality of second node clusters conduct fork attacks, and determine the ledger status after consensus of each node in the blockchain; determine whether the consensus ledger status of each node in the blockchain is consistent, and if not, determine all The above blockchain does not have anti-fork features.

Optionally, the processing unit is specifically used for:

Optionally, the consensus task is a Byzantine consensus task.

In a third aspect, an embodiment of the present invention further provides a computing device, including:

memory for storing program instructions;

The processor is configured to call the program instructions stored in the memory, and execute the above-mentioned anti-fork detection method of the blockchain according to the obtained program.

In a fourth aspect, embodiments of the present invention further provide a computer-readable non-volatile storage medium, including computer-readable instructions, when the computer reads and executes the computer-readable instructions, the computer is made to execute the above-mentioned block chain. Anti-bifurcation detection method.

Description of drawings

In order to illustrate the technical solutions in the embodiments of the present invention more clearly, the following briefly introduces the accompanying drawings used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can also be obtained from these drawings without any creative effort.

1 is a schematic diagram of a system architecture according to an embodiment of the present invention;

2 is a schematic flowchart of a method for anti-fork detection of a blockchain provided by an embodiment of the present invention;

3 is a schematic diagram of message transmission in a pre-preparation stage in a fork attack according to an embodiment of the present invention;

4 is a schematic diagram of message transmission in a preparation stage in a bifurcation attack provided by an embodiment of the present invention;

FIG. 5 is a schematic diagram of message transmission in the confirmation phase in a fork attack according to an embodiment of the present invention;

FIG. 6 is a schematic diagram of a ledger state of a blockchain before and after an attack according to an embodiment of the present invention;

FIG. 7 is a schematic structural diagram of a block chain anti-fork detection device according to an embodiment of the present invention.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

FIG. 1 is a system architecture provided by an embodiment of the present invention. As shown in FIG. 1 , the system architecture may include a blockchain 100 and a client 200;

The client 200 may be a client 200 used by different institutions, and the client 200 mainly sends transaction data to each blockchain node and receives transaction result information fed back by each blockchain node.

The blockchain 100 includes a plurality of blockchain nodes, which are composed of a plurality of blocks and are used to store transaction data sent by the client 200 .

It should be noted that the structure shown in FIG. 1 above is only an example, which is not limited in this embodiment of the present invention.

Based on the above description, FIG. 2 shows in detail a flow of a method for anti-fork detection of a blockchain provided by an embodiment of the present invention, and the flow may be executed by a device for anti-fork detection of a blockchain.

As shown in Figure 2, the process specifically includes:

Step 201, obtaining a consensus task.

In the embodiment of the present invention, the consensus task is a task for testing the anti-fork feature of the blockchain under the test network. The reason why the embodiments of the present invention can achieve the equivalent anti-fork detection results in the production environment under the test network is that the underlying consensus mechanism of the blockchain operation in the test network is the same as the consensus mechanism under the production environment.

In step 202, each node of the blockchain to be detected is divided, and a first node cluster and a plurality of second node clusters are determined.

When dividing the first node cluster and the second node cluster, it is mainly to select multiple nodes that meet the consensus fault tolerance number from each node of the blockchain to be detected, and determine it as the first node cluster; The nodes in the nodes other than the nodes in the first node cluster are equally divided according to the first preset ratio to obtain a plurality of second node clusters. Among them, the consensus fault tolerance quantity is determined by the consensus mechanism. For example, the fault tolerance quantity of the Byzantine consensus mechanism is less than 1/3 of the total number of nodes. The first preset ratio can be set according to experience, for example, it can be 2/3.

Assuming that the total number of nodes in the blockchain network is n, in the anti-fork detection process, the detection party first runs (n-1)/3=f number of nodes. It is assumed here that a node cluster P1 (the first node cluster) is controlled by the detection party, and the remaining node clusters are divided into P2, P3, and P4 with the same number. P2, P3, and P4 are the second node cluster.

Step 203 , according to the consensus task, control the first node cluster to selectively conduct a fork attack on the plurality of second node clusters, and determine the ledger state after consensus of each node in the blockchain.

When the fork attack is performed, the first node cluster is mainly controlled to send consensus synchronization information to the second node cluster selected from a plurality of second node clusters according to a second preset ratio. Wherein, the second preset ratio can be set according to experience.

Specifically, a master node is determined from the first node cluster, a plurality of third node clusters are determined from a plurality of second node clusters according to a second preset ratio, and a plurality of third node clusters are divided from the plurality of second node clusters The node cluster other than the node cluster is determined as the fourth node cluster. In the preparatory stage, the control master node broadcasts the first broadcast message to each node in the first node cluster and each node in the multiple third node clusters. In the preparation stage, the control master node broadcasts the second broadcast message to each node in the first node cluster and each node in the multiple third node clusters. In the confirmation phase, the control master node broadcasts a confirmation message to each node in the first node cluster and each node in some third node clusters in the multiple third node clusters.

For example, when a node in P1 is elected as the master node, a fork attack is launched to test the anti-fork and anti-deactivation characteristics of the blockchain network. The specific fork attack is as follows:

1. In the preparatory stage shown in Figure 3, the node cluster P1 where the master node is located sends the broadcast message sequence number allocation information (the first broadcast message) to each node in the P1, P2, and P3 node clusters (the third node cluster). But not communicating with the nodes in the P4 node cluster.

2. In the preparation stage shown in FIG. 4 , the master node cluster in P1 broadcasts the preparation information (second broadcast message) to each node in the P1, P2, and P3 node clusters. But not communicating with the nodes in the P4 node cluster. The nodes in the P2, P3 node cluster will send messages to all nodes. At this point, the nodes in the P1, P2, and P3 node clusters all enter the confirmation phase. However, since the nodes in the P4 node cluster receive at most 2f mutual interaction messages, they cannot enter the confirmation phase.

3. In the confirmation phase shown in Figure 5, the master node in the P1 node cluster broadcasts the confirmation message to the P1 and P2 node clusters (part of the third node cluster). But not to P4 node cluster. P2, P3 node cluster will broadcast confirmation message to all nodes. At this time, the nodes in the P1 and P2 node clusters can receive 3f confirmation messages for the consensus task m. The nodes in the P3 node cluster and the P4 node cluster receive at most 2f confirmation messages for the consensus task m. The nodes in the P2 node cluster will execute the tasks contained in the task request m and send the results directly to the client. However, the nodes in the P1, P3, and P4 node clusters do not perform this task. The user side cannot get feedback on task processing.

After the above-mentioned fork attack is carried out, the detection party controls the node cluster P1 no longer to reply any messages. Get the current ledger status of each node in the blockchain.

Step 204: Determine whether the consensus ledger status of each node in the blockchain is consistent, and if not, then determine that the blockchain does not have the anti-fork feature.

Compare the ledger status after consensus of each node, if it is inconsistent, it is determined that the blockchain does not have the anti-fork feature, otherwise it is determined that the blockchain has the anti-fork feature.

As in the above-mentioned fork attack, the master node in the detection node cluster P1 does not publish the status update message, and the status update message published by P2 is different from the status update message published by P3 and P4. And since at least 2f+1 identical state update messages are required to update the state of a node, the state of P2 cannot be synchronized with P3 and P4. The system will be in an uncoordinated state for a long time.

After the above-mentioned fork attack is performed, the detection node cluster P1 cooperates with the honest node clusters P3 and P4 to jointly execute another task request of the client. Therefore, the state of each node will enter an unrecoverable and uncoordinated state. If it can be observed that the ledger maintained by the P2 node cluster is inconsistent with the node clusters P1, P3 and P4 after the fork attack occurs, that is, the phenomenon of blockchain fork is observed, and the PBFT (Practical Byzantine Fault Tolerance) can be judged. Practical Byzantine Fault Tolerance ) consensus blockchain does not have complete anti-fork features.

In order to better explain the embodiments of the present invention, the foregoing data processing process will be described below in a specific implementation scenario.

There are n=3+1=4 nodes P1, P2, P3, P4 in the experiment. The node P1 is controlled by the detection party. At the beginning of detection, the main node of view v is P1, the task information is m, the hashed task information is recorded as H(m), and each node uses ECDSA (Elliptic Curve Digital Signature Algorithm, elliptic curve digital signature algorithm) to broadcast information Signature, the public key of each node is public, and the private key is held locally. Before the fork attack is implemented, the blockchain state is A→B→C→D.

1. In the pre-preparation stage, P1 sends the first broadcast message (m, <PRE-PREPARE, v, seq, H(m)>, SIGNATURE) to P1, P2, and P3. But not to P4.

2. In the preparation stage, P1 sends the second broadcast message (<PREPARE, v, seq, H(m), P1>, SIGNATURE) to P1, P2, and P3. But not to P4. In the preparation stage, nodes P2 and P3 will send broadcast messages (<PREPARE, v, seq, H(m), P2>, SIGNATURE) and (<PREPARE, v, seq, H(m), P3>, SIGNATURE) to all nodes. At this point, the nodes P1, P2, and P3 are ready to complete. P4 cannot move to the next stage.

3. In the sequence number confirmation phase, P1 sends the broadcast message (<COMMIT,v,seq,H(m),P1>, SIGNATURE) to P1 and P2, but not to P4. Nodes P2, P3 send broadcast messages (<COMMIT, v, seq, H(m), P2>, SIGNATURE) and (<PREPARE, v, seq, H(m), P3>, SIGNATURE) to all nodes. At this point, nodes P1 and P2 have received three confirmation messages for task m. Nodes P3 and P4 receive at most 2 confirmation messages for task m. The node P2 executes the tasks contained in the task request m and sends the results directly to the client. P1, P3, P4 do not perform this task. Customers are not getting enough responses.

After that, node P1 will not reply to any messages of any view v any more.

It can be observed that after the fork attack is implemented, as shown in Figure 6, the blockchain maintained locally by P2 is: A→B→C→D→E. But the current blockchain recorded by P3 and P4 is still A→B→C→D. Then the Byzantine node P1 of the detection party reaches a consensus with P3 and P4, and adds block F. In the records of P3 and P4, we can see that the blockchain is: A→B→C→D→F. Because block E is different from block F. The blockchain has forked. Since the next block must be extended by the current blockchain, and P1 no longer participates in any blockchain system activities, it can be observed that the blockchain system forks. Therefore, it is detected that the blockchain system based on PBFT consensus does not have good anti-fork characteristics.

The embodiment of the present invention can achieve anti-fork detection results equivalent to the production environment under the test network. Since the underlying consensus of the blockchain operation in the test network is the same as the consensus mechanism in the production environment, and starting from the consensus mechanism and theoretical analysis of the present invention, it does not require massive data to train prediction models and customized block information, so it can greatly reduce Computational and communication overhead required in blockchain fork resistance detection.

The blockchain system to which the embodiments of the present invention are applicable is more general. In the past, the analysis of blockchain consensus security was mainly limited to PoW (Proof of Work, Proof of Work) consensus or PoS (Proof of Stake, Proof of Stake) consensus. In theoretical analysis, economic models are often used to judge the rationality of consensus. The current application trend of blockchain is the rise of currencyless blockchain and consortium chain, and the consensus usually adopted is PBFT consensus or its revised algorithm. The blockchain anti-fork algorithm proposed in the present invention is basically applicable to all The three-stage consensus BFT (Byzantine Fault Tolerance, Byzantine Fault Tolerance) algorithm has a wide range of application scenarios.

In the embodiment of the present invention, a consensus task is obtained, each node of the blockchain to be detected is divided, a first node cluster and a plurality of second node clusters are determined, and according to the consensus task, the selective direction of the first node cluster is controlled. Multiple second node clusters conduct fork attacks to determine the ledger status after consensus of each node in the blockchain, and determine whether the consensus ledger status of each node in the blockchain is consistent. If they are inconsistent, it is determined that the blockchain does not have Anti-splitting properties. By controlling some nodes to selectively fork attacks on other node clusters, and then by observing the ledger status of each node after the attack to determine the occurrence of the fork, the anti-fork feature of the blockchain can be detected. In the environment, the anti-fork performance of the blockchain is detected by massive block data, which can save the system overhead and reduce the burden of the blockchain network.

Based on the same technical concept, FIG. 7 exemplarily shows the structure of a block chain anti-fork detection device provided by an embodiment of the present invention, and the device can perform a block chain anti-fork detection process.

As shown in Figure 7, the device specifically includes:

an obtaining unit 701, configured to obtain a consensus task;

The processing unit 702 is used to divide each node of the blockchain to be detected, and determine a first node cluster and a plurality of second node clusters; according to the consensus task, control the first node cluster to selectively send to all nodes. The multiple second node clusters perform a fork attack to determine the ledger status after consensus of each node in the blockchain; determine whether the consensus ledger status of each node in the blockchain is consistent, and if not, determine The blockchain is not fork resistant.

Optionally, the processing unit 702 is specifically configured to:

Optionally, the consensus task is a Byzantine consensus task.

Based on the same technical concept, an embodiment of the present invention also provides a computing device, including:

memory for storing program instructions;

The processor is used to call the program instructions stored in the memory, and execute the above-mentioned anti-fork detection method of the blockchain according to the obtained program.

Based on the same technical concept, an embodiment of the present invention also provides a computer-readable non-volatile storage medium, including computer-readable instructions, when the computer reads and executes the computer-readable instructions, the computer executes the above-mentioned blockchain Anti-bifurcation detection method.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device produce Means for implementing the functions specified in a flow or flow of a flowchart and/or a block or blocks of a block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions The apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process such that The instructions provide steps for implementing the functions specified in the flow or blocks of the flowcharts and/or the block or blocks of the block diagrams.

Although the preferred embodiments of the present invention have been described, additional changes and modifications to these embodiments may occur to those skilled in the art once the basic inventive concepts are known. Therefore, the appended claims are intended to be construed to include the preferred embodiment and all changes and modifications that fall within the scope of the present invention.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit and scope of the invention. Thus, provided that these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

An anti-fork detection method for a blockchain, characterized in that it includes:

Get consensus tasks;

Divide each node of the blockchain to be detected, and determine a first node cluster and a plurality of second node clusters;

According to the consensus task, control the first node cluster to selectively conduct a fork attack on the plurality of second node clusters, and determine the ledger state after consensus of each node in the blockchain;

Determine whether the state of the ledger after the consensus of each node in the blockchain is consistent, if not, it is determined that the blockchain does not have the anti-fork feature.
The method according to claim 1, wherein, dividing each node of the blockchain to be detected to determine a first node cluster and a plurality of second node clusters, comprising:

Select a plurality of nodes that meet the consensus fault tolerance number from each node of the blockchain to be detected, and determine it as the first node cluster;

The plurality of second node clusters are obtained by evenly dividing the nodes in each node of the blockchain except the nodes in the first node cluster according to a first preset ratio.
The method of claim 1, wherein, according to the consensus task, controlling the first node cluster to selectively perform a fork attack on the plurality of second node clusters, comprising:

Controlling the first node cluster to send consensus synchronization information to a second node cluster selected from the plurality of second node clusters according to a second preset ratio.
The method of claim 1, wherein the controlling the first node cluster to send consensus synchronization information to a second node cluster selected from the plurality of second node clusters according to a second preset ratio ,include:

A master node is determined from the first node cluster, a plurality of third node clusters are determined from the plurality of second node clusters according to the second preset ratio, and the plurality of second node clusters are A node cluster other than the plurality of third node clusters is determined as a fourth node cluster;

In the pre-preparation stage, controlling the master node to broadcast the first broadcast message to each node in the first node cluster and each node in the plurality of third node clusters;

In the preparation stage, controlling the master node to broadcast a second broadcast message to each node in the first node cluster and each node in the plurality of third node clusters;

In the confirmation phase, the master node is controlled to broadcast a confirmation message to each node in the first node cluster and each node in some third node clusters in the plurality of third node clusters.
The method according to any one of claims 1 to 4, wherein the consensus task is a Byzantine consensus task.
An anti-fork detection device for blockchain, characterized in that it includes:

The acquisition unit is used to acquire consensus tasks;

The processing unit is used to divide each node of the blockchain to be detected, and determine a first node cluster and a plurality of second node clusters; according to the consensus task, control the first node cluster to selectively send to the A plurality of second node clusters conduct fork attacks, and determine the ledger status after consensus of each node in the blockchain; determine whether the consensus ledger status of each node in the blockchain is consistent, if not, determine all The above blockchain does not have anti-fork features.
The apparatus of claim 6, wherein the processing unit is specifically configured to:

Select a plurality of nodes that meet the consensus fault tolerance number from each node of the blockchain to be detected, and determine it as the first node cluster;

The plurality of second node clusters are obtained by evenly dividing the nodes in each node of the blockchain except the nodes in the first node cluster according to a first preset ratio.
The apparatus of claim 6, wherein the processing unit is specifically configured to:

Controlling the first node cluster to send consensus synchronization information to a second node cluster selected from the plurality of second node clusters according to a second preset ratio.
The apparatus of claim 6, wherein the processing unit is specifically configured to:

A master node is determined from the first node cluster, a plurality of third node clusters are determined from the plurality of second node clusters according to the second preset ratio, and the plurality of second node clusters are A node cluster other than the plurality of third node clusters is determined as a fourth node cluster;

In the pre-preparation stage, controlling the master node to broadcast the first broadcast message to each node in the first node cluster and each node in the plurality of third node clusters;

In the preparation stage, controlling the master node to broadcast a second broadcast message to each node in the first node cluster and each node in the plurality of third node clusters;

In the confirmation phase, the master node is controlled to broadcast a confirmation message to each node in the first node cluster and each node in some third node clusters in the plurality of third node clusters.
The apparatus according to any one of claims 6 to 9, wherein the consensus task is a Byzantine consensus task.
A computing device, comprising:

memory for storing program instructions;

The processor is configured to call the program instructions stored in the memory, and execute the method according to any one of claims 1 to 5 according to the obtained program.
A computer-readable non-volatile storage medium, characterized by comprising computer-readable instructions, when the computer reads and executes the computer-readable instructions, the computer is made to execute any one of claims 1 to 5. Methods.