Block chain filing method and device, storage medium and computer equipment

Abstract

The embodiment of the invention discloses a block chain filing method and device, a storage medium and computer equipment. The method comprises the steps of obtaining a to-be-archived block from a target block chain of a target consensus node; the to-be-archived block is stored in a first archived file of the first archiving area, a first index is established for the to-be-archived block, and the first index indicates a first archived file identifier of the first archived file in which the to-be-archived block is stored and a first storage position of the to-be-archived block in the first archived file; and when an acquisition request of the target consensus node for the to-be-archived block is received, acquiring the first archived file in the first archiving area according to the first archived file identifier, and acquiring the to-be-archived block in the first archived file according to the first storage position. Therefore, the first archived file of the block needing to be queried is found through the first index, and the block needing to be queried is found in the first archived file, so that the data processing efficiency of the archived block is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and specifically to a blockchain archiving method, apparatus, storage medium and computer equipment. Background Art

[0002] With the development of information technology, blockchain has become a commonly used distributed data storage technology. A node can store multiple blockchains, and the node stores the data corresponding to each blockchain. As the length or number of blockchains increases, the data stored in the node will also increase accordingly.

[0003] In the related art, the data stored in the node is archived to reduce the storage space occupied by the data on the node, that is, the data that is not used for a long time in the storage space of the node is migrated to the archive database to reduce the storage space occupied by the data on the node.

[0004] However, the data archiving method in the blockchain in the related technology is relatively simple. After the data stored in the node is archived to the database, the archived data is not differentiated and managed, resulting in relatively redundant archived data. When the node obtains and restores data from the archived database, it takes a long time to find the corresponding data in the database. Therefore, the related technology has low processing efficiency for archived data. Summary of the invention

[0005] The embodiments of the present application provide a blockchain archiving method, apparatus, storage medium, and computer equipment, which can improve the data processing efficiency of archived blocks.

[0006] To solve the above technical problems, the present application provides the following technical solutions:

[0007] A blockchain archiving method, comprising:

[0008] Obtain the blocks to be archived from the target blockchain of the target consensus node;

[0009] The block to be archived is stored in a first archive file of a first archive area, and a first index is established for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file where the block to be archived is stored, and a first storage position of the block to be archived in the first archive file;

[0010] When a request for obtaining a block to be archived is received from the target consensus node, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage location.

[0011] A blockchain archiving device, comprising:

[0012] The acquisition module is used to obtain the blocks to be archived from the target blockchain of the target consensus node;

[0013] A storage module, used for storing the block to be archived in a first archive file of a first archive area, and establishing a first index for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file in which the block to be archived is stored, and a first storage position of the block to be archived in the first archive file;

[0014] The search module is used to obtain the first archive file in the first archive area according to the first archive file identifier when receiving a request for obtaining the block to be archived from the target consensus node, and to obtain the block to be archived in the first archive file according to the first storage location.

[0015] In some embodiments, the acquisition module is used to:

[0016] Get a first threshold height;

[0017] Obtain a block on the target blockchain whose block height is less than a first threshold height as a block to be archived.

[0018] In some embodiments, the storage module is used to:

[0019] If the first archived file has not been stored in the first archived area, or the first archived files in the first archived area are fully stored, a first document file is added to the first archived area, and the blocks to be archived are serialized and stored in the added first archived file;

[0020] If there is an incomplete first archive file in the first archive area, the blocks to be archived are serialized and stored in the incomplete first archive file.

[0021] In some implementations, the first storage location of the to-be-archived block in the first archive file includes the starting storage location of the to-be-archived block in the first archive file and the length of the to-be-archived block; the search module is used to:

[0022] Locate the starting point of the block to be archived in the first archive file according to the starting storage position;

[0023] Locate the end point of the block to be archived in the first archive file according to the length;

[0024] Extract the portion between the start point and the end point in the first archive file as the block to be archived.

[0025] In some embodiments, the first archive file has an end block height, which is the maximum height of the block to be archived contained in the first archive file on the target blockchain; the storage module further includes a compression submodule, which is used to:

[0026] Get the second threshold height;

[0027] Determine the first archive file to be compressed based on the comparison between the second threshold height and the end block height of each first archive file;

[0028] The first archive file to be compressed is compressed as a second archive file, the second archive file is stored in a second archive area, and the first archive file to be compressed is deleted from the first archive area.

[0029] In some embodiments, the compression submodule is further configured to:

[0030] Sort the plurality of first archive files in ascending order according to the end block height;

[0031] If the second threshold height is equal to the end block height of a first archive file, the first archive file and the first archive file before the first archive file in the sorting are determined as the first archive files to be compressed;

[0032] If the second threshold height is less than the end block height of a first archive file in the sort, but greater than the end block height of the previous first archive file in the sort, the previous first archive file and the first archive file in front of the previous first archive file in the sort are determined as first archive files to be compressed.

[0033] In some embodiments, the storage module further includes a cold storage submodule, which is used to: after storing the block to be archived in the first archive file of the first archive area and creating a first index for the block to be archived:

[0034] Among the second archive files in the second archive area, determine the second archive file whose archive time is before the predetermined time point as the third archive file;

[0035] The third archive file is stored in the third archive area, and the third archive file is deleted in the second archive area.

[0036] In some embodiments, the refrigeration submodule is used to:

[0037] Determining, among the second archive files in the second archive area, a target second archive file corresponding to a predetermined time point;

[0038] Determine the starting block height of the target second archive file;

[0039] The target second archive file and the second archive file whose end block height is less than the start block height of the target second archive file are determined as the third archive file.

[0040] In some embodiments, the search module further includes a height acquisition submodule, the height acquisition submodule being used to:

[0041] After storing the second archive file in the second archive area, determining the maximum end block height among the end block heights corresponding to each second archive file as the first identification block height;

[0042] After the third archive file is stored in the third archive area, the end block height with the maximum height among the end block heights corresponding to each third archive file is determined as the second identification block height.

[0043] In some embodiments, before obtaining the first archive file in the first archive area according to the first archive file identifier and obtaining the to-be-archived block in the first archive file according to the first storage location, the height acquisition submodule is further configured to:

[0044] When receiving a request from the target consensus node for obtaining a block to be archived, the target block height of the block to be archived in the target blockchain is obtained.

[0045] In some embodiments, the search module further includes a search submodule, which, after obtaining the target block height of the block to be archived in the target blockchain, is used to:

[0046] If the target block height is greater than the first identification block height and the block to be archived has a first index, the first archive file is obtained in the first archive area according to the first archive file identification, and the block to be archived is obtained in the first archive file according to the first storage location.

[0047] In some implementations, after obtaining the target block height of the block to be archived in the target blockchain, a submodule is searched for:

[0048] If the target block height is less than or equal to the first identification block height and greater than the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, obtain the selected second archive file in the second archive area, decompress the selected second archive file to the fourth archive area, and obtain the first archive file;

[0049] In the fourth archive area, a block to be archived is obtained in the first archive file according to the first storage location.

[0050] In some implementations, after obtaining the target block height of the block to be archived in the target blockchain, a submodule is searched for:

[0051] If the target block height is less than or equal to the second identification block height, and the to-be-archived block has a first index, then according to the first archive file identification, a selected third archive file is obtained in the third archive area, and the selected third archive file is decompressed to the fourth archive area to obtain the first archive file;

[0052] In the fourth archive area, a block to be archived is obtained in the first archive file according to the first storage location.

[0053] In some implementations, the search module further includes a management submodule, the fourth archive area includes a plurality of first archive files, and the management submodule is used to:

[0054] Obtaining the last access time corresponding to each first archive file in the fourth archive area;

[0055] Determine a first non-access time length corresponding to each first archive file according to the current time and the last access time corresponding to each first archive file;

[0056] Among the multiple first archive files, a to-be-deleted first archive file whose first non-access time exceeds a first preset time is determined, and the to-be-deleted first archive file is deleted from the fourth archive area.

[0057] In some embodiments, in the fourth archive area, after obtaining the block to be archived in the first archive file according to the first storage location, the management submodule is configured to:

[0058] storing the block to be archived in the fourth archive file of the fifth archive area;

[0059] A second index is set for the block to be archived in the fourth archive file, wherein the second index indicates a fourth archive file identifier of the fourth archive file in which the block to be archived is stored, and a second storage position of the block to be archived in the fourth archive file.

[0060] In some implementations, the fifth archive area includes a plurality of fourth archive files, and the management submodule is configured to:

[0061] Obtain the last access time corresponding to each fourth archive file in the fifth archive area;

[0062] Determine the second non-access time corresponding to each fourth archive file according to the current time and the last access time corresponding to each fourth archive file;

[0063] A fourth archive file to be deleted whose second non-access time length exceeds a second preset time length is determined, and the fourth archive file to be deleted is deleted from the fifth archive area.

[0064] In some embodiments, the storage module is further configured to:

[0065] If there are multiple target blockchains, a corresponding blockchain identifier is set for the archive file corresponding to each target blockchain in the first archive area, the second archive area, the third archive area, the fourth archive area and the fifth archive area.

[0066] A computer-readable storage medium stores a plurality of instructions, wherein the instructions are suitable for a processor to load to execute the steps in the above-mentioned blockchain archiving method.

[0067] A computer device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above-mentioned blockchain archiving method when executing the computer program.

[0068] A computer program product or computer program, the computer program product or computer program includes computer instructions, the computer instructions are stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium, and the processor executes the computer instructions to implement the steps in the above-mentioned blockchain archiving method.

[0069] In an embodiment of the present application, a block to be archived is obtained from a target blockchain of a target consensus node; the block to be archived is stored in a first archive file of a first archive area, and a first index is established for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file where the block to be archived is stored, and a first storage position of the block to be archived in the first archive file; when receiving a request from the target consensus node to obtain the block to be archived, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage position. In this way, by storing the block to be archived in the first archive file and setting a corresponding first index for the block to be archived, when it is necessary to find the block to be archived, the first archive file corresponding to the block to be archived can be directly found according to the first index, and the block to be archived can be extracted from the first archive file. Compared with the related art of directly traversing and searching for the block to be queried in the redundant archive data, the present application can find the block to be archived more efficiently and quickly, thereby improving the data processing efficiency of the archived block.

[0070] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0072] Figure 1 This is a schematic diagram of a blockchain archiving scenario provided by an embodiment of the present application;

[0073] Figure 2 This is another schematic diagram of a blockchain archiving scenario provided by an embodiment of the present application;

[0074] Figure 3 It is a flowchart of the blockchain archiving method provided in the embodiment of the present application;

[0075] Figure 4 is a schematic diagram of the data structure of the first archive file provided in an embodiment of the present application;

[0076] Figure 5 is another data structure diagram of the first archive file provided in an embodiment of the present application;

[0077] Figure 6 It is another flowchart of the blockchain archiving method provided by an embodiment of the present application;

[0078] Figure 7 This is another schematic diagram of a blockchain archiving scenario provided by an embodiment of the present application;

[0079] Figure 8 It is another flowchart of the blockchain archiving method provided by an embodiment of the present application;

[0080] Fig. 9 This is another schematic diagram of a blockchain archiving scenario provided by an embodiment of the present application;

[0081] Fig.10 It is another flowchart of the blockchain archiving method provided by an embodiment of the present application;

[0082] Fig.11 It is another flowchart of the blockchain archiving method provided by an embodiment of the present application;

[0083] Fig.12 It is a file schematic diagram of the target blockchain provided by the embodiment of the present application;

[0084] Fig.13 It is another flowchart of the blockchain archiving method provided by an embodiment of the present application;

[0085] Fig.14 It is a structural schematic diagram of a blockchain archiving device provided in an embodiment of the present application;

[0086] Fig.15 It is another structural schematic diagram of the blockchain archiving device provided in an embodiment of the present application;

[0087] Fig.16 It is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0088] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0089] It should be noted that in some processes described in the specification, claims and the above-mentioned drawings, multiple steps appearing in a specific order are included, but it should be clearly understood that these steps may not be executed in the order in which they appear in this document or may be executed in parallel. The step numbers are only used to distinguish different steps, and the numbers themselves do not represent any execution order. In addition, descriptions such as "first", "second" or "target" in this document are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0090] It is understandable that in the specific implementation of this application, it involves obtaining blockchain data and other related data. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0091] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations:

[0092] Blockchain: It is a chain of blocks. Each block stores certain information, and they are connected into a chain in the order of their generation. This chain is stored in all servers. As long as there is one server in the entire system that can work, the entire blockchain is safe. These servers are called nodes in the blockchain system, and they provide storage space and computing power support for the entire blockchain system. If you want to modify the information in the blockchain, you must obtain the consent of more than half of the nodes and modify the information in all nodes. These nodes are usually in the hands of different entities, so it is extremely difficult to tamper with the information in the blockchain. Compared with traditional networks, blockchain has two core characteristics: one is that data is difficult to tamper with, and the other is decentralization. Based on these two characteristics, the information recorded in the blockchain is more authentic and reliable, which can help solve the problem of people's distrust.

[0093] Block: A block has a main structure, including a block header and a block body. The data in the block header and the block body are block data.

[0094] Block Header: The block header stores the hash value of the previous block, the hash value of the current block, the random number, the timestamp, and the Merkle root.

[0095] Block Body: A block body contains a set of transactions or other data records, which are encoded and put together and are also calculated in the hash value of the entire block. The size of the block body can vary as needed, usually within a certain size limit.

[0096] Block height: Block height is the number of blocks linked to the main chain, that is, the number of blocks connected to the blockchain. The height of a block refers to the number of blocks between it and the genesis block in the blockchain. For example, a block height of 100 means that there are 100 blocks between this block and the genesis block.

[0097] Consensus node: A node that participates in consensus voting, transaction execution, block verification, and bookkeeping in the blockchain.

[0098] With the development of information technology, blockchain has become a commonly used distributed data storage technology. A node can store multiple blockchains, and the node stores the data corresponding to each blockchain. As the length or number of blockchains increases, the data stored in the node will also increase accordingly.

