Blockchain-based offline data query method and related apparatus

Abstract

This application discloses an offline data query method and related apparatus based on blockchain. The method involves an offline parsing server performing transaction data analysis on the blockchain and storing the parsed data in a pre-defined third-party caching component and a search engine. When a blockchain explorer receives a data query request, it first searches the third-party caching component. If the data is found, it is directly returned; otherwise, it searches the search engine. Because the data writing time of the third-party caching component is lower than the data refresh time of the search engine, the latest transaction data can be found in the third-party caching component and returned to the user before it is written to the search engine. This avoids the inability to find the latest transaction data for a period of time due to the search engine's refresh mechanism, thus improving the real-time performance of offline data queries.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a blockchain-based offline data query method and related apparatus. Background Technology

[0002] A blockchain explorer is a tool used to view information such as transactions, addresses, and blocks on a blockchain. It allows users to directly access and explore the blockchain network, providing a more intuitive and transparent way to access blockchain data. Through a blockchain explorer, users can check the status of transactions, confirm whether transactions were successful, view the balance of a specific address, and view transaction history, among other things.

[0003] In related technologies, blockchain data querying typically involves first using the Elasticsearch (ES) search engine to query on-chain data offline, and then storing it in ES in a way that is easier for users to understand. Users can then query and analyze on-chain data from ES more quickly and conveniently. To ensure the real-time performance of queried data, current methods often involve reducing ES's data refresh time to allow ES to query newly inserted data more quickly. However, this increases the amount of I / O operations in ES, impacting its overall performance and reducing transaction throughput. In scenarios where blockchain block generation is fast, this can lead to block blocking during offline block queries, resulting in more severe latency issues and ultimately poor real-time performance of offline data queries. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a blockchain-based offline data query method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can improve the real-time performance of offline data queries.

[0005] According to one aspect of the embodiments of this application, a blockchain-based offline data query method is provided, applied to a blockchain query system. The blockchain query system includes a blockchain network, a user terminal, a blockchain explorer, a parsing server, a search engine, and a third-party caching component. The parsing server is used to perform offline parsing of transaction data on the blockchain and store the data obtained from the offline parsing in the third-party caching component and the search engine. The data writing time of the third-party caching component is lower than the data refresh time of the search engine. The method is executed by the blockchain explorer, and the method includes: receiving a data query request from the user terminal; responding to the data query request, querying the target data corresponding to the data query request in the third-party caching component; if the target data does not exist in the third-party caching component, performing a data query in the search engine; and returning the queried target data to the user terminal.

[0006] In another exemplary embodiment, the blockchain query system further includes an operation platform, which is used to conduct preset digital asset trading activities and store the corresponding transaction data in the chain nodes included in the blockchain network; before responding to the data query request and querying the target data corresponding to the data query request in the third-party caching component, the method further includes: determining the transaction data corresponding to the preset digital asset trading activities as high-frequency hotkey data through the operation platform; and pre-storing the high-frequency hotkey data in the third-party caching component before the operation platform conducts the preset digital asset trading activities.

[0007] In another exemplary embodiment, the method further includes deleting the high-frequency hotkey data from the third-party cache component after the preset digital asset transaction activity ends.

[0008] In another exemplary embodiment, after responding to the data query request and querying the target data corresponding to the data query request in the third-party caching component, the method further includes: periodically obtaining the number of times transaction data in the blockchain network has been accessed; determining transaction data whose access count is greater than or equal to a first preset threshold as target transaction data; determining high-frequency hotkey data based on the target transaction data; and storing the high-frequency hotkey data in the third-party caching component.

[0009] In another exemplary embodiment, the method further includes: periodically detecting the validity of the high-frequency hotkey data and obtaining a detection result; if the detection result indicates that the high-frequency hotkey data is valid, extending the caching time of the high-frequency hotkey data in the third-party caching component; if the detection result indicates that the high-frequency hotkey data is invalid, deleting the high-frequency hotkey data in the third-party caching component.

[0010] In another exemplary embodiment, the method further includes: querying the target data from a chain node if the target data is not present in the search engine; and storing the data queried from the chain node into the third-party caching component and the search engine.

[0011] In another exemplary embodiment, the method further includes: if other user terminals query the target data, obtaining the historical query start time of the target data; determining the query status of the target data based on the current time and the historical query start time; and performing a processing operation matching the query status; wherein different query statuses correspond to different processing operations.

[0012] In another exemplary embodiment, the query status includes a query chain node failure status; the execution of processing operations matching the query status includes: if the query status is a query chain node failure status, then feeding back preset query failure information to the user terminal, and updating the historical query start time to the current time, so as to more accurately determine the query status of the target data in the next query.

[0013] In another exemplary embodiment, determining the query status of the target data based on the current time and the historical query start time includes: obtaining the time difference between the current time and the historical query start time; determining the query status as query chain node failure when the time difference is greater than a preset time threshold and the number of times the third-party cache component is re-queried exceeds a second preset number threshold; confirming the query status as query chain node in when the time difference is less than or equal to the preset time threshold and the target data is not present in the third-party cache component; and confirming the query status as query chain node successful when the time difference is less than or equal to the preset time threshold and the target data is present in the third-party cache component.

[0014] In another exemplary embodiment, the method further includes: obtaining an automatic deletion time period set for the data stored in the third-party caching component; wherein the automatic deletion time period is the data refresh duration of the search engine; and performing deletion processing on the data stored in the third-party caching component based on the automatic deletion time period.

[0015] According to one aspect of the embodiments of this application, a blockchain-based offline data query device is provided, applied to a blockchain query system. The blockchain query system includes a blockchain network, a user terminal, a blockchain explorer, a parsing server, a search engine, and a third-party caching component. The parsing server is used to perform offline parsing of transaction data on the blockchain and store the data obtained from the offline parsing in the third-party caching component and the search engine. The data writing time of the third-party caching component is lower than the data refresh time of the search engine. The device includes: a receiving module configured to receive a data query request from a user terminal; a first query module configured to, in response to the data query request, query the target data corresponding to the data query request in the third-party caching component; a second query module configured to, if the target data does not exist in the third-party caching component, perform a data query in the search engine; and a feedback module configured to return the queried target data to the user terminal.

