CN116074331A

CN116074331A - Block data synchronization method and related product

Info

Publication number: CN116074331A
Application number: CN202111295745.1A
Authority: CN
Inventors: 刘攀
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-11-03
Filing date: 2021-11-03
Publication date: 2023-05-05

Abstract

The application belongs to the technical field of blockchain, and particularly relates to a block data synchronization method, a block data synchronization device, a computer readable medium, electronic equipment and a computer program product. The block data synchronization method comprises the following steps: acquiring a plurality of data nodes in a communication connection state, wherein the data nodes are block chain nodes for providing block data reading service; respectively counting the round trip delay and the packet loss rate of each data node for data communication; determining evaluation information of each data node according to the round trip delay and the packet loss rate, wherein the evaluation information is used for representing real-time communication quality of the data node; and selecting a target node from the plurality of data nodes according to the evaluation information, and sending a block data synchronization request to the target node according to the block height. The method and the device can improve the synchronization efficiency and accuracy of the block data.

Description

Block data synchronization method and related product

Technical Field

The application belongs to the technical field of blockchain, and particularly relates to a block data synchronization method, a block data synchronization device, a computer readable medium, electronic equipment and a computer program product.

Background

Blockchain is a technical solution in which a reliable database is maintained by a large number of blockchain nodes together in a decentralised, distrusted manner. When new block data is generated on the blockchain network, data synchronization needs to be performed on each blockchain node. Because of numerous block chain link points and wide distribution, how to perform high-efficiency and accurate data synchronization is a problem to be solved at present.

Disclosure of Invention

The present invention provides a block data synchronization method, a block data synchronization device, a computer readable medium, an electronic device and a computer program product, which overcome at least to some extent the technical problem of low data synchronization efficiency in the related art.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned in part by the practice of the application.

According to an aspect of the embodiments of the present application, there is provided a block data synchronization method, including:

acquiring a plurality of data nodes in a communication connection state, wherein the data nodes are block chain nodes for providing block data reading service;

respectively counting the round trip delay and the packet loss rate of each data node for data communication;

Determining evaluation information of each data node according to the round trip delay and the packet loss rate, wherein the evaluation information is used for representing real-time communication quality of the data node;

and selecting a target node from the plurality of data nodes according to the evaluation information, and sending a block data synchronization request to the target node according to the block height.

According to an aspect of the embodiments of the present application, there is provided a block data synchronization apparatus, including:

an acquisition module configured to acquire a plurality of data nodes in a communication connection state, the data nodes being blockchain nodes for providing a blockdata reading service;

the statistics module is configured to respectively count round trip delay and packet loss rate of data communication of each data node;

an evaluation module configured to determine evaluation information of each data node according to the round trip delay and the packet loss rate, wherein the evaluation information is used for representing real-time communication quality of the data node;

and the request module is configured to select a target node from the plurality of data nodes according to the evaluation information and send a block data synchronization request to the target node according to the block height.

In some embodiments of the present application, based on the above technical solutions,

according to an aspect of the embodiments of the present application, there is provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a block data synchronization method as in the above technical solution.

According to an aspect of the embodiments of the present application, there is provided an electronic device including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the block data synchronization method as in the above technical solution via execution of the executable instructions.

According to an aspect of embodiments of the present application, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the block data synchronization method as in the above technical solution.

In the technical scheme provided by the embodiment of the application, by acquiring a plurality of data nodes for data communication with the current block chain node and respectively counting round trip delay and packet loss rate for each data node, the real-time communication quality of data communication between each data node and the current block chain node can be obtained, and then the target node with higher real-time communication quality is selected for data synchronization, so that the synchronization efficiency and accuracy of block data can be improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is apparent that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art.

FIG. 1 illustrates a schematic composition of a blockchain system in an embodiment of the present application.

FIG. 2 illustrates the constituent structure of a blockchain maintained on a blockchain network.

Fig. 3 shows a network architecture of a blockchain network to which the technical scheme of the present application is applied.

Fig. 4 is a flowchart illustrating steps of a block data synchronization method in one embodiment of the present application.

Figure 5 illustrates a flow chart of steps for data statistics for individual data nodes in one embodiment of the present application.

Figure 6 shows a flow chart of steps for counting round trip delays for a data node in one embodiment of the present application.

Fig. 7 shows a schematic diagram of the principle of counting round trip delay in one embodiment of the present application.

Fig. 8 is a flowchart illustrating steps for aggregating packet loss rates of data nodes in one embodiment of the present application.

Fig. 9 is a flowchart illustrating steps for determining a packet loss rate in one embodiment of the present application.

FIG. 10 is a flowchart illustrating steps for determining data node evaluation information in one embodiment of the present application.

Figure 11 illustrates a round trip delay integration model in one embodiment of the present application.

Fig. 12 illustrates a packet loss rate integration model in one embodiment of the present application.

Fig. 13 is a block diagram of a block data synchronization apparatus according to an embodiment of the present application.

Fig. 14 shows a block diagram of a computer system suitable for use in implementing embodiments of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the present application. One skilled in the relevant art will recognize, however, that the aspects of the application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the application.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

Blockchains are a shared, fake-proof, tamper-proof and traceable digital ledger with block-chained data structure (charged-block data structure) built with transparent and trusted rules in a peer-to-peer network environment. A block chain data structure is a data structure in which transactions occurring over a period of time are stored in blocks, and the blocks are chronologically connected into a chain by a cryptographic algorithm. The ledger is distributed to all member nodes in the network, and the history of asset transactions occurring between peer nodes in the network is permanently recorded in a sequential chain of blocks linked by a hash cryptographic algorithm. All validated and verified transactions are linked from the first linear chain of chains to the most current block, thus denominating a blockchain. The blockchain may act as a single source of facts and members of the blockchain network can only view transactions that are related to them.

