WO2024021406A1

WO2024021406A1 - Network attack prevention method and device

Info

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

Abstract

The present description provides a network attack prevention method and device, which are applied to an access node in a blockchain network. The method comprises: receiving a connection request sent by a request node, and sending a proof-of-work request to the request node, the proof-of-work request comprising a random number for generating a proof-of-work task; receiving an execution result obtained by the request node executing the proof-of-work task in response to the proof-of-work request, and a signature generated with respect to the execution result; verifying the signature on the basis of a public key of the request node, and verifying the proof-of-work task on the basis of the execution result; and establishing connection with the request node if the signature passes verification and the proof-of-work task passes verification.

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 the first aspect of one or more embodiments of this specification, a method for preventing network attacks is proposed, which is applied to access nodes in a blockchain network, including: receiving a connection request sent by the requesting node, and converting the workload proof A request is sent to the requesting node, where the proof-of-work request includes a random number used to generate a proof-of-work task; and an execution result obtained by the requesting node executing the proof-of-work task in response to the proof-of-work request is received. and a signature generated for the execution result; verifying the signature based on the node public key of the requesting node, and verifying the workload proof task based on the execution result; when the signature verification is successful And if the verification of the workload proof task passes, a connection is established with the requesting node.

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 an access node in a blockchain network and includes: a request receiving unit configured to receive a connection sent by the requesting node. Request, send a workload proof request to the requesting node, the workload proof request includes a random number used to generate a workload proof task; a result receiving unit, used to receive the request node's response to the workload proof Request the execution result obtained by executing the workload proof task and the signature generated for the execution result; the result verification unit is used to verify the signature based on the node public key of the requesting node, and based on the execution As a result, the proof-of-work task is verified; a connection establishment unit is configured to establish a connection with the requesting node when the signature verification is successful and the verification of the proof-of-work task passes.

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 connection establishment mechanism is proposed that requires additional computing power. The requesting node needs to provide the access node in the blockchain network with identity proof and the execution results obtained after executing the workload proof task. And the connection can only be established with the access node after passing the verification of the access node. This increases the computational cost and time cost required for the attacker to invade the blockchain network, thereby limiting the attacker from being able to pass through the area in a short time. The blockchain network establishes a large number of connections to launch large-scale attacks, which improves the blockchain network's ability to prevent cyber attacks.

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.

The node responsible for accessing new nodes or establishing new connections in the blockchain network is called an access node. If there is a new node outside the blockchain network that wants to join the blockchain network, it needs to connect with the node in the blockchain network. The entry node applies for it, and after the application is passed, it establishes a connection with the access node to join the blockchain network where the access node is located. In the embodiment of this specification, the access node can be any node that has joined the blockchain network. The access node usually needs to ensure that it is trustworthy and open source. For example, the access node can be used when the blockchain network is initially established. The initial node serves as the access node, or the communication pillar node in the blockchain network (usually has more connections with other nodes in the blockchain network) as the access node. Taking Figure 1 as an example, nodeF that does not belong to the blockchain network can send a network access request to nodeE in the blockchain network to apply to join the blockchain network. At this time, nodeE serves as the access node of the blockchain network, and nodeF serves as the requesting node; or nodeA, which has not established a connection with nodeE, can send a connection request to nodeE to apply for establishing a connection with nodeE. At this time, nodeE also serves as the access node of the blockchain network, and nodeA serves as the requesting node. .

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 access nodes in the blockchain network and may include the following steps 202-208.

Step 202: Receive the connection request sent by the requesting node, and send the workload proof request to the requesting node, where the workload proof request includes a random number used to generate a workload proof task.

The requesting nodes involved in the embodiments of this specification may include nodes in the blockchain network that have not established a connection with the access node, or nodes that do not currently belong to the blockchain network. When the requesting node does not belong to the blockchain network, that is, it is not a node in the blockchain network, the connection request here is also called a network access request.

