Data processing method, device and equipment and readable storage medium

Abstract

The invention discloses a data processing method and device, equipment and a readable storage medium, and the method comprises the steps: obtaining a historical block from a block chain data structure through at least one container node started by a block analysis service of a block chain browser; synchronously storing block data obtained by analyzing the historical block to a search engine database of the block chain browser through at least one container node; performing data integrity detection on the synchronized block data in the search engine database to obtain a detection result; determining abnormal to-be-repaired block data according to a detection result, and querying a target historical block associated with the to-be-repaired block data in the block chain data structure; and repairing the to-be-repaired block data based on the target historical block through the at least one container node. Therefore, the aging requirement of analysis and storage of the high-concurrency block data can be met, and the block data which fails to be stored can be automatically repaired, so that the query efficiency and accuracy of the block data can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a data processing method, apparatus, device, and readable storage medium. Background Technology

[0002] A blockchain is a data structure composed of several blocks linked together by hash values. Each block is generated by packaging operational data from interactions between an object and the blockchain system. Therefore, each block on the blockchain contains corresponding data, such as virtual resource transfers, a specific address, and the amount of virtual resources. While objects can use a blockchain explorer to directly view historical block data on the blockchain to understand the corresponding interactions, this method relies on the performance of the blockchain nodes and cannot guarantee query efficiency.

[0003] The relevant technology parses and stores the block data on the blockchain sequentially into a search engine database. Subsequently, the block data can be viewed from the search engine database offline, without relying on the performance of the blockchain node to query the block data on the blockchain, thus avoiding the impact of the blockchain node's performance on query efficiency.

[0004] In the process of researching and practicing related technologies, the inventors of this application discovered that the related technologies, by parsing and storing the block data on the blockchain sequentially into the search engine database, cannot meet the timeliness requirements of high-concurrency parsing and storage of block data, thus blocking the parsing and storage progress of block data on the blockchain. Furthermore, for block data that fails to be parsed and stored, it is impossible to recover it in real time and automatically, thereby affecting the efficiency and accuracy of the object's query for block data. Summary of the Invention

[0005] This application provides a data processing method, apparatus, device, and readable storage medium that can meet the timeliness requirements of high-concurrency parsing and storage of block data, as well as the real-time automatic repair of failed storage of block data, ensuring that blocks on the blockchain are correctly parsed and stored, and improving the query efficiency and accuracy of block data.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] This application provides a data processing method, including:

[0008] At least one container node is started through the block parsing service of a blockchain explorer to retrieve historical blocks from the blockchain data structure;

[0009] The block data parsed from the historical blocks will be synchronously stored in the search engine database of the blockchain explorer through the at least one container node;

[0010] Data integrity checks are performed on the synchronized block data in the search engine database to obtain the check results;

[0011] Based on the detection results, identify abnormal block data that needs to be repaired, and query the target historical block in the blockchain data structure that is associated with the block data that needs to be repaired;

[0012] The at least one container node performs repair processing on the data of the block to be repaired based on the target historical block.

[0013] Accordingly, embodiments of this application provide a data processing apparatus, including:

[0014] The acquisition unit is used to retrieve historical blocks from the blockchain data structure by starting at least one container node through the block parsing service of the blockchain explorer.

[0015] A storage unit is used to synchronously store the block data parsed from the historical blocks to the search engine database of the blockchain explorer through the at least one container node;

[0016] The detection unit is used to perform data integrity detection on the block data that has been synchronized in the search engine database and obtain the detection result;

[0017] The determining unit is used to determine the abnormal block data to be repaired based on the detection result, and to query the target historical block associated with the block data to be repaired in the blockchain data structure;

[0018] The repair unit is used to repair the data of the block to be repaired based on the target historical block through the at least one container node.

[0019] In some embodiments, the detection unit is further configured to:

[0020] When a block detection instruction triggered by a preset condition is detected, the starting block data to be detected is selected from the block data synchronized in the search engine database according to the block detection instruction.

[0021] Based on the initial block data, data integrity checks are performed on the block data that has been synchronized in the search engine database to obtain the check results.

[0022] In some embodiments, the detection unit is further configured to:

[0023] When the block detection instruction is a detection instruction triggered based on the restart request of the container node, the first normal block range is determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block;

[0024] The starting block data is block data that is synchronously stored in the search engine database based on the historical blocks at the current end of the blockchain data structure;

[0025] Starting with the initial block data, the data integrity of the synchronized block data in the search engine database is sequentially traversed and checked until a number of normal block data within the first normal block range are continuously detected, and the detection result is obtained.

[0026] In some embodiments, the detection unit is further configured to:

[0027] When the block detection instruction is a detection instruction triggered based on a preset timed detection task, the range of the second normal blocks is determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block.

[0028] According to the size of the second normal block range, the block data that has been synchronized in the search engine database is divided into multiple block intervals, wherein any block data in each block interval is used as the starting block data.

[0029] Based on the starting block data in each block interval, data integrity checks are performed on the block data in each block interval to obtain the check results.

[0030] In some embodiments, the detection unit is further configured to:

[0031] Data integrity checks are performed on the starting block data in each block interval to obtain the block check result corresponding to the starting block data in each block interval;

[0032] When at least one block detection result indicates that the corresponding starting block data is abnormal, the block interval to be repaired containing the abnormal starting block data is determined.

[0033] For each block interval to be repaired, taking the starting block data as the starting point, data integrity checks are performed on the block data before and after the starting block data in a cross-block interval manner, until normal block data of the second normal block range are continuously detected in both the forward and backward directions, and the detection result is obtained.

[0034] In some embodiments, the detection unit is further configured to:

[0035] For the starting block data in each block interval, obtain the forward adjacent candidate block data from the search engine database, and obtain the candidate hash value corresponding to the candidate block data from the candidate block data;

[0036] The comparison result is obtained by comparing the forward block hash value recorded in the corresponding starting block data with the candidate hash value;

[0037] When the comparison result shows that the forward block hash value is inconsistent with the candidate hash value, the block detection result of the starting block data is determined to be abnormal.

[0038] In some embodiments, the detection unit is further configured to:

[0039] When the comparison result shows that the forward block hash value is consistent with the candidate hash value, the number of records for historical interaction tasks in the block header corresponding to the starting block data is determined.

[0040] Obtain the actual number of historical interaction tasks contained in the block body corresponding to the starting block data;

[0041] When the number of records is inconsistent with the actual number of tasks, the block detection result of the starting block data is determined to be abnormal.

[0042] In some embodiments, the storage unit is further used for:

[0043] When a restart request is detected from at least one container node of the blockchain explorer, the restart waiting time is determined based on the current block generation speed of the blockchain data structure and the synchronization speed of the blockchain explorer for historical blocks.

[0044] The restart of the container node corresponding to the restart request is intercepted according to the restart waiting time, and the block data parsed from the historical blocks by the at least one container node is synchronously stored in the search engine database of the blockchain explorer.

[0045] In some embodiments, the storage unit is further used for:

[0046] Based on the block parsing service of the at least one container node, the historical blocks obtained are parsed to obtain block data according to a number of preset parsing indicators.

[0047] The parsed block data is synchronously stored in the search engine database of the blockchain explorer through the data synchronization channel in at least one container node.

[0048] In some embodiments, the data processing apparatus further includes a startup unit for:

[0049] Determine the number of historical blocks waiting to be synchronized in the blockchain data structure, and determine the current block generation speed of the blockchain data structure;

[0050] The number of container nodes to be started is determined based on the number of historical blocks and the current block generation rate.

[0051] Based on the number of container nodes launched, at least one container node is launched to support the block parsing service of the blockchain explorer.

[0052] In some embodiments, the repair unit is further configured to:

[0053] The target historical block is retrieved from the blockchain data structure through the query thread of at least one container node, and the target historical block is parsed to obtain the target block data.

[0054] The target block data is transmitted to the search engine database through the data repair channel of the at least one container node, so as to update the block data to be repaired in the search engine database according to the target block data.

[0055] Furthermore, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described data processing method.

[0056] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the above-described data processing method.

[0057] Furthermore, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium and executes the computer instructions to implement the aforementioned data processing method.

[0058] In this embodiment, at least one container node can be started through the block parsing service of a blockchain explorer to obtain historical blocks from the blockchain data structure; the block data parsed from the historical blocks can be synchronously stored in the search engine database of the blockchain explorer through at least one container node; data integrity checks can be performed on the synchronized block data in the search engine database to obtain the check results; based on the check results, abnormal block data to be repaired can be identified, and a target historical block associated with the block data to be repaired can be queried in the blockchain data structure; the block data to be repaired can be repaired based on the target historical block through at least one container node.

[0059] Based on this, when historical blocks in the blockchain data structure require real-time parsing and storage under high concurrency, this application can start at least one container node corresponding to the block parsing service of the blockchain explorer. Each container node can retrieve the corresponding historical blocks from the blockchain data structure and synchronize the retrieved historical blocks to the search engine database. In this way, the high-concurrency parsing and storage requirements of historical blocks can be met through at least one container node. Then, by performing data integrity checks on the synchronized block data in the search engine database, missing block data, i.e., abnormal block data to be repaired, is identified. Finally, the abnormal block data to be repaired in the search engine database is repaired according to the corresponding target historical block to ensure that every historical block on the blockchain is successfully parsed and stored.

[0060] Therefore, compared to existing technologies that parse and store blockchain block data sequentially into a search engine database, this application operates the blockchain explorer's block parsing service using a container node management approach. This ensures that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. Furthermore, real-time data integrity checks can be performed on the parsed and stored block data in the blockchain explorer's search engine database to detect any anomalies in the synchronized block data and repair any anomalies. This allows for real-time automatic repair of failed-to-store block data, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, thus improving the efficiency and accuracy of block data queries.

[0061] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application.

[0064] Figure 2 This is a flowchart illustrating the steps of the data processing method provided in the embodiments of this application;

[0065] Figure 3 This is another step of the data processing method provided in the embodiments of this application;

[0066] Figure 4 This is an example diagram showing how to directly query data on the blockchain using a blockchain explorer;

[0067] Figure 5 Example diagram of a data processing scenario provided in the embodiments of this application;

[0068] Figure 6 Example diagram of the parsing and storage scenario of the original block provided in the embodiments of this application;

[0069] Figure 7 A flowchart illustrating the restart process of the container node for the block resolution service provided in this application embodiment;

[0070] Figure 8 A flowchart of block data detection provided in this application embodiment;

[0071] Figure 9 Example diagram of the block header structure provided in the embodiments of this application;

[0072] Figure 10 A flowchart of block data detection provided in this application embodiment;

[0073] Figure 11 This is an example diagram illustrating a block data detection scenario triggered by a container node restart request, as provided in an embodiment of this application.

[0074] Figure 12 Example diagram of a repair scenario for a problematic block provided in the embodiments of this application;

[0075] Figure 13 This is a schematic diagram of the structure of the data processing apparatus provided in the embodiments of this application;

[0076] Figure 14 This is a schematic diagram of the terminal structure provided in the embodiments of this application;

[0077] Figure 15 This is a schematic diagram of the server structure provided in an embodiment of this application. Detailed Implementation

[0078] To enable those skilled in the art to better understand the solutions of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0079] It is understood that in the specific implementation of this application, data related to historical blocks, block data, block data to be repaired, target block data, etc. are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the subject is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0080] Furthermore, when this application embodiment needs to obtain relevant data such as historical blocks, block data, block data to be repaired, and target block data, it will obtain separate permission or separate consent for the relevant data such as historical blocks, block data, block data to be repaired, and target block data through pop-up windows or redirection to a confirmation page. After clearly obtaining separate permission or separate consent for the relevant data such as historical blocks, block data, block data to be repaired, and target block data, it will then obtain the necessary relevant data such as historical blocks, block data, block data to be repaired, and target block data for the normal operation of this application embodiment.

[0081] It should be noted that while some processes described in the specification, claims, and accompanying drawings contain multiple steps that appear in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not represent any particular order of execution. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0082] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0083] The data processing method provided in this application can be applied to the blockchain field. The blockchain is described below:

[0084] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information from a batch of network interaction tasks used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0085] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0086] Blockchain: A data structure consisting of several blocks linked together by hash values. Each block consists of pending tasks generated within a certain period of time, packaged by computer nodes that have the right to record transactions, and independently verified by each computer node.

[0087] A blockchain explorer is a tool used to view information such as historical tasks (interaction tasks, interaction requests, etc.), addresses, and blocks on a blockchain. It allows objects to directly access and explore the blockchain network, providing a more intuitive and transparent way to access blockchain data. Through a blockchain explorer, objects can track the status of task interactions in real time, confirm whether an interaction was successful, view the amount of virtual assets at a specific address, and view historical interaction tasks / requests.

[0088] A blockchain explorer works by sending a query request to the blockchain network. The explorer then parses the returned block data and presents it to the user in an easy-to-understand manner. This block data typically includes information such as block height, block hash, interaction details, and the amount of virtual assets on the resource storage address. Blockchain explorers are valuable to developers, researchers, and 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 users can use them to view the status of their interactive tasks and virtual assets.