Fig. 1 illustrates a schematic diagram of the components of a blockchain system in an embodiment of the present application, the blockchain system 100 may include at least one client 110 and a blockchain network 120, the blockchain network 120 including at least one blockchain node 121. The client 110 may be various electronic devices such as a smart phone, a tablet computer, a notebook computer, a desktop computer, an intelligent wearable device, an intelligent vehicle-mounted device, an intelligent payment terminal, a face recognition terminal, etc., and may provide a blockchain data service to a user by installing a corresponding client application program. The blockchain node 121 may be a terminal device or a server, for example, the blockchain node 121 may be an independent physical server, a server cluster formed by a plurality of physical servers, or a cloud server that provides cloud computing services.

In the blockchain network 120, each blockchain node 121 may receive input information during normal operation and maintain shared data within the blockchain network based on the received input information. To ensure information interworking, there may be information connections between the various blockchain nodes 121, and the various blockchain nodes 121 may communicate information with each other via the information connections. For example, when any blockchain node 121 in the blockchain network 120 receives input information and broadcasts the input information in the blockchain network 120, other node devices in the blockchain network 120 may obtain the input information according to a consensus algorithm and store the input information as shared data.

For each blockchain node 121 in the blockchain network 120, there is a node identification corresponding thereto, and each blockchain node 121 in the blockchain network 120 may store node identifications of other blockchain nodes in the same blockchain network for subsequent broadcasting of the generated block to other nodes in the blockchain network 120 based on the node identifications of the other blockchain nodes. The blockchain node 121 may maintain a node identifier list as shown in table 1, and store the node name and the node identifier in the node identifier list. The node identifier may be an IP (Internet Protocol, protocol of interconnection between networks) address and any other information that can be used to identify the node, and table 1 is a list of node identifiers for example of IP addresses.

TABLE 1

Node name	Node identification
		Node
1	117.114.151.174
		Node 2	117.116.189.145
…	…
		Node N	119.123.789.258

FIG. 2 illustrates the constituent structure of a blockchain maintained on a blockchain network. As shown in fig. 2, the blockchain is composed of a plurality of blocks connected in sequence, and whenever new data needs to be written into the blockchain, the data is summarized into a newly generated block, the newly generated block is linked to the end of the blockchain, and the newly added block on each node device 121 can be guaranteed to be identical through a consensus algorithm. The data of the current block is recorded in the block body of each block, and the Hash value (Hash) of the previous block connected with the current block is stored in the block head of each block, and if the transaction data in the previous block changes, the Hash value of the current block also changes. Therefore, the data uploaded into the blockchain network is difficult to tamper, and the reliability of the shared data can be improved.

Fig. 3 shows a network architecture of a blockchain network to which the technical scheme of the present application is applied. As shown in fig. 3, the blockchain network to which the technical solution of the present application is applied adopts a hierarchical model, and specifically includes a core network 310, a data node network 320, and a service network 330.

The core network 310 is composed of consensus nodes 311 responsible for the consensus of the blockchain network, packaging transactions into blocks and accounting for the consensus. The consensus node 311 is a node having accounting rights generated by blockchain nodes in the blockchain network by voting or alternatively designating.

The data node network 320 is composed of data nodes 321, and is responsible for synchronizing account information of the core network 310, i.e. synchronizing the latest block data, and providing data reading services to the service network 330.

The service network 330 is composed of service nodes 331 or light nodes 332, and is responsible for synchronizing the block data of the service itself from the data node network 320 and performing data isolation by the data node network 320. Service node 331 is a node in direct communication connection with the user terminal device, on which a complete blockchain copy including a block header and a block body is stored, and can independently provide blockchain service to users. The lightweight nodes 332 are lightweight nodes, specifically nodes that do not store or maintain a complete blockchain copy, but only store a minimal amount of state as a node to send or communicate transaction information; the light node 332 may store only the block header data of each block in the block chain, and when receiving a service request initiated by a user to query specific block data, the light node 332 may implement data interaction with the adjacent service node 331, so as to indirectly provide service to the user.

With the network hierarchy, each layer of network can be infinitely extended, especially a service network. The data node network and the core network can be limited to a certain size range on the premise of ensuring high performance and high availability of the whole network. A large number of service nodes are connected with a plurality of data nodes, and the service nodes synchronize own block data with the data nodes in real time.

The following describes in detail the block data synchronization method, the block data synchronization device, the computer readable medium, the electronic device, the computer program product, and other technical schemes provided in the present application with reference to the specific embodiments.

Fig. 4 is a flowchart illustrating steps of a block data synchronization method in an embodiment of the present application, which is performed by a service node or a light node in the service network shown in fig. 3. As shown in fig. 4, the block data synchronization method in the embodiment of the present application mainly includes the following steps S410 to S440.

Step S410: acquiring a plurality of data nodes in a communication connection state, wherein the data nodes are block chain nodes for providing block data reading service;

step S420: respectively counting round trip delay and packet loss rate of each data node for data communication;

Step S430: determining evaluation information of each data node according to the round trip delay and the packet loss rate, wherein the evaluation information is used for representing the real-time communication quality of the data node;

step S440: and selecting a target node from the plurality of data nodes according to the evaluation information, and sending a block data synchronization request to the target node according to the block height.

In the block data synchronization method provided by the embodiment of the application, by acquiring a plurality of data nodes which are in data communication with the current block chain node and respectively counting round trip delay and packet loss rate for each data node, the real-time communication quality of data communication between each data node and the current block chain node can be obtained, and then a target node with higher real-time communication quality is selected for data synchronization, so that the synchronization efficiency and accuracy of block data can be improved.

The following describes each method step of the block data synchronization method in the present application in detail through a plurality of embodiments.

In step S410, a plurality of data nodes in a communication connection state, which are blockchain nodes for providing a blockdata reading service, are acquired.

As shown in the blockchain network architecture of fig. 3, one service node or light node in the service network may simultaneously communicate data with a plurality of data nodes in the data node network, and one data node in the data node network may also simultaneously provide a data reading service to a plurality of service nodes or light nodes in the service network.

The service node or the light node in the service network may each maintain a data node list for storing a plurality of data nodes in communication connection with the service node or the light node, and the data node list may store a current state of each data node in addition to a communication address of each data node, for example, may include a communication connection state or a connection interruption state. When the current state of one data node is a communication connection state, the current block chain node (service node or light node) can communicate data with the current block chain node; when the current state of one data node is the connection interruption state, the current block link point cannot communicate data with the current block link point.

