Block data synchronization method and related products

Abstract

This application belongs to the field of blockchain technology, specifically relating to a block data synchronization method, a block data synchronization device, a computer-readable medium, an electronic device, and a computer program product. The block data synchronization method includes: acquiring multiple data nodes in a communication connection state, wherein the data nodes are blockchain nodes used to provide block data reading services; respectively calculating the round-trip latency and packet loss rate of data communication between each of the data nodes; determining evaluation information for each data node based on the round-trip latency and packet loss rate, wherein the evaluation information represents the real-time communication quality of the data node; selecting a target node from the multiple data nodes based on the evaluation information, and sending a block data synchronization request to the target node according to the block height. This application can improve the synchronization efficiency and accuracy of block data.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, specifically relating to a block data synchronization method, a block data synchronization device, a computer-readable medium, an electronic device, and a computer program product. Background Technology

[0002] Blockchain is a technological solution that uses a decentralized and trustless approach, where a large number of blockchain nodes collectively maintain a reliable database. When new block data is generated on the blockchain network, data synchronization is required across all blockchain nodes. Due to the large number and wide distribution of blockchain nodes, how to achieve efficient and accurate data synchronization is a pressing problem that needs to be solved. Summary of the Invention

[0003] The purpose of this application is to provide a block data synchronization method, a block data synchronization device, a computer-readable medium, an electronic device, and a computer program product, which at least to some extent overcomes the technical problem of low data synchronization efficiency in related technologies.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a block data synchronization method is provided, the method comprising:

[0006] Acquire multiple data nodes that are in a communication connection state, wherein the data nodes are blockchain nodes used to provide block data reading services;

[0007] The round-trip latency and packet loss rate of data communication for each of the data nodes are calculated separately.

[0008] Evaluation information for each data node is determined based on the round-trip delay and packet loss rate, and the evaluation information is used to represent the real-time communication quality of the data node.

[0009] Based on the evaluation information, a target node is selected from the plurality of data nodes, and a block data synchronization request is sent to the target node according to the block height.

[0010] According to one aspect of the embodiments of this application, a block data synchronization apparatus is provided, the apparatus comprising:

[0011] The acquisition module is configured to acquire multiple data nodes that are in a communication connection state, wherein the data nodes are blockchain nodes used to provide block data reading services;

[0012] The statistics module is configured to separately calculate the round-trip latency and packet loss rate of data communication for each of the data nodes;

[0013] An evaluation module is configured to determine evaluation information for each data node based on the round-trip time and packet loss rate, wherein the evaluation information is used to represent the real-time communication quality of the data node.

[0014] The request module is configured to select a target node from the plurality of data nodes based on the evaluation information, and send a block data synchronization request to the target node based on the block height.

[0015] In some embodiments of this application, based on the above technical solutions,

[0016] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the block data synchronization method as described in the above technical solutions.

[0017] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform a block data synchronization method as described above by executing the executable instructions.

[0018] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the block data synchronization method as described in the above technical solutions.

[0019] In the technical solution provided in this application embodiment, by acquiring multiple data nodes that communicate with the current blockchain node, and calculating the round-trip latency and packet loss rate for each data node, the real-time communication quality of each data node communicating with the current blockchain node can be obtained. Then, a target node with higher real-time communication quality can be selected for data synchronization, thereby improving the synchronization efficiency and accuracy of block data.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] Figure 1 A schematic diagram of the composition of the blockchain system in an embodiment of this application is shown.

[0023] Figure 2 The structure of a blockchain maintained on a blockchain network is shown.

[0024] Figure 3 The network architecture of a blockchain network applying the technical solution of this application is shown.

[0025] Figure 4 A flowchart illustrating the steps of a block data synchronization method in one embodiment of this application is shown.

[0026] Figure 5 A flowchart illustrating the steps of performing data statistics on each data node in one embodiment of this application is shown.

[0027] Figure 6 A flowchart illustrating the steps for calculating the round-trip delay of statistical data nodes in one embodiment of this application is shown.

[0028] Figure 7 A schematic diagram illustrating the principle of statistical round-trip delay in one embodiment of this application is shown.

[0029] Figure 8 A flowchart illustrating the steps of statistically analyzing the packet loss rate of data nodes in one embodiment of this application is shown.

[0030] Figure 9 A flowchart illustrating the steps for determining the packet loss rate in one embodiment of this application is shown.

[0031] Figure 10 A flowchart illustrating the steps for determining data node evaluation information in one embodiment of this application is shown.

[0032] Figure 11 A round-trip delay integral model in one embodiment of this application is shown.

[0033] Figure 12 An integral model of packet loss rate in one embodiment of this application is shown.

[0034] Figure 13 A structural block diagram of the block data synchronization device provided in an embodiment of this application is shown.

[0035] Figure 14 A computer system architecture block diagram suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0036] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0037] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0038] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0039] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0040] A blockchain is a shared, chained-block data structure built on transparent and trusted rules in a peer-to-peer network environment. It is designed to be tamper-proof, tamper-proof, and traceable. The chained-block data structure stores transactions occurring over a period of time in blocks, which are then linked chronologically using cryptographic algorithms. The ledger is distributed to all member nodes in the network, permanently recording the history of asset transactions between peer nodes in the sequential chain of blocks linked by hash cryptographic algorithms. All confirmed and verified transactions are linked from the beginning of the chain to the latest block, hence the name blockchain. A blockchain can serve as a single source of truth, and members of a blockchain network can only view transactions relevant to them.

[0041] Figure 1 A schematic diagram of the blockchain system composition in this embodiment is shown. The blockchain system 100 may include at least one client 110 and a blockchain network 120. The blockchain network 120 includes at least one blockchain node 121. The client 110 may be various electronic devices such as smartphones, tablets, laptops, desktop computers, smart wearable devices, smart in-vehicle devices, smart payment terminals, and facial recognition terminals. By installing the corresponding client application, it can provide blockchain data services to users. 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 composed of multiple physical servers, or a cloud server providing cloud computing services.

