Block chain data acquisition method and device, electronic equipment and readable medium

Abstract

The invention provides a block chain data acquisition method and device, electronic equipment and a readable medium. The method comprises the steps that node information of multiple block chain nodes in the block chain system is acquired, the node information of the multiple block chain nodes comprises local block height values of the nodes and historical communication results of the nodes, and the historical communication results are used for representing whether block chain data are successfully acquired from the block chain nodes or not; scoring according to the historical communication results of the plurality of block chain nodes to obtain node scores of the plurality of block chain nodes; according to the block height values and the node scores of the plurality of block chains, selecting a target communication node satisfying a target condition from the plurality of block chain nodes; and obtaining the block chain data from the target communication node, thereby updating local data of one block chain node in the block chain system according to the obtained block chain data. The method can save processing resources and improve data acquisition efficiency.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain data acquisition method, device, electronic device and readable medium. Background Art

[0002] During the operation of a blockchain node, due to some reasons, the local block ledger data may lag behind the block ledger on the entire chain, and the node needs to pull block data from other blockchain nodes with higher block heights than itself. In this process, for the complex operating environment of the blockchain, remote nodes may affect the synchronization of data on local nodes due to network and malicious issues. Therefore, there needs to be a better mechanism to ensure which node is selected to synchronize blocks optimally and how to deal with abnormal block synchronization.

[0003] In the related art, when obtaining data from a remote node, the remote node will be polled to pull blocks. If the communication is unstable or the node has incorrect data, it will be removed from the polling sequence and rejoined after the node data is successfully obtained.

[0004] However, in such schemes, nodes with unstable communications or nodes that provide erroneous data may be added back into the polling sequence after being removed from the polling sequence due to the immediate receipt of node data, causing subsequent data acquisition processes to fail, wasting processing resources and reducing data acquisition efficiency. Summary of the invention

[0005] Based on the above technical problems, the present application provides a blockchain data acquisition method, device, electronic device and readable medium to save processing resources and improve data acquisition efficiency.

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

[0007] According to one aspect of an embodiment of the present application, a blockchain data acquisition method is provided, including:

[0008] Obtain node information of multiple blockchain nodes in a blockchain system, wherein the node information of the multiple blockchain nodes includes a local block height value of the node and a historical communication result of the node, wherein the historical communication result is used to indicate whether blockchain data is successfully obtained from the blockchain node;

[0009] Scoring the multiple blockchain nodes according to historical communication results to obtain node scores of the multiple blockchain nodes;

[0010] Selecting a target communication node that meets a target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores;

[0011] Obtain blockchain data from the target communication node to update local data of a blockchain node in the blockchain system according to the acquired blockchain data.

[0012] According to one aspect of an embodiment of the present application, a blockchain data acquisition device is provided, including:

[0013] An information acquisition module is configured to acquire node information of multiple blockchain nodes in a blockchain system, wherein the node information of the multiple blockchain nodes includes a local block height value of the node and a historical communication result of the node, wherein the historical communication result is used to indicate whether the blockchain data is successfully acquired from the blockchain node;

[0014] A scoring module is configured to score the multiple blockchain nodes according to the historical communication results of the multiple blockchain nodes to obtain node scores of the multiple blockchain nodes;

[0015] A node selection module, configured to select a target communication node that meets a target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores;

[0016] The data acquisition module is configured to acquire blockchain data from the target communication node to update the local data of a blockchain node in the blockchain system according to the acquired blockchain data.

[0017] In some embodiments of the present application, based on the above technical solution, the data acquisition module is configured to: send a data acquisition request to the target communication node to obtain the blockchain data that the target communication node feedbacks in response to the data acquisition request; if a response message of the target communication node to the data acquisition request is not received within a preset response time, then an acquisition failure entry is added to the node information of the target communication node.

[0018] In some embodiments of the present application, based on the above technical solution, the data acquisition module is also configured to: receive the blockchain data fed back by the target communication node in response to the data acquisition request; perform data verification on the blockchain data according to the local data of the blockchain; if the data verification passes, update the local data of the blockchain according to the blockchain data; if the data verification fails, add a verification failure entry to the node information of the target communication node.

[0019] In some embodiments of the present application, based on the above technical solution, the information acquisition module is also configured to: send a height value acquisition request to the multiple blockchain nodes; receive the block height values ​​fed back by the multiple blockchain nodes in response to the height value acquisition request; and update the node information of the multiple blockchain nodes according to the block height values ​​from the multiple blockchain nodes.

[0020] In some embodiments of the present application, based on the above technical solution, the information acquisition module is also configured as follows: if no blockchain node responds to the height value acquisition request within a response period, a connection exception entry is added to the node information of the non-responding blockchain node.

[0021] In some embodiments of the present application, based on the above technical solution, the information acquisition module is further configured to: count the number of abnormal connection entries in the node information of the unresponsive blockchain node; if the number of abnormal connection entries exceeds the abnormal connection number threshold, the unresponsive blockchain node is marked as offline to stop data communication with the unresponsive blockchain node; after marking the unresponsive blockchain node as offline, when a communication message is received from the unresponsive blockchain node, the unresponsive blockchain node is marked as online to resume data communication with the unresponsive blockchain node.

[0022] In some embodiments of the present application, based on the above technical solution, each record entry in the node information includes the local block height when the entry is generated; the scoring module is specifically configured to: compare the local block height of each record entry in the node information of the multiple blockchain nodes with the current block height of the local blockchain node to obtain a comparison result; for the multiple blockchain nodes, according to the comparison result, obtain the record entry in which the height difference between the local block height and the current block height is less than the height difference threshold, and obtain the scoring record entry of each blockchain node; score each blockchain node according to the scoring record entry to obtain the node score of the multiple blockchain nodes.

[0023] In some embodiments of the present application, based on the above technical solution, the scoring module is also configured to: compare the local block height of each record entry in the node information of the multiple blockchain nodes with the current block height of the local blockchain node to obtain a comparison result; if the comparison result indicates that the height difference between the local block height of any record entry and the current block height exceeds the expired height threshold, the record entry is deleted from the node information.

[0024] In some embodiments of the present application, based on the above technical solution, the node information of the blockchain node also includes the number of requests; the node selection module is specifically configured as follows: according to the block height values ​​and node scores of the multiple blockchain nodes, the blockchain node with the highest block height and a node score greater than the score threshold is selected as a candidate node; the candidate node with the least number of requests is determined as the target communication node, and the number of requests in the node information of the target communication node is incremented.

[0025] In some embodiments of the present application, based on the above technical solution, the node selection module is also configured to: when the blockchain data of the target communication node is received or when the blockchain data of the target communication node is not received within a predetermined time period, the number of requests in the node information of the target communication node is decremented.

[0026] In some embodiments of the present application, based on the above technical solution, the scoring module is specifically configured as follows: for each blockchain node, obtaining a specified record entry of a specified record type in the node information, wherein the specified record type includes at least one of a connection abnormality entry, an acquisition failure entry, and an acquisition failure entry; deducting points from each blockchain node according to the number of the specified record entries of each blockchain node to obtain node scores of the multiple blockchain nodes.

[0027] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute a blockchain data acquisition method as in the above technical solution by executing the executable instructions.

[0028] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the blockchain data acquisition method in the above technical solution is implemented.