When a new block is generated in the blockchain network, the data node may send the latest block height to the service node or the light node to inform the relevant node to update the block data in time. When the current block chain link point receives the latest block height sent by the data node, the latest block height can be compared with the block height stored by the current block chain link point, if the latest block height is larger than the block height stored by the current block chain node, the data node in the communication connection state can be obtained according to the data node list maintained by the current block chain link point, the target node is selected based on the follow-up step, and the data synchronization is carried out with the target node.

In step S420, round trip delay and packet loss rate of each data node for data communication are counted.

Round-Trip Time (RTT) is the Time required for data to travel from one end of the network to the other. Generally, the round trip time RTT is composed of a transmission time delay, a propagation time delay, a queuing time delay, a processing time delay, and the like. The round trip time RTT may be used to diagnose the speed, reliability and congestion level of the network connection.

Data is transmitted in a network in packets, each of which has frames representing data information and providing data routing. When a packet propagates through a network medium, a small portion of the packet may be lost to varying degrees due to excessive transmission distance, network congestion, and the like. The packet loss rate, which is used to indicate the degree of packet loss occurring during data transmission, can be generally expressed by the ratio of the number of lost packets to the total amount of packets transmitted.

Figure 5 illustrates a flow chart of steps for data statistics for individual data nodes in one embodiment of the present application. As shown in fig. 5, on the basis of the above embodiment, the round trip delay and the packet loss rate of each data node for data communication in step S420 may include the following steps S510 to S530.

In step S510, heartbeat request packets are sent to each data node, and heartbeat response packets returned by the data nodes are monitored.

The heartbeat mechanism is a mechanism for sending a self-defined structure body (namely a heartbeat request data packet) at fixed time to enable the opposite party to know that the opposite party is still alive so as to ensure the validity of the connection. The heartbeat request data packet may be a message with empty data, if the opposite party responds to the message, which indicates that the opposite party is still online, the connection may be kept continuously, if the opposite party does not return the message, and after retrying for a plurality of times, the connection is considered to be lost, and the connection is not necessarily kept.

In one embodiment of the present application, the current blockchain node may send a heartbeat request packet to each data node through its blockchain client application to detect whether the connection is normal, and further determine the round trip delay of the data node for data communication. The link point of the current block sends a short data packet to each data node at regular intervals, then starts a thread, and continuously detects the response of each data node in the thread. If the response of a certain data node is not received after a certain time, the data node is considered to be disconnected, and the current state of the data node can be updated to be a connection interruption state.

In one embodiment of the present application, the current blockchain node may implement the heartbeat packet mechanism using the KeepAlive socket option in the TCP protocol. TCP (Transmission Control Protocol ) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol, defined by IETF RFC 793. TCP is intended to accommodate a layered protocol hierarchy that supports multiple network applications. Reliable communication services are provided between pairs of processes in host computers connected to different but interconnected computer communication networks by means of TCP, which assumes that it can obtain simple, possibly unreliable datagram services from lower level protocols.

Among the mechanisms of TCP, there is a mechanism of heartbeat packet itself, namely, keepAlive socket option of TCP. After the current block link point starts the KeepAlive function, heartbeat request data packets are automatically sent to each data node within a set time, and the data nodes automatically reply to the heartbeat response data packets after receiving the heartbeat request data packets.

In one embodiment of the present application, the current blockchain node may obtain the number of data nodes currently in a communication connection state; if the number of the data nodes in the communication connection state is smaller than the set number threshold, a block chain client application program can be used for sending heartbeat request data packets to each data node; if the number of the data nodes currently in the communication connection state is greater than the set number threshold, a KeepAlive socket option of the TCP protocol can be started to send heartbeat request data packets to each data node by utilizing a TCP mechanism.

In one embodiment of the present application, the current blockchain node may respectively acquire a heartbeat request period corresponding to each data node, and periodically send a heartbeat request data packet to each data node according to the heartbeat request period.

In one embodiment of the present application, the current blockchain node may respectively obtain a communication frequency of data communication between the current blockchain node and each data node, and further determine a heartbeat request period corresponding to the data node according to a frequency interval where the communication frequency is located.

In one embodiment of the present application, the positive correlation is formed between the heartbeat request period and the communication frequency, and the higher the communication frequency is, the higher the heartbeat request period is.

In one embodiment of the present application, the current blockchain node may maintain a mapping relationship table between the frequency interval and the heartbeat request period, and may monitor and update the communication frequency of each data node in the data node list in real time. And inquiring the mapping relation table according to the communication frequency of each data node to obtain a frequency interval in which the data node is positioned, and further determining a heartbeat request period corresponding to the frequency interval.

In step S520, round trip delay of each data node for data communication is counted according to the response duration of the heartbeat response data packet.

The response time of the heartbeat response data packet refers to the time interval between sending the heartbeat request data packet and receiving the heartbeat response data packet by the current blockchain node, and after the current blockchain node monitors the heartbeat response data packet returned by each data node, the time interval between the heartbeat response data packet and the corresponding heartbeat request data packet can be calculated respectively, so that the round trip delay of each data node for data communication is determined.

In one embodiment of the present application, a method for counting round trip delay of each data node for data communication according to response duration of a heartbeat response data packet may include: respectively acquiring heartbeat response data packets returned by each data node; determining the response time of the heartbeat response data packet according to the receiving time of the heartbeat response data packet and the sending time of the corresponding heartbeat request data packet; and counting the round trip delay of the data communication by the data node according to the response time length.

The response time of the heartbeat response data packet can include a plurality of parts including presentation time consumption, transmission time consumption, application system time consumption and the like. The display time consumption is reflected on the configuration difference of the browser or the client, and the network transmission time consumption is generally distributed between 5ms and 50ms in a wide area network; in local area networks, network transmissions typically take less than 1ms and are negligible. The time consumption of the application system is embodied in the aspects of processing logic, data reading performance, server performance and the like, and factors affecting the processing logic comprise the time complexity of an algorithm and the number of logs; factors affecting data reading performance include whether the table of the database and index design are reasonable, whether the table association is correct, whether the waste of IO reading caused by scanning a large amount of unnecessary data exists, whether an SQL implementation algorithm can be optimized, and the like; factors that affect server performance include CPU usage, disk transfer rate, memory usage, etc.

