WO2024021410A1

WO2024021410A1 - Method and apparatus for preventing network attacks

Info

Publication number: WO2024021410A1
Application number: PCT/CN2022/135159
Authority: WO
Inventors: 焦梦洪
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-07-29
Filing date: 2022-11-29
Publication date: 2024-02-01
Also published as: CN115277021A

Abstract

Provided in the present specification are a method and apparatus for preventing network attacks, which are applied to a verification node in a blockchain network. The method comprises: sending a verification request to a node to be verified in a blockchain network, the verification request comprising the block height of a block to be verified selected by the verification node from locally maintained blocks; and receiving a verification response sent by the node to be verified in response to the verification request, the verification response comprising first block information; when the first block information fails to be matched with second block information corresponding to the block to be verified, determining that the verification of the node to be verified has failed; and, when it is determined that a first number of verification failure times of the node to be verified exceeds a first preset threshold value, disconnecting from the node to be verified.

Description

A method and device for preventing network attacks

Technical field

The embodiments of this specification belong to the field of network security technology, and particularly relate to a method and device for preventing network attacks.

Background technique

At this stage, attacks on communication networks are emerging one after another, and the attack methods are also different. Among them, the number of attack cases on P2P networks is relatively common. For example, for blockchain networks, attackers can design attack algorithms based on the characteristics of the underlying P2P network corresponding to the blockchain network, thereby achieving attacks on the blockchain network.

Contents of the invention

The purpose of the present invention is to provide a method and device for preventing network attacks.

According to a first aspect of one or more embodiments of this specification, a method for preventing network attacks is proposed, which is applied to a verification node in a blockchain network, including: sending a message to a node to be verified in the blockchain network. Verification request, the verification request includes the block height of the block to be verified selected by the verification node from the locally maintained blocks; receiving the verification response sent by the node to be verified in response to the verification request, the verification The response includes the first block information; when the first block information fails to match the second block information corresponding to the block to be verified, it is determined that the verification of the node to be verified fails; when it is determined that the verification of the node to be verified fails. If the first number of failures exceeds the first preset threshold, the connection with the node to be verified is disconnected.

According to the second aspect of one or more embodiments of this specification, a device for preventing network attacks is proposed, which is applied to a verification node in a blockchain network and includes: a request sending unit for sending a request to the blockchain network. The node to be verified in sends a verification request, the verification request includes the block height of the block to be verified selected by the verification node from the locally maintained blocks; a response receiving unit is used to receive the response of the node to be verified A verification response sent by the verification request, the verification response including the first block information; a verification unit used to fail to match the first block information with the second block information corresponding to the block to be verified. It is determined that the node to be verified has failed to verify; a connection disconnecting unit is configured to disconnect from the node to be verified if it is determined that the first number of verification failures of the node to be verified exceeds a first preset threshold.

According to a third aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; and a memory for storing instructions executable by the processor. Wherein, the processor implements the method described in the first aspect by running the executable instructions.

According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is proposed, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

Based on the foregoing embodiments of this specification, a verification mechanism is proposed to ensure that each node in the blockchain network maintains the same set of blockchain ledgers. The node to be verified needs to provide the correct verification node based on the block height in the verification request. Block information, otherwise the node to be verified will be regarded as a fault node by the verification node, or as an attacker of a special attack, that is, the node to be verified does not actually maintain the same set of blockchain ledgers as the verification node, but reuses them. The same set of communication modules of the underlying P2P network is used, causing nodes actually in different blockchain networks to be able to access illegally. At this time, the verification node disconnects from the node to be verified that is regarded as a fault node or attacker, so that it can Eliminate risks that threaten the normal operation of the system or network security in a timely manner. In addition, even if the attacker as the node to be verified can provide correct block information through other means to avoid forced disconnection, the foregoing embodiments of this specification can objectively increase the cost of the attacker maintaining the connection with the blockchain network. , thereby indirectly improving the blockchain network's ability to prevent cyber attacks by increasing attack costs.

Description of drawings

In order to explain the technical solutions of the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some of the embodiments recorded in this specification. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 is a schematic diagram of a blockchain network provided by an exemplary embodiment.

Figure 2 is a flow chart of a method for preventing network attacks provided by an exemplary embodiment.