[0016] According to one aspect of the present application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the blockchain-based offline data query method as described above.

[0017] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the blockchain-based offline data query method as described above.

[0018] According to one aspect of the embodiments of this application, a computer program product is also provided, the computer program product including computer instructions, which, when executed by a processor, are used to implement the blockchain-based offline data query method as described above.

[0019] In the technical solution provided by the embodiments of this application, the transaction data on the blockchain is parsed offline by the parsing server, and the data obtained from the offline parsing is stored in a preset third-party caching component and a search engine. When the blockchain explorer receives a data query request, it first queries the data in the third-party caching component. If the data is found, it is directly returned; otherwise, it queries the data in the search engine. In this way, since the data writing time of the third-party caching component is lower than the data refresh time of the search engine, the corresponding latest transaction data can be found in the third-party caching component and returned to the user before it is written to the search engine. This avoids the situation where the latest transaction data cannot be found for a period of time due to the refresh mechanism of the search engine, thereby improving the real-time performance of offline data query.

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

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

[0022] Figure 1 This is a schematic diagram of the structure of a blockchain network shown in an exemplary embodiment of this application;

[0023] Figure 2This is a schematic diagram illustrating an implementation environment of the blockchain-based offline data query method, as shown in an exemplary embodiment of this application.

[0024] Figure 3 This is a flowchart illustrating an exemplary embodiment of the blockchain-based offline data query method.

[0025] Figure 4 This is a flowchart illustrating a blockchain-based offline data query method, as shown in another exemplary embodiment of this application.

[0026] Figure 5 This is an exemplary embodiment of the present application illustrating an application of a blockchain-based offline data query method;

[0027] Figure 6 This is a flowchart illustrating a blockchain-based offline data query method, as shown in another exemplary embodiment of this application.

[0028] Figure 7 This is another exemplary embodiment of the present application illustrating an application of a blockchain-based offline data query method;

[0029] Figure 8 This is a flowchart illustrating a blockchain-based offline data query method, as shown in another exemplary embodiment of this application.

[0030] Figure 9 This is another exemplary embodiment of the present application illustrating an application of a blockchain-based offline data query method;

[0031] Figure 10 This is a flowchart illustrating a blockchain-based offline data query method, as shown in another exemplary embodiment of this application.

[0032] Figure 11 This is a schematic diagram illustrating the structure of a blockchain-based offline data query device, as shown in an exemplary embodiment of this application.

[0033] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0034] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments identical to those described in this application. Rather, they are merely examples of apparatuses and methods identical to some aspects of this application as detailed in the appended claims.

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

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

[0037] It should be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0038] First, it should be noted that the embodiments of this application involve blockchain technology. Blockchain technology is a novel distributed infrastructure and computing method that utilizes a block-chain data structure to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script code to program and manipulate data. Specifically, it is a data structure that organizes data blocks in chronological order using a linked list-like manner, which can securely store data with sequential relationships that can be verified within the system, and uses cryptography to ensure that the data is immutable and unforgeable. Simply put, blockchain is a decentralized distributed ledger, where each chain is equivalent to an independent ledger.

[0039] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain network shown in an exemplary embodiment of this application. Figure 1 The blockchain network 100 shown may include node devices 10a, 10b, 10c, and 10d. Node devices 10a, 10b, 10c, and 10d are all... Figure 1The blockchain nodes (hereinafter referred to as nodes) in the blockchain network 100 shown can be any form of computing device connected to the blockchain network 100, such as servers, user terminals, etc. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this connection. Figure 1 The node devices 10a, 10b, 10c, and 10d shown can also be connected to form a blockchain network 100 through network communication.

[0040] Each node in blockchain network 100 can be used to maintain the same blockchain (i.e. Figure 1 The blockchain 10e shown can be pre-deployed with multiple smart contracts, such as agent contracts, permission management contracts, data contracts, agent management contracts, etc., which have different data processing functions.

[0041] In related technologies, in order to ensure the real-time performance of query data, the current common practice is to reduce the data refresh time of Elasticsearch (ES) so that ES can query newly inserted data faster. However, this method increases the number of IO operations in ES, affecting the overall performance of ES and reducing the throughput of transactions written to ES. In scenarios where blockchain blocks are produced quickly, it can lead to blockage of offline query blocks, resulting in more serious latency problems and thus poor real-time performance of offline query data.

[0042] Based on this, in order to improve the real-time performance of offline data query, embodiments of this application propose a blockchain-based offline data query method, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0043] The following is a detailed description of the blockchain-based offline data query scheme provided in the embodiments of this application.

[0044] Please see Figure 2 , Figure 2 This is a schematic diagram of an implementation environment involved in this application, specifically a blockchain query system. Figure 2As shown, the blockchain query system includes a blockchain network 100, a user terminal 210, a blockchain explorer 220, a parsing server 230, a third-party caching component 240, and a search engine 250. The parsing server 230 is used to perform offline parsing of transaction data on the blockchain deployed in the blockchain network 100, and stores the data obtained from the offline parsing in the third-party caching component 240 and the search engine 250.

[0045] In this embodiment, the data write time of the third-party caching component 240 is shorter than the data refresh time of the search engine 250. In some embodiments, the parsing server 230 parses the latest transaction data in the blockchain network 100 and stores the parsed transaction data in the memory of the search engine 250. The data refresh mechanism of the search engine 250 refreshes periodically (every data refresh interval, e.g., 10 seconds), batching the transaction data in the memory of the search engine 250 into segment files, thus enabling the blockchain explorer 220 to query the transaction data. If the data write time of the third-party caching component 240 is shorter than the data refresh time of the search engine 250, the transaction data can be queried in the third-party caching component 240 and returned to the user before it is written to the segment file in the search engine 250.