[0029] According to one aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the blockchain data acquisition method provided in the above-mentioned various optional implementations.

[0030] In an embodiment of the present application, a blockchain node first obtains node information of multiple blockchain nodes, wherein the node information of the multiple blockchain nodes includes the block height value and node information of the blockchain node, wherein the node information includes the historical communication result of obtaining blockchain data from the blockchain node, and then the blockchain node scores the multiple blockchain nodes according to the historical communication results, and obtains the node scores of the multiple blockchain nodes, and the node scores are negatively correlated with the number of negative results of the historical communication results, and then selects the target communication node that meets the target condition from the multiple blockchain nodes according to the block height value and the node score of the multiple blockchains, and finally obtains the blockchain data of the target communication node from the target communication node to update the local data of the blockchain according to the blockchain data. By scoring the nodes according to the behavior of the nodes and selecting the communication nodes according to the scoring results, the selection of the communication nodes can be dynamically selected according to the communication results between the nodes, avoiding the failure of obtaining data caused by the nodes with unstable communication or the nodes that provide wrong data being repeatedly selected as the target nodes for obtaining data, saving processing resources and improving data acquisition efficiency.

[0031] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0033] In the attached picture:

[0034] Figure 1 This is a system architecture applied to a blockchain data acquisition solution according to an embodiment of the present application.

[0035] Figure 2 This is a schematic diagram of a blockchain network in an embodiment of the present application.

[0036] Figure 3 This is a schematic diagram of blocks in a blockchain network in an embodiment of the present application.

[0037] Figure 4 The present invention is a flowchart of a method for obtaining blockchain data according to an embodiment of the present application.

[0038] Figure 5 The present invention is a flowchart of a method for obtaining blockchain data according to an embodiment of the present application.

[0039] Figure 6 The present invention is a flowchart of a method for obtaining blockchain data according to an embodiment of the present application.

[0040] Figure 7 The present invention is a flowchart of a method for obtaining blockchain data according to an embodiment of the present application.

[0041] Figure 8 The figure is a schematic flowchart of deleting a record entry in an embodiment of the present application.

[0042] Fig. 9 The present invention is a flowchart of a method for obtaining blockchain data according to an embodiment of the present application.

[0043] Fig.10 This is a flowchart of determining a target communication node based on the number of requests in an embodiment of the present application.

[0044] Fig.11 This is a schematic flowchart of the overall process of blockchain data acquisition in an embodiment of the present application.

[0045] Fig.12 The block diagram schematically shows the composition of the blockchain data acquisition device in the embodiment of the present application.

[0046] Fig.13 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0047] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more comprehensive and complete and fully convey the concept of the example embodiments to those skilled in the art.

[0048] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0049] 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 may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0050] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0051] It should be understood that the solution of the present application can be applied to the scenario of obtaining data between nodes of the blockchain, and is specifically applied in the process of block synchronization of blockchain nodes. Synchronizing blocks is the process of nodes pulling block data from other blockchain nodes with higher block heights than themselves. In such scenarios, during the operation of blockchain nodes, due to poor network communication, node offline, or the influence of erroneous data or malicious nodes, the local block ledger data will lag behind the block ledger on the entire chain. At this time, a synchronization mechanism is needed to ensure that the node data can catch up with the data on the chain. In this process, for the complex operating environment of the blockchain, remote nodes will affect the synchronization of data by local nodes due to network, malicious and other issues. Therefore, there is a need for a suitable mechanism to ensure which node is selected to synchronize the block optimally, and how to deal with abnormal block synchronization.

[0052] In the related art, when obtaining data from a remote node, the remote node will be polled to pull blocks. If the communication is unstable or the node has incorrect data, it will be removed from the polling sequence and rejoined after the node data is successfully obtained.

[0053] However, in such schemes, nodes with unstable communications or nodes that provide erroneous data may be added back into the polling sequence after being removed from the polling sequence due to the immediate receipt of node data, causing subsequent data acquisition processes to fail, wasting processing resources and reducing data acquisition efficiency.

[0054] Based on such problems, the technical solution of the embodiment of the present application proposes a blockchain data acquisition solution. Specifically, Figure 1As shown, the system architecture applied to the blockchain data acquisition solution according to the embodiment of the present application may include a blockchain network composed of multiple blockchain node devices 110. The blockchain node device 110 may include a smart phone, a tablet computer, a laptop computer, an intelligent voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, and the like. The blockchain node device 110 may also be a server that provides various services, which may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. There may be various types of communication media for the connection of the communication link between the blockchain node devices 110, such as a wired communication link or a wireless communication link.

[0055] According to the implementation needs, the system architecture in the embodiment of the present application can have any number of terminal devices and servers. For example, the blockchain node device 110 can be a server group composed of multiple server devices. In addition, the technical solution provided in the embodiment of the present application can be applied to any blockchain node device 110, or can be implemented by multiple blockchain node devices 110, and the present application does not make any special restrictions on this.

[0056] In one embodiment of the present application, the blockchain node device 110 obtains node information of multiple blockchain nodes in the blockchain system, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication results of the node, and the historical communication results are used to indicate whether the blockchain data is successfully obtained from the blockchain node.

[0057] Subsequently, the blockchain node device 110 scores the multiple blockchain nodes according to the historical communication results to obtain node scores of the multiple blockchain nodes.

[0058] After scoring, the blockchain node device 110 selects a target communication node that meets the target conditions from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores, and finally obtains blockchain data from the target communication node to update the local data of the current blockchain node device 110 according to the obtained blockchain data.

[0059] Specifically, the blockchain node device can be any node in the blockchain, and the local data of the node is inconsistent with the latest data in the blockchain due to communication failure or other nodes doing evil. The blockchain node will select a suitable node from the blockchain and send a request to the node so that the node sends the latest block data to it, thereby completing the data synchronization between the nodes. In an embodiment of the present application, the blockchain node device will save the behavior record of communicating with multiple blockchain nodes, and the behavior record is used to record the data communication results with other nodes, as one of the criteria for judging whether the node is suitable as a provider of blockchain data.

[0060] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks (i.e. blocks) generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain is maintained by the nodes in the blockchain network. For example, in Figure 2 The blockchain network shown may include multiple nodes 201, and the multiple nodes 201 may be the various clients forming the blockchain network. Each node 201 may receive input information during normal operation, and maintain the shared data in the blockchain network based on the received input information. In order to ensure the information intercommunication within the blockchain network, there may be an information connection between each node in the blockchain network, and information may be transmitted between nodes through the above information connection. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network obtain the input information according to the consensus algorithm, and store the input information as shared data, so that the data stored on all nodes in the blockchain network are consistent.

[0061] Each node in the blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes, so that the generated blocks can be broadcast to other nodes in the blockchain network according to the node identifiers of other nodes. A node identifier list can be maintained in each node, and the node name and node identifier are stored in the node identifier list accordingly. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node.

[0062] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 3As shown, the blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version numbers, timestamps, and difficulty values, and the block body stores input information. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores input information feature values ​​of the current block, feature values ​​of the block header of the parent block, version numbers, timestamps, and difficulty values, and so on. This ensures that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, thereby ensuring the security of the input information in the block.