Figure 3 is a schematic structural diagram of a device provided by an exemplary embodiment.

Figure 4 is a block diagram of a device for preventing network attacks provided by an exemplary embodiment.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of this specification.

P2P (Peer to Peer) network, that is, point-to-point network, or peer-to-peer network, is a distributed network that is different from the C/S (client/server) model. All nodes in the P2P network are in a peer-to-peer position with each other, and each node can act as both a client and a server to provide resources and services to other nodes. For example, the blockchain network is a typical P2P network. The P2P network involved in the embodiments of this specification can be a blockchain network, and the nodes included in the P2P network all belong to the blockchain in the blockchain network. node.

Figure 1 is a schematic diagram of a blockchain network provided by an exemplary embodiment. As shown in Figure 1, the blockchain network contains 5 nodes that have been connected to the network, namely nodeA, nodeB, nodeC, nodeD and nodeE. Among them, the relationship between these 5 nodes is not fully connected. For example, nodeA Only connections are established with nodeB, nodeC and nodeD but no connection is established with nodeE. Each node maintains an independent node list locally. The node list records the node information of other nodes in the same blockchain network that are connected to the node. Therefore, the node list is also called a neighbor table. For example, nodeA maintains The node information of nodeB, nodeC and nodeD is recorded in the node list. In addition, from a functional perspective, the node list can also be used as a routing table to guide message transmission. In the embodiment of this specification, the node information of any node may include the node identification, network address (such as IP address, port number, etc.) of any node, and/or the node's identity information (such as node public key), etc. , this manual does not limit this. The connection involved in the embodiment of this specification refers to a network connection, such as a TCP or TLS connection at the session layer, and the embodiment of this specification does not impose any limitation on this. It should be noted that the node corresponding to the node information maintained in the node list maintained by any node does not necessarily have a physical direct connection with the node, that is, other nodes that have network connections with the node may be connected to the node. There is a multi-hop relationship between any of the nodes.

In the field of blockchain technology, due to the large number of blockchain-related code reuse phenomena, different blockchain networks may use the same P2P network as the underlying communication basis, which ultimately leads to the occurrence of alien attacks. Alien attack is a type of network attack, also known as address pollution attack. It refers to an attack method that induces nodes in different blockchain networks to discover, interconnect, and invade each other. So if an attacker performs a special attack, it may cause nodes in different blockchain networks to become entangled with each other, affecting the communication and routing within the nodes in their respective blockchain networks, and thus affecting the execution of transactions and blocks. The security of the consensus gives attackers the opportunity to carry out other attacks, such as DDoS (Distributed Denial of Service) attacks, network split attacks, etc.

Under normal circumstances, a P2P network will only be specifically connected to one blockchain network, that is, each node in the P2P network will only maintain the same set of blockchain ledgers, and will only be responsible for communicating with the nodes that maintain this set of blockchain ledgers. Serve. The reason why alien attacks occur is essentially because the same P2P network assumes the function of communication services for multiple blockchain networks. That is, in addition to docking with its corresponding dedicated blockchain network, the P2P network also The reuse relationship caused the blockchain network to mistakenly add some nodes from other blockchain networks. This is ultimately reflected in the fact that the nodes in the blockchain network may maintain different blockchain ledgers (because these nodes originally do not belong to the same blockchain network). In response to the above problems, the embodiment of this specification proposes a method to prevent alien attacks. The verification node in the blockchain network initiates an attack to the node to be verified in the blockchain network to verify whether each other maintains the same set of blockchains. Verification request of the ledger, and disconnects from the node to be verified when the number of verification failures reaches the preset threshold, thereby ensuring that the nodes in the blockchain network all belong to the same blockchain network, thus reducing The possibility of encountering alien attacks.