[0042] In blockchain network 120, each blockchain node 121 receives input information during normal operation and maintains shared data within the blockchain network based on the received input information. To ensure information interoperability, information connections can exist between the various blockchain nodes 121, allowing them to transmit information to each other. For example, when any blockchain node 121 in blockchain network 120 receives input information and broadcasts it within the blockchain network 120, other node devices in blockchain network 120 can obtain the input information according to a consensus algorithm and store it as shared data.

[0043] Each blockchain node 121 in the blockchain network 120 has a corresponding node identifier. Each blockchain node 121 can also store the node identifiers of other blockchain nodes in the same blockchain network, so that the generated block can be broadcast to other nodes in the blockchain network 120 based on their node identifiers. Each blockchain node 121 can maintain a node identifier list as shown in Table 1, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 shows a node identifier list using IP addresses as an example.

[0044] Table 1

[0045] Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0046] Figure 2 This illustrates the structural composition of a blockchain maintained on a blockchain network. For example... Figure 2As shown, a blockchain consists of multiple sequentially linked blocks. Whenever new data needs to be written to the blockchain, this data is aggregated into a newly generated block. This newly generated block is then linked to the end of the blockchain. A consensus algorithm ensures that the blocks added on each node device 121 are identical. The block body of each block records the data of the current block, while its block header stores the hash value of the preceding block. If the transaction data in the preceding block changes, the hash value of the current block will also change accordingly. Therefore, data uploaded to the blockchain network is difficult to tamper with, improving the reliability of shared data.

[0047] Figure 3 The network architecture of a blockchain network applying the technical solution of this application is shown. For example... Figure 3 As shown, the blockchain network using the technical solution of this application adopts a layered model, specifically including a core network 310, a data node network 320, and a business network 330.

[0048] The core network 310 consists of consensus nodes 311, responsible for achieving consensus on the blockchain network, packaging transactions into blocks, and recording transactions in the ledger. Consensus nodes 311 are nodes with the right to record transactions, elected by the blockchain network through voting or rotating appointment.

[0049] The data node network 320 consists of data nodes 321, which are responsible for synchronizing the ledger information of the core network 310, that is, synchronizing the latest block data, and providing data reading services to the business network 330.

[0050] The business network 330 consists of business nodes 331 or light nodes 332, responsible for synchronizing its own block data from the data node network 320, with the data node network 320 providing data isolation. Business nodes 331 are nodes directly connected to user terminal devices, storing a complete copy of the blockchain, including block headers and block bodies, and can independently provide blockchain business services to users. Light nodes 332 are lightweight nodes; specifically, they do not store or maintain a complete copy of the blockchain, but only store a minimal amount of state to send or transmit transaction information. Light nodes 332 may only store the block header data of each block in the blockchain. When receiving a business request from a user to query specific block data, light nodes 332 can indirectly provide business services to users by interacting with neighboring business nodes 331.

[0051] A layered network structure is adopted, allowing each layer to expand infinitely, especially the service network. The data node network and core network can be limited to a certain size while ensuring high overall network performance and availability. A large number of service nodes will connect to multiple data nodes, synchronizing their block data with the data nodes in relatively real-time.

[0052] The following detailed description of the block data synchronization method, block data synchronization device, computer-readable medium, electronic device, and computer program product provided in this application, in conjunction with specific embodiments, provides a detailed explanation of these technical solutions.

[0053] Figure 4 This application illustrates a flowchart of the steps of a block data synchronization method according to one embodiment of the present application. The method consists of... Figure 3 The service nodes or light nodes in the shown service network execute the commands. For example... Figure 4 As shown, the block data synchronization method in this application embodiment can mainly include the following steps S410 to S440.

[0054] Step S410: Obtain multiple data nodes that are in a communication connection state. Data nodes are blockchain nodes used to provide block data reading services.

[0055] Step S420: Calculate the round-trip latency and packet loss rate for data communication at each data node;

[0056] Step S430: Determine the evaluation information of each data node based on the round-trip delay and packet loss rate. The evaluation information is used to represent the real-time communication quality of the data nodes.

[0057] Step S440: Select a target node from multiple data nodes based on the evaluation information, and send a block data synchronization request to the target node according to the block height.

[0058] In the block data synchronization method provided in this application embodiment, by acquiring multiple data nodes that communicate with the current blockchain node, and calculating the round-trip latency and packet loss rate for each data node, the real-time communication quality of each data node communicating with the current blockchain node can be obtained. Then, a target node with higher real-time communication quality can be selected for data synchronization, thereby improving the synchronization efficiency and accuracy of block data.

[0059] The following describes in detail each step of the block data synchronization method in this application through multiple embodiments.

[0060] In step S410, multiple data nodes in a communication connection state are obtained. The data nodes are blockchain nodes used to provide block data reading services.

[0061] like Figure 3The blockchain network architecture shown allows a business node or light node in the business network to communicate with multiple data nodes in the data node network simultaneously, and a data node in the data node network can also provide data reading services to multiple business nodes or light nodes in the business network simultaneously.

[0062] Each business node or light node in the business network can maintain a data node list to store multiple data nodes with which it has communication connections. In addition to storing the communication addresses of each data node, the data node list can also store the current state of each data node, such as whether the connection is established or terminated. When a data node is in a connected state, it means that the current blockchain node (business node or light node) can communicate with it; when a data node is in a terminated state, it means that the current blockchain node cannot communicate with it.

[0063] When a new block is generated in the blockchain network, data nodes can send the latest block height to business nodes or light nodes to notify relevant nodes to update their block data in a timely manner. When the current blockchain node receives the latest block height sent by the data node, it can compare the latest block height with its own stored block height. If the latest block height is greater than the block height stored by the current blockchain node, it can obtain the data nodes currently in a communication connection state according to the data node list maintained by the current blockchain node, select the target node from it based on subsequent steps, and synchronize data with the target node.