Fig. 6 is a flowchart illustrating steps of counting round trip delay of a data node in an embodiment of the present application, and as shown in fig. 6, on the basis of the above embodiment, counting round trip delay of data communication by the data node according to a response time length may include the following steps S610 to S650.

Step S610: and acquiring the response time length of the preset quantity nearest to the current moment in real time.

The current blockchain node may maintain a plurality of response time length monitoring lists, each of the response time length monitoring lists being used for recording a response time length generated by a data node returning a heartbeat response data packet to the current blockchain node. For example, the current blockchain node may be in data communication with N data nodes, and N response duration monitoring lists may be maintained, and each time a heartbeat response data packet is received, the heartbeat response data packet may be allocated to a corresponding response duration monitoring list according to a source of the heartbeat response data packet.

Fig. 7 shows a schematic diagram of the principle of counting round trip delay in one embodiment of the present application. As shown in fig. 7, the current blockchain node 701 may simultaneously perform data communication with a plurality of data nodes 702, and obtain a response duration of each data node in each heartbeat round and a time node receiving the heartbeat response data packet in each heartbeat round by sending a heartbeat request data packet to each data node 702 and monitoring a heartbeat response data packet returned by each data node 702.

The current blockchain node 701 maintains a response time length monitoring list 703 for each data node 702, and according to the data monitoring result, multiple groups of data such as heartbeat times, time nodes, response time length and the like can be written into the response time length monitoring list 703 updated in real time.

In each response time length monitoring list 703, the heartbeat response data packets are sorted according to the time sequence of receiving the heartbeat response data packets, for a data node, a preset number of heartbeat response data packets closest to the current moment can be screened out from all the heartbeat response data packets returned by the data node, and the response time length of each screened heartbeat response data packet is obtained. The number of acquired response time periods is in negative correlation with the heartbeat request period, and the smaller the heartbeat request period is, the larger the number of acquired response time periods is. For example, the link point of the current block sends a heartbeat request data packet to a data node every 2 seconds, and accordingly, the latest 30 heartbeat response data packets returned by the data node can be obtained, and the response time length of each heartbeat response data packet is respectively obtained. In an embodiment of the present application, the number of acquired response durations may also be a preset fixed value, which is not limited in this application.

Step S620: and drawing a response time length distribution diagram of the data nodes according to the preset number of response time lengths.

In one embodiment of the present application, the response round may be taken as an abscissa, the response time length may be taken as an ordinate, and a response time length distribution diagram of the data node may be drawn, so as to represent the distribution situation of the response time length of the data node responding to each heartbeat request of the current blockchain node in different response rounds.

In one embodiment of the present application, the sending time of the heartbeat request data packet or the receiving time of the heartbeat response data packet may be taken as an abscissa, and the response time length may be taken as an ordinate, and a response time length distribution map of the data node may be drawn, so as to represent the distribution situation of the response time length of the data node responding to each heartbeat request of the current blockchain node at different heartbeat response times.

With continued reference to fig. 7, according to the data recorded and screened in the response time length monitoring list 703, a corresponding response time length distribution map 704 may be drawn for each data node, and according to the distribution situation of each data point in the response time length distribution map 704, whether the distribution of each data point is normal may be determined, and may be used to predict a response time length change trend in a future period.

Step S630: and carrying out abnormal data identification on the response time length distribution map so as to remove abnormal data points in the response time length distribution map.

When the distribution of one data point is obviously different from that of other data points, namely that the data point may have an abnormality, the reason for the abnormality may be that the data is recorded with errors or sudden network faults. For example, when one data point experiences a sudden increase or decrease in response time and the magnitude of the increase or decrease exceeds the average change in response time between other data points, the data may be marked as an abnormal data point and removed from the response time profile.

In one embodiment of the present application, the response time period variation between one data point and two adjacent data points may be compared with a preset variation threshold to determine whether the data point is abnormal. For example, the response time of one data point is X _i The response time length of the previous data point adjacent to the data point is X _i-1 The response time of the next data point adjacent to the data point is X _i+1 From this, the response time length variation of the data point can be calculated as (X _i+1 +X _i-1 -2X _i )/2. In one embodiment of the present application, the average response may be calculated based on the response time variation of each data point And the time length change quantity is used as a preset change quantity threshold value by taking the product of the average response time length change quantity and a preset coefficient.

Step S640: and performing curve fitting on the response time length distribution graph after the abnormal data points are removed to obtain a response time length fitting function used for representing the change state of the response time length.

Curve fitting is a data processing method that approximately characterizes or compares a functional relationship between coordinates represented by a discrete point group on a plane with a continuous curve, i.e., a method that approximates discrete data with an analytical expression. By curve fitting, a response time length fitting function of continuous data distribution can be obtained by fitting according to discrete distributed data points in the response time length distribution map after abnormal data points are removed.

In one embodiment of the present application, multiple function types may be used to perform curve fitting on the response time length distribution map after the abnormal data points are removed, and one curve function with the best fitting effect is selected as the response time length fitting function according to the fitting result. For example, the present application may perform curve fitting on the response time length distribution map after removing the abnormal data points by using a linear function, an exponential function, a power function, and a hyperbolic function, and select a function type with the best fitting effect from the curve fitting, so as to determine a final response time length fitting function.

Step S650: and predicting the round trip delay of the data node for data communication according to the response time fitting function.

In one embodiment of the present application, the round trip delay for data communication with the data node at the next heartbeat round or at the next time may be predicted from the response time length fitting function.

As shown in fig. 7, for each response time length distribution diagram 704, curve fitting may be performed to obtain a corresponding response time length fitting function 705, and round trip time delay RTT of each data node for data communication may be predicted by using the response time length fitting function 705.