[0089] Elasticsearch (ES) is a search and analytics engine based on the full-text search engine Lucene. It provides distributed, multi-tenant capabilities and is also a distributed real-time analytics search engine. Elasticsearch's underlying storage uses the Lucene framework, utilizing a tokenizer to break down text data into words or phrases and storing them according to an inverted index for efficient retrieval. Elasticsearch is not only used for searching various documents but is also widely applied in business scenarios requiring massive data storage, retrieval, and analysis. Its 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. Specifically, raw blockchain blocks can be stored in ES in a way that is easier for users to understand. This allows for offline querying of on-chain data, enabling users to query block data from ES more quickly and conveniently.

[0090] A container node (Pod) is the foundation of all business types in a Kubernetes (K8s) container orchestration engine cluster and the smallest unit managed by K8s. A Pod is a combination of one or more containers that share storage, network, namespaces, and a set of rules for how they run. Within a Pod, all containers are uniformly arranged and scheduled, running on shared system resources (such as CPU and memory). For a specific application, a Pod is its logical host, containing multiple application containers related to its business logic.

[0091] This application provides a data processing method, apparatus, device, and readable storage medium. Specifically, this application will describe the data processing apparatus from the perspective of the data processing apparatus. This data processing apparatus can be integrated into a computer device, which can be a server or a terminal device, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server 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, CDN, and big data and artificial intelligence platforms. The terminal device can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, smart home appliance, vehicle terminal, smart voice interaction device, aircraft, etc., but is not limited to these.

[0092] This application provides a data processing method that can be applied to any blockchain node in a blockchain system. Specifically, the blockchain network system can consist of multiple blockchain nodes, which are consensus nodes and are referred to as "computer devices" in this application, such as servers or terminals. The blockchain explorer's block parsing service can be run according to the management method of container nodes to ensure that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. Simultaneously, for the block data already parsed and stored in the blockchain explorer's search engine database, real-time data integrity checks can be performed to detect whether there are any anomalies in the synchronized block data, and to repair any anomaly-caused block data. In this way, failed-to-store block data can be automatically repaired in real time, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, improving the efficiency and accuracy of block data queries. This is specifically illustrated through the following embodiments:

[0093] Related technologies parse and store blockchain block data sequentially in a search engine database. This allows for offline querying of block data from this database, eliminating reliance on blockchain node performance and thus avoiding the impact of node performance on query efficiency. However, this approach fails to meet the demands of high-concurrency parsing and timely storage of blockchain data, hindering the parsing and storage progress. Furthermore, it cannot automatically recover failed blocks from parsing, impacting the efficiency and accuracy of queries targeting specific blocks.

[0094] To address the aforementioned issues, this application proposes a data processing method that runs the blockchain explorer's block parsing service according to the management method of container nodes. This ensures that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. Simultaneously, real-time data integrity checks can be performed on the block data already parsed and stored in the blockchain explorer's search engine database to detect any anomalies in the synchronized block data and repair any anomaly-stricken blocks. This allows for real-time automatic repair of failed-to-store block data, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, thus improving the efficiency and accuracy of block data queries. Please refer to the following specific embodiments for details.

[0095] This application provides a data processing system. The devices in this system may include a server and / or a terminal. The terminal may request the server to execute the data processing method of this application.

[0096] For example, the system includes a server or terminal. The terminal or server can start at least one container node through the block parsing service of the blockchain explorer to obtain historical blocks from the blockchain data structure. The block data parsed from the historical blocks is synchronously stored in the search engine database of the blockchain explorer through at least one container node. Data integrity is checked on the synchronized block data in the search engine database to obtain the detection results. Based on the detection results, abnormal block data to be repaired is identified, and the target historical block associated with the block data to be repaired is queried in the blockchain data structure. The block data to be repaired is repaired based on the target historical block through at least one container node.

[0097] For example, see Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application. The system includes a terminal 110 and a server 120.

[0098] The terminal 110 can send data processing requests to the server 120; in addition, a client can be installed on the terminal 110, which can send data processing requests to the server.

[0099] The server 120 can be a distributed blockchain system composed of multiple physical machines, with each physical machine corresponding to a blockchain node. Upon receiving a data processing request, the server 120 can execute the following steps of the data processing method: It can retrieve historical blocks from the blockchain data structure through at least one container node started by the blockchain explorer's block parsing service; synchronize the block data parsed from the historical blocks to the blockchain explorer's search engine database through at least one container node; perform data integrity checks on the synchronized block data in the search engine database to obtain the check results; determine the abnormal block data to be repaired based on the check results, and query the target historical block associated with the block data to be repaired in the blockchain data structure; and perform repair processing on the block data to be repaired based on the target historical block through at least one container node. Afterwards, the server 120 will transmit the above data processing results, including but not limited to which blocks were parsed and synchronized, and which blocks were repaired.

[0100] Based on the above, this application can run the blockchain explorer's block parsing service according to the management method of container nodes, ensuring that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. At the same time, for the block data already parsed and stored in the blockchain explorer's search engine database, real-time data integrity detection can be performed to detect whether there are any anomalies in the synchronized block data, and repair the anomaly-caused block data. In this way, the storage failure of block data can be automatically repaired in real time, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, improving the efficiency and accuracy of querying block data.

[0101] It should be noted that the above are just examples and can be applied to other data processing scenarios, which will not be elaborated here.

[0102] For ease of understanding, each step of the data processing method will be described in detail below. It should be noted that the order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0103] In this embodiment, the description will focus on the data processing device, which can be specifically integrated into a computer device, such as a terminal or server. See also Figure 2 , Figure 2 This is a flowchart illustrating the steps of the data processing method provided in this application embodiment. Taking the data processing device specifically integrated on a server as an example, the specific process when the processor on the server executes the program instructions corresponding to the data processing method is as follows:

[0104] 101. At least one container node started through the block parsing service of a blockchain explorer retrieves historical blocks from the blockchain data structure.

[0105] A blockchain is a data structure composed of interconnected blocks, each block consisting of a package of pending tasks generated within a certain period. A blockchain system comprises multiple blockchain nodes, each of which can be a computer device such as a server or terminal. Blockchain nodes can receive task and event requests from any object, broadcast these requests among all blockchain nodes, and store them in a task pool. These requests are then selected and processed by the blockchain nodes to generate blocks. This task pool can be located on the receiving blockchain node or on other specific blockchain nodes within the system. Blockchain nodes can be understood as witness nodes; multiple nodes jointly participate in consensus authentication of tasks or events within the blockchain network, ensuring the secure and reliable execution of submitted tasks or events in a decentralized manner, thus guaranteeing data security.

[0106] Task requesters, blockchain users, or other entities can act as queryers of blockchain data to retrieve relevant data from historical blocks on the blockchain. However, the original blocks on the blockchain are generally raw data, such as key-value pairs, which may make it difficult for users to directly understand this raw data.

[0107] It's important to note that a blockchain explorer, as a tool that allows users to view historical tasks, resource storage addresses, and historical blocks on a blockchain, can also be understood as a query service for blockchain data. It provides a more intuitive and transparent way to access blockchain data. When a user sends a query request to a blockchain explorer, the explorer can retrieve the corresponding historical blocks from the blockchain nodes—that is, query the original blocks stored in the blockchain data structure—and parse those original blocks to present them to the user in an easily understandable way. Therefore, using a blockchain explorer to query block data on the blockchain can avoid the confusion caused by a lack of understanding.

[0108] However, related technologies parse and store blockchain block data sequentially into the blockchain explorer's search engine database, allowing for offline querying of block data without relying on the performance of blockchain nodes. However, this method cannot meet the high-concurrency parsing and storage timeliness requirements of blockchain data, hindering the parsing and storage progress. Furthermore, it cannot automatically recover failed blocks from parsing and storage failures, thus impacting the efficiency and accuracy of querying blockchain data.

[0109] In this embodiment, the performance of the blockchain explorer's block parsing service is expanded by adding or removing container nodes to ensure that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. At the same time, for the block data already parsed and stored in the blockchain explorer's search engine database, data integrity checks are also performed to detect whether there are any anomalies in the synchronized block data, and the abnormal block data is repaired. In this way, the storage failure of block data can be automatically repaired in real time, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, thereby improving the efficiency and accuracy of querying block data.

[0110] In this embodiment, the block parsing service can be understood as a data analysis service for original blocks on the blockchain. It can be considered a service process or application service that converts the original data of the block into data of a target type and format according to a specific data type or expression form. For example, it converts the original data of the block into a data form that is easy for users to understand, such as text, images, or other forms of description. This enables the analysis of the original data of historical blocks on the blockchain. Subsequently, the analyzed block data is synchronously stored in other storage spaces. For example, a blockchain explorer can associate with the database of a search engine (ES). Through the blockchain explorer's block parsing service, it can query the original block from the blockchain data structure and parse the original block to obtain the corresponding block data, storing the block data in the search engine database for subsequent offline retrieval of the block data.

[0111] Here, a container node refers to the smallest scheduling unit in a Container Orchestration System (Kubernetes) cluster, which can contain multiple application-specific sub-containers. In this embodiment, the block resolution service can be supported by container nodes in the Kubernetes cluster. As the smallest scheduling unit of Kubernetes, the number of container nodes can be flexibly increased or decreased to achieve scaling and expansion of the block resolution service, thereby enabling performance control and ensuring reliability of the block resolution service.

[0112] In this embodiment, to address the high-concurrency parsing requirements of historical blocks in the blockchain data structure, the processing capacity of the block parsing service can be managed using a container node management approach. It should be noted that each container node contains one or more application-specific sub-containers, which can be understood as sub-containers for the block parsing service. Specifically, by increasing the number of container nodes, the processing capacity of the block parsing service is improved, thereby handling the high-concurrency parsing requirements of a large number of original blocks. On the other hand, when the number of original blocks requiring parsing is relatively small, the processing capacity of the block parsing service can be reduced by decreasing the number of container nodes. This approach aims to conserve computing resources while meeting the parsing requirements of a small number of historical blocks, ensuring reliability.

[0113] The blockchain data structure refers to a data structure composed of multiple historical blocks linked together, which will not be elaborated upon here. The historical blocks are the original blocks that have been uploaded to the blockchain from previous historical times. They are generated by blockchain nodes packaging relevant data from interactive tasks, and added to the end of the blockchain data structure after consensus verification among the blockchain nodes. Each block records the execution results of one or more interactive tasks, the amount of virtual resources transferred, the virtual resource storage address of related objects, the quantity of virtual assets, etc.

[0114] In this embodiment, to improve the efficiency of querying block data, a blockchain explorer parses historical blocks on the blockchain data structure into easily understandable block data and stores it in the blockchain explorer's search engine database. Subsequently, the easily understandable block data can be directly queried from the search engine database offline, thus eliminating reliance on the performance of blockchain nodes. Furthermore, this block data may not be the original block data. Further, to address the high concurrency of parsing and storing historical blocks on the blockchain data structure in the blockchain explorer's search engine database, multiple container nodes can be started to support the block parsing service. Each container node supporting the block parsing service sequentially retrieves historical blocks from the blockchain data structure for subsequent parsing and storage. This ensures that the search engine database contains the corresponding block data, supporting the block data query service and improving query efficiency.

[0115] It should be noted that during the process of retrieving historical blocks from the blockchain data structure, each container node can concurrently retrieve one or more historical blocks. Specifically, each container node can contain an application-based target sub-container for block parsing services. This target sub-container can have multiple query threads and multiple storage threads connected through a data synchronization channel. These query threads can concurrently and independently query the corresponding historical blocks from the blockchain data structure; for example, each query thread can independently retrieve the corresponding historical block from the blockchain data structure. This improves the efficiency of historical block querying and retrieval, thereby improving the efficiency of historical block parsing and processing.

[0116] In some implementations, to address the timeliness requirements of processing a small number or a large number of historical blocks on the blockchain data structure, the performance of the blockchain explorer's block parsing service can be scaled based on the number of container nodes. For example, before step 101, the process may include: determining the number of historical blocks waiting to be synchronized in the blockchain data structure, and determining the current block generation rate of the blockchain data structure; determining the number of container nodes to start based on the number of historical blocks and the current block generation rate; and starting at least one container node to support the blockchain explorer's block parsing service based on the number of container nodes to start.

[0117] The historical block count refers to the number of unsynchronized original blocks on the blockchain data structure. It's important to note that, to enable users to quickly retrieve easily understandable block data, original blocks added to the blockchain at a specific historical time can be parsed and synchronously stored in the database of the blockchain explorer's search engine. To avoid congestion during the parsing and storage of original blocks on the blockchain data structure, the number of original blocks currently requiring parsing and synchronization can be determined. This number can then be used to control the number of container nodes started, thereby reasonably controlling the performance of the block parsing service.

[0118] The block generation speed can be the real-time block production speed on the blockchain, which can be understood as the growth rate of the number of blocks on the blockchain, such as how many blocks per second, how many blocks per hour, or how many blocks per day, etc., which can be determined according to the actual situation.

[0119] It should be noted that the computer equipment (such as a server) in this application embodiment can increase or decrease the number of container nodes used to support the block parsing service of the blockchain explorer in real time, thereby scaling up the performance of the block parsing service. Based on this, the real-time number of container nodes corresponding to the block parsing service can be determined according to the number of historical blocks that need to be synchronized on the blockchain data structure.