The access node responds to the connection request sent by the requesting node and sends the proof-of-work request to the requesting node. The proof-of-work request is used to cause the requesting node to trigger the generation and execution of the corresponding proof-of-work task, and finally returns it to the access node. The execution results obtained by executing the proof-of-work task. In order to ensure the randomness of the proof-of-work task and prevent the requesting node from obtaining the execution results in advance instead of temporarily executing the proof-of-work task, a random number needs to be provided to the requesting node to generate a random proof-of-work task. In addition, the proof of work request can also include the proof difficulty value used to generate the proof of work task, thereby instructing the requesting node to perform the proof of work task according to the corresponding proof difficulty value.

Step 204: Receive the execution result obtained by the requesting node from executing the workload proof task in response to the workload proof request and the signature generated for the execution result.

After receiving the proof-of-work request, the requesting node first generates the corresponding proof-of-work task based on the random number it contains. The proof-of-work task specifically refers to: by continuously changing the undetermined value, continuously constructing the random number and the undetermined value according to the A string composed of a preset sequence (or a string composed of the node public key of the requesting node, a random number and a pending value in a preset sequence), and the hash value corresponding to the string is calculated at the same time. When the hash value satisfies specific formal rules, the undetermined value determined in that string is determined as the execution result of the workload proof task. The above-mentioned specific formal rules may include, for example, several consecutive identical characters (such as "0") appearing at the beginning or end of the hash value. The specific number of consecutive identical characters required to appear depends on the proof corresponding to the workload proof task. The difficulty value proves that the higher the difficulty value, the more consecutive identical characters need to appear. It is easy to understand that the higher the proof difficulty value, the higher the computing power cost and time cost required to perform the workload proof task and obtain the final execution result.

The above workload proof task takes advantage of the irreversible characteristics of hash operations and the lack of regularity between output values and input values. It requires the prover to obtain the final execution result only by exhaustively enumerating the undetermined values. Therefore, as the request node of the prover Additional computing power is required to establish a connection with the access node, which increases the cost of requesting the node to establish a connection.

At the same time, in order to prove that the execution result obtained is obtained by the requesting node itself to perform the workload proof task, it is also necessary to provide the corresponding identity certificate to the access node. Specifically, after obtaining the execution result, the requesting node will also generate a corresponding signature for the execution result. The signature is obtained by encrypting the execution result using the node private key of the requesting node it holds.

Finally, the requesting node will send the execution result it obtains and the signature generated for the execution result to the access node for verification. Of course, the requesting node can also send the node public key of the requesting node at the same time. Sent to access node.

Step 206: Verify the signature based on the node public key of the requesting node, and verify the workload proof task based on the execution result.

When the access node verifies the signature, it needs to use the node public key of the requesting node that it has maintained in advance or that is temporarily provided by the requesting node to decrypt the signature, and compare the obtained decryption result with the execution result. If the comparison is consistent, it means that the source of the execution result is indeed the requesting node, thereby determining that the signature verification is successful. If the comparison is inconsistent, it means that the source of the execution result is not the requesting node, thus determining that the signature verification is successful. The above signature verification failed.

When the access node verifies the workload proof task, its actual process is similar to the process of requesting the node to perform the workload proof task. First, the string to be verified is generated based on the execution result and the random number, and then the string is generated. The string to be tested is subjected to a hash operation to obtain the corresponding hash result; finally, when the hash result meets the workload proof requirements corresponding to the proof difficulty value, it is determined that the workload proof task is verified, Otherwise, it is determined that the proof-of-work task verification fails. For example, the proof difficulty value maintained by the access node requires that the hash result satisfies the workload proof requirement: the beginning of the hash result contains 8 consecutive characters "0", then only when the hash result Only when the beginning does contain 8 consecutive characters "0" will the proof-of-work task be deemed to have passed the verification, that is, the requesting node will be considered to have indeed executed the proof-of-work task correctly and compliantly. As mentioned above, in order to enable the requesting node to provide execution results that meet the proof of work requirements corresponding to the proof difficulty value, the proof of work request may also include the proof difficulty value used to generate the proof of work task, so that the request The node fully considers the proof difficulty value when generating the workload proof task, and based on this, generates execution results that meet the workload proof requirements corresponding to the proof difficulty value.