[0099] In the related art, the data stored in the node is archived to reduce the storage space occupied by the data on the node, that is, the data that is not used for a long time in the storage space of the node is migrated to the archive database to reduce the storage space occupied by the data on the node.

[0100] However, the data archiving method in the blockchain in the related technology is relatively simple. After the data stored in the node is archived to the database, the archived data is not differentiated and managed, resulting in relatively redundant archived data. When the node obtains and restores data from the archived database, it takes a long time to find the corresponding data in the database. Therefore, the related technology has low processing efficiency for archived data.

[0101] In order to solve the above technical problems, the embodiments of the present application provide a blockchain archiving method, device, storage medium and computer equipment. After archiving the block data corresponding to the blockchain, the blockchain archiving method can manage the archived block data, thereby improving the data processing efficiency of the archived blocks.

[0102] See also Figure 1 , Figure 1 This is a schematic diagram of the blockchain archiving scenario provided in an embodiment of the present application.

[0103] It is understandable that in the blockchain, each block stores certain information, and they are connected into a chain in the order of their generation. This chain is stored in the corresponding devices, which are called nodes. Each node of the blockchain stores complete data in a block chain structure. When the blockchain is updated, the corresponding device also needs to store the updated blockchain data. As the length of the blockchain increases, or as the number of blockchains increases, the data corresponding to the blockchain stored in each node also increases. In order to save the storage space of the node, the node can archive the blocks corresponding to some blockchains.

[0104] like Figure 1 As shown, device 1, device 2 and device 3 are all target consensus nodes corresponding to the blockchain, and server 1 and server 2 can be understood as databases. Device 1, device 2 and device 3 can archive the blocks that need to be backed up in the blockchain to server 1 and / or server 2, and then device 1, device 2 and device 3 can delete the archived blocks locally to save storage space. Among them, device 1, device 2 and device 3 delete the archived blocks, and can use data isolation to delete them for the blockchain, so as not to affect the update of the blockchain. At the same time, device 1, device 2 and device 3 will save the information of the archived blocks, such as the block height, hash value, etc.

[0105] Taking server 1 and device 1 as an example, device 1 is the target consensus node, and server 1 can obtain the blocks to be archived from the target blockchain of the target consensus node. For example, device 1 can upload at least part of the blocks of the stored target blockchain to server 1, and server 1 determines these uploaded blocks as blocks to be archived.

[0106] Server 1 stores the block to be archived in the first archive file of the first archive area, and establishes a first index for the block to be archived, wherein the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file.

[0107] When receiving a request from the target consensus node to obtain a block to be archived, server 1 obtains the first archive file in the first archive area according to the first archive file identifier, and obtains the block to be archived in the first archive file according to the first storage location.

[0108] Then, the server 1 sends the block to be archived to the device 1, and the device 1 can receive the block to be archived, thereby realizing data reading of the block to be archived.

[0109] That is to say, in the embodiment of the present application, the block to be archived can be set in the corresponding first archive file, and the first index can be set for the block to be archived. When it is necessary to find the block to be archived, the block to be archived can be found in the first archive file according to the first index. Compared with the related art of directly traversing the archived data to find the block to be queried, the present application can find the block to be archived more efficiently and quickly, thereby improving the data processing efficiency of the archived blocks.

[0110] See also Figure 2 , Figure 2 This is another schematic diagram of a blockchain archiving scenario provided by an embodiment of the present application.

[0111] like Figure 2 As shown, there are multiple archive centers, such as archive center 1, archive center 2, and archive center 3, and one archive center can store blocks corresponding to multiple blockchains, such as blocks corresponding to blockchain 1 can be stored in archive center 1, and blocks corresponding to blockchain 2 can be stored in archive center 1. Among them, one archive center can set corresponding blockchain identifiers for blocks corresponding to different blockchains to distinguish them.

[0112] Nodes corresponding to the same blockchain can share a copy of archived data, and node 1 of blockchain 1 and node 2 of blockchain 1 can share a copy of archived data in the archive center. For example, after node 1 of blockchain 1 archives certain blocks of blockchain 1, both node 1 and node 2 of blockchain 1 can read these archived blocks in the archive center.

[0113] The blocks of the blockchain can be archived to multiple archiving centers. For example, node 1 of blockchain 1 can archive the blocks that need to be archived to archiving center 1, and node 1 of blockchain 1 can also archive the blocks that need to be archived to archiving center 2.

[0114] That is to say, in the embodiment of the present application, the blockchain corresponding to the node can be archived and saved, and the node can also obtain a block in the blockchain from the archive center at any time to perform data recovery.

[0115] For a more detailed description of the blockchain archiving method provided in the embodiment of the present application, please continue to refer to Figure 3 , Figure 3 : is a flowchart of the blockchain archiving method provided by the embodiment of the present application. The following blockchain archiving method is considered from the perspective of the archiving center, or from the perspective of the server, and the blockchain archiving method may include the following steps:

[0116] In step 110, the block to be archived is obtained from the target blockchain of the target consensus node.

[0117] In some implementations, there are multiple types of nodes corresponding to the blockchain, and consensus nodes can implement more data interactions in the blockchain. For example, consensus nodes participate in consensus voting, transaction execution, block verification, and accounting in the blockchain.

[0118] The target consensus node can be determined from multiple consensus nodes. For example, if the storage space corresponding to some consensus nodes is not very large and continuing to store blockchain data will lead to insufficient storage space, these consensus nodes need to back up and archive the stored blockchain blocks. These consensus nodes can be determined as target consensus nodes. Alternatively, the consensus nodes that need to back up blockchain data can be directly identified as target consensus nodes.

[0119] In some embodiments, the target blockchain corresponding to the target consensus node is obtained. For example, the target consensus node may correspond to multiple blockchains, such as blockchain 1, blockchain 2, and blockchain 3. Some blockchains are newly generated, or some blockchains are short in length, and these blockchains do not need to be archived. Some blockchains are long in length, or some blockchains are generated for a long time. For data in some blocks that are not frequently read, these blockchains can be determined as target blockchains. Alternatively, the target blockchain is a blockchain that a target consensus node can actively select to be archived.

[0120] After obtaining the target blockchain, the block to be archived can be obtained from the target blockchain. The data in the block to be archived can be understood as read-only data that cannot be modified. The data in the block to be archived can be archived.

[0121] In some embodiments, some blocks may be randomly selected from the blocks in the target blockchain as blocks to be archived. For example, the number of blocks to be archived in the target blockchain may be first determined, and then the same number of blocks may be randomly selected from the blocks in the target blockchain as blocks to be archived.

[0122] In some implementations, obtaining a block to be archived from a target blockchain of a target consensus node includes:

[0123] (1.1) Obtaining a first threshold height;

[0124] (1.2) Obtain a block on the target blockchain whose block height is less than the first threshold height as the block to be archived.

[0125] Since the blocks at the first threshold height have a lower height in the target blockchain, they will not be read in the target blockchain or the probability of being read is low. Therefore, these blocks can be determined as blocks to be archived, and then archived, thereby saving the storage capacity consumed by the target consensus node when storing the blocks to be archived.

[0126] Specifically, for a target blockchain, the first threshold height corresponding to the target blockchain can be obtained. Blocks with block heights below the first threshold height can only be read and will not be modified, so these blocks can be archived.

[0127] A block on the target blockchain whose block height is less than the first threshold height can be obtained as a block to be archived. For example, if the first threshold height is 175502, then a block with a height of 154402 is a block to be archived. There are multiple blocks to be archived.

[0128] In step 120, the block to be archived is stored in the first archive file of the first archive area, and a first index is established for the block to be archived, wherein the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file.

[0129] In some implementations, the archiving center includes multiple archiving areas, wherein the first archiving area can be used to preliminarily archive the blocks to be archived, such as storing the blocks to be archived in the first archiving file of the first archiving area.

[0130] The first archive area includes multiple first archive files, each of which can be used to store data corresponding to multiple blocks to be archived. Each first archive file has a certain capacity limitation. For example, the capacity of each first archive file is 1024MB. When the capacity of a first archive file is completely occupied by the data corresponding to the blocks to be archived, the first archive file can no longer store the data corresponding to other blocks to be archived.

[0131] In some implementations, the blocks to be archived that can be stored in the first archive file in the first archive area can be limited, and each first archive file can only store a preset number of blocks to be archived. For example, a first archive file can only store ten blocks to be archived. After a first archive file stores ten blocks to be archived, it can no longer store blocks to be archived.

[0132] In some implementations, multiple first archive files may be preset in the first archive area according to the number of blocks to be archived, and then the blocks to be archived are randomly stored in any first archive file until all the blocks to be archived are stored in the first archive file.

[0133] In some implementations, storing the to-be-archived block in a first archive file in a first archive area includes:

[0134] (1.1) If the first archive area has not yet stored the first archive file, or the first archive area is full of first archive files, add a first document file to the first archive area, and serialize the blocks to be archived and store them in the added first archive file;

[0135] (1.2) If there is an incomplete first archive file in the first archive area, the blocks to be archived are serialized and stored in the incomplete first archive file.

[0136] In the first archive area, when storing the blocks to be archived into the first archive file, the next first archive file is added only when the current first archive file is full, and then the remaining blocks to be archived that have not been stored are stored in the first archive file until the next first archive file is full. And so on, until all the blocks to be archived are stored in the first archive file. In this way, it can be ensured that each first archive file can be fully stored, thereby ensuring the highest utilization rate of the first archive file and the minimum number of first archive files in the first archive area, avoiding the waste of storage space in the first archive area caused by setting too many first archive files. At the same time, when the number of first archive files is small, when searching for blocks to be queried later, a smaller number of first archive files can be searched, thereby improving the efficiency of searching for blocks to be archived.

[0137] Specifically, if the first archive file has not been stored in the first archive area, or the first archive files in the first archive area are full, it means that the block to be archived must be stored in a new first archive file. At this time, a first archive file that does not store any data can be added, and then the block to be archived can be serialized to obtain serialized data of the block to be archived, and finally the serialized data is stored in this first archive file that does not store any data.

[0138] If there is an incomplete first archive file in the first archive area, the blocks to be archived are serialized to obtain serialized data of the blocks to be archived, and then the serialized data is stored in the incomplete first archive file.

[0139] Among them, when the blocks to be archived are stored in the first archive file, they can be stored in order of their height. For example, if there are multiple blocks to be archived, they can be sorted from low to high according to their block heights to obtain a block height sorting result.

[0140] According to the block height sorting result, serialization processing is performed on the block to be archived with the lowest block height to obtain serialized data, and then the serialized data is stored in the current first archive file. Then, serialization processing is performed on the block to be archived with the next block height to obtain serialized data, and the serialized data is stored in the current first archive file, and so on, until the remaining capacity of the current first archive file cannot store the serialized data corresponding to the block to be archived.

[0141] Then, the remaining blocks to be archived are serialized to obtain serialized data of each remaining block to be archived, and the serialized data of each remaining block to be archived is stored in the next first archive file until the remaining capacity of the next first archive file cannot store the serialized data corresponding to the block to be archived. By analogy, the serialized data corresponding to multiple blocks to be archived can be stored in the corresponding first archive files, thus obtaining one, two or more first archive files.

[0142] Please also read Figure 4 , Figure 4 It is a schematic diagram of the data structure of the first archive file provided in an embodiment of the present application.

[0143] Among them, taking a first archive file as an example, block 1 is the block to be archived with the lowest block height. Block 1 can be serialized to obtain serialized data corresponding to block 1. For example, the block header of block 1 can be serialized to obtain serialized data corresponding to the block header of block 1. Then, each transaction in the block body of block 1 is serialized to obtain serialized data corresponding to each transaction. Other objects of block 1 can also be serialized to obtain corresponding serialized data. Other objects can be transaction logs, read-write logs, etc.

[0144] The serialized data may be byte text data, and the serialized data corresponding to the block header, transaction, other objects, etc. of block 1 may all be byte text data, and the serialized data corresponding to the block header, transaction, other objects, etc. of block 1 may be arranged in sequence to form the serialized data corresponding to block 1. For example, the serialized data corresponding to the block header may be arranged first, then the serialized data corresponding to transaction 1, then the serialized data corresponding to transaction 2, etc., to obtain the serialized data corresponding to block 1.

[0145] After obtaining the serialized data corresponding to block 1, the serialized data corresponding to block 1 can be written into the first archive file, and then the serialized data corresponding to block 2 at the next block height of block 1 can be serialized to obtain the serialized data corresponding to block 2, and the serialized data corresponding to block 2 can be written into the first archive file, and the serialized data corresponding to block 2 can be stored after the serialized data corresponding to block 1. And so on, until the capacity of the first archive file is completely occupied by the serialized data corresponding to the blocks to be archived.

[0146] It should be noted that the name of the first archive file can be determined according to the height of the block to be archived corresponding to the first serialized data written. For example, the common blockchain uses the uint64 data type, and the maximum value of the field of this data type is data with a length of 20 bytes. If the height of the block to be archived is 1, the file name of the first archive file is 00000000000000000001.fdb, where ".fdb" is the file format of the first archive file.

[0147] If a first archive file is writing serialized data and the capacity of the first archive file has not been fully occupied, the file format of the first archive file can be determined as ".fdb.END" to distinguish it from the first archive file that has been fully written with serialized data.

[0148] For the first archive file that has been filled with serialized data, the starting block height and the ending block height in the first archive file can be obtained. For example, when the serialized data corresponding to the blocks to be archived are stored from low to high according to the block height, the height of the block to be archived corresponding to the first serialized data written is determined as the starting block height, and the height of the block to be archived corresponding to the last serialized data written is determined as the ending block height. Among them, the ending block height of the first archive file can also be understood as the maximum height of the blocks to be archived contained in the first archive file on the target blockchain.

