A method and device for preventing cyberattacks

Abstract

This specification provides a method and apparatus for preventing network attacks, applied to an access node in a blockchain network. The method includes: receiving a connection request sent by a requesting node; sending a proof-of-work request to the requesting node, the proof-of-work request including a random number for generating a proof-of-work task; receiving an execution result obtained by the requesting node in response to the proof-of-work request by executing the proof-of-work task and a signature generated for the execution result; verifying the signature based on the requesting node's public key and verifying the proof-of-work task based on the execution result; and establishing a connection with the requesting node if the signature verification is successful and the proof-of-work task is verified.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of network security technology, and in particular relate to a method and apparatus for preventing network attacks. Background Technology

[0002] Currently, attacks targeting communication networks are rampant, with various attack methods employed. Among these, attacks targeting P2P networks are particularly common. For example, with blockchain networks, attackers can design attack algorithms based on the characteristics of the underlying P2P network, thereby achieving their goal of attacking the blockchain network. Summary of the Invention

[0003] The purpose of this invention is to provide a method and apparatus for preventing network attacks.

[0004] According to a first aspect of one or more embodiments of this specification, a method for preventing network attacks is proposed, applied to an access node in a blockchain network, comprising:

[0005] Receive a connection request sent by a requesting node, and send a proof-of-work request to the requesting node, wherein the proof-of-work request includes a random number for generating a proof-of-work task;

[0006] The requesting node receives the execution result of the proof-of-work task obtained by executing the proof-of-work request in response to the proof-of-work request, and the signature generated for the execution result;

[0007] The signature is verified based on the public key of the requesting node, and the proof-of-work task is verified based on the execution result.

[0008] If the signature verification is successful and the proof-of-work task is verified, a connection is established with the requesting node.

[0009] According to a second aspect of one or more embodiments of this specification, an apparatus for preventing network attacks is provided, applied to an access node in a blockchain network, comprising:

[0010] A request receiving unit is used to receive a connection request sent by a requesting node and send a proof-of-work request to the requesting node. The proof-of-work request includes a random number for generating a proof-of-work task.

[0011] The result receiving unit is configured to receive the execution result obtained by the requesting node in response to the proof-of-work request and the signature generated for the execution result;

[0012] The result verification unit is used to verify the signature based on the public key of the requesting node, and to verify the proof-of-work task based on the execution result.

[0013] The connection establishment unit is used to establish a connection with the requesting node when the signature verification is successful and the proof of work task is verified.

[0014] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0015] processor;

[0016] Memory used to store processor-executable instructions;

[0017] The processor implements the method as described in the first aspect by running the executable instructions.

[0018] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0019] Based on the aforementioned embodiments of this specification, a connection establishment mechanism that requires additional computing power is proposed. The requesting node needs to provide identity verification and the execution result obtained after performing the proof-of-work task to the access node in the blockchain network, and can only establish a connection with the access node after being verified by the access node. This increases the computing and time costs required for attackers to intrude into the blockchain network, thereby limiting attackers from launching large-scale attacks by establishing a large number of connections with the blockchain network in a short period of time, and improving the blockchain network's ability to prevent network attacks. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of a blockchain network provided in an exemplary embodiment.

[0022] Figure 2 This is a flowchart illustrating a method for preventing network attacks, provided in an exemplary embodiment.

[0023] Figure 3 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0024] Figure 4 This is a block diagram of an apparatus for preventing network attacks, provided in an exemplary embodiment. Detailed Implementation

[0025] 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0026] A P2P (Peer-to-Peer) network, also known as a peer-to-peer network, is a distributed network distinct from the client / server (C / S) model. In a P2P network, all nodes are equal to each other, and each node can act as both a client and a server, providing resources and services to other nodes. For example, a blockchain network is a typical P2P network. The P2P network described in the embodiments of this specification can be a blockchain network, and the nodes included in the P2P network are all blockchain nodes within that blockchain network.