[0063] The blockchain data obtained by the blockchain node device 110 can be Figure 3 It is understood that although three blocks are shown, the blockchain node device 110 can obtain more or fewer blocks at a time, or obtain all blocks in the blockchain at one time.

[0064] Figure 4 A flowchart of a blockchain data acquisition method according to an embodiment of the present application is shown. The blockchain data acquisition method can be executed by a device with a computing and processing function, such as a computing device that can be a blockchain node. Figure 4 As shown, the blockchain data acquisition method at least includes steps S410 to S440, which are described in detail as follows:

[0065] Step S410, obtaining node information of multiple blockchain nodes in the blockchain system, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication results of the node, and the historical communication results are used to indicate whether the blockchain data is successfully obtained from the blockchain node.

[0066] In an embodiment of the present application, a local blockchain node obtains node information of multiple blockchain nodes in a blockchain. Node information is usually data maintained by a local blockchain node in a local cache for all other blockchain nodes in the blockchain. Usually, a local blockchain node maintains node information for each other blockchain node separately, and multiple blockchain nodes maintain node information independently. The node information includes the block height value of the corresponding blockchain node and the historical communication result of the node. The block height value is usually obtained by the local blockchain node from other blockchain nodes and saved locally, while the historical communication result is recorded by the local blockchain node during the communication process with other blockchain nodes. The historical communication result is used to indicate whether the blockchain data is successfully obtained from the blockchain node, and the behavior of other blockchain nodes in this communication process can usually be determined based on the historical communication result. For example, if the historical communication result is a data acquisition failure or a communication timeout, it means that the blockchain node has a communication failure behavior, and if the historical communication result is a data verification failure, it means that the blockchain node has a behavior of providing wrong data in local communication, etc. It can be understood that the historical communication result generally contains two types of records, namely positive records and negative records. Positive records usually refer to normal actions taken by blockchain nodes or actions that are conducive to the normal operation of the blockchain, such as timely provision of data or effective consensus or endorsement, while negative records refer to abnormal actions taken by blockchain nodes or actions that are not conducive to the normal operation of the blockchain, such as disconnection from the network or malicious acts, etc. The historical communication results can also include the results of other blockchain communication processes other than the data synchronization process, such as the results of blockchain transactions or consensus processes.

[0067] Step S420: Scoring the multiple blockchain nodes according to their historical communication results to obtain node scores for the multiple blockchain nodes.

[0068] The local blockchain node will traverse the historical communication results of multiple blockchain nodes in the local cache to score each blockchain node, thereby obtaining the node scores of multiple blockchain nodes. The node score is negatively correlated with the number of negative results of the historical communication results, that is, the more negative results there are, the lower the node score. Correspondingly, the node score is positively correlated with the number of positive results of the historical communication results, that is, the more positive results there are, the higher the node score. Specifically, the initial score of each blockchain node is the same. For a blockchain node, the local blockchain node will traverse all the historical communication result entries in the node information of the node. Each negative result will deduct one point, and each positive result will increase one point. After traversing all the entries, the node score of the blockchain node can be obtained. It can be understood that the scores of positive results and negative results can be different, or the positive results and negative results can be further classified, and the scores of different types of positive results and negative results can also be different, thereby improving the precision of node scoring.

[0069] Step S430: Select a target communication node that meets the target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores.

[0070] The local blockchain node will determine the blockchain nodes whose block height values ​​and node scores meet the target conditions as target communication nodes. The target conditions include rules for setting block height values ​​and node scores. For example, the block height values ​​and node scores are sorted separately, and the two highest ranked nodes or the top 5 nodes are determined as target communication nodes. The target conditions are usually pre-stored in the blockchain node, and the target conditions of each blockchain node in the blockchain can be the same or different. The local blockchain node can determine one or more blockchain nodes as target communication nodes. For example, the blockchain node with the highest node score is selected from multiple blockchain nodes that meet the target conditions. If the node scores are the same, all blockchain nodes with the same score are determined as target communication nodes.

[0071] Step S440: Obtain blockchain data from the target communication node to update local data of a blockchain node in the blockchain system according to the obtained blockchain data.

[0072] After determining the target communication node, the local blockchain node obtains the blockchain data of the target communication node from the target communication node to update the local data of the blockchain according to the blockchain data. The blockchain data is the blockchain data provided by the target communication node based on the blockchain account book it saves. Depending on the way of obtaining the blockchain data, the blockchain data provided by the target communication node can be incremental data determined based on the local data of the local blockchain node, or it can be the full data containing all blocks on the blockchain. In an optional embodiment of the present application, the local blockchain node will send its local current block height value to the target communication node, such as 200, and the target communication node will determine the block to be provided based on its own block height value. For example, if the target communication node's own block height value is 205, the target communication node will provide blocks 201 to 205 to the local blockchain node.

[0073] In an embodiment of the present application, a blockchain node first obtains node information of multiple blockchain nodes, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication result of the node, and the historical communication result is used to indicate whether the blockchain data is successfully obtained from the blockchain node. Subsequently, the blockchain node scores the multiple blockchain nodes according to the historical communication results to obtain the node scores of the multiple blockchain nodes, and then selects the target communication node that meets the target conditions from the multiple blockchain nodes according to the block height value of the multiple blockchains and the node score, and finally obtains the blockchain data from the target communication node to update the local data of a blockchain node in the blockchain system according to the obtained blockchain data. By scoring the nodes according to the behavior of the nodes and selecting the communication nodes according to the scoring results, the selection of the communication nodes can be dynamically selected according to the communication results between the nodes, avoiding the failure of obtaining data caused by the nodes with unstable communication or the nodes that provide wrong data being repeatedly selected as the target nodes for obtaining data, saving processing resources and improving data acquisition efficiency.

[0074] In some optional embodiments, in the process of scoring based on the historical communication results of multiple blockchain nodes and obtaining the node scores of multiple blockchain nodes, for each blockchain node, the local blockchain node will obtain the specified record entry of the specified record type in the node information, and the specified record type includes at least one of the abnormal connection entry, the failed acquisition entry and the failed acquisition entry. The record type of the record entry is usually used to indicate the communication type involved in the entry. The abnormal connection entry, the failed acquisition entry and the failed acquisition entry are all entries associated with the communication connectivity of the blockchain node. Therefore, the communication connectivity of the target communication node obtained by scoring based on these specified types of entries is better. In some embodiments, the specified record type can also be a good consensus entry, which is usually determined according to the data or consensus results provided by the blockchain node during the consensus process of the blockchain node, that is, if a correct verification consensus vote is provided, a positive result is recorded, and if wrong malicious data is provided, a negative result is recorded. Finally, the local blockchain node deducts points from each blockchain node according to the number of specified record entries of each blockchain node to obtain the node scores of multiple blockchain nodes. Connection abnormal entries, acquisition failure entries, and acquisition failure entries are all negative results, so points will be deducted according to the number of negative results during the scoring process. By selecting specific types of record entries for scoring, the scoring process allows different scoring methods or rules to be used according to different needs, which is conducive to selecting target communication nodes that better meet actual needs and improving the flexibility of the data acquisition process.

[0075] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown in the figure are as follows Figure 5 As shown, in a blockchain data acquisition method of an embodiment of the present application, the blockchain data acquisition method may include the following steps:

[0076] Step S510, obtaining node information of multiple blockchain nodes in the blockchain system, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication results of the node, and the historical communication results are used to indicate whether the blockchain data is successfully obtained from the blockchain node.

[0077] Optionally, the implementation details of step S510 are the same as Figure 4 The step S410 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0078] Step S520: Scoring is performed according to the historical communication results of the multiple blockchain nodes to obtain node scores of the multiple blockchain nodes.

[0079] Optionally, the implementation details of step S520 are the same as Figure 4The step S420 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0080] Step S530: Select a target communication node that meets the target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores.

[0081] Optionally, the implementation details of step S530 are the same as Figure 4 The step S430 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0082] Step S540: Send a data acquisition request to the target communication node to obtain the blockchain data fed back by the target communication node in response to the data acquisition request.

[0083] The local blockchain node will send a data acquisition request to the determined target communication node. The target communication node will feedback the blockchain data required for data synchronization to the local blockchain node in response to the data acquisition request. When there are multiple target communication nodes, the local blockchain node will send a data acquisition request to each target communication node, and continue to perform subsequent operations after receiving the blockchain data feedback from any target communication node.

[0084] When sending a data acquisition request, the blockchain node will start a timer. If a response message to the data acquisition request from the target communication node is received within the preset response time, the local block data can be updated according to the blockchain data carried in the response message, thereby completing data synchronization with the target communication node. If a response message to the data acquisition request from the target communication node is not received within the preset response time, the local blockchain node will execute step S550.

[0085] Step S550: adding an acquisition failure entry to the node information of the target communication node.

[0086] In the case where data cannot be obtained from the target communication node, the local blockchain node will add a failed acquisition entry to the node information of the target communication node in the cached node information. The failed acquisition entry is a negative result. Therefore, when the target communication node is selected later, the negative result will reduce the node's score, thereby reducing the probability of being selected as the target communication node. In some optional embodiments, upon receiving a response message from the target communication node to the data acquisition request, the local blockchain node will add a successful acquisition entry to the node information of the target communication node in the cached node information. The successful acquisition entry is a positive result, thereby increasing the probability of the node being selected as the target communication node. By adding a failed acquisition entry to the node that failed to communicate, the score of the blockchain node can be adjusted according to the communication status of the blockchain node, so that the blockchain node selects a node with better communication conditions to obtain data, which is conducive to improving the success rate of data acquisition.

[0087] In an embodiment of the present application, a blockchain node first obtains node information of multiple blockchain nodes, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication result of the node, and the historical communication result is used to indicate whether the blockchain data is successfully obtained from the blockchain node. Subsequently, the blockchain node scores the multiple blockchain nodes according to the historical communication results to obtain the node scores of the multiple blockchain nodes, and then selects the target communication node that meets the target conditions from the multiple blockchain nodes according to the block height value of the multiple blockchains and the node score, and finally obtains the blockchain data from the target communication node to update the local data of a blockchain node in the blockchain system according to the obtained blockchain data. By scoring the nodes according to the behavior of the nodes and selecting the communication nodes according to the scoring results, the selection of the communication nodes can be dynamically selected according to the communication results between the nodes, avoiding the failure of obtaining data caused by the nodes with unstable communication or the nodes that provide wrong data being repeatedly selected as the target nodes for obtaining data, saving processing resources and improving data acquisition efficiency.

[0088] In some optional embodiments, in the process of scoring based on the historical communication results of multiple blockchain nodes and obtaining the node scores of multiple blockchain nodes, for each blockchain node, the local blockchain node will obtain the specified record entry of the specified record type in the node information, and the specified record type includes at least one of the abnormal connection entry, the failed acquisition entry and the failed acquisition entry. The record type of the record entry is usually used to indicate the communication type involved in the entry. The abnormal connection entry, the failed acquisition entry and the failed acquisition entry are all entries associated with the communication connectivity of the blockchain node. Therefore, the communication connectivity of the target communication node obtained by scoring based on these specified types of entries is better. In some embodiments, the specified record type can also be a good consensus entry, which is usually determined according to the data or consensus results provided by the blockchain node during the consensus process of the blockchain node, that is, if a correct verification consensus vote is provided, a positive result is recorded, and if wrong malicious data is provided, a negative result is recorded. Finally, the local blockchain node deducts points from each blockchain node according to the number of specified record entries of each blockchain node to obtain the node scores of multiple blockchain nodes. Connection abnormal entries, acquisition failure entries, and acquisition failure entries are all negative results, so points will be deducted according to the number of negative results during the scoring process. By selecting specific types of record entries for scoring, the scoring process allows different scoring methods or rules to be used according to different needs, which is conducive to selecting target communication nodes that better meet actual needs and improving the flexibility of the data acquisition process.

[0089] In some optional embodiments, after sending a data acquisition request to the target communication node, the local blockchain node receives the blockchain data fed back by the target communication node in response to the data acquisition request, and then verifies the blockchain data according to the local data of the blockchain. If the data verification passes, the local data of the blockchain is updated according to the blockchain data; if the data verification fails, a verification failure entry is added to the node information of the target communication node. By adding a record entry of verification failure, the score of the blockchain node can be adjusted according to the data accuracy of the blockchain node, so that the blockchain node selects a node with better data status to obtain data, which is conducive to improving the accuracy of the acquired data.

[0090] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown in the figure are as follows Figure 6 As shown, in a blockchain data acquisition method of an embodiment of the present application, the blockchain data acquisition method may include the following steps:

[0091] Step S610, sending a height value acquisition request to multiple blockchain nodes.

[0092] Step S620, receiving block height values ​​fed back by multiple blockchain nodes in response to the height value acquisition request.

[0093] Step S630, updating the node information of the multiple blockchain nodes according to the block height values ​​from the multiple blockchain nodes.

[0094] Before the local blockchain node synchronizes data, it maintains the node information of other nodes in the blockchain. To this end, the local blockchain node needs to periodically obtain the block height values ​​of other nodes to determine which blockchain nodes have the latest blockchain data. Therefore, the local blockchain node sends a height value acquisition request to multiple blockchain nodes of the blockchain. After receiving the height value acquisition request, other nodes send their current block height values ​​to the local blockchain node. The local blockchain node establishes corresponding node information for each blockchain node that feedbacks the block height value in the local cache, and updates the block height value in the corresponding node confidence in the local cache according to the received block height value. By obtaining the block height information from other nodes in advance and saving it in the node information, the height information of other blockchain nodes can be obtained more quickly when selecting the node to obtain data, which is conducive to improving data acquisition efficiency.

[0095] Step S640, obtaining node information of multiple blockchain nodes in the blockchain system, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication results of the node, and the historical communication results are used to indicate whether the blockchain data is successfully obtained from the blockchain node.

[0096] Optionally, the implementation details of step S640 are the same as Figure 4 The step S410 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0097] Step S650: Scoring the multiple blockchain nodes according to their historical communication results to obtain node scores for the multiple blockchain nodes.

[0098] Optionally, the implementation details of step S650 are the same as Figure 4 The step S420 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0099] Step S660: Select a target communication node that meets the target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores.

[0100] Optionally, the implementation details of step S660 are the same as Figure 4 The step S430 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0101] Step S670, obtaining blockchain data from the target communication node to update local data of a blockchain node in the blockchain system according to the obtained blockchain data.