[0149] In some embodiments, after the serialized data corresponding to the block to be archived is written into the first archive file, it can be understood that the block to be archived is stored in the first archive file. In order to facilitate the subsequent finding of the block to be archived in the first archive file, a first index can be established for the block to be archived, wherein the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file.

[0150] The first index includes the file name of the first archive file corresponding to the block to be archived, and the file name can be used as the first archive file identifier. The first index also includes the first storage position of the block to be archived in the first archive file, and the first storage position of the block to be archived in the first archive file includes the starting storage position of the block to be archived in the first archive file and the length of the block to be archived. The first storage position also includes the corresponding starting point and end point of the serialized data of each transaction in the block to be archived in the first archive file.

[0151] Please also read Figure 5 , Figure 5 This is another data structure diagram of the first archive file provided in an embodiment of the present application.

[0152] Among them, in the archive data, the blockchain identifier of the target blockchain can be set, such as blockchain 1. Then, an archive file set is set, and the archive file set includes multiple first archive files, such as first archive file 1, first archive file 2, first archive file n, etc. Index information can also be set, wherein the index information includes the first index corresponding to the block to be archived, such as the first index 1 corresponding to block 1, the first index 2 corresponding to block 2, the first index n corresponding to block n, etc.

[0153] When subsequently searching for the corresponding block to be archived in the first archive file, the first archive file corresponding to the block to be archived can be found through the first index, and then the serialized data corresponding to the block to be archived can be searched in the first archive file according to the first index. Finally, the serialized data corresponding to the block to be archived can be deserialized to obtain the original data of the block to be archived.

[0154] By setting a first archive file to store blocks to be archived and setting a corresponding first index for the blocks to be archived, the blocks to be archived are managed and distinguished. When searching for the blocks to be archived subsequently, the blocks to be archived can be quickly found according to the first index, thereby improving the processing efficiency of the archived data.

[0155] In some implementations, after the blocks to be archived are stored in the first archive file in the first archive area and a first index is created for the blocks to be archived, some first archive files in the first archive area may be transferred to the second archive area for storage.

[0156] It is understandable that the first archive area is suitable for storing first archive files corresponding to the newly archived to-be-archived blocks. As the number of first archive files in the first archive area increases, some first archive files may not be used or accessed for a long time. These first archive files may be transferred from the first archive area to the second archive area, thereby saving storage space in the first archive area.

[0157] Please also read Figure 6 , Figure 6 This is another flowchart of the blockchain archiving method provided by the embodiment of the present application. Specifically, it includes:

[0158] In step 201, a second threshold height is obtained.

[0159] In some implementations, since the blocks to be archived in the first archive file are stored in order of block height from low to high, a second threshold height may be specified, and the first archive file corresponding to the blocks to be archived below the second threshold height needs to be transferred and stored. For example, if the first archive file corresponding to the blocks to be archived below a certain height is rarely accessed or used, it means that the first archive file corresponding to the blocks to be archived below the height may be transferred and stored, and the height is confirmed as the second threshold height.

[0160] In some embodiments, before determining the first archive file to be compressed based on a comparison of the second threshold height and the end block heights of each first archive file, it is also necessary to judge the second threshold height to confirm whether the second threshold height is applicable to determining the first archive file to be compressed among multiple first archive files.

[0161] Please refer to Table 1 for details:

[0162] First archive file Contains blocks to be archived 00000000000000000001.fdb 0～176517 00000000000000176518.fdb 176518～352656 00000000000000352657.fdb 352657～528795 00000000000000528796.fdb 528796～704934 00000000000000704935.fdb.END 704935～881074

[0163] Table 1

[0164] As shown in Table 1, the first archive area includes multiple first archive files in Table 1, and each first archive file includes multiple blocks to be archived. For example, the first archive file 000000000000000000001.fdb includes highly consecutive blocks 1 to 176517 to be archived.

[0165] Please also refer to Table 2:

[0166]

[0167]

[0168] Table 2

[0169] Combining Table 1 and Table 2, when the second threshold height is 100000, the second threshold height is within the height range of 0 to 176517 of the first archive file 000000000000000000001.fdb. Since the first archive file is the first archive file generated, it means that the second threshold height is set too low, and the first archive file 000000000000000000001.fdb cannot be compressed.

[0170] When the second threshold height is 350000, at this time the second threshold height is within the height range of 176518 to 352656 of the first archive file 000000000000000176518.fdb, and the second threshold height is not equal to the end block height 352656 of the first archive file 00000000000000176518.fdb, then at this time the first archive file 000000000000000176518.fdb is not allowed to be compressed.

[0171] When the second threshold height is 352656, at this time the second threshold height is within the height range of 176518 to 352656 of the first archive file 00000000000000176518.fdb, and the second threshold height is the end block height 352656 of the first archive file 00000000000000176518.fdb, then at this time the first archive file 000000000000000176518.fdb is allowed to be compressed.

[0172] When the second threshold height is 530000, the second threshold height is within the height range of 528796 to 704934 of the first archive file 00000000000000528796.fdb, and the second threshold height is not the end block height 704934 of the first archive file 00000000000000528796.fdb. At this time, the first archive file 000000000000000528796.fdb cannot be compressed. The end block heights corresponding to the first archive file 0000000000000000001.fdb, the first archive file 000000000000000176518.fdb, and the first archive file 000000000000000352657.fdb are all less than the second threshold height, indicating that the three first archive files can be compressed.

[0173] When the second threshold height is 720000, the second threshold height is within the height range of 704935 to 881074 of the first archive file 00000000000000704935.fdb.END, but the first archive file 00000000000000704935.fdb.END is not full of data, indicating that the first archive file 00000000000000704935.fdb.END cannot be compressed. The end block heights corresponding to the first archive file 00000000000000000001.fdb, the first archive file 000000000000000176518.fdb, the first archive file 000000000000000352657.fdb, and the first archive file 000000000000000528796.fdb are all less than the second threshold height, which means that the four first archive files can be compressed.

[0174] Therefore, when actually obtaining the second threshold height, it is necessary to judge the second threshold height to determine whether the second threshold height is suitable for compressing the first archive file.

[0175] In step 202, based on the comparison between the second threshold height and the end block height of each first archive file, the first archive file to be compressed is determined.

[0176] The specified second threshold height may be a height between a start block height and an end block height in a first archive file. The specified second threshold height may also be an end block height in a first archive file.

[0177] If the second threshold height is between the start block height and the end block height of a first archive file, then the first archive file cannot be determined as the first archive file to be compressed. If the second threshold height is also the end block height of a first archive file, then the first archive file can be determined as the first archive file to be compressed. If the end block height of a first archive file is less than the second threshold height, then the first archive file can be determined as the first archive file to be compressed.

[0178] Therefore, it is necessary to compare the second threshold height with the end block height of each first archive file to obtain a comparison result, and then determine the first archive file to be compressed from the multiple first archive files in the first archive area based on the comparison result.

[0179] In some embodiments, the end block heights of all first archive files may be obtained, and then the end block height of each first archive file is compared with the second threshold height. If the end block height of a first archive file is less than or equal to the second threshold height, the first archive file is determined to be the first archive file to be compressed.

[0180] In some implementations, determining the first archive files to be compressed based on a comparison between the second threshold height and the end block heights of each first archive file includes:

[0181] (2.1) sorting the plurality of first archive files from small to large according to the end block height;

[0182] (2.2) if the second threshold height is equal to the end block height of a first archive file, the first archive file and the first archive file before the first archive file in the sorting are determined as the first archive files to be compressed;

[0183] (2.3) If the second threshold height is less than the end block height of a first archive file in the sort, but greater than the end block height of the previous first archive file in the sort, the previous first archive file and the first archive file in front of the previous first archive file in the sort are determined as the first archive files to be compressed.

[0184] By sorting the first archive files according to the end block height and then comparing the sorting result with the second threshold height, all the first archive files to be compressed can be directly determined at one time from multiple first archive files, thereby improving the efficiency of determining the first archive files to be compressed.

[0185] Specifically, among the multiple first archive files in the first archive area, the end block height of each first archive file can be determined, and then they are sorted from small to large according to the end block height, so as to achieve sorting of each first archive file.

[0186] If the second threshold height is equal to the end block height of a first archive file, for example, the second threshold height is 10000, and among the multiple first archive files, the end block height of one of the first archive files is 10000, then the first archive file and the first archive file before the first archive file in the sorting are determined as the first archive files to be compressed, for example, the first archive file with the end block height of 780 is determined as the first archive file to be compressed.

[0187] If the second threshold height is less than the end block height of a first archive file in the sort, but greater than the end block height of the previous first archive file in the sort, for example, the end block height of the first archive file 1 is 1000, the previous first archive file of the first archive file 1 is the first archive file 2, the end block height of the first archive file 2 is 800, and the second threshold height is 900, then the second threshold height is greater than the end block height of the first archive file 2, but less than the end block height of the first archive file 1.

[0188] At this time, the previous first archive file and the first archive file that is ahead of the previous first archive file in the sorting are determined as the first archive files to be compressed. For example, the first archive file 2 and the first archive file whose end block height is less than the end block height of the first archive file 2 are determined as the first archive files to be compressed, that is, the first archive file whose end block height is less than 800 is determined as the first archive file to be compressed.

[0189] In step 203, the first archive file to be compressed is compressed as a second archive file, the second archive file is stored in the second archive area, and the first archive file to be compressed is deleted from the first archive area.

[0190] After determining the first archive file to be compressed, a compression algorithm may be used to compress the first archive file to be compressed, for example, a common 7z compression algorithm, a rar compression algorithm, a zip compression algorithm, etc., so as to obtain a second archive file.

[0191] It can be understood that the second archive file is compared with the corresponding first archive file to be compressed, and the data volume of the second archive file is smaller than that of the first archive file to be compressed after compression, and the file format of the second archive file is changed, and the name of the second archive file is the same as that of the first archive file to be compressed. For example, the full name of the first archive file to be compressed is "00000000000000000001.fdb", and the full name of the second archive file is "0000000000000000001.fdb.7z".

[0192] After the second archive file is obtained, the second archive file can be transferred and stored in the second archive area, and then the first archive file to be compressed in the first archive area is deleted, thereby saving storage space in the first archive area.

[0193] In some embodiments, after the second archive file is stored in the second archive area, the end block height of the maximum height can be determined as the first identification block height among the end block heights corresponding to each second archive file. The first identification block height can be used to distinguish the archive files stored in the first archive area and the second archive area, for example, the starting block height of all the first archive files in the first archive area is greater than the first identification block height, and the end block height of the second archive files in the second archive area is less than or equal to the first identification block height.

[0194] For a more detailed understanding of the process of transferring files in the first filing area to the second filing area in the embodiment of the present application, please continue to refer to Figure 7 , Figure 7 This is another schematic diagram of a blockchain archiving scenario provided by an embodiment of the present application.

[0195] The archive center corresponds to multiple archive areas, for example, the archive center corresponds to the first archive area, the second archive area, the third archive area, the fourth archive area and the fifth archive area. The third archive area can be understood as a data cold storage area corresponding to the archive center.

[0196] The archiving center can determine the first archive file to be compressed from multiple first archive files in the first archiving area, then compress the first archive file to be compressed to obtain a second archive file, then store the second archive file in the second archiving area, and then delete the first archive file to be compressed in the first archiving area.

[0197] Specifically, in the process of determining the first archive file to be compressed from the multiple first archive files in the first archive area, the archive center can obtain the second threshold height, sort the multiple first archive files from small to large according to the end block height, and if the second threshold height is equal to the end block height of a first archive file, the first archive file and the first archive file before the first archive file in the sorting are determined as the first archive file to be compressed; if the second threshold height is less than the end block height of a first archive file in the sorting, but greater than the end block height of the previous first archive file in the sorting, the previous first archive file and the first archive file before the previous first archive file in the sorting are determined as the first archive file to be compressed. Then, the first archive file to be compressed is compressed as the second archive file, the second archive file is stored in the second archive area, and the first archive file to be compressed is deleted from the first archive area.

[0198] That is to say, in the embodiment of the present application, the archiving center can set up different archiving areas, such as the first archiving area and the second archiving area, and then store the first archiving file corresponding to the block to be compressed in the first archiving area, compress the first archiving file corresponding to the block to be compressed as the second archiving file, and store the second archiving file in the second archiving area, thereby achieving the management distinction of the archiving files corresponding to the block to be archived. In this way, when the archiving center needs to search for the block to be archived later, the archiving center can search for the archiving file from the corresponding archiving area, and then determine the block to be archived from the archiving file, so as to quickly find the block to be archived, thereby improving the archiving center's processing efficiency of archived data.

[0199] In some embodiments, after compressing the first archive file to be compressed to obtain the second archive file and storing the second archive file in the second archive area, some second archive files with a relatively long archive time in the second archive area can also be transferred and stored in the third archive area.

[0200] It is understandable that, as the second archive files are gradually stored in the second archive area, the second archive files in the second archive area will occupy more and more storage space, resulting in the remaining storage space in the second archive area becoming smaller and smaller.

[0201] At the same time, in order to further manage the archive files corresponding to the archive blocks, the second archive files in the second archive area can be managed, a part of the second archive files can be used as the third archive files, and then the third archive files can be stored in the third archive area, thereby saving storage space in the second archive area.

[0202] Please also read Figure 8 , Figure 8 This is another flowchart of the blockchain archiving method provided by the embodiment of the present application. Specifically, it includes:

[0203] In step 301, among the second archive files in the second archive area, a second archive file whose archive time is before a predetermined time point is determined as a third archive file.

[0204] In some implementations, the filing time corresponding to each second filing file in the second filing area is determined, and then the second filing files with filing times before the predetermined time point are used as the third filing files. For example, if the predetermined time point is 9:00 on August 30, 2023, the second filing files in the second filing area before 9:00 on August 30, 2023 are used as the third filing files.

[0205] In some implementations, determining, among the second archived files in the second archived area, the second archived files whose archived time is before the predetermined time point as the third archived files includes:

[0206] (3.1) determining, in the second archive file in the second archive area, a target second archive file corresponding to a predetermined time point;

[0207] (3.2) Determine the starting block height of the target second archive file;

[0208] (3.3) The target second archive file and the second archive file whose end block height is less than the start block height of the target second archive file are determined as the third archive file.

[0209] Since the blocks to be archived are stored in order of height from small to large, after the current first archive file is full, the remaining blocks to be archived are stored in the next first archive file according to the height order. Therefore, the block height order of each first archive file is certain, and the second archive file is a compressed file of the first archive file, so the block height order corresponding to each second archive file is also certain. By determining the target second archive file corresponding to the predetermined time point, and then according to the starting block height of the target second archive file, the second archive file whose end block height is less than the starting block height of the target second archive file is determined as the third archive file. It can avoid mistaking some second archive files for the third archive file, and can more accurately determine the third archive file among multiple second archive files, thereby achieving more reliable data differentiation management.

[0210] Specifically, in the second archive file in the second archive area, the target second archive file corresponding to the predetermined time point is first determined. For example, the predetermined time point is 9:00 on August 30, 2023, and then the second archive file corresponding to 9:00 on August 30, 2023 is determined. The second archive file is determined as the target second archive file.

[0211] Then determine the starting block height of the target second archive file. Since the target second archive file is obtained by compressing the first archive file, the starting block height of the target second archive file is actually the starting block height of the corresponding first archive file. Since the file name of the target second archive file is the same as the file name of the corresponding first archive file, the first archive file has recorded the starting block height and the ending block height after storing the block to be archived. At this time, the starting block height of the first archive file corresponding to the target second archive file can be directly determined as the starting block height of the target second archive file.

[0212] Among the multiple second archive files in the second archive area, a second archive file whose end block height is smaller than the start block height of the target second archive file is determined and determined as the third archive file, and the target second archive file is also confirmed as the third archive file.

[0213] In step 302, the third archive file is stored in the third archive area, and the third archive file is deleted in the second archive area.

[0214] Then the third archive file is stored in the third storage area, and then the third archive file in the second archive area is deleted, thereby saving the storage space of the second archive area, and the third archive file can be further subdivided and managed. By subdividing the third archive file, when the subsequent target consensus node searches for the to-be-archived block in the archive center, it can first determine the archive area corresponding to the to-be-archived block to be checked, and then find the corresponding archive file in the corresponding archive area, and finally obtain the to-be-archived block to be queried from the archive file. It avoids traversing all the archived data to search for the to-be-archived block to be queried, thereby improving the processing efficiency of the archived data.

[0215] It should be noted that after storing the third archive file in the third storage area, the end block height of the maximum height is determined as the second identification block height in the end block height corresponding to each third archive file, and the second identification block height is recorded. The second identification block height can be used to distinguish the files stored in the second archive area and the third archive area. For example, the starting block height of all second archive files in the second archive area is greater than the second identification block height, and the end block height of the third archive file in the third archive area is less than or equal to the second identification block height.

[0216] For a more detailed understanding of the process of transferring files in the second filing area to the third filing area in the embodiment of the present application, please continue to refer to Figure 7 , where the third archiving area can be understood as a data cold storage area corresponding to the archiving center. For example, the third archiving area is an independent storage space, such as a storage space constructed by cheap storage devices such as tapes and optical disks, or the third archiving area can be a low-cost cloud storage space.

[0217] Please also read Fig. 9 , Fig. 9 This is another schematic diagram of a blockchain archiving scenario provided by an embodiment of the present application.

[0218] Among them, the third archiving area can be an archiving area in the archiving center, and the third archiving area can be understood as a cold storage area in the archiving center.

[0219] The archiving center can determine the third archive file from the multiple second archive files in the second archive area, then store the third archive file in the third archive area, and delete the third archive file in the second archive area.

[0220] Specifically, the archiving center can determine the target second archive file corresponding to the predetermined time point in the second archive file of the second archive area; determine the starting block height of the target second archive file; determine the target second archive file and the second archive file whose ending block height is less than the starting block height of the target second archive file as the third archive file. Then, the third archive file is stored in the third archive area, and the third archive file is deleted in the second archive area.

[0221] That is to say, in the embodiment of the present application, the archiving center can establish different archiving areas, such as the second archiving area and the third archiving area, and then store the second archived file in the second archiving area. In the second archived file in the second archiving area, the second archived file with an archived time before the predetermined time point is determined as the third archived file, and the third archived file is stored in the third archiving area, thereby achieving the management distinction of the archived files corresponding to the to-be-archived blocks. In this way, when the archiving center needs to search for the to-be-archived blocks in the future, the archiving center can search for the archived files from the corresponding archiving area, and then determine the to-be-archived blocks from the archived files, thereby quickly finding the to-be-archived blocks, thereby improving the archiving center's processing efficiency of the archived data.

[0222] It should be noted that after a first archive file is compressed, a second archive file is obtained. The first archive file and the second archive file have the same file name, but only have different file formats. Therefore, the first index to be set for archiving, wherein the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file. The first index is also applicable to the second archive file. For example, if the block to be archived is in the second archive file in the second archive area, the second archive file corresponding to the block to be archived can be determined in the second archive area through the first archive file identifier. Similarly, since the third archive file is determined from the second archive file, the first index is also applicable to the third archive file.

[0223] As can be seen from the above, in the process of archiving the blocks to be archived of the target blockchain, the archive files corresponding to the blocks to be archived can be distinguished and managed through different archive areas. For example, the first archive file corresponding to the block to be archived is in the first archive area, or the second archive file corresponding to the block to be archived is in the second archive area, or the third archive file corresponding to the block to be archived is in the third archive area. In this way, the archive files corresponding to the blocks to be archived are divided in detail, thereby saving the storage space of the archive center while ensuring the data reliability of the blocks to be archived. At the same time, when searching for the blocks to be archived later, the archive area corresponding to the blocks to be archived can be quickly found, and then the archive file corresponding to the blocks to be archived can be found in the archive area, and finally the blocks to be archived can be found in the archive file. Thereby, the processing efficiency of archived data is improved.

[0224] In step 130, when a request for obtaining a block to be archived is received from the target consensus node, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage location.

[0225] It can be understood that after archiving the blocks to be archived corresponding to the target blockchain, when the target consensus node needs to read and use the blocks to be archived, it can send a request to the archiving center to obtain the blocks to be archived, and then the archiving center returns the data corresponding to the blocks to be archived to the target consensus node.

[0226] In some implementations, before obtaining the first archive file in the first archive area according to the first archive file identifier and obtaining the to-be-archived block in the first archive file according to the first storage location, the following may also be performed:

[0227] When receiving a request from the target consensus node for obtaining a block to be archived, the target block height of the block to be archived in the target blockchain is obtained.

[0228] For example, the acquisition request includes the height information corresponding to the block to be archived, and the target block height of the block to be archived is determined by the height information.

[0229] According to the first archive file identifier, the first archive file is obtained in the first archive area, and according to the first storage location, the to-be-archived block is obtained in the first archive file, including:

[0230] If the target block height is greater than the first identification block height and the block to be archived has a first index, the first archive file is obtained in the first archive area according to the first archive file identification, and the block to be archived is obtained in the first archive file according to the first storage location.

[0231] Specifically, the target block height can be compared with the first identification block height. Since the first identification height is the compression height corresponding to the second archive area, if the target block height is greater than the first identification block height, it means that the block to be archived is in the first archive area.

[0232] Since a corresponding first index is established for each block in the archiving center when archiving, if the block to be archived has a first index, the first archive file identifier is determined according to the first index, and then the first archive file is obtained in the first archiving area according to the first archive file identifier.

[0233] In some embodiments, after obtaining the first archive file corresponding to the block to be archived, the serialized data stored in the first archive file can be deserialized to obtain multiple blocks to be archived, and then the block to be archived that needs to be found can be found from the multiple blocks to be archived.

[0234] In some implementations, a first storage location corresponding to the block to be archived is determined according to the first index, and then the block to be archived is obtained in the first archive file according to the first storage location.

[0235] The first storage position of the to-be-archived block in the first archive file includes the starting storage position of the to-be-archived block in the first archive file and the length of the to-be-archived block. According to the first storage position, obtaining the to-be-archived block in the first archive file includes:

[0236] (1.1) Locate the starting point of the block to be archived in the first archive file according to the starting storage position;

[0237] (1.2) Locate the end point of the block to be archived in the first archive file according to the length;

[0238] (1.3) Extract the portion between the start point and the end point in the first archive file as the block to be archived.

[0239] By using the starting storage position and the length of the block to be archived, only the serialized data corresponding to the block to be archived that needs to be found can be extracted from the serialized data in the first archive file, and then deserialized to obtain the block to be archived. This achieves the extraction of the data to be found in the first archive file, thereby improving the efficiency of data search in the first archive file.

[0240] Specifically, the data in the first archive file are all serialized data, and each serialized data corresponding to the block to be archived has a corresponding storage position in the first archive file. The starting point of the block to be archived can be located in the first archive file according to the starting storage position of the block to be archived.

[0241] Then starting from the starting point, the end point of the block to be archived is located in the first archive file according to the length of the serialized data corresponding to the block to be archived. The serialized data between the starting point and the end point is the serialized data corresponding to the block to be archived, which can also be understood as the block to be archived.

[0242] After obtaining the serialized data corresponding to the block to be archived, the serialized data can be deserialized to obtain the original data corresponding to the block to be archived. The original data can be understood as the data contained in the block header and block body in the block to be archived.

[0243] After finding the blocks to be archived, the archiving center can send the blocks to be archived to the target consensus node. After the target consensus node receives the blocks to be archived, it can restore the data of the blocks to be archived.

[0244] It is understandable that a plurality of archiving areas are correspondingly arranged in the archiving center, and the archiving file of the to-be-archived block corresponding to the acquisition request may be stored in other archiving areas other than the first archiving area.

[0245] In some embodiments, when a request to obtain a block to be archived is received from a target consensus node, an archive file corresponding to the block to be archived may be searched in each archive area, and then the archive block may be obtained from the archive file.

[0246] In some embodiments, after obtaining the target block height of the block to be archived in the target blockchain, the method further includes:

[0247] (2.1) If the target block height is less than or equal to the first identification block height and greater than the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, obtain the selected second archive file in the second archive area, decompress the selected second archive file to the fourth archive area, and obtain the first archive file;

[0248] (2.2) In the fourth archive area, according to the first storage location, obtain the block to be archived in the first archive file.

[0249] The first identified height is the compression height corresponding to the second filing area, and the second identified height is the refrigeration height corresponding to the third filing area. If the target block height is less than or equal to the first identified block height and greater than the second identified block height, it means that the archived file corresponding to the block to be archived is in the second filing area.

[0250] By using the first identification height, the second identification height, and the target block height, it is possible to directly determine in which archive area the to-be-archived block to be found is located, thus avoiding searching for archive files corresponding to the to-be-archived block in multiple archive areas, thereby improving the efficiency of searching for archived blocks.

[0251] Then, the first index corresponding to the block to be archived is obtained. If the block to be archived has the first index, the first archive file identifier is obtained according to the first index, and then the selected second archive file is obtained in the second archive area according to the first archive file identifier. It should be noted that since the second archive file in the second archive area is obtained by compressing the first archive file to be compressed, after compression, the name of the obtained second archive file is the same as the name of the first archive file to be compressed, and the two are only different in file format. Therefore, the selected second archive file can be obtained in the second archive area through the first archive file identifier, and the selected second archive file contains the data corresponding to the block to be archived, that is, it contains the block to be archived.

[0252] It is understandable that, since the selected second archive file is compressed, if the block to be archived is to be obtained, the selected second archive file needs to be decompressed. Therefore, the selected second archive file is decompressed to obtain the first archive file corresponding to the block to be archived, and then the first archive file is stored in the fourth archive area. At this time, the selected second archive file is still saved in the second archive area to prevent the archived data from being lost.

[0253] Please combine Figure 7 The fourth archive area can be understood as a storage area for decompressed files. When the second archive files in the second archive area are decompressed, the decompressed files are actually the first archive files, and then these first archive files are stored in the fourth archive area.

[0254] Then, in the fourth archive area, the first storage position corresponding to the block to be archived is determined according to the first index, and the block to be archived is obtained in the first archive file according to the first storage position. For example, the first storage position of the block to be archived in the first archive file includes the starting storage position of the block to be archived in the first archive file and the length of the block to be archived. According to the starting storage position, the starting point of the block to be archived is located in the first archive file. Then, according to the length, the ending point of the block to be archived is located in the first archive file. Finally, the part between the starting point and the ending point in the first archive file is extracted as the block to be archived.

[0255] The portion between the start point and the end point in the extracted first archive file is the serialized data corresponding to the block to be archived, and the serialized data can be deserialized to obtain the original data of the block to be archived.

[0256] After obtaining the block to be archived, the block to be archived can be sent to the target consensus node, so that the target consensus node can restore the data of the block to be archived.

[0257] It is understandable that a plurality of archiving areas are correspondingly arranged in the archiving center, and the archiving file of the to-be-archived block corresponding to the acquisition request may be stored in a third archiving area outside the first archiving area and the second archiving area.

[0258] In some embodiments, after obtaining the target block height of the block to be archived in the target blockchain, the method further includes:

[0259] (3.1) If the target block height is less than or equal to the second identifier block height, and the block to be archived has a first index, then according to the first archive file identifier, obtain a selected third archive file in the third archive area, decompress the selected third archive file to the fourth archive area, and obtain the first archive file;

[0260] (3.2) In the fourth archive area, according to the first storage location, obtain the block to be archived in the first archive file.

[0261] Among them, the second identification block height is the cold storage height corresponding to the third archiving area. If the target block height is less than or equal to the second identification block height, it means that the archive file corresponding to the block to be archived is in the third archiving area.

