Data update methods, apparatus, equipment and storage media

Abstract

This application relates to a data update method, apparatus, device, and storage medium, and pertains to the field of computer technology, for at least improving data consistency and real-time performance, thereby supporting real-time querying of all data on the blockchain. The data update method includes: acquiring blockchain data corresponding to the current period; the blockchain data includes data from each block within the current block range; the current block range represents the range of blocks from the target height to the current height of the blockchain in the current period; the length of the current period is less than the block production duration corresponding to the blockchain; when it is determined that there is inconsistency between the blockchain data stored in a preset cache and the blockchain data corresponding to the current period, updating the data of each block in the preset cache; when it is determined that there is no data for a block corresponding to the target height in a preset database, updating the data of the block corresponding to the target height in the preset database.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data updating method, apparatus, device, and storage medium. Background Technology

[0002] For blockchain systems deployed in sectors such as finance and postal services, it is typically necessary to support off-chain query services for data on the blockchain to meet business needs. Off-chain query services require both data consistency and high real-time performance.

[0003] Currently, the common practice is to synchronize data from the blockchain to a database using a T+1 approach, and then support off-chain queries based on the database. While this method can achieve data consistency, the synchronization latency is high, making it difficult to support real-time data queries. Summary of the Invention

[0004] This application provides a data update method, apparatus, device, and storage medium to at least improve data consistency and enhance data real-time performance, thereby supporting real-time querying of the full dataset on the blockchain. The technical solution of this application is as follows:

[0005] According to a first aspect of the embodiments of this application, a data update method is provided, comprising: acquiring blockchain data corresponding to the current period; the blockchain data including data of each block in the blockchain within the current block range; the current block range being used to characterize the block range from the target height to the current height of the blockchain in the current period; the difference between the target height and the current height being greater than or equal to a preset value; the preset value being used to characterize the number of subsequent blocks corresponding to the confirmation of a block in the blockchain; the length of the current period being less than the block production time corresponding to the blockchain; when it is determined that there is inconsistent data between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period, updating the data of each block in the preset cache; when it is determined that there is no data of a block corresponding to the target height in the preset database, updating the data of the block corresponding to the target height in the preset database.

[0006] In one optional implementation, the data update method further includes: responding to a data query request carrying a field to be queried sent by a requesting node, determining whether data corresponding to the field to be queried exists in a preset cache and a preset database; when it is determined that data corresponding to the field to be queried exists in the preset cache or the preset database, sending the data corresponding to the field to be queried to the requesting node; when it is determined that no data corresponding to the field to be queried exists in the preset cache or the preset database, sending a prompt message to the requesting node indicating that the query has failed.

[0007] In one optional implementation, the method for determining whether data corresponding to the field to be queried exists in the preset cache and the preset database specifically includes: matching data corresponding to the field to be queried in the preset cache, and determining that data corresponding to the field to be queried exists in the preset cache when a match is successful; or, when a match fails in the preset cache, matching data corresponding to the field to be queried in the preset database; when a match succeeds in the preset database, determining that data corresponding to the field to be queried exists in the preset database; and when a match fails in the preset database, determining that data corresponding to the field to be queried does not exist in the preset cache and the preset database.

[0008] In one optional implementation, the block data includes a block hash value; the method for determining whether the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period specifically includes: determining whether the height of the blockchain stored in the preset cache is consistent with the current height, and when the height of the blockchain is inconsistent with the current height, determining that the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period; or, when the height of the blockchain is consistent with the current height, determining whether the block hash values ​​of each block stored in the preset cache are consistent with the block hash values ​​of each block corresponding to the current period, and when the block hash value of any block stored in the preset cache is inconsistent with the block hash value of any block in the current period, determining that the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period.

[0009] In one optional implementation, the method for determining that there is no data corresponding to the target height in the preset database specifically includes: when it is determined that the storage state of the block corresponding to the target height in the preset cache is not updated, determining that there is no data corresponding to the target height in the preset database; or, when it is determined that there is no hash value of the block corresponding to the target height in the preset database, determining that there is no data corresponding to the target height in the preset database; or, when it is determined that the height of the blockchain stored in the preset database is different from the target height, determining that there is no data corresponding to the target height in the preset database.

[0010] In one optional implementation, after obtaining the blockchain data corresponding to the current period, the data update method further includes: when the blockchain data stored in the preset cache is consistent with the blockchain data corresponding to the current period, maintaining the blockchain data stored in the preset cache and waiting for the next period.

[0011] In one optional implementation, the block data also includes block header data and transaction data. The method for obtaining the blockchain data corresponding to the current period specifically includes: calling the current block hash retrieval service to obtain the hash value of the current block corresponding to the current height in the blockchain; calling the block retrieval service based on the hash value of the current block to obtain the block header data of the current block; parsing the block header data of the current block to obtain the current height and the transaction hash value corresponding to the current block, and determining the current block range based on the current height; calling the block hash retrieval service based on the current block range to obtain the hash values ​​of other blocks within the current block range, and calling the block retrieval service based on the hash values ​​of other blocks to obtain the block header data of other blocks; and calling the transaction data retrieval service based on the transaction hash value corresponding to the current block and the transaction hash values ​​corresponding to other blocks to obtain the transaction data corresponding to the current block and the transaction data corresponding to other blocks.

[0012] According to a second aspect of the embodiments of this application, a data updating apparatus is provided, including: an acquisition unit and an updating unit;

[0013] The acquisition unit is configured to acquire the blockchain data corresponding to the current period; the blockchain data includes the data of each block in the blockchain within the current block range; the current block range is used to characterize the block range from the target height to the current height of the blockchain in the current period; the difference between the target height and the current height is greater than or equal to a preset value; the preset value is used to characterize the number of subsequent blocks corresponding to the confirmation and effectiveness of a block in the blockchain; the length of the current period is less than the block production time corresponding to the blockchain;

[0014] The update unit is configured to update the data of each block in the preset cache when it is determined that there is a discrepancy between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period.

[0015] The update unit is also configured to update the data of the block corresponding to the target height in the preset database when it is determined that there is no data for the block corresponding to the target height in the preset database.

[0016] In one alternative implementation, the data update device further includes: a determining unit and a sending unit;

[0017] The determining unit is configured to execute a data query request sent by the requesting node, which carries the field to be queried, and determine whether there is data corresponding to the field to be queried in the preset cache and preset database;

[0018] The sending unit is configured to send the data corresponding to the field to be queried to the requesting node when it is determined that there is data corresponding to the field to be queried in the preset cache or preset database.

[0019] The sending unit is also configured to send a message indicating query failure to the requesting node when it is determined that there is no data in the preset cache and the preset database that corresponds to the field to be queried.

[0020] In one alternative implementation, the determining unit is specifically configured to perform: matching data corresponding to the field to be queried in a preset cache, and if a match is successful in the preset cache, determining that data corresponding to the field to be queried exists in the preset cache; or, if a match fails in the preset cache, matching data corresponding to the field to be queried in a preset database; if a match is successful in the preset database, determining that data corresponding to the field to be queried exists in the preset database; and if a match fails in the preset database, determining that no data corresponding to the field to be queried exists in the preset cache or the preset database.