[0046] It should also be noted that the parsing server 230, the third-party caching component 240, and the search engine 250 can be deployed on at least two servers or on the same server; there are no restrictions on this.

[0047] User terminal 210 can be an electronic device with a front-end interface, such as a mobile phone, computer, or computer, but is not limited to these. User terminal 210 can refer to one of multiple terminals; this embodiment only uses user terminal 210 as an example. Those skilled in the art will understand that the number of terminals can be more or less. For example, there may be only one terminal, or there may be dozens or hundreds of terminals, or even more. This application embodiment does not limit the number or type of user terminal 210. The user can initiate a data query request to the blockchain explorer through the front-end interface of user terminal 210. Blockchain explorer 220 first performs a data query in third-party caching component 240. If the data is found, it is returned to user terminal 210; if not, it then performs a data query in search engine 250.

[0048] A blockchain explorer 220 is a tool used to view information such as transactions, addresses, and blocks on a blockchain network 100. It allows users to directly access and explore the blockchain network 100, providing a more intuitive and transparent way to access blockchain data. Through the blockchain explorer 220, users can query the status of transactions, confirm whether transactions were successful, view the balance of a specific address, and view transaction history. In some embodiments, the blockchain explorer 220 can be a Zhixin Chain explorer, in which case the blockchain can be Zhixin Chain.

[0049] A blockchain explorer works by sending a data query request to the blockchain network, parsing the returned data, and displaying it to the user in an easy-to-understand manner. This data typically includes information such as block height, block hash, transaction details, and address balance. Blockchain explorers are valuable for developers, researchers, and ordinary users. Developers can use them to debug and test smart contracts, researchers can use them to analyze data patterns and trends on the blockchain, and ordinary users can use them to view their transaction status and assets.

[0050] The third-party caching component 240 can be Redis (Remote Dictionary Server). Redis is a high-performance key-value store database that supports various data structures, including strings, lists, hashes, sets, and sorted sets. This makes it more than just a simple key-value store; it can also be used to store and process complex data. Redis's main application scenarios include caching, counters, message queues, leaderboards, and session caching.

[0051] The search engine 250 could be Elasticsearch (ES). ES is a search and analytics engine based on Lucene (a high-performance, fully functional full-text search engine toolkit written entirely in Java). It provides a distributed, multi-tenant full-text search engine and is also a distributed real-time analytics search engine. ES's underlying storage uses the Lucene framework, utilizing a tokenizer to break down text into words or phrases and storing them according to an inverted index for efficient retrieval. ES is not only used for searching various documents but is also widely applied in business scenarios requiring massive data storage, retrieval, and analysis. ES's powerful capabilities make it widely applicable in areas such as massive data processing, real-time data analysis, log analysis, security information and event management (SIEM), enterprise search, and application search. Blockchain can leverage ES to query on-chain data offline, storing it in ES in a way that is easier for users to understand, making it faster and more convenient for users to query and analyze on-chain data.

[0052] The parsing server 230 stores the transactions retrieved offline into Elasticsearch (ES). ES first loads the data into memory and then periodically (the interval is the data refresh duration, which is configurable) batches the transaction data in memory into segment files. These files reside on disk and undergo I / O operations. Once the segment files are generated, they can be queried by the blockchain explorer 220. The segment file is the basic storage unit for indexed data in ES.

[0053] Elasticsearch's data refresh interval refers to the time interval during which Elasticsearch makes newly indexed documents searchable. By default, Elasticsearch's data refresh interval is 10 seconds, meaning that newly indexed documents will become searchable within 10 seconds. This interval can be adjusted according to actual needs. In some cases, you may need to adjust the data refresh interval to optimize performance. For example, if your application needs to index a large number of documents in a short period of time, you can consider increasing the data refresh interval to reduce I / O operations. However, increasing the data refresh interval will cause newly indexed documents to be unsearchable for a longer period of time, so a trade-off needs to be struck based on actual requirements.

[0054] Understandably, in this implementation environment, the transaction data on the blockchain is parsed offline by the parsing server, and the data obtained from the offline parsing is stored in a preset third-party caching component 240 and a search engine 250. Users initiate data query requests to the blockchain explorer 220 through the front-end page of the user terminal 210. After receiving the data query request, the blockchain explorer 220 first searches for data in the third-party caching component 240. If the data is found, it is returned to the user terminal 210; otherwise, it searches for data in the search engine 250. In this way, because the data writing time of the third-party caching component 240 is lower than the data refresh time of the search engine 250, the latest transaction data can be found in the third-party caching component 240 and returned to the user before it is written to the search engine 250. This avoids the situation where the latest transaction data cannot be found for a period of time due to the refresh mechanism of the search engine 250, thus improving the real-time performance of offline data queries.

[0055] Please continue reading. Figure 3 , Figure 3 This is a flowchart illustrating an exemplary embodiment of the blockchain-based offline data query method. This method can be applied to... Figure 2 The implementation environment shown is specifically executed by the blockchain explorer 220 within that implementation environment. It should be understood that this method can also be applied to other exemplary implementation environments and executed by blockchain explorers in other implementation environments; this embodiment does not limit the implementation environment to which this method is applicable.

[0056] like Figure 3 As shown, in an exemplary embodiment, the blockchain-based offline data query method includes at least steps S310 to S340, which are described in detail below:

[0057] Step S310: Receive a data query request from the user terminal.

[0058] In some embodiments, the user terminal may be an electronic device with a front-end interface, such as a mobile phone, computer, or computer, but it is not limited to this. Users can initiate data query requests to the blockchain explorer through the front-end interface of the user terminal.

[0059] Step S320: In response to the data query request, query the target data corresponding to the data query request in the third-party caching component.