[0027] Figure 1 This is a schematic diagram of a blockchain network provided in an exemplary embodiment. (As shown) Figure 1As shown, the blockchain network contains five nodes: nodeA, nodeB, nodeC, nodeD, and nodeE. These five nodes are not fully connected; for example, nodeA is only connected to nodeB, nodeC, and nodeD, but not to nodeE. Each node maintains its own independent node list, which records the node information of other nodes in the same blockchain network that are connected to it. Therefore, this node list is also called a neighbor table. For example, nodeA's node list records the node information of nodeB, nodeC, and nodeD. Furthermore, from a functional perspective, this node list can also serve as a routing table to guide message transmission. In the embodiments of this specification, the node information of any node may include the node identifier, network address (such as IP address, port number, etc.), and / or the node's identity information (such as node public key), etc., and this specification does not limit this. The connection mentioned in the embodiments of this specification refers to a network connection, such as a session-layer TCP or TLS connection, etc., and this specification does not impose any limitations on this. It is important to note that the nodes maintained in the node list maintained by any node may not necessarily have a direct physical connection with that node. That is, other nodes that have established network connections with that node may have a multi-hop relationship with that node.

[0028] In a blockchain network, the node responsible for connecting new nodes or establishing new connections is called an access node. If a new node outside the blockchain network wishes to join, it needs to apply to an access node within that blockchain network. After the application is approved, it establishes a connection with the access node and joins the blockchain network where the access node resides. In the embodiments of this specification, an access node can be any node already joined in the blockchain network. Access nodes typically need to ensure that they are trustworthy and open-source. For example, the initial node used when the blockchain network was first established can be used as an access node, or a communication backbone node in the blockchain network (which usually has many connections with other nodes in the blockchain network) can be used as an access node. Figure 1 For example, nodeF, which is not part of the blockchain network, can send a network access request to nodeE in the blockchain network to apply to join the blockchain network. In this case, nodeE acts as an access node of the blockchain network, while nodeF acts as a requesting node. Alternatively, nodeA, which has not established a connection with nodeE, can send a connection request to nodeE to apply to establish a connection with nodeE. In this case, nodeE also acts as an access node of the blockchain network, while nodeA acts as a requesting node.

[0029] Please see Figure 2 , Figure 2This is a flowchart illustrating a method for preventing network attacks, as provided in an exemplary embodiment. Figure 2 As shown, the method is applied to access nodes in a blockchain network and may include the following steps 202-208.

[0030] Step 202: Receive the connection request sent by the requesting node, and send the proof-of-work request to the requesting node. The proof-of-work request includes a random number for generating the proof-of-work task.

[0031] The requesting node involved in the embodiments of this specification may include a node in the blockchain network that has not established a connection with the access node, or a node that is not currently part of the blockchain network. When the requesting node is not part of the blockchain network, i.e., is not a node in the blockchain network, the connection request here is also called a network entry request.

[0032] In response to a connection request from a requesting node, the access node sends a proof-of-work request to the requesting node. This request instructs the requesting node to generate and execute a corresponding proof-of-work task, and ultimately returns the execution result to the access node. To ensure the randomness of the proof-of-work task and prevent the requesting node from obtaining the execution result in advance instead of executing the task on the fly, a random number is provided to the requesting node to generate a random proof-of-work task. Additionally, the proof-of-work request may include a proof difficulty value used to generate the task, thus guiding the requesting node to execute the task according to the corresponding difficulty value.

[0033] Step 204: Receive the execution result obtained by the requesting node in response to the proof-of-work request by executing the proof-of-work task, and the signature generated for the execution result.