The node in the blockchain network that actively verifies whether other nodes maintain the same set of blockchain ledgers is called a verification node, and the node in the blockchain network that is subject to the above verification is called a node to be verified. In the embodiment of this specification, the verification node can be any node that has joined the blockchain network. The verification node usually needs to ensure that it is trustworthy and open source, and in order to ensure that the verification node maintains the correct Blockchain ledger (to avoid the phenomenon that the verification node itself is a node in other blockchain networks mistakenly added to the blockchain network), the initial node when the blockchain network is first established can be used as the verification node, or the blockchain network can be The communication pillar node (usually has many connections with other nodes in the blockchain network. This node is usually considered a backbone node and has a relatively high probability of maintaining a correct blockchain ledger) as a verification node. . Taking Figure 1 as an example, nodeA can send a verification request to nodeB that has established a connection to verify whether nodeB maintains the same set of blockchain ledgers. At this time, nodeA serves as the verification node, and nodeB serves as the node to be verified.

Please refer to Figure 2. Figure 2 is a flow chart of a method for preventing network attacks provided by an exemplary embodiment. As shown in Figure 2, the method is applied to verification nodes in the blockchain network and may include the following steps 202-208.

Step 202: Send a verification request to the node to be verified in the blockchain network, where the verification request includes the block height of the block to be verified selected by the verification node from locally maintained blocks.

After the verification node determines that it needs to send a verification request to the node to be verified, it first needs to determine a block height to carry in the verification request and serve as the basis for the node to be verified to obtain the first block information. Specifically, the verification node can select a block from the locally maintained blockchain ledger as the block to be verified, and then carry the block height of the block to be verified in the verification request. In the embodiment of this specification, the block to be verified is obtained by the verification node from locally maintained blocks according to preset selection rules or random selection. When the block to be verified is randomly selected by the verification node from the blockchain ledger maintained by itself, the randomness of the verification task can be ensured to the greatest extent and prevent the node to be verified from preparing the block information corresponding to the block height in advance. Temporarily obtain the first block information.

In the embodiment of this specification, sending a verification request to a node to be verified in the blockchain network includes: periodically sending a verification request to a node to be verified in the blockchain network. In the embodiment of this specification, any node in the blockchain network can serve as a verification node and send verification requests to other nodes, and the verification node can also send verification requests to multiple nodes to be verified at the same time. In addition, for each node to be verified, As for the verification node, it can also periodically send verification requests to the node to be verified. When initiating verification requests to different nodes to be verified or sending verification requests periodically, since the corresponding block to be verified needs to be re-selected each time a verification request is generated, the height of the block carried in each verification request is different. Must be the same. When the process of verifying whether the same blockchain ledger is maintained is a universal and continuous behavior in the blockchain network, it can continuously ensure that the nodes in the blockchain network maintain the same blockchain ledger. , belong to the same blockchain network, thus further increasing the overall resistance of the blockchain network to system failures (because the cause of verification failure may also be that the node to be detected is a faulty node) and the ability to prevent alien attacks.

Step 204: Receive a verification response sent by the node to be verified in response to the verification request, where the verification response includes first block information.

After receiving the verification request, the node to be verified will respond to the verification request and obtain the corresponding block height, and locally search for the first block height corresponding to the block height in the blockchain ledger maintained by the node to be verified. block, and at the same time determine the first block information corresponding to the first block, and send the verification response carrying the first block information to the verification node for subsequent verification by the verification node. In the embodiment of this specification, the first block information may include the first block itself or the hash value corresponding to the first block.

At the same time, in order to prove that the first block information obtained by the node to be verified was obtained by the node to be verified by querying the blockchain ledger, it is also necessary to provide the corresponding identity certificate to the verification node to prove the first block. The block information is obtained by the node to be verified. Specifically, after the node to be verified obtains the first block information, it will also generate a corresponding signature for the first block information. This signature is the node private key of the node to be verified that it holds for the first block. The block information is encrypted.

Finally, the node to be verified will send the first block information obtained by itself and the signature generated for the first block information to the verification node for verification by the verification node. Of course, the node to be verified can also send the node to be verified at the same time. The node public key is also sent to the verification node.

Step 206: Determine that the node to be verified fails to verify if the first block information fails to match the second block information corresponding to the block to be verified.

After receiving the verification response sent by the node to be verified, the verification node will obtain the first block information from the verification response. In addition, the verification node also needs to obtain the previously selected block to be verified from the blockchain ledger maintained locally by the verification node, and at the same time determine the second block information corresponding to the block to be verified. The second block information includes the to-be-verified block. block or the hash value corresponding to the block to be verified. For example, when the first block information is the first block, the second block information is the second block, and when the first block information is the When the hash value corresponding to one block is determined, the information of the second block is the hash value corresponding to the second block. The process of the verification node obtaining the second block information can occur at any time point between the verification node selecting the block to be selected and the verification node needing to match the first block information with the second block information.