[0060] In this embodiment, the search engine is Elasticsearch. The parsing server parses the latest transaction data in the blockchain network and stores the parsed transaction data in Elasticsearch's memory. Elasticsearch's data refresh mechanism refreshes the data periodically (every data refresh interval, e.g., 10 seconds), batching the transaction data in Elasticsearch's memory into segment files, thus enabling the blockchain explorer to query the transaction data. The data write time of the third-party caching component is shorter than the search engine's data refresh time. Therefore, before the transaction data is written to the segment file in the search engine, it can be queried in the third-party caching component and returned to the user. Thus, if the target data exists in the third-party caching component, the queried target data is directly fed back to the user terminal.

[0061] In some embodiments, the third-party caching component is Redis. Redis write times are in the millisecond range, and queried data is also real-time; once a write to Redis is successful, the data can be retrieved from Redis. Using this method, new transaction data can be queried in Redis and returned to the user before it is written to the search engine's segment file. This reduces the real-time performance of offline data queries from seconds to milliseconds.

[0062] In some embodiments, the third-party caching component may also be MySQL (a relational database management system), ClickHouse (a columnar database management system for online analytical processing), etc.

[0063] Step S330: If the target data is not found in the third-party caching component, then perform a data query in the search engine.

[0064] Understandably, since complex business data cannot be queried through chain nodes, when the target data is not found in the third-party caching component, data is queried through a search engine. This avoids directly querying chain nodes, allowing the blockchain explorer to ensure both real-time data querying and compatibility with complex business queries.

[0065] In some embodiments, since the number of third-party caching components cannot be set indefinitely, transaction data stored in these components must be cleared promptly to prevent large amounts of cached data from dragging down their performance and increasing the overall cost of the blockchain query system. Therefore, an automatic deletion period for cached data can be set in the third-party caching components. Regarding the search engine refresh mechanism in this embodiment, by setting the automatic deletion period to the search engine's data refresh interval, the data in the third-party caching components is cleared every data refresh interval, while ensuring that the cleared data can still be found in the search engine.

[0066] In some embodiments, the blockchain-based offline data query method of this application further includes: obtaining the automatic deletion time period set for data stored in a third-party caching component; and performing deletion processing on the data stored in the third-party caching component based on the automatic deletion time period. The automatic deletion time period is the data refresh duration of the search engine.

[0067] For example, if a search engine refreshes data every 10 seconds, and a third-party caching component can delete transaction data older than 10 seconds, then the data lifespan can be set to 10 seconds (i.e., the automatic deletion period is set to 10 seconds). This not only avoids a large amount of data dragging down the performance of the third-party caching component, but also allows the transaction data to be found in the search engine if it cannot be found in the third-party caching component.

[0068] In some embodiments, the specific command to set the automatic deletion time period is as follows: SET mykey(transaction A)value(data of transaction A)EX 10. Here, EX 10 indicates that the data of transaction A has a lifespan of 10 seconds and will be automatically deleted after 10 seconds.

[0069] Step S340: Return the retrieved target data to the user terminal.

[0070] By returning the retrieved target data to the user terminal for display on the user interface, the user can gain a more intuitive understanding of the retrieved target data.

[0071] Therefore, this embodiment employs the blockchain-based offline data query method provided in this application. The server performs offline parsing of transaction data on the blockchain and stores the parsed data in a pre-defined third-party caching component and a search engine. Upon receiving a data query request, the system prioritizes querying the third-party caching component. If the data is found, it is directly returned; otherwise, the search engine is used. Because the data writing time of the third-party caching component is lower than the data refresh time of the search engine, the latest transaction data can be found in the third-party caching component and returned to the user before it is written to the search engine. This avoids the inability to find the latest transaction data for a period of time due to the search engine's refresh mechanism, thus improving the real-time performance of offline data queries.

[0072] In another exemplary embodiment, the blockchain query system further includes an operating platform for conducting preset digital asset trading activities and storing the resulting transaction data in the chain nodes included in the blockchain network. Figure 4 As shown, before performing data retrieval in a third-party caching component in response to a received data query request, the blockchain-based offline data query method... Figure 3 Based on the illustrated embodiment, steps S410 to S420 are also included, which are described in detail below:

[0073] Step S410: The transaction data corresponding to the preset digital asset transaction activities is determined as high-frequency hotkey data through the operation platform.

[0074] It's understandable that users exhibit a characteristic when querying transaction data through blockchain explorers. For example, if a particular series of NFTs (Non-Fungible Tokens) is undergoing airdrops or sales, those NFTs will be subject to a surge in queries during this period. To address this scenario, high-frequency hotkey data can be cached, diverting this concurrent traffic to a third-party caching component. This avoids a large influx of query traffic to the search engine, which could negatively impact its overall performance and potentially cause blockages in the offline transaction query and Elasticsearch (ES) storage links, resulting in user query delays.

[0075] In this embodiment of the application, transaction data may refer to one or more of all data included in a transaction. For example, if the preset digital asset transaction activity is an NFT activity, the transaction data corresponding to this activity may include one or more of the following: digital asset ID, issuer, link information, and hash.

[0076] Step S420: Before conducting preset digital asset trading activities on the operating platform, high-frequency hotkey data is pre-stored in a third-party cache component.

[0077] For example, in a scenario where the pre-set digital asset trading activity is an NFT event, before the event begins, the transaction data generated by the event is written to a third-party caching component using an operations platform (operated by users or operators). In some embodiments, such as an NFT event starting at 10:00 AM, the data can be preheated half an hour earlier, at 9:30 AM, storing the transaction data corresponding to the NFT event as high-frequency hotkey data in the third-party caching component. This way, during the event, most of the traffic can be diverted to the third-party caching component, thus avoiding any impact on the overall performance of Elasticsearch.

[0078] In some embodiments, after a preset digital asset trading activity ends, high-frequency hotkey data is deleted from the third-party caching component. This deletion of high-frequency hotkey data corresponding to the activity after it concludes allows for timely cleanup of the third-party caching component's storage space, thereby preventing a large amount of cached data from hindering its performance.