[0034] Upon receiving a proof-of-work request, the requesting node first generates a corresponding proof-of-work task based on the included random number. This task involves continuously constructing a string (or a string composed of the requesting node's public key, random numbers, and the pending value in a preset order) by repeatedly changing the pending value. Simultaneously, it calculates the hash value of this string. If the hash value satisfies a specific formal rule, the determined pending value in that string is taken as the result of the proof-of-work task. This specific formal rule might include, for example, the hash value starting or ending with several consecutive identical characters (such as "0"). The number of consecutive identical characters required depends on the proof difficulty value of the task; a higher difficulty value requires more consecutive identical characters. It's easy to understand that a higher difficulty value results in higher computational and time costs for executing the proof-of-work task and obtaining the final result.

[0035] The aforementioned proof-of-work task utilizes the irreversible nature of hash operations and the lack of a pattern between the output and input values. It requires the prover to obtain the final execution result only by exhaustively listing the undetermined values. Therefore, the requesting node, as the prover, needs to consume additional computing power to establish a connection with the access node, which increases the cost of establishing a connection for the requesting node.

[0036] Meanwhile, to prove that the execution result was obtained by the requesting node itself performing the proof-of-work task, it also needs to provide corresponding identity verification to the access node. Specifically, after receiving the execution result, the requesting node will generate a corresponding signature for the execution result. This signature is obtained by encrypting the execution result using the requesting node's private key.

[0037] Finally, the requesting node will send the execution result it obtained and the signature generated for the execution result to the access node for verification. Of course, the requesting node can also send its own public key to the access node at the same time.

[0038] Step 206: Verify the signature based on the public key of the requesting node, and verify the proof-of-work task based on the execution result.

[0039] When verifying the signature, the access node needs to decrypt the signature using its own pre-maintained public key or the public key of the requesting node temporarily provided by the requesting node. The decryption result is then compared with the execution result. If the comparison matches, it means that the source of the execution result is indeed the requesting node, thus confirming that the signature verification is successful. If the comparison does not match, it means that the source of the execution result is not the requesting node, thus confirming that the signature verification fails.

[0040] When an access node verifies the proof-of-work task, its actual process is similar to that of the requesting node executing the proof-of-work task. First, it generates a string to be verified based on the execution result and the random number. Then, it performs a hash operation on the string to obtain the corresponding hash result. Finally, if the hash result satisfies the proof-of-work requirement corresponding to the proof difficulty value, the proof-of-work task is deemed to have passed verification; otherwise, it is deemed to have failed verification. For example, if the proof difficulty value maintained by the access node requires the hash result to meet the proof-of-work requirement of starting with eight consecutive "0" characters, then the proof-of-work task is considered to have passed verification only if the hash result indeed starts with eight consecutive "0" characters, meaning the requesting node has correctly and compliantly executed the proof-of-work task. As mentioned earlier, to enable the requesting node to provide an execution result that satisfies the proof-of-work requirement corresponding to the proof difficulty value, the proof-of-work request may also include a proof difficulty value for generating the proof-of-work task, so that the requesting node fully considers this proof difficulty value when generating the proof-of-work task and generates an execution result that satisfies the proof difficulty requirement based on this value.

[0041] Optionally, generating the string to be verified based on the execution result and the random number includes: combining the execution result, the random number, and the public key of the request node in a preset order to generate the string to be verified. In the embodiments of this specification, the string constructed in the above-mentioned proof-of-work task may also include the public key of the request node, which can further realize a strong binding between the request node and the execution result, thereby more effectively proving that the execution result originates from the request node corresponding to the public key in the string. Since verifying the proof-of-work task is essentially the same as executing the proof-of-work task, the string to be verified should also be generated according to the same construction rules described above and further verified during the verification of the proof-of-work task.

[0042] In the embodiments of this specification, the process of verifying the signature based on the public key of the requesting node and the process of verifying the proof-of-work task based on the execution result can be independent processes. That is, there is no necessary execution order between the two processes; they can be executed sequentially or simultaneously. This embodiment of the specification does not impose any restrictions on this. Optionally, verifying the proof-of-work task based on the execution result includes: verifying the proof-of-work task based on the execution result if the signature verification is successful. It is worth mentioning that in the embodiments of this specification, the process of the access node verifying the proof-of-work task can be executed after the signature verification is successful. In this way, if the signature verification fails, there is no need to further execute the verification process of the relatively more time-consuming proof-of-work task, thereby saving the computing resources of the access node to a certain extent. It can also prevent attackers from forcing the access node to execute a large number of computationally intensive signature verification / verification tasks in a short period of time by sending excessive execution results and their signatures, thus causing the access node to crash. This has a certain effect of preventing network attacks.

[0043] Optionally, it also includes: adjusting the proof difficulty value based on the number of proof-of-work verification failures within a first preset time period prior to the current time, wherein the proof difficulty value is positively correlated with the number of failures, and the number of failures is the sum of the number of signature verification failures and the number of proof-of-work task verification failures within the first preset time period prior to the current time.

[0044] In the embodiments of this specification, the access node maintains a proof difficulty value, which can be adjusted based on the number of recent costless access attempts (i.e., the aforementioned signature verification failures or proof-of-work task verification failures). The number of costless access attempts is the number of proof-of-work verification failures, which is the sum of the number of signature verification failures and the number of proof-of-work task verification failures (i.e., for each connection request, if the signature verification or proof-of-work task verification provided by the requesting node fails, the count is incremented by one). When calculating this count, for each connection request, the execution result and signature provided by the requesting node may result in both signature verification failure and proof-of-work task verification failure. In this case, only the number of proof-of-work verification failures is counted as one (not two), thus avoiding duplicate counting and ensuring the count is higher than the actual value. Since the number of costless access attempts objectively reflects the intensity of network attacks encountered by the blockchain network, the embodiments of this specification can increase the cost for new requesting nodes to establish connections when the blockchain network encounters a network attack, further increasing the cost for attackers to conduct network attacks by establishing a large number of connections with the blockchain network, and further improving the blockchain network's ability to defend against network attacks. In addition, since the adjustment of the proof difficulty value is dynamic, for example, when the number of costless access attempts decreases recently, the current proof difficulty value can be appropriately reduced, thereby reducing the cost required for normal access attempts without encountering network attacks and minimizing the phenomenon of "false positives".

[0045] Optionally, the network management contract deployed in the blockchain network maintains the proof difficulty value; adjusting the proof difficulty value based on the number of proof-of-work verification failures within a first preset time period prior to the current moment includes: initiating a proof difficulty value adjustment transaction containing the number of failures to the network management contract deployed in the blockchain network, so that the network management contract adjusts the proof difficulty value maintained in the network management contract based on the number of failures.

[0046] In the embodiments described in this specification, the proof difficulty value maintained by the access node is specifically stored in its deployed network management contract. Therefore, in this case, each blockchain node in the blockchain network actually shares the same proof difficulty value by maintaining the same network management contract. This allows any blockchain node to adjust the proof difficulty value maintained in the network management contract by initiating a proof difficulty adjustment transaction when a network attack is detected. This informs other blockchain nodes in the blockchain network of the change in proof difficulty value, enabling the blockchain network to adjust the access strategy of all nodes as a whole according to changes in the current network environment, thereby improving the overall ability of the blockchain network to defend against network attacks.

[0047] Step 208: If the signature verification is successful and the proof of work task is verified, establish a connection with the requesting node.

[0048] Based on the aforementioned embodiments of this specification, a connection establishment mechanism that requires additional computing power is proposed. The requesting node needs to provide identity verification and the execution result obtained after performing the proof-of-work task to the access node in the blockchain network, and can only establish a connection with the access node after being verified by the access node. This increases the computing and time costs required for attackers to intrude into the blockchain network, thereby limiting attackers from launching large-scale attacks by establishing a large number of connections with the blockchain network in a short period of time, and improving the blockchain network's ability to prevent network attacks.

[0049] If the requesting node belongs to the blockchain network, the access node will only establish a connection with it after confirming successful signature verification and successful proof-of-work task verification. If the requesting node does not belong to the blockchain network, the method further includes adding the requesting node to the blockchain network after successful signature verification and successful proof-of-work task verification. In this embodiment, if the requesting node itself does not belong to the blockchain network, the access node will by default add the requesting node to the blockchain network after confirming successful signature verification and successful proof-of-work task verification. Because this embodiment requires additional computing power to add a new node to the blockchain network, it increases the cost of Sybil attacks (where an attacker deploys multiple nodes with legitimate identities in a P2P network such as a blockchain), indirectly limiting the intensity of Sybil attacks and improving the blockchain network's ability to defend against network attacks.

[0050] Specifically, adding the requesting node to the blockchain network includes: storing the requesting node's node information in a node list maintained by the access node, and sending the access node's node information to the requesting node. As mentioned above, each node in the blockchain network maintains a node list to store node information of other nodes connected to that node. In this embodiment, the access node first stores the requesting node's node information in its maintained node list. Simultaneously, the access node sends its own node information to the requesting node, informing it that it has successfully joined the blockchain network. The requesting node then creates its own maintained node list and stores the access node's node information within it. After a requesting node joins the blockchain network through an access node, it initially only knows about that access node. If it needs to discover other nodes in the blockchain network and establish connections with them, it needs to send a node discovery request to the access node. The access node then responds by returning a list of nodes it maintains. The access node, through this list, learns about other nodes in the blockchain network and establishes connections with them, sending new node discovery requests. Theoretically, iterating this process can enable a newly joined requesting node to know about all nodes in the blockchain network and establish connections with all of them. Figure 1 Taking nodeF joining the blockchain network through nodeE as an example, nodeF first sends a node discovery request to nodeE to obtain the node list maintained by nodeE. From this node list, nodeF obtains the node information of nodeB and nodeD, which are connected to nodeE. Based on this, nodeF then establishes connections with nodeB and nodeD respectively and sends node discovery requests to each, thereby further obtaining the node lists maintained by nodeB and nodeD. By repeating the above process, nodeF can eventually obtain the node information of all nodes in the blockchain network and, theoretically, can also establish connections with all nodes.

[0051] Optionally, adding the requesting node to the blockchain network includes: initiating a node joining transaction containing the node information of the requesting node to the network management contract in the blockchain network, so that the network management contract maintains the node information of the requesting node. In the embodiments of this specification, the network management contract deployed in the blockchain network maintains the node information of each blockchain node that is a member of the blockchain network. Therefore, after a new node (requesting node) joins, the access node can also initiate a node joining transaction to the network management contract to update and maintain the node information of the requesting node in the network management contract.

[0052] Optionally, the node identifier of the requesting node is generated by the access node, or the node identifier of the requesting node is generated by the requesting node itself. Specifically, when the node identifier of the requesting node is generated by the access node, the access node generates it upon successful signature verification and successful verification of the proof-of-work task. This avoids generating a node identifier every time a connection request is received, reducing the computational burden on the access node. It also prevents attackers from forcing the access node to perform a large number of computationally intensive node identifier generation tasks in a short period of time by sending an excessive number of connection requests, thus causing the access node to crash. This provides a certain degree of protection against network attacks. Optionally, the node identifier of the requesting node is generated by hashing the node's public key. Therefore, the global uniqueness of the node identifier of each node can be ensured by the global uniqueness of the node's public key, provided that no hash collision occurs.

[0053] Optionally, it further includes: if it detects that the node identifier of the requesting node is not globally unique in the blockchain network, sending a node identifier provision request to the requesting node or generating a globally unique first node identifier in the blockchain network to re-determine it as the node identifier of the requesting node. The node identifier provision request is used to cause the requesting node to re-provide a second node identifier to the access node to re-determine it as the node identifier of the requesting node. In the embodiments of this specification, if the access node finds that the node identifier of the requesting node is duplicated with the node identifier of an existing node in the blockchain network, it will regenerate a new node identifier to be used as the node identifier of the requesting node again, or require the requesting node to provide a new node identifier to be used as the node identifier of the requesting node again, thereby ensuring that the node identifiers of each node in the blockchain network are globally unique.

[0054] Optionally, it also includes: if the number of historical messages initiated by the same initiator based on any protocol received within a second preset time period prior to the current time exceeds a preset threshold, refuse to respond to messages initiated by the same initiator based on any protocol. Messages of any protocol include at least connection requests in connection protocols, node discovery requests in node discovery protocols, etc. This specification embodiment does not limit the type of protocol, but the protocol must be pre-established and maintained in the blockchain network so that nodes in the blockchain network can identify and process messages corresponding to that protocol. Through this specification embodiment, by statistically analyzing received messages of various protocols (including various requests or responses), and if historical messages of a certain type of protocol from the same initiator are excessive in a short period, refuse to respond to messages of that type of protocol from the same initiator again, thereby effectively identifying the attacker and adding them to a blacklist, effectively preventing network attacks such as flooding attacks or Denial of Service (DOS) attacks where the same attacker sends excessive amounts of messages.

[0055] Figure 3 This is a schematic structural diagram of a device provided in 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, memory 308, and non-volatile memory 310, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 302 reading the corresponding computer program from the non-volatile memory 310 into memory 308 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the executor of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0056] like Figure 4 As shown, Figure 4 This is a block diagram of an apparatus for preventing network attacks provided in this specification according to an exemplary embodiment. This apparatus can be applied to, for example... Figure 3 The device shown implements the technical solution described in this specification. This device is used as an access node in a blockchain network and includes:

[0057] The request receiving unit 401 is used to receive a connection request sent by a requesting node and send a proof-of-work request to the requesting node. The proof-of-work request includes a random number for generating a proof-of-work task.

[0058] Result receiving unit 402 is used to receive the execution result obtained by the requesting node in response to the proof-of-work request and the signature generated for the execution result;

[0059] The result verification unit 403 is used to verify the signature based on the node public key of the requesting node, and to verify the proof-of-work task based on the execution result.

[0060] The connection establishment unit 404 is used to establish a connection with the requesting node when the signature verification is successful and the proof of work task is verified.

[0061] Optionally, the proof-of-work request further includes a proof difficulty value for generating the proof-of-work task; the result verification unit 403 is specifically used for:

[0062] Based on the execution result and the random number, a string to be tested is generated, and the string to be tested is hashed to obtain the corresponding hash result.

[0063] If the hash result satisfies the proof-of-work requirement corresponding to the proof difficulty value, the proof-of-work task is determined to have passed verification; otherwise, the proof-of-work task is determined to have failed verification.

[0064] Optionally, the result verification unit 403 is further configured to:

[0065] The execution result, the random number, and the public key of the requesting node are combined in a preset order to generate the string to be verified.

[0066] Optional, also includes:

[0067] The difficulty adjustment unit 405 is used to adjust the proof difficulty value according to the number of times the proof of work verification fails within a first preset time period before the current time. The proof difficulty value is positively correlated with the number of times the verification fails for any signature and the number of times the proof of work task fails to verify within the first preset time period before the current time.