[0262] By using the first identification height, the second identification height, and the target block height, it is possible to directly determine in which archive area the to-be-archived block to be found is located, thus avoiding searching for archive files corresponding to the to-be-archived block in multiple archive areas, thereby improving the efficiency of searching for archived blocks.

[0263] Then, the first index corresponding to the block to be archived is obtained. If the block to be archived has the first index, the first archive file identifier is obtained according to the first index, and then the selected third archive file is obtained in the third archive area according to the first archive file identifier. It should be noted that since the third archive file in the third archive area is obtained by compressing the first archive file to be compressed, after compression, the name of the third archive file obtained is the same as the name of the first archive file to be compressed, and the two are only different in file format. Therefore, the selected third archive file can be obtained in the third archive area through the first archive file identifier, and the selected third archive file contains the data corresponding to the block to be archived, that is, it contains the block to be archived.

[0264] It is understandable that, since the selected third archive file is compressed, if the block to be archived is to be obtained, the selected third archive file needs to be decompressed. Therefore, the selected third archive file is decompressed, and the first archive file corresponding to the block to be archived is obtained after decompression, and then the first archive file is stored in the fourth archive area. At this time, the selected third archive file is still saved in the third archive area to prevent the archived data from being lost.

[0265] Please combine Figure 7The fourth archive area can be understood as a storage area for decompressed files. When the third archive files in the third archive area are decompressed, the decompressed files are actually the original first archive files, and then these first archive files are stored in the fourth archive area.

[0266] Then, in the fourth archive area, the first storage position corresponding to the block to be archived is determined according to the first index, and the block to be archived is obtained in the first archive file according to the first storage position. For example, the first storage position of the block to be archived in the first archive file includes the starting storage position of the block to be archived in the first archive file and the length of the block to be archived. According to the starting storage position, the starting point of the block to be archived is located in the first archive file. Then, according to the length, the ending point of the block to be archived is located in the first archive file. Finally, the part between the starting point and the ending point in the first archive file is extracted as the block to be archived.

[0267] The portion between the start point and the end point in the extracted first archive file is the serialized data corresponding to the block to be archived, and the serialized data can be deserialized to obtain the original data of the block to be archived.

[0268] After obtaining the block to be archived, the block to be archived can be sent to the target consensus node, so that the target consensus node can restore the data of the block to be archived.

[0269] From the above, it can be seen that the first archive file stored in the fourth archive area is obtained by decompressing the second archive file from the second archive area, and the first archive file stored in the fourth archive area is obtained by decompressing the third archive file from the third archive area.

[0270] In some embodiments, the fourth archive area includes multiple first archive files, some of which have not been accessed for a long time. The first archive files that have not been accessed for a long time need to be deleted to save storage space in the fourth archive area.

[0271] Please also read Fig.10 , Fig.10 This is another flowchart of the blockchain archiving method provided by the embodiment of the present application. It may include:

[0272] In step 401, the last access time corresponding to each first archive file in the fourth archive area is obtained.

[0273] It can be understood that multiple first archive files in the fourth archive area can be accessed. For example, when receiving a request to obtain a block to be archived corresponding to any target consensus node, the archive center can give priority to searching for the first archive file corresponding to the block to be archived in the fourth archive area. If the first archive file corresponding to the block to be archived is in the fourth archive area, the block to be archived is directly obtained from the first archive file in the fourth archive area.

[0274] Considering that some first archive files in the fourth archive area may not be accessed for a long time, these first archive files that have not been accessed for a long time may be deleted, thereby saving storage space in the fourth archive area.

[0275] When each first archive file in the fourth archive area is accessed, the access time of each first archive file can be recorded, and then the last access time corresponding to each first archive file can be determined from the access time of each first archive file.

[0276] In step 402, a first non-access time length corresponding to each first archive file is determined according to the current time and the last access time corresponding to each first archive file.

[0277] According to the current time and the last access time corresponding to each first archive file, the first non-access time corresponding to each first archive file is determined. For example, if the last access time of a first archive file in the fourth archive area is 10:00 on August 23, 2023, and the current time is 11:00 on August 24, 2023, then the first non-access time corresponding to the first archive file is 25 hours. In this way, the first non-access time corresponding to each first archive file in the fourth archive area can be obtained.

[0278] In step 403, among the multiple first archive files, a to-be-deleted first archive file whose first non-access time exceeds a first preset time is determined, and the to-be-deleted first archive file is deleted from the fourth archive area.

[0279] Among the multiple first archive files, a first archive file to be deleted whose first non-access time exceeds a first preset time is determined, and the first archive file to be deleted is deleted from the fourth archive area. For example, if the first preset time is 24 hours, and the first non-access time corresponding to a first archive file is 25 hours, the first archive file is regarded as the first archive file to be deleted, and then the first archive file to be deleted is deleted from the fourth archive area.

[0280] Specifically, please refer to Table 3:

[0281]

[0282] Table 3

[0283] Among them, the first archive files in Table 3 are all first archive files in the fourth archive area. The last access time of each first archive file can be obtained. If the current time is: 1:44:45 on June 21, 2023, the first preset time is 24 hours. Then, the current time is compared with the last access time of each first archive file in Table 3. If the first non-access time corresponding to the first archive file 00000000000000176519.fdb and the first archive file 00000000000000352658.fdb respectively exceeds 24 hours, the first archive file 00000000000000176519.fdb and the first archive file 00000000000000352658.fdb are deleted in the fourth archive area. If the first non-access time length corresponding to the first archive file 00000000000000352658.fdb does not exceed 24 hours, the first archive file 00000000000000352658.fdb is retained in the fourth archive area.

[0284] In some embodiments, when receiving a request from a target consensus node to obtain a block to be archived, if an archive file corresponding to the block to be archived is found in the second archive area or the third archive area, then the first archive file corresponding to the block to be archived is decompressed in the fourth archive area. In the fourth archive area, the block to be archived is obtained from the first archive file according to the first storage position. After obtaining the block to be archived, the block to be archived can be stored in the fifth archive area, which can be understood as a hot data storage area, which can be used to store the most recently accessed block to be archived.

[0285] In the fourth archiving area, after obtaining the to-be-archived block in the first archive file according to the first storage location, the following may be further performed:

[0286] (4.1) storing the block to be archived in the fourth archive file of the fifth archive area;

[0287] (4.2) Setting a second index for the block to be archived in the fourth archive file, wherein the second index indicates a fourth archive file identifier of the fourth archive file in which the block to be archived is stored, and a second storage position of the block to be archived in the fourth archive file.

[0288] It is understandable that the block to be archived is the most recently accessed block and may be accessed again by some target consensus nodes later. Therefore, it can be transferred to the fourth archive file in the fifth archive area for some target consensus nodes to access the block to be archived next time. This avoids the need to search for the block to be archived again in the first archive area, the second archive area, or the third archive area with more archive files, and can be searched in the fifth archive area with fewer archive files, thereby improving the search efficiency of the block to be archived.

[0289] When the serialized data corresponding to the block to be archived is read in the first archive file in the fourth archive area, the serialized data can be directly stored in the fourth archive file, except that the storage location of the serialized data corresponding to the block to be archived has changed, and the serialized data corresponding to the block to be archived can be considered as the block to be archived itself.

[0290] Please also read Figure 7 The fifth archiving area can be understood as a hot data storage area, and the fifth archiving area can store recently accessed blocks to be archived. However, the recently accessed blocks to be archived stored in the fifth archiving area only come from the fourth archiving area.

[0291] Among them, the fourth archive file is similar to the first archive file, and is a file for storing serialized data corresponding to the blocks to be archived. The fourth archive file also has certain storage capacity restrictions, such as the storage capacity limit of the fourth archive file is 1024MB. However, the heights of the blocks to be archived stored in the fourth archive file are discontinuous. For example, a block to be archived with a block height of 1 can be stored in the fourth archive file, and a block to be archived with a block height of 8 can also be stored in the fourth archive file. The block heights of these two blocks to be archived are discontinuous.

[0292] Specifically, please refer to Table 4:

[0293]

[0294] Table 4

[0295] Among them, taking the fourth archive file 000000000000000000000.fdb as an example, it contains various blocks to be archived with block heights of 0, 100, 120, 3, and 9 respectively, and the heights of these blocks to be archived are not continuous.

[0296] It should be noted that the name of each fourth archive file may be a name corresponding to the block height of the first stored block to be archived. Taking the fourth archive file 000000000000000000000.fdb as an example, the block height of the first stored block to be archived is 0, and the name of the fourth archive file is "00000000000000000000".

[0297] After the blocks to be archived are stored in the fourth archive file, a second index needs to be set for the blocks to be archived in the fourth archive file. It can be understood that since the height of the blocks to be archived in the fourth archive file is discontinuous, the fourth archive file is stored in the fifth archive area, so the second index established is different from the first index. For example, the name corresponding to the second index needs to be preceded by the character "hot" to identify it as the index corresponding to the fifth archive area.

[0298] The second index indicates a fourth archive file identifier of the fourth archive file where the block to be archived is stored, and a second storage position of the block to be archived in the fourth archive file. For example, the fourth archive file identifier may be a file name corresponding to the fourth archive file corresponding to the block to be archived. The second storage position of the block to be archived in the fourth archive file includes a starting storage position of the block to be archived in the fourth archive file, and a length of the block to be archived.

[0299] The blocks to be archived in the fourth archive files in the fifth archive area are the blocks to be archived that were most recently accessed. In the fifth archive area, some fourth archive files may not be accessed again for a long time. These fourth archive files will occupy the storage space of the fifth archive area. Therefore, these fourth archive files that have not been accessed for a long time can be deleted.

[0300] In some embodiments, the fifth archive area includes multiple fourth archive files, some of which have not been accessed for a long time. The fourth archive files that have not been accessed for a long time need to be deleted to save storage space in the fifth archive area.

[0301] Please also read Fig.11 , Fig.11 This is another flowchart of the blockchain archiving method provided by the embodiment of the present application. It may include:

[0302] In step 501, the last access time corresponding to each fourth archive file in the fifth archive area is obtained.

[0303] It can be understood that multiple fourth archive files in the fifth archive area can be accessed. For example, when receiving a request to obtain a block to be archived corresponding to any target consensus node, the archive center can give priority to searching for the fourth archive file corresponding to the block to be archived in the fifth archive area. If the fourth archive file corresponding to the block to be archived exists in the fifth archive area, the block to be archived is directly obtained from the fourth archive file in the fifth archive area.

[0304] Considering that some fourth archive files in the fifth archive area may not be accessed for a long time, these fourth archive files that have not been accessed for a long time may be deleted, thereby saving storage space in the fifth archive area.

[0305] When each fourth archive file in the fifth archive area is accessed, the access time of each fourth archive file can be recorded, and then the last access time corresponding to each fourth archive file can be determined from the access time of each fourth archive file.

[0306] In step 502, the second non-access time length corresponding to each fourth archive file is determined according to the current time and the last access time corresponding to each fourth archive file.

[0307] According to the current time and the last access time corresponding to each fourth archive file, the second non-access time corresponding to each fourth archive file is determined. For example, if the last access time of a fourth archive file in the fourth archive area is 10:00 on August 23, 2023, and the current time is 13:00 on August 23, 2023, then the second non-access time corresponding to the fourth archive file is 3 hours. In this way, the second non-access time corresponding to each fourth archive file in the fifth archive area can be obtained.

[0308] In step 503, a fourth archive file to be deleted whose second non-access time exceeds a second preset time is determined, and the fourth archive file to be deleted is deleted from the fifth archive area.

[0309] Among the plurality of fourth archive files, the fourth archive file to be deleted whose second non-access time exceeds the second preset time is determined, and the fourth archive file to be deleted is deleted from the fifth archive area. For example, if the second preset time is 2 hours, and the second non-access time corresponding to a fourth archive file is 3 hours, the fourth archive file is regarded as the fourth archive file to be deleted, and then the fourth archive file to be deleted is deleted from the fifth archive area.

[0310] Specifically, please refer to Table 5:

[0311]

[0312] Table 5

[0313] Among them, the fourth archive files in Table 5 are all stored in the fifth archive area, and the last access time corresponding to each fourth archive file can be obtained in the fifth archive area. If the current time is 1:44:45 on June 21, 2023. The second preset time is 2 hours. Then, the current time is compared with the last access time of each fourth archive file in Table 5. If the second non-access time of the fourth archive file 000000000000000000000.fdb exceeds 2 hours, the fourth archive file 000000000000000000000.fdb is deleted in the fifth archive area. If the second non-access time of the fourth archive file 000000000000000000050.fdb is less than 2 hours, the fourth archive file 00000000000000000050.fdb is retained in the fifth archive area. It should be noted that the fourth archive files to be deleted determined by the second preset time length and the second non-access time length are all fourth archive files that have been fully stored.

[0314] As for the fourth archive file that has not been fully stored, it cannot be deleted in the fifth archive area by default. For example, the fourth archive file 000000000000000000014.fdb.END is the fourth archive file being stored. Since the fourth archive file is not fully stored yet and can continue to be stored, the fourth archive file that has not been fully stored cannot be deleted in the fifth archive area.

[0315] In some embodiments, when deleting the fourth archive file to be deleted in the fifth archive area, the index corresponding to the fourth archive file to be deleted can be deleted first, such as the second index corresponding to each archive block to be deleted in each fourth archive file to be deleted, and then the fourth archive file to be deleted can be deleted.

[0316] As can be seen from the above, in the embodiment of the present application, the first archiving area, the second archiving area, the third archiving area, the fourth archiving area and the fifth archiving area corresponding to the archiving center can all store the archiving files corresponding to the blocks to be archived. Among them, the first archiving area, the second archiving area and the third archiving area are permanent storage areas corresponding to the blocks to be archived of the target blockchain, that is, the blocks to be archived of the target blockchain can be distributed and stored in the archiving files corresponding to the first archiving area, the second archiving area and the third archiving area respectively.