[0079] For example, combining Figure 5 As shown, Figure 5 This is an exemplary embodiment of the present application illustrating an application diagram of a blockchain-based offline data query method. Figure 5 In the process, the parsing server 230 parses the latest transaction data in the blockchain network 100 and stores the parsed transaction data in the memory of the search engine 250. User terminals 210 include user terminal 1 and user terminal 2. User terminal 1 stores the transaction data corresponding to a pre-set digital asset trading activity as high-frequency hotkey data in a third-party caching component 240 and in the search engine 250 via the operation platform 260 before the activity begins. After the activity starts, user terminal 2 can initiate a data query request to the blockchain explorer 220 through the front-end interface. Upon receiving the data query request, the blockchain explorer 220 can directly query the transaction data corresponding to the activity in the third-party caching component 240. This directs the concurrent traffic during the activity to the third-party caching component 240, avoiding a large amount of query traffic to the search engine 250, which could drag down the overall performance of the search engine and cause the risk of offline transaction query and Elasticsearch (ES) storage link being blocked, resulting in user query delays. Furthermore, after the event ends, user terminal 1 can delete the high-frequency hotkey data in the third-party cache component 240 through the operation platform 260, so as to clean up the storage space of the third-party cache component 240 in a timely manner.

[0080] It should be noted that the steps in this embodiment are consistent with the corresponding steps in the foregoing embodiments. Therefore, for a detailed description of these steps, please refer to the description in the foregoing embodiments. This embodiment will not repeat them here.

[0081] In another exemplary embodiment, such as Figure 6 As shown, after querying data in a third-party caching component in response to a received data query request, the blockchain-based offline data query method... Figure 3 Based on the illustrated embodiment, steps S610 to S620 are also included, which are described in detail below:

[0082] Step S610: Periodically obtain the number of times transaction data in the blockchain network has been accessed.

[0083] It is understood that the blockchain query system in this application also includes a monitoring platform, which can periodically query high-frequency hotkey data in the blockchain network over a period of time, and then automatically write this data into a third-party cache component.

[0084] For example, if the query cycle of the monitoring platform is a preset time period, such as 5 minutes, then the monitoring platform will count the number of times the transaction data in the blockchain network is accessed every 5 minutes.

[0085] Step S620: Transaction data accessed more than or equal to a first preset threshold number of accesses is identified as target transaction data. High-frequency hotkey data is determined based on the target transaction data and stored in a third-party caching component. The first preset threshold number of accesses is 1000.

[0086] Understandably, this application allows setting up relevant services in the blockchain explorer to report data such as the number of requests for querying transaction data to the monitoring platform. For example, if transaction data A is accessed 10 times within a period, it will be counted as 10 times on the monitoring platform. The monitoring platform is essentially a big data component responsible for summarizing data by time. By querying the number of times transaction data is accessed within a period (e.g., 5 minutes), if the number of accesses exceeds a first preset threshold (e.g., 1000 times), the transaction data is retrieved from the search engine and written to a third-party caching component. Subsequent data query requests for this transaction data will first be queried in the third-party caching component, thus directing subsequent traffic to the third-party caching component and preventing a large amount of query traffic from dragging down the overall performance of the search engine.

[0087] In this embodiment of the application, the transaction data of a transaction in the blockchain network includes multiple data, such as digital asset ID, issuer, link information, and hash. High-frequency hotkey data can be one or more of these multiple data.

[0088] For example, the target transaction data includes digital asset ID, issuer, link information, and hash. Determining high-frequency hotkey data based on the target transaction data includes identifying one or more of the digital asset ID, issuer, link information, and hash from the target transaction data as high-frequency hotkey data. In practical applications, this can be configured according to user needs, allowing selection of one type of data, several types of data, or all data to be designated as high-frequency hotkey data. This provides greater flexibility and makes queries more tailored to user requirements.

[0089] In some embodiments, the blockchain-based offline data query method of this application further includes: periodically detecting the validity of high-frequency hotkey data and obtaining detection results; if the detection results indicate that the high-frequency hotkey data is valid, extending the caching time of the high-frequency hotkey data in a third-party caching component; and if the detection results indicate that the high-frequency hotkey data is invalid, deleting the high-frequency hotkey data from the third-party caching component.

[0090] In this embodiment, to promptly clear storage space in the third-party caching component, the validity of high-frequency hotkey data can be periodically checked. If, within a detection period, the number of times previously stored high-frequency hotkey data is accessed is less than a first preset threshold, the high-frequency hotkey data is considered invalid, no longer considered high-frequency hotkey data, and is deleted. If, within a detection period, the number of times previously stored high-frequency hotkey data is accessed is still greater than or equal to the first preset threshold, the high-frequency hotkey data is considered valid, and the caching time of the high-frequency hotkey data is extended. In some embodiments, the extended caching time can be the duration of one detection period, for example, 5 minutes.

[0091] For example, combining Figure 7 As shown, Figure 7 This is another exemplary embodiment of the present application illustrating an application diagram of a blockchain-based offline data query method. Figure 7In this process, the parsing server 230 parses the latest transaction data in the blockchain network 100 and stores the parsed transaction data in the memory of the search engine 250. Simultaneously, the blockchain explorer 220 periodically checks the transaction data in the blockchain network 100, reporting the number of times the transaction data is accessed within a detection period to the monitoring platform 270. The monitoring platform 270 determines the number of times the transaction data is accessed; if the number of accesses is greater than or equal to a first preset threshold, the transaction data is identified as target transaction data. This target transaction data is then identified as high-frequency hotkey data, and a preheating service is used to retrieve this high-frequency hotkey data from the search engine 250, which is then written to the third-party caching component 240. Subsequent data query requests for this transaction data will first be queried in the third-party caching component 240, thus directing subsequent traffic to the third-party caching component 240 and preventing a large amount of query traffic from impacting the overall performance of the search engine 250.

