A data processing method, device and related equipment based on a blockchain network

Abstract

An embodiment of the present application provides a data processing method, apparatus, and related device based on a blockchain network. The method includes: obtaining network status data of the blockchain network, where the network status data includes one or both of the first network status recorded by the first service node and the second network status recorded by the second service node. The first network status includes network status parameters of each data node connected to the first service node, and the second network status includes network status parameters of each data node connected to the second service node; determining a network quality score for each data node connected to the first service node according to the network status data; determining target data nodes whose network quality meets the conditions from each data node connected to the first service node. The target data nodes are used to provide block data, which can accurately evaluate the network quality of the data nodes, make full use of the network resources of the blockchain network, and effectively improve the synchronization efficiency of block data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a data processing method, device, and related equipment based on a blockchain network. Background Art

[0002] With the progress of science and technology and the development of society, the application of blockchain technology is becoming more and more extensive. Among them, a blockchain is a distributed ledger, a reliable database collectively maintained in a decentralized and trustless manner. Specifically, it can be jointly maintained by multiple nodes in the blockchain network. Based on this, it is particularly important to efficiently synchronize data such as blocks between nodes in the blockchain network.

[0003] Currently, when synchronizing data between nodes in a blockchain network, nodes for data synchronization are usually selected according to the business load of the nodes or by a random method. However, it has been found in practice that when selecting nodes for data synchronization according to the business load of the nodes or by a random selection method, it is difficult to fully utilize the resources of the blockchain network, and the synchronization efficiency of block data is relatively low. Therefore, how to effectively improve the data synchronization efficiency in the blockchain network has become an urgent problem to be solved. Summary of the Invention

[0004] Embodiments of this application provide a data processing method, device, and related equipment based on a blockchain network, which can accurately evaluate the network quality of data nodes and make full use of the network resources of the blockchain network, thereby effectively improving the synchronization efficiency of block data.

[0005] In a first aspect, embodiments of this application provide a data processing method based on a blockchain network, which is applied to a first service node of the blockchain network. The method includes:

[0006] Obtain network status data of the blockchain network, where the network status data includes one or both of a first network status recorded by the first service node and a second network status recorded by a second service node of the blockchain network. The first network status includes network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes network status parameters of each data node connected to the second service node in the blockchain network. The network status parameters include one or both of network latency time and historical transmission speed;

[0007] Determine the network quality score of each data node connected to the first service node according to the network status data;

[0008] Determine a target data node whose network quality score meets a preset condition from each data node connected to the first service node, where the target data node is used to provide block data to be synchronized.

[0009] In a second aspect, an embodiment of the present application provides a data processing device, which includes:

[0010] An acquisition module, configured to acquire network status data of a blockchain network, where the network status data includes one or both of a first network status recorded by a first service node of the blockchain network and a second network status recorded by a second service node of the blockchain network. The first network status includes network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes network status parameters of each data node connected to the second service node in the blockchain network. The network status parameters include one or both of network latency time and historical transmission speed;

[0011] A determination module, configured to determine a network quality score of each data node connected to the first service node according to the network status data;

[0012] The determination module is further configured to determine a target data node whose network quality score meets a preset condition from each data node connected to the first service node, where the target data node is used to provide block data to be synchronized.

[0013] In a third aspect, an embodiment of the present application provides a computer device, which includes a processor, a network interface, and a storage device. The processor, the network interface, and the storage device are interconnected. Among them, the network interface is controlled by the processor to send and receive data, the storage device is used to store a computer program, the computer program includes program instructions, and the processor is configured to call the program instructions to execute the data processing method as described in the first aspect.

[0014] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program includes program instructions, and the program instructions are executed by a processor to execute the data processing method as described in the first aspect.

[0015] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, characterized in that when the computer program is executed by a computer processor, it implements the data processing method as described in the first aspect.

[0016] In an embodiment of the present application, a first service node of a blockchain network may obtain network status data of the blockchain network. The network status data includes one or both of a first network status recorded by the first service node and a second network status recorded by a second service node of the blockchain network. The first network status includes network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes network status parameters of each data node connected to the second service node in the blockchain network. Based on the network status data, the first service node may determine a network quality score for each data node connected to the first service node, and determine target data nodes whose network quality scores meet a preset condition from each data node connected to the first service node. The target data nodes may be used to provide block data to be synchronized. By using dimensions such as network latency time and historical transmission speed, and combining the network status recorded by other service nodes, the network condition of the data nodes can be accurately evaluated, and the data node with the best network condition can be selected from them to provide block synchronization services, thereby accurately evaluating the network quality of the data nodes, making full use of the network resources of the blockchain network, and effectively improving the synchronization efficiency of block data. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for describing the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0018] Figure 1a is a schematic diagram of the architecture of a data processing system provided by an embodiment of the present application;

[0019] Figure 1b is a schematic diagram of the structure of a blockchain provided by an embodiment of the present application;

[0020] Figure 1c is a schematic diagram of the process of generating a new block provided by an embodiment of the present application;

[0021] Figure 2 is a schematic diagram of the flow of a data processing method based on a blockchain network provided by an embodiment of the present application;

[0022] Figure 3 is a schematic diagram of the flow of another data processing method based on a blockchain network provided by an embodiment of the present application;

[0023] Figure 4 is a schematic diagram of the structure of a data processing device provided by an embodiment of the present application;

[0024] Figure 5 It is a schematic structural diagram of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0025] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without making creative efforts shall fall within the protection scope of the present application.

[0026] Please refer to Figure 1a , which is a schematic architecture diagram of a data processing system provided by an embodiment of the present application. The data processing system includes a blockchain network 10 and a terminal device 20, where:

[0027] The blockchain network 10 may specifically be a hierarchical structure, including a business network 101, a data network 102, and a core network 103. Among them, the core network 103 is composed of multiple consensus nodes 1030. The core network 103 is responsible for the consensus of the whole network, packing transactions into blocks for consensus accounting; the data network 102 is composed of multiple data nodes 1020. The data network 102 is responsible for synchronizing the ledger information of the core network 103, that is, synchronizing the latest block data, and providing read services to the business network 101; the business network 101 is composed of multiple business nodes 1010. The business network 101 is responsible for synchronizing the block data of the business itself from the data network 102, and data isolation is performed by the data network 102. With the hierarchical structure, it can be infinitely expanded each time, especially for the business network 101. When the data network 102 and the core network 103 are expanded, they can be limited to a certain size range on the premise of ensuring the high performance and high availability of the overall network.

[0028] The business network 101, the data network 102, and the core network 103 may each include multiple nodes. For example, the business nodes 1010 included in the business network 101, the data nodes 1020 included in the data network 102, and the consensus nodes 1030 included in the core network 103 may all be multiple. To ensure information intercommunication within the blockchain network, there may be information connections between nodes within the same network (such as the data network 102), and point-to-point (Peer To Peer, P2P) communication can be achieved between any two nodes. Specifically, P2P communication can be performed through a wired communication link or a wireless communication link.