Based on the above steps S610 to S650, the round trip delay RTT of the data node may be predicted in a curve fitting manner. In one embodiment of the present application, the data node may perform a plurality of heartbeat responses to obtain an average value of the response duration, and use the average value of the response duration as the round trip delay of the data node for performing data communication.

In step S530, the packet loss rate of each data node for data communication is counted according to the data amount information carried by the heartbeat response data packet.

Fig. 8 is a flowchart illustrating steps for aggregating packet loss rates of data nodes in one embodiment of the present application. As shown in fig. 8, step S530 may further include steps S810 to S840 as follows, on the basis of the above embodiment.

Step S810: analyzing the heartbeat response data packet to obtain data quantity information carried in the heartbeat response data packet, wherein the data quantity information comprises a statistical time interval and data transmission quantity of the data node in the statistical time interval, and the data transmission quantity is the data quantity of the data node transmission block data.

A special field is configured in the heartbeat response data packet for recording data volume information of the data node. The statistical time interval is a time interval which is respectively configured by each data and used for counting the data transmission quantity, each data node can have the same statistical time interval, and the same statistical time interval is beneficial to summarizing and comparing the data quantity information of all the data nodes by the current block chain node.

In one embodiment of the present application, the data transmission amount is a transmission amount per unit time calculated according to a total amount of data of the block data transmitted by the data node to other block chain nodes in the statistical time interval.

In one embodiment of the present application, the data node may also send the data message recording the data amount information to the current block link separately.

Step S820: and acquiring the data receiving quantity of the current block chain node in the statistical time interval, wherein the data receiving quantity is the data quantity of the block data received by the current block chain node.

In one embodiment of the present application, the current blockchain node may monitor the amount of data received from each data node to send the blockdata according to the statistical time interval.

In one embodiment of the present application, the data reception amount may be a total amount of block data received in a statistical time interval, or may be a reception amount per unit time calculated from the total amount of data.

Comparing the numerical relation between the data transmission quantity and the data receiving quantity; if the data transmission amount is smaller than the data reception amount, the value of the data reception amount is updated to the data transmission amount.

Step S830: and determining the packet loss rate of the data node in each statistical time interval according to the data transmission quantity and the data receiving quantity.

Determining packet loss rate of the data node in each statistical time interval according to the formula loss=1- (rcv+a)/(snt +b); where loss is a packet loss rate, rcv is a data reception amount, snt is a data transmission amount, a is a first adjustment coefficient greater than or equal to 0, and b is a second adjustment coefficient greater than or equal to a.

In one embodiment of the present application, a may have a value of 1 and b may have a value of 2.

Step S840: and determining the packet loss rate of the data node for data communication according to the packet loss rates of the data node in a plurality of statistical time intervals.

Fig. 9 is a flowchart illustrating steps for determining a packet loss rate in one embodiment of the present application. As shown in fig. 9, step S840 may further include steps S910 to S950 as follows, on the basis of the above embodiment.

Step S910: and acquiring the preset number of packet loss rates in real time in a plurality of statistical time intervals closest to the current moment.

The current blockchain node may maintain a plurality of packet loss rate monitoring lists, each of which is used for recording a packet loss rate generated by a data node sending data to the current blockchain link. For example, the current blockchain node performs data communication with N data nodes, may maintain N packet loss rate monitoring lists, and may calculate a packet loss rate according to a source of a heartbeat response packet whenever the heartbeat response packet is received, and allocate the packet loss rate to a corresponding packet loss rate monitoring list.

For example, the statistical time interval is 1 minute, the current blockchain node may count the packet loss rate of data communication with one data node every 1 minute, and when the preset number is 30, the current blockchain node acquires the packet loss rate counted by the last 30 times (i.e. the latest 30 statistical time intervals) in real time.

Step S920: and drawing a packet loss rate distribution diagram of the data node according to the preset number of packet loss rates.

In one embodiment of the present application, the statistical round may be taken as an abscissa, and the packet loss rate is taken as an ordinate, and a packet loss rate distribution diagram of the data node is drawn, so as to represent the distribution situation of the data packet loss rate of the data node in different statistical rounds when the data node transmits data to the current block link. In the embodiment of the present application, a statistical time interval represents a statistical round.

Step S930: and carrying out abnormal data identification on the packet loss rate distribution diagram so as to remove abnormal data points in the packet loss rate distribution diagram.

When the distribution of one data point is obviously different from that of other data points, namely that the data point may have an abnormality, the reason for the abnormality may be that the data is recorded with errors or sudden network faults. For example, when a sudden increase or decrease in the packet loss rate occurs for one data point and the magnitude of the increase or decrease exceeds the average change in the packet loss rate profile between other data points, the data may be marked as an outlier and removed from the packet loss rate profile.

In one embodiment of the present application, the change amount of the packet loss rate distribution curve between one data point and two adjacent data points may be compared with a preset change amount threshold to determine whether the data point is abnormal. For example, the packet loss rate distribution curve of one data point is Y _i The packet loss rate of the previous data point adjacent to the data point is Y _i-1 The packet loss rate of the next data point adjacent to the data point is Y _i+1 From this, the packet loss rate variation of the data point can be calculated as (Y _i+1 +Y _i-1 -2Y _i )/2. In one embodiment of the present application, the packet loss rate is based on the individual data pointsThe variation can be calculated to obtain the average packet loss rate variation, and the product of the average packet loss rate variation and a preset coefficient is used as a preset variation threshold.

Step S940: and performing curve fitting on the packet loss rate distribution map after the abnormal data points are removed to obtain a packet loss rate fitting function for representing the change state of the packet loss rate.

In one embodiment of the present application, multiple function types may be used to perform curve fitting on the packet loss rate distribution map after the abnormal data points are removed, and one curve function with the best fitting effect is selected as the packet loss rate fitting function according to the fitting result. For example, the present application may perform curve fitting on the packet loss rate distribution map after removing the abnormal data points by using a linear function, an exponential function, a power function, and a hyperbolic function, and select a function type with the best fitting effect from the curve fitting, so as to determine a final packet loss rate fitting function.

Step S950: and predicting the packet loss rate of the data node for data communication according to the packet loss rate fitting function.