[0064] In step S420, the round-trip time and packet loss rate of data communication for each data node are calculated.

[0065] Round-Trip Time (RTT) refers to the time required for data to travel from one end of a network to the other. Typically, RTT consists of transmission delay, propagation delay, queuing delay, and processing delay. RTT can be used to diagnose the speed, reliability, and congestion level of a network connection.

[0066] Data is transmitted in a network by being divided into data packets. Each data packet contains frames that represent data information and provide data routing. During transmission through the network medium, a small percentage of data packets may be lost to varying degrees due to factors such as long transmission distances and network congestion. Packet loss rate is used to represent the degree of data packet loss during data transmission, and is generally expressed as the ratio of the number of lost data packets to the total number of data packets sent.

[0067] Figure 5A flowchart illustrating the steps for performing data statistics on various data nodes in one embodiment of this application is shown. Figure 5 As shown, based on the above embodiments, step S420, which involves separately calculating the round-trip latency and packet loss rate of each data node for data communication, may include steps S510 to S530.

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

[0069] A heartbeat mechanism is a system that periodically sends a custom structure (a heartbeat request packet) to let the other party know that it is still online, thus ensuring the validity of the connection. The heartbeat request packet can be an empty message. If the other party responds to this message, it means that the other party is still online, and the connection can be maintained. If the other party does not return a message, and after multiple retries, the connection is considered lost, and there is no need to maintain the connection.

[0070] In one embodiment of this application, the current blockchain node can send heartbeat request packets to each data node through its own blockchain client application to detect whether the connection is normal and further determine the round-trip latency of data communication between the data nodes. The current blockchain node sends a short data packet to each data node at regular intervals and then starts a thread to continuously monitor the responses from each data node. If no response is received from a data node after a certain period, it is considered that the data node has gone offline, and its current state can be updated to a connection interrupted state.

[0071] In one embodiment of this application, the current blockchain node can implement a heartbeat 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 designed to adapt to layered protocol hierarchies that support multiple network applications. Pairs of processes in host computers connected to different but interconnected computer communication networks rely on TCP for reliable communication services, assuming that it can obtain simple, potentially unreliable datagram services from lower-level protocols.

[0072] The TCP mechanism includes a heartbeat mechanism, specifically the TCP KeepAlive socket option. Once a blockchain node enables KeepAlive, it automatically sends heartbeat request packets to each data node within a specified time. Upon receiving a heartbeat request packet, the data node automatically replies with a heartbeat response packet.

[0073] In one embodiment of this application, the current blockchain node can obtain the number of data nodes currently in a communication connection state; if the number of data nodes currently in a communication connection state is less than a set threshold, a blockchain client application can be used to send heartbeat request data packets to each data node; if the number of data nodes currently in a communication connection state is greater than the set threshold, the KeepAlive socket option of the TCP protocol can be enabled to send heartbeat request data packets to each data node using the TCP mechanism.

[0074] In one embodiment of this application, the current blockchain node can obtain the heartbeat request cycle corresponding to each data node, and periodically send heartbeat request data packets to each data node according to the heartbeat request cycle.

[0075] In one embodiment of this application, the current blockchain node can obtain the communication frequency of the data communication between the current blockchain node and each data node, and then determine the heartbeat request period corresponding to the data node based on the frequency range in which the communication frequency is located.

[0076] In one embodiment of this application, there is a positive correlation between the heartbeat request period and the communication frequency; the higher the communication frequency of a data node, the longer its heartbeat request period.

[0077] In one embodiment of this application, the current blockchain node can maintain a mapping table between frequency ranges and heartbeat request cycles, and can monitor and update the communication frequency of each data node in real time in the data node list. By querying the mapping table based on the communication frequency of each data node, the frequency range in which the data node is located is obtained, and thus the heartbeat request cycle corresponding to the frequency range is determined.

[0078] In step S520, the round-trip delay of data communication between each data node is calculated based on the response time of the heartbeat response data packet.

[0079] The response time of a heartbeat response data packet refers to the time interval between when the current blockchain node sends a heartbeat request data packet and when it receives a heartbeat response data packet. After listening to the heartbeat response data packets returned by each data node, the current blockchain node can calculate the time interval between the heartbeat response data packet and the corresponding heartbeat request data packet, thereby determining the round-trip delay of data communication between each data node.

[0080] In one embodiment of this application, a method for calculating the round-trip time of data communication between data nodes based on the response duration of the heartbeat response data packet may include: acquiring the heartbeat response data packet returned by each data node; determining the response duration of the heartbeat response data packet based on the reception time of the heartbeat response data packet and the sending time of the corresponding heartbeat request data packet; and calculating the round-trip time of data communication between data nodes based on the response duration.

[0081] The response time of a heartbeat response data packet can include multiple components such as display time, transmission time, and application system time. Display time varies depending on browser or client configuration. Network transmission time in a wide area network (WAN) is generally between 5ms and 50ms; while in a local area network (LAN), network transmission time is generally less than 1ms and can be ignored. Application system time is reflected in processing logic, data read performance, and server performance. For example, factors affecting processing logic include the time complexity of the algorithm and the amount of logs; factors affecting data read performance include the rationality of database table and index design, the correctness of table joins, whether there is a waste of IO reads due to scanning a large amount of unnecessary data, and whether the SQL implementation algorithm can be optimized; factors affecting server performance include CPU utilization, disk transfer rate, and memory usage.

[0082] Figure 6 A flowchart illustrating the steps for calculating the round-trip delay of statistical data nodes in one embodiment of this application is shown, as follows: Figure 6 As shown, based on the above embodiments, the round-trip latency of data communication between statistical nodes according to response duration statistics can include the following steps S610 to S650.

[0083] Step S610: Obtain the response time of the nearest preset number of responses in real time.

[0084] Each blockchain node can maintain multiple response duration monitoring lists. Each list records the response time of a data node sending a heartbeat response data packet to the current blockchain node. For example, if a blockchain node communicates with N data nodes, it can maintain N response duration monitoring lists. Whenever a heartbeat response data packet is received, it can be assigned to the corresponding response duration monitoring list based on the source of the data packet.