After the verification node obtains the first block information and the second block information at the same time, it can match the first block information and the second block information to compare whether they are consistent. If the two are consistent, If the comparison is inconsistent, the match is determined to be successful; if the comparison between the two is inconsistent, the match is determined to be failed. If the node to be verified and the verification node maintain the same blockchain ledger, then the blocks they take out at the same block height should be the same, and the corresponding first block information and second block information should also match successfully, and If the final matching of the first block information and the second block information fails, it can mean that the node to be verified and the verification node respectively maintain different blockchain ledgers or the node to be verified has a transmission failure. At this time, it can be determined whether the node to be verified is The verification result of the same set of blockchain ledgers maintained by the verification node is verification failure.

In addition to the above verification method of determining whether the node to be verified has failed to verify by matching the first block information with the second block information, embodiments of this specification also provide other additional verification methods to determine whether the node to be verified has failed to verify. .

Optionally, the method further includes: determining that the node to be verified has failed in verification if the verification response is not received within a first preset time period after sending the verification request. In the embodiment of this specification, the verification node requires the node to be verified to return a verification response within the first preset time period, otherwise it is considered that the verification of the node to be verified has failed, even if the first block information in the subsequent verification response received can Successfully matched with the second block information. Assuming that the node to be verified belongs to the same blockchain network as the verification node, that is, the node to be verified maintains the same blockchain ledger maintained by the verification node, then the way for the node to be verified to obtain the first block information is to obtain the first block information locally based on Searching at block height, the efficiency of this process is theoretically faster; and if the node to be verified does not maintain (or is not fully maintained) a complete blockchain ledger corresponding to the blockchain network where the verification node is located, and It is hoped to obtain the first block information through other means (such as first accessing the public platform of the blockchain network where the verification node is located to query the first block corresponding to the block height), thereby forging that it is at the location of the verification node. The identity of the blockchain network, then this process is more time-consuming than directly searching and obtaining the first block information locally. Therefore, the length of time for the node to be verified to return the verification response can be limited to identify those attackers who attempt to forge their true identity through the above methods, and then the node to be verified will be regarded as The attacker also determines that the node to be verified has failed to verify, thereby avoiding as much as possible the node to be verified as the attacker using other means to avoid verification failure or increasing the attack cost of the attacker, thereby improving the blockchain network's ability to prevent network attacks.

Optionally, the verification response also includes a signature generated by the node to be verified for the first block information, and the method further includes: verifying the signature based on the node public key of the node to be verified, in If the signature verification fails, it is determined that the node to be verified fails to verify. As mentioned above, the node to be verified can also provide the verification node with the signature of the first block information to prove its identity. When the verification node verifies the signature, it needs to use the node public key of the node to be verified that is maintained in advance by itself or temporarily provided by the node to be verified, and the obtained decryption result is compared with the first block The information is compared. If the comparison is consistent, it means that the source of the first block information is indeed the node to be verified, thereby determining that the signature verification is successful. If the comparison is inconsistent, it means the source of the first block information. The party is not the node to be verified, thereby determining that the signature verification fails. If the signature verification fails, it is deemed to be verified by the node to be verified, thereby preventing the node to be verified as an attacker from forging its identity. Avoiding verification failure or increasing the attack cost of the attacker improves the ability of the blockchain network to prevent network attacks.

Step 208: If it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, disconnect the node to be verified.

The verification node will count the total number of verification failures (the first number) of the node to be verified. When the first number of verification failures in the history of the node to be verified exceeds the first preset threshold, the verification node can completely Confirm that it does not belong to the same blockchain network as the node to be verified, so it is necessary to disconnect the node to be verified to exit the node to be verified from the blockchain network to ensure that the P2P network is only connected to the same area The nodes in the blockchain network only maintain the same set of blockchain ledgers to prevent the blockchain network from being attacked by aliens. In addition, since the embodiments of this specification need to disconnect the connection with the node to be verified only after the verification failure reaches a certain threshold, a certain fault-tolerant mechanism is also maintained to minimize the possibility of accidentally leaving a temporarily faulty normal node out of the area. Blockchain networks lead to the possibility of manslaughter.