Optionally, generating a string to be verified based on the execution result and the random number includes: combining the execution result, the random number and the node public key of the requesting node in a preset order to Generate the string to be tested. In the embodiment of this specification, the string constructed in the workload proof task mentioned above may also include the node public key of the requesting node. In this way, a strong binding between the requesting node and the execution result can be further realized. This can more effectively prove that the execution result comes from the requesting node corresponding to the node public key in the string. Since the substantive process of verifying a proof-of-work task is equivalent to that of executing a proof-of-work task, the string to be verified should also be generated according to the same combination of construction rules mentioned above and further verified during the process of verifying a proof-of-work task.

In the embodiment of this specification, the above-mentioned process of verifying the signature based on the node public key of the requesting node and the process of verifying the workload proof task based on the execution result may be independent processes, That is, there is no necessary order of execution between the two processes. The two processes can be executed sequentially or simultaneously. The embodiments of this specification do not impose any restrictions on this. Optionally, the verification of 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 embodiment of this specification, the process of the access node verifying the workload proof task can be executed when the signature verification is successful. In this way, the signature can be verified successfully. If the signature verification is unsuccessful, there is no need to further perform the verification process of the relatively more time-consuming workload proof task, thus saving the computing resources of the access node to a certain extent and preventing the attacker from sending excessive execution results and their signatures. To force the access node to perform a large number of signature verification/verification tasks that consume computing resources in a short period of time, causing the access node to go down, and to a certain extent, it has the effect of preventing network attacks.

Optionally, it also includes: adjusting the proof difficulty value according to the number of failed proof-of-work verifications within the first preset time period before the current moment, where the proof difficulty value is directly related to the number of times, and the number of times is the number of times since the current moment. The sum of the number of times any signature verification fails and the number of times any proof-of-work task fails verification within the first preset time period before the current time.

In the embodiment of this specification, the access node maintains a certification difficulty value, and can adjust the certification difficulty value according to the number of recent encounters with costless access behaviors (ie, the aforementioned signature verification failure or workload proof task verification failure). The number of costless access behaviors is the number of failed proof-of-work verifications. This number refers to the sum of the number of failed signature verifications and the number of failed verifications of any proof-of-work task (that is, for each connection request, If the signature provided by the requesting node fails to be verified or the proof-of-work task fails to be verified, this number will be increased by one). When counting this number, signatures may appear in the execution results and signatures provided by the requesting node corresponding to each connection request. If the signature verification fails and the proof-of-work task verification fails, then only the number of failed proof-of-work verifications will be counted once (instead of twice) to avoid repeated statistics that may cause the number to be higher than the actual value. Since the number of costless access behaviors objectively reflects the intensity of network attacks encountered by the blockchain network, embodiments of this specification can enable the blockchain network to increase the cost of establishing a connection by new requesting nodes when encountering network attacks. To further increase the cost of cyber attacks for attackers by establishing a large number of connections to the blockchain network, and further improve the ability of the blockchain network to prevent cyber attacks. In addition, since the adjustment of the proof difficulty value is carried out dynamically, for example, when the number of costless access behaviors encountered recently decreases, the current proof difficulty value can be appropriately reduced, thereby reducing the normal access level without encountering network attacks. The cost required for entry behavior should be paid attention to, and the phenomenon of "accidental killing" should be avoided as much as possible.

Optionally, the network management contract deployed by the blockchain network maintains the proof difficulty value; the proof difficulty value is adjusted according to the number of workload proof verification failures within the first preset time period before the current time. , including: initiating a proof difficulty value adjustment transaction including the said number of times to the network management contract deployed on the blockchain network, so that the network management contract adjusts the said number maintained in the network management contract based on the said number of times. Prove the difficulty value.