[0317] The fourth and fifth archiving areas can be understood as a cache area. The archived files can only be stored for a period of time. When the target consensus node needs to obtain the archived blocks to be archived, it can first search for the archived files corresponding to the blocks to be archived in the fourth and fifth archiving areas. If they cannot be found, the archived files corresponding to the blocks to be archived can be searched in the first, second and third archiving areas. In this way, the blocks to be archived can be obtained from the archived files.

[0318] In some embodiments, if there are multiple target blockchains, a corresponding blockchain identifier is set for the archive file corresponding to each target blockchain in the first archive area, the second archive area, the third archive area, the fourth archive area, and the fifth archive area.

[0319] That is to say, in order to prevent chaotic management of archived data, resulting in archived data errors, a corresponding blockchain identifier can be set for each archive file corresponding to the target blockchain. The blockchain identifier can be a hash value corresponding to the target blockchain.

[0320] Please refer to Fig.12 , Fig.12 It is a file diagram of the target blockchain provided in an embodiment of the present application.

[0321] For a target blockchain, the blockchain identifier of the target blockchain can be obtained first, for example, by calculating the hash value corresponding to the target blockchain through a hash function. Then, in each archive area, a folder corresponding to the blockchain identifier is set first, and under this folder, the archive file corresponding to the target blockchain is stored.

[0322] For example, in the first archive area, a folder corresponding to the target blockchain is set, the name of the folder uses the blockchain identifier corresponding to the target blockchain, and then the first archive file corresponding to the target blockchain is stored in the folder.

[0323] For another example, in the storage area corresponding to the index information, a folder corresponding to the target blockchain is set, and the name of the folder uses the blockchain identifier corresponding to the target blockchain. Then, in the folder, the index data corresponding to the blocks to be archived of the target blockchain in the archive file is stored, such as the first index and the second index in the above content.

[0324] The storage area corresponding to the system information can be used to store the read and write log information of the archive files corresponding to the target blockchain. For example, if the target consensus node reads the first archive file in the first archive area at a specific time, it needs to be recorded in the system information.

[0325] In an embodiment of the present application, in the process of archiving the blocks to be archived corresponding to the target blockchain, the blocks to be archived can be first stored in the first archive file. Then, the first archive file to be compressed is selected from the first archive file, and the first archive file to be compressed is compressed to obtain a second archive file, and the second archive file is stored in the second archive area, and the first archive file to be compressed in the first archive area is deleted. Then, the second archive file whose archiving time is before the predetermined time point is determined from the second archive file as the third archive file, and then the third archive file is stored in the third archive area. In this way, the archive files corresponding to the target blockchain can be stored in a more subdivided manner, so that when searching for the blocks to be archived later, the archive files corresponding to the blocks to be archived can be quickly found in the corresponding archive area, and then the blocks to be archived are obtained from the archive files, thereby improving the processing efficiency of the data of the archived target blockchain.

[0326] At the same time, the fourth archive area and the fifth archive area can be used as cache areas. The fourth storage area can store the first archive file that was recently decompressed, and the fifth archive area can store the fourth archive file corresponding to the recently read block to be archived. When the subsequent target consensus node needs to find the block to be archived again, it can first search for the archive file corresponding to the block to be archived in the fourth archive area or the fifth archive area, thereby further improving the processing efficiency of the data of the archived target blockchain.

[0327] As can be seen from the above, in the embodiment of the present application, by obtaining the block to be archived from the target blockchain of the target consensus node; the block to be archived is stored in the first archive file of the first archive area, and a first index is established for the block to be archived, the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file; when receiving the acquisition request of the block to be archived by the target consensus node, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage position. In this way, by storing the block to be archived in the first archive file and setting the corresponding first index for the block to be archived, when it is necessary to find the block to be archived, the first archive file corresponding to the block to be archived can be directly found according to the first index, and the block to be archived can be extracted from the first archive file. Compared with the related art of directly traversing and searching for the block to be queried in the redundant archive data, the present application can find the block to be archived more efficiently and quickly, thereby improving the data processing efficiency of the archived block.

[0328] For a more detailed understanding of the blockchain archiving method provided in the embodiment of this application, please continue to refer to Fig.13 , Fig.13This is another flowchart of the blockchain archiving method provided by the embodiment of the present application. The blockchain archiving method may include the following steps:

[0329] In step 601, a first threshold height is obtained, and a block on the target blockchain whose block height is less than the first threshold height is obtained as a block to be archived.

[0330] For a target blockchain, the first threshold height corresponding to the target blockchain can be obtained. Blocks with block heights below the first threshold height can only be read and will not be modified, so these blocks can be archived.

[0331] A block on the target blockchain whose block height is less than the first threshold height can be obtained as a block to be archived. For example, if the first threshold height is 175502, then a block with a height of 154402 is a block to be archived. There are multiple blocks to be archived.

[0332] In step 602, the block to be archived is stored in the first archive file of the first archive area, and a first index is established for the block to be archived, wherein the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file.

[0333] The first archive area includes multiple first archive files, each of which can be used to store data corresponding to multiple blocks to be archived. Each first archive file has a certain capacity limitation. For example, the capacity of each first archive file is 1024MB. When the capacity of a first archive file is completely occupied by the data corresponding to the blocks to be archived, the first archive file can no longer store the data corresponding to other blocks to be archived.

[0334] If the first archive file has not been stored in the first archive area, or the first archive files in the first archive area are full, it means that the block to be archived must be stored in a new first archive file. At this time, a first archive file that does not store any data can be added, and then the block to be archived can be serialized to obtain serialized data of the block to be archived, and finally the serialized data can be stored in this first archive file that does not store any data.

[0335] If there is an incomplete first archive file in the first archive area, the blocks to be archived are serialized to obtain serialized data of the blocks to be archived, and then the serialized data is stored in the incomplete first archive file.

[0336] Among them, when the blocks to be archived are stored in the first archive file, they can be stored in order of their height. For example, if there are multiple blocks to be archived, they can be sorted from low to high according to their block heights to obtain a block height sorting result.

[0337] According to the block height sorting result, serialization processing is performed on the block to be archived with the lowest block height to obtain serialized data, and then the serialized data is stored in the current first archive file. Then, serialization processing is performed on the block to be archived with the next block height to obtain serialized data, and the serialized data is stored in the current first archive file, and so on, until the remaining capacity of the current first archive file cannot store the serialized data corresponding to the block to be archived.

[0338] Then, the remaining blocks to be archived are serialized to obtain serialized data of each remaining block to be archived, and the serialized data of each remaining block to be archived is stored in the next first archive file until the remaining capacity of the next first archive file cannot store the serialized data corresponding to the block to be archived. By analogy, the serialized data corresponding to multiple blocks to be archived can be stored in the corresponding first archive files, thus obtaining one, two or more first archive files.

[0339] In step 603, a second threshold height is obtained, and based on a comparison between the second threshold height and the end block heights of each first archive file, the first archive file to be compressed is determined.

[0340] Since the blocks to be archived in the first archive file are stored in order of block height from low to high, a second threshold height can be specified, and the first archive file corresponding to the blocks to be archived below the second threshold height needs to be transferred and stored. For example, if the first archive file corresponding to the blocks to be archived below a certain height is rarely accessed or used, it means that the first archive file corresponding to the blocks to be archived below the height can be transferred and stored, and the height is confirmed as the second threshold height.

[0341] If the second threshold height is between the start block height and the end block height of a first archive file, then the first archive file cannot be determined as the first archive file to be compressed. If the second threshold height is also the end block height of a first archive file, then the first archive file can be determined as the first archive file to be compressed. If the end block height of a first archive file is less than the second threshold height, then the first archive file can be determined as the first archive file to be compressed.

[0342] Therefore, it is necessary to compare the second threshold height with the end block height of each first archive file to obtain a comparison result, and then determine the first archive file to be compressed from the multiple first archive files in the first archive area based on the comparison result.

[0343] In step 604, the first archive file to be compressed is compressed as a second archive file, the second archive file is stored in the second archive area, and the first archive file to be compressed is deleted from the first archive area.

[0344] After determining the first archive file to be compressed, a compression algorithm may be used to compress the first archive file to be compressed, for example, a common 7z compression algorithm, a rar compression algorithm, a zip compression algorithm, etc., so as to obtain a second archive file.

[0345] After the second archive file is obtained, the second archive file can be transferred and stored in the second archive area, and then the first archive file to be compressed in the first archive area is deleted, thereby saving storage space in the first archive area.

[0346] In step 605, among the end block heights corresponding to each second archive file, the end block height with the maximum height is determined as the first identification block height.

[0347] After the second archive file is stored in the second archive area, the end block height of the maximum height can be determined as the first identification block height in the end block height corresponding to each second archive file. The first identification block height can be used to distinguish the archive files stored in the first archive area and the second archive area, for example, the starting block height of all the first archive files in the first archive area is greater than the first identification block height, and the end block height of the second archive file in the second archive area is less than or equal to the first identification block height.

[0348] In step 606, among the second archive files in the second archive area, a second archive file whose archive time is before the predetermined time point is determined as the third archive file.

[0349] Specifically, by determining the filing time corresponding to each second filing file in the second filing area, the second filing files with filing time before the predetermined time point are used as the third filing files. For example, if the predetermined time point is 9:00 on August 30, 2023, the second filing files in the second filing area before 9:00 on August 30, 2023 are used as the third filing files.

[0350] In step 607, among the end block heights corresponding to each third archive file, the end block height with the maximum height is determined as the second identification block height.

[0351] After storing the third archive files in the third storage area, the end block height of the maximum height is determined as the second identification block height in the end block height corresponding to each third archive file, and the second identification block height is recorded. The second identification block height can be used to distinguish the files stored in the second archive area and the third archive area. For example, the starting block height of all the second archive files in the second archive area is greater than the second identification block height, and the end block height of the third archive files in the third archive area is less than or equal to the second identification block height.

[0352] In step 608, when a request for obtaining a block to be archived is received from the target consensus node, the target block height of the block to be archived in the target blockchain is obtained.

[0353] For example, the acquisition request includes the height information corresponding to the block to be archived, and the target block height of the block to be archived is determined by the height information.

[0354] In step 609, if the target block height is greater than the first identification block height and the block to be archived has a first index, the first archive file is obtained in the first archive area according to the first archive file identification, and the block to be archived is obtained in the first archive file according to the first storage location.

[0355] Specifically, the target block height can be compared with the first identification block height. Since the first identification height is the compression height corresponding to the second archive area, if the target block height is greater than the first identification block height, it means that the block to be archived is in the first archive area.

[0356] Since each block in the archiving center has a corresponding first index when it is archived, if the block to be archived has the first index, the first archive file identifier is determined according to the first index, and then the first archive file is obtained in the first archiving area according to the first archive file identifier. Then, the first storage location corresponding to the block to be archived is determined according to the first index, and then the block to be archived is obtained in the first archive file according to the first storage location.

[0357] Among them, the data in the first archive file are all serialized data, and the serialized data corresponding to each block to be archived has a corresponding storage position in the first archive file. The starting point of the block to be archived can be located in the first archive file according to the starting storage position of the block to be archived.

[0358] Then starting from the starting point, the end point of the block to be archived is located in the first archive file according to the length of the serialized data corresponding to the block to be archived. The serialized data between the starting point and the end point is the serialized data corresponding to the block to be archived, which can also be understood as the block to be archived.

[0359] After obtaining the serialized data corresponding to the block to be archived, the serialized data can be deserialized to obtain the original data corresponding to the block to be archived. The original data can be understood as the data contained in the block header and block body in the block to be archived.

[0360] After finding the blocks to be archived, the archiving center can send the blocks to be archived to the target consensus node. After the target consensus node receives the blocks to be archived, it can restore the data of the blocks to be archived.

[0361] In step 610, if the target block height is less than or equal to the first identification block height and greater than the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, the selected second archive file is obtained in the second archive area, and the selected second archive file is decompressed to the fourth archive area to obtain the first archive file.

[0362] The first identified height is the compression height corresponding to the second filing area, and the second identified height is the refrigeration height corresponding to the third filing area. If the target block height is less than or equal to the first identified block height and greater than the second identified block height, it means that the archived file corresponding to the block to be archived is in the second filing area.

[0363] Then, the first index corresponding to the block to be archived is obtained. If the block to be archived has the first index, the first archive file identifier is obtained according to the first index, and then the selected second archive file is obtained in the second archive area according to the first archive file identifier. It should be noted that since the second archive file in the second archive area is obtained by compressing the first archive file to be compressed, after compression, the name of the obtained second archive file is the same as the name of the first archive file to be compressed, and the two are only different in file format. Therefore, the selected second archive file can be obtained in the second archive area through the first archive file identifier, and the selected second archive file contains the data corresponding to the block to be archived, that is, it contains the block to be archived.

[0364] It is understandable that, since the selected second archive file is compressed, if the block to be archived is to be obtained, the selected second archive file needs to be decompressed. Therefore, the selected second archive file is decompressed to obtain the first archive file corresponding to the block to be archived, and then the first archive file is stored in the fourth archive area. At this time, the selected second archive file is still saved in the second archive area to prevent the archived data from being lost.

[0365] In step 611, in the fourth archive area, the block to be archived is obtained in the first archive file according to the first storage location.

[0366] In the fourth archive area, the first storage position corresponding to the block to be archived is determined according to the first index, and the block to be archived is obtained in the first archive file according to the first storage position. For example, the first storage position of the block to be archived in the first archive file includes the starting storage position of the block to be archived in the first archive file and the length of the block to be archived. According to the starting storage position, the starting point of the block to be archived is located in the first archive file. Then, according to the length, the ending point of the block to be archived is located in the first archive file. Finally, the part between the starting point and the ending point in the first archive file is extracted as the block to be archived.

[0367] The portion between the start point and the end point in the extracted first archive file is the serialized data corresponding to the block to be archived, and the serialized data can be deserialized to obtain the original data of the block to be archived.

[0368] After obtaining the block to be archived, the block to be archived can be sent to the target consensus node, so that the target consensus node can restore the data of the block to be archived.