[0021] In one optional implementation, the block data includes a block hash value; the update unit is specifically configured to perform: determining whether the height of the blockchain stored in the preset cache is consistent with the current height, and when the height of the blockchain is inconsistent with the current height, determining that the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period; or, when the height of the blockchain is consistent with the current height, determining whether the block hash values ​​of each block stored in the preset cache are consistent with the block hash values ​​of each block corresponding to the current period, and when the block hash value of any block stored in the preset cache is inconsistent with the block hash value of any block in the current period, determining that the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period.

[0022] In one optional implementation, the update unit is specifically configured to perform the following: when it is determined that the storage state of the block corresponding to the target height in the preset cache is not updated, determine that there is no data for the block corresponding to the target height in the preset database; or, when it is determined that there is no hash value for the block corresponding to the target height in the preset database, determine that there is no data for the block corresponding to the target height in the preset database; or, when it is determined that the height of the blockchain stored in the preset database is different from the target height, determine that there is no data for the block corresponding to the target height in the preset database.

[0023] In one alternative implementation, the update unit is further configured to maintain the blockchain data stored in the preset cache and wait for the next cycle when the blockchain data stored in the preset cache is consistent with the blockchain data corresponding to the current cycle.

[0024] In one optional implementation, the block data also includes block header data and transaction data. The acquisition unit is specifically configured to perform the following actions: call the current block hash acquisition service to obtain the hash value of the current block corresponding to the current height in the blockchain; call the block acquisition service based on the hash value of the current block to obtain the block header data of the current block; parse the block header data of the current block to obtain the current height and the transaction hash value corresponding to the current block, and determine the current block range based on the current height; call the block hash acquisition service based on the current block range to obtain the hash values ​​of other blocks within the current block range, and call the block acquisition service based on the hash values ​​of other blocks to obtain the block header data of other blocks; and call the transaction data acquisition service based on the transaction hash value corresponding to the current block and the transaction hash values ​​corresponding to other blocks to obtain the transaction data corresponding to the current block and the transaction data corresponding to other blocks.

[0025] According to a third aspect of the embodiments of this application, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement any optional data update method as described in the first aspect.

[0026] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which instructions are stored, such that when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform any of the optional data update methods in the first aspect.

[0027] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by an electronic device, implements any of the optional data update methods in the first aspect.

[0028] The technical solution of the first aspect provided by the embodiments of this application brings at least the following beneficial effects: it can obtain blockchain data corresponding to the current period, including the data of each block in the current block range of the blockchain, and when it is determined that there is inconsistent data between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period, it can update the data of each block in the preset cache, so as to further update the data of the block corresponding to the target height in the preset database when it is determined that there is no data of the block corresponding to the target height in the preset database.

[0029] Since the current block range represents the range of blocks from the target height to the current height of the blockchain in the current period, and the difference between the target height and the current height is greater than or equal to a preset value (i.e., greater than or equal to the number of subsequent blocks corresponding to the confirmed block in the blockchain), and the length of the current period is less than the block generation time of the blockchain, this application can promptly obtain data from all unconfirmed blocks in the blockchain, as well as data from newly generated blocks.

[0030] Based on this, this application can promptly determine whether the data stored in the preset cache is consistent with the data on the blockchain, and if there is no consistency, it will obtain the data of all unconfirmed blocks in the blockchain, as well as the data of newly generated blocks, and update the preset cache. Compared with the T+1 data synchronization method, this application can shorten the synchronization time interval, improving the consistency between the data in the preset cache and the data on the blockchain, while also enhancing the real-time performance of the data in the preset cache.

[0031] Furthermore, based on the timely acquisition of newly generated blocks, this application can promptly confirm the blocks that can take effect, i.e., the blocks corresponding to the target height, and update the blocks corresponding to the target height in the preset database in a timely manner. This avoids data inconsistency caused by the deletion of data corresponding to the target height in the preset cache area, thereby improving data consistency. Therefore, this application can at least be used to improve data consistency and enhance data real-time performance, thereby supporting real-time querying of the full amount of data on the blockchain.

[0032] It should be noted that the technical effects of any of the implementation methods in aspects two through five can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

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

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0035] Figure 1 This is a schematic diagram illustrating an implementation architecture according to an embodiment of this application;

[0036] Figure 2 This is a flowchart illustrating a data update method according to an embodiment of this application;

[0037] Figure 3 This is a flowchart illustrating yet another data update method shown in the embodiments of this application;

[0038] Figure 4 This is a schematic diagram illustrating a data query process according to an embodiment of this application;

[0039] Figure 5 This is a schematic diagram illustrating a data update process according to an embodiment of this application;

[0040] Figure 6 This is a block diagram illustrating a data update device according to an embodiment of this application;

[0041] Figure 7 This is a block diagram illustrating an electronic device according to an embodiment of this application. Detailed Implementation

[0042] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0043] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0044] To facilitate understanding of this application, the relevant elements involved in this application are described below.

[0045] Blockchain technology

[0046] A blockchain is a chain-like structure that maintains blocks. It can be understood as a permanent and irreversible data record created by stacking encrypted data (i.e., blocks) in chronological order of their creation. This data record has characteristics such as continuous growth and shareability.

[0047] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices work together to "keep accounts" (i.e. record transaction data) and jointly maintain a complete distributed database.

[0048] Because of its decentralized (i.e., no central node), transparent, and multi-device-participatory database recording capabilities, blockchain technology has been widely applied in numerous fields, such as finance, postal services, and healthcare.

[0049] A blockchain system can include multiple blockchain nodes. A blockchain node is a device with communication and storage capabilities, such as a device storing the blockchain data. Each blockchain node can both receive and generate data. Different blockchain nodes maintain communication by maintaining a shared blockchain.

[0050] In this application's embodiments, the blockchain node can be understood as a processing unit. In one implementation, the blockchain node can be a physical device such as a server or terminal device. In another implementation, the blockchain node can be a virtual computer. A virtual computer is a general term for the software-virtualized runtime environment in all types of virtualization devices; this concept includes virtual machines and containers. In other implementations, the blockchain node can also be a process or a thread.

[0051] Block

[0052] In blockchain technology, transaction data is permanently stored in the form of electronic records, and the files that store these electronic records are called "blocks".

[0053] Blocks are generated sequentially in chronological order. Each block records all transactions that occurred during its creation period, and all blocks are aggregated to form a chain-like collection of records. Because the throughput of blockchain nodes varies across different blockchain systems, the block size may also differ.

[0054] As can be seen, a block records transaction data within the time period in which the block was generated; therefore, the main body of a block is actually a collection of transaction data. While the structural design of each blockchain may not be exactly the same, a block typically consists of two parts: a block header and a block body.

[0055] The block header is mainly used to record the characteristic values ​​of the current block. It can include at least one of the following: the identifier of the current block (such as the block number), the hash value of the block body in the current block, the timestamp (used to indicate the generation time of the block), the transaction count, and the nonce. In addition, the block header can also include the hash value of the previous block (specifically, the hash value of the block header in the previous block).

[0056] The block header includes multiple feature values. To determine the hash value of a block, these feature values ​​are concatenated in sequence to form a string, and then the hash value is calculated from this string. Since the feature values ​​in the block headers of different blocks are usually different, each block uniquely corresponds to a hash value.

[0057] Since each block uniquely corresponds to a hash value, and the block header of each block includes the hash value of the previous block, multiple blocks can form a blockchain.