[0120] Specifically, the computer device can obtain the number of historical blocks awaiting parsing and synchronization in the blockchain data structure from any blockchain node in the blockchain system, and also calculate the current block generation rate in the blockchain data structure. Further, it determines the number of container nodes to start. Specifically, it obtains the allowed lag time, determines the number of blocks to grow based on the lag time and the block generation rate, determines the expected total number of historical blocks to be processed within the lag time based on the number of blocks to grow and the number of historical blocks, evaluates the expected block processing speed based on the expected total number of historical blocks and the lag time, and evaluates the number of container nodes to start based on the expected block processing speed and the maximum processing speed of each container node. Finally, according to the number of container nodes to start, at least one container node is started to support the block parsing service of the blockchain explorer. Subsequently, based on the real-time running container nodes, the block parsing service is run to parse and synchronize the original blocks on the blockchain data structure to the blockchain explorer's search engine database on this computer device or the corresponding device, thus addressing the timeliness requirements for processing a small or large number of historical blocks on the blockchain data structure, ensuring reliability.

[0121] By combining the above methods with container orchestration system technology, the performance of the blockchain explorer's block parsing service can be scaled by adding or removing container nodes to cope with the high-concurrency processing requirements of historical blocks on the blockchain data structure. Furthermore, the container nodes started based on the block parsing service can obtain historical blocks from the blockchain data structure to ensure that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks, effectively avoiding the blocking of parsing and storing the original historical blocks, and ensuring reliability.

[0122] 102. Block data parsed from historical blocks is synchronously stored in the blockchain explorer's search engine database through at least one container node.

[0123] In this embodiment, after the container node corresponding to the block parsing service obtains historical blocks from the blockchain data structure, it can process the historical blocks. For example, in order to ensure that the block data retrieved later is not the original data of the block, the obtained historical blocks can be parsed. Specifically, the historical blocks can be parsed according to the set content requirements, or one or more personalized content indicators can be customized for the queryer to parse the historical blocks. Then, the parsed block data is stored in the search engine database of the blockchain explorer to support subsequent fast querying of easy-to-understand block data, which is reliable.

[0124] The block data can be parsed data, which may include various related data, such as the original historical blocks, the corresponding block identifier after parsing, the number of task requests (interactive tasks), task results, resource storage addresses, the number of virtual resources, etc., without limitation here.

[0125] The search engine database can be a database used to support blockchain explorers in quickly querying block data. This database stores parsed block data. It can be a full-text search engine (ES) database, supporting data queries by the blockchain explorer. The parsed block data can be stored in a way that is easy to search and query. For example, the parsed block data may include the original historical blocks, the corresponding parsed block identifiers, the number of task requests (interactive tasks), task results, resource storage addresses, and the number of virtual resources requested by the requester. This data can be stored in text format; for instance, it can combine text, numbers, and images to generate a text description of the relevant historical blocks, explaining them in natural language so that users can understand and interpret the data, ensuring its reliability.

[0126] In this embodiment, during the process of parsing and synchronously storing historical blocks in the search engine database, the block parsing service may experience dynamic adjustments. Specifically, the container nodes supporting the block parsing service may need to be restarted. For example, if a container node experiences a runtime error or requires a version upgrade, it needs to be destroyed and restarted. This can lead to failures in the historical block parsing and storage process, potentially causing data anomalies in the block data synchronously stored in the search engine database, such as data loss or missing data. To prevent data loss or missing data, when a container node needs to be restarted, the restart of the corresponding container node can be intercepted. The restart can proceed only after the relevant container node has completely parsed and synchronously stored the currently acquired historical blocks in the search engine database, thus improving the accuracy of the parsed block data.

[0127] In some implementations, a restart waiting time can be determined based on the relationship between the block generation rate and the synchronization rate of the blockchain explorer for historical blocks before restarting a container node. During this restart waiting time, block data parsed from historical blocks by at least one container node is synchronously stored in the blockchain explorer's search engine database. For example, step 102 may include:

[0128] (102.1) When at least one container node of the blockchain explorer is detected to issue a restart request, the restart waiting time is determined based on the current block generation speed of the blockchain data structure and the synchronization speed of the blockchain explorer for historical blocks.

[0129] (102.2) Intercept the restart of the container node corresponding to the restart request according to the restart waiting time, and synchronize the block data parsed from the historical blocks by at least one container node to the search engine database of the blockchain explorer.

[0130] The block generation speed can be the real-time block production speed on the blockchain, which can be understood as the growth rate of the number of blocks on the blockchain, such as how many blocks per second, how many blocks per hour, or how many blocks per day.

[0131] The synchronization speed can be the processing speed of the block parsing service for historical blocks. Specifically, it can be the speed at which the blocks are parsed and stored in the database. It can be the number of blocks processed per second, the number of blocks processed per hour, etc., which can be determined according to the actual situation and is not limited here.

[0132] The restart wait time can be the duration during which a container node waits when a restart is required. Specifically, this time can start from the moment a restart request is detected and continue until the actual restart. This restart wait time can be configured according to actual needs. It's understood that to ensure historical blocks obtained from the container node are completely parsed and synchronously stored in the database, the container node needs to continue running during this period. Therefore, the restart wait time is used to intercept the container node's restart and wait for it to resume operation. Furthermore, this restart wait time can be a pre-set wait time, such as 30 seconds or 1 minute; no specific limitation is made here.

[0133] Specifically, as the smallest scheduling unit for the block parsing service, the container node can determine the restart waiting time based on the block generation speed and the synchronization speed of the blockchain explorer for historical blocks before one or more container nodes of the block parsing service are restarted.