[0369] In step 612, if the target block height is less than or equal to the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, the selected third archive file is obtained in the third archive area, and the selected third archive file is decompressed to the fourth archive area to obtain the first archive file.

[0370] Among them, the second identification block height is the cold storage height corresponding to the third archiving area. If the target block height is less than or equal to the second identification block height, it means that the archive file corresponding to the block to be archived is in the third archiving area.

[0371] Then, the first index corresponding to the block to be archived is obtained. If the block to be archived has the first index, the first archive file identifier is obtained according to the first index, and then the selected third archive file is obtained in the third archive area according to the first archive file identifier. It should be noted that since the third archive file in the third archive area is obtained by compressing the first archive file to be compressed, after compression, the name of the third archive file obtained is the same as the name of the first archive file to be compressed, and the two are only different in file format. Therefore, the selected third archive file can be obtained in the third archive area through the first archive file identifier, and the selected third archive file contains the data corresponding to the block to be archived, that is, it contains the block to be archived.

[0372] It is understandable that, since the selected third archive file is compressed, if the block to be archived is to be obtained, the selected third archive file needs to be decompressed. Therefore, the selected third archive file is decompressed, and the first archive file corresponding to the block to be archived is obtained after decompression, and then the first archive file is stored in the fourth archive area. At this time, the selected third archive file is still saved in the third archive area to prevent the archived data from being lost.

[0373] In step 613, in the fourth archive area, the block to be archived is obtained in the first archive file according to the first storage location.

[0374] In the fourth archive area, the first storage position corresponding to the block to be archived is determined according to the first index, and the block to be archived is obtained in the first archive file according to the first storage position. For example, the first storage position of the block to be archived in the first archive file includes the starting storage position of the block to be archived in the first archive file and the length of the block to be archived. According to the starting storage position, the starting point of the block to be archived is located in the first archive file. Then, according to the length, the ending point of the block to be archived is located in the first archive file. Finally, the part between the starting point and the ending point in the first archive file is extracted as the block to be archived.

[0375] The portion between the start point and the end point in the extracted first archive file is the serialized data corresponding to the block to be archived, and the serialized data can be deserialized to obtain the original data of the block to be archived.

[0376] After obtaining the block to be archived, the block to be archived can be sent to the target consensus node, so that the target consensus node can restore the data of the block to be archived.

[0377] As can be seen from the above, in the embodiment of the present application, in the process of archiving the block to be archived corresponding to the target blockchain, the block to be archived can be first stored in the first archive file. Then, the first archive file to be compressed is selected from the first archive file, and the first archive file to be compressed is compressed to obtain a second archive file, and the second archive file is stored in the second archive area, and the first archive file to be compressed in the first archive area is deleted. Then, the second archive file whose archiving time is before the predetermined time point is determined from the second archive file as the third archive file, and then the third archive file is stored in the third archive area. In this way, the archive files corresponding to the target blockchain can be stored in a more subdivided manner, so that when searching for the block to be archived later, the archive file corresponding to the block to be archived can be quickly found in the corresponding archive area, and then the block to be archived is obtained from the archive file, thereby improving the processing efficiency of the data of the archived target blockchain.

[0378] For a more detailed understanding of the blockchain archiving method in the embodiments of this application, please refer to Figure 7 The following will describe the core idea of ​​this application from the perspective of data storage and data search in the entire archive center. Some of the terms have been introduced in detail above and will not be explained again.

[0379] like Figure 7 As shown, the client can be understood as the client corresponding to the target consensus node, and the target consensus node can exchange data with the archive center through the client.

[0380] First, the target consensus node archives the to-be-archived blocks of the target blockchain of the target consensus node through the client.

[0381] The blocks to be archived in the target blockchain may be blocks that are only read and not modified. A first threshold height may be set, and the blocks below the first threshold height in the target blockchain are blocks to be archived.

[0382] Then, the blocks to be archived are written into at least one first archive file. Specifically, if the first archive file has not been stored in the first archive area, or the first archive files in the first archive area are fully stored, a first document file is added to the first archive area, and the blocks to be archived are serialized and stored in the added first archive file; if there are first archive files that are not fully stored in the first archive area, the blocks to be archived are serialized and stored in the first archive files that are not fully stored, and each first archive file includes a starting block height and an ending block height.

[0383] In the first archive area, some first archive files may not be accessed and read for a long time, and these first archive files may be transferred and stored in the second archive area. Specifically, a second threshold height is obtained; based on the comparison between the second threshold height and the end block height of each first archive file, the first archive file to be compressed is determined; the first archive file to be compressed is compressed as the second archive file, the second archive file is stored in the second archive area, and the first archive file to be compressed is deleted from the first archive area.

[0384] In the second archive area, some second archive files may not be accessed for a long time, and these second archive files may be transferred and stored in the third archive area. Specifically, among the second archive files in the second archive area, the second archive files whose archiving time is before the predetermined time point are determined as the third archive files; the third archive files are stored in the third archive area, and the third archive files are deleted in the second archive area.

[0385] That is to say, the first archiving area, the second archiving area, and the third archiving area all store archive files corresponding to the blocks to be archived.

[0386] Then, we will introduce it from the perspective of searching for blocks to be archived in the archive center.

[0387] When receiving a request from the target consensus node for obtaining a block to be archived, the target block height of the block to be archived in the target blockchain is obtained.

[0388] If the target block height is greater than the first identification block height and the block to be archived has a first index, the first archive file is obtained in the first archive area according to the first archive file identification, and the block to be archived is obtained in the first archive file according to the first storage location.

[0389] If the target block height is less than or equal to the first identification block height and greater than the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, the selected second archive file is obtained in the second archive area, and the selected second archive file is decompressed to the fourth archive area to obtain the first archive file; in the fourth archive area, according to the first storage location, the block to be archived is obtained in the first archive file.

[0390] If the target block height is less than or equal to the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, obtain the selected third archive file in the third archive area, decompress the selected third archive file to the fourth archive area, and obtain the first archive file; in the fourth archive area, according to the first storage location, obtain the block to be archived in the first archive file.

[0391] That is to say, the target block height can be compared with the first identification height and the second identification height, and then the archiving area corresponding to the block to be archived that needs to be queried can be determined, and then the corresponding archive file can be obtained in the corresponding archiving area according to the first index, and finally the block to be archived can be obtained from the archive file according to the first index. Then the archiving center sends the block to be archived to the target consensus node.

[0392] The archive center also includes a fourth archive area and a fifth archive area. The archive files obtained from the second archive area and the third archive area need to be decompressed to the fourth archive area to obtain the first archive file corresponding to the block to be archived that needs to be queried. Then, the block to be archived is obtained from the first archive file in the fourth archive area.

[0393] The block to be archived may be stored in a fourth archive file in the fifth archive area, and a second index between the block to be archived and the fourth archive file may be established in the fifth archive area.

[0394] If some other target consensus nodes need to query the blocks to be archived later, they can first search in the fourth archive area and the fifth archive area, and then search in the first archive area, the second archive area, or the third archive area. This avoids searching for the blocks to be archived in the entire archive data, thereby improving the processing efficiency of the archived data.

[0395] See also Fig.14 , Fig.14 This is a schematic diagram of the structure of the blockchain archiving device provided in the embodiment of the present application. The meanings of the terms are the same as those in the above-mentioned blockchain archiving method, and the specific implementation details can refer to the description in the method embodiment.

[0396] A blockchain archiving device, comprising:

[0397] An acquisition module 710 is used to acquire a block to be archived from a target blockchain of a target consensus node;

[0398] A storage module 720, configured to store the block to be archived in a first archive file of a first archive area, and to establish a first index for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file in which the block to be archived is stored, and a first storage position of the block to be archived in the first archive file;

[0399] The search module 730 is used to obtain the first archive file in the first archive area according to the first archive file identifier when receiving a request for obtaining the block to be archived from the target consensus node, and obtain the block to be archived in the first archive file according to the first storage location.

[0400] In some implementations, the acquisition module 710 is configured to:

[0401] Get a first threshold height;

[0402] Obtain a block on the target blockchain whose block height is less than a first threshold height as a block to be archived.

[0403] In some embodiments, the storage module 720 is configured to:

[0404] If the first archived file has not been stored in the first archived area, or the first archived files in the first archived area are fully stored, a first document file is added to the first archived area, and the blocks to be archived are serialized and stored in the added first archived file;

[0405] If there is an incomplete first archive file in the first archive area, the blocks to be archived are serialized and stored in the incomplete first archive file.

[0406] In some implementations, the first storage location of the to-be-archived block in the first archive file includes the starting storage location of the to-be-archived block in the first archive file and the length of the to-be-archived block; the search module 730 is used to:

[0407] Locate the starting point of the block to be archived in the first archive file according to the starting storage position;

[0408] Locate the end point of the block to be archived in the first archive file according to the length;

[0409] Extract the portion between the start point and the end point in the first archive file as the block to be archived.

[0410] Please also read Fig.15 , Fig.15 7 is another structural diagram of the blockchain archiving device provided in the embodiment of the present application. The storage module 720 includes a compression submodule 721 and a cold storage submodule 722. The search module 730 includes a height acquisition submodule 731 and a management submodule 732.

[0411] In some embodiments, the first archive file has an end block height, which is the maximum height of the block to be archived contained in the first archive file on the target blockchain; the storage module 720 also includes a compression submodule 721, which is used to:

[0412] Get the second threshold height;

[0413] Determine the first archive file to be compressed based on the comparison between the second threshold height and the end block height of each first archive file;

[0414] The first archive file to be compressed is compressed as a second archive file, the second archive file is stored in a second archive area, and the first archive file to be compressed is deleted from the first archive area.

[0415] In some implementations, the compression submodule 721 is further configured to:

[0416] Sort the plurality of first archive files in ascending order according to the end block height;

[0417] If the second threshold height is equal to the end block height of a first archive file, the first archive file and the first archive file before the first archive file in the sorting are determined as the first archive files to be compressed;

[0418] If the second threshold height is less than the end block height of a first archive file in the sort, but greater than the end block height of the previous first archive file in the sort, the previous first archive file and the first archive file in front of the previous first archive file in the sort are determined as first archive files to be compressed.

[0419] In some embodiments, the storage module 720 further includes a cold storage submodule 722. After storing the block to be archived in the first archive file of the first archive area and creating a first index for the block to be archived, the cold storage submodule 722 is configured to:

[0420] Among the second archive files in the second archive area, determine the second archive file whose archive time is before the predetermined time point as the third archive file;

[0421] The third archive file is stored in the third archive area, and the third archive file is deleted in the second archive area.

[0422] In some embodiments, the refrigeration submodule 722 is used to:

[0423] Determining, among the second archive files in the second archive area, a target second archive file corresponding to a predetermined time point;

[0424] Determine the starting block height of the target second archive file;

[0425] The target second archive file and the second archive file whose end block height is less than the start block height of the target second archive file are determined as the third archive file.

[0426] In some implementations, the search module 730 further includes a height acquisition submodule 731, and the height acquisition submodule 731 is used to:

[0427] After storing the second archive file in the second archive area, determining the maximum end block height among the end block heights corresponding to each second archive file as the first identification block height;

[0428] After the third archive file is stored in the third archive area, the end block height with the maximum height among the end block heights corresponding to each third archive file is determined as the second identification block height.

[0429] In some implementations, before obtaining the first archive file in the first archive area according to the first archive file identifier and obtaining the to-be-archived block in the first archive file according to the first storage location, the height acquisition submodule 731 is further configured to:

[0430] When receiving a request from the target consensus node for obtaining a block to be archived, the target block height of the block to be archived in the target blockchain is obtained.

[0431] In some embodiments, the search module 730 further includes a search submodule, which, after obtaining the target block height of the block to be archived in the target blockchain, is used to:

[0432] If the target block height is greater than the first identification block height and the block to be archived has a first index, the first archive file is obtained in the first archive area according to the first archive file identification, and the block to be archived is obtained in the first archive file according to the first storage location.

[0433] In some implementations, after obtaining the target block height of the block to be archived in the target blockchain, a submodule is searched for:

[0434] If the target block height is less than or equal to the first identification block height and greater than the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, obtain the selected second archive file in the second archive area, decompress the selected second archive file to the fourth archive area, and obtain the first archive file;

[0435] In the fourth archive area, a block to be archived is obtained in the first archive file according to the first storage location.

[0436] In some implementations, after obtaining the target block height of the block to be archived in the target blockchain, a submodule is searched for:

[0437] If the target block height is less than or equal to the second identification block height, and the to-be-archived block has a first index, then according to the first archive file identification, a selected third archive file is obtained in the third archive area, and the selected third archive file is decompressed to the fourth archive area to obtain the first archive file;

[0438] In the fourth archive area, a block to be archived is obtained in the first archive file according to the first storage location.

[0439] In some implementations, the search module 730 further includes a management submodule 732. The fourth archive area includes a plurality of first archive files. The management submodule 732 is configured to:

[0440] Obtaining the last access time corresponding to each first archive file in the fourth archive area;

[0441] Determine a first non-access time length corresponding to each first archive file according to the current time and the last access time corresponding to each first archive file;

[0442] Among the multiple first archive files, a to-be-deleted first archive file whose first non-access time exceeds a first preset time is determined, and the to-be-deleted first archive file is deleted from the fourth archive area.

[0443] In some embodiments, in the fourth archive area, after obtaining the block to be archived in the first archive file according to the first storage location, the management submodule 732 is configured to:

[0444] storing the block to be archived in the fourth archive file of the fifth archive area;

[0445] A second index is set for the block to be archived in the fourth archive file, wherein the second index indicates a fourth archive file identifier of the fourth archive file in which the block to be archived is stored, and a second storage position of the block to be archived in the fourth archive file.

[0446] In some implementations, the fifth archive area includes a plurality of fourth archive files, and the management submodule 732 is configured to:

[0447] Obtain the last access time corresponding to each fourth archive file in the fifth archive area;