Optionally, it also includes: when it is determined that the first number of verification failures of the node to be verified exceeds a first preset threshold, removing the node information of the node to be verified from the node list maintained by the verification node. delete. As mentioned before, each node in the blockchain network maintains a node list to store node information of other nodes that are connected to the node. In the embodiment of this specification, since the verification node and the node to be verified have previously established a connection, the node information of the node to be verified is stored in the node list of the verification node. When it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, the verification node will disconnect from the node to be verified, and at the same time, the verification node will also maintain the node list in its own maintenance node list. Delete the previously existing node information of the node to be verified so that the node to be verified is forgotten and the storage space of the node list is released.

Optionally, the method further includes: when it is determined that the first number of verification failures of the node to be verified exceeds a first preset threshold, initiating a verification process including the verification to the network management contract in the blockchain network. The node deletion transaction of the node information of the node to be verified causes the network management contract to delete the node information of the node to be verified maintained in the network management contract. In the embodiment of this specification, the network management contract deployed by the blockchain network maintains the node information of each blockchain node as all members of the blockchain network (including the node information of the node to be verified). Therefore, when determining the need When the node to be verified exits the blockchain network (that is, the node to be verified is verified and does not belong to the blockchain network), the verification node can also initiate a node deletion transaction to the network management contract to make the network management contract Delete the node information maintained on the node to be verified in the network management contract to ensure the correctness of the node members in the blockchain node.

Optionally, it also includes: when it is determined that the first number of failed verifications of the node to be verified exceeds a first preset threshold, sending a message carrying the node to be verified to other nodes in the blockchain network. Suspicious node notification of node information, so that the other nodes send a verification request to the node to be verified in response to the suspicious node notification. In the embodiment of this specification, when the number of verification failures of the node to be verified for the first time exceeds the first preset threshold, the verification node will not only disconnect from the node to be verified, but will also further notify the node with a suspicious node. Inform other nodes in the blockchain network in a way so that these other nodes can also know that the node to be verified may belong to other blockchain networks, and then send verification requests to the node to be verified as the identity of the verification node. , that is, perform the aforementioned steps 202 to 208 respectively, and again initiate the verification process to the node to be verified as to whether it maintains the same blockchain ledger as the other nodes, so that each node in the blockchain network can gradually Disconnecting the connection with the node to be verified will ultimately have the effect of causing the node to be verified that has failed to be verified multiple times to completely exit the blockchain network. The suspicious node notification mechanism involved in the embodiment of this specification improves the efficiency of the blockchain. The ability of the network as a whole to prevent cyber attacks.

Optionally, it also includes: when it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, refusing to respond to the node to be verified within a third preset time period after the current moment. The connection request sent. In the embodiment of this specification, when it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, in addition to needing to disconnect from the node to be verified, the node to be verified can also be disconnected. The node is added to the connection blacklist so that it cannot establish a connection with the verification node again within a period of time, thereby preventing the node to be verified as an attacker from continuing to harass the verification node by initiating connection requests. The node information of the node in the connection blacklist involved in the embodiment of this specification will be automatically deleted after the third preset time period after being added. Therefore, after the third preset time period after disconnecting from the node to be verified, , the node to be verified can still establish a connection with the verification node again by initiating a connection request to the verification node.