[0085] Figure 7 A schematic diagram illustrating the principle of statistical round-trip delay in one embodiment of this application is shown. For example... Figure 7As shown, the current blockchain node 701 can communicate with multiple data nodes 702 simultaneously. By sending heartbeat request data packets to each data node 702 and listening to the heartbeat response data packets returned by each data node 702, the response duration of each data node in each heartbeat round and the time node when the heartbeat response data packet is received in each heartbeat round can be obtained.

[0086] Currently, blockchain node 701 maintains a response duration monitoring list 703 for each data node 702. Based on the data monitoring results, multiple sets of data, such as heartbeat rounds, time nodes, and response durations, can be written into the real-time updated response duration monitoring list 703.

[0087] In each response duration monitoring list 703, the heartbeat response data packets are sorted according to the time order of receipt. For a data node, a preset number of heartbeat response data packets closest to the current time can be filtered from all the heartbeat response data packets returned by that data node, and the response duration of each filtered heartbeat response data packet can be obtained. The number of response durations obtained is negatively correlated with the heartbeat request period; the shorter the heartbeat request period, the more response durations can be obtained. For example, if the current blockchain node sends a heartbeat request data packet to a data node every 2 seconds, the most recent 30 heartbeat response data packets returned by that data node can be obtained, and the response duration of each heartbeat response data packet can be obtained. In one embodiment of this application, the number of response durations obtained can also be a preset fixed value, and this application does not impose any special limitations on this.

[0088] Step S620: Draw a response time distribution map of data nodes based on a preset number of response times.

[0089] In one embodiment of this application, the response round can be used as the horizontal axis and the response duration as the vertical axis to draw a response duration distribution map of data nodes, which can be used to represent the distribution of the response duration of data nodes responding to each heartbeat request of the current blockchain node in different response rounds.

[0090] In one embodiment of this application, the sending time of the heartbeat request data packet or the receiving time of the heartbeat response data packet can be used as the horizontal axis and the response duration as the vertical axis to draw a response duration distribution map of the data node, which can be used to represent the distribution of the response duration of the data node in response to each heartbeat request of the current blockchain node at different heartbeat response times.

[0091] Continue to refer to Figure 7Based on the data recorded and filtered in the response time monitoring list 703, a corresponding response time distribution map 704 can be drawn for each data node. Based on the distribution of each data point in the response time distribution map 704, it can be determined whether the distribution of each data point is normal, and it can be used to predict the trend of response time changes in the future.

[0092] Step S630: Identify abnormal data in the response duration distribution map to remove abnormal data points in the response duration distribution map.

[0093] When the distribution of a data point differs significantly from that of other data points, it indicates that the data point may be an anomaly. The cause of the anomaly could be incorrect data recording or a sudden network failure. For example, if a data point experiences a sudden increase or decrease in response time, and the magnitude of this increase or decrease exceeds the average change in response time among other data points, this data point can be marked as an anomaly and removed from the response time distribution map.

[0094] In one embodiment of this application, the abnormality of a data point can be determined by comparing the change in response time between a data point and two adjacent data points with a preset change threshold. For example, the response time of a data point is X. i The response time of the adjacent preceding data point is X. i-1 The response time of the next adjacent data point is X. i+1 Therefore, the change in response time for this data point can be calculated as (X). i+1 +X i-1 -2X i ) / 2. In one embodiment of this application, the average response time change can be calculated based on the response time change of each data point, and the product of the average response time change and a preset coefficient is used as a preset change threshold.

[0095] Step S640: Perform curve fitting on the response duration distribution map after removing outlier data points to obtain a response duration fitting function that represents the response duration change state.

[0096] Curve fitting is a data processing method that approximates or analogizes the functional relationship between coordinates represented by a set of discrete points on a plane using a continuous curve; in other words, it approximates discrete data with an analytical expression. Through curve fitting, a response duration fitting function representing a continuous data distribution can be obtained from the discrete data points in the response duration distribution plot after removing outlier data points.

[0097] In one embodiment of this application, various function types can be used to perform curve fitting on the response time distribution map after removing outlier data points, and the curve function with the best fitting effect can be selected as the response time fitting function based on the fitting results. For example, this application can use linear functions, exponential functions, power functions, and hyperbolic functions to perform curve fitting on the response time distribution map after removing outlier data points, and select the function type with the best fitting effect to determine the final response time fitting function.

[0098] Step S650: Predict the round-trip delay for data communication between data nodes based on the response duration fitting function.

[0099] In one embodiment of this application, the round-trip delay for data communication with a data node in the next heartbeat cycle or at the next moment can be predicted based on the response duration fitting function.

[0100] like Figure 7 As shown, for each response duration distribution map 704, curve fitting can be performed to obtain the corresponding response duration fitting function 705. The round-trip time (RTT) for data communication between each data node can be predicted using the response duration fitting function 705.

[0101] Based on steps S610 to S650 above, the round-trip time (RTT) of a data node can be predicted using curve fitting. In one embodiment of this application, the average response time of a data node can be obtained by performing multiple heartbeat responses, and this average response time can be used as the round-trip time for data communication.

[0102] In step S530, the packet loss rate of each data node during data communication is calculated based on the data volume information carried by the heartbeat response data packet.

[0103] Figure 8 A flowchart illustrating the steps involved in calculating the packet loss rate of statistical nodes in one embodiment of this application is shown. Figure 8 As shown, based on the above embodiments, step S530 may further include the following steps S810 to S840.

[0104] Step S810: Parse the heartbeat response data packet to obtain the data volume information carried in the heartbeat response data packet. The data volume information includes the statistical time interval and the data transmission volume of the data node within the statistical time interval. The data transmission volume is the amount of block data sent by the data node.