[0134] For example, in high-concurrency parsing and storage scenarios of historical blocks, a balance between the growth rate and synchronization rate of historical blocks can be considered. This ensures that, given the performance of the block parsing service supported by the current container nodes, the synchronization rate of historical blocks is greater than or equal to the growth rate of historical blocks (i.e., the parsing processing speed is greater than or equal to the blockchain's block generation speed). This ensures that the number of historical blocks requiring processing does not continue to grow positively before the container node can be restarted. For instance, based on the current block generation speed and the current number of historical blocks requiring parsing, it can be estimated how long it will take for the number of historical blocks waiting to be parsed on the blockchain data structure to begin to decline (i.e., how long it will take for the number of historical blocks requiring synchronization to gradually decrease). Based on this, the waiting time required when the synchronization rate of historical blocks is greater than or equal to the growth rate of historical blocks can be estimated.

[0135] For example, the number of historical blocks currently acquired in the container node can be obtained. Based on the number of historical blocks acquired and the maximum historical time taken for the container node to parse and synchronize a historical block, the estimated processing time for parsing and synchronizing all the historical blocks currently acquired in the container node and storing them in the search engine database can be calculated. This estimated processing time can then be used as the restart waiting time.

[0136] For example, a new container node can be started to replace the container node that needs to be restarted, and the startup time of the new container node can be used as the restart waiting time for the container node that needs to be restarted.

[0137] Based on the above, the restart waiting time can be determined in the above manner. Specifically, the maximum waiting time determined in the above manner can be used as the restart waiting time, or a constant can be added to the determined restart waiting time to serve as the final restart waiting time. This ensures that the container node can wait for a sufficient amount of time, avoiding problems such as loss or anomalies of the block data being processed due to premature restart of the container node, and improving the integrity and accuracy of the block data.

[0138] Furthermore, after determining the restart waiting time for the container node that needs to be restarted, the restart request for the container node can be intercepted according to the restart waiting time. This prevents the container node from immediately restarting. Further, the block data parsed from historical blocks is synchronized and stored in the blockchain explorer's search engine database through the container node corresponding to the block resolution service. It should be noted that after the restart waiting time expires, the restart of the container node that issued the restart request is performed. This restart process may involve destroying the current container node and restarting a new container node to replace the destroyed one. This avoids issues such as missing or lost block data, ensuring the security, accuracy, and integrity of the block data.

[0139] In some implementations, multi-dimensional block data parsed from historical blocks can be synchronously stored in the search engine database of the blockchain explorer. For example, step (102.2) may include: parsing historical blocks obtained from each of the at least one container node's block parsing service according to a set of preset parsing indicators to obtain block data; and synchronously storing the parsed block data to the search engine database of the blockchain explorer through a data synchronization channel in at least one container node.

[0140] These multiple parsing metrics can be pre-defined block content metrics, including but not limited to interactive task identifiers, task quantity, virtual asset quantity, virtual asset storage address, task processing result, and common attributes of objects associated with the task recorded in the original historical blocks. These parsing metrics can be pre-defined by the block parsing service during development, and one or more parsing metrics can be added or deleted in a customized manner later, without limitation here.

[0141] Specifically, each container node contains at least one target sub-container for running application-based block parsing services. After each container node obtains historical blocks from the blockchain data structure through a query thread, it can parse and process the obtained historical blocks according to multiple preset parsing indicators to obtain block data corresponding to multiple parsing indicators. Each parsing indicator corresponds to a piece of data content; for example, detailed data corresponding to the task processing result, detailed data corresponding to the common attributes of the objects associated with the task, etc. The block data obtained by parsing can be described and represented using natural language to ensure that the parsed block data can be understood by the queryer and has reliability.

[0142] Furthermore, after parsing historical blocks to obtain block data, the parsed block data can be transmitted to the storage thread via a data synchronization channel connecting the query thread and the storage thread. The storage thread then synchronously stores the parsed block data in the blockchain explorer's search engine database. It should be noted that this data synchronization channel can be used for the transmission of block data between multiple concurrent threads, thus meeting the timeliness requirements for concurrent parsing and storage of multiple original historical blocks, and ensuring reliability.

[0143] Using the above methods, historical blocks can be parsed in a multi-dimensional manner to obtain block data. This allows historical blocks on the blockchain to be parsed into multi-dimensional, non-raw data that is easy for objects to understand, and the block data is stored in the blockchain explorer's search engine database to support subsequent fast queries of easily understandable block data and improve data query efficiency.

[0144] 103. Perform data integrity checks on the synchronized block data in the search engine database and obtain the check results.

[0145] In this embodiment of the application, after parsing and synchronizing historical block data into the search engine database of the blockchain explorer, in order to ensure the normality, integrity and accuracy of the synchronized block data in the search engine database, the synchronized block data in the search engine database can be detected to check whether there are synchronization anomalies in these block data. Specifically, the integrity of the data can be determined based on the content of the block data, thereby further determining whether the block data is synchronized abnormally, and obtaining the detection results. In order to subsequently filter out the abnormal block data according to the detection results and perform data repair.

[0146] The data integrity check can be understood as checking whether the content of the synchronized block data is complete relative to the content of the original historical block records. Specifically, the data integrity check can be performed from one or more aspects.

[0147] For example, regarding original historical blocks, whether the search engine database has already parsed and stored the corresponding block data can be determined by directly querying the search engine database based on the block identifier to check for the existence of the corresponding historical block data and thus verify data integrity. Furthermore, data loss, missing data, errors, and other incompleteness will cause changes in the block's hash value. Using each historical block as a unit, check whether the hash of the adjacent previous block data matches the hash of the previous block recorded in the subsequent block data. The hash value can be used to verify the integrity of the block data. Finally, since the information recorded in the block header corresponds to the actual content contained in the block body, for example, by checking whether the number of tasks recorded in the block header corresponds to the actual interactive tasks (interaction requests or task requests) contained in the block body, the integrity of each block's data can be verified. The above are only examples of some detection methods and are not intended as specific limitations.

[0148] It should be noted that the detection of block data can be triggered by restart requests from container nodes in scenarios such as version upgrades, anomalies, or idle periods, or by scheduled detection tasks; there is no limitation here. To trigger the detection of block data synchronized in the search engine database, preset conditions can be set in advance. For example, preset conditions could be "a restart request or need for a container node has been detected," or "the current time condition (interval duration, time information) has reached the trigger time of the scheduled detection task," and so on.

[0149] In this embodiment, to improve the detection efficiency of synchronized block data in the search engine database, a portion of the block data in the search engine database can be detected. For example, a selection of blocks can be used for detection, or a random sampling of the block data in the search engine database can be performed. It is understood that for any detection method, a starting point needs to be selected to begin detecting the block data in the search engine database. It should be noted that different detection methods use different starting points for the selected block data. By employing these detection methods, the amount of data to be checked in the search engine database can be minimized, thereby improving the detection efficiency of the block data.

[0150] In some implementations, starting block data can be selected from the search engine database based on the triggering conditions of the triggered block detection command, and the detection of block data in the search engine database can begin using the starting block data as the basis for detection. For example, step 103 may include:

[0151] (103.1) When a block detection instruction triggered by a preset condition is detected, the starting block data to be detected is selected from the block data synchronized in the search engine database according to the block detection instruction.

[0152] (103.2) Based on the initial block data, perform data integrity checks on the synchronized block data in the search engine database and obtain the check results.

[0153] The block detection instruction can be an instruction used to instruct related services or programs to perform block data detection operations. Specifically, when a computer device detects any triggering condition that triggers block data detection, it will generate a block detection instruction corresponding to that triggering condition. Different triggering conditions correspond to different triggering scenarios or triggering methods. Therefore, the block detection instructions under different triggering conditions are also different. For example, the detection method identifier carried by the block detection instruction is different, indicating the corresponding triggering condition.

[0154] The starting block data can be any block data in the search engine database, such as the block data currently located at the end of the search engine database, or block data in other locations. Specifically, the starting block data can be selected according to the corresponding triggering conditions of the block detection instruction.

[0155] Specifically, the computer equipment can monitor the status and time information of the block resolution service in real time. When the restart of the container node corresponding to the block resolution service is used as a trigger condition, or when the time information reaches the trigger condition of the scheduled detection task, the block data in the search engine database is detected. At this time, a block detection instruction is generated according to the trigger condition. This block detection instruction carries an identifier representing the trigger condition, so that different block data detection methods can be selected according to different trigger conditions. It should be noted that the starting block data is determined differently under different block data inspection methods.

[0156] Furthermore, based on the trigger condition identifier carried in the block detection command, the trigger type is determined to select a starting block data to be detected from the synchronized block data in the search engine database. Further, using this starting block data as the detection starting point, data integrity checks are performed on the synchronized block data in the search engine database; alternatively, based on the detection results of the starting block data, a decision is made to perform data integrity checks on the synchronized block data in the search engine database, obtaining the detection result. In this way, the appropriate starting block data is selected according to different trigger conditions of the block detection command, and data integrity checks are performed on the synchronized block data in the search engine database based on this starting block data, thereby improving detection efficiency by reducing the amount of block data to be detected.

[0157] In some implementations, when a block detection command is triggered by a container node restart request, data integrity checks are performed on each block starting from the last block in the search engine database until a target number of normal blocks are detected consecutively, thus obtaining the detection result. For example, step (103.2) may include:

[0158] (103.2.a.1) When the block detection instruction is a detection instruction triggered by the restart request of the container node, the first normal block range is determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block; wherein, the starting block data is the block data that is synchronously stored in the search engine database according to the historical blocks at the current end of the blockchain data structure.

[0159] (103.2.a.2) Starting from the initial block data, perform a sequential traversal check on the synchronized block data in the search engine database to check the data integrity until a number of normal blocks within the first normal block range are detected, and obtain the detection result.

[0160] Block synchronization time refers to the total time consumed from the time a single historical block on the blockchain data structure is added to the chain to the time it is parsed and synchronized and stored in the search engine database. It can be understood as the minimum time required for a block to be generated and for the block data to be queried, or as the delay time of the block.

[0161] The first normal block range can be determined based on the product of the current block generation speed and the block synchronization time. It serves as a constraint during the block data detection process; specifically, it indicates that detection will terminate when a continuous number of normal blocks are detected within this range. It should be noted that if a block experiences a synchronization failure in the block parsing service due to a container node malfunction during its journey from being uploaded to the blockchain to being synchronized and stored in the search engine database, resulting in abnormal block data (such as data loss or missing data), other adjacent blocks may also exhibit abnormalities. This first normal block range serves as the termination condition for block data detection triggered by a container node restart, ensuring the accuracy of the block data.

[0162] Specifically, when the computer device detects a container node restart request as the trigger condition, it generates a corresponding block detection instruction. That is, when the block detection instruction is triggered by the container node restart request, it uses a specific algorithm—such as multiplying the two—based on the current block generation speed of the blockchain data structure and the synchronization time of a single historical block, and the product size is used as the size of the first normal block range. It should be noted that when the trigger condition is a container node restart request, the block data synchronized to the search engine database from the current end of the blockchain structure is used as the starting block data. Starting from the starting block data, the data integrity of the synchronized blocks in the search engine database is traversed and checked sequentially. During the checking process, the integrity of each block is judged; and the checking continues until a number of normal blocks equal to the first normal block range are detected consecutively, finally obtaining the detection result. In this way, by determining the normal block range based on the block generation speed and synchronization time, the range of potentially problematic blocks can be quickly located, improving detection efficiency. The sequential traversal and checking of block data ensures the accuracy of the detection results. Timely data integrity checks are performed when container nodes restart, ensuring the reliability and stability of the blockchain system.

[0163] In some implementations, when a block detection instruction is triggered by a timed detection task, the block data in the search engine database is divided into multiple block intervals. Any block data within each interval is used as the starting block data, and data integrity checks are performed on the block data in each interval to obtain the detection results. For example, step (103.2) may include:

[0164] (103.2.b.1) When the block detection instruction is a detection instruction triggered by a preset timed detection task, the range of the second normal blocks shall be determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block.

[0165] (103.2.b.2) According to the size of the second normal block range, the synchronized block data in the search engine database is divided into multiple block intervals, wherein any block data in each block interval is used as the starting block data.

[0166] (103.2.b.3) Based on the starting block data in each block interval, perform data integrity checks on the block data in each block interval to obtain the check results.

[0167] The second normal block range can be determined based on the product of the current block generation speed and the block synchronization time. It serves as a constraint during the block data detection process; specifically, it indicates that detection will terminate when a continuous number of normal blocks are detected within this range. It should be noted that if a block experiences a synchronization failure in the block parsing service due to a container node malfunction during its journey from being uploaded to the blockchain to being synchronized and stored in the search engine database, resulting in abnormal block data (such as data loss or missing data), other adjacent blocks may also exhibit abnormalities. Using this second normal block range as the termination condition for block data detection triggered in timed detection tasks ensures the accuracy of the block data.

[0168] Specifically, when the trigger condition is the arrival of the trigger time corresponding to the scheduled detection task, the computer equipment generates a corresponding block detection instruction. That is, when the block detection instruction is triggered by the scheduled detection task, based on the current block generation speed of the blockchain data structure and the synchronization time of a single historical block, a specific algorithm is used, such as multiplying the two, and the product size is used as the size of the second normal block range. It should be noted that when the trigger condition is the arrival of the trigger time corresponding to the scheduled detection task, the synchronized block data in the search engine database is divided into multiple block intervals. Each block interval corresponds to a starting block, specifically using any block data within the interval as the starting block data. Further, according to the sequential relationship of each block interval, for each interval, based on the starting block data, data integrity checks are performed on the block data within that interval. Finally, the detection results of the block data in the search engine database are obtained. Therefore, when the block data detection is triggered by the scheduled detection task, the synchronized block data is divided into block intervals. Based on the starting block data in each block interval, the block data in each block interval is detected separately, so as to minimize the number of block data to be detected and improve detection efficiency.

[0169] In some implementations, data integrity checks are performed on the starting block data within each block interval, and a decision is made on whether to check the block data within the corresponding block interval based on the block check results of each starting block data. For example, step (103.2.b.3) may include:

[0170] (103.2.b.3.1) Perform data integrity checks on the starting block data in each block interval to obtain the block check results corresponding to the starting block data in each block interval;

[0171] (103.2.b.3.2) When there is at least one block detection result indicating that the corresponding starting block data is abnormal, determine the block interval to be repaired that contains the abnormal starting block data;

[0172] (103.2.b.3.3) For each block interval to be repaired, starting from the initial block data, perform data integrity checks on the block data before and after the initial block data in a cross-block interval manner until normal block data of the second normal block range are continuously detected in both the forward and backward directions, and obtain the detection result.

[0173] It should be noted that when performing data integrity checks on the block data within each block interval based on the starting block data in each interval, the block data can be checked one interval at a time according to the sequential relationship of each block interval. Specifically, for the currently polled block interval, data integrity checks are performed on the starting block data within that interval. For example, the hash of the previous block recorded in the starting block data is compared with the actual hash of the previous block to determine the block check result.

[0174] On one hand, when the block detection result indicates that the corresponding starting block data is normal, the block interval containing the normal starting block data is determined as the normal block interval. In this case, there is no need to detect other block data in this normal block interval, reducing the number of block data to be detected. Furthermore, when each block detection result indicates that the starting block data in the corresponding block interval is normal, the block data in the search engine database that does not contain abnormalities is taken as the detection result. In this way, only one starting block data in each block interval needs to be detected, without the need to detect other block data, reducing the number of block data to be detected in the search engine database and improving the efficiency of block data detection.

[0175] On the other hand, if at least one block detection result indicates that the corresponding starting block data is abnormal, a block interval containing the abnormal starting block data is identified as needing repair. For this block interval, starting from the starting block data, the integrity of each block preceding the starting block data within the interval is assessed sequentially, and this process continues until a number of normal blocks within the second normal block range are detected consecutively. Similarly, the integrity of each block following the starting block data within the interval is assessed sequentially, and this process continues until a number of normal blocks within the second normal block range are detected consecutively. In this way, by determining the normal block range based on the block generation speed and synchronization duration, and combining this with a block interval sampling method, potentially problematic block ranges can be quickly located, improving detection efficiency and ensuring the accuracy of the detection results.

[0176] In some implementations, integrity checks can be performed on any block data to be checked based on the consistency between the block hash value of the preceding block data and the preceding block hash value recorded in the adjacent subsequent block data. For example, taking the starting block data as an example, step (103.2.b.3.1) may include: for the starting block data in each block interval, obtaining the forward adjacent candidate block data from the search engine database, and obtaining the candidate hash value corresponding to the candidate block data from the candidate block data; comparing the forward block hash value recorded in the corresponding starting block data with the candidate hash value to obtain a comparison result; when the comparison result shows that the forward block hash value and the candidate hash value are inconsistent, the block detection result of the starting block data is determined to be abnormal.

[0177] The forward block hash value refers to the block hash value recorded in the current block data for the previous block data. It should be noted that each block data records the block hash value of the previous block data, which can be used to verify whether the current block hash is consistent with the previous block hash; and each block hash is generally calculated based on the corresponding block data. When block data is missing or lost, the calculated block hash will also be inconsistent.

[0178] It should be noted that during the parsing and synchronization of historical blocks, when calculating the forward block hash value of the previous block, the forward block hash value can be calculated based on the relevant data of the previous block on the blockchain, or it can be directly calculated based on the current previous block data in the search engine database. However, when a container node needs to upgrade its version or encounters an anomaly, the block-related data it obtains may be incomplete. For example, the relevant data of the previous block obtained from the blockchain may be incomplete, or the current previous block data obtained from the search engine database may be incomplete, leading to an incorrect forward block hash value. Therefore, by comparing the previous block hash recorded in the current block data with the actual previous block hash, it is possible to determine whether the current block data is abnormal. Thus, hash comparison can be used to detect whether block data is abnormal.

[0179] Specifically, when performing data integrity checks on any block of data to be checked, the hash of the previous block recorded in the block of data to be checked can be compared with the actual hash of the previous block to ensure that there are no anomalies in the block of data to be checked.

[0180] For example, taking the starting block data as the block data to be detected, during data integrity detection, the candidate block data adjacent to the starting block data is retrieved from the search engine database, and the candidate hash value corresponding to the candidate block data is obtained from the candidate block data. Further, the preceding block hash value for the candidate block data is obtained from the starting block data, and this preceding block hash value is compared with the candidate hash value to obtain the comparison result. If the comparison result shows that the preceding block hash value and the candidate hash value are inconsistent, it is directly confirmed that the starting block data is abnormal, and the block detection result is obtained.

[0181] On the other hand, if the comparison result shows that the forward block hash value matches the candidate hash value, the block detection result of the starting block data can be directly determined to be normal. In addition, to strengthen the detection of block data, other aspects of the starting block data can be further detected, such as whether the number of recorded interaction tasks (task requests, interaction requests) matches the actual number of included interaction tasks, thereby determining whether the block data is complete.

[0182] In some implementations, data integrity checks can be performed on the block data to be checked based on the consistency between the actual number of historical interaction tasks recorded in the block data and the number of records. For example, taking the starting block data as an example, the process may further include: when the comparison result shows that the forward block hash value is consistent with the candidate hash value, determining the number of records for historical interaction tasks in the block header corresponding to the starting block data; obtaining the actual number of historical interaction tasks contained in the block body corresponding to the starting block data; and when the number of records is inconsistent with the actual number of tasks, determining the block detection result of the starting block data as abnormal.

[0183] Specifically, to enhance the detection of block data, taking the starting block data as an example, if the comparison result indicates that the forward block hash value matches the candidate hash value, the number of tasks recorded for historical interaction tasks (i.e., the number of records) can be obtained from the block header corresponding to the starting block data, along with the actual number of all historical interaction tasks contained in the block body corresponding to the starting block data. Furthermore, this number of records is compared with the actual number of tasks. If the number of records matches the actual number of tasks, the block detection result of the starting block data is determined to be normal; otherwise, if the number of records does not match the actual number of tasks, the block detection result of the starting block data is determined to be abnormal. This strengthens the detection of block data and improves its security.

[0184] The above methods can be used to detect synchronized block data in the search engine database to check for synchronization anomalies. Specifically, the integrity of the data can be determined based on its content, thereby further determining whether the block data is synchronized abnormally and obtaining the detection results. This allows for subsequent filtering of abnormal block data based on the detection results and data repair.

[0185] 104. Based on the detection results, identify the abnormal blocks that need to be repaired, and query the target historical blocks in the blockchain data structure that are associated with the blocks that need to be repaired.

[0186] In this embodiment of the application, after obtaining the detection results for the synchronized block data in the search engine database, it can be determined whether there is abnormal block data in the search engine database based on the detection results. If there is abnormal block data, the source historical block of the abnormal block data, i.e. the target historical block, is found in the blockchain data structure so that the abnormal block data can be repaired according to the target historical block to ensure the accuracy of the block data in the database.

[0187] The block data to be repaired can be block data in the search engine database that has been detected as abnormal. The abnormal situation can be that the recorded forward block hash value is inconsistent with the actual hash value of the previous block, or that the number of tasks recorded in the block header is inconsistent with the total number of tasks contained in the block body. For example, the total number of tasks contained in the block body is less than the number of tasks recorded in the block header. In addition, the abnormal situation can also be that the block data is missing. The above are just examples and are not intended to be specific limitations.

[0188] The target historical block can be the source historical block on the blockchain that corresponds to the data to be repaired. When querying the target historical block associated with the data to be repaired in the blockchain data structure, the identifier of the historical block associated with the data to be repaired can be determined. Based on the historical block identifier, the corresponding target historical block is queried from the blockchain data structure so that the target historical block can be obtained from the blockchain data structure for use in repairing the data to be repaired.

[0189] Using the above methods, it is possible to determine whether there are abnormal block data in the search engine database based on the detection results. For abnormal block data that needs to be repaired, the target historical block corresponding to the block data to be repaired can be determined from the blockchain data structure so that the abnormal block data can be repaired according to the target historical block, thus ensuring the accuracy of the block data in the database.

[0190] 105. Repair the block data to be repaired based on the target historical block using at least one container node.

[0191] In this embodiment of the application, when abnormal block data to be repaired is detected in the search engine database, the block data to be repaired can be repaired based on the target historical block found on the blockchain. The repair process may involve re-parse the target historical block and synchronously storing the parsed target block data in the search engine database. In this way, the abnormal block data is repaired, ensuring the accuracy of the block data synchronized to the search engine database.

[0192] When repairing abnormal block data, the main process involves re-parseing the source block, synchronously storing it in the search engine database, and then deleting the abnormal block data from the search engine database to replace it. It should be noted that the repair process can be performed by the container node previously used to synchronize the block data, or by any other container node. For example, the currently running container node supporting the block parsing service can be used to perform the repair process for the abnormal block data.

[0193] In some implementations, the target historical block can be retrieved from the blockchain data structure by any currently running container node, and the target historical block can be parsed to obtain target block data, which can then replace the abnormal block data to be repaired in the search engine database. For example, step 105 may include: retrieving the target historical block from the blockchain data structure through the query thread of at least one container node, parsing the target historical block to obtain target block data; and transmitting the target block data to the search engine database through the data repair channel of at least one container node, so as to update the block data to be repaired in the search engine database according to the target block data.

[0194] The target block data can be multi-dimensional parsing data obtained by multi-dimensional parsing based on the target historical block. It can include various related data, such as the original historical block, the corresponding block identifier after parsing, the number of task requests (interactive tasks), task results, resource storage addresses, the number of virtual resources, etc. The specific parsing can be performed according to the actual situation, and no limitation is made here.

[0195] It should be noted that the container nodes used to support the block resolution service in this application embodiment can be one or more. Based on this, in the process of repairing abnormal block data to be repaired, if there is only one running container node, the abnormal block data to be repaired is directly repaired through that container node; if there are multiple container nodes, the abnormal block data to be repaired is repaired through one of the target container nodes among these multiple container nodes.

[0196] Specifically, during the repair process of abnormal block data, the target historical block is retrieved from the blockchain again through the query thread of the container node. It should be noted that this query thread can be a dedicated repair query thread, capable of retrieving the target historical block from the blockchain during the data repair process. Then, the target historical block is parsed according to multiple analytical indicators to obtain the target block data corresponding to each indicator. Each analytical indicator corresponds to a piece of data content. It should be noted that the parsed block data can be described using natural language to ensure that the parsed block data is understandable to the queryer.

[0197] Furthermore, a data repair channel connecting the query thread and the storage thread transmits the parsed block data to the storage thread. This data repair channel differs from the regular block data synchronization channel; these are parallel and independent data transmission channels. This dedicated data repair channel avoids conflicts between the data repair and data synchronization processes, preventing mutual impact on their speeds, such as the data repair rate and the data synchronization rate, thus improving data repair efficiency. It should be noted that this data repair channel can be used for transmitting target block data between multiple concurrent threads.

[0198] Next, the storage thread synchronously stores the parsed target block data to the blockchain explorer's search engine database. Similarly, this storage thread can be a dedicated data repair storage thread, which can store the parsed target block data during the data repair process to update the previously abnormal block data to be repaired in the search engine database based on the target block data. This update method can be to supplement, replace, or completely replace the abnormal block data to be repaired based on the target block data, etc., without limitation. This ensures the accuracy of the block data in the search engine database.

[0199] Using the above methods, the target historical blocks found on the blockchain can be used to repair the data of the blocks to be repaired. After the abnormal block data is repaired, the accuracy of the block data synchronized to the search engine database can be ensured.

[0200] As can be seen from the overall description of the embodiments of this application, the embodiments of this application can obtain historical blocks from the blockchain data structure by starting at least one container node through the block parsing service of the blockchain explorer; synchronously store the block data parsed from the historical blocks to the search engine database of the blockchain explorer through at least one container node; perform data integrity detection on the synchronized block data in the search engine database to obtain the detection result; determine the abnormal block data to be repaired based on the detection result, query the target historical block associated with the block data to be repaired in the blockchain data structure; and perform repair processing on the block data to be repaired based on the target historical block through at least one container node.

[0201] Based on this, when historical blocks in the blockchain data structure require real-time parsing and storage under high concurrency, this application can start at least one container node corresponding to the block parsing service of the blockchain explorer. Each container node can retrieve the corresponding historical blocks from the blockchain data structure and synchronize the retrieved historical blocks to the search engine database. In this way, the high-concurrency parsing and storage requirements of historical blocks can be met through at least one container node. Then, by performing data integrity checks on the synchronized block data in the search engine database, missing block data, i.e., abnormal block data to be repaired, is identified. Finally, the abnormal block data to be repaired in the search engine database is repaired according to the corresponding target historical block to ensure that every historical block on the blockchain is successfully parsed and stored.

[0202] Therefore, compared to existing technologies that parse and store blockchain block data sequentially into a search engine database, this application operates the blockchain explorer's block parsing service using a container node management approach. This ensures that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. Furthermore, real-time data integrity checks can be performed on the parsed and stored block data in the blockchain explorer's search engine database to detect any anomalies in the synchronized block data and repair any anomalies. This allows for real-time automatic repair of failed-to-store block data, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, thus improving the efficiency and accuracy of block data queries.

[0203] Based on the methods described in the above embodiments, the following examples will provide further detailed explanations.

[0204] Figure 3 This is a schematic flowchart of another step in the data processing method provided in the embodiments of this application. For ease of understanding, the embodiments of this application are combined with... Figure 3 Describe it.

[0205] In this embodiment, the description will be from the perspective of a data processing device, which can be integrated into a computer device such as a terminal or server. For example, when the processor on the computer device executes the program corresponding to the data processing method, the specific flow of the data processing method is as follows:

[0206] 201. At least one container node started through the block parsing service of a blockchain explorer retrieves historical blocks from the blockchain data structure.

[0207] In this embodiment, to address the high-concurrency parsing requirements of historical blocks in the blockchain data structure, the processing capacity of the block parsing service can be managed using a container node management approach. It should be noted that each container node contains one or more application-specific sub-containers, which can be understood as sub-containers for the block parsing service. Specifically, by increasing the number of container nodes, the processing capacity of the block parsing service is improved, thereby handling the high-concurrency parsing requirements of a large number of original blocks. On the other hand, when the number of original blocks requiring parsing is relatively small, the processing capacity of the block parsing service can be reduced by decreasing the number of container nodes. This approach aims to conserve computing resources while meeting the parsing requirements of a small number of historical blocks, ensuring reliability.

[0208] Block parsing service can be understood as a data analysis service for raw blocks on the blockchain. It can be viewed as a service process or application service that transforms the raw data of blocks into target types and formats according to specific data types or expressions. For example, it converts the raw data of blocks into a data format that is easy for users to understand, such as text, images, or other forms of description. This enables the analysis of the raw data of historical blocks on the blockchain. Afterward, the analyzed block data is synchronously stored in other storage spaces. For example, a blockchain explorer can connect to the database of a search engine (ES). Through the blockchain explorer's block parsing service, it can query the raw blocks from the blockchain data structure, parse the raw blocks to obtain the corresponding block data, and store the block data in the search engine database for subsequent offline retrieval of the block data.

[0209] Here, a container node refers to the smallest scheduling unit in a Container Orchestration System (Kubernetes) cluster, which can contain multiple application-specific sub-containers. In this embodiment, the block resolution service can be supported by container nodes in the Kubernetes cluster. As the smallest scheduling unit of Kubernetes, the number of container nodes can be flexibly increased or decreased to achieve scaling and expansion of the block resolution service, thereby enabling performance control and ensuring reliability of the block resolution service.

[0210] It should be noted that during the process of retrieving historical blocks from the blockchain data structure, each container node can concurrently retrieve one or more historical blocks. Specifically, each container node can contain an application-specific target sub-container for block parsing services. This target sub-container can have multiple query threads and multiple storage threads connected through a data synchronization channel. These query threads can concurrently and independently query the corresponding historical blocks from the blockchain data structure; for example, each query thread independently retrieves the corresponding historical block from the blockchain data structure. This improves the efficiency of historical block querying and retrieval, thereby enhancing the efficiency of subsequent historical block parsing and processing.

[0211] 202. When a restart request is detected from at least one container node of the blockchain explorer, the restart waiting time is determined based on the current block generation speed of the blockchain data structure and the synchronization speed of the blockchain explorer for historical blocks.

[0212] In this embodiment, the container node corresponding to the block parsing service can process historical blocks after obtaining them from the blockchain data structure. It should be noted that during the process of parsing and synchronously storing historical blocks in the search engine database, the block parsing service may experience dynamic adjustments. Specifically, the container node supporting the block parsing service may need to be restarted. For example, if a container node experiences a runtime error or requires a version upgrade, it needs to be destroyed and restarted. This can lead to failures during the parsing and storage of historical blocks, potentially causing data anomalies in the block data synchronously stored in the search engine database, such as data loss or missing data. To prevent data loss or missing data, the restart of the corresponding container node can be intercepted when a restart is required, thus avoiding data loss or missing blocks.

[0213] Therefore, when it is necessary to destroy and restart the relevant container nodes, it is necessary to determine a duration for intercepting the restart of the container nodes, i.e., the restart waiting time.

[0214] The restart waiting time can be determined based on the relationship between the block generation speed and the synchronization speed of the blockchain explorer for historical blocks. Specifically, in scenarios involving high concurrency in parsing and storing historical blocks, a balance between the growth rate and synchronization speed of historical blocks can be considered. This ensures that, given the performance of the block parsing service supported by the current container nodes, the synchronization speed of historical blocks is greater than or equal to the growth rate of historical blocks (i.e., the parsing processing speed is greater than or equal to the block production speed of the blockchain). Only when the number of historical blocks requiring processing no longer continues to grow positively can the container node be restarted. For example, based on the current block generation speed and the current number of historical blocks requiring parsing, it can be estimated how long it will take for the number of historical blocks waiting to be parsed on the blockchain data structure to begin to decline (i.e., how long it will take for the number of historical blocks requiring synchronization to gradually decrease). Based on this, the waiting time required when the synchronization speed of historical blocks is greater than or equal to the growth rate of historical blocks can be estimated.

[0215] In addition, the number of historical blocks currently acquired in the container node can be obtained. Based on the number of historical blocks acquired and the maximum historical time taken for the container node to parse and synchronize a historical block, the estimated processing time for parsing and synchronizing all the historical blocks currently acquired in the container node and storing them in the search engine database can be calculated. This estimated processing time is used as the restart waiting time.

[0216] 203. Intercept the restart of the container node corresponding to the restart request according to the restart waiting time, and synchronize the block data parsed from the historical blocks by at least one container node to the search engine database of the blockchain explorer.

[0217] In this embodiment of the application, after determining the restart waiting time corresponding to the container node that needs to be restarted, the restart of the container node that issued the restart request can be intercepted according to the restart waiting time, so that the container node does not immediately perform the restart, thereby avoiding problems such as missing or lost block data.

[0218] Furthermore, the block data parsed from historical blocks is synchronously stored in the blockchain explorer's search engine database via the container nodes corresponding to the block resolution service. Specifically, to ensure that the block data retrieved later is not the original block data, the acquired historical blocks can be parsed. This parsing can be performed according to multiple preset parsing indicators to obtain block data corresponding to each indicator, with each indicator corresponding to a specific data item. Then, the parsed block data is transmitted to the storage thread via a data synchronization channel connecting the query thread and the storage thread, and the storage thread synchronously stores the parsed block data in the blockchain explorer's search engine database.

[0219] It should be noted that after the restart waiting period ends, the container node that issued the restart request will be restarted. This restart process may involve destroying the current container node and restarting a new container node to replace the destroyed one. This is to ensure the security, accuracy, and integrity of the block data.

[0220] 204. When a block detection command that has been triggered under preset conditions is detected, the starting block data to be detected is selected from the block data that has been synchronized in the search engine database according to the block detection command.

[0221] In this embodiment of the application, after parsing and synchronizing historical block data into the search engine database of the blockchain explorer, in order to ensure the normality, integrity and accuracy of the synchronized block data in the search engine database, the synchronized block data in the search engine database can be detected to check whether there are synchronization anomalies in these block data. Specifically, the integrity of the data can be determined based on the content of the block data, thereby further determining whether the block data is synchronized abnormally, and obtaining the detection results. In order to subsequently filter out the abnormal block data according to the detection results and perform data repair.

[0222] It should be noted that the detection of block data can be triggered by restart requests from container nodes in scenarios such as version upgrades, anomalies, or idle periods, or by scheduled detection tasks; there is no limitation here. To trigger the detection of block data synchronized in the search engine database, preset conditions can be set in advance. For example, preset conditions could be "a restart request or need for a container node has been detected," or "the current time condition (interval duration, time information) has reached the trigger time of the scheduled detection task," and so on.

[0223] Specifically, the status and time information of the block resolution service can be monitored in real time. When the restart of the container node corresponding to the block resolution service serves as a trigger condition, or when the time information reaches the trigger condition of the scheduled detection task, the block data in the search engine database is detected. At this time, a block detection instruction is generated according to the trigger condition. This block detection instruction carries an identifier indicating the trigger condition, so that different block data detection methods can be selected according to different trigger conditions. It should be noted that the method for determining the starting block data under different block data inspection methods is different. Furthermore, based on the trigger condition identifier carried by the block detection instruction, the trigger type is determined to select a starting block data to be detected from the block data synchronized in the search engine database.

[0224] For example, when the block detection instruction is a detection instruction triggered by a restart request of a container node, the starting block data is the block data that is synchronously stored in the search engine database based on the historical blocks at the current end of the blockchain data structure.

[0225] For example, when the block detection instruction is a detection instruction triggered by a preset timed detection task, the second normal block range is determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block. According to the size of the second normal block range, the synchronized block data in the search engine database is divided into multiple block intervals, where any block data in each block interval is used as the starting block data.

[0226] 205. Based on the initial block data, perform data integrity checks on the synchronized block data in the search engine database and obtain the check results.

[0227] In this embodiment, the starting block data is used as the detection starting point to perform data integrity checks on the synchronized block data in the search engine database. Alternatively, based on the detection results of the starting block data, a decision is made to perform data integrity checks on the synchronized block data in the search engine database, thus obtaining the detection results. In this way, according to different triggering conditions of the block detection instruction, the corresponding starting block data is selected, and data integrity checks on the synchronized block data in the search engine database are performed based on the starting block data, thereby improving detection efficiency by reducing the amount of block data to be detected.

[0228] The data integrity check can be understood as checking whether the content of the synchronized block data is complete relative to the content of the original historical block records. Specifically, the data integrity check can be performed from one or more aspects.

[0229] For example, regarding original historical blocks, whether the search engine database has already parsed and stored the corresponding block data can be determined by directly querying the search engine database based on the block identifier to check for the existence of the corresponding historical block data and thus verify data integrity. Furthermore, data loss, missing data, errors, and other incompleteness will cause changes in the block's hash value. Using each historical block as a unit, check whether the hash of the adjacent previous block data matches the hash of the previous block recorded in the subsequent block data. The hash value can be used to verify the integrity of the block data. Finally, since the information recorded in the block header corresponds to the actual content contained in the block body, for example, by checking whether the number of tasks recorded in the block header corresponds to the actual interactive tasks (interaction requests or task requests) contained in the block body, the integrity of each block's data can be verified. The above are only examples of some detection methods and are not intended as specific limitations.

[0230] It should be noted that different block data detection methods are selected based on different triggering conditions. Specifically, the detection triggering condition may be a container node restart request, or it may be the arrival of the trigger time corresponding to the scheduled detection task. The detection process can be referred to in the previous embodiments, and will not be repeated here.

[0231] 206. Based on the detection results, identify the abnormal blocks that need to be repaired, and query the target historical blocks in the blockchain data structure that are associated with the blocks that need to be repaired.

[0232] In this embodiment of the application, after obtaining the detection results for the synchronized block data in the search engine database, it can be determined whether there is abnormal block data in the search engine database based on the detection results. If there is abnormal block data, the source historical block of the abnormal block data, i.e. the target historical block, is found in the blockchain data structure so that the abnormal block data can be repaired according to the target historical block to ensure the accuracy of the block data in the database.

[0233] 207. Repair the block data to be repaired based on the target historical block using at least one container node.

[0234] In this embodiment of the application, when abnormal block data to be repaired is detected in the search engine database, the block data to be repaired can be repaired based on the target historical block found on the blockchain. The repair process may involve re-parse the target historical block and synchronously storing the parsed target block data in the search engine database. In this way, the abnormal block data is repaired, ensuring the accuracy of the block data synchronized to the search engine database.

[0235] To facilitate understanding of the embodiments of this application, specific application scenario examples will be used to describe the embodiments of this application. Specifically, the application scenario example will be described by performing the above steps 201-207.

[0236] It should be noted that this data processing method is applicable to data processing in blockchain network systems, ensuring high-concurrency parsing and storage efficiency of original blocks, and self-recovering abnormal block data in the event of a failure during parsing and storage. The process specifically includes, but is not limited to: retrieving original blocks generated at historical times (i.e., before) from the blockchain; parsing the original blocks according to multiple dimensions and storing them in the database corresponding to the search engine; inspecting the block data stored in the database; and repairing any abnormal block data in the database. This improves the robustness of the system and the accuracy of the block data, thereby facilitating the efficiency and accuracy of subsequent data queries. The following is a case study illustrating this data processing method:

[0237] I. A brief introduction to this data processing scenario is as follows:

[0238] Because data on the blockchain is in key-value format, key-value data is inconvenient to retrieve and analyze. Directly querying data on the blockchain relies on the performance of the blockchain nodes, which can easily lead to performance bottlenecks. In other words, the reliability and performance of queries depend on the state of the blockchain nodes themselves and cannot be scaled. Blockchain explorers provide users with the ability to query and retrieve data on the blockchain.

[0239] Figure 4 This is an example diagram illustrating how to directly query data on the blockchain using a blockchain explorer. In related technologies, [the following is combined]... Figure 4 As shown, users can directly query data on the blockchain through a blockchain explorer. The data retrieved is generally the original data, and if the query service malfunctions, the blockchain node can be called again to query the data on the chain.

[0240] Alternatively, based on a blockchain explorer, raw blockchain data can be queried offline and stored in an Elasticsearch (ES) database according to dimensions such as blocks, tasks, and business processes. ES serves as a search and analysis engine, allowing users to directly query block data and improve query performance. However, storing raw blockchain blocks sequentially in the ES database is not efficient. In scenarios with fast block generation, i.e., high concurrency in parsing and storing a large number of raw blocks, the blockchain explorer may experience data verification delays. For example, a performance bottleneck may occur with chains that generate blocks quickly. When parsing block 1, the chain may have already generated blocks 10. The service can only parse block 1, then block 2, and so on until block 10, failing to improve browser parsing performance as the chain's block generation speed increases. In extreme cases, such as when a single interactive task issues multiple non-fungible virtual resources (NFTs), the blockchain explorer needs to query the NFT data. Since a single task requests to issue multiple NFTs, each NFT needs to be parsed and stored. If 100,000 NFTs are issued, then parsing the block data of this task requires parsing and storing 100,000 NFTs simultaneously. In this case, with the parsing method being sequential, multiple tasks with similar large amounts of data will cause parsing blockage, resulting in a very serious impact. Objects will not be able to see the block data related to their task requests for a period of time.

[0241] Therefore, the above-mentioned technologies cannot meet the high-concurrency parsing and storage timeliness requirements of block data, thus blocking the parsing and storage progress of block data on the blockchain. Furthermore, they cannot recover block data that fails to be parsed and stored in real time or automatically, thereby affecting the query efficiency and accuracy of objects for block data.

[0242] Unlike related technologies, this data processing scenario example is as follows: A self-repair technology for block data is proposed when a blockchain explorer encounters a failure in parsing and processing the original block data. This technology solves the problem of data anomalies such as loss or missing block data caused by failures when offline querying of on-chain data stored in Elasticsearch. Based on the performance of the blockchain explorer, it ensures the robustness of the data, enhances the user experience, and does not drag down the overall chain's task throughput due to the blockchain explorer.

[0243] For example, when a task request is packaged into a block and uploaded to the blockchain, the block needs to be parsed and stored. Suppose a failure occurs during the parsing and storage process to Elasticsearch, resulting in block data loss. When an object checks its uploaded task request through a blockchain explorer and finds the missing block data, the object might immediately assume there's a problem with the blockchain (such as member nodes), thus increasing concerns about blockchain data security. However, implementing this data processing scenario example ensures data self-repair capabilities after a failure, improving the product's user experience and overall competitiveness.

[0244] II. The specific implementation process of this data processing scenario example is as follows:

[0245] Figure 5 Example diagram of a data processing scenario provided in an embodiment of this application. See also... Figure 5 As shown, this data processing scenario example can use the blockchain explorer's parsing service to query blocks 1, 2...3 on the blockchain. After parsing, the block data, along with the corresponding interactive task (i.e., task request) related processing data, processing status, business data, etc., are obtained. The above block data is stored in the Elasticsearch (ES) database. Subsequently, any object or related object can query the corresponding ES database of the blockchain explorer to view and understand the relevant data of its corresponding interactive task.

[0246] Figure 6 This diagram illustrates an example of a parsing and storage scenario for the original block provided in this application embodiment. In a high-concurrency parsing and storage scenario for the original block, the parsing service will launch multiple container node Pods to run the block parsing service, combined with... Figure 6 As shown, container nodes Pod1 and Pod2 are started, each running a parsing service container. Multiple container nodes concurrently parse the raw blocks on the blockchain. When querying and storing blocks, each Pod starts multiple query threads and storage threads to handle the block parsing task. Query threads and storage threads exchange messages through a channel (i.e., a data synchronization channel or data recovery channel). This channel is an in-memory queue used for message passing during multi-threaded concurrent task execution. For example, as... Figure 6As shown, each container node Pod starts two query threads and two storage threads. For example, container node Pod1 starts two query threads and two storage threads. These two query threads operate independently, retrieving raw blocks from the blockchain data structure, such as block 1, block 3, etc., from the blockchain node. Then, after parsing the raw blocks 1, block 3, etc., the corresponding block data is obtained. At this point, the block data is transmitted to the two storage threads through a channel, and the storage threads respectively store the relevant data of block 1 and block 3 into the Elasticsearch database. This allows for subsequent offline querying of block data directly from the Elasticsearch database, ensuring reliability.

[0247] In this data processing scenario, the process of parsing and storing the original blocks in the Elasticsearch database may encounter situations such as container node failures or version upgrades. These situations require the container node Pod to be destroyed and restarted, which can lead to failures in parsing and storing the original blocks, affecting the block parsing and storage process and resulting in missing or abnormal block data. To improve the integrity of the parsed and stored block data, in the event of a block parsing and storage failure, the obtained original blocks can be parsed and stored first, and then the container node can be restarted.

[0248] Figure 7 This is a flowchart illustrating the restart process of a container node for the block resolution service provided in this embodiment. Specifically, it is combined with... Figure 7 As shown, taking the container node Pod1 of the block resolution service as an example, the restart process of container node Pod1 is as follows:

[0249] (A.1) If Pod1 encounters an error or is restarted due to a version upgrade, a destruction process must be performed.

[0250] (A.2) When the state of Pod1 changes from running to terminating, it means that Pod1 has entered the shutdown process.

[0251] (A.3) Pod1 will enter a waiting grace period (i.e. restart waiting time), the length of which is the configuration value of "terminationGracePeriodSeconds".

[0252] The "terminationGracePeriodSeconds" parameter represents the waiting time before a container node Pod is destroyed. When container node Pod1 is destroyed, it is not immediately destroyed; it sends a container termination signal and waits for the child containers of the parsing service to gracefully exit before Pod1 exits. Therefore, by configuring this parameter appropriately, the Pod can exit only after all tasks have been parsed normally. For example, setting it to 30 seconds can be done as follows:

[0253]

[0254]

[0255] (A.4) The process of starting a Pod and shutting down its internal containers in parallel will be executed if the `preStop` configuration command is set. The `preStop` configuration command can be used to clean up resources before the container node Pod terminates, such as cleaning up the sub-containers of the block parsing service. Specifically, the `preStop` configuration command is the parsing service exit command (parserserver stop).

[0256] (A.5) Execute the preStop configuration command.

[0257] (A.6) The sub-container of the parsing service receives the parsing service exit command.

[0258] (A.7) Stop accepting new block parsing tasks, that is, stop retrieving new original historical blocks from the blockchain.

[0259] (A.8) The sub-container of the block resolution service continues to resolve the original blocks already obtained in the current channel.

[0260] (A.9) The sub-container of the block resolution service exits normally after completing the parsing of the original block, that is, the sub-container of the block resolution service exits and closes.

[0261] (A.10) After the sub-container of the block resolution service exits, it means that the preStop command has been executed. The execution time of the preStop configuration command must be less than the waiting grace period configured in terminationGracePeriodSeconds. In this way, the phenomenon that the container node Pod1 is forcibly exited before the sub-container of the block resolution service has exited normally can be avoided.

[0262] (A.11) Wait for the end of the grace period configured for terminationGracePeriodSeconds.

[0263] (A.12) Pod1 exited normally.

[0264] In this data processing scenario example, to prevent the loss or missing of parsed and stored block data, each block data item already parsed and stored in the Elasticsearch (ES) database can be inspected. Specifically, anomaly detection can be performed on each block data item in the ES database at any time. For example, it can be triggered when the container node supporting the block parsing service starts up or needs to restart and issues an alarm (i.e., a restart request, restart prompt, or other alarm information), or when a scheduled detection task reaches its corresponding detection time. This can be understood as a data integrity check. This ensures the accuracy of the parsed and stored block data.

[0265] Figure 8 This is a flowchart illustrating the block data detection process provided in an embodiment of this application. (In conjunction with...) Figure 8 As shown, the scenarios that trigger the inspection of synchronized block data in the Elasticsearch database are as follows:

[0266] The scenario of container node startup (Pod start). Whether a Pod restarts due to abnormal exit, normal version upgrade, or resource insufficiency causing idleness, it will passively restart everywhere, which can easily lead to the loss of block data. Therefore, triggering a block data check when the container node starts is essential.

[0267] Scheduled detection scenarios. A block data check is triggered daily when the blockchain is inactive (e.g., around 1 AM).

[0268] Alarm triggering scenarios under abnormal conditions. Abnormal conditions include Pod crash alarms, service failure alarms, query failure alarms, write failure alarms, etc., in which case it is necessary to start the block data inspection and recovery process.

[0269] The process for performing block checks based on the above detection scenarios is as follows:

[0270] (B.1) Trigger check.

[0271] (B.2) Begin inspecting blocks by querying a specific block from the Elasticsearch database.

[0272] (B.3) Was a problematic block detected? If not, check the next block; if so, repair the problematic block.

[0273] (B.4) Query the original block corresponding to the problem block on the blockchain.

[0274] (B.5) Parse the original block to obtain the block data and write the block data into the ES database.

[0275] In this data processing scenario example, when inspecting block data, the inspection can be based on the information contained in the block, such as the information in the block header. Figure 9 This is an example diagram of the block header structure provided in the embodiments of this application, combined with... Figure 9 As shown, the block header contains information such as the block height of the current block, the block hash, the hash of the previous block, the number of interactive tasks (i.e., task requests) in the current block, the list of interactive tasks in the current block, and the time (such as execution time, request time, etc.) of the interactive tasks in the current block. For example, the block header of block 3 contains the height of block 3 in the blockchain data structure, the block hash of block 3, the hash of the preceding block 2, the number of interactive tasks (task requests) in block 3, the list of interactive tasks (task requests) in block 3, and the execution time and / or request time of each task request recorded in block 3.

[0276] Figure 10 This is a flowchart illustrating the block data detection process provided in an embodiment of this application. (In conjunction with...) Figure 10 As shown, taking block 3 as an example, the detection process for block data that has been synchronized and stored in the ES database is as follows:

[0277] (C.1) Determine the detection task and start detection block 3.

[0278] (C.2) Query block 3 from the ES database.

[0279] (C.3) Check if the block header of block 3 exists in the ES database. If not, the task does not exist, and it is determined that the entire block data of block 3 is lost. If it does exist, the block header of block 3 exists, and a block hash check is performed.

[0280] (C.4) Detect the block hash of the previous block in the block data of the ES database, that is, the block hash of block 2.

[0281] (C.5) Check whether the hash of the previous block recorded in the block header of the Elasticsearch database matches the actual hash of the previous block. For example, check whether the hash field of the previous block recorded in the block header of block 3 matches the hash of the previous block in block 2. On the one hand, if it does not match, block 3 is confirmed as a problematic block, and the correct block needs to be recovered. On the other hand, if it matches, the hash check passes, and the number of interactive tasks (task requests) actually contained in block 3 can be further checked.

[0282] (C.6) Detect the number of interactive tasks (task requests) actually contained in block 3.

[0283] (C.7) Check the number of interaction tasks recorded in the block header of block 3 in the ES database, and compare this recorded number of interaction tasks with the actual number of interaction tasks (task requests) contained in block 3 to determine if they match. If they don't match, it means that block 3 has missing data, making it a problematic block that needs to be recovered. If they match, it means that block 3 has normal data and is a normal block.

[0284] By using the above block data detection process, block data detection can be achieved by parsing only the corresponding block headers without parsing all block data, ensuring that no block data is lost, quickly identifying problematic blocks, and improving detection efficiency.

[0285] In this data processing scenario example, the detection method for block data in the ES database can be either to traverse and detect all the block data in the ES database, or to detect only a portion of the block data in the ES database.

[0286] It's important to note that blockchain blocks are generated sequentially, and therefore, parsing and storage also proceed sequentially in the order of block generation. If a failure occurs during block parsing and storage, the lost or problematic blocks are generally consecutive blocks. In this scenario, the shortest consecutive height of a normal block (i.e., the number of consecutive normal blocks) can be estimated based on the block generation speed and the latency of the blockchain explorer in parsing and storing a single block (i.e., the time difference from block generation to storage in Elasticsearch). This is the range of normal blocks, calculated as: block generation speed * latency. For example, assuming a latency of 1 second and a block generation speed of 600 blocks per second, the shortest consecutive height of a normal range is 600, meaning the number of consecutive normal block data units is 600.

[0287] To better understand the block data detection process, the following describes the process triggered by two scenarios: container node restart and scheduled detection tasks.

[0288] (1) When a restart scenario is triggered due to a container node version upgrade, anomaly, or alarm, the block data detection is triggered under this restart scenario. The latest parsed block data in the ES database is used as the starting point to start detecting the block data in front. If the number of normal block data that appears continuously without interruption exceeds 600, it is considered that the block data has not been lost.

[0289] Figure 11 This is an example diagram illustrating a block data detection scenario triggered by a container node restart request, as provided in an embodiment of this application. Combined with... Figure 11As shown, when a container node restart request triggers block data detection, the detection starts from "block 60000". If "block 60000" is normal, the previous "block 59999" is checked. If "block 59999" is a problematic block, the recovery process is initiated for "block 59999", and the previous "block 59998" is parsed. If "block 59998" is a normal block, the count of "normal blocks + 1" is incremented. However, if "block 59997" is parsed and found to be a problematic block, the count of normal blocks needs to be cleared. When a normal block is encountered, the normal block count is restarted. For example, assuming "block 59996" is normal, and blocks 59996 to 59397 are all normal blocks, it means that more than 600 normal blocks have been detected without interruption. At this point, the detection ends. The above is an example and is not intended to be limiting.

[0290] (2) For block data detection scenarios triggered by timed detection tasks, since the range of block data to be checked is relatively large, for example, it is necessary to detect the block data parsed and stored in the ES database within 1 day or 1 week, in order to avoid affecting the parsing and storage performance of the original blocks by occupying the running resources during the block data detection process, a random sampling detection mechanism between block partitions can be used to sample and detect the block data in each block interval. In this way, the problem blocks can be quickly parsed while ensuring performance, and the reliability is guaranteed.

[0291] For example, suppose there are 60,000 blocks in the Elasticsearch database that need to be checked. In this case, the 60,000 blocks can be divided into 100 block intervals (60,000 / 600) according to the range of normal blocks (e.g., 600). One block is randomly selected from each block interval for checking. If the check passes, the blocks in the block interval are considered to be normal blocks, and the check of the next block interval continues. If the check fails, the block is a problem block, and it is determined that there are consecutive problem blocks in the block interval. Then, the problem block is repaired. At the same time, the check is performed across intervals, up and down, centered on the problem block, until more than 600 normal blocks are detected without interruption in both the upper and lower intervals, so as to avoid missing consecutive problem blocks in other block intervals.

[0292] Finally, for the block data detection scenarios triggered by (1) the restart of container nodes and (2) the block data detection scenarios triggered by timed detection tasks, after a problem block is detected, the corresponding original block information is queried from the blockchain, then parsed, and written into the ES database through a specific data recovery channel and by starting a specific storage thread, so as to avoid affecting the normal business of parsing and storing the original block.

[0293] Figure 12 This is an example diagram illustrating a repair scenario for a problematic block provided in an embodiment of this application. Combined with... Figure 12 As shown, when problematic blocks are detected in the Elasticsearch (ES) database, additional query and storage threads are started within the same container node. These threads are connected via a dedicated data recovery channel for data repair. For example, assuming blocks 2 and 3 are detected as problematic, two query threads and two storage threads are started in container node Pod1. The number of these threads can be determined based on the actual situation; it can be related to or independent of the number of problematic blocks. Furthermore, the two query and storage threads are connected via the dedicated data recovery channel. Subsequently, the query threads re-query the original blocks 2 and 3 from the blockchain data structure on the blockchain node, parse them respectively, obtain the corresponding block data, and store these two block data in the storage thread via the data recovery channel to write them into the ES database.

[0294] By executing the above data processing scenario examples, the following effects can be achieved: resolving the timeliness issues of parsing and storing block data under high concurrency, while ensuring data integrity, thereby improving the blockchain explorer's resilience to failures. This enhances the product quality of the blockchain explorer, making it both high-performance and robust, meeting the timeliness requirements of block parsing and storage under high-speed block generation.

[0295] As described above, when historical blocks in the blockchain data structure require real-time parsing and storage under high concurrency, this application embodiment can start at least one container node corresponding to the block parsing service of the blockchain explorer. Each container node can obtain the corresponding historical blocks from the blockchain data structure and synchronize the obtained historical blocks to the search engine database. In this way, the high-concurrency parsing and storage requirements of historical blocks can be met through at least one container node. Then, by performing data integrity checks on the synchronized block data in the search engine database, missing block data, i.e., abnormal block data to be repaired, is identified. Finally, the abnormal block data to be repaired in the search engine database is repaired according to the corresponding target historical block to ensure that each historical block on the blockchain is successfully parsed and stored.

[0296] Therefore, compared to existing technologies that parse and store blockchain block data sequentially into a search engine database, this application operates the blockchain explorer's block parsing service using a container node management approach. This ensures that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. Furthermore, real-time data integrity checks can be performed on the parsed and stored block data in the blockchain explorer's search engine database to detect any anomalies in the synchronized block data and repair any anomalies. This allows for real-time automatic repair of failed-to-store block data, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, thus improving the efficiency and accuracy of block data queries.

[0297] For details on the implementation of each of the above steps, please refer to the previous examples, which will not be repeated here.

[0298] To facilitate better implementation of the data processing method provided in the embodiments of this application, the embodiments of this application also provide an apparatus based on the above-described data processing method. The meanings of the terms used are the same as in the data processing method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0299] Please see Figure 13 , Figure 13 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device is integrated into the computer equipment of this application. The data processing device may include a first acquisition unit 401, a storage unit 402, a detection unit 403, a determination unit 404, and a repair unit 405.