[0448] Determine the second non-access time corresponding to each fourth archive file according to the current time and the last access time corresponding to each fourth archive file;

[0449] A fourth archive file to be deleted whose second non-access time length exceeds a second preset time length is determined, and the fourth archive file to be deleted is deleted from the fifth archive area.

[0450] In some implementations, the storage module 720 is further configured to:

[0451] If there are multiple target blockchains, a corresponding blockchain identifier is set for the archive file corresponding to each target blockchain in the first archive area, the second archive area, the third archive area, the fourth archive area and the fifth archive area.

[0452] The specific implementation of each of the above modules can be found in the previous embodiments and will not be described in detail here.

[0453] As can be seen from the above, in the embodiment of the present application, by obtaining the block to be archived from the target blockchain of the target consensus node; the block to be archived is stored in the first archive file of the first archive area, and a first index is established for the block to be archived, the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file; when receiving the acquisition request of the block to be archived by the target consensus node, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage position. In this way, by storing the block to be archived in the first archive file and setting the corresponding first index for the block to be archived, when it is necessary to find the block to be archived, the first archive file corresponding to the block to be archived can be directly found according to the first index, and the block to be archived can be extracted from the first archive file. Compared with the related art of directly traversing and searching for the block to be queried in the redundant archive data, the present application can find the block to be archived more efficiently and quickly, thereby improving the data processing efficiency of the archived block.

[0454] The embodiment of the present application also provides a computer device, which can be a server. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited to this. The terminal and the server can be directly or indirectly connected via wired or wireless communication, and this application does not limit this.

[0455] See also Fig.16 , Fig.16 It is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.

[0456] like Fig.16 As shown, the computer device may be a server, which shows a schematic diagram of the structure of the server, specifically:

[0457] The computer device may include one or more processing core processors 801, one or more computer-readable storage media memories 802, a power supply 803, an input unit 804 and other components. Those skilled in the art will appreciate that Fig.16 The computer device structure shown in the figure does not constitute a limitation on the computer device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. Among them:

[0458] The processor 801 is the control center of the computer device. It uses various interfaces and lines to connect various parts of the entire computer device. By running or executing software programs and / or modules stored in the memory 802 and calling data stored in the memory 802, it executes various functions of the computer device and processes data, thereby monitoring the computer device as a whole. Optionally, the processor 801 may include one or more processing cores; optionally, the processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, object interface and application programs, etc., and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 801.

[0459] The memory 802 can be used to store software programs and modules. The processor 801 executes various functional applications and data processing by running the software programs and modules stored in the memory 802. The memory 802 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the server, etc. In addition, the memory 802 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory 802 may also include a memory controller to provide the processor 801 with access to the memory 802.

[0460] The computer device also includes a power supply 803 for supplying power to various components. Optionally, the power supply 803 can be logically connected to the processor 801 through a power management system, so as to manage charging, discharging, and power consumption through the power management system. The power supply 803 can also include any components such as one or more DC or AC power supplies, recharging systems, power failure detection circuits, power converters or inverters, and power status indicators.

[0461] The computer device may further include an input unit 804, which may be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to object settings and function controls.

[0462] Although not shown, the computer device may further include a display unit, etc., which will not be described in detail herein. Specifically in this embodiment, the processor 801 in the computer device will load the executable files corresponding to the processes of one or more application programs into the memory 802 according to the following instructions, and the processor 801 will run the application programs stored in the memory 802, thereby implementing the various method steps provided in the aforementioned embodiments, as follows:

[0463] Obtain the blocks to be archived from the target blockchain of the target consensus node;

[0464] The block to be archived is stored in a first archive file of a first archive area, and a first index is established for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file where the block to be archived is stored, and a first storage position of the block to be archived in the first archive file;

[0465] When a request for obtaining a block to be archived is received from the target consensus node, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage location.

[0466] In the above embodiments, the description of each embodiment has its own focus. For the part that is not described in detail in a certain embodiment, please refer to the detailed description of the blockchain archiving method above, which will not be repeated here.

[0467] As can be seen from the above, in the embodiment of the present application, by obtaining the block to be archived from the target blockchain of the target consensus node; the block to be archived is stored in the first archive file of the first archive area, and a first index is established for the block to be archived, the first index indicates the first archive file identifier of the first archive file where the block to be archived is stored, and the first storage position of the block to be archived in the first archive file; when receiving the acquisition request of the block to be archived by the target consensus node, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage position. In this way, by storing the block to be archived in the first archive file and setting the corresponding first index for the block to be archived, when it is necessary to find the block to be archived, the first archive file corresponding to the block to be archived can be directly found according to the first index, and the block to be archived can be extracted from the first archive file. Compared with the related art of directly traversing and searching for the block to be queried in the redundant archive data, the present application can find the block to be archived more efficiently and quickly, thereby improving the data processing efficiency of the archived block.

[0468] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0469] To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to execute the steps in any blockchain archiving method provided in the embodiment of the present application. For example, the instructions can execute the following steps:

[0470] Obtain the blocks to be archived from the target blockchain of the target consensus node;

[0471] The block to be archived is stored in a first archive file of a first archive area, and a first index is established for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file where the block to be archived is stored, and a first storage position of the block to be archived in the first archive file;

[0472] When a request for obtaining a block to be archived is received from the target consensus node, the first archive file is obtained in the first archive area according to the first archive file identifier, and the block to be archived is obtained in the first archive file according to the first storage location.

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

[0474] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0475] The computer-readable storage medium may include: a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0476] Since the instructions stored in the computer-readable storage medium can execute the steps in any blockchain archiving method provided in the embodiments of the present application, the beneficial effects that can be achieved by any blockchain archiving method provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0477] The above is a detailed introduction to a blockchain archiving method, device, storage medium and computer equipment provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for technical personnel in this field, according to the ideas of the present application, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A blockchain archiving method, characterized in that: include: Obtain the blocks to be archived from the target blockchain of the target consensus node; The block to be archived is stored in a first archive file of a first archive area, and a first index is established for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file where the block to be archived is stored, and a first storage position of the block to be archived in the first archive file; When receiving the acquisition request of the target consensus node for the block to be archived, the first archive file is acquired in the first archive area according to the first archive file identifier, and the block to be archived is acquired in the first archive file according to the first storage location.

2. The blockchain archiving method according to claim 1, characterized in that: The step of obtaining the block to be archived from the target blockchain of the target consensus node includes: Get a first threshold height; A block on the target blockchain whose block height is less than the first threshold height is obtained as the block to be archived.

3. The blockchain archiving method according to claim 1, characterized in that: The step of storing the to-be-archived block in a first archive file in a first archive area includes: If the first archived file has not been stored in the first archived area, or the first archived files in the first archived area are fully stored, adding a first document file to the first archived area, and serializing the blocks to be archived and storing them in the added first archived file; If there is a part of the first archive file in the first archive area that is not fully stored, the blocks to be archived are serialized and stored in the part of the first archive file that is not fully stored.

4. The blockchain archiving method according to claim 1, characterized in that: The first storage position of the block to be archived in the first archive file includes the starting storage position of the block to be archived in the first archive file and the length of the block to be archived; The obtaining the to-be-archived block in the first archive file according to the first storage location includes: Locating the starting point of the block to be archived in the first archive file according to the starting storage position; According to the length, locating the end point of the block to be archived in the first archive file; The portion between the starting point and the ending point in the first archive file is extracted as the block to be archived.

5. The blockchain archiving method according to claim 1, characterized in that: The first archive file has an end block height, and the end block height is the maximum height of the block to be archived contained in the first archive file on the target blockchain; After storing the block to be archived in the first archive file of the first archive area and creating a first index for the block to be archived, the blockchain archiving method further includes: Get the second threshold height; Determine the first archive file to be compressed based on the comparison between the second threshold height and the end block height of each of the first archive files; The first archive file to be compressed is compressed as a second archive file, the second archive file is stored in a second archive area, and the first archive file to be compressed is deleted from the first archive area.

6. The blockchain archiving method according to claim 5, characterized in that: The step of determining the first archive file to be compressed based on the comparison between the second threshold height and the end block height of each of the first archive files comprises: sorting the plurality of first archive files from small to large according to the end block height; If the second threshold height is equal to the end block height of one of the first archive files, determining the first archive file and the first archive file preceding the first archive file in the sorting as the first archive files to be compressed; If the second threshold height is less than the end block height of one of the first archive files in the sort, but greater than the end block height of the previous first archive file in the sort, the previous first archive file and the first archive file in the sort that is ahead of the previous first archive file are determined as the first archive files to be compressed.

7. The blockchain archiving method according to claim 5, characterized in that: After compressing the first archive file to be compressed to obtain a second archive file, and storing the second archive file in the second archive area, the blockchain archiving method further includes: Among the second archive files in the second archive area, determine the second archive files whose archive time is before a predetermined time point as third archive files; The third archive file is stored in the third archive area, and the third archive file is deleted in the second archive area.

8. The blockchain archiving method according to claim 7, characterized in that: The step of determining, among the second archive files in the second archive area, the second archive files whose archive time is before a predetermined time point as the third archive file comprises: Determining, among the second archive files in the second archive area, a target second archive file corresponding to the predetermined time point; Determine the starting block height of the target second archive file; The target second archive file and the second archive file whose end block height is smaller than the start block height of the target second archive file are determined as the third archive file.

9. The blockchain archiving method according to claim 7, characterized in that: After storing the second archive file in the second archive area, the blockchain archiving method further includes: In the end block heights corresponding to each of the second archive files, determining the end block height with the maximum height as the first identification block height; After storing the third archive file in the third archive area, the blockchain archiving method further includes: In the end block heights corresponding to each of the third archive files, the end block height with the maximum height is determined as the second identification block height.

10. The blockchain archiving method according to claim 9, characterized in that: Before obtaining the first archive file in the first archive area according to the first archive file identifier, and obtaining the to-be-archived block in the first archive file according to the first storage location, the blockchain archiving method further includes: When receiving a request from the target consensus node for obtaining the block to be archived, obtaining a target block height of the block to be archived in the target blockchain; The acquiring the first archive file in the first archive area according to the first archive file identifier, and acquiring the to-be-archived block in the first archive file according to the first storage location, includes: If the target block height is greater than the first identification block height and the block to be archived has a first index, then according to the first archive file identifier, the first archive file is obtained in the first archive area, and according to the first storage location, the block to be archived is obtained in the first archive file.

11. The blockchain archiving method according to claim 10, characterized in that: After obtaining the target block height of the block to be archived in the target blockchain, the blockchain archiving method further includes: If the target block height is less than or equal to the first identification block height and greater than the second identification block height, and the block to be archived has a first index, then according to the first archive file identifier, a selected second archive file is obtained in the second archive area, and the selected second archive file is decompressed to the fourth archive area to obtain the first archive file; In the fourth archiving area, the block to be archived is obtained in the first archive file according to the first storage location.

12. The blockchain archiving method according to claim 10, characterized in that: After obtaining the target block height of the block to be archived in the target blockchain, the blockchain archiving method further includes: If the target block height is less than or equal to the second identification block height, and the to-be-archived block has a first index, then according to the first archive file identifier, a selected third archive file is obtained in the third archive area, and the selected third archive file is decompressed to the fourth archive area to obtain the first archive file; In the fourth archiving area, the block to be archived is obtained in the first archive file according to the first storage location.

13. The blockchain archiving method according to claim 11 or 12, characterized in that: The fourth archiving area includes a plurality of the first archiving files, and the blockchain archiving method further includes: Obtaining the last access time corresponding to each of the first archive files in the fourth archive area; Determine a first non-access time length corresponding to each of the first archive files according to the current time and the last access time corresponding to each of the first archive files; Among the multiple first archive files, determine the first archive files to be deleted whose first non-access time exceeds the first preset time, and delete the first archive files to be deleted from the fourth archive area.

14. The blockchain archiving method according to claim 11 or 12, characterized in that: In the fourth archiving area, after obtaining the to-be-archived block in the first archive file according to the first storage location, the blockchain archiving method further includes: storing the to-be-archived block in a fourth archive file in a fifth archive area; A second index is set for the block to be archived in the fourth archive file, wherein the second index indicates a fourth archive file identifier of the fourth archive file where the block to be archived is stored, and a second storage position of the block to be archived in the fourth archive file.

15. The blockchain archiving method according to claim 14, characterized in that: The fifth archiving area includes a plurality of fourth archiving files, and the blockchain archiving method further includes: Obtaining the last access time corresponding to each of the fourth archive files in the fifth archive area; Determine a second non-access time length corresponding to each of the fourth archive files according to the current time and the last access time corresponding to each of the fourth archive files; Determine a fourth archive file to be deleted whose second non-access time exceeds a second preset time, and delete the fourth archive file to be deleted from the fifth archive area.

16. The blockchain archiving method according to claim 14, characterized in that: The blockchain archiving method further includes: If there are multiple target blockchains, a corresponding blockchain identifier is set for the archive file corresponding to each target blockchain in the first archive area, the second archive area, the third archive area, the fourth archive area and the fifth archive area.

17. A blockchain archiving device, characterized in that: include: The acquisition module is used to obtain the blocks to be archived from the target blockchain of the target consensus node; a storage module, configured to store the block to be archived in a first archive file in a first archive area, and to establish a first index for the block to be archived, wherein the first index indicates a first archive file identifier of the first archive file in which the block to be archived is stored, and a first storage position of the block to be archived in the first archive file; A search module is used to obtain the first archive file in the first archive area according to the first archive file identifier when receiving a request from the target consensus node for the block to be archived, and to obtain the block to be archived in the first archive file according to the first storage location.

18. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, which are suitable for loading by a processor to execute the steps in the blockchain archiving method according to any one of claims 1 to 16.

19. 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, the steps in the blockchain archiving method according to any one of claims 1 to 16 are implemented.

20. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instructions are executed by a processor, the steps in the blockchain archiving method according to any one of claims 1 to 16 are implemented.

Images