[0105] The heartbeat response data packet includes a dedicated field for recording the data volume information of each data node. The statistical time interval is a time interval configured separately for each data node to count the amount of data sent. All data nodes can have the same statistical time interval, which is beneficial for the current blockchain node to summarize and compare the data volume information of all data nodes.

[0106] In one embodiment of this application, the data transmission volume is the transmission volume per unit time calculated based on the total amount of block data sent by a data node to other blockchain nodes within a statistical time interval.

[0107] In one embodiment of this application, a data node may also send a data message containing data volume information to the current blockchain node independently.

[0108] Step S820: Obtain the amount of data received by the current blockchain node within the statistical time interval. The amount of data received is the amount of block data received by the current blockchain node.

[0109] In one embodiment of this application, the current blockchain node can monitor the amount of data received from each data node's block data based on a statistical time interval.

[0110] In one embodiment of this application, the data received amount may be the total amount of block data received within a statistical time interval, or it may be the amount received per unit time calculated based on the total amount of data.

[0111] Compare the data transmission volume with the data reception volume; if the data transmission volume is less than the data reception volume, update the data reception volume to the data transmission volume.

[0112] Step S830: Determine the packet loss rate of the data node in each statistical time interval based on the data transmission volume and data reception volume.

[0113] The packet loss rate of the data node in each statistical time interval is determined by the formula loss = 1 - (rcv + a) / (snt + b); where loss is the packet loss rate, rcv is the amount of data received, snt is the amount of data sent, a is the first adjustment coefficient greater than or equal to 0, and b is the second adjustment coefficient greater than or equal to a.

[0114] In one embodiment of this application, a can be 1 and b can be 2.

[0115] Step S840: Determine the packet loss rate of the data node for data communication based on the packet loss rate of the data node in multiple statistical time intervals.

[0116] Figure 9A flowchart illustrating the steps for determining the packet loss rate in one embodiment of this application is shown. Figure 9 As shown, based on the above embodiments, step S840 may further include steps S910 to S950.

[0117] Step S910: In the multiple statistical time intervals closest to the current time, obtain the packet loss rate of a preset number in real time.

[0118] A blockchain node can maintain multiple packet loss rate monitoring lists. Each list records the packet loss rate incurred when a data node sends data to the current blockchain node. For example, if a blockchain node communicates with N data nodes, it can maintain N packet loss rate monitoring lists. Whenever a heartbeat response data packet is received, the packet loss rate can be calculated based on the source of the heartbeat response data packet, and the packet loss rate can be assigned to the corresponding packet loss rate monitoring list.

[0119] For example, if the statistical time interval is 1 minute, the current blockchain node can calculate the packet loss rate of data communication with a data node every 1 minute. When the preset number is 30, it means that the current blockchain node obtains the packet loss rate of the most recent 30 times (i.e., the most recent 30 statistical time intervals) in real time.

[0120] Step S920: Draw a packet loss rate distribution map of data nodes based on the preset number of packet loss rates.

[0121] In one embodiment of this application, a packet loss rate distribution chart can be plotted using the statistical round as the horizontal axis and the packet loss rate as the vertical axis. This chart represents the distribution of the data packet loss rate of data nodes sending data to the current blockchain node across different statistical rounds. In this embodiment, one statistical time interval represents one statistical round.

[0122] Step S930: Identify abnormal data in the packet loss rate distribution map to remove abnormal data points in the packet loss rate distribution map.

[0123] When the distribution of a data point differs significantly from that of other data points, it indicates that the data point may be an anomaly. The cause of the anomaly could be incorrect data recording or a sudden network failure. For example, if a data point experiences a sudden increase or decrease in packet loss rate, and the magnitude of this increase or decrease exceeds the average change in the packet loss rate distribution curves of other data points, this data point can be marked as an anomaly and removed from the packet loss rate distribution curve map.

[0124] In one embodiment of this application, the change in the packet loss rate distribution curve between a data point and two adjacent data points can be compared with a preset change threshold to determine whether the data point is abnormal. For example, the packet loss rate distribution curve of a data point is Y... i The packet loss rate of the preceding data point adjacent to it is Y. i-1 The packet loss rate of the next adjacent data point is Y. i+1 Therefore, the change in packet loss rate for this data point can be calculated as (Y). i+1 +Y i-1 -2Y i ) / 2. In one embodiment of this application, the average packet loss rate change can be calculated based on the packet loss rate change of each data point, and the product of the average packet loss rate change and a preset coefficient is used as a preset change threshold.

[0125] Step S940: Perform curve fitting on the packet loss rate distribution map after removing abnormal data points to obtain a packet loss rate fitting function to represent the packet loss rate change state.

[0126] In one embodiment of this application, various function types can be used to perform curve fitting on the packet loss rate distribution map after removing outlier data points, and the curve function with the best fitting effect can be selected as the packet loss rate fitting function based on the fitting results. For example, this application can use linear functions, exponential functions, power functions, and hyperbolic functions to perform curve fitting on the packet loss rate distribution map after removing outlier data points, and select the function type with the best fitting effect to determine the final packet loss rate fitting function.

[0127] Step S950: Predict the packet loss rate of data nodes during data communication based on the packet loss rate fitting function.

[0128] In one embodiment of this application, the packet loss rate for data communication with data nodes in the next statistical round or the next statistical time interval can be predicted based on the packet loss rate fitting function.

[0129] Based on steps S910 to S950 above, the packet loss rate of data nodes can be predicted using curve fitting. In one embodiment of this application, the average value of multiple packet loss rates of data nodes over multiple statistical time intervals can also be calculated and used as the packet loss rate for data communication.

[0130] In step S430, evaluation information for each data node is determined based on round-trip time and packet loss rate. The evaluation information is used to represent the real-time communication quality of the data node.

[0131] Figure 10 A flowchart illustrating the steps for determining data node evaluation information in one embodiment of this application is shown. Figure 10 As shown, based on the above embodiments, step S430 may further include the following steps S1010 to S1040.

[0132] Step S1010: Obtain the round-trip delay integral model and packet loss rate integral model maintained by the current blockchain node.