[0068] Optionally, the network management contract deployed on the blockchain network maintains the proof difficulty value; the difficulty adjustment unit 405 is specifically used for:

[0069] Initiate a proof difficulty adjustment transaction containing the number of times to the network management contract deployed on the blockchain network, so that the network management contract adjusts the proof difficulty value maintained in the network management contract based on the number of times.

[0070] Optionally, the result verification unit 403 is specifically used for:

[0071] If the signature verification is successful, the proof-of-work task is verified based on the execution result.

[0072] Optionally, if the requesting node does not belong to the blockchain network, the device further includes:

[0073] The node joining unit 406 is used to add the requesting node to the blockchain network when the signature verification is successful and the proof-of-work task is verified.

[0074] Optionally, the node joining unit 406 is specifically used for:

[0075] The node information of the requesting node is stored in the node list maintained by the access node, and the node information of the access node is sent to the requesting node.

[0076] Optionally, the node joining unit 406 is specifically used for:

[0077] A node joining transaction containing the node information of the requesting node is initiated to the network management contract in the blockchain network, so that the network management contract maintains the node information of the requesting node.

[0078] Optionally, the node information includes a node identifier, a node public key, and / or a network address.

[0079] Optionally, the node identifier of the requesting node is generated by the access node when the signature verification is successful and the proof-of-work task is verified, or the node identifier of the requesting node is generated by the requesting node itself.