[0092] It should be noted that the steps in this embodiment are consistent with the corresponding steps in the foregoing embodiments. Therefore, for a detailed description of these steps, please refer to the description in the foregoing embodiments. This embodiment will not repeat them here.

[0093] In another exemplary embodiment, such as Figure 8 As shown, the blockchain-based offline data query method in Figure 3 Based on the illustrated embodiment, steps S810 to S820 are also included, which are described in detail below:

[0094] Step S810: If the target data does not exist in the search engine, query the target data from the chain node.

[0095] It is understandable that when the transaction data corresponding to the data query request is directly queried through the chain node, if the transaction is a legitimate transaction, then the transaction data of that transaction must exist in the chain node.

[0096] Step S820 stores the data retrieved from the chain nodes into a third-party caching component and a search engine.

[0097] In this application, during blockchain queries, offline queries of on-chain data may be blocked due to various factors, making it difficult to write transaction data to the search engine and third-party storage components in a timely manner. Consequently, users may not be able to find transaction data when querying transactions. Therefore, in this embodiment, if the transaction data corresponding to the data query request cannot be found in either the third-party storage component or the search engine, the corresponding transaction data is obtained by directly querying the chain node. The retrieved data is then fed back to the user terminal, and the retrieved data is stored in the search engine and the third-party storage component.

[0098] For example, combining Figure 9 As shown, Figure 9 This is another exemplary embodiment of the present application illustrating an application diagram of a blockchain-based offline data query method. Figure 9 In this process, the parsing server 230 parses the latest transaction data in the blockchain network 100 and stores the parsed transaction data in the memory of the search engine 250. When the user terminal 210 performs offline data queries through the blockchain explorer 220, it first queries the third-party caching component 240. If the third-party caching component 240 does not find the transaction data corresponding to the data query request, it queries the search engine 250. If the search engine 250 also does not find the transaction data corresponding to the data query request, it is assumed that the offline query for on-chain data may be blocked, resulting in the transaction data not yet being written to the search engine and the third-party caching component, thus making it impossible to query the corresponding transaction data. Therefore, in this scenario, by directly querying the chain nodes in the blockchain network 100, after finding the transaction data in the chain node, the transaction data is fed back to the blockchain explorer 220, and then fed back to the user terminal 210 through the blockchain explorer 220; at the same time, the transaction data is written to the search engine 250 and the third-party caching component 240, which can avoid subsequent traffic for querying the transaction data being sent to the chain node.

[0099] Furthermore, in cases where the target data is not found in the search engine, after querying the target data from the chain node, the process further includes: setting the query status of the target data to the status of querying the chain node in a third-party caching component, and setting the query start time. In this embodiment, when querying data in the chain node, directly querying the chain node carries certain risks, potentially causing all traffic to be routed to the chain node. Therefore, by setting the query status of the target data in a third-party caching component after querying the target data in the chain node, subsequent queries for the same target data will be intercepted in the third-party caching component, preventing all requests from reaching the chain node. This avoids duplicate high-concurrency data query requests to the chain node, reducing chain node pressure and preventing blockchain block production anomalies. Simultaneously, setting the query start time facilitates subsequent judgment of the target data's query status, enabling the execution of processing operations matching the query status.

[0100] It should be noted that the steps in this embodiment are consistent with the corresponding steps in the foregoing embodiments. Therefore, for a detailed description of these steps, please refer to the description in the foregoing embodiments. This embodiment will not repeat them here.

[0101] In another exemplary embodiment, it is important to understand that directly querying chain nodes still carries risks. For example, if a batch of transaction data that does not exist in the search engine is queried simultaneously within a short period, it can overwhelm the blockchain query system, causing all traffic to be directed to the chain nodes, increasing their pressure, and potentially even crashing them, leading to abnormal block production in the blockchain. Therefore, to avoid repeated high-concurrency queries to chain nodes, a cached state can be used to prevent duplicate traffic from hitting the chain nodes.

[0102] like Figure 10 As shown, to avoid duplicate traffic hitting the chain nodes, the blockchain-based offline data query method... Figure 8 Based on the illustrated embodiment, steps S1010 to S1030 are also included, which are described in detail below:

[0103] Step S1010: If other user terminals are querying the target data, obtain the historical query start time of the target data.

[0104] It is understandable that the historical query start time for the target data is the most recent time that the target data was queried. Here, the current time refers to the time when the target data is being queried, i.e., the time when other user terminals are querying the target data.

[0105] Step S1020: Determine the query status of the target data based on the current time and the historical query start time.

[0106] In this embodiment of the application, the query status of the target data can be determined based on the current time and the historical query start time through the following process:

[0107] Step S1021: Obtain the time difference between the current time and the historical query start time;

[0108] Step S1022: If the time difference is greater than a preset time threshold and the number of times the third-party cache component is re-queried exceeds a second preset number threshold, then the query status is determined to be a query chain node failure; in some embodiments, the preset time threshold is 5s.

[0109] Step S1023: If the time difference is less than or equal to the preset time threshold and the target data does not exist in the third-party cache component, then the query status is confirmed as being in the query chain node.

[0110] In step S1024, if the time difference is less than or equal to the preset time threshold and the target data exists in the third-party caching component, then the query status is confirmed as a successful query chain node.

[0111] In some embodiments, if the query status is "in the query chain node," it is assumed that another user is currently requesting to query the target data, and the third-party cache component is queried again after a second preset time interval. The second preset time interval is 500ms.

[0112] In some embodiments, if the query status is "query chain node successful", it is considered that the previous data query request for the target data successfully retrieved the target data in the chain node. At this time, the target data is directly retrieved from the third-party caching component and fed back to the user terminal.