[0133] Figure 11 A round-trip delay integral model from one embodiment of this application is shown. For example... Figure 11 As shown, the round-trip delay integral model is a piecewise model, which includes multiple delay intervals, each of which can be mapped to a delay integral. The higher the round-trip delay, the larger the corresponding delay integral, which also indicates higher network latency.

[0134] Figure 12 An integral model for packet loss rate in one embodiment of this application is shown. For example... Figure 12 As shown, the packet loss rate integral model is similar to the round-trip delay integral model. It is also a piecewise model, which includes multiple packet loss rate intervals. Each packet loss rate interval can be associated with a packet loss rate integral.

[0135] Step S1020: Locate the time delay interval in the round-trip time delay integral model and obtain the time delay integral associated with the time delay interval.

[0136] Based on the round-trip time (RTT) of a data node, its corresponding latency interval can be found in the RTT integral model. For example, if the RTT of data node A falls within the latency interval 0 <= RTT < 50, it indicates that the network quality between data node A and the current blockchain node is good and the network latency is low, so the latency integral of data node A can be determined to be 1. As another example, if the RTT of data node B falls within the latency interval 300 <= RTT < 500, it indicates that the network quality between data node B and the current blockchain node is poor and the network latency is high, so the latency integral of data node B can be determined to be 21.

[0137] Step S1030: Find the packet loss rate interval in the packet loss rate integral model and obtain the packet loss rate integral associated with the packet loss rate interval.

[0138] Based on the packet loss rate of a data node, its packet loss rate interval can be found in the packet loss rate integral model. For example, if the packet loss rate of data node A falls within the interval 0 <= Loss < 4%, it indicates that the network quality between data node A and the current blockchain node is good and the data transmission is normal, so the packet loss rate integral of data node A can be determined to be 3. As another example, if the packet loss rate of data node B falls within the interval 10% <= Loss < 20%, it indicates that the network quality between data node B and the current blockchain node is poor and the data transmission is abnormal, so the packet loss rate integral of data node B can be determined to be 20.

[0139] Step S1040: Determine the evaluation information of the data node based on the latency integral and the packet loss rate integral.

[0140] In one embodiment of this application, the latency evaluation weight and packet loss rate evaluation weight associated with the data node are obtained; the latency integral and packet loss rate integral are weighted according to the latency evaluation weight and packet loss rate evaluation weight to obtain the evaluation information of the data node.

[0141] Based on the above steps S1010 to S1040, the evaluation information of each data node can be determined. This evaluation information can be expressed as a weighted integral obtained by weighting the round-trip delay and packet loss rate.

[0142] In step S440, a target node is selected from multiple data nodes based on the evaluation information, and a block data synchronization request is sent to the target node according to the block height.

[0143] When a current blockchain node receives the block height from a data node, it can determine whether the current blockchain node needs to synchronize block data based on the block height. If so, the final score of each data node is evaluated, and the data node with the lowest score—that is, the data node with the best overall performance in terms of network latency and packet loss rate—is selected. Then, the block data synchronization request is sent to the data node with the lowest score, ultimately improving the overall block data synchronization speed of the blockchain network.

[0144] In the block data synchronization method provided in this application embodiment, an integral model is established through two dimensions: RTT and packet loss rate. This model can make full use of network resources and the computing resources of the nodes themselves, thereby improving the speed of block synchronization. Furthermore, it can dynamically schedule the data node network to ensure high availability of block data transmission.

[0145] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0146] The following describes an apparatus embodiment of this application, which can be used to execute the block data synchronization method in the above embodiments of this application. Figure 13 A structural block diagram of a block data synchronization device provided in an embodiment of this application is shown. Figure 13 The block data synchronization device 1300 shown may mainly include:

[0147] The acquisition module 1310 is configured to acquire multiple data nodes that are in a communication connection state, wherein the data nodes are blockchain nodes used to provide block data reading services;

[0148] The statistics module 1320 is configured to separately calculate the round-trip latency and packet loss rate of data communication for each of the data nodes;

[0149] Evaluation module 1330 is configured to determine evaluation information for each data node based on the round-trip delay and packet loss rate, wherein the evaluation information is used to represent the real-time communication quality of the data node.

[0150] The request module 1340 is configured to select a target node from the plurality of data nodes based on the evaluation information, and send a block data synchronization request to the target node based on the block height.

[0151] In one embodiment of this application, based on the above embodiments, the statistics module 1320 includes:

[0152] The heartbeat monitoring module 1321 is configured to send heartbeat request data packets to each of the data nodes respectively, and to monitor the heartbeat response data packets returned by the data nodes.

[0153] The latency statistics module 1322 is configured to calculate the round-trip latency of data communication between each data node based on the response time of the heartbeat response data packet.

[0154] The packet loss rate statistics module 1323 is configured to calculate the packet loss rate of each data node in data communication based on the data volume information carried by the heartbeat response data packet.

[0155] In one embodiment of this application, based on the above embodiments, the heartbeat monitoring module 1321 may further include:

[0156] The period acquisition module is configured to acquire the heartbeat request period corresponding to each of the data nodes;

[0157] The heartbeat sending module is configured to periodically send heartbeat request data packets to each of the data nodes according to the heartbeat request period.

[0158] In one embodiment of this application, based on the above embodiments, the period acquisition module may further include:

[0159] The frequency acquisition module is configured to acquire the communication frequency of the current blockchain node and each of the data nodes for data communication.

[0160] The period determination module is configured to determine the heartbeat request period corresponding to the data node based on the frequency range in which the communication frequency is located.

[0161] In one embodiment of this application, based on the above embodiments, the latency statistics module 1322 may further include:

[0162] The response acquisition module is configured to acquire the heartbeat response data packets returned by each of the data nodes;

[0163] The response duration determination module is configured to determine the response duration of the heartbeat response data packet based on the reception time of the heartbeat response data packet and the sending time of the corresponding heartbeat request data packet;