[0080] Optional, also includes:

[0081] The node identifier re-determination unit 407 is used to send a node identifier provision request to the requesting node or generate a globally unique first node identifier in the blockchain network to re-determine the node identifier of the requesting node when it is detected that the node identifier of the requesting node is not globally unique in the blockchain network. The node identifier provision request is used to enable the requesting node to provide a second node identifier to the access node to re-determine the node identifier of the requesting node.

[0082] Optional, also includes:

[0083] The response rejection unit 408 is configured to refuse to respond to messages initiated by the same initiator based on any protocol if the number of historical messages received from the same initiator based on any protocol within a second preset time period prior to the current time exceeds a preset threshold. The messages of any protocol include at least a connection request in the connection protocol.

[0084] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0085] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0087] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0088] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0089] This 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 block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0090] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0091] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0093] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0094] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can 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), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0095] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0096] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0097] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0098] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for preventing network attacks, applied to access nodes in a blockchain network, comprising: The system receives a connection request from a requesting node and sends a proof-of-work request to the requesting node. The proof-of-work request includes a random number for the requesting node to generate a proof-of-work task and a proof difficulty value for generating the proof-of-work task. The requesting node receives the execution result of the proof-of-work task obtained by executing the proof-of-work request in response to the proof-of-work request, and the signature generated for the execution result; The signature is verified based on the public key of the requesting node, and the proof-of-work task is verified based on the execution result. If the signature verification is successful and the proof-of-work task is verified, a connection is established with the requesting node; The verification of the proof-of-work task based on the execution result includes: Based on the execution result and the random number, a string to be tested is generated, and the string to be tested is hashed to obtain the corresponding hash result. If the hash result satisfies the proof-of-work requirement corresponding to the proof difficulty value, the proof-of-work task is determined to have passed verification; otherwise, the proof-of-work task is determined to have failed verification.