In one embodiment of the present application, the packet loss rate of data communication with the data node in the next statistical round or the next statistical time interval can be predicted according to the packet loss rate fitting function.

Based on the above steps S910 to S950, the packet loss rate of the data node may be predicted in a curve fitting manner. In one embodiment of the present application, an average value may be calculated according to a plurality of packet loss rates of the data node in a plurality of statistical time intervals, and the average value may be used as the packet loss rate of the data node for performing data communication.

In step S430, evaluation information of each data node is determined according to the round trip delay and the packet loss rate, where the evaluation information is used to represent real-time communication quality of the data node.

FIG. 10 is a flowchart illustrating steps for determining data node evaluation information in one embodiment of the present application. As shown in fig. 10, step S430 may further include the following steps S1010 to S1040 on the basis of the above embodiment.

Step S1010: and acquiring a round trip delay integral model and a packet loss rate integral model maintained by the link points of the current block.

Figure 11 illustrates a round trip delay integration model in one embodiment of the present application. As shown in fig. 11, the round trip delay integration model is a segment model, which includes a plurality of delay intervals, and each delay interval may be mapped to one delay integration. The higher the round trip delay, the greater the corresponding delay integral, which also means higher network delay.

Fig. 12 illustrates a packet loss rate integration model in one embodiment of the present application. As shown in fig. 12, the packet loss rate integration model is similar to the round trip delay integration model, and is also a segment model, and includes a plurality of packet loss rate intervals, where each packet loss rate interval can be mapped to one packet loss rate integration in an associated manner.

Step S1020: and searching a time delay section in which the round trip time delay is located in the round trip time delay integration model, and acquiring a time delay integration associated with the time delay section.

According to the round trip delay of the data node, the delay interval where the round trip delay integration model is located can be searched, for example, if the round trip delay of the data node A falls within the range of 0< = RTT <50, the network quality between the data node A and the current blockchain node is good, the network delay is low, and the delay integration of the data node A can be determined to be 1; for another example, if the round trip delay of the data node B falls within the range of 300< = RTT <500, which indicates that the network quality between the data node B and the current blockchain node is poor, the network delay is high, and it may be determined that the delay integral of the data node B is 21.

Step S1030: searching a packet loss rate interval in which the packet loss rate is located in the packet loss rate integral model, and acquiring packet loss rate integral associated with the packet loss rate interval.

According to the packet Loss rate of the data node, a packet Loss rate section where the data node is located can be searched in a packet Loss rate integral model, for example, if the packet Loss rate of the data node A falls in a range of 0< = Loss <4%, the network quality between the data node A and the current blockchain node is good, the data transmission is normal, and the packet Loss rate integral of the data node A can be determined to be 3; for another example, if the packet Loss rate of the data node B falls within the range of 10% <=loss <20%, it indicates that the network quality between the data node B and the current blockchain node is poor, and the data transmission is abnormal, and it can be determined that the packet Loss rate integral of the data node B is 20.

Step S1040: and determining evaluation information of the data node according to the time delay integral and the packet loss rate integral.

In one embodiment of the application, a delay evaluation weight and a packet loss rate evaluation weight related to a data node are obtained; and weighting the time delay integral and the packet loss rate integral according to the time delay evaluation weight and the packet loss rate evaluation weight to obtain evaluation information of the data node.

Based on the above steps S1010 to S1040, evaluation information of each data node may be determined, which may be expressed as a weighted integral obtained by weighting two dimensions of the round trip delay and the packet loss rate.

In step S440, a target node is selected from the plurality of data nodes according to the evaluation information, and a block data synchronization request is sent to the target node according to the block height.

When the current block chain node receives the block height sent by the data node, whether the current block chain node needs to synchronize the block data or not can be judged based on the block height. If necessary, the data node with the minimum integral, namely the data node with the best comprehensive performance of network delay and packet loss rate, is selected by evaluating the final integral of each data node, then the block data synchronization request is sent to the data node with the minimum integral, and finally the block data synchronization speed of the whole block chain network is improved.

In the block data synchronization method provided by the embodiment of the application, the integral model is built through the RTT and the packet loss ratio, so that network resources and calculation resources of the nodes can be fully utilized, the block synchronization speed is improved, the data node network can be dynamically scheduled, and the high availability of block data transmission is ensured.

It should be noted that although the steps of the methods in the present application are depicted in the accompanying drawings in a particular order, this does not require or imply that the steps must be performed in that particular order, or that all illustrated steps be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform, etc.

The following describes an embodiment of an apparatus of the present application, which may be used to perform the block data synchronization method in the above embodiment of the present application. Fig. 13 is a block diagram of a block data synchronization apparatus according to an embodiment of the present application. The block data synchronization apparatus 1300 shown in fig. 13 mainly includes:

an acquisition module 1310 configured to acquire a plurality of data nodes in a communication connection state, the data nodes being blockchain nodes for providing a block data reading service;

a statistics module 1320, configured to respectively count round trip delay and packet loss rate of each data node for data communication;

an evaluation module 1330 configured to determine, according to the round trip delay and the packet loss rate, evaluation information of each of the data nodes, where the evaluation information is used to represent real-time communication quality of the data nodes;

a request module 1340 configured to select a target node from the plurality of data nodes according to the evaluation information and send a block data synchronization request to the target node according to the block height.

In one embodiment of the present application, based on the above embodiment, the statistics module 1320 includes:

the heartbeat monitoring module 1321 is configured to send heartbeat request data packets to the data nodes respectively, and monitor heartbeat response data packets returned by the data nodes;

A delay statistics module 1322 configured to count round trip delays of the data nodes for data communication according to response durations of the heartbeat response data packets;

and the packet loss rate statistics module 1323 is configured to count the packet loss rate of each data node for data communication according to the data volume information carried by the heartbeat response data packet.

In one embodiment of the present application, based on the above embodiments, the heartbeat monitoring module 1321 may further include:

the period acquisition module is configured to acquire heartbeat request periods corresponding to the data nodes respectively;

and the heartbeat sending module is configured to send heartbeat request data packets to each data node periodically according to the heartbeat request period.