[0164] The round-trip delay statistics module is configured to calculate the round-trip delay of data communication between the data nodes based on the response duration.

[0165] In one embodiment of this application, based on the above embodiments, the round-trip delay statistics module includes:

[0166] The response duration acquisition module is configured to acquire the preset number of response durations closest to the current time in real time;

[0167] The response duration plotting module is configured to plot the response duration distribution of the data nodes based on the preset number of response durations;

[0168] The first anomaly identification module is configured to identify abnormal data in the response duration distribution map in order to remove abnormal data points in the response duration distribution map;

[0169] The first curve fitting module is configured to perform curve fitting on the response duration distribution map after removing the abnormal data points to obtain a response duration fitting function that represents the response duration change state.

[0170] The round-trip delay prediction module is configured to predict the round-trip delay of the data node for data communication based on the response duration fitting function.

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

[0172] The transmission volume determination module is configured to parse the heartbeat response data packet to obtain the data volume information carried in the heartbeat response data packet. The data volume information includes a statistical time interval and the data transmission volume of the data node within the statistical time interval. The data transmission volume is the amount of block data transmitted by the data node.

[0173] The receiving volume determination module is configured to obtain the data receiving volume of the current blockchain node within the statistical time interval, wherein the data receiving volume is the amount of block data received by the current blockchain node.

[0174] The interval packet loss rate statistics module is configured to determine the packet loss rate of the data node in each statistical time interval based on the data transmission volume and the data reception volume.

[0175] The packet loss rate determination module is configured to determine the packet loss rate of the data node for data communication based on the packet loss rate of the data node in multiple statistical time intervals.

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

[0177] The numerical comparison module is configured to compare the numerical relationship between the data transmission amount and the data reception amount;

[0178] The value update module is configured to update the value of the data received to the data sent if the data sent is less than the data received.

[0179] In one embodiment of this application, based on the above embodiments, the interval packet loss rate statistics module can be further configured as follows:

[0180] The packet loss rate of the data node in each statistical time interval is determined according to the formula loss = 1 - (rcv + a) / (snt + b); where loss is the packet loss rate, rcv is the amount of data received, snt is the amount of data sent, 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.

[0181] In one embodiment of this application, based on the above embodiments, the packet loss rate determination module may further include:

[0182] The interval packet loss rate acquisition module is configured to acquire a preset number of packet loss rates in real time within multiple statistical time intervals closest to the current time.

[0183] The packet loss rate plotting module is configured to plot a packet loss rate distribution map of the data nodes based on the preset number of packet loss rates;

[0184] The second anomaly identification module is configured to identify abnormal data in the packet loss rate distribution map in order to remove abnormal data points in the packet loss rate distribution map.

[0185] The second curve fitting module is configured to perform curve fitting on the packet loss rate distribution map after removing the abnormal data points to obtain a packet loss rate fitting function that represents the packet loss rate change state.

[0186] The packet loss rate prediction module is configured to predict the packet loss rate of the data node during data communication based on the packet loss rate fitting function.

[0187] In one embodiment of this application, based on the above embodiments, the evaluation module 1330 includes:

[0188] The model acquisition module 1331 is configured to acquire the round-trip delay integral model and packet loss rate integral model maintained by the current blockchain node.

[0189] The delay integral acquisition module 1332 is configured to search for the delay interval in the round-trip delay integral model and acquire the delay integral associated with the delay interval;

[0190] The packet loss rate integral acquisition module 1333 is configured to search for the packet loss rate interval in the packet loss rate integral model and acquire the packet loss rate integral associated with the packet loss rate interval.

[0191] The evaluation information determination module 1334 is configured to determine the evaluation information of the data node based on the latency integral and the packet loss rate integral.

[0192] In one embodiment of this application, based on the above embodiments, the evaluation information determination module 1334 includes:

[0193] The weight acquisition module is configured to acquire the latency evaluation weight and packet loss rate evaluation weight related to the data node.

[0194] The integral weighting module is configured to perform weighted processing on the latency integral and the packet loss rate integral according to the latency evaluation weight and the packet loss rate evaluation weight to obtain the evaluation information of the data node.

[0195] The specific details of the block data synchronization device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0196] Figure 14 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0197] It should be noted that, Figure 14 The computer system 1400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0198] like Figure 14 As shown, the computer system 1400 includes a central processing unit (CPU) 1401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1402 or programs loaded from storage section 1408 into random access memory (RAM). The RAM 1403 also stores various programs and data required for system operation. The CPU 1401, ROM 1402, and RAM 1403 are interconnected via a bus 1404. An input / output interface 1405 (I / O interface) is also connected to the bus 1404.

[0199] The following components are connected to the input / output interface 1405: an input section 1406 including a keyboard, mouse, etc.; an output section 1407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a local area network card, modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to the input / output interface 1405 as needed. A removable medium 1411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1410 as needed so that computer programs read from it can be installed into the storage section 1408 as needed.

[0200] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1409, and / or installed from removable medium 1411. When the computer program is executed by central processing unit 1401, it performs various functions defined in the system of this application.

[0201] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0202] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0203] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0204] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0205] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0206] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for synchronizing block data, characterized in that, include: Acquire multiple data nodes that are in a communication connection state, wherein the data nodes are blockchain nodes used to provide block data reading services; The round-trip latency and packet loss rate of data communication for each of the data nodes are calculated separately. Obtain the round-trip latency integral model and packet loss rate integral model maintained by the current blockchain node; In the round-trip delay integral model, find the delay interval in which the round-trip delay is located, and obtain the delay integral associated with the delay interval; Find the packet loss rate interval in the packet loss rate integral model and obtain the packet loss rate integral associated with the packet loss rate interval; Obtain the latency evaluation weight and packet loss rate evaluation weight associated with the data node; The latency integral and the packet loss rate integral are weighted according to the latency evaluation weight and the packet loss rate evaluation weight to obtain the evaluation information of the data node. The evaluation information is used to represent the real-time communication quality of the data node. Based on the evaluation information, a target node is selected from the plurality of data nodes, and a block data synchronization request is sent to the target node according to the block height; The method for calculating round-trip latency includes: acquiring the response duration of a preset number of heartbeat response data packets closest to the current time in real time; plotting the response duration distribution map of the data node based on the response duration of the preset number of heartbeat response data packets; identifying abnormal data in the response duration distribution map to remove abnormal data points; performing curve fitting on the response duration distribution map after removing the abnormal data points to obtain a response duration fitting function representing the response duration change state; and predicting the round-trip latency of the data node for data communication based on the response duration fitting function.