[0102] Optionally, the implementation details of step S670 are the same as Figure 4 The step S440 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0103] In an embodiment of the present application, a blockchain node first obtains node information of multiple blockchain nodes, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication result of the node, and the historical communication result is used to indicate whether the blockchain data is successfully obtained from the blockchain node. Subsequently, the blockchain node scores the multiple blockchain nodes according to the historical communication results to obtain the node scores of the multiple blockchain nodes, and then selects the target communication node that meets the target conditions from the multiple blockchain nodes according to the block height value of the multiple blockchains and the node score, and finally obtains the blockchain data from the target communication node to update the local data of a blockchain node in the blockchain system according to the obtained blockchain data. By scoring the nodes according to the behavior of the nodes and selecting the communication nodes according to the scoring results, the selection of the communication nodes can be dynamically selected according to the communication results between the nodes, avoiding the failure of obtaining data caused by the nodes with unstable communication or the nodes that provide wrong data being repeatedly selected as the target nodes for obtaining data, saving processing resources and improving data acquisition efficiency.

[0104] In some optional embodiments, in the process of scoring based on the historical communication results of multiple blockchain nodes and obtaining the node scores of multiple blockchain nodes, for each blockchain node, the local blockchain node will obtain the specified record entry of the specified record type in the node information, and the specified record type includes at least one of the abnormal connection entry, the failed acquisition entry and the failed acquisition entry. The record type of the record entry is usually used to indicate the communication type involved in the entry. The abnormal connection entry, the failed acquisition entry and the failed acquisition entry are all entries associated with the communication connectivity of the blockchain node. Therefore, the communication connectivity of the target communication node obtained by scoring based on these specified types of entries is better. In some embodiments, the specified record type can also be a good consensus entry, which is usually determined according to the data or consensus results provided by the blockchain node during the consensus process of the blockchain node, that is, if a correct verification consensus vote is provided, a positive result is recorded, and if wrong malicious data is provided, a negative result is recorded. Finally, the local blockchain node deducts points from each blockchain node according to the number of specified record entries of each blockchain node to obtain the node scores of multiple blockchain nodes. Connection abnormal entries, acquisition failure entries, and acquisition failure entries are all negative results, so points will be deducted according to the number of negative results during the scoring process. By selecting specific types of record entries for scoring, the scoring process allows different scoring methods or rules to be used according to different needs, which is conducive to selecting target communication nodes that better meet actual needs and improving the flexibility of the data acquisition process.

[0105] In some optional embodiments, after sending a height value acquisition request to multiple blockchain nodes, if no blockchain node responds to the height value acquisition request within a response period, the local blockchain node adds a connection abnormality entry to the node information of the unresponsive blockchain node. By adding a connection abnormality entry when the block height value acquisition fails, the communication status of the blockchain node can be further scored, which is conducive to improving the communication success rate when acquiring data.

[0106] In some optional embodiments, after adding a connection abnormality record to the node information of the unresponsive blockchain node, the local blockchain node will count the number of connection abnormality entries in the node information of the unresponsive blockchain node. If the number of connection abnormality entries exceeds the threshold value of the number of abnormal connections, the unresponsive blockchain node is marked as offline to stop data communication with the unresponsive blockchain node. After marking the unresponsive blockchain node as offline, when receiving a communication message from the unresponsive blockchain node, the local blockchain node will mark the unresponsive blockchain node as online to resume data communication with the unresponsive blockchain node.

[0107] In the embodiments of the present application, it is also proposed to Figure 4 In another embodiment, the technical solution of the embodiment shown is refined. In this embodiment, each record entry in the node information includes the local block height when the entry is generated. Figure 7 As shown, in a blockchain data acquisition method of an embodiment of the present application, the blockchain data acquisition method may include the following steps:

[0108] Step S710, obtaining node information of multiple blockchain nodes in the blockchain system, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication results of the node, and the historical communication results are used to indicate whether the blockchain data is successfully obtained from the blockchain node.

[0109] Optionally, the implementation details of step S710 are the same as Figure 4 The step S410 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0110] Step S720, comparing the local block height of each record entry in the node information of the multiple blockchain nodes with the current block height of the local blockchain node to obtain a comparison result;

[0111] Step S730: for multiple blockchain nodes, according to the comparison result, obtain the record entry in which the height difference between the local block height and the current block height is less than the height difference threshold, and obtain the score record entry of each blockchain node;

[0112] Step S740, scoring is performed according to the scoring record entries of each blockchain node to obtain node scores of multiple blockchain nodes, and the node scores are negatively correlated with the number of negative results of the historical communication results in the node information.

[0113] In some optional embodiments, the local blockchain node will not include records with low current association in the scoring process. Specifically, each record entry in the node information contains the local block height when the entry is generated, that is, when the local blockchain node generates the record entry in the node information, it will also record the block height of the local blockchain node at that moment in the record entry. The block height is used to measure the degree of association or time span between the moment when the record occurs and the current moment. This is because the frequency of transactions and the generation of new blocks in the blockchain is not necessarily balanced, so it is not necessarily accurate to determine the degree of association between two intervals according to the time interval. For multiple blockchain nodes, if the height difference between the local block height and the current block height in the comparison result is less than the height difference threshold, it means that there may be an association between the blockchain data to be obtained and that record entry, so the record entry will be added to the scoring record entry. The scoring record entry is an entry used to score the blockchain node. The local blockchain node will score according to the scoring record entry of each blockchain node respectively to obtain the node scores of multiple blockchain nodes. For example, a blockchain node has 100 corresponding entries in the node information. After comparing the block height when each entry is recorded and the current block height of the local blockchain node, 60 of them are obtained as scoring record entries, because the height difference between the local block height of these 60 record entries and the current block height of the local blockchain node is less than 50 blocks, while the other 40 records are greater than 50 blocks. Finally, the local blockchain node scores the blockchain node based on these 60 scoring record entries to determine the node score of the blockchain node. Filtering record entries by block height can reduce the impact of low-correlation information on node scores, which is conducive to the accuracy of node selection.

[0114] Step S750: Select a target communication node that meets the target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores.

[0115] Optionally, the implementation details of step S750 are the same as Figure 4 The step S430 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0116] Step S760, obtaining blockchain data from the target communication node to update local data of a blockchain node in the blockchain system according to the obtained blockchain data.

[0117] Optionally, the implementation details of step S760 are the same as Figure 4 The step S440 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0118] In an embodiment of the present application, a blockchain node first obtains node information of multiple blockchain nodes, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication result of the node, and the historical communication result is used to indicate whether the blockchain data is successfully obtained from the blockchain node. Subsequently, the blockchain node scores the multiple blockchain nodes according to the historical communication results to obtain the node scores of the multiple blockchain nodes, and then selects the target communication node that meets the target conditions from the multiple blockchain nodes according to the block height value of the multiple blockchains and the node score, and finally obtains the blockchain data from the target communication node to update the local data of a blockchain node in the blockchain system according to the obtained blockchain data. By scoring the nodes according to the behavior of the nodes and selecting the communication nodes according to the scoring results, the selection of the communication nodes can be dynamically selected according to the communication results between the nodes, avoiding the failure of obtaining data caused by the nodes with unstable communication or the nodes that provide wrong data being repeatedly selected as the target nodes for obtaining data, saving processing resources and improving data acquisition efficiency.