[0029] The terminal device 20 can access the blockchain network 10 and communicate with the nodes in the blockchain network 10. For example, it can submit data (such as transaction data, data query requests, etc.) to the service node 1010 in the service network 101, query data from the service node 1010, and so on. Among them, the terminal device 20 can specifically be a smart phone, a tablet computer, a laptop, a desktop computer, an in-vehicle intelligent terminal, etc., which is not limited in the embodiments of the present application.

[0030] It should be noted that Figure 1a the numbers of various types of nodes such as the service node 1010, the data node 1020, and the consensus node 1030 shown in

[0031] are only illustrative. According to actual needs, any number of nodes can be deployed. Figure 1b Each node in the blockchain network 10 stores an identical blockchain. The blockchain consists of multiple blocks. Refer to

[0032] When generating each block in the blockchain, refer to Figure 1c When the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, it stores the input information in the memory pool and updates the hash tree used to record the input information; then, it updates the timestamp to the time when the input information is received, and tries different random numbers, and performs eigenvalue calculations multiple times, so that the calculated eigenvalue can satisfy the following formula:

[0033] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

[0034] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time for updating the timestamp; nbits is the current difficulty, which is a fixed value within a certain period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined according to nbits.

[0035] In this way, when a random number that satisfies the above formula is calculated, the information can be correspondingly stored to generate a block header and a block body, obtaining the current block. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in its blockchain network according to the node identifiers of other nodes in the blockchain network. Other nodes verify the newly generated block and add the newly generated block to the blockchain they store after the verification is completed.

[0036] Among them, smart contracts can run on the nodes of the blockchain network. A smart contract is a code implementation used to execute when certain conditions are met. Developers can define contract logic through programming languages, publish it to the blockchain (smart contract registration), trigger the execution according to the logic of the contract terms by calling keys or other events, complete the contract logic, and at the same time provide functions for upgrading and canceling smart contracts.

[0037] In some feasible embodiments, each service node 1010 in the service network 101 can establish a connection with one or more data nodes 1020 in the data network 102. Taking the first service node in the service network 101 as an example, the first service node can be any one of the service nodes. The first service node can obtain the network status data of the blockchain network. The network status data includes one or both of the first network status recorded by the first service node and the second network status recorded by the second service node in the blockchain network. The first network status refers to the network status parameters of each data node connected to the first service node in the blockchain network, and the second network status refers to the network status parameters of each data node connected to the second service node in the blockchain network. The network status parameters include one or both of the network latency time and the historical transmission speed. The first service node can determine the network quality score of each data node 1020 connected to the first service node according to the network status data, and determine the target data node whose network quality score meets the preset conditions from the connected data nodes 1020. The target data node can be used to provide the block data to be synchronized. Using dimensions such as the network latency time and the historical transmission speed can accurately evaluate the network condition of the data node, and select the data node with the best network condition to provide the block synchronization service, which can make full use of the network resources of the blockchain network, thereby effectively improving the synchronization efficiency of the block data.

[0038] The following elaborates in detail on the implementation details of the technical solution of the embodiments of the present application:

[0039] Please refer to Figure 2 , which is a schematic flowchart of a data processing method based on a blockchain network provided by the data processing system shown in Figure 1a . The data processing method of the embodiments of the present application is mainly described from the perspective of the first service node in the blockchain network. The data processing method includes the following steps:

[0040] 201. Obtain the network status data of the blockchain network, where the network status data includes one or both of the first network status recorded by the first service node and the second network status recorded by the second service node in the blockchain network.

[0041] Among them, each service node can establish communication connections with one or more data nodes simultaneously. The same data node can be connected to one or more service nodes at the same time. That is to say, there may be the same data nodes among the data nodes connected by different service nodes. The data node is used to provide the synchronization service of block data to the connected service nodes. Each service node can record the network status of each data node that establishes a communication connection with it. The network status can specifically be network status parameters, such as one or both of the network latency time and the historical transmission speed. The above-mentioned first service node can be any service node in the service network of the blockchain network. The network status data can specifically include one or both of the first network status recorded by the first service node and the second network status recorded by the second service node of the blockchain network. The second service node can specifically include one or more service nodes in the service network of the blockchain network other than the first service node. Among them, the first network status includes the network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes the network status parameters of each data node connected to the second service node in the blockchain network.

[0042] Specifically, for each data node with which a connection is established, the first service node can first obtain the network status data of the blockchain network, and then determine the network status parameters of each data node connected to the first service node according to one or both of the first network status recorded by the first service node and the second network status recorded by the second service node included in the network status data. That is to say, the first service node can use the first network status recorded by itself to determine the network status parameters of each data node connected to the first service node, or use the second network status recorded by the second service node to determine the network status parameters of each data node connected to the first service node, or comprehensively use the first network status recorded by itself and the second network status recorded by the second service node to determine the network status parameters of each data node connected to the first service node. The embodiments of the present application do not make any limitations.

[0043] Among them, the network status parameters can specifically count the network conditions of the data nodes from one or two dimensions of the network latency time and the historical transmission speed. By using dimensions such as the network latency time and the historical transmission speed, the network conditions of the data nodes can be accurately evaluated, providing an accurate basis for the selection of data nodes.

[0044] In some feasible embodiments, if the first service node determines the network status parameters of each data node connected to the first service node by using the first network status recorded by itself, since the first network status exactly includes the network status parameters of each data node connected to the first service node in the blockchain network, the network status parameters of each data node connected to the first service node can be directly determined according to the first network status.

[0045] In some feasible embodiments, if the first service node determines the network status parameters of each data node connected to the first service node by using the second network status recorded by the second service node, the first service node can first obtain each data node connected to the second service node, and then find out the data nodes that are also connected to the first service node, which can be recorded as the co-connected data nodes. For the co-connected data nodes, the first service node can obtain the network status parameters of the co-connected data nodes from the second network status recorded by the second service node. For the other data nodes among the data nodes connected to the first service node except the co-connected data nodes, the first service node can obtain the network status parameters of the other data nodes from the first network status recorded by itself. Of course, for the co-connected data nodes, the first node can also comprehensively determine the network status parameters of the co-connected data nodes according to the network status parameters of the co-connected data nodes included in the first network status and the network status parameters of the co-connected data nodes included in the second network status. For example, the network status parameters of the co-connected data nodes included in the first network status can be averaged with the network status parameters of the co-connected data nodes included in the second network status, and then the average value can be used as the determined network status parameters of the co-connected data nodes. By comprehensively evaluating the network status of the data nodes by combining the network statuses recorded by other service nodes in the business network of the blockchain network, the situation of inaccurate network status evaluation caused by poor network status between a single service node and the connected data nodes can be effectively avoided, and the accuracy of network quality evaluation can be improved.

[0046] In some feasible embodiments, the specific way for the first service node to obtain the second network status recorded by the second service node included in the network status data can be:

[0047] The first service node sends a network status acquisition request to the second service node of the blockchain network, receives the response data packet sent by the second service node in response to the network status acquisition request. The response data packet carries the signature information of the second service node and the second network status recorded by the second service node; after the first service node verifies the signature information and passes, it obtains the second network status from the response data packet.