In one embodiment of the present application, based on the above embodiments, the period acquisition module may further include:

the frequency acquisition module is configured to acquire communication frequencies of data communication between the current blockchain node and each data node respectively;

and the period determining module is configured to determine a heartbeat request period corresponding to the data node according to the frequency interval where the communication frequency is located.

In one embodiment of the present application, based on the above embodiments, the delay statistics module 1322 may further include:

the response acquisition module is configured to acquire heartbeat response data packets returned by the data nodes respectively;

the response time length determining module is configured to determine the response time length of the heartbeat response data packet according to the receiving time of the heartbeat response data packet and the sending time of the corresponding heartbeat request data packet;

and the round trip delay statistics module is configured to count the round trip delay of the data node for data communication according to the response time length.

In one embodiment of the present application, based on the above embodiments, the round trip delay statistics module includes:

the response time length acquisition module is configured to acquire a preset number of response time lengths nearest to the current moment in real time;

the response time length drawing module is configured to draw a response time length distribution diagram of the data node according to the preset number of response time lengths;

the first anomaly identification module is configured to perform anomaly data identification on the response time length distribution map so as to remove anomaly data points in the response time length distribution map;

the first curve fitting module is configured to perform curve fitting on the response time length distribution graph after the abnormal data points are removed, and a response time length fitting function used for representing the change state of the response time length is obtained;

And the round trip delay prediction module is configured to predict the round trip delay of the data node for data communication according to the response time fitting function.

In one embodiment of the present application, based on the above embodiments, the packet loss rate statistics module 1323 may further include:

the sending amount determining module is configured to analyze the heartbeat response data packet to obtain data amount information carried in the heartbeat response data packet, wherein the data amount information comprises a statistical time interval and the data sending amount of the data node in the statistical time interval, and the data sending amount is the data amount of the data node sending block data;

a receiving amount determining module configured to obtain a data receiving amount of a current block link point in the statistical time interval, wherein the data receiving amount is a data amount of block data received by the current block link point;

the interval packet loss rate statistics module is configured to determine the packet loss rate of the data node in each statistical time interval according to the data transmission quantity and the data receiving quantity;

and the packet loss rate determining module is configured to determine the packet loss rate of the data node for data communication according to the packet loss rates of the data node in a plurality of statistical time intervals.

In one embodiment of the present application, based on the above embodiments, the packet loss rate statistics module 1323 further includes:

a numerical comparison module configured to compare a numerical relationship of the data transmission amount and the data reception amount;

and the numerical value updating module is configured to update the numerical value of the data receiving amount to the data sending amount if the data sending amount is smaller than the data receiving amount.

In one embodiment of the present application, based on the above embodiments, the interval packet loss rate statistics module may be further configured to:

determining the packet loss rate of the data node in each statistical time interval according to the formula loss=1- (rcv+a)/(snt +b); where loss is a packet loss rate, rcv is a data reception amount, snt is a data transmission amount, a is a first adjustment coefficient greater than or equal to 0, and b is a second adjustment coefficient greater than or equal to a.

In an embodiment of the present application, based on the above embodiments, the packet loss rate determining module may further include:

the interval packet loss rate acquisition module is configured to acquire a preset number of packet loss rates in real time in a plurality of statistical time intervals closest to the current moment;

the packet loss rate drawing module is configured to draw a packet loss rate distribution diagram of the data node according to the preset number of packet loss rates;

The second anomaly identification module is configured to perform anomaly data identification on the packet loss rate distribution map so as to remove anomaly data points in the packet loss rate distribution map;

the second curve fitting module is configured to perform curve fitting on the packet loss rate distribution map after the abnormal data points are removed, so as to obtain a packet loss rate fitting function for representing the change state of the packet loss rate;

and the packet loss rate prediction module is configured to predict the packet loss rate of the data node for data communication according to the packet loss rate fitting function.

In one embodiment of the present application, based on the above embodiments, the evaluation module 1330 includes:

a model acquisition module 1331 configured to acquire a round trip delay integration model and a packet loss rate integration model maintained by the current blockchain node;

a delay integration acquisition module 1332 configured to find a delay interval in which the round trip delay is located in the round trip delay integration model, and acquire a delay integration associated with the delay interval;

a packet loss rate integral obtaining module 1333 configured to find a packet loss rate interval in which the packet loss rate is located in the packet loss rate integral model, and obtain a packet loss rate integral associated with the packet loss rate interval;

An evaluation information determination module 1334 configured to determine evaluation information for the data node based on the delay integral and the packet loss rate integral.

In one embodiment of the present application, based on the above embodiments, the evaluation information determination module 1334 includes:

the weight acquisition module is configured to acquire a time delay evaluation weight and a packet loss rate evaluation weight related to the data node;

and the integral weighting module is configured to carry out weighting processing on the time delay integral and the packet loss rate integral according to the time delay evaluation weight and the packet loss rate evaluation weight to obtain the evaluation information of the data node.

Specific details of the block data synchronization device provided in each embodiment of the present application have been described in the corresponding method embodiments, and are not described herein.

Fig. 14 schematically shows a block diagram of a computer system for implementing an electronic device according to an embodiment of the present application.

It should be noted that, the computer system 1400 of the electronic device shown in fig. 14 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.

As shown in fig. 14, the computer system 1400 includes a central processing unit 1401 (Central Processing Unit, CPU) that can execute various appropriate actions and processes according to a program stored in a Read-Only Memory 1402 (ROM) or a program loaded from a storage section 1408 into a random access Memory 1403 (Random Access Memory, RAM). In the random access memory 1403, various programs and data necessary for the system operation are also stored. The cpu 1401, the rom 1402, and the ram 1403 are connected to each other via a bus 1404. An Input/Output interface 1405 (Input/Output interface, i.e., I/O interface) is also connected to bus 1404.