[0119] In some optional embodiments, in the process of scoring based on the historical communication results of multiple blockchain nodes and obtaining the node scores of multiple blockchain nodes, for each blockchain node, the local blockchain node will obtain the specified record entry of the specified record type in the node information, and the specified record type includes at least one of the abnormal connection entry, the failed acquisition entry and the failed acquisition entry. The record type of the record entry is usually used to indicate the communication type involved in the entry. The abnormal connection entry, the failed acquisition entry and the failed acquisition entry are all entries associated with the communication connectivity of the blockchain node. Therefore, the communication connectivity of the target communication node obtained by scoring based on these specified types of entries is better. In some embodiments, the specified record type can also be a good consensus entry, which is usually determined according to the data or consensus results provided by the blockchain node during the consensus process of the blockchain node, that is, if a correct verification consensus vote is provided, a positive result is recorded, and if wrong malicious data is provided, a negative result is recorded. Finally, the local blockchain node deducts points from each blockchain node according to the number of specified record entries of each blockchain node to obtain the node scores of multiple blockchain nodes. Connection abnormal entries, acquisition failure entries, and acquisition failure entries are all negative results, so points will be deducted according to the number of negative results during the scoring process. By selecting specific types of record entries for scoring, the scoring process allows different scoring methods or rules to be used according to different needs, which is conducive to selecting target communication nodes that better meet actual needs and improving the flexibility of the data acquisition process.

[0120] In some optional embodiments, after a blockchain node compares the local block height of each record entry in the node information of multiple blockchain nodes with the current block height of the local blockchain node and obtains a comparison result, if the comparison result indicates that the height difference between the local block height of any record entry and the current block height exceeds an expired height threshold, the record entry is deleted from the node information. This deletion can be performed periodically or during the process of scoring nodes. For record entries whose height difference exceeds the expired height threshold, the local blockchain node directly deletes these record entries from the node information, thereby reducing the storage resource occupation of the node information and reducing the impact of useless data on the scoring process. Specifically, please refer to Figure 8 , Figure 8 The schematic flow chart of deleting a record entry in an embodiment of the present application. When scoring a node, the local node first traverses the records of each type in the node information. In the process of traversing the records, the local node determines whether the height generated by the record is far from the height of the current request. If it is far, the record is deleted, otherwise, the record is scored.

[0121] In the embodiments of the present application, it is also proposed to Figure 4 The technical solution of the embodiment shown in the figure is further refined in another embodiment, in which the node information of the blockchain node also includes the number of requests. Fig. 9 As shown, in a blockchain data acquisition method of an embodiment of the present application, the blockchain data acquisition method may include the following steps:

[0122] Step S910, obtaining node information of multiple blockchain nodes in the blockchain system, wherein the node information of the multiple blockchain nodes includes the local block height value of the node and the historical communication results of the node, and the historical communication results are used to indicate whether the blockchain data is successfully obtained from the blockchain node.

[0123] Optionally, the implementation details of step S910 are the same as Figure 4 The step S410 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0124] Step S920: Scoring the multiple blockchain nodes according to their historical communication results to obtain node scores for the multiple blockchain nodes.

[0125] Optionally, the implementation details of step S920 are the same as Figure 4 The step S420 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0126] Step S930: According to the block height values ​​and node scores of multiple blockchain nodes, a blockchain node with the highest block height and a node score greater than a score threshold is selected as a candidate node.

[0127] Step S940: determine the candidate node with the least number of requests as the target communication node, and increment the number of requests in the node information of the target communication node.

[0128] In some optional embodiments, the node information of the blockchain node also includes the number of requests. The number of requests indicates the number of times the blockchain node is requested to provide blockchain data. The local blockchain node will select a blockchain node with a smaller number of requests as the target communication node. Specifically, the local blockchain node first selects the blockchain node with the highest block height and a node score greater than the score threshold as a candidate node based on the block height values ​​and node scores of multiple blockchain nodes. Then, among the selected candidate nodes, the candidate node with the least number of requests is determined as the target communication node, and the number of requests in the node information of the determined target communication node is incremented. By recording the number of requests of multiple blockchain nodes, it is possible to select a node with fewer requests as the target communication node, thereby avoiding a single node from being subjected to too many data requests and reducing the pressure on node data communication.

[0129] Step S950, obtaining blockchain data from the target communication node to update local data of a blockchain node in the blockchain system according to the obtained blockchain data.

[0130] Optionally, the implementation details of step S950 are the same as Figure 4 The step S440 shown in FIG. 1 is the same as that in FIG. 1 and will not be described in detail.

[0131] In an embodiment of the present application, a blockchain node first obtains node information of multiple blockchain nodes, wherein the node information of the multiple blockchain nodes includes the block height value and node information of the blockchain node, wherein the node information includes the historical communication result of obtaining blockchain data from the blockchain node, and then the blockchain node scores the multiple blockchain nodes according to the historical communication results, and obtains the node scores of the multiple blockchain nodes, and the node scores are negatively correlated with the number of negative results of the historical communication results, and then selects the target communication node that meets the target condition from the multiple blockchain nodes according to the block height value and the node score of the multiple blockchains, and finally obtains the blockchain data of the target communication node from the target communication node to update the local data of the blockchain according to the blockchain data. By scoring the nodes according to the behavior of the nodes and selecting the communication nodes according to the scoring results, the selection of the communication nodes can be dynamically selected according to the communication results between the nodes, avoiding the failure of obtaining data caused by the nodes with unstable communication or the nodes that provide wrong data being repeatedly selected as the target nodes for obtaining data, saving processing resources and improving data acquisition efficiency.

[0132] In some optional embodiments, in the process of scoring based on the historical communication results of multiple blockchain nodes and obtaining the node scores of multiple blockchain nodes, for each blockchain node, the local blockchain node will obtain the specified record entry of the specified record type in the node information, and the specified record type includes at least one of the abnormal connection entry, the failed acquisition entry and the failed acquisition entry. The record type of the record entry is usually used to indicate the communication type involved in the entry. The abnormal connection entry, the failed acquisition entry and the failed acquisition entry are all entries associated with the communication connectivity of the blockchain node. Therefore, the communication connectivity of the target communication node obtained by scoring based on these specified types of entries is better. In some embodiments, the specified record type can also be a good consensus entry, which is usually determined according to the data or consensus results provided by the blockchain node during the consensus process of the blockchain node, that is, if a correct verification consensus vote is provided, a positive result is recorded, and if wrong malicious data is provided, a negative result is recorded. Finally, the local blockchain node deducts points from each blockchain node according to the number of specified record entries of each blockchain node to obtain the node scores of multiple blockchain nodes. Connection abnormal entries, acquisition failure entries, and acquisition failure entries are all negative results, so points will be deducted according to the number of negative results during the scoring process. By selecting specific types of record entries for scoring, the scoring process allows different scoring methods or rules to be used according to different needs, which is conducive to selecting target communication nodes that better meet actual needs and improving the flexibility of the data acquisition process.