Optionally, the block to be verified is selected by the verification node from blocks in a selection range corresponding to the locally maintained verification difficulty value, and the selection range is directly related to the verification difficulty value; the method further includes: The verification difficulty value is adjusted according to the second number of verification failures of the node to be verified within a second preset time period before the current time, and the verification difficulty value is positively related to the second number of times. In the embodiment of this specification, it is considered that the node to be verified as the attacker may also locally maintain the same blockchain ledger as the verification node through other means so as to be able to find the correct first block information and avoid verification failure. , but due to the cost of attack, a complete blockchain ledger may not be maintained locally (like a normal node). Therefore, in the embodiment of this specification, the selection range of the blocks to be verified is determined to varying degrees according to the verification difficulty value. Adjustment, so that in the case of high verification difficulty value, the node to be verified as the attacker must locally maintain a sufficient number of blocks in the same blockchain ledger as the verification node to avoid verification failure, thereby indirectly increasing attacks Party’s attack cost. At the same time, the verification difficulty value maintained by the verification node can be dynamically adjusted, for example, based on the recently determined second number of verification failures of the node to be verified (that is, the node to be verified is determined within the second preset time period before the current time). The second number of failed verifications) is used to adjust the verification difficulty value. Since the second number of times objectively reflects the possibility that the node to be verified is an attacker, the embodiments of this specification can make the possibility of the node to be verified being an attacker In higher cases, increase the verification difficulty of the node to be verified (requiring the node to be verified to maintain more blocks in the correct blockchain ledger) to further increase the cost of the attacker's network attack by circumventing verification failures. , to further improve the blockchain network’s ability to prevent cyber attacks. In addition, since the adjustment of the verification difficulty value is carried out dynamically, for example, when the number of verification failures of the verification node in the near future decreases, the current verification difficulty value can be appropriately reduced, so that the possibility of the node being verified as an attacker is lower. Reduce the cost required for normal verification behavior (when the selection range of the block to be verified is small, the range that the node to be verified needs to search when obtaining the first block information is also small, so the time and computing cost required smaller).

Optionally, the network management contract deployed by the blockchain network maintains the verification difficulty value; the adjustment is based on the second number of verification failures of the node to be verified determined within a second preset time period before the current time. The verification difficulty value includes: initiating a difficulty value adjustment transaction including a second number of times to the network management contract deployed on the blockchain network, so that the network management contract is maintained in the network management contract based on the second number of adjustments. The verification difficulty value in .

In the embodiment of this specification, the verification difficulty value maintained by the verification node is specifically stored in the network management contract deployed by it. Therefore, in this case, each blockchain node in the blockchain network actually shares the same verification difficulty value by maintaining the same network management contract, which allows any one of the blockchain nodes to detect When a certain node to be verified is more likely to be an attacker, the verification difficulty value maintained in the network management contract is adjusted by initiating a proof difficulty value adjustment transaction to the network management contract to provide support to the blockchain network. Other blockchain nodes inform the changes in the verification difficulty value when performing verification actions on the node to be verified, so that the blockchain network has the function of overall adjusting the verification strategy of all nodes according to changes in the current network environment, improving the blockchain network Overall ability to protect against cyberattacks.

Optionally, it also includes: when the number of historical messages based on any protocol initiated by the same initiator received within a fourth preset time period before the current moment exceeds a second preset threshold, refuse to respond to the same Messages initiated by the initiator based on any of the protocols described. The messages of any of the protocols include at least a connection request in the connection protocol, a node discovery request in the node discovery protocol, and a verification response in the verification protocol to verify whether the same set of blockchain ledgers is maintained (mainly to prevent the node to be verified from targeting the same A verification request returns an excessive number of verification responses, causing the verification node to crash), etc. The embodiments of this specification do not limit the type of protocol, but the protocol must be pre-established and maintained in the blockchain network so that the blockchain network Nodes in can identify and process messages corresponding to this protocol. Through the embodiments of this specification, it is possible to count received messages of various protocols (including various types of requests or responses), and in the case where there are too many historical messages of a certain type of protocol originating from the same initiator in a short period of time. , refuse to respond to messages of this type of protocol from the same initiator again, thereby effectively identifying the attacker and moving it into the blacklist, effectively preventing the same attacker such as flooding attacks or DOS (Denial of Service, Denial of Service) attacks. A network attack method through excessive sending of messages.

Figure 3 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to Figure 3. At the hardware level, the device includes a processor 302, an internal bus 303, a network interface 306, a memory 308 and a non-volatile memory 310. Of course, it may also include other hardware required for services. One or more embodiments of this specification may be implemented based on software. For example, the processor 302 reads the corresponding computer program from the non-volatile memory 310 into the memory 308 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution party of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.