[0300] The acquisition unit 401 is used to acquire historical blocks from the blockchain data structure by starting at least one container node through the block parsing service of the blockchain explorer.

[0301] Storage unit 402 is used to synchronously store block data parsed from historical blocks to the search engine database of the blockchain explorer through at least one container node;

[0302] The detection unit 403 is used to perform data integrity checks on the synchronized block data in the search engine database and obtain the detection results.

[0303] The determination unit 404 is used to determine the abnormal block data to be repaired based on the detection results, and to query the target historical block associated with the block data to be repaired in the blockchain data structure.

[0304] Repair unit 405 is used to repair the block data to be repaired based on the target historical block through at least one container node.

[0305] In some embodiments, the detection unit 403 is further configured to:

[0306] When a block detection command triggered by a preset condition is detected, the starting block data to be detected is selected from the block data synchronized in the search engine database according to the block detection command.

[0307] Based on the initial block data, data integrity checks are performed on the synchronized block data in the search engine database to obtain the check results.

[0308] In some embodiments, the detection unit 403 is further configured to:

[0309] When the block detection instruction is a detection instruction triggered by a restart request of a container node, the range of the first normal blocks is determined based on the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block.

[0310] The starting block data is the block data that is synchronously stored in the search engine database based on the historical blocks at the current end of the blockchain data structure;