[0133] In some optional embodiments, after increasing the number of requests in the node information of the target communication node, the local blockchain node decreases the number of requests in the node information of the target communication node when receiving the blockchain data of the target communication node or when not receiving the blockchain data of the target communication node within a predetermined time period. By decreasing the number of requests in the node information of the target communication node when it is determined that data has been received or when it is determined that data has not been received, the number of requests of the target communication node can represent the number of communications currently requesting to obtain data from the target communication node, thereby reducing the real-time communication pressure of the node, making the communication load of the node more balanced, and facilitating data transmission efficiency. Please refer to Fig.10 , Fig.10This is a flow chart for determining the target communication node based on the number of requests in an embodiment of the present application. When scoring the nodes, for the blockchain node with the highest block height, the local blockchain node will select multiple nodes with higher node score values, and then traverse the selected nodes. During the traversal process, according to the number of requests being requested corresponding to the node, the node with the least number of requests is selected as the target communication node. Subsequently, a request is sent to the target communication node, and the number of requests corresponding to the target communication node is increased by 1. Subsequently, when a response is received from the target communication node, or when a timeout occurs and no response is received, the number of requests corresponding to the target communication node is reduced by 1, thereby maintaining the number of requests for data requested from the target communication node.

[0134] Combine the following Fig.11 An overall description of the blockchain data acquisition process of this application is given. Fig.11 This is a schematic flow chart of the overall process of obtaining blockchain data in the embodiment of this application. Fig.11 As shown, when the node starts, the synchronization node broadcasts to obtain the block height information of other nodes, adds or updates the obtained node information to the node cache, and if the information data of the cached node is not received within the time period, a connection abnormality record is made for this node. If it is not received for multiple consecutive times, the secondary node is marked as offline. When selecting nodes from the cache, all nodes are traversed and the nodes are scored. If the node has a negative record, the score is reduced once, and the node score with more negative records will be lower. The less likely it will be selected. Different scoring methods can be used for nodes according to needs, such as comprehensive scoring of all types of records, or scoring of one or several types, such as selecting nodes with better connectivity, selecting good nodes, etc. Send a data request to the selected node for processing. If the data response of the node is not received, a data acquisition failure record is made for this node. After obtaining the data, the data is verified. If the verification fails, a data verification failure record is made for the node sending the data. For the node scoring mechanism, different scoring strategies can be adopted for different categories of records. For example, a record is made for nodes that fail verification. When scoring at a certain moment, the height of the current local ledger is compared with the height of this record. If the height distance is too far, this record will not be used as a scoring record. In this way, nodes that occasionally have problems can be reactivated.

[0135] It should be noted that although the steps of the method in the present application are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all the steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps, etc.

[0136] The following introduces the device implementation of the present application, which can be used to execute the blockchain data acquisition method in the above embodiments of the present application. Fig.12 The block diagram of the block chain data acquisition device in the embodiment of the present application is schematically shown. Fig.12 As shown, the blockchain data acquisition device 1200 may mainly include:

[0137] The information acquisition module 1210 is configured to acquire node information of multiple blockchain nodes in the blockchain system, wherein the node information of the multiple blockchain nodes includes a local block height value of the node and a historical communication result of the node, wherein the historical communication result is used to indicate whether the blockchain data is successfully acquired from the blockchain node;

[0138] A scoring module 1220 is configured to score the multiple blockchain nodes according to the historical communication results of the multiple blockchain nodes to obtain node scores of the multiple blockchain nodes;

[0139] The node selection module 1230 is configured to select a target communication node that meets a target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores;

[0140] The data acquisition module 1240 is configured to acquire blockchain data from the target communication node to update the local data of a blockchain node in the blockchain system according to the acquired blockchain data.

[0141] In some embodiments of the present application, based on the above technical solution, the data acquisition module 1240 is configured to: send a data acquisition request to the target communication node to obtain the blockchain data that the target communication node feedbacks in response to the data acquisition request; if a response message of the target communication node to the data acquisition request is not received within a preset response time, then an acquisition failure entry is added to the node information of the target communication node.

[0142] In some embodiments of the present application, based on the above technical solution, the data acquisition module 1240 is also configured to: receive the blockchain data fed back by the target communication node in response to the data acquisition request; perform data verification on the blockchain data according to the local data of the blockchain; if the data verification passes, update the local data of the blockchain according to the blockchain data; if the data verification fails, add a verification failure entry to the node information of the target communication node.

[0143] In some embodiments of the present application, based on the above technical solution, the information acquisition module 1210: sends a height value acquisition request to multiple blockchain nodes; receives block height values ​​fed back by multiple blockchain nodes in response to the height value acquisition request; and updates the node information of the multiple blockchain nodes according to the block height values ​​from the multiple blockchain nodes.

[0144] In some embodiments of the present application, based on the above technical solution, the information acquisition module 1210: if no blockchain node responds to the height value acquisition request within the response period, a connection exception entry is added to the node information of the non-responding blockchain node.

[0145] In some embodiments of the present application, based on the above technical solution, the information acquisition module 1210: counts the number of connection abnormality entries in the node information of the unresponsive blockchain node; if the number of connection abnormality entries exceeds the abnormal connection number threshold, the unresponsive blockchain node is marked as offline to stop data communication with the unresponsive blockchain node; after marking the unresponsive blockchain node as offline, when a communication message is received from the unresponsive blockchain node, the unresponsive blockchain node is marked as online to resume data communication with the unresponsive blockchain node.

[0146] In some embodiments of the present application, based on the above technical solution, each record entry in the node information includes the local block height when the entry is generated; the scoring module 1220 is specifically configured to: compare the local block height of each record entry in the node information of multiple blockchain nodes with the current block height of the local blockchain node to obtain a comparison result; for multiple blockchain nodes, according to the comparison result, obtain a record entry in which the height difference between the local block height and the current block height is less than a height difference threshold, and obtain a scoring record entry for each blockchain node; score each blockchain node according to the scoring record entry to obtain node scores for multiple blockchain nodes.

[0147] In some embodiments of the present application, based on the above technical solution, the scoring module 1220 is also configured to: compare the local block height of each record entry in the node information of the multiple blockchain nodes with the current block height of the local blockchain node to obtain a comparison result; if the comparison result indicates that the height difference between the local block height of any record entry and the current block height exceeds the expired height threshold, then delete the record entry from the node information.

[0148] In some embodiments of the present application, based on the above technical solution, the node information of the blockchain node also includes the number of requests; the node selection module 1230 is specifically configured as follows: according to the block height values ​​and node scores of multiple blockchain nodes, the blockchain node with the highest block height and a node score greater than the score threshold is selected as a candidate node; the candidate node with the least number of requests is determined as the target communication node, and the number of requests in the node information of the target communication node is incremented.

[0149] In some embodiments of the present application, based on the above technical solution, the node selection module 1230 is also configured to: when the blockchain data of the target communication node is received or the blockchain data of the target communication node is not received within a predetermined time period, the number of requests in the node information of the target communication node is decremented.

[0150] In some embodiments of the present application, based on the above technical solution, the scoring module 1220 is specifically configured as follows: for each blockchain node, obtaining a specified record entry of a specified record type in the node information, wherein the specified record type includes at least one of a connection abnormality entry, an acquisition failure entry, and an acquisition failure entry; deducting points from each blockchain node according to the number of the specified record entries of each blockchain node, and obtaining node scores of multiple blockchain nodes.