As shown in Figure 4, Figure 4 is a block diagram of a device for preventing network attacks provided in this specification according to an exemplary embodiment. This device can be applied to the equipment shown in Figure 3 to implement the technical solution of this specification. . The device is applied to verification nodes in a blockchain network and includes: a request sending unit 401, used to send a verification request to a node to be verified in the blockchain network, where the verification request includes the verification node maintaining locally The block height of the block to be verified selected from the block; the response receiving unit 402 is used to receive the verification response sent by the node to be verified in response to the verification request, where the verification response includes the first block information; The verification unit 403 is used to determine that the node to be verified fails to verify when the first block information fails to match the second block information corresponding to the block to be verified; the connection disconnecting unit 404 is used to determine If the first number of verification failures of the node to be verified exceeds the first preset threshold, the connection with the node to be verified is disconnected.

Optionally, the request sending unit 401 is specifically configured to periodically send verification requests to the nodes to be verified in the blockchain network.

Optionally, the second block information includes the block to be verified or the hash value corresponding to the block to be verified.

Optionally, the block to be verified is obtained by the verification node from locally maintained blocks according to preset selection rules or random selection.

Optionally, the block to be verified is selected by the verification node from blocks in a selection range corresponding to the locally maintained verification difficulty value, and the selection range is directly related to the verification difficulty value; the device further includes: The difficulty value adjustment unit 405 is configured to adjust the verification difficulty value according to the second number of failed verifications of the node to be verified within a second preset time period before the current time. The verification difficulty value is positively related to the second number of verification failures. .

Optionally, the network management contract deployed on the blockchain network maintains the verification difficulty value; the difficulty value adjustment unit 405 is specifically configured to: initiate a second verification process to the network management contract deployed on the blockchain network. The number of difficulty value adjustment transactions is such that the network management contract adjusts the verification difficulty value maintained in the network management contract based on the second number of times.

Optionally, the method also includes: a verification failure determination unit 406, configured to determine that the node to be verified has failed in verification if the verification response is not received within a first preset time period after sending the verification request.

Optionally, the verification response also includes a signature generated by the node to be verified for the first block information, and the device further includes: a signature verification unit 407 for verifying the signature based on the node public key of the node to be verified. The signature is verified, and if the signature verification fails, it is determined that the node to be verified has failed to verify.

Optionally, it also includes: a list information deletion unit 408, configured to remove the node information of the node to be verified from all the nodes when it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold. Delete from the node list maintained by the verification node.

Optionally, it also includes: a node deletion transaction sending unit 409, configured to send a message to the network in the blockchain network when it is determined that the first number of failed verifications of the node to be verified exceeds the first preset threshold. The management contract initiates a node deletion transaction containing the node information of the node to be verified, so that the network management contract deletes the node information of the node to be verified maintained in the network management contract.

Optionally, it also includes: a suspicious node notification sending unit 410, configured to notify other nodes in the blockchain network when it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold. The node sends a suspicious node notification carrying the node information of the node to be verified, so that the other nodes send a verification request to the node to be verified in response to the suspicious node notification.

Optionally, the node information includes node identification, node public key and/or network address.

Optionally, it also includes: a connection request rejection unit 411, configured to, if it is determined that the first number of failed verifications of the node to be verified exceeds the first preset threshold, a third preset time period after the current moment. Refuse to respond to the connection request sent by the node to be verified.

Optionally, it also includes: a response rejection unit 412, used to receive the number of historical messages based on any protocol initiated by the same initiator within the fourth preset time period before the current moment exceeding the second preset threshold. , refuse to respond to messages based on any of the protocols initiated by the same initiator.

In the 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented using hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing, and before compilation The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but there are many, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The two are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present invention does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps listed in the embodiment is only one way of executing the sequence of many steps, and does not represent the only execution sequence. When the actual device or terminal product is executed, it can be executed sequentially or in parallel according to the methods shown in the embodiments or figures (such as a parallel processor or a multi-thread processing environment, or even a distributed data processing environment). The terms "comprises," "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process, method, product or apparatus including a list of elements includes not only those elements but also others not expressly listed elements, or also elements inherent to the process, method, product or equipment. Without further limitation, it does not exclude the presence of additional identical or equivalent elements in a process, method, product or apparatus including the stated elements. For example, if the words "first" and "second" are used to express names, they do not indicate any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

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 a 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 a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape disk storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.