2. The block data synchronization method according to claim 1, characterized in that, The round-trip latency and packet loss rate for data communication at each of the aforementioned data nodes are calculated separately, including: Send heartbeat request data packets to each of the data nodes respectively, and listen for heartbeat response data packets returned by the data nodes; The round-trip latency of data communication between each data node is calculated based on the response time of the heartbeat response data packet. The packet loss rate of each data node during data communication is calculated based on the data volume information carried by the heartbeat response data packet.

3. The block data synchronization method according to claim 2, characterized in that, Send heartbeat request data packets to each of the data nodes respectively, including: Obtain the heartbeat request period corresponding to each of the data nodes respectively; Heartbeat request data packets are periodically sent to each of the data nodes according to the stated heartbeat request cycle.

4. The block data synchronization method according to claim 3, characterized in that, Obtain the heartbeat request period corresponding to each of the data nodes, including: Obtain the communication frequency between the current blockchain node and each of the data nodes; The heartbeat request period corresponding to the data node is determined based on the frequency range in which the communication frequency is located.

5. The block data synchronization method according to claim 2, characterized in that, The round-trip time of data communication between each data node is calculated based on the response duration of the heartbeat response data packet, including: Obtain the heartbeat response data packets returned by each of the data nodes; The response duration of the heartbeat response data packet is determined based on the reception time of the heartbeat response data packet and the sending time of the corresponding heartbeat request data packet; The round-trip latency of data communication between the data nodes is calculated based on the response duration.

6. The block data synchronization method according to claim 2, characterized in that, Based on the data volume information carried by the heartbeat response data packet, the packet loss rate of each data node during data communication is calculated, including: Parse the heartbeat response data packet to obtain the data volume information carried in the heartbeat response data packet. The data volume information includes the statistical time interval and the data transmission volume of the data node within the statistical time interval. The data transmission volume is the amount of block data sent by the data node. Obtain the data received by the current blockchain node within the statistical time interval, where the data received is the amount of block data received by the current blockchain node. The packet loss rate of the data node in each statistical time interval is determined based on the data transmission volume and the data reception volume. The packet loss rate of the data node during data communication is determined based on the packet loss rate of the data node in multiple statistical time intervals.

7. The block data synchronization method according to claim 6, characterized in that, Before determining the packet loss rate of the data node in each statistical time interval based on the data transmission volume and the data reception volume, the method further includes: Compare the numerical relationship between the data sent and the data received; If the amount of data sent is less than the amount of data received, then the value of the amount of data received is updated to the amount of data sent.

8. The block data synchronization method according to claim 6, characterized in that, Determining the packet loss rate of the data node in each statistical time interval based on the data transmission volume and the data reception volume includes: The packet loss rate of the data node in each statistical time interval is determined according to the formula loss = 1-(rcv+a) / (snt+b); where loss is the packet loss rate, rcv is the amount of data received, snt is the amount of data sent, 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.

9. The block data synchronization method according to claim 6, characterized in that, The packet loss rate of the data node for data communication is determined based on the packet loss rate of the data node within multiple statistical time intervals, including: Within the multiple statistical time intervals closest to the current moment, obtain a preset number of packet loss rates in real time; Draw a packet loss rate distribution map of the data nodes based on the preset number of packet loss rates; Abnormal data is identified in the packet loss rate distribution map to remove abnormal data points in the packet loss rate distribution map; Curve fitting is performed on the packet loss rate distribution map after removing the abnormal data points to obtain a packet loss rate fitting function that represents the packet loss rate change state. The packet loss rate of the data node during data communication is predicted based on the packet loss rate fitting function.

10. A block data synchronization device, characterized in that, include: The acquisition module is configured to acquire multiple data nodes that are in a communication connection state, wherein the data nodes are blockchain nodes used to provide block data reading services; The statistics module is configured to separately calculate the round-trip latency and packet loss rate of data communication for each of the data nodes; The evaluation module is configured to obtain the round-trip delay integral model and packet loss rate integral model maintained by the current blockchain node; find the delay interval in the round-trip delay integral model where the round-trip delay is located, and obtain the delay integral associated with the delay interval; In the packet loss rate integral model, find the packet loss rate interval where the packet loss rate is located, and obtain the packet loss rate integral associated with the packet loss rate interval; obtain the latency evaluation weight and packet loss rate evaluation weight associated with the data node; perform weighted processing on the latency evaluation weight and packet loss rate evaluation weight to obtain the evaluation information of the data node, which is used to represent the real-time communication quality of the data node; The request module is configured to select a target node from the plurality of data nodes based on the evaluation information, and send a block data synchronization request to the target node based on the block height; The statistics module is further configured to: acquire in real time the response duration of a preset number of heartbeat response data packets closest to the current time; plot the response duration distribution map of the data nodes based on the response duration of the preset number of heartbeat response data packets; identify abnormal data in the response duration distribution map to remove abnormal data points; perform curve fitting on the response duration distribution map after removing the abnormal data points to obtain a response duration fitting function to represent the response duration change state; and predict the round-trip latency of the data nodes for data communication based on the response duration fitting function.

11. A computer-readable medium, characterized in that, The computer-readable medium stores a computer program that, when executed by a processor, implements the block data synchronization method according to any one of claims 1 to 9.

12. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to cause the electronic device to perform the block data synchronization method according to any one of claims 1 to 9 by executing the executable instructions.

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

Images