[0311] Starting with the initial block data, the system sequentially traverses and checks the data integrity of the synchronized blocks in the search engine database until it detects a number of normal blocks within the range of the first normal block, thus obtaining the detection result.

[0312] In some embodiments, the detection unit 403 is further configured to:

[0313] When the block detection instruction is a detection instruction triggered by a preset timed detection task, the range of the second normal blocks is determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block.

[0314] Based on the size of the second normal block range, the synchronized block data in the search engine database is divided into multiple block intervals, where any one block data in each block interval is used as the starting block data.

[0315] Based on the starting block data in each block interval, data integrity checks are performed on the block data in each block interval to obtain the check results.

[0316] In some embodiments, the detection unit 403 is further configured to:

[0317] Perform data integrity checks on the starting block data in each block interval to obtain the block check results corresponding to the starting block data in each block interval;

[0318] When at least one block detection result indicates that the corresponding starting block data is abnormal, the block interval to be repaired containing the abnormal starting block data is determined.

[0319] For each block interval to be repaired, starting from the initial block data, data integrity checks are performed on the block data before and after the initial block data in a cross-block interval manner until normal block data of the second normal block range are continuously detected in both the forward and backward directions, and the detection result is obtained.

[0320] In some embodiments, the detection unit 403 is further configured to:

[0321] For the starting block data in each block interval, retrieve the forward adjacent candidate block data from the search engine database, and retrieve the candidate hash value corresponding to the candidate block data from the candidate block data;

[0322] The comparison result is obtained by comparing the forward block hash value recorded in the corresponding starting block data with the candidate hash value;

[0323] When the comparison result shows that the forward block hash value is inconsistent with the candidate hash value, the block detection result of the starting block data is determined to be abnormal.

[0324] In some embodiments, the detection unit 403 is further configured to:

[0325] When the comparison result shows that the forward block hash value is consistent with the candidate hash value, determine the number of records for historical interaction tasks in the block header corresponding to the starting block data;

[0326] Get the actual number of historical interaction tasks contained in the block body corresponding to the starting block data;

[0327] When the number of records is inconsistent with the actual number of tasks, the block detection result of the starting block data will be identified as abnormal.

[0328] In some embodiments, storage unit 402 is further used for:

[0329] When a restart request is detected from at least one container node of the blockchain explorer, the restart waiting time is determined based on the current block generation speed of the blockchain data structure and the synchronization speed of the blockchain explorer for historical blocks.

[0330] The restart of the container node corresponding to the restart request is intercepted according to the restart waiting time, and the block data parsed from the historical blocks by at least one container node is synchronously stored to the search engine database of the blockchain explorer.