In the embodiment of this specification, the proof difficulty value maintained by the access 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 proof difficulty value by maintaining the same network management contract, which allows any one of the blockchain nodes to detect When a network attack occurs, the proof difficulty value maintained in the network management contract is adjusted by initiating a proof difficulty value adjustment transaction to the network management contract to inform other blockchain nodes in the blockchain network of the change in proof difficulty value. , enabling the blockchain network to have the function of overall adjusting the access strategies of all nodes according to changes in the current network environment, and improving the overall ability of the blockchain network to prevent network attacks.

Step 208: If the signature verification is successful and the proof-of-work task verification passes, establish a connection with the requesting node.

If the requesting node belongs to the blockchain network, the access node will only establish a connection with it after confirming that the signature verification is successful and the proof-of-work task verification is passed. When the requesting node does not belong to the blockchain network, the method further includes: when the signature verification is successful and the proof-of-work task verification passes, adding the requesting node to the network. The blockchain network. In the embodiment of this specification, if the requesting node itself does not belong to the blockchain network, then the access node will add the requesting node to the blockchain network by default after confirming that the signature verification is successful and the workload proof task verification is passed. in the blockchain network. Since the embodiments of this specification require additional computing power costs for new nodes to join the blockchain network, there is an increase in Sybil attacks (the attacker deploys multiple nodes with legal identities in a P2P network such as the blockchain network). ) attack cost, indirectly limits the intensity of the attacker's Sybil attack, and improves the blockchain network's ability to prevent network attacks.

Specifically, adding the requesting node to the blockchain network includes: storing the node information of the requesting node in a node list maintained by the access node, and adding the node information of the access node to the blockchain network. Node information is sent to the requesting node. 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, the access node will first store the node information of the requesting node in the node list maintained by the access node. At the same time, the access node will send the node information of the access node to the requesting node and notify the request The node has successfully joined the blockchain network, then the requesting node will establish a node list maintained by itself, and store the node information of the access node in the node list maintained by the requesting node. After the requesting node joins the blockchain network through the access node, it initially only knows the access node in the blockchain network. If it needs to further discover other nodes in the blockchain network and establish connections with them, it needs to The access node sends a node discovery request, so that the access node returns the node list maintained by the access node to the requesting node in response to the node discovery request. The access node knows other nodes in the blockchain network through the received node list. , and establish connections with other nodes through the received node information in the node list and send them new node discovery requests. Iterating the above process can theoretically make the requesting nodes newly added to the blockchain network aware of the information in the blockchain network. of all nodes and establish connections with all nodes. Take nodeF joining the blockchain network through nodeE in Figure 1 as an example. nodeF first sends a node discovery request to nodeE to obtain the node list maintained by nodeE, and obtain the nodes of nodeB and nodeD that have a connection relationship with nodeE from the node list. Information, nodeF then establishes connections with nodeB and nodeD respectively and sends node discovery requests respectively, thereby further obtaining the node list maintained by nodeB and the node list maintained by nodeD. By repeating the above process, nodeF will finally be able to learn all the nodes in the blockchain network. The node information of the node, and theoretically can also establish connections with all nodes.

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 requesting node can be added to the blockchain network. The network management contract maintains node information of the requesting node. 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. Therefore, after a new node (requesting node) joins, The entry node can also initiate a node joining transaction to the network management contract so that the node information of the requesting node is updated and maintained in the network management contract.

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. Specifically, when the node identification of the requesting node is generated by the access node, the access node generates it when the signature verification is successful and the proof-of-work task verification is passed, so that It avoids generating a node identifier every time a connection request is received, reducing the computing burden on the access node. It also prevents the attacker from forcing the access node to execute a large number of node identifiers that consume computing resources in a short period of time by sending an excessive number of connection requests. Generating tasks causes the access node to go down, which to a certain extent prevents network attacks. Optionally, the node identification of the requesting node is generated by hashing the node public key of the requesting node, so the global uniqueness of the node public key can be used to ensure that no hash collision occurs. Global uniqueness of the node ID of each node.