[0058] A block body can include multiple transaction data. For each transaction data, the block body can include data such as the input blockchain address, the output blockchain address, and the number of digital tokens. The hash value of the block body can be multiple hash values ​​corresponding one-to-one with the multiple transaction data, that is, one hash value is recorded for each transaction data. Alternatively, the hash value of the block body can also be a single hash value corresponding to multiple transaction data, that is, one hash value is recorded for each of the multiple transaction data.

[0059] For example, Table 1 shows one structural form of a block. Of course, the structure of a block is not limited to that shown in Table 1, and the values ​​of each structure are not limited to those shown in Table 1.

[0060] Table 1

[0061]

[0062] Remote Procedure Call

[0063] Remote procedure call (RPC) is a method of inter-process communication that allows one application to call a method in another application over a network; it can also be understood as one application requesting a service from another application. These two applications can reside on the same physical device or on different physical devices. This application's embodiments primarily involve calls between different applications within a single blockchain node.

[0064] cache

[0065] A cache can be a fixed-capacity storage space in memory, which can be understood as a memory block or a segmented transmission area used to buffer input or output data. Compared to a database, a cache can provide faster data query services.

[0066] database

[0067] A database can be understood as a warehouse for storing data, used to store a series of organized data. This organized data, once stored in a database, typically remains unchanged. Compared to a cache, a database can provide a more stable, long-term storage service.

[0068] The following is a brief introduction to the application scenarios and implementation environment involved in this application.

[0069] For blockchain systems deployed in financial and delivery services, it is typically necessary to support off-chain query services for data on the blockchain to meet business needs. Queries generally require access to block header data and transaction data. Furthermore, off-chain query services demand both data consistency and high real-time performance. In some scenarios, the real-time requirement for block queries can be within one second or even one minute.

[0070] Currently, the common practice is to synchronize data from the blockchain to a database using a T+1 approach, and then support off-chain queries based on the database. While this method can achieve data consistency, the synchronization latency is high, making it difficult to support real-time data queries.

[0071] To address the aforementioned issues, this application provides a data update method that can acquire blockchain data corresponding to the current period, including data from each block within the current block range in the blockchain. Furthermore, when it is determined that there is inconsistency between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period, the data of each block is updated in the preset cache. Additionally, when it is determined that there is no data for a block corresponding to the target height in the preset database, the data of the block corresponding to the target height is updated in the preset database.

[0072] Since the current block range represents the range of blocks from the target height to the current height of the blockchain in the current period, and the difference between the target height and the current height is greater than or equal to a preset value (i.e., greater than or equal to the number of subsequent blocks corresponding to the confirmed block in the blockchain), and the length of the current period is less than the block generation time of the blockchain, this application can promptly obtain data from all unconfirmed blocks in the blockchain, as well as data from newly generated blocks.

[0073] Based on this, this application can promptly determine whether the data stored in the preset cache is consistent with the data on the blockchain, and if there is no consistency, it will obtain the data of all unconfirmed blocks in the blockchain, as well as the data of newly generated blocks, and update the preset cache. Compared with the T+1 data synchronization method, this application can shorten the synchronization time interval, improving the consistency between the data in the preset cache and the data on the blockchain, while also enhancing the real-time performance of the data in the preset cache.

[0074] Furthermore, based on the timely acquisition of newly generated blocks, this application can promptly confirm the blocks that can take effect, i.e., the blocks corresponding to the target height, and update the blocks corresponding to the target height in the preset database in a timely manner. This avoids data inconsistency caused by the deletion of data corresponding to the target height in the preset cache area, thereby improving data consistency. Therefore, this application can at least be used to improve data consistency and enhance data real-time performance, thereby supporting real-time querying of the full amount of data on the blockchain.

[0075] Figure 1 This is an implementation architecture diagram of this application. (For example...) Figure 1 As shown, the data update system 100 provided in this application embodiment may include multiple blockchain nodes 101 and request nodes 102. Request nodes 102 can communicate with any one of the blockchain nodes 101. Multiple blockchain nodes 101 can form a blockchain system, and different blockchain nodes 101 can communicate with each other.

[0076] In practical applications, the number of request nodes 102 can be one or more.

[0077] For ease of understanding, this application uses the communication connection between a blockchain node 101 and a request node 102 as an example.

[0078] Optional, Figure 1 The blockchain node 101 and request node 102 can be functional modules integrated into the same device, or they can be two independently configured devices. This application embodiment does not impose any restrictions on this.

[0079] It is easy to understand that when blockchain node 101 and request node 102 are functional modules integrated within the same device, the communication method between blockchain node 101 and request node 102 is the same as the communication method between modules within the device. In this case, the communication process between the two is the same as that between blockchain node 101 and request node 102 when they are set up independently.

[0080] For ease of understanding, this application mainly uses the example of blockchain node 101 and request node 102 being set up independently.

[0081] Optionally, if the blockchain node 101 and the request node 102 are set up independently, the request node 102 can be an independent device outside the blockchain system composed of multiple blockchain nodes 101. Alternatively, the request node 102 can also be a single blockchain node, which can form a blockchain system together with multiple blockchain nodes 101.

[0082] In one possible way, Figure 1Multiple blockchain nodes 101 can form a blockchain network, which can be used to provide data storage and data retrieval services for medical institutions and banking institutions. This blockchain network can be regarded as a peer-to-peer (P2P) network.

[0083] In one possible approach, multiple blockchain nodes 101 can store the same blockchain. This blockchain can include data from multiple blocks. For example, the blockchain can include, for instance,... Figure 1 The diagram shows multiple blocks, including initial block 0, block 1, block 2, and block 3.

[0084] Optionally, the blockchain can be a private blockchain, a consortium blockchain, or a public blockchain. A private blockchain refers to a blockchain with strict access control. A consortium blockchain, also known as a community blockchain, refers to a blockchain whose consensus process is controlled by pre-selected nodes. In a consortium blockchain, all or some functions are only open to the nodes storing the blockchain data; each node can customize read / write permissions, query permissions, etc., as needed. A public blockchain refers to a blockchain where any individual or group in the world can send transactions and participate in the consensus process.

[0085] In one possible configuration, blockchain node 101 can be configured with a specific memory space, a preset cache, and a preset database. The specific memory space can be used to store the blockchain. The preset cache can be used to store data of unconfirmed blocks retrieved from the blockchain, as well as data of partially confirmed blocks. The preset database can be used to store data of confirmed blocks.

[0086] In one possible approach, the specific memory space and / or preset cache area and / or preset database can be the memory space inside the blockchain node 101, or it can be the memory space on other devices located outside the blockchain node 101 and connected to the blockchain node 101. This application embodiment does not limit this.

[0087] In one possible approach, blockchain node 101 can be configured with services such as current block hash retrieval, block hash retrieval, block retrieval, transaction data retrieval, and transaction data decoding. For example, the current block hash retrieval service could be an RPC interface with current block hash retrieval functionality. Similarly, the block hash retrieval service could be an RPC interface with block hash retrieval functionality, the transaction data retrieval service could be an RPC interface with transaction data retrieval functionality, and the transaction data decoding service could be an RPC interface with transaction data decoding functionality.

[0088] An RPC interface that can retrieve the current block hash can also be called getbestblockhash. When called, it can return the hash value of the last block on the local blockchain at the current moment, that is, the hash value of the current block.