[0113] In some embodiments, if the query status indicates a failed query to a chain node, it is assumed that the previous data query request for that target data did not find the target data in the chain node. In this case, a preset query failure message is sent to the user terminal, and the historical query start time is updated to the current time. This allows for a more accurate determination of the target data's query status in subsequent queries. By updating the historical query start time to the current time, the query status can be determined more accurately based on the updated time, enabling the execution of appropriate processing operations and preventing subsequent requests from repeatedly querying the chain node, thus avoiding increased pressure on the chain node.

[0114] Step S1030: Perform processing operations that match the query status.

[0115] In this embodiment, after a data query request queries target data in the chain node, the query status and start time of the target data are simultaneously set in the third-party caching component. If the target data is found in the chain node, it is fed back to the user terminal and written to the third-party caching component and the search engine. This prevents subsequent data query requests from querying the chain node. If other query requests for the target data exist at this time, various situations may occur, such as the previous data query request still querying the chain node, the target data already being found, or the query failing. Therefore, by using the historical query start time of the target data, the current query status of the target data can be determined, and then processing operations matching the query status can be executed. Different query statuses correspond to different processing operations, which allows for more accurate and efficient data querying while avoiding the possibility of high-concurrency requests querying the chain node simultaneously, thus ensuring the security of the chain node.

[0116] By employing the blockchain-based offline data query method described in this application, the real-time performance of the blockchain browser can be optimized, addressing the real-time requirements of data under high concurrency and thus improving the user experience of the blockchain browser. This enables the blockchain browser to be both real-time and compatible with complex business logic, while ensuring the security of the blockchain browser system, laying a solid foundation for improving the blockchain's block generation speed. Ultimately, this enhances the overall product functionality and increases the product's competitiveness within the industry.

[0117] It should be noted that the steps in this embodiment are consistent with the corresponding steps in the foregoing embodiments. Therefore, for a detailed description of these steps, please refer to the description in the foregoing embodiments. This embodiment will not repeat them here.

[0118] Combination Figure 11 As shown, Figure 11 This is a structural diagram illustrating a blockchain-based offline data query device, as shown in an exemplary embodiment of this application. This offline data query device can be applied to... Figure 2 The implementation environment shown, for example, the offline data query device can be specifically configured as follows: Figure 2 The blockchain browser 220 is shown in the implementation environment. Of course, this offline data query device can also be applied to other exemplary implementation environments and specifically configured in the blockchain browser. This embodiment does not limit the implementation environment to which the device is applicable.

[0119] like Figure 11As shown, the exemplary offline data query device includes: a receiving module 1110, a first query module 1120, a second query module 1130, and a feedback module 1140. The receiving module 1110 is configured to receive data query requests from a user terminal; the first query module 1120 is configured to, in response to a data query request, query the target data corresponding to the data query request in a third-party caching component; the second query module 1130 is configured to, if the target data is not found in the third-party caching component, perform a data query in a search engine; and the feedback module 1140 is configured to return the queried target data to the user terminal.

[0120] In this exemplary offline data query device, the transaction data on the blockchain is parsed offline by a parsing server, and the parsed data is stored in a preset third-party caching component and a search engine. Upon receiving a data query request, the system first searches for data in the third-party caching component. If the data is found, it is directly returned; otherwise, the data is searched in the search engine. Because the data writing time of the third-party caching component is lower than the data refresh time of the search engine, the latest transaction data can be found in the third-party caching component and returned to the user before it is written to the search engine. This avoids the situation where the latest transaction data cannot be found for a period of time due to the search engine's refresh mechanism, thus improving the real-time performance of offline data queries.

[0121] In another exemplary embodiment, the blockchain query system further includes an operating platform for conducting preset digital asset trading activities and storing the resulting transaction data in the chain nodes of the blockchain network. The offline data query device also includes a storage module configured to, before querying the target data corresponding to the data query request in a third-party caching component, determine the transaction data corresponding to the preset digital asset trading activities as high-frequency hotkey data through the operating platform; and pre-store the high-frequency hotkey data in the third-party caching component before the operating platform conducts the preset digital asset trading activities.

[0122] In another exemplary embodiment, the storage module is further configured to delete high-frequency hotkey data from a third-party cache component after a preset digital asset transaction activity has ended.

[0123] In another exemplary embodiment, the storage module is further configured to, after responding to a data query request and querying the target data corresponding to the data query request in a third-party caching component, periodically obtain the number of times the transaction data in the blockchain network has been accessed; determine the transaction data whose access count is greater than or equal to a first preset threshold as the target transaction data; determine the high-frequency hotkey data based on the target transaction data; and store the high-frequency hotkey data in the third-party caching component.

[0124] In another exemplary embodiment, the storage module is further configured to periodically detect the validity of high-frequency hotkey data and obtain a detection result; if the detection result indicates that the high-frequency hotkey data is valid, extend the caching time of the high-frequency hotkey data in the third-party caching component; if the detection result indicates that the high-frequency hotkey data is invalid, delete the high-frequency hotkey data in the third-party caching component.

[0125] In another exemplary embodiment, the offline data query device further includes a third query module, which is configured to query the target data from the chain node when the target data does not exist in the search engine; and to store the data queried from the chain node in a third-party caching component and the search engine.

[0126] In another exemplary embodiment, the third query module is further configured to, if other user terminals query the target data, obtain the historical query start time of the target data; determine the query status of the target data based on the current time and the historical query start time; and execute a processing operation that matches the query status; wherein different query statuses correspond to different processing operations.

[0127] In another exemplary embodiment, the query status includes a query chain node failure status; the third query module is further configured to perform processing operations that match the query status in the following manner: if the query status is a query chain node failure status, then a preset query failure message is fed back to the user terminal, and the historical query start time is updated to the current time, so as to more accurately determine the query status of the target data in the next query.