Optionally, it also includes: when it is detected that the node identification of the requesting node is not globally unique in the blockchain network, sending a node identification provision request to the requesting node or generating the blockchain network The globally unique first node identifier in the requesting node is re-determined to be the node identifier of the requesting node. The node identifier providing request is used to cause the requesting node to re-provide the second node identifier to the access node to be re-determined to be the requesting node. The node ID of the requesting node. In the embodiment of this specification, if the access node finds that the node identification of the requesting node is the same as the node identification of an existing node in the blockchain network, it will regenerate a new node identification to serve as the node identification of the requesting node. Or require the requesting node to re-provide a new node identification as the node identification of the requesting node, thereby ensuring that the node identification of each node in the blockchain network is globally unique.

Optionally, it also includes: refusing to respond to the same initiator when the number of historical messages based on any protocol initiated by the same initiator exceeds a preset threshold within a second preset time period before the current moment. Messages initiated based on any of the protocols, which include at least a connection request in a connection protocol, a node discovery request in a node discovery protocol, etc. The embodiments of this specification do not limit the type of the 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 the protocol. Through the embodiments of this specification, it is possible to count the received messages of various protocols (including various requests or responses), and when the historical messages of a certain type of protocol originating from the same initiator are excessive in a short period of time, , refusing 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 access nodes in a blockchain network and includes: a request receiving unit 401, used to receive a connection request sent by a requesting node, and send a workload proof request to the requesting node, where the workload proof request includes Random numbers used to generate proof-of-work tasks;

The result receiving unit 402 is used to receive the execution result obtained by the requesting node from executing the workload proof task in response to the workload proof request and the signature generated for the execution result; the result verification unit 403 is used to based on the workload proof task. The node public key of the requesting node verifies the signature, and verifies the workload proof task based on the execution result; the connection establishment unit 404 is used to verify the signature when the signature verification is successful and the workload If the verification task passes, a connection is established with the requesting node.

Optionally, the workload proof request also includes a proof difficulty value used to generate the workload proof task; the result verification unit 403 is specifically configured to: generate a character to be verified based on the execution result and the random number. String, perform a hash operation on the string to be tested to obtain the corresponding hash result; when the hash result meets the workload proof requirements corresponding to the proof difficulty value, determine the workload proof task The verification passes, otherwise it is determined that the verification of the workload proof task fails.

Optionally, the result verification unit 403 is further configured to: combine the execution result, the random number and the node public key of the requesting node in a preset order to generate the string to be verified.

Optionally, it also includes: a difficulty value adjustment unit 405, configured to adjust the proof difficulty value according to the number of workload proof verification failures within the first preset time period before the current time, and the proof difficulty value is positively related to the proof difficulty value. The number of times described above is the sum of the number of times any signature verification fails and the number of times any proof-of-work task fails verification within the first preset time period before the current moment.

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

Optionally, the result verification unit 403 is specifically configured to verify the workload proof task based on the execution result if the signature verification is successful.

Optionally, when the requesting node does not belong to the blockchain network, the device further includes:

The node adding unit 406 is configured to add the requesting node to the blockchain network when the signature verification is successful and the proof-of-work task verification passes.

Optionally, the node joining unit 406 is specifically configured to: store the node information of the requesting node in the node list maintained by the access node, and send the node information of the access node to the requesting node. node.

Optionally, the node joining unit 406 is specifically configured to: initiate 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 for the requested node.

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

Optionally, the node identification of the requesting node is generated by the access node when the signature verification is successful and the proof-of-work task verification passes, or the node identification of the requesting node is generated by the access node. Request node generation.

Optionally, it also includes: a node identification re-determination unit 407, configured to send a node identification provision to the requesting node when it is detected that the node identification of the requesting node is not globally unique in the blockchain network. Request or generate a globally unique first node identification in the blockchain network to re-determine as the node identification of the requesting node, and the node identification providing request is used to cause the requesting node to re-provide it to the access node. The second node identification is redetermined as the node identification of the requesting node.