[0089] An RPC interface that can retrieve block hashes can also be called getblockhash. When called, it can return the hash value of the block corresponding to the specified block number or block height.

[0090] An RPC interface with block retrieval functionality can also be called getblock. When called, it can return the block header data corresponding to the specified block hash value.

[0091] An RPC interface with transaction data retrieval capabilities can also be called getrawtransaction. When called, it can return the original transaction field corresponding to the specified transaction hash value or a decoded JSON object (JavaScript objectnotation).

[0092] An RPC interface with transaction data decoding capabilities can also be called decoderawtransaction. When called, it can decode the specified raw transaction fields into a JSON object.

[0093] Optionally, Figure 1 The blockchain node 101 can be a terminal, a server, or other devices that support blockchain maintenance and other functions. Figure 1 This is merely an example of the device form of blockchain node 101 and does not constitute a limitation.

[0094] In one possible way, Figure 1 The request node 102 can be configured with functions such as data statistical processing, data fusion processing, and data parallel processing to provide data processing services. Specifically, the request node 102 can send a data query request to the blockchain node 101 based on identifier information such as block number, block hash value, transaction hash value, and blockchain address to obtain the corresponding blockchain data, and then process the obtained blockchain data according to the configured functions.

[0095] Optionally, Figure 1 The request node 102 can be a terminal, a server, or other devices used to provide data processing services. Figure 1 The above is merely an example of the device configuration of the requesting node 102 and does not constitute a limitation thereof.

[0096] Optionally, when blockchain node 101 and request node 102 are terminals, the terminal can be a mobile phone, tablet, desktop, laptop, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA) device. Furthermore, the terminal can interact with the user through one or more methods such as a keyboard, touchpad, touchscreen, remote control, voice interaction, or handwriting device. This application does not impose any special restrictions on the specific form of the terminal.

[0097] When blockchain node 101 and request node 102 are servers, the server can be a single server or a server cluster consisting of multiple servers. In some embodiments, the server cluster can also be a distributed cluster. This application does not limit the specific implementation of the server.

[0098] Combination Figure 1 This application provides a real-time blockchain query method based on fixed-period RPC interface calls for data updates, which can be divided into two parts. The first part concerns a method for establishing and maintaining blockchain data in a preset cache and a preset database. The second part concerns a method for querying blockchain data based on given block numbers, block hash values, and transaction hash values.

[0099] For ease of understanding, the data update method provided in this application will be described in detail below with reference to the accompanying drawings.

[0100] Figure 2 This is a flowchart illustrating a data update method according to an exemplary embodiment, the data update method being applied to... Figure 1 Blockchain node 101 in the example. Figure 2 As shown, the data update method includes: S201-S203.

[0101] S201, Blockchain nodes obtain the blockchain data corresponding to the current period.

[0102] The blockchain data can include data from all blocks within the current block range. Block data can include the block hash, block header data, and block body data. The block body data can include transaction data from multiple transactions. The current block range can be used to represent the range of blocks from the target height to the current height of the blockchain in the current period. The current block range can include the target height and the current height of the blockchain in the current period. The difference between the target height and the current height can be greater than or equal to a preset value. The preset value can be used to represent the number of subsequent blocks corresponding to the confirmation and effectiveness of a block in the blockchain.

[0103] It's important to note that to support off-chain queries of the full on-chain data, it's advisable to synchronize all data on the blockchain to off-chain storage. However, data in unconfirmed blocks on the blockchain may change, leading to inconsistencies between on-chain and off-chain data. Specifically, the blockchain can have a transaction confirmation process. This process typically involves confirming the transaction data and the block containing the transaction when the number of subsequent blocks corresponding to the block containing the transaction is greater than or equal to a specific value (i.e., a preset value). Blocks with a number of subsequent blocks less than the preset value are not confirmed. These unconfirmed blocks may be deleted, or the transaction data they contain may change.

[0104] Based on this, this application considers periodically retrieving multiple newly generated blocks from the blockchain, where the number is greater than or equal to a preset value, and the length of the polling period (e.g., the current period) can be less than the corresponding block generation time of the blockchain. In this case, it can be guaranteed that all unconfirmed and invalidated blocks can be retrieved in a timely manner. Specifically, the corresponding block generation time of the blockchain can be used to characterize the average time for generating a block in the blockchain. When the length of the polling period is less than the corresponding block generation time of the blockchain, it is possible to know in real time whether a new block has been generated in the blockchain, thereby enabling real-time synchronization of new block data. This improves the consistency between on-chain and off-chain data while supporting real-time querying of blockchain data.

[0105] It should be understood that for every block generated in a blockchain, one block can be confirmed as effective. Based on the latest generated blocks, it is also possible to confirm whether a new confirmed effective block exists, which can then be stored as permanently saved data in a pre-defined database. Furthermore, to promptly confirm whether a new block has been generated in the blockchain, the ratio between the block generation time and the polling cycle length can be an integer, thereby further improving the real-time performance of data queries.

[0106] For example, the block generation time for a blockchain could be 10 minutes. That is, the blockchain can generate a block every 10 minutes. The polling period could be 1 minute. That is, the blockchain is polled every 1 minute to see if a new block has been generated. The length of this polling period is less than the block generation time for the blockchain, and the ratio between the block generation time and the polling period is an integer of 10. In this case, the polling process can be matched with the blockchain's block generation process to support the real-time acquisition of newly generated blocks.

[0107] In one possible approach, blockchain nodes can be pre-configured with a daemon. This daemon can periodically poll the blockchain, that is, query the data on the blockchain at fixed time intervals.

[0108] In one possible approach, blockchain nodes can be pre-configured with fixed time intervals. When the interval between the current moment and the last time blockchain data was triggered is determined to be a fixed time interval, the current cycle begins, and blockchain data is acquired. When acquiring blockchain data, the blockchain node can directly obtain the entire dataset on the blockchain. After obtaining the entire dataset, the current height of the blockchain is determined, and a preset value is subtracted from the current height to obtain the target height. This allows the node to read data from each block within the current block range from the entire dataset.

[0109] It should be understood that when the height of the blockchain is less than the preset value, the full amount of data on the blockchain is the blockchain data for the current period.

[0110] In one possible approach, the height of the blockchain can be the block number corresponding to the block at that height, also known as the block identifier. For example, when the height of the blockchain is 10001, the block number corresponding to the block at that height could be 10001.

[0111] In one possible implementation, a blockchain node can also obtain the blockchain data corresponding to the current period by calling relevant services. For example... Figure 3 As shown, this method can be implemented in the following ways: S2011-S2015.

[0112] S2011, The blockchain node calls the current block hash retrieval service to obtain the hash value of the current block in the blockchain corresponding to the current height.

[0113] Optionally, the current block hash retrieval service can be an RPC interface with the function of retrieving the current block hash. An RPC interface with the function of retrieving the current block hash can also be called getbestblockhash, which, when called, can return the hash value of the last block on the local blockchain at the current moment, that is, the hash value of the current block.

[0114] S2012, The blockchain node calls the block retrieval service based on the hash value of the current block to obtain the block header data of the current block.

[0115] Optionally, the block retrieval service can be an RPC interface with block retrieval functionality. An RPC interface with block retrieval functionality can also be called `getblock`, and when called, it can return the block header data corresponding to the specified block hash value.