The following components are connected to the input/output interface 1405: an input section 1406 including a keyboard, a mouse, and the like; an output portion 1407 including a Cathode Ray Tube (CRT), a liquid crystal display (Liquid Crystal Display, LCD), and a speaker; a storage section 1408 including a hard disk or the like; and a communication section 1409 including a network interface card such as a local area network card, a modem, and the like. The communication section 1409 performs communication processing via a network such as the internet. The drive 1410 is also connected to the input/output interface 1405 as needed. Removable media 1411, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memory, and the like, is installed as needed on drive 1410 so that a computer program read therefrom is installed as needed into storage portion 1408.

In particular, according to embodiments of the present application, the processes described in the various method flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1409 and/or installed from the removable medium 1411. The computer programs, when executed by the central processor 1401, perform the various functions defined in the system of the present application.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal that propagates in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more modules or units described above may be embodied in one module or unit, in accordance with embodiments of the present application. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a usb disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains.

It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for synchronizing block data, comprising:

2. The block data synchronization method according to claim 1, wherein counting round trip delay and packet loss rate of data communication by each data node respectively comprises:

respectively sending heartbeat request data packets to each data node, and monitoring heartbeat response data packets returned by the data nodes;

counting the round trip time delay of each data node for data communication according to the response time length of the heartbeat response data packet;

and counting the packet loss rate of each data node for data communication according to the data quantity information carried by the heartbeat response data packet.

3. The block data synchronization method according to claim 2, wherein transmitting heartbeat request packets to each of the data nodes, respectively, comprises:

respectively acquiring heartbeat request periods corresponding to the data nodes;

and sending heartbeat request data packets to each data node periodically according to the heartbeat request period.

4. A block data synchronization method according to claim 3, wherein acquiring heartbeat request periods corresponding to the respective data nodes, respectively, comprises:

respectively acquiring communication frequencies of data communication between the current block chain node and each data node;

and determining a heartbeat request period corresponding to the data node according to the frequency interval where the communication frequency is located.

5. The block data synchronization method according to claim 2, wherein counting round trip delay of each data node for data communication according to response duration of the heartbeat response data packet includes:

respectively acquiring heartbeat response data packets returned by each data node;

determining the response time of the heartbeat response data packet according to the receiving time of the heartbeat response data packet and the sending time of the corresponding heartbeat request data packet;

And counting the round trip delay of the data node for data communication according to the response time length.

6. The block data synchronization method according to claim 5, wherein counting round trip delays of the data nodes for data communication according to the response time length comprises:

acquiring the response time length of the preset quantity nearest to the current moment in real time;

drawing a response time length distribution diagram of the data node according to the preset number of response time lengths;

carrying out abnormal data identification on the response time length distribution map so as to remove abnormal data points in the response time length distribution map;

performing curve fitting on the response time length distribution graph after the abnormal data points are removed to obtain a response time length fitting function for representing the change state of the response time length;

and predicting the round trip delay of the data node for data communication according to the response time fitting function.

7. The block data synchronization method according to claim 2, wherein counting packet loss rate of each data node for data communication according to data amount information carried by the heartbeat response data packet includes:

analyzing the heartbeat response data packet to obtain data volume information carried in the heartbeat response data packet, wherein the data volume information comprises a statistical time interval and data transmission volume of the data node in the statistical time interval, and the data transmission volume is the data volume of the data node transmission block data;

Acquiring the data receiving quantity of the current block link point in the statistical time interval, wherein the data receiving quantity is the data quantity of the block data received by the current block link point;

determining the packet loss rate of the data node in each statistical time interval according to the data transmission quantity and the data receiving quantity;

and determining the packet loss rate of the data node for data communication according to the packet loss rates of the data node in a plurality of statistical time intervals.

8. The block data synchronization method according to claim 7, wherein before determining a packet loss rate of the data node in each statistical time interval from the data transmission amount and the data reception amount, the method further comprises:

comparing the numerical relation between the data transmission quantity and the data receiving quantity;

and if the data transmission amount is smaller than the data receiving amount, updating the numerical value of the data receiving amount into the data transmission amount.

9. The block data synchronization method according to claim 7, wherein determining the packet loss rate of the data node in each statistical time interval according to the data transmission amount and the data reception amount comprises:

10. The block data synchronization method according to claim 7, wherein determining the packet loss rate of the data node for data communication according to the packet loss rates of the data node in a plurality of statistical time intervals comprises:

acquiring a preset number of packet loss rates in real time in a plurality of statistical time intervals closest to the current moment;

drawing a packet loss rate distribution diagram of the data node according to the preset number of packet loss rates;

abnormal data identification is carried out on the packet loss rate distribution diagram so as to remove abnormal data points in the packet loss rate distribution diagram;

performing curve fitting on the packet loss rate distribution map after the abnormal data points are removed to obtain a packet loss rate fitting function for representing the change state of the packet loss rate;

and predicting the packet loss rate of the data node for data communication according to the packet loss rate fitting function.

11. The block data synchronization method according to any one of claims 1 to 10, wherein determining the evaluation information of each of the data nodes according to the round trip delay and the packet loss rate comprises:

Acquiring a round trip delay integral model and a packet loss rate integral model maintained by a current block chain link point;

searching a delay interval in which the round trip delay is located in the round trip delay integration model, and acquiring a delay integration associated with the delay interval;

searching a packet loss rate interval in which the packet loss rate is located in the packet loss rate integral model, and acquiring packet loss rate integral associated with the packet loss rate interval;

and determining the evaluation information of the data node according to the time delay integral and the packet loss rate integral.

12. The block data synchronization method according to claim 11, wherein determining the evaluation information of the data node according to the delay integral and the packet loss rate integral comprises:

acquiring delay evaluation weights and packet loss rate evaluation weights related to the data nodes;

and weighting the time delay integral and the packet loss rate integral according to the time delay evaluation weight and the packet loss rate evaluation weight to obtain evaluation information of the data node.

13. A block data synchronization apparatus, comprising:

14. A computer readable medium, characterized in that the computer readable medium has stored thereon a computer program which, when executed by a processor, implements the block data synchronization method of any one of claims 1 to 12.

15. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to cause the electronic device to perform the block data synchronization method of any one of claims 1 to 12 via execution of the executable instructions.

16. A computer program product comprising a computer program which, when executed by a processor, implements the block data synchronization method of any one of claims 1 to 12.