[0048] Specifically, the first service node can request the network status recorded by other service nodes (such as the second service node) in the blockchain network. After receiving the request, the second service node can send the second network status it recorded to the first service node. To ensure data reliability, the second service node can also send its signature information (such as a digital signature generated using its private key) to the first service node. For example, the second network status and the signature information are sent to the first service node as a response data packet. After receiving the response data packet, the first service node can verify the signature information in the response data packet. For example, the first service node can obtain the public key of the second service node and use the public key to verify the signature information. If the verification passes, the first service node obtains the second network status from the response data packet, thereby obtaining a secure and reliable network status recorded by other service nodes.

[0049] In some feasible embodiments, each service node can write the network status it records into the blockchain and record the storage location of the network status in the blockchain (such as block height information). For example, the first service node writes the first network status it records into the blockchain, and the height of the block where it is located is the first block height. The second service node writes the second network status it records into the blockchain, and the height of the block where it is located is the second block height. Then, when the first service node obtains the second network status recorded by the second service node, it can first request the second service node to obtain the storage location of the second network status in the blockchain. The second service node returns the storage location of the second network status in the blockchain (such as the second block height) to the first service node. The first service node can obtain the second network status recorded by the second service node from the blockchain according to the second block height. Obtaining the network status of other service nodes from the blockchain can prevent other service nodes from maliciously tampering with the network status, thereby obtaining an accurate and credible network status recorded by other service nodes.

[0050] In some feasible embodiments, after each business node writes the network status it records into the blockchain, it can broadcast the height of the block where it is located in the business network, so that each business node can record the storage location of the network status of each other business node in the blockchain. For example, after the first business node writes the first network status it records into the blockchain, it broadcasts the height of the block where it is located (such as the first block height) to other business nodes in the business network, and other business nodes can record the storage location of the first network status recorded by the first business node in the blockchain (such as the first block height); similarly, after the second business node writes the second network status it records into the blockchain, it broadcasts the height of the block where it is located (such as the second block height) to other business nodes in the business network, and other business nodes can record the storage location of the second network status recorded by the second business node in the blockchain (such as the second block height). When the first business node needs to obtain the second network status recorded by the second business node, it can query the second block height corresponding to the second network status according to the record, and then the first business node can obtain the second network status recorded by the second business node from the blockchain according to the second block height, further improving the efficiency of obtaining the network status of other business nodes, thereby improving the efficiency of network quality evaluation, and ultimately improving the efficiency of block synchronization.

[0051] 202. Determine the network quality score of each data node connected to the first business node according to the network status data.

[0052] Specifically, the first business node can quantitatively represent the network status of the data node through a scoring mechanism. Scoring rules can be set for network status parameters, and different scoring rules can be set for network status parameters in different dimensions. For example, one scoring rule can be set for network latency time, and another scoring rule can be set for historical transmission speed. Moreover, the weights of each scoring rule can be increased or decreased according to the focus during scoring. If the scoring is mainly based on network latency time, a scoring method with a higher score can be set for the scoring rule of network latency time. If the scoring is mainly based on historical transmission speed, a scoring method with a higher score can be set for the scoring rule of historical transmission speed. The first business node can calculate the network quality score of each data node by using one or both of network latency time and historical transmission speed, and the network quality score is used to indicate the network status of the data node, such as network resource utilization rate, data transmission performance, etc.

[0053] 203. Determine target data nodes whose network quality scores meet preset conditions from each data node connected to the first business node, and the target data nodes are used to provide block data to be synchronized.

[0054] Specifically, after obtaining the network quality scores of each connected data node, the first service node can determine whether the network quality scores of each data node meet the preset conditions. The preset conditions can be that the network quality score is the smallest, or the network quality score is less than or equal to the preset score threshold, so as to find the target data nodes among one or more connected data nodes whose network quality scores meet the preset conditions. Since the network quality scores of the target data nodes meet the preset conditions, it means that the network conditions of the target data nodes are better, with advantages such as low network latency and fast transmission speed, that is, the data nodes with the best comprehensive performance of network latency and packet loss. The target data nodes can be used to provide the block data to be synchronized to the first service node.

[0055] It should be noted that when using other scoring rules, the preset conditions can also be that the network quality score is the largest, or the network quality score is greater than or equal to the preset score threshold, which is not limited in the embodiments of the present application.

[0056] In some feasible implementation manners, after determining the target data nodes, the first service node can send a block data synchronization request to the target data nodes. The block data synchronization request carries the target block height, and the target block height indicates the block data to be synchronized. After receiving the block data synchronization request, the target data nodes can query the corresponding block data from the blockchain according to the target block height, and send the block data corresponding to the target block height to the first service node. The first service node receives the block data corresponding to the target block height sent by the target data nodes, thereby completing the efficient synchronization of the block data, making full use of the network resources of the target data nodes, and improving the operation efficiency of the blockchain network.

[0057] In an embodiment of the present application, a first service node of a blockchain network may obtain network status data of the blockchain network. The network status data includes one or both of a first network status recorded by the first service node and a second network status recorded by a second service node of the blockchain network. The first network status includes network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes network status parameters of each data node connected to the second service node in the blockchain network. Based on the network status data, the first service node may determine a network quality score for each data node connected to the first service node, and determine target data nodes whose network quality scores meet a preset condition from each data node connected to the first service node. The target data nodes may be used to provide block data to be synchronized. By using dimensions such as network latency time and historical transmission speed, and comprehensively considering the network status recorded by other service nodes, the network condition of the data nodes can be accurately evaluated, and the data node with the best network condition can be selected to provide block synchronization services, thereby accurately evaluating the network quality of the data nodes, making full use of the network resources of the blockchain network, ensuring the accuracy of data node scheduling, effectively improving the synchronization efficiency of block data, and ensuring the high availability of block data synchronization.

[0058] Please refer to Figure 3 , which is another Figure 1a schematic flowchart of a data processing method based on a blockchain network provided by the data processing system shown. The data processing method of the embodiment of the present application is mainly described from the perspective of the service nodes in the blockchain network. The data processing method includes the following steps:

[0059] 301. Determine the network latency time of each data node according to the round-trip delay of data packets of each data node connected to the first service node in the blockchain network.

[0060] Among them, the first service node may jointly evaluate the network condition of the data nodes from two dimensions of network latency time and historical transmission speed.

[0061] Specifically, when the first service node obtains the network latency time of each of the one or more data nodes it is connected to, it can first obtain the packet round-trip latency of each data node. The packet round-trip latency includes the current heartbeat packet round-trip latency and the reference first-packet round-trip latency. Among them, the current heartbeat packet round-trip latency can be denoted as heartbeat packet RTT (Round-Trip Time), which reflects the network latency when the first service node and the data node interact with the heartbeat packet. The reference first-packet round-trip latency can be denoted as first-packet RTT (Round-Trip Time), which reflects the network latency during the first block data synchronization process when the first service node and the data node perform block data synchronization within a recent period of time or a recent preset number of times. The network latency time of each data node can be determined based on the current heartbeat packet round-trip latency and the reference first-packet round-trip latency of each data node.

[0062] In some feasible embodiments, the specific manner for the first service node to obtain the packet round-trip latency of each connected data node may include:

[0063] The first service node can periodically send heartbeat packets to each of the connected data nodes, for example, once every 2 seconds, and determine the current heartbeat packet round-trip latency (i.e., heartbeat packet RTT) of each data node based on the sending time of the most recent heartbeat packet and the response time of each data node to this heartbeat packet; the first service node can obtain the historical first-packet round-trip latency of each data node, for example, the network latency during the first block data synchronization process when performing block data synchronization within a recent period of time or a recent preset number of times. The network latency can be the time difference from initiating a block data synchronization request to receiving the first block data, and determine the reference first-packet round-trip latency of each data node based on the historical first-packet round-trip latency. For example, the average of the historical first-packet round-trip latency recorded in the most recent 10 minutes or the historical first-packet round-trip latency recorded in the most recent 30 times can be used as the currently used reference first-packet round-trip latency.

[0064] In some feasible embodiments, the network latency time of the data node can be denoted as Smoothed Round-Trip Time (SRTT), and SRTT is obtained by comprehensively calculating the heartbeat packet RTT and the first-packet RTT. The specific implementation manner for the first service node to determine the network latency time of each data node based on the current heartbeat packet round-trip latency and the reference first-packet round-trip latency of each data node may include: obtaining the first weight corresponding to the current heartbeat packet round-trip latency and the second weight corresponding to the reference first-packet round-trip latency; determining the network latency time of each data node based on the current heartbeat packet round-trip latency of each data node, the first weight, the reference first-packet round-trip latency of each data node, and the second weight. It can be expressed by the formula as follows:

[0065] Among them, SRTT = (α * heartbeat RTT) + ((1 - α) * first packet RTT), where the value range of α can be [0, 1], the default value can be 0.5, or other values between 0 and 1. α corresponds to the above-mentioned first weight, and (1 - α) corresponds to the above-mentioned second weight.

[0066] 302. Determine the historical transmission speed of each data node according to the data transmission records with each data node.

[0067] Specifically, when the first service node obtains the historical transmission speed of each data node among one or more connected data nodes, it can obtain the data transmission records with each data node. The data transmission records include the amount of block data transmitted and the transmission time. Determine the historical transmission speed of each data node according to the amount of block data transmitted and the transmission time. For example, the ratio between the amount of block data transmitted and the transmission time can be used as the historical transmission speed.

[0068] In some feasible implementation manners, the first service node can obtain the amount of block data transmitted and the transmission time of the transmission with each data node within a recent period of time or within a recent preset number of times, calculate the transmission speed of each data transmission, and use the average transmission speed obtained by averaging multiple transmission speeds as the historical transmission speed of each data node.

[0069] In some feasible implementation manners, before obtaining the network quality score of the data node and determining the target data node, it can be first determined whether the service node has a need to synchronize blocks. Specifically, after the consensus node of the core network packages a transaction into a block for consensus accounting, the data nodes of the data network can obtain the latest packaged block data from the core network and store it, and then notify the connected service nodes that a new block has been generated. Specifically, the block height of the new block (denoted as the target block height) can be notified to the first service node. Then the first service node can receive the target block height sent by the data node and determine whether the block data corresponding to the target block height is stored locally, that is, whether the block data corresponding to the target block height has been synchronized. If not, it means that the block data corresponding to the target block height has not been synchronized yet. The first service node needs to obtain the network quality scores of each data node and determine the target data node to synchronize the block data, that is, execute steps 303-308; if the block data corresponding to the target block height is already stored locally, it means that the latest block data has been synchronized. At this time, steps 303-308 can be not executed, and only the network delay time and historical transmission speed of each data node need to be recorded for use when subsequent block data synchronization is required.

[0070] 303. Obtain the first scoring rule corresponding to the network latency and the second scoring rule corresponding to the transmission speed.

[0071] 304. Determine the network latency score according to the first scoring rule and the network latency time of each data node connected to the first service node.

[0072] 305. Determine the transmission speed score according to the second scoring rule and the historical transmission speed of each data node.

[0073] Specifically, the first service node can quantitatively represent the network conditions of each connected data node through a scoring mechanism. Scoring rules can be set for network state parameters, and different scoring rules can be set for network state parameters in different dimensions. For example, the network latency can correspond to the first scoring rule, and the transmission speed can correspond to the second scoring rule. After the first service node obtains the network latency time and historical transmission speed of each data node, it can determine the network latency score according to the first scoring rule and the network latency time of each data node, and determine the transmission speed score according to the second scoring rule and the historical transmission speed of each data node, so as to quantitatively represent the network conditions of the data nodes in two dimensions of network latency and transmission speed respectively.

[0074] In some feasible implementation manners, the first scoring rule corresponding to the network latency may include multiple time intervals and the scoring algorithm corresponding to each time interval. Then the specific implementation manner for the first service node to determine the network latency score may include: obtaining the target time interval corresponding to the network latency time of each data node connected to the first service node in the first scoring rule, and determining the network latency score of each data node according to the scoring algorithm corresponding to the target time interval and the network latency time.

[0075] For example, the multiple time intervals included in the first scoring rule and the scoring algorithm corresponding to each time interval can be shown in Table 1. Among the scores corresponding to different time intervals, the higher the network latency time SRTT, the larger the corresponding integral value. Specifically as follows:

[0076]

[0077]

[0078] Table 1

[0079] Among them, the first scoring rule can be specified as follows:

[0080] According to the feedback from the existing network, 80% of the network delay time SRTT is within 0 - 40ms, and 10% of the network delay time SRTT is within 40 - 100ms, indicating low network delay. At the same time, the integral value design for this part has little difference. The scoring algorithms corresponding to the time intervals 0 - 40ms, 40ms - 70ms, and 70 - 100ms are constant 1 point, 2 points, and 3 points respectively;

[0081] When SRTT > 100ms, it indicates that the network condition is poor, and the integral value design for this part has a large difference. For example, when 100ms <= SRTT < 140ms, the corresponding scoring algorithms are constant 6 points, and when 140ms <= SRTT, the corresponding scoring algorithms are constant 9 points. That is, the larger the integral, the higher the network delay and the worse the network condition.

[0082] In some feasible implementation manners, the second scoring rule corresponding to the transmission speed may include multiple speed ratio intervals and the scoring algorithms corresponding to each speed ratio interval. Then the specific implementation manner for the first service node to determine the transmission speed score may include: obtaining the target speed ratio between the historical transmission speed of each data node and the target expected transmission speed; obtaining the target speed ratio interval corresponding to the target speed ratio in the second scoring rule; and determining the transmission speed score of each data node according to the scoring algorithm corresponding to the target speed ratio interval and the target speed ratio.

[0083] For the calculation of the transmission speed score, the following design idea can be adopted:

[0084] If the historical transmission speed is extremely poor, at this time, increase the score of the speed, give a penalty, and reduce the scheduling weight of the data node;

[0085] If the historical transmission speed is average, at this time, the score of the speed can be defaulted to 0, and at this time, the scheduling of the data node mainly depends on the score of the network delay time SRTT;

[0086] If the historical transmission speed is extremely fast, at this time, reduce the score of the speed, give a reward, and increase the scheduling weight of the data node.