Optionally, it also includes: a response rejection unit 408, configured to receive a number of historical messages based on any protocol initiated by the same initiator within the second preset time period before the current moment exceeding the preset threshold, Do not respond to messages based on any protocol initiated by the same initiator, and the messages of any protocol at least include a connection request in the connection protocol.

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 may be executed sequentially or in parallel according to the methods shown in the embodiments or figures (for example, 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 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 access nodes in the blockchain network, including:

Receive a connection request sent by a requesting node, and send a proof-of-work request to the requesting node, where the proof-of-work request includes a random number used to generate a proof-of-work task;

Receive the execution result obtained by the requesting node from executing the workload proof task in response to the workload proof request and the signature generated for the execution result;

Verify the signature based on the node public key of the requesting node, and verify the workload proof task based on the execution result;

When the signature verification is successful and the proof-of-work task verification passes, a connection is established with the requesting node.
The method according to claim 1, wherein the proof-of-work request further includes a proof difficulty value used to generate the proof-of-work task; and verifying the proof-of-work task based on the execution results includes:

Generate a string to be tested based on the execution result and the random number, and perform a hash operation on the string to be tested to obtain the corresponding hash result;

In the case where the hash result meets the proof-of-work requirements corresponding to the proof difficulty value, it is determined that the proof-of-work task has passed the verification, otherwise it is determined that the proof-of-work task has failed the verification.
The method according to claim 2, generating a string to be tested based on the execution result and the random number includes:

The execution result, the random number and the node public key of the requesting node are combined in a preset order to generate the string to be verified.
The method of claim 2, further comprising:

The proof difficulty value is adjusted according to the number of failed proof-of-work verifications within the first preset time period before the current moment. The proof difficulty value is directly related to the number of times, and the number of times is the number of failed proof-of-work verifications within the first preset time period before the current moment. The sum of the number of times any signature verification fails and the number of times any proof-of-work task fails verification within a preset period of time.
According to the method of claim 4, the network management contract deployed by the blockchain network maintains the proof difficulty value; the adjustment is based on the number of workload proof verification failures within the first preset time period before the current time. The proof difficulty value includes:

Initiate a proof difficulty value adjustment transaction including 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. .
The method according to claim 1, the verification of the workload proof task based on the execution results includes:

If the signature verification is successful, the workload proof task is verified based on the execution result.
The method according to claim 1, when the requesting node does not belong to the blockchain network, the method further includes:

When the signature verification is successful and the proof-of-work task verification passes, the requesting node is added to the blockchain network.
The method according to claim 7, adding the requesting node to the blockchain network includes:

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.
The method according to claim 7, adding the requesting node to the blockchain network includes:

Initiate 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.
According to the method of claim 8 or 9, the node information includes node identification, node public key and/or network address.
According to the method of claim 10, the node identification of the requesting node is generated by the access node when the signature verification is successful and the workload proof task verification passes, or the requesting node The node identification is generated by the requesting node.
The method of claim 10, further comprising:

When it is detected that the node identification of the requesting node is not globally unique in the blockchain network, send a node identification provision request to the requesting node or generate a globally unique first node in the blockchain network The identification is to be redetermined as the node identification of the requesting node, and the node identification provision request is used to cause the requesting node to re-provide the second node identification to the access node to be redetermined as the node identification of the requesting node.
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 second preset time period before the current moment exceeds the preset threshold, refuse to respond to the historical messages initiated by the same initiator based on any protocol. Messages of any protocol include at least a connection request in the connection protocol.
A device to prevent network attacks, applied to access nodes in the blockchain network, including:

A request receiving unit, configured to receive a connection request sent by a requesting node, and send a proof-of-work request to the requesting node, where the proof-of-work request includes a random number used to generate a proof-of-work task;

A result receiving unit configured to receive the execution result obtained by the requesting node from executing the workload proof task in response to the workload proof request and the signature generated for the execution result;

A result verification unit, configured to verify the signature based on the node public key of the requesting node, and verify the workload proof task based on the execution result;

A connection establishment unit, configured to establish a connection with the requesting node when the signature verification is successful and the proof-of-work task verification passes.
An electronic device including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor implements the method according to any one of claims 1-13 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-13.