[0151] It should be noted that the apparatus provided in the above embodiment and the method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module performs the operation has been described in detail in the method embodiment and will not be repeated here.

[0152] Fig.13 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0153] It should be noted that Fig.13 The computer system 1300 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0154] like Fig.13As shown, the computer system 1300 includes a central processing unit (CPU) 1301, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1302 or the program loaded from the storage part 1308 to the random access memory (RAM) 1303. Various programs and data required for system operation are also stored in the RAM 1303. The CPU 1301, the ROM 1302, and the RAM 1303 are connected to each other through a bus 1304. An input / output (I / O) interface 1305 is also connected to the bus 1304.

[0155] The following components are connected to the I / O interface 1305: an input section 1306 including a keyboard, a mouse, etc.; an output section 1307 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the I / O interface 1305 as needed. A removable medium 1311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1310 as needed so that a computer program read therefrom is installed into the storage section 1308 as needed.

[0156] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program includes a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication part 1309, and / or installed from a removable medium 1311. When the computer program is executed by a central processing unit (CPU) 1301, various functions defined in the system of the present application are executed.

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

[0158] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the above-mentioned module, program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0159] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0160] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation method of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the implementation method of the present application.

[0161] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary technical means in the art that are not disclosed in the present application.

[0162] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A blockchain data acquisition method, characterized in that: include: Obtain node information of multiple blockchain nodes in a blockchain system, wherein the node information of the multiple blockchain nodes includes a local block height value of the node and a historical communication result of the node, wherein the historical communication result is used to indicate whether blockchain data is successfully obtained from the blockchain node; Scoring the multiple blockchain nodes according to historical communication results to obtain node scores of the multiple blockchain nodes; Selecting a target communication node that meets a target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores; Obtain blockchain data from the target communication node to update local data of a blockchain node in the blockchain system according to the acquired blockchain data.

2. The blockchain data acquisition method according to claim 1, characterized in that: The obtaining blockchain data from the target communication node includes: Sending a data acquisition request to the target communication node to obtain blockchain data fed back by the target communication node in response to the data acquisition request; If a response message of the target communication node to the data acquisition request is not received within a preset response time, an acquisition failure entry is added to the node information of the target communication node.

3. The blockchain data acquisition method according to claim 2, characterized in that: After sending the data acquisition request to the target communication node, the method further includes: Receiving blockchain data fed back by the target communication node in response to the data acquisition request; Performing data verification on the blockchain data according to the local data of the blockchain; If the data verification is successful, the local data of the blockchain is updated according to the blockchain data; If the data verification fails, a verification failure entry is added to the node information of the target communication node.

4. The blockchain data acquisition method according to claim 1, characterized in that: Before obtaining the node information of multiple blockchain nodes in the blockchain system, the method further includes: Sending a height value acquisition request to the multiple blockchain nodes; Receiving block height values ​​fed back by the plurality of blockchain nodes in response to the height value acquisition request; Update node information of the multiple blockchain nodes according to block height values ​​from the multiple blockchain nodes.

5. The blockchain data acquisition method according to claim 4 is characterized in that: After sending the height value acquisition request to the multiple blockchain nodes, the method further includes: If no blockchain node responds to the height value acquisition request within the response period, a connection exception entry is added to the node information of the unresponsive blockchain node.

6. The blockchain data acquisition method according to claim 5, characterized in that: After adding a connection abnormality entry to the node information of the unresponsive blockchain node, the method further includes: Count the number of abnormal connection entries in the node information of unresponsive blockchain nodes; If the number of abnormal connection entries exceeds the abnormal connection number threshold, the unresponsive blockchain node is marked as offline to stop data communication with the unresponsive blockchain node; After marking the unresponsive blockchain node as being in an offline state, when a communication message is received from the unresponsive blockchain node, the unresponsive blockchain node is marked as being in an online state to resume data communication with the unresponsive blockchain node.

7. The blockchain data acquisition method according to claim 1, characterized in that: Each record entry in the node information includes the local block height when the entry is generated; The scoring according to the historical communication results of the multiple blockchain nodes to obtain the node scores of the multiple blockchain nodes includes: Comparing the local block height of each record entry in the node information of the multiple blockchain nodes with the current block height of the local blockchain node to obtain a comparison result; For the multiple blockchain nodes, according to the comparison result, obtain the record entries in which the height difference between the local block height and the current block height is less than the height difference threshold, and obtain the scoring record entry of each blockchain node; Scoring is performed according to the scoring record entries of each blockchain node respectively to obtain node scores of the multiple blockchain nodes.

8. The blockchain data acquisition method according to claim 1, characterized in that: The method further comprises: Comparing the local block height of each record entry in the node information of the multiple blockchain nodes with the current block height of the local blockchain node to obtain a comparison result; If the comparison result indicates that the height difference between the local block height of any record entry and the current block height exceeds the expired height threshold, the record entry is deleted from the node information.

9. The blockchain data acquisition method according to claim 1, characterized in that: The node information of the blockchain node also includes the number of requests; the step of selecting a target communication node that meets the target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores includes: According to the block height values ​​and node scores of the multiple blockchain nodes, a blockchain node with the highest block height and a node score greater than a score threshold is selected as a candidate node; The candidate node with the least number of requests is determined as the target communication node, and the number of requests in the node information of the target communication node is incremented.

10. The blockchain data acquisition method according to claim 9, characterized in that: After the number of requests in the node information of the target communication node is incremented, the method further comprises: When the blockchain data of the target communication node is received or the blockchain data of the target communication node is not received within a predetermined time period, the number of requests in the node information of the target communication node is decremented.

11. The blockchain data acquisition method according to claim 1, characterized in that: The scoring according to the historical communication results of the multiple blockchain nodes to obtain the node scores of the multiple blockchain nodes includes: For each blockchain node, obtaining a specified record entry of a specified record type in the node information, wherein the specified record type includes at least one of a connection abnormality entry, an acquisition failure entry, and an acquisition failure entry; Points are deducted from each blockchain node according to the number of designated record entries of each blockchain node to obtain node scores of the multiple blockchain nodes.

12. A blockchain data acquisition device, characterized in that: include: An information acquisition module is configured to acquire node information of multiple blockchain nodes in a blockchain system, wherein the node information of the multiple blockchain nodes includes a local block height value of the node and a historical communication result of the node, wherein the historical communication result is used to indicate whether the blockchain data is successfully acquired from the blockchain node; A scoring module is configured to score the multiple blockchain nodes according to the historical communication results of the multiple blockchain nodes to obtain node scores of the multiple blockchain nodes; A node selection module, configured to select a target communication node that meets a target condition from the multiple blockchain nodes according to the block height values ​​of the multiple blockchains and the node scores; The data acquisition module is configured to acquire blockchain data from the target communication node to update the local data of a blockchain node in the blockchain system according to the acquired blockchain data.

13. An electronic device, characterized in that: include: processor; A memory, configured to store executable instructions of the processor; Wherein, the processor is configured to execute the blockchain data acquisition method described in any one of claims 1 to 11 by executing the executable instructions.

14. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the blockchain data acquisition method according to any one of claims 1 to 11 is implemented.

15. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads and executes the computer instructions from the computer-readable storage medium, so that the computer device executes the blockchain data acquisition method as described in any one of claims 1 to 11.

Images