[0087] At the same time, the service node can introduce the target expected transmission speed target as a measurement standard. The target expected transmission speed target can be, for example, 1Mps. In this way, the speed ratio ratio can be calculated, where ratio = (historical transmission speed / target expected transmission speed target) * 100. Here, according to the result of ratio, the historical transmission speed is divided into the following situations:

[0088] (1) ratio < ratio1, that is, the historical transmission speed is extremely poor. At this time, increase the score for speed, impose a penalty, and reduce the scheduling weight of the data node. The corresponding scoring algorithm is: (100 - ratio) * Score1;

[0089] (2) ratio1 <= ratio <= ratio2, that is, the historical transmission speed is average. The corresponding scoring algorithm is: ratio * Score2;

[0090] (3) ratio > ratio2, that is, the historical transmission speed is very fast. At this time, reduce the score for speed and increase the scheduling weight of the data node. The corresponding scoring algorithm is: -1 * ratio * Score3;

[0091] The default values of the above parameters can be as follows: the target expected transmission speed target is 1 Mps, ratio1 is 75, ratio2 is 100, Scroe1 is 5, Score2 is 0, and Score3 is 2. For example, if the historical transmission speed of a certain data node is 1.5 Mbps, then the corresponding target speed ratio ratio is (1.5 Mbps / 1 Mps) * 100 = 150. Since 150 is greater than ratio2 (i.e., 100), the transmission speed score is -1 * ratio * Score3 = -1 * 150 * 2 = -300 points; Another example, if the historical transmission speed of a certain data node is 800 Kbps, then the corresponding target speed ratio ratio is (800 Kbps / 1 Mps) * 100 = 80. Since 150 is greater than ratio1 (i.e., 75) and less than ratio2 (i.e., 100), the transmission speed score is ratio * Score2 = 80 * 0 = 0 points; Another example, if the historical transmission speed of a certain data node is 400 Kbps, then the corresponding target speed ratio ratio is (400 Kbps / 1 Mps) * 100 = 40. Since 40 is less than ratio1 (i.e., 75), the transmission speed score is (100 - ratio) * Score1 = (100 - 40) * 5 = 300 points; It can be seen that the faster the historical transmission speed, the lower the transmission speed score, and the slower the historical transmission speed, the higher the transmission speed score.

[0092] In some feasible embodiments, when the historical transmission speed of the data node is relatively average, for example, the corresponding speed ratio is between the first speed ratio (such as ratio1) and the second speed ratio (such as ratio2), the transmission speed score can be 0. At this time, the network quality score of this data node is equal to the network latency score. That is, when the historical transmission speeds of multiple data nodes are all average, data nodes can be selected for block data synchronization only based on network latency. For example, the data node with the shortest network latency is preferentially selected.

[0093] In some feasible embodiments, the opposite design can also be adopted, that is, the faster the historical transmission speed, the higher the transmission speed score, and the slower the historical transmission speed, the lower the transmission speed score; correspondingly, the longer the network delay time SRTT, the lower the network delay score, and the shorter the network delay time SRTT, the higher the network delay score. The corresponding preset condition can be adjusted to the maximum network quality score, or the network quality score is greater than or equal to the preset score threshold.

[0094] 306. Determine the network quality score of each data node according to the network delay score and the transmission speed score.

[0095] Specifically, the first service node can obtain the third weight corresponding to the network delay and the fourth weight corresponding to the transmission speed, and determine the network quality score of each data node according to the network delay score of each data node, the third weight, the transmission speed score of each data node, and the fourth weight.

[0096] In some feasible embodiments, the third weight and the fourth weight can be equal, both being 0.5. Then the service node can take the average of the network delay score and the transmission speed score, and the final network quality score = (network delay score + transmission speed score) / 2.

[0097] In some feasible embodiments, the fourth weight can be greater than the third weight, that is, to increase the proportion of the transmission speed score in the network quality score and improve the influence of the historical transmission speed on the selection of data nodes to ensure speed priority.

[0098] 307. Determine multiple candidate data nodes whose network quality scores meet the preset conditions from each data node connected to the first service node.

[0099] 308. Obtain the service load status of each candidate data node among the multiple candidate data nodes, and determine the target data node from the multiple candidate data nodes according to the service load status.

[0100] Specifically, if the network quality scores of multiple data nodes among the data nodes connected to the first service node meet the preset conditions, or in other words, the network quality scores of multiple data nodes are equal, the first service node can further determine the most suitable target data node in combination with the service load status of the data nodes. Among them, the service load status of the data node can include the number of connections for which the data node currently provides synchronization services, the consumption of hardware resources of the data node, etc. Thus, after filtering out data nodes with better network conditions based on network performance, a relatively idle data node can be selected according to the current load situation of the data node. For example, the candidate data node with the smallest current service load among multiple candidate data nodes can be used as the target data node, thereby further improving the synchronization efficiency of block data, enhancing the utilization rate of various resources in the blockchain network, and also avoiding access overload of a single data node.

[0101] It can be understood that the service node establishes a scoring mechanism for network quality through two dimensions of network delay time SRTT and historical transmission speed, which can accurately reflect the network condition of the blockchain. By the historical transmission speed, the inaccurate packet loss rate can be eliminated, and the transmission speed of the data node can be more accurately evaluated. Among the speed performance and network delay, the block data transmission speed can directly reflect the quality of the blockchain data node, and this needs to be fed back as soon as possible in the final network quality score. Therefore, in the calculation of the network delay integral and the transmission speed integral, the weight of the transmission speed integral will be relatively large, belonging to the type of speed priority. If the speed is very fast, the data node with a fast transmission speed will be preferentially scheduled. If the speed is average, at this time, the data node with the smallest network delay will be preferentially scheduled. If both the speed and the network delay performance are very poor, at this time, the one with the smallest network quality score will be preferentially scheduled, so as to make full use of the network resources and the computing resources of the node itself, and to a certain extent, improve the processing speed of transactions and the speed of block synchronization.

[0102] In the embodiment of the present application, the first service node of the blockchain network may determine the network delay time of each data node according to the round-trip delay of data packets of each connected data node, determine the historical transmission speed of each data node according to the data transmission records between each data node, determine the network delay score by using the first scoring rule corresponding to the network delay and the network delay time of each data node, determine the transmission speed score by using the second scoring rule corresponding to the transmission speed and the historical transmission speed of each data node, and then determine the network quality score of each data node according to the network delay score and the transmission speed score, so as to accurately reflect the network status of the data nodes in the blockchain from two dimensions of network delay and transmission speed. The inaccurate packet loss rate can be eliminated through the historical transmission speed, and the transmission speed of the data node can be evaluated more accurately. Then, the first service node may determine multiple candidate data nodes whose network quality scores meet the preset conditions from the connected data nodes, and then determine the target data node according to the service load status of each candidate data node. It can be seen that the service node can select the data node with the best network status and the smallest service load from the multiple connected data nodes to provide block synchronization services, which can make full use of the network resources of the blockchain network and thus effectively improve the synchronization efficiency of block data.

[0103] Please refer to Figure 4 , which is a schematic structural diagram of a data processing device according to an embodiment of the present application. The data processing device according to the embodiment of the present application may be applied to the above-mentioned service node. The device includes:

[0104] An obtaining module 401, configured to obtain network status data of the blockchain network. The network status data includes one or both of the first network status recorded by the first service node and the second network status recorded by the second service node in the blockchain network. The first network status includes network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes network status parameters of each data node connected to the second service node in the blockchain network. The network status parameters include one or both of the network delay time and the historical transmission speed.

[0105] A determining module 402, configured to determine the network quality score of each data node connected to the first service node according to the network status data.

[0106] The determining module 402 is further configured to determine a target data node whose network quality score meets a preset condition from each data node connected to the first service node. The target data node is used to provide block data to be synchronized.

[0107] Optionally, the network status parameter includes network latency time and historical transmission speed. The obtaining module 401 is specifically configured to:

[0108] Determine the network latency time of each data node connected to the first service node in the blockchain network according to the round-trip latency of data packets of each data node.

[0109] Determine the historical transmission speed of each data node according to the data transmission records between the obtaining module and each data node.

[0110] Optionally, the obtaining module 401 is specifically further configured to:

[0111] Send a network status obtaining request to a second service node of the blockchain network, where the second service node includes one or more service nodes in the blockchain network other than the first service node.

[0112] Receive a response data packet sent by the second service node in response to the network status obtaining request, where the response data packet carries the signature information of the second service node and the second network status recorded by the second service node.

[0113] After the signature information is verified to be passed, obtain the second network status from the response data packet.

[0114] Optionally, the obtaining module 401 is specifically further configured to:

[0115] Send a block height obtaining request to a second service node of the blockchain network.

[0116] Receive block height information sent by the second service node in response to the block height obtaining request, where the block height information is used to indicate the storage location of the second network status in the blockchain.

[0117] Obtain the second network status from the blockchain by using the block height information.

[0118] Optionally, the obtaining module 401 is specifically configured to:

[0119] Obtain the round-trip latency of data packets of each data node connected to the first service node in the blockchain network, where the round-trip latency of data packets includes the current round-trip latency of heartbeat packets and the reference round-trip latency of the first packet.

[0120] Determine the network latency time of each data node according to the current round-trip latency of heartbeat packets and the reference round-trip latency of the first packet of each data node.

[0121] Optionally, the obtaining module 401 is specifically configured to:

[0122] Send heartbeat packets to each data node connected to the first service node in the blockchain network.

[0123] Determine the current round-trip latency of the heartbeat packet for each data node according to the sending time of the heartbeat packet and the response time of each data node to the heartbeat packet.

[0124] Obtain the historical round-trip latency of the first packet for each data node, and determine the reference round-trip latency of the first packet for each data node according to the historical round-trip latency of the first packet.

[0125] Optionally, the obtaining module 401 is specifically configured to:

[0126] Obtain a first weight corresponding to the current round-trip latency of the heartbeat packet and a second weight corresponding to the reference round-trip latency of the first packet.

[0127] Determine the network delay time for each data node according to the current round-trip latency of the heartbeat packet for each data node, the first weight, the reference round-trip latency of the first packet for each data node, and the second weight.

[0128] Optionally, the obtaining module 401 is specifically configured to:

[0129] Obtain the data transmission records between the first service node and each data node, where the data transmission records include the amount of block data transmitted and the transmission time.

[0130] Determine the historical transmission speed of each data node according to the amount of block data transmitted and the transmission time.

[0131] Optionally, the determining module 402 is specifically configured to:

[0132] Obtain a first scoring rule corresponding to the network delay and a second scoring rule corresponding to the transmission speed.

[0133] Determine the network delay score according to the first scoring rule and the network delay time of each data node connected to the first service node.

[0134] Determine the transmission speed score according to the second scoring rule and the historical transmission speed of each data node.

[0135] Determine the network quality score of each data node according to the network delay score and the transmission speed score.

[0136] Optionally, the determining module 402 is specifically configured to:

[0137] Obtain a third weight corresponding to the network delay and a fourth weight corresponding to the transmission speed.

[0138] Determine the network quality score of each data node according to the network latency score of each data node, the third weight, the transmission speed score of each data node, and the fourth weight.

[0139] Optionally, the first scoring rule includes multiple time intervals and a scoring algorithm corresponding to each time interval. The determining module 402 is specifically configured to:

[0140] Obtain the target time interval corresponding to the network latency time of each data node connected to the first service node in the first scoring rule.

[0141] Determine the network latency score of each data node according to the scoring algorithm corresponding to the target time interval and the network latency time.

[0142] Optionally, the second scoring rule includes multiple speed ratio intervals and a scoring algorithm corresponding to each speed ratio interval. The determining module 402 is specifically configured to:

[0143] Obtain the target speed ratio between the historical transmission speed and the target expected transmission speed of each data node.

[0144] Obtain the target speed ratio interval corresponding to the target speed ratio in the second scoring rule.

[0145] Determine the transmission speed score of each data node according to the scoring algorithm corresponding to the target speed ratio interval and the target speed ratio.

[0146] Optionally, the determining module 402 is specifically configured to:

[0147] Determine multiple candidate data nodes whose network quality scores meet the preset conditions from each data node connected to the first service node.

[0148] Obtain the service load status of each candidate data node among the multiple candidate data nodes.

[0149] Determine the target data node from the multiple candidate data nodes according to the service load status.

[0150] Optionally, the apparatus further includes a receiving module 403, where:

[0151] The receiving module 403 is configured to receive the target block height sent by any data node connected to the first service node.

[0152] The determining module 402 is further configured to determine whether block data corresponding to the target block height is stored; if not, determine the network quality score of each data node connected to the first service node according to the network status data.

[0153] Optionally, the apparatus further includes a sending module 404, where:

[0154] The sending module 404 is configured to send a block data synchronization request to the target data node, where the block data synchronization request carries the target block height.

[0155] The receiving module 403 is further configured to receive the block data corresponding to the target block height sent by the target data node in response to the block data synchronization request.

[0156] It should be noted that the functions of the functional modules of the data processing apparatus in the embodiments of the present application can be specifically implemented according to the methods in the foregoing method embodiments, and the specific implementation process can refer to the relevant descriptions of the foregoing method embodiments, which will not be elaborated herein.

[0157] Please refer to Figure 5 , which is a schematic structural diagram of a computer device according to an embodiment of the present application. The computer device in the embodiment of the present application includes a power supply module and other structures, and includes a processor 501, a storage device 502, and a network interface 503. Data can be exchanged between the processor 501, the storage device 502, and the network interface 503.

[0158] The storage device 502 may include a volatile memory, such as a random-access memory (RAM); the storage device 502 may also include a non-volatile memory, such as a flash memory, a solid-state drive (SSD), etc.; the storage device 502 may also include a combination of the above types of memories.

[0159] The processor 501 may be a central processing unit (CPU). In one embodiment, the processor 501 may also be a Graphics Processing Unit (GPU). The processor 501 may also be a combination of a CPU and a GPU. In one embodiment, the storage device 502 is used to store program instructions, and the processor 501 may call the program instructions to perform the following operations:

[0160] Obtain the network status data of the blockchain network, where the network status data includes one or both of the first network status recorded by the first service node and the second network status recorded by the second service node of the blockchain network. The first network status includes the network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes the network status parameters of each data node connected to the second service node in the blockchain network. The network status parameters include one or both of the network delay time and the historical transmission speed.

[0161] Determine the network quality score of each data node connected to the first service node according to the network status data.

[0162] Determine target data nodes whose network quality scores meet the preset conditions from each data node connected to the first service node. The target data nodes are used to provide block data to be synchronized.

[0163] Optionally, the network status parameters include the network delay time and the historical transmission speed. The processor 501 is specifically configured to:

[0164] Determine the network delay time of each data node according to the round-trip delay of data packets of each data node connected to the first service node in the blockchain network.

[0165] Determine the historical transmission speed of each data node according to the data transmission records between each data node.

[0166] Optionally, the processor 501 is specifically further configured to:

[0167] Call the network interface 503 to send a network status acquisition request to the second service node of the blockchain network. The second service node includes one or more service nodes in the blockchain network other than the first service node.

[0168] Call the network interface 503 to receive a response data packet sent by the second service node in response to the network status acquisition request. The response data packet carries the signature information of the second service node and the second network status recorded by the second service node.

[0169] After the signature information is verified to be passed, obtain the second network status from the response data packet.

[0170] Optionally, the processor 501 is specifically further configured to:

[0171] Call the network interface 503 to send a block height acquisition request to the second service node of the blockchain network.

[0172] Invoke the network interface 503 to receive the block height information sent by the second service node in response to the block height acquisition request, where the block height information is used to indicate the storage location of the second network state in the blockchain.

[0173] Use the block height information to obtain the second network state from the blockchain.

[0174] Optionally, the processor 501 is specifically configured to:

[0175] Obtain the packet round-trip delay of each data node connected to the first service node in the blockchain network, where the packet round-trip delay includes the current round-trip delay of the heartbeat packet and the reference round-trip delay of the first packet.

[0176] Determine the network delay time of each data node according to the current round-trip delay of the heartbeat packet and the reference round-trip delay of the first packet of each data node.

[0177] Optionally, the processor 501 is specifically configured to:

[0178] Invoke the network interface 503 to send heartbeat packets to each data node connected to the first service node in the blockchain network.

[0179] Determine the current round-trip delay of the heartbeat packet of each data node according to the sending time of the heartbeat packet and the response time of each data node to the heartbeat packet.

[0180] Obtain the historical round-trip delay of the first packet of each data node, and determine the reference round-trip delay of the first packet of each data node according to the historical round-trip delay of the first packet.

[0181] Optionally, the processor 501 is specifically configured to:

[0182] Obtain the first weight corresponding to the current round-trip delay of the heartbeat packet and the second weight corresponding to the reference round-trip delay of the first packet.

[0183] Determine the network delay time of each data node according to the current round-trip delay of the heartbeat packet of each data node, the first weight, the reference round-trip delay of the first packet of each data node, and the second weight.

[0184] Optionally, the processor 501 is specifically configured to:

[0185] Obtain the data transmission record between each data node, where the data transmission record includes the amount of block data transmitted and the transmission time.

[0186] Determine the historical transmission speed of each data node according to the transmitted block data volume and the transmission time.

[0187] Optionally, the processor 501 is specifically configured to:

[0188] Obtain a first scoring rule corresponding to network latency and a second scoring rule corresponding to transmission speed.

[0189] Determine the network latency score according to the first scoring rule and the network latency time of each data node connected to the first service node.

[0190] Determine the transmission speed score according to the second scoring rule and the historical transmission speed of each data node.

[0191] Determine the network quality score of each data node according to the network latency score and the transmission speed score.

[0192] Optionally, the processor 501 is specifically configured to:

[0193] Obtain a third weight corresponding to network latency and a fourth weight corresponding to transmission speed.

[0194] Determine the network quality score of each data node according to the network latency score of each data node, the third weight, the transmission speed score of each data node, and the fourth weight.

[0195] Optionally, the first scoring rule includes multiple time intervals and a scoring algorithm corresponding to each time interval. The processor 501 is specifically configured to:

[0196] Obtain the target time interval corresponding to the network latency time of each data node connected to the first service node in the first scoring rule.

[0197] Determine the network latency score of each data node according to the scoring algorithm corresponding to the target time interval and the network latency time.

[0198] Optionally, the second scoring rule includes multiple speed ratio intervals and a scoring algorithm corresponding to each speed ratio interval. The processor 501 is specifically configured to:

[0199] Obtain the target speed ratio between the historical transmission speed of each data node and the target expected transmission speed.

[0200] Obtain the target speed ratio interval corresponding to the target speed ratio in the second scoring rule.

[0201] Determine the transmission speed score of each data node according to the scoring algorithm corresponding to the target speed ratio range and the target speed ratio.

[0202] Optionally, the processor 501 is specifically configured to:

[0203] Determine multiple candidate data nodes whose network quality scores meet preset conditions from each data node connected to the first service node.

[0204] Obtain the service load status of each candidate data node among the multiple candidate data nodes.

[0205] Determine the target data node from the multiple candidate data nodes according to the service load status.

[0206] Optionally, the processor 501 is further configured to:

[0207] Call the network interface 503 to receive the target block height sent by any data node connected to the first service node.

[0208] Determine whether there is block data corresponding to the target block height stored; if not, determine the network quality scores of each data node connected to the first service node according to the network status data.

[0209] Optionally, the processor 501 is further configured to:

[0210] Call the network interface 503 to send a block data synchronization request to the target data node, where the block data synchronization request carries the target block height.

[0211] Call the network interface 503 to receive the block data corresponding to the target block height sent by the target data node in response to the block data synchronization request.

[0212] In specific implementation, the processor 501, the storage device 502, and the network interface 503 described in the embodiments of the present application may execute the implementation manners described in the relevant embodiments of the method provided by the embodiments of the present application Figures 2 to 3 and may also execute the implementation manners described in the relevant embodiments of the device provided by the embodiments of the present application Figure 4 which will not be elaborated herein.

[0213] In the above embodiments, the descriptions of the respective embodiments have their own emphases. For parts not elaborated in a certain embodiment, reference may be made to the relevant descriptions of other embodiments. Essentially, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc., specifically, the processor in the computer device) to execute all or part of the steps of the methods in the various embodiments of the present application. Among them, the aforementioned storage medium may include: various media that can store program codes, such as USB flash drives, mobile hard disks, magnetic disks, optical disks, read-only memory (English: Read-Only Memory, abbreviation: ROM), or random access memory (English: Random Access Memory, abbreviation: RAM).

[0214] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present application.

Claims

1. A data processing method based on a blockchain network, characterized in that, The first service node applied to the blockchain network, the method includes: Obtain the network status data of the blockchain network, where the network status data includes one or both of the first network status recorded by the first service node and the second network status recorded by the second service node in the blockchain network. The first network status includes the network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes the network status parameters of each data node connected to the second service node in the blockchain network. The network status parameters include one or both of network latency time and historical transmission speed; Determine the network quality score of each data node connected to the first service node according to the network status data; Determine the target data nodes whose network quality scores meet the preset conditions from each data node connected to the first service node. The target data nodes are used to provide the block data to be synchronized. The block data is obtained by the target data nodes from the consensus nodes of the blockchain network, and the block data is generated by the consensus nodes of the blockchain network through packaging transactions.