[0331] In some embodiments, storage unit 402 is further used for:

[0332] Based on a block parsing service with at least one container node, the historical blocks obtained are parsed to obtain block data according to multiple preset parsing indicators.

[0333] The parsed block data is synchronously stored in the blockchain explorer's search engine database through the data synchronization channel in at least one container node.

[0334] In some embodiments, the data processing apparatus further includes a startup unit for:

[0335] Determine the number of historical blocks waiting to be synchronized in the blockchain data structure, and determine the current block generation rate of the blockchain data structure;

[0336] The number of container nodes to start is determined based on the number of historical blocks and the current block generation rate.

[0337] Based on the number of container nodes launched, launch at least one container node to support the block parsing service of the blockchain explorer.

[0338] In some embodiments, the repair unit 405 is further configured to:

[0339] The target historical block is retrieved from the blockchain data structure through the query thread of at least one container node, and the target historical block is parsed to obtain the target block data.

[0340] The target block data is transmitted to the search engine database through the data repair channel of at least one container node, so as to update the block data to be repaired in the search engine database according to the target block data.

[0341] As described above, when historical blocks in the blockchain data structure require real-time parsing and storage under high concurrency, this application embodiment can start at least one container node corresponding to the block parsing service of the blockchain explorer. Each container node can obtain the corresponding historical blocks from the blockchain data structure and synchronize the obtained historical blocks to the search engine database. In this way, the high-concurrency parsing and storage requirements of historical blocks can be met through at least one container node. Then, by performing data integrity checks on the synchronized block data in the search engine database, missing block data, i.e., abnormal block data to be repaired, is identified. Finally, the abnormal block data to be repaired in the search engine database is repaired according to the corresponding target historical block to ensure that each historical block on the blockchain is successfully parsed and stored.

[0342] Therefore, compared to existing technologies that parse and store blockchain block data sequentially into a search engine database, this application operates the blockchain explorer's block parsing service using a container node management approach. This ensures that the block parsing service can meet the timeliness requirements of high-concurrency parsing and storage of historical blocks. Furthermore, real-time data integrity checks can be performed on the parsed and stored block data in the blockchain explorer's search engine database to detect any anomalies in the synchronized block data and repair any anomalies. This allows for real-time automatic repair of failed-to-store block data, ensuring that historical blocks on the blockchain are correctly parsed and stored in the blockchain explorer's search engine database, thus improving the efficiency and accuracy of block data queries.

[0343] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0344] See Figure 14 , Figure 14 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. It includes a structural block of a portion of the terminal 110 implementing this embodiment. The terminal 110 includes: a radio frequency (RF) circuit 510, a memory 515, an input unit 520, a display unit 540, a sensor 550, an audio circuit 560, a wireless fidelity (WiFi) module 570, a processor 580, and a power supply 590, among other components. Those skilled in the art will understand that... Figure 14 The terminal 110 structure shown does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0345] The RF circuit 510 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 580; in addition, it transmits uplink data to the base station.

[0346] The memory 515 can be used to store software programs and modules. The processor 580 executes various functional applications and data processing of the terminal by running the software programs and modules stored in the memory 515.

[0347] The input unit 520 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 520 may include a touch panel 531 and other input devices 532.

[0348] The display unit 540 can be used to display input or provided information, as well as various menus of the terminal. The display unit 540 may include a display panel 541.

[0349] Audio circuit 560, speaker 561, and microphone 562 provide an audio interface.

[0350] In this embodiment, the processor 580 included in the terminal 110 can execute the data processing method of the previous embodiment.

[0351] The terminal 110 in this application embodiment includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. This invention embodiment can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0352] See Figure 15 , Figure 15 This is a schematic diagram of the server structure provided in an embodiment of this application, which includes a structural block of a portion of the server 120 implementing this embodiment. The server 120 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 622 (e.g., one or more processors) and memory 632, and one or more storage media 630 (e.g., one or more mass storage devices) for storing application programs 642 or data 644. The memory 632 and storage media 630 may be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server 600. Furthermore, the central processing unit 622 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the server 600.

[0353] Server 600 may also include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input / output interfaces 658, and / or one or more operating systems 641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0354] The central processing unit 622 in server 600 can be used to execute the data processing method of the embodiments of this application, as follows:

[0355] At least one container node, started through the blockchain explorer's block parsing service, retrieves historical blocks from the blockchain data structure; the block data parsed from the historical blocks is synchronously stored in the blockchain explorer's search engine database through at least one container node; data integrity is checked on the synchronized block data in the search engine database to obtain the detection results; based on the detection results, abnormal block data to be repaired is identified, and the target historical block associated with the block data to be repaired is queried in the blockchain data structure; the block data to be repaired is repaired based on the target historical block through at least one container node.

[0356] This application also provides a computer-readable storage medium for storing program code, which is used to execute the data processing methods of the foregoing embodiments, as follows:

[0357] At least one container node, started through the blockchain explorer's block parsing service, retrieves historical blocks from the blockchain data structure; the block data parsed from the historical blocks is synchronously stored in the blockchain explorer's search engine database through at least one container node; data integrity is checked on the synchronized block data in the search engine database to obtain the detection results; based on the detection results, abnormal block data to be repaired is identified, and the target historical block associated with the block data to be repaired is queried in the blockchain data structure; the block data to be repaired is repaired based on the target historical block through at least one container node.

[0358] This application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the data processing method described above.

[0359] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0360] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0361] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0362] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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 system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0363] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0364] 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.

[0365] 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 computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part 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, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0366] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0367] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0368] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A data processing method, characterized in that, include: At least one container node is started through the block parsing service of a blockchain explorer to retrieve historical blocks from the blockchain data structure; The block data parsed from the historical blocks will be synchronously stored in the search engine database of the blockchain explorer through the at least one container node; Data integrity checks are performed on the synchronized block data in the search engine database to obtain the check results; Based on the detection results, identify abnormal block data that needs to be repaired, and query the target historical block in the blockchain data structure that is associated with the block data that needs to be repaired; The at least one container node performs repair processing on the data of the block to be repaired based on the target historical block.

2. The method according to claim 1, characterized in that, The step of performing data integrity checks on the synchronized block data in the search engine database and obtaining the check results includes: When a block detection instruction triggered by a preset condition is detected, the starting block data to be detected is selected from the block data synchronized in the search engine database according to the block detection instruction. Based on the initial block data, data integrity checks are performed on the block data that has been synchronized in the search engine database to obtain the check results.

3. The method according to claim 2, characterized in that, The step of performing data integrity checks on the synchronized block data in the search engine database based on the initial block data, and obtaining the check results, includes: When the block detection instruction is a detection instruction triggered based on the restart request of the container node, the first normal block range is determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block; The starting block data is block data that is synchronously stored in the search engine database based on the historical blocks at the current end of the blockchain data structure; Starting with the initial block data, the data integrity of the synchronized block data in the search engine database is sequentially traversed and checked until a number of normal block data within the first normal block range are continuously detected, and the detection result is obtained.

4. The method according to claim 2, characterized in that, The step of performing data integrity checks on the synchronized block data in the search engine database based on the initial block data, and obtaining the check results, includes: When the block detection instruction is a detection instruction triggered based on a preset timed detection task, the range of the second normal blocks is determined according to the current block generation speed of the blockchain data structure and the block synchronization time of a single historical block. According to the size of the second normal block range, the block data that has been synchronized in the search engine database is divided into multiple block intervals, wherein any block data in each block interval is used as the starting block data. Based on the starting block data in each block interval, data integrity checks are performed on the block data in each block interval to obtain the check results.

5. The method according to claim 4, characterized in that, The process involves performing data integrity checks on the block data within each block interval based on the starting block data, and obtaining the check results, including: Data integrity checks are performed on the starting block data in each block interval to obtain the block check result corresponding to the starting block data in each block interval; When at least one block detection result indicates that the corresponding starting block data is abnormal, the block interval to be repaired containing the abnormal starting block data is determined. For each block interval to be repaired, taking the starting block data as the starting point, data integrity checks are performed on the block data before and after the starting block data in a cross-block interval manner, until normal block data of the second normal block range are continuously detected in both the forward and backward directions, and the detection result is obtained.

6. The method according to claim 5, characterized in that, The step of performing data integrity checks on the starting block data in each block interval to obtain the block check result corresponding to the starting block data in each block interval includes: For the starting block data in each block interval, obtain the forward adjacent candidate block data from the search engine database, and obtain the candidate hash value corresponding to the candidate block data from the candidate block data; The comparison result is obtained by comparing the forward block hash value recorded in the corresponding starting block data with the candidate hash value; When the comparison result shows that the forward block hash value is inconsistent with the candidate hash value, the block detection result of the starting block data is determined to be abnormal.

7. The method according to claim 6, characterized in that, The method further includes: When the comparison result shows that the forward block hash value is consistent with the candidate hash value, the number of records for historical interaction tasks in the block header corresponding to the starting block data is determined. Obtain the actual number of historical interaction tasks contained in the block body corresponding to the starting block data; When the number of records is inconsistent with the actual number of tasks, the block detection result of the starting block data is determined to be abnormal.

8. The method according to any one of claims 1 to 7, characterized in that, The step of synchronously storing the block data parsed from the historical blocks through the at least one container node to the search engine database of the blockchain explorer includes: When a restart request is detected from at least one container node of the blockchain explorer, the restart waiting time is determined based on the current block generation speed of the blockchain data structure and the synchronization speed of the blockchain explorer for historical blocks. The restart of the container node corresponding to the restart request is intercepted according to the restart waiting time, and the block data parsed from the historical blocks by the at least one container node is synchronously stored in the search engine database of the blockchain explorer.

9. The method according to claim 8, characterized in that, The step of synchronously storing the block data parsed from the historical blocks by the at least one container node into the search engine database of the blockchain explorer includes: Based on the block parsing service of the at least one container node, the historical blocks obtained are parsed to obtain block data according to a number of preset parsing indicators. The parsed block data is synchronously stored in the search engine database of the blockchain explorer through the data synchronization channel in at least one container node.

10. The method according to any one of claims 1 to 9, characterized in that, Before the at least one container node started via the block parsing service of the blockchain explorer retrieves historical blocks from the blockchain data structure, the method further includes: Determine the number of historical blocks waiting to be synchronized in the blockchain data structure, and determine the current block generation speed of the blockchain data structure; The number of container nodes to be started is determined based on the number of historical blocks and the current block generation rate. Based on the number of container nodes launched, at least one container node is launched to support the block parsing service of the blockchain explorer.

11. The method according to any one of claims 1 to 9, characterized in that, The repair process of the block data to be repaired based on the target historical block by the at least one container node includes: The target historical block is retrieved from the blockchain data structure through the query thread of at least one container node, and the target historical block is parsed to obtain the target block data. The target block data is transmitted to the search engine database through the data repair channel of the at least one container node, so as to update the block data to be repaired in the search engine database according to the target block data.

12. A data processing apparatus, characterized in that, include: The acquisition unit is used to retrieve historical blocks from the blockchain data structure by starting at least one container node through the block parsing service of the blockchain explorer. A storage unit is used to synchronously store the block data parsed from the historical blocks to the search engine database of the blockchain explorer through the at least one container node; The detection unit is used to perform data integrity detection on the block data that has been synchronized in the search engine database and obtain the detection result; The determining unit is used to determine the abnormal block data to be repaired based on the detection result, and to query the target historical block associated with the block data to be repaired in the blockchain data structure; The repair unit is used to repair the data of the block to be repaired based on the target historical block through the at least one container node.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the data processing method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the data processing method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the data processing method according to any one of claims 1 to 11.

Images