One or more embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "an example," "specific examples," or "some examples" or the like means that specific features are described in connection with the embodiment or example. , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. To those skilled in the art, various modifications and changes may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A method to prevent network attacks, applied to verification nodes in a blockchain network, including:

Send a verification request to the node to be verified in the blockchain network, where the verification request includes the block height of the block to be verified selected by the verification node from the locally maintained blocks;

Receive a verification response sent by the node to be verified in response to the verification request, where the verification response includes first block information;

In the case where the first block information fails to match the second block information corresponding to the block to be verified, it is determined that the node to be verified fails to verify;

When it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, the connection with the node to be verified is disconnected.
The method according to claim 1, sending a verification request to a node to be verified in the blockchain network includes:

Verification requests are periodically sent to the nodes to be verified in the blockchain network.
According to the method of claim 1, the second block information includes the block to be verified or the hash value corresponding to the block to be verified.
According to the method of claim 1, the block to be verified is obtained by the verification node from locally maintained blocks according to preset selection rules or random selection.
According to the method of claim 1, the block to be verified is selected by the verification node from blocks in a selection range corresponding to the locally maintained verification difficulty value, and the selection range is directly related to the verification difficulty value; The above methods also include:

The verification difficulty value is adjusted according to the second number of verification failures of the node to be verified within a second preset time period before the current time, and the verification difficulty value is positively related to the second number of times.
The method according to claim 5, the network management contract deployed by the blockchain network maintains the verification difficulty value; the verification failure of the node to be verified is determined based on the second preset time period before the current time. The second number of adjustments to the verification difficulty value include:

Initiate a difficulty value adjustment transaction including a second number of times to the network management contract deployed on the blockchain network, so that the network management contract adjusts the verification difficulty value maintained in the network management contract based on the second number of times.
The method of claim 1, further comprising:

If the verification response is not received within a first preset time period after sending the verification request, it is determined that the node to be verified has failed to verify.
The method according to claim 1, the verification response further includes a signature generated by the node to be verified for the first block information, the method further includes:

The signature is verified based on the node public key of the node to be verified, and if the signature verification fails, it is determined that the node to be verified fails to verify.
The method of claim 1, further comprising:

When it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, the node information of the node to be verified is deleted from the node list maintained by the verification node.
The method of claim 1, further comprising:

When it is determined that the first number of failed verifications of the node to be verified exceeds the first preset threshold, initiate a node deletion transaction containing the node information of the node to be verified to the network management contract in the blockchain network , so that the network management contract deletes the node information of the node to be verified maintained in the network management contract.
The method of claim 1, further comprising:

When it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, sending a suspicious node notification carrying the node information of the node to be verified to other nodes in the blockchain network , so that the other nodes send a verification request to the node to be verified in response to the suspicious node notification.
According to the method of claim 9, 10 or 11, the node information includes node identification, node public key and/or network address.
The method of claim 1, further comprising:

If it is determined that the first number of verification failures of the node to be verified exceeds the first preset threshold, refuse to respond to the connection request sent by the node to be verified within a third preset time period after the current time.
The method of claim 1, further comprising:

When the number of historical messages initiated by the same initiator based on any protocol received within the fourth preset time period before the current moment exceeds the second preset threshold, refuse to respond to the historical messages initiated by the same initiator based on the said messages for any protocol.
A device to prevent network attacks, applied to verification nodes in the blockchain network, including:

A request sending unit, configured to send a verification request to the node to be verified in the blockchain network, where the verification request includes the block height of the block to be verified selected by the verification node from the locally maintained blocks;

A response receiving unit configured to receive a verification response sent by the node to be verified in response to the verification request, where the verification response includes first block information;

A verification unit configured to determine that the verification of the node to be verified fails when the first block information fails to match the second block information corresponding to the block to be verified;

A connection disconnecting unit, configured to disconnect from the node to be verified when it is determined that the first number of failed verifications of the node to be verified exceeds a first preset threshold.
An electronic device including a processor and a memory for storing instructions executable by the processor;

Wherein, the processor implements the method according to any one of claims 1 to 14 by running the executable instructions.
A computer-readable storage medium having computer instructions stored thereon, which when executed by a processor, implements the steps of the method according to any one of claims 1 to 14.