[0116] S2013. The blockchain node parses the block header data of the current block to obtain the current height and the transaction hash value corresponding to the current block, and determines the range of the current block based on the current height.

[0117] In one possible approach, when a blockchain node determines the current block range based on the current height, it can subtract a preset value from the current height to obtain the target height, and then define the range from the target height to the current height as the current block range.

[0118] S2014. The blockchain node calls the block hash retrieval service based on the current block range to obtain the hash values ​​of other blocks within the current block range, and calls the block retrieval service based on the hash values ​​of other blocks to obtain the block header data of other blocks.

[0119] Optionally, the block hash retrieval service can be an RPC interface with block hash retrieval functionality. An RPC interface with block hash retrieval functionality can also be called getblockhash, and when called, it can return the hash value of the block corresponding to a specified block number or block height.

[0120] S2015. Based on the transaction hash value corresponding to the current block and the transaction hash values ​​corresponding to other blocks, the blockchain node calls the transaction data acquisition service to obtain the transaction data corresponding to the current block and the transaction data corresponding to other blocks.

[0121] Optionally, the transaction data retrieval service can be an RPC interface with transaction data retrieval functionality. An RPC interface with transaction data retrieval functionality can also be called getrawtransaction, and when called, it can return the original transaction fields corresponding to the specified transaction hash value or a decoded JSON object (JavaScript object notation).

[0122] In one possible approach, when a blockchain node obtains the original transaction fields by calling the transaction data acquisition service, it can further call the transaction data decoding service to decode the original transaction fields and obtain the specific transaction data.

[0123] Optionally, the transaction data decoding service can be an RPC interface with transaction data decoding capabilities. An RPC interface with transaction data decoding capabilities can also be called decoderawtransaction, and when called, it can decode specified raw transaction fields into JSON objects.

[0124] S202. When a blockchain node determines that there is a discrepancy between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period, it updates the data of each block in the preset cache.

[0125] In one possible approach, a pre-configured cache can be configured within the blockchain node. This cache can be used to cache data retrieved from the blockchain by the blockchain node, and confirmed blocks stored in the cache can be synchronized to a pre-configured database. The blockchain node can store data in the cache in key-value pairs. Specifically, the cache can store the block hash value corresponding to the block number, the block header data corresponding to the block number, the transaction hash value corresponding to the block number, the block header data corresponding to the block hash value, and the transaction data corresponding to the transaction hash value.

[0126] In one possible approach, after a blockchain node obtains the blockchain data corresponding to the current period, it can read the blockchain data stored in a preset cache area and compare the blockchain data corresponding to the current period with the blockchain data stored in the preset cache area to determine whether there is any consistency between the blockchain data stored in the preset cache area and the blockchain data corresponding to the current period.

[0127] If a blockchain node determines that the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period, it indicates that the transaction data on the blockchain has changed. In this case, to ensure data consistency, the blockchain node can update the data of each block in the preset cache. Specifically, if the data of a block is not stored in the preset cache, the blockchain node can create the data for that block in the preset cache. If the data of a block is already stored in the preset cache, the blockchain node can replace the data of that block in the preset cache with the data obtained in the current period.

[0128] If a blockchain node determines that the blockchain data stored in the preset cache is consistent with the blockchain data corresponding to the current period, it indicates that the transaction data on the blockchain has not changed. In this case, the blockchain node can keep the blockchain data stored in the preset cache unchanged and wait for the next period.

[0129] In one possible embodiment, when a blockchain node compares the blockchain data corresponding to the current period with the blockchain data stored in a preset cache, it may compare the block hash values ​​of each block included in the blockchain data corresponding to the current period with the hash values ​​of each block stored in the preset cache.

[0130] In another possible embodiment, the blockchain node can also determine, based on the height of the blockchain and the block hash value of each block, that there is data inconsistency between the blockchain data stored in the preset cache area and the blockchain data corresponding to the current period, specifically including: S2021-S2022.

[0131] S2021. The blockchain node determines whether the height of the blockchain stored in the preset cache is consistent with the current height, and when the height of the blockchain is inconsistent with the current height, it determines that there is inconsistent data between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period.

[0132] In one possible approach, a blockchain node can determine the block number of the block whose generation time is closest to the current time among all blocks stored in a preset cache as the height of the blockchain stored in the preset cache, and then compare the current height of the blockchain with the height of the blockchain stored in the preset cache. If the two are inconsistent, it indicates that a new block has been generated. In this case, the blockchain node can determine that there is a data inconsistency between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period.

[0133] It should be noted that because comparing two values ​​yields results quickly, blockchain nodes can efficiently identify inconsistencies between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period, thereby improving the efficiency of data updates.

[0134] S2022. When the height of the blockchain is consistent with the current height, the blockchain node determines whether the block hash value of each block stored in the preset cache is consistent with the block hash value of each block corresponding to the current period. When the block hash value of any block stored in the preset cache is inconsistent with the block hash value of any block in the current period, it determines that there is inconsistent data between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period.

[0135] In one possible approach, if the current height of the blockchain matches the height of the blockchain stored in the preset cache, while this indicates that no new blocks have been generated, it doesn't determine whether any blocks have been replaced or whether the data within one or more blocks has changed. In this case, the blockchain can further determine whether the block hash values ​​of each block stored in the preset cache match the block hash values ​​of the blocks corresponding to the current period.

[0136] If the block hash value of any block stored in the preset cache is inconsistent with the block hash value of any block in the current period, it indicates that some unconfirmed blocks may have been replaced, and / or the data in one or more blocks may have changed. In this case, the blockchain node can determine that there is inconsistency between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period.

[0137] If the block hash values ​​of all blocks stored in the preset cache are consistent with the block hash values ​​of all blocks corresponding to the current period, it indicates that no blocks have been replaced and the data within each block has not changed. In this case, the blockchain node can determine that the data stored in the preset cache is consistent with the blockchain data corresponding to the current period.

[0138] It should be understood that the block hash value is generated based on the block header data. The block header data includes information such as the block number and generation timestamp, as well as transaction hash values ​​generated based on transaction data. Therefore, a change in any item of the block header data will cause a change in the block hash value. In other words, a change in the block hash value indicates that the block header data has changed.

[0139] S203. When a blockchain node determines that there is no data for a block corresponding to the target height in the preset database, it updates the data for the block corresponding to the target height in the preset database.

[0140] In one possible approach, blockchain nodes can be configured with a pre-defined database. Compared to a pre-defined cache, the pre-defined database can permanently store data, improving data consistency. Based on this, blockchain nodes can synchronize the data of confirmed and effective blocks to the pre-defined database as permanently stored data. This avoids data inconsistencies caused by the deletion of data from blocks corresponding to the target height in the pre-defined cache, thus improving data consistency and providing more stable support for querying blockchain data.

[0141] In one possible approach, the pre-defined database could be a relational database, used to store mappings between one or more keywords and transaction data. Keywords could be block numbers, block hashes, transaction hashes, and blockchain addresses, among others.

[0142] In one possible approach, if the difference between the target height and the current height of the blockchain equals a preset value, it indicates that the number of subsequent blocks corresponding to the block at the target height equals the preset value, and the blockchain node can then confirm that the block at the target height is valid. In this case, the blockchain node can determine whether data for a block corresponding to the target height exists in the preset database.