2. The method according to claim 1, wherein The network status parameters include network latency time and historical transmission speed. The obtaining of the network status data of the blockchain network includes: Determine the network latency time of each data node according to the round-trip delay of data packets of each data node connected to the first service node in the blockchain network; Determine the historical transmission speed of each data node according to the data transmission records between each data node.

3. The method according to claim 2, characterized in that, The obtaining of the network status data of the blockchain network further includes: Send a network status acquisition request to the second service node of the blockchain network. The second service node includes one or more service nodes in the blockchain network other than the first service node; Receive the response data packet sent by the second service node in response to the network status acquisition request. The response data packet carries the signature information of the second service node and the second network status recorded by the second service node; After the signature information is verified, obtain the second network status from the response data packet.

4. The method according to claim 2, characterized in that The second network status recorded by the second service node is stored in the blockchain. The obtaining of the network status data of the blockchain network further includes: Send a block height acquisition request to the second service node of the blockchain network; Receive the block height information sent by the second service node in response to the block height acquisition request. The block height information is used to indicate the storage location of the second network status in the blockchain; Obtain the second network status from the blockchain using the block height information.

5. The method according to claim 2, wherein The determining of the network latency time of each data node according to the round-trip delay of data packets of each data node connected to the first service node in the blockchain network includes: Obtain the round-trip delay of data packets for each data node connected to the first service node in the blockchain network, where the round-trip delay of the data packet includes the current round-trip delay of the heartbeat packet and the reference round-trip delay of the first packet; Determine the network delay time of each data node according to the current round-trip delay of the heartbeat packet and the reference round-trip delay of the first packet of each data node.

6. The method according to claim 4, wherein The obtaining of the round-trip delay of data packets for each data node connected to the first service node in the blockchain network includes: Send a heartbeat packet to each data node connected to the first service node in the blockchain network; Determine the current round-trip delay of the heartbeat packet for each data node according to the sending time of the heartbeat packet and the response time of each data node to the heartbeat packet; Obtain the historical round-trip delay of the first packet for each data node, and determine the reference round-trip delay of the first packet for each data node according to the historical round-trip delay of the first packet.

7. The method according to claim 5, characterized in that, The determining of the network delay time of each data node according to the current round-trip delay of the heartbeat packet and the reference round-trip delay of the first packet of each data node includes: Obtain the first weight corresponding to the current round-trip delay of the heartbeat packet and the second weight corresponding to the reference round-trip delay of the first packet; Determine the network delay time of each data node according to the current round-trip delay of the heartbeat packet of each data node, the first weight, the reference round-trip delay of the first packet of each data node, and the second weight.

8. The method according to claim 2, wherein The determining of the historical transmission speed of each data node according to the data transmission record with each data node includes: Obtain the data transmission record with each data node, where the data transmission record includes the amount of block data transmitted and the transmission time; Determine the historical transmission speed of each data node according to the amount of block data transmitted and the transmission time.

9. The method according to any one of claims 1 to 7, characterized in that The determining of the network quality score of each data node connected to the first service node according to the network status data includes: Obtain the first scoring rule corresponding to the network delay and the second scoring rule corresponding to the transmission speed; Determine the network delay score according to the first scoring rule and the network delay time of each data node connected to the first service node; Determine the transmission speed score according to the second scoring rule and the historical transmission speed of each data node; Determine the network quality score of each data node according to the network delay score and the transmission speed score.

10. The method according to claim 9, characterized in that, The determining of the network quality score of each data node according to the network delay score and the transmission speed score includes: Obtain the third weight corresponding to the network delay and the fourth weight corresponding to the transmission speed; Determine the network quality score of each data node according to the network delay score of each data node, the third weight, the transmission speed score of each data node, and the fourth weight.

11. The method according to claim 9, wherein The first scoring rule includes multiple time intervals and the scoring algorithm corresponding to each time interval. The determining of the network delay score according to the first scoring rule and the network delay time of each data node connected to the first service node includes: Obtain the target time interval corresponding to the network latency time of each data node connected to the first service node in the first scoring rule; Determine the network latency score of each data node according to the scoring algorithm corresponding to the target time interval and the network latency time.

12. The method according to claim 9, wherein The second scoring rule includes multiple speed ratio intervals and the scoring algorithm corresponding to each speed ratio interval. The determining the transmission speed score according to the second scoring rule and the historical transmission speed of each data node includes: Obtain the target speed ratio between the historical transmission speed of each data node and the target expected transmission speed; Obtain the target speed ratio interval corresponding to the target speed ratio in the second scoring rule; Determine the transmission speed score of each data node according to the scoring algorithm corresponding to the target speed ratio interval and the target speed ratio.

13. The method according to any one of claims 1 to 7, characterized in that, The determining the target data node whose network quality score meets the preset condition from each data node connected to the first service node includes: Determine multiple candidate data nodes whose network quality scores meet the preset condition from each data node connected to the first service node; Obtain the service load status of each candidate data node among the multiple candidate data nodes; Determine the target data node from the multiple candidate data nodes according to the service load status.

14. The method according to claim 1, characterized in that, Before determining the network quality score of each data node connected to the first service node according to the network status data, the method further includes: Receive the target block height sent by any data node connected to the first service node; Determine whether there is block data corresponding to the target block height stored; If not, execute the step of determining the network quality score of each data node connected to the first service node according to the network status data.

15. The method according to claim 1 or 14, characterized in that, After determining the target data node whose network quality score meets the preset condition from each data node connected to the first service node, the method further includes: Send a block data synchronization request to the target data node, where the block data synchronization request carries the target block height; Receive the block data corresponding to the target block height sent by the target data node in response to the block data synchronization request.

16. A data processing device, characterized in that, The apparatus includes: An obtaining module, configured to obtain network status data of a blockchain network, where the network status data includes one or both of a first network status recorded by a first service node of the blockchain network and a second network status recorded by a second service node of the blockchain network. The first network status includes network status parameters of each data node connected to the first service node in the blockchain network, and the second network status includes network status parameters of each data node connected to the second service node in the blockchain network. The network status parameters include one or both of network latency time and historical transmission speed; A determining module, configured to determine the network quality score of each data node connected to the first service node according to the network status data; The determining module is further configured to determine, from each data node connected to the first service node, a target data node whose network quality score meets a preset condition, where the target data node is used to provide block data to be synchronized, the block data is obtained by the target data node from a consensus node of the blockchain network, and the block data is generated by the consensus node of the blockchain network by packing transactions.

17. A computer device, characterized in that, The computer device includes a processor, a network interface, and a storage device, where the processor, the network interface, and the storage device are interconnected. Among them, the network interface is controlled by the processor to send and receive data, the storage device is used to store a computer program, the computer program includes program instructions, and the processor is configured to call the program instructions to execute the data processing method according to any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program includes program instructions, and the program instructions are executed by a processor to execute the data processing method according to any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a computer processor, it implements the data processing method according to any one of claims 1 to 15.

Images