2. The method according to claim 1, wherein generating the string to be tested based on the execution result and the random number comprises: The execution result, the random number, and the public key of the requesting node are combined in a preset order to generate the string to be verified.

3. The method according to claim 1, further comprising: The proof difficulty value is adjusted based on the number of proof-of-work verification failures within a first preset time period prior to the current time. The proof difficulty value is positively correlated with the number of failures, which is the sum of the number of signature verification failures and the number of proof-of-work task verification failures within the first preset time period prior to the current time.

4. The method according to claim 3, wherein the network management contract deployed in the blockchain network maintains the proof difficulty value; adjusting the proof difficulty value based on the number of proof-of-work verification failures within a first preset time period prior to the current moment includes: Initiate a proof difficulty adjustment transaction containing the number of times to the network management contract deployed on the blockchain network, so that the network management contract adjusts the proof difficulty value maintained in the network management contract based on the number of times.

5. The method according to claim 1, wherein verifying the proof-of-work task based on the execution result includes: If the signature verification is successful, the proof-of-work task is verified based on the execution result.

6. The method according to claim 1, wherein if the requesting node does not belong to the blockchain network, the method further comprises: If the signature verification is successful and the proof-of-work task is verified, the requesting node will be added to the blockchain network.

7. The method according to claim 6, wherein adding the requesting node to the blockchain network comprises: The node information of the requesting node is stored in the node list maintained by the access node, and the node information of the access node is sent to the requesting node.

8. The method according to claim 6, wherein adding the requesting node to the blockchain network comprises: A node joining transaction containing the node information of the requesting node is initiated to the network management contract in the blockchain network, so that the network management contract maintains the node information of the requesting node.

9. The method according to claim 7 or 8, wherein the node information includes a node identifier, a node public key, and / or a network address.

10. The method according to claim 9, wherein the node identifier of the requesting node is generated by the access node when the signature verification is successful and the proof-of-work task is verified, or the node identifier of the requesting node is generated by the requesting node.

11. The method of claim 9, further comprising: If it is detected that the node identifier of the requesting node is not globally unique in the blockchain network, a node identifier provision request is sent to the requesting node or a globally unique first node identifier is generated in the blockchain network to re-determine the node identifier of the requesting node. The node identifier provision request is used to enable the requesting node to provide a second node identifier to the access node to re-determine the node identifier of the requesting node.

12. The method according to claim 1, further comprising: If the number of historical messages initiated by the same initiator based on any protocol received within a second preset time period prior to the current time exceeds a preset threshold, the system will refuse to respond to messages initiated by the same initiator based on any protocol, wherein the messages of any protocol include at least a connection request in the connection protocol.

13. A device for preventing network attacks, applied to an access node in a blockchain network, comprising: The request receiving unit is used to receive the connection request sent by the requesting node and send the proof-of-work request to the requesting node. The proof-of-work request includes a random number for the requesting node to generate the proof-of-work task and a proof difficulty value for generating the proof-of-work task. The result receiving unit is configured to receive the execution result obtained by the requesting node in response to the proof-of-work request and the signature generated for the execution result; The result verification unit is used to verify the signature based on the public key of the requesting node, and to verify the proof-of-work task based on the execution result. A connection establishment unit is used to establish a connection with the requesting node when the signature verification is successful and the proof of work task is verified. The result verification unit is specifically used for: Based on the execution result and the random number, a string to be tested is generated, and the string to be tested is hashed to obtain the corresponding hash result. If the hash result satisfies the proof-of-work requirement corresponding to the proof difficulty value, the proof-of-work task is determined to have passed verification; otherwise, the proof-of-work task is determined to have failed verification.

14. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-12 by executing the executable instructions.

15. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-12.

Images