[0143] If the preset database does not contain data for a block corresponding to the target height, the blockchain node can update the data for the block corresponding to the target height in the preset database, that is, create the data for the block corresponding to the target height in the preset database.

[0144] If the preset database contains data for a block corresponding to the target height, the blockchain node can wait for the next cycle.

[0145] In one possible approach, if the difference between the target height and the current height of the blockchain is greater than a preset value, the blockchain node can determine the difference between the current height and the preset value, obtain a first height, and confirm that all blocks within the block range from the target height to the first height are valid. In this case, the blockchain node can determine whether data for each block within the block range from the target height to the first height exists in the preset database.

[0146] If the preset database does not contain data for one or more blocks within the range from the target height to the first height, the blockchain node can update the preset database with the data of those one or more blocks, that is, create the data for those one or more blocks in the preset database.

[0147] If the preset database contains data for all blocks within the range from the target height to the first height, the blockchain node can wait for the next cycle.

[0148] Optionally, when a blockchain node determines whether data for a block corresponding to the target height exists in the preset database, it can be achieved through methods including but not limited to the following two approaches. It should be understood that when a blockchain node determines whether data for each block within the block range from the target height to the first height exists in the preset database, it can also be achieved through methods similar to, but not limited to, the following two approaches, which will not be elaborated upon here.

[0149] In one possible approach, blockchain nodes can maintain a state identifier for each block within a pre-defined cache. This state identifier can indicate whether a block's storage state is either "not updated" or "updated." "Not updated" means it hasn't been updated to the pre-defined database. "Updated" means it has been updated to the pre-defined database. Based on this, blockchain nodes can read the state identifier of the block corresponding to the target height from the pre-defined cache.

[0150] If the status identifier of the block corresponding to the target height is used to indicate that the storage state of the block is not updated, then the blockchain node can determine that there is no data for the block corresponding to the target height in the preset database.

[0151] If the status identifier of the block corresponding to the target height is used to indicate that the storage status of the block is updated, then the blockchain node can determine that there is data in the preset database that corresponds to the target height.

[0152] In one possible approach, blockchain nodes can match the block hash value of the block corresponding to the target height in a pre-defined database.

[0153] If a block hash value corresponding to the target height is found in the preset database, it indicates that a block hash value corresponding to the target height exists in the preset database. In this case, the blockchain node can confirm that the preset database contains data for a block corresponding to the target height.

[0154] If no matching block hash value for the target height is found in the preset database, it indicates that the preset database does not contain a block hash value corresponding to the target height. In this case, the blockchain node can determine that the preset database does not contain data for a block corresponding to the target height.

[0155] In one possible approach, the blockchain node can determine whether the height of the blockchain stored in the preset database is the same as the target height.

[0156] If the height of the blockchain stored in the preset database is the same as the target height, it indicates that a block hash value corresponding to the target height exists in the preset database. In this case, the blockchain node can determine that the preset database contains data for a block corresponding to the target height.

[0157] If the height of the blockchain stored in the preset database is different from the target height, it indicates that there is no block hash value corresponding to the target height in the preset database. In this case, the blockchain node can determine that there is no data for a block corresponding to the target height in the preset database.

[0158] Based on the methods described in S201-S203 above, since the current block range represents the block range from the target height to the current height of the blockchain in the current period, and the difference between the target height and the current height is greater than or equal to a preset value, that is, greater than or equal to the number of subsequent blocks corresponding to the time when a block in the blockchain is confirmed to be effective, and the length of the current period is less than the block generation time corresponding to the blockchain, this application can promptly obtain the data of all unconfirmed blocks in the blockchain, as well as the data of newly generated blocks.

[0159] Based on this, this application can promptly determine whether the data stored in the preset cache is consistent with the data on the blockchain, and if there is no consistency, it will obtain the data of all unconfirmed blocks in the blockchain, as well as the data of newly generated blocks, and update the preset cache. Compared with the T+1 data synchronization method, this application can shorten the synchronization time interval, improving the consistency between the data in the preset cache and the data on the blockchain, while also enhancing the real-time performance of the data in the preset cache.

[0160] Furthermore, based on the timely acquisition of newly generated blocks, this application can promptly confirm the blocks that can take effect, i.e., the blocks corresponding to the target height, and update the blocks corresponding to the target height in the preset database in a timely manner. This avoids data inconsistency caused by the deletion of data corresponding to the target height in the preset cache area, thereby improving data consistency. Therefore, this application can at least be used to improve data consistency and enhance data real-time performance, thereby supporting real-time querying of the full amount of data on the blockchain.

[0161] In one embodiment, when querying data in the blockchain, the data update method provided in this application embodiment further includes: S301-S303.

[0162] S301. In response to a data query request sent by a requesting node, which carries a field to be queried, the blockchain node determines whether data corresponding to the field to be queried exists in the preset cache and preset database.

[0163] Optionally, the field to be queried can be a block number, block hash, transaction hash, or blockchain address. A blockchain address can be a string consisting of multiple letters and / or numbers, used to support digital token transactions on the blockchain.

[0164] In one possible approach, combining Figure 1 A requesting node can send a data query request carrying the field to be queried to a blockchain node. Correspondingly, the blockchain node can receive the data query request from the requesting node, parse it to obtain the field to be queried, and, in response to the data query request, determine whether data corresponding to the field to be queried exists in the preset cache and preset database.

[0165] In one possible embodiment, the blockchain node can use parallel processing to simultaneously determine whether there is data corresponding to the field to be queried in the preset cache area and whether there is data corresponding to the field to be queried in the preset database.

[0166] In one possible embodiment, considering that the preset cache can store data of unconfirmed blocks and data of partially confirmed blocks, if the data corresponding to the queried field is located in the partially confirmed block data stored in the preset cache, then reading data from the preset cache is faster than reading data corresponding to the queried field from the preset database. Therefore, to improve data query efficiency, blockchain nodes can also adopt a serial processing method, first determining whether data corresponding to the queried field exists in the preset cache, and then determining whether data corresponding to the queried field exists in the preset database. This embodiment may specifically include steps S3011-S3013.

[0167] S3011. The blockchain node matches the data corresponding to the field to be queried in the preset cache area, and when the match is successful in the preset cache area, it is determined that the data corresponding to the field to be queried exists in the preset cache area.

[0168] S3012. When a blockchain node fails to match within the preset cache area, it matches the data corresponding to the field to be queried within the preset database. When a match is successful within the preset database, it confirms that the data corresponding to the field to be queried exists in the preset database.

[0169] S3013. When a blockchain node fails to match within a preset database, it determines that there is no data in the preset cache or preset database corresponding to the field to be queried.

[0170] S302. When a blockchain node determines that data corresponding to the field to be queried exists in the preset cache or preset database, it sends the data corresponding to the field to be queried to the requesting node.

[0171] In one possible implementation, when a blockchain node determines that data corresponding to the queried field exists in a preset cache or database, it reads the data corresponding to the queried field from the preset cache or database and sends the data to the requesting node. Correspondingly, the requesting node can receive the data corresponding to the queried field from the blockchain node.

[0172] S303. When a blockchain node determines that there is no data in the preset cache area and the preset database that corresponds to the field to be queried, it sends a prompt message to the requesting node to indicate that the query has failed.