[0128] In another exemplary embodiment, the third query module is further configured to determine the query status of the target data based on the current time and the historical query start time in the following manner: obtaining the time difference between the current time and the historical query start time; if the time difference is greater than a preset time threshold and the number of times the third-party cache component is re-queried exceeds a second preset number threshold, then determining the query status as query chain node failure; if the time difference is less than or equal to the preset time threshold and the target data is not present in the third-party cache component, then confirming the query status as query chain node success; if the time difference is less than or equal to the preset time threshold and the target data is present in the third-party cache component, then confirming the query status as query chain node success.

[0129] In another exemplary embodiment, the storage module is further configured to obtain an automatic deletion time period set for data stored in a third-party caching component; wherein the automatic deletion time period is the data refresh duration of the search engine; and to perform deletion processing on the data stored in the third-party caching component based on the automatic deletion time period.

[0130] It should be noted that the offline data query device provided in the above embodiments and the blockchain-based offline data query method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the offline data query device provided in the above embodiments 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. This is not a limitation.

[0131] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, enable the electronic device to implement the blockchain-based offline data query method provided in the above embodiments.

[0132] Figure 12 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 12 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0133] like Figure 12 As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1203. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. An Input / Output (I / O) interface 1205 is also connected to bus 1204.

[0134] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0135] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

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

[0137] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the blockchain-based offline data query method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0138] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based offline data query method provided in the various embodiments described above.

[0139] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

[0140] It is understood that in the specific implementation of this application, data related to digital asset transactions is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A blockchain-based offline data query method, characterized in that, The system is applied to a blockchain query system, which includes a blockchain network, a user terminal, a blockchain browser, a parsing server, a search engine, and a third-party caching component. The parsing server is used to perform offline parsing of transaction data on the blockchain and store the data obtained from the offline parsing in the third-party caching component and the search engine. The data writing time of the third-party caching component is shorter than the data refresh time of the search engine. The method is executed by the blockchain explorer, and the method includes: Receive data query requests from user terminals; In response to the data query request, the target data corresponding to the data query request is queried from the third-party caching component; If the target data is not present in the third-party caching component, then a data query is performed in the search engine; The retrieved target data will be returned to the user terminal.

2. The method according to claim 1, characterized in that, The blockchain query system also includes an operation platform, which is used to conduct preset digital asset trading activities and store the corresponding transaction data in the chain nodes included in the blockchain network. Before responding to the data query request and querying the target data corresponding to the data query request in the third-party caching component, the method further includes: The operation platform determines the transaction data corresponding to the preset digital asset trading activities as high-frequency hotkey data. Before conducting the preset digital asset trading activity on the operating platform, the high-frequency hotkey data is pre-stored in the third-party cache component.

3. The method according to claim 2, characterized in that, The method further includes: After the preset digital asset transaction activity ends, the high-frequency hotkey data is deleted from the third-party cache component.

4. The method according to claim 1, characterized in that, After responding to the data query request and querying the target data corresponding to the data query request in the third-party caching component, the method further includes: Periodically obtain the number of times transaction data in the blockchain network has been accessed; Transaction data whose access count is greater than or equal to a first preset threshold number is identified as target transaction data. High-frequency hotkey data is determined based on the target transaction data and stored in the third-party caching component.

5. The method according to claim 4, characterized in that, The method further includes: The validity of the high-frequency hotkey data is periodically checked to obtain the detection results; If the detection results indicate that the high-frequency hotkey data is valid, the caching time of the high-frequency hotkey data in the third-party caching component shall be extended. If the detection result indicates that the high-frequency hotkey data is invalid, the high-frequency hotkey data shall be deleted from the third-party caching component.

6. The method according to claim 1, characterized in that, The method further includes: If the target data does not exist in the search engine, the target data is queried from the chain node; The data retrieved from the chain nodes will be stored in the third-party caching component and the search engine.

7. The method according to claim 6, characterized in that, The method further includes: If other user terminals query the target data, obtain the historical query start time of the target data; The query status of the target data is determined based on the current time and the start time of the historical query. Perform processing operations that match the query state; where different query states correspond to different processing operations.

8. The method according to claim 7, characterized in that, The query status includes the query chain node failure status; The execution of processing operations matching the query status includes: If the query status is a query chain node failure status, a preset query failure message is fed back to the user terminal, and the historical query start time is updated to the current time, so as to more accurately determine the query status of the target data in the next query.

9. The method according to claim 7, characterized in that, Determining the query status of the target data based on the current time and the historical query start time includes: Obtain the time difference between the current time and the start time of the historical query; If the time difference is greater than a preset time threshold and the number of times the third-party cache component is re-queried exceeds a second preset number threshold, then the query status is determined to be a query chain node failure. If the time difference is less than or equal to the preset time threshold and the target data is not present in the third-party caching component, then the query status is confirmed as being in the query chain node. If the time difference is less than or equal to the preset time threshold, and the target data exists in the third-party caching component, then the query status is confirmed as a successful query chain node.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: Obtain the automatic deletion time period set for the data stored in the third-party caching component; wherein, the automatic deletion time period is the data refresh duration of the search engine; The data stored in the third-party caching component is deleted based on the automatic deletion time period.

11. A blockchain-based offline data query device, characterized in that, The system is applied to a blockchain query system, which includes a blockchain network, a user terminal, a blockchain browser, a parsing server, a search engine, and a third-party caching component. The parsing server is used to perform offline parsing of transaction data on the blockchain and store the data obtained from the offline parsing in the third-party caching component and the search engine. The data writing time of the third-party caching component is shorter than the data refresh time of the search engine. The device includes: The receiving module is configured to receive data query requests from user terminals; The first query module is configured to, in response to the data query request, query the target data corresponding to the data query request in the third-party caching component; The second query module is configured to perform a data query in the search engine if the target data is not found in the third-party caching component. The feedback module is configured to return the retrieved target data to the user terminal.

12. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the blockchain-based offline data query method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, It stores computer-readable instructions, which, when executed by the computer's processor, cause the computer to perform the blockchain-based offline data query method as described in any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the blockchain-based offline data query method as described in any one of claims 1 to 10.

Images