[0173] In one possible implementation, a blockchain node can send a message indicating query failure to the requesting node if it determines that no data corresponding to the queried field exists in a preset cache or preset database. Correspondingly, the requesting node can receive the message from the blockchain node and confirm the query failure.

[0174] In one embodiment, in conjunction with the description in S301-S303, such as Figure 4The diagram illustrates a data query process according to an embodiment of this application. After receiving a data query request from a requesting node, a blockchain node can match data corresponding to the queried field within a preset cache. If a match is successful within the preset cache, the blockchain node sends the data corresponding to the queried field to the requesting node. Alternatively, if a match fails within the preset cache, the blockchain node can match data corresponding to the queried field within a preset database. If a match is successful within the preset database, the blockchain node sends the data corresponding to the queried field to the requesting node. Alternatively, if a match fails within the preset database, the blockchain node sends a message indicating query failure to the requesting node and terminates the query request.

[0175] In one embodiment, such as Figure 5 The diagram illustrates a data update process provided in an embodiment of this application. A blockchain node can initialize the system and start the blockchain maintenance service. Staff can set the cycle length (a fixed time interval t for updating data) and a preset value N within the blockchain node, which is the number of subsequent blocks corresponding to the confirmed block in the blockchain. It should be understood that when the difference between the current height and the target height equals the preset value N, the current block range includes N+1 blocks. For example, with a current height of 100, a target height of 95, and a preset value N of 5, the height range of 95-100 can also be represented as [95, 100], including a total of 6 blocks corresponding to 95, 96, 97, 98, 99, and 100 respectively.

[0176] At fixed time intervals t, blockchain nodes can call the RPC interface to query the blockchain data corresponding to the current period. The blockchain data corresponding to the current period can include the block header data and transaction data of each block within the current block range.

[0177] Blockchain nodes can determine whether the blockchain height has increased and whether the block data has changed. If the data of the most recently generated N blocks has not changed, the data in the preset cache remains unchanged. If there is a new block height and / or the data of one or more blocks has changed, the preset cache is updated. The N+1 blocks are numbered, meaning each block within the current block range is numbered, with the most recently generated block numbered 0, and the sequence extending towards the earliest generated block, which is then numbered N. The block numbered N corresponds to the height obtained by subtracting a preset value from the current height. Blockchain nodes can determine whether the data for the Nth block exists in the preset database. If the Nth block has not been written to the preset database, its data is updated there. Blockchain nodes can wait for the next cycle, repeatedly checking at fixed time intervals t, until an exit command is received.

[0178] In this embodiment, the current block range represents the range of blocks from the target height to the current height of the blockchain in the current period, and the difference between the target height and the current height is greater than or equal to a preset value, that is, greater than or equal to the number of subsequent blocks corresponding to the time when a block in the blockchain is confirmed to be effective. Furthermore, the length of the current period is less than the block generation time corresponding to the blockchain. Therefore, this application can promptly obtain data from all unconfirmed blocks in the blockchain, as well as data from newly generated blocks.

[0179] Based on this, blockchain nodes can promptly determine whether the data stored in the preset cache is consistent with the data on the blockchain. If inconsistency exists, the nodes will retrieve all unconfirmed block data from the blockchain, as well as the data from newly generated blocks, and update the preset cache. Compared to the T+1 data synchronization method, this application can shorten the synchronization time interval, improving both the consistency between the data in the preset cache and the data on the blockchain, and enhancing the real-time performance of the data in the preset cache.

[0180] Furthermore, based on the timely acquisition of newly generated blocks, blockchain nodes can promptly confirm the blocks that can take effect, i.e., the blocks corresponding to the target height, and update the blocks corresponding to the target height in the preset database in a timely manner. This avoids data inconsistencies caused by the deletion of data corresponding to the target height in the preset cache, thereby improving data consistency. Therefore, this application can at least be used to improve data consistency and enhance data real-time performance, thereby supporting real-time querying of the full amount of data on the blockchain.

[0181] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0182] This application embodiment can, according to the above method, exemplarily divide an electronic device into functional modules. For example, the electronic device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0183] For example, embodiments of this application also provide a data update device.

[0184] Figure 6 This is a block diagram illustrating a data update apparatus according to an exemplary embodiment. (Refer to...) Figure 6 The data update device may include: an acquisition unit 401 and an update unit 402;

[0185] The acquisition unit 401 is configured to acquire the blockchain data corresponding to the current period; the blockchain data includes the data of each block in the blockchain within the current block range; the current block range is used to characterize the block range from the target height to the current height of the blockchain in the current period; the difference between the target height and the current height is greater than or equal to a preset value; the preset value is used to characterize the number of subsequent blocks corresponding to the confirmation and effectiveness of a block in the blockchain; the length of the current period is less than the block production time corresponding to the blockchain;

[0186] The update unit 402 is configured to update the data of each block in the preset cache when it is determined that there is a discrepancy between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period.

[0187] The update unit 402 is also configured to update the data of the block corresponding to the target height in the preset database when it is determined that there is no data of the block corresponding to the target height in the preset database.

[0188] In one alternative implementation, the data update device further includes: a determining unit 403 and a sending unit 404;

[0189] The determining unit 403 is configured to execute a data query request sent by the requesting node, carrying a field to be queried, to determine whether there is data corresponding to the field to be queried in the preset cache and preset database;

[0190] Sending unit 404 is configured to send the data corresponding to the field to be queried to the requesting node when it is determined that there is data corresponding to the field to be queried in the preset cache or preset database.

[0191] The sending unit 404 is also configured to send a prompt message to the requesting node indicating that the query has failed when it is determined that there is no data in the preset cache and the preset database that corresponds to the field to be queried.

[0192] In one alternative implementation, the determining unit 403 is specifically configured to perform: matching data corresponding to the field to be queried in a preset cache, and when a match is successful in the preset cache, determining that data corresponding to the field to be queried exists in the preset cache; or, when a match fails in the preset cache, matching data corresponding to the field to be queried in a preset database; when a match is successful in the preset database, determining that data corresponding to the field to be queried exists in the preset database; when a match fails in the preset database, determining that no data corresponding to the field to be queried exists in the preset cache or the preset database.

[0193] In one optional implementation, the block data includes a block hash value; the update unit 402 is specifically configured to perform: determining whether the height of the blockchain stored in the preset cache is consistent with the current height, and when the height of the blockchain is inconsistent with the current height, determining that the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period; or, when the height of the blockchain is consistent with the current height, determining whether the block hash values ​​of each block stored in the preset cache are consistent with the block hash values ​​of each block corresponding to the current period, and when the block hash value of any block stored in the preset cache is inconsistent with the block hash value of any block in the current period, determining that the blockchain data stored in the preset cache is inconsistent with the blockchain data corresponding to the current period.

[0194] In one optional implementation, the update unit 402 is specifically configured to perform the following: when it is determined that the storage state of the block corresponding to the target height in the preset cache is not updated, determine that there is no data for the block corresponding to the target height in the preset database; or, when it is determined that there is no hash value for the block corresponding to the target height in the preset database, determine that there is no data for the block corresponding to the target height in the preset database; or, when it is determined that the height of the blockchain stored in the preset database is different from the target height, determine that there is no data for the block corresponding to the target height in the preset database.

[0195] In one alternative implementation, the update unit 402 is further configured to maintain the blockchain data stored in the preset cache and wait for the next cycle when the blockchain data stored in the preset cache is consistent with the blockchain data corresponding to the current cycle.

[0196] In one optional implementation, the block data also includes block header data and transaction data. The acquisition unit 401 is specifically configured to: call the current block hash acquisition service to obtain the hash value of the current block corresponding to the current height in the blockchain; call the block acquisition service based on the hash value of the current block to obtain the block header data of the current block; parse the block header data of the current block to obtain the current height and the transaction hash value corresponding to the current block, and determine the current block range based on the current height; call the block hash acquisition service based on the current block range to obtain the hash values ​​of other blocks within the current block range, and call the block acquisition service based on the hash values ​​of other blocks to obtain the block header data of other blocks; and call the transaction data acquisition service based on the transaction hash value corresponding to the current block and the transaction hash values ​​corresponding to other blocks to obtain the transaction data corresponding to the current block and the transaction data corresponding to other blocks.

[0197] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0198] Figure 7 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0199] like Figure 7 As shown, the electronic device 200 includes, but is not limited to, a processor 210 and a memory 220.

[0200] The memory 220 described above is used to store the executable instructions of the processor 210. It is understood that the processor 210 is configured to execute instructions to implement the data update method in the above embodiments.

[0201] It should be noted that those skilled in the art will understand that Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 7 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0202] Processor 210 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 220, and by calling data stored in memory 220, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 210 may include one or more processing units; optionally, processor 210 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 210.

[0203] The memory 220 can be used to store software programs and various data. The memory 220 may primarily include a program storage area and a data storage area, wherein the program storage area may store the operating system, applications required by at least one functional module, etc. Furthermore, the memory 220 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0204] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 220 including instructions, which can be executed by a processor 210 of an electronic device 200 to implement the data update method in the above embodiments.

[0205] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0206] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 210 of the electronic device 200 to complete the data update method in the above embodiments.

[0207] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor 210 of the electronic device 200, they implement the various processes of the above-described data update method embodiments and achieve the same technical effect as the above-described data update method. To avoid repetition, they will not be described again here.

[0208] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0209] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0210] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the classified units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0211] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0212] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to general technology, or the entirety or portion of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute the entirety or portion of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0213] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data update method, characterized in that, include: Obtain the blockchain data corresponding to the current period; the blockchain data includes the data of each block in the blockchain that is within the current block range; The current block range is used to characterize the block range from the target height to the current height of the blockchain in the current period; The difference between the target height and the current height is greater than or equal to a preset value; The preset value is used to represent the number of subsequent blocks corresponding to the confirmation and effectiveness of a block in the blockchain; the length of the current period is less than the block production time corresponding to the blockchain; When it is determined that there is inconsistent data between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period, the data of each block is updated in the preset cache. When it is determined that there is no data in the preset database corresponding to the target height, the data of the block corresponding to the target height is updated in the preset database.

2. The data update method according to claim 1, characterized in that, Also includes: In response to a data query request sent by a requesting node carrying a field to be queried, determine whether there is data corresponding to the field to be queried in the preset cache and the preset database; When it is determined that data corresponding to the field to be queried exists in the preset cache or the preset database, the data corresponding to the field to be queried is sent to the request node; When it is determined that the preset cache area and the preset database do not contain data corresponding to the field to be queried, a prompt message indicating query failure is sent to the request node.

3. The data update method according to claim 2, characterized in that, Determining whether data corresponding to the field to be queried exists in the preset cache and the preset database includes: Match the data corresponding to the field to be queried in the preset cache area, and when the match is successful in the preset cache area, determine that there is data corresponding to the field to be queried in the preset cache area; Alternatively, if a match fails in the preset cache area, the data corresponding to the field to be queried is matched in the preset database; if a match is successful in the preset database, it is determined that the data corresponding to the field to be queried exists in the preset database; if a match fails in the preset database, it is determined that the preset cache area and the preset database do not contain data corresponding to the field to be queried.

4. The data update method according to claim 1, characterized in that, The data in the block includes the block hash value; The determination that there is inconsistency between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period includes: Determine whether the height of the blockchain stored in the preset cache area is consistent with the current height, and when the height of the blockchain is inconsistent with the current height, determine that there is inconsistent data between the blockchain data stored in the preset cache area and the blockchain data corresponding to the current period; Alternatively, when the height of the blockchain is consistent with the current height, it is determined whether the block hash value of each block stored in the preset cache is consistent with the block hash value of each block corresponding to the current period. And when the block hash value of any block stored in the preset cache is inconsistent with the block hash value of any block in the current period, it is determined that there is inconsistent data between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period.

5. The data update method according to claim 1, characterized in that, The step of determining that there is no data block in the preset database corresponding to the target height includes: When it is determined that the storage status of the block corresponding to the target height in the preset cache area is not updated, it is determined that there is no data in the preset database corresponding to the target height. Alternatively, when it is determined that there is no block hash value corresponding to the target height in the preset database, it is determined that there is no data of a block corresponding to the target height in the preset database. Alternatively, if it is determined that the height of the blockchain stored in the preset database is different from the target height, it is determined that there is no data of a block corresponding to the target height in the preset database.

6. The data update method according to claim 1, characterized in that, After obtaining the blockchain data corresponding to the current period, the process also includes: When the blockchain data stored in the preset cache is consistent with the blockchain data corresponding to the current period, the blockchain data stored in the preset cache is maintained, and the process waits for the next period.

7. The data update method according to any one of claims 1-6, characterized in that, The block data also includes block header data and transaction data; obtaining the blockchain data corresponding to the current period includes: Call the current block hash retrieval service to obtain the hash value of the current block in the blockchain corresponding to the current height; The block header data of the current block is obtained by calling the block retrieval service based on the hash value of the current block. The current height and the transaction hash value corresponding to the current block are obtained by parsing the block header data of the current block, and the range of the current block is determined based on the current height; Based on the current block range, call the block hash retrieval service to obtain the hash values ​​of other blocks within the current block range, and based on the hash values ​​of the other blocks, call the block retrieval service to obtain the block header data of the other blocks; Based on the transaction hash value corresponding to the current block and the transaction hash values ​​corresponding to other blocks, the transaction data acquisition service is invoked to obtain the transaction data corresponding to the current block and the transaction data corresponding to other blocks.

8. A data update device, characterized in that, include: Get unit and update unit; The acquisition unit is configured to acquire blockchain data corresponding to the current period; the blockchain data includes data of each block in the blockchain within the current block range; the current block range is used to characterize the block range from the target height to the current height of the blockchain in the current period; The difference between the target height and the current height is greater than or equal to a preset value; The preset value is used to represent the number of subsequent blocks corresponding to the confirmation and effectiveness of a block in the blockchain; the length of the current period is less than the block production time corresponding to the blockchain; The update unit is configured to update the data of each block in the preset cache when it is determined that there is a discrepancy between the blockchain data stored in the preset cache and the blockchain data corresponding to the current period. The update unit is further configured to update the data of the block corresponding to the target height in the preset database when it is determined that there is no data of the block corresponding to the target height in the preset database.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the data update method as described in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the data update method as described in any one of claims 1-7.

Images