Data processing method and device based on block chain, equipment and medium

Abstract

The embodiment of the invention discloses a data processing method and device based on a block chain, equipment and a medium, which can be applied to various scenes such as intelligent traffic, auxiliary driving, cloud technology and artificial intelligence. The data processing method based on the block chain comprises the steps that after a block chain node receives a block filing request containing a target block height, a determined target to-be-filed block is written into a filing file from a local block chain, the position of the target to-be-filed block in the written filing file is recorded, an index file is generated, and the target to-be-filed block is stored in the index file; and transferring the archived file and the index file to the archiving party. According to the technical scheme of the invention, the method achieves the quick archiving of the block, and improves the data processing based on the block chain.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically, to a blockchain-based data processing method, a blockchain-based data processing device, an electronic device, and a computer-readable medium. Background Art

[0002] In recent years, with the development of blockchain technology, the application fields of blockchain systems have become more and more extensive. As the operation time of the blockchain system increases, the storage space occupied by the blockchain data of each blockchain node in the blockchain system will become larger and larger. Therefore, in order to avoid the blockchain data occupying a large storage space, it is necessary to archive the blockchain data periodically. In the related art, the single block on the blockchain is archived as a unit, and the archiving efficiency is low.

[0003] Therefore, how to improve blockchain-based data processing to improve archiving efficiency is an urgent problem to be solved. Summary of the invention

[0004] The embodiments of the present application provide a blockchain-based data processing method, device, equipment, and medium, which improve the archiving efficiency and thus improve the blockchain-based data processing.

[0005] In a first aspect, an embodiment of the present application provides a blockchain-based data processing method, the method comprising: receiving a block archiving request containing a target block height sent by a requester; wherein the target block height is used to represent the maximum block height of multiple blocks to be archived; based on the target block height and the block storage capacity of a single archive file, determining a target block to be archived from the multiple blocks to be archived; writing the target block to be archived from a local blockchain into an archive file, and recording the position of the target block to be archived in the written archive file to generate an index file; transferring the archive file and the index file to the archiving party corresponding to the block archiving request.

[0006] In a second aspect, an embodiment of the present application provides a blockchain-based data processing method, the method comprising: receiving an archive file and an index file sent by a blockchain node; wherein the archive file is generated by the blockchain node according to a target block to be archived in a local blockchain, and the index file is obtained by recording the position of the target block to be archived in the archive file; and storing the received archive file and index file.

[0007] In one embodiment of the present application, based on the aforementioned scheme, the method further includes: if a block query request for a specified block height is received from the blockchain node, and it is detected that the block of the specified block height is stored in a compressed archive file corresponding to the specified block height, the compressed archive file is decompressed to obtain a decompressed archive file; based on the index file corresponding to the specified block height, the block of the specified block height is obtained from the decompressed archive file; and the obtained block is returned to the blockchain node.

[0008] In one embodiment of the present application, based on the aforementioned scheme, before decompressing the compressed archive file to obtain the decompressed archive file, the method also includes: if it is detected that there is an archive file that has not been accessed within a specified period of time among the multiple stored archive files, compressing the unaccessed archive file to obtain the compressed archive file.

[0009] In one embodiment of the present application, based on the aforementioned scheme, the storage of the received archive files and index files includes: obtaining the maximum block height among the multiple archive files stored; wherein the multiple archive files come from multiple different blockchain nodes; if the minimum block height among the received archive files is greater than the maximum block height, the received archive files and index files are stored.

[0010] In one embodiment of the present application, based on the aforementioned scheme, the storage of the received archive files and index files includes: obtaining the identification information of the blockchain corresponding to the received archive files; if it is detected that the identification information matches any file directory in multiple file directories, the received archive files and index files are stored in the matching file directory; wherein each file directory is used to represent the identification information of the corresponding blockchain.

[0011] In a third aspect, an embodiment of the present application provides a blockchain-based data processing device, the device comprising: a receiving module, configured to receive a block archiving request containing a target block height sent by a requesting party; wherein the target block height is used to represent the maximum block height among multiple blocks to be archived; a determining module, configured to determine the target block to be archived from the multiple blocks to be archived based on the target block height and the block storage capacity of a single archive file; a writing and generating module, configured to write the target block to be archived from a local blockchain into an archive file, and record the position of the target block to be archived in the written archive file to generate an index file; a transferring module, configured to transfer the archive file and the index file to the archiving party corresponding to the block archiving request.

[0012] In a fourth aspect, an embodiment of the present application provides a blockchain-based data processing device, the device comprising: a receiving module, configured to receive archive files and index files sent by a blockchain node; wherein the archive files are generated by the blockchain node according to the target block to be archived in the local blockchain, and the index file is obtained by recording the position of the target block to be archived in the archive file; a storage module, configured to store the received archive files and index files.

[0013] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the blockchain-based data processing method as described above.

[0014] In a sixth aspect, an embodiment of the present application provides a computer-readable medium on which a computer program is stored, and when the computer program is executed by a processor, the blockchain-based data processing method as described above is implemented.

[0015] In a seventh aspect, an embodiment of the present application provides a computer program product, including computer instructions, which, when executed by a processor, implement the blockchain-based data processing method as described above.

[0016] In the technical solution provided in the embodiments of the present application:

[0017] After receiving the block archiving request containing the target block height, the blockchain node will determine that the target block to be archived is written into the archive file by the local blockchain, and record the position of the target block to be archived in the archive file written into it, generate an index file, and transfer the archive file and the index file to the archiving party; in this way, the rapid archiving of the blocks to be archived is achieved, avoiding the low archiving efficiency of a single block in the related technology. At the same time, since the position of the target block to be archived in the archive file written into it is recorded, it is more convenient for the later management of the blocks such as query and recovery, which is suitable for a wide range of scenarios and improves the data processing based on blockchain.

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

[0019] Figure 1 It is a schematic diagram of the structure of the blockchain network;

[0020] Figure 2 It is a schematic diagram of the connection relationship between blocks in the blockchain;

[0021] Figure 3is a schematic diagram of an exemplary implementation environment to which the technical solution of the embodiments of the present application can be applied;

[0022] Figure 4 is a flowchart of a data processing method based on blockchain shown in an exemplary embodiment of the present application;

[0023] Figure 5 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0024] Figure 6 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0025] Figure 7 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0026] Figure 8 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0027] Fig. 9 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0028] Fig.10 is a flowchart of a data processing method based on blockchain shown in an exemplary embodiment of the present application;

[0029] Fig.11 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0030] Fig.12 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0031] Fig.13 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0032] Fig.14 is a schematic diagram of the structure of a block in a xxx.fdb file shown in an exemplary embodiment of the present application;

[0033] Fig.15 is a schematic diagram of an interface shown in an exemplary embodiment of the present application;

[0034] Fig.16 is a schematic diagram of an exemplary implementation environment to which the technical solution of the embodiments of the present application can be applied;

[0035] Fig.17is a schematic diagram of an interface shown in another exemplary embodiment of the present application;

[0036] Fig.18 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0037] Fig.19 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0038] Fig. 20 is a schematic diagram of an interface shown in another exemplary embodiment of the present application;

[0039] Fig.21 is a schematic diagram of block archiving shown in another exemplary embodiment of the present application;

[0040] Fig. 22 is a schematic diagram of an interface shown in another exemplary embodiment of the present application;

[0041] Fig.23 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0042] Fig.24 is a flowchart of a data processing method based on blockchain shown in another exemplary embodiment of the present application;

[0043] Fig.25 is a schematic diagram of an interface shown in another exemplary embodiment of the present application;

[0044] Fig.26 is a schematic diagram of block recovery shown in another exemplary embodiment of the present application;

[0045] Fig. 27 is a block diagram of an exemplary embodiment of the present application showing a data processing device based on blockchain;

[0046] Fig.28 is a block diagram of another exemplary embodiment of the present application showing a data processing device based on blockchain;

[0047] Fig.29 It is a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0048] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments that are the same as the present application. Instead, they are only examples of devices and methods that are the same as some aspects of the present application as detailed in the attached claims.

[0049] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

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

[0051] It should be noted that the "multiple" mentioned in this application refers to two or more than two. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship.

[0052] Before introducing the technical solution of the embodiment of the present application, the blockchain technology used in the embodiment of the present application is first introduced.

[0053] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks (i.e. blocks) generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0054] As mentioned above, blockchain is essentially a decentralized database, and the blockchain is maintained by the nodes in the blockchain network. Figure 1 ,exist Figure 1The blockchain network shown may include multiple nodes 101, and the multiple nodes 101 may be the various clients forming the blockchain network. Each node 101 may receive input information during normal operation, and maintain the shared data in the blockchain network based on the received input information. In order to ensure the information intercommunication within the blockchain network, there may be an information connection between each node in the blockchain network, and the nodes may transmit information through the above information connection. For example, when any node in the blockchain network receives input information, the other nodes in the blockchain network obtain the input information according to the consensus algorithm, and store the input information as shared data, so that the data stored on all nodes in the blockchain network are consistent.

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

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

[0057] Each node in the blockchain network can be a server or a terminal device. The server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and intelligent platforms. The terminal device can be a smart phone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, etc., but is not limited to this. Each node can be directly or indirectly connected by wired or wireless communication, and this application is not limited here.

[0058] The aforementioned cloud computing refers to the delivery and use model of IT infrastructure, specifically refers to obtaining required resources through the network in an on-demand, easily scalable manner; in a broad sense, cloud computing refers to the delivery and use model of services, which refers to obtaining required services through the network in an on-demand, easily scalable manner. This service can be related to IT and software, the Internet, or other services. Cloud computing is the product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing. With the development of the Internet, real-time data streams, and the diversification of connected devices, as well as the promotion of search services, social networks, mobile commerce, and open collaboration, cloud computing has developed rapidly. Different from the previous parallel distributed computing, the emergence of cloud computing will promote revolutionary changes in the entire Internet model and enterprise management model in terms of concept.

[0059] The aforementioned blockchains are generally divided into three types: public blockchain, private blockchain and consortium blockchain. In addition, there can also be a combination of the above types, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain, etc.

[0060] Among them, the public chain has the highest degree of decentralization. Participants who join the public chain (also known as nodes in the blockchain network) can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, each node can freely join or exit the blockchain network and perform related operations.

[0061] On the contrary, the private chain has a blockchain network where the write permission is controlled by a certain organization or institution, and the data read permission is regulated by the organization. In simple terms, a private chain can be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a specific organization.

[0062] The consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the consortium chain usually has a corresponding entity or organization; the nodes join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain network.

[0063] In the related art, a single block on the blockchain is used as a unit for archiving, which has a low archiving efficiency. Therefore, in order to improve the data processing based on the blockchain and improve the archiving efficiency, this application provides a data processing solution based on the blockchain.

[0064] See also Figure 3 , Figure 3 301, a blockchain node 302, and an archiver 303. It is understood that the requester 301, the blockchain node 302, and the archiver 303 are connected through a network communication, and the network may include various connection types, such as wireless communication links, wired and optical fiber cables, etc. Among them:

[0065] The requester 301 is the party that initiates the request, and can initiate a request to the blockchain node and / or the archiver, wherein the request initiated by the requester may be a block archive request, a block query request, a block recovery request, etc.

[0066] Exemplarily, the requester can be any electronic device or server. The electronic device can be a smart phone, tablet, laptop, computer, intelligent voice interaction device, smart home appliance, smart wearable device, aircraft, etc. 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, content distribution networks, big data and artificial intelligence platforms, etc.

[0067] Blockchain node 302 is Figure 3 Any node in the blockchain network shown will not be described in detail here.

[0068] The archiving party 303 is the party that archives the blocks on the local blockchain of the blockchain node to avoid the local blockchain data of the blockchain node occupying a large storage space.

[0069] Exemplarily, the archiving party can be any electronic device or server. The electronic device can be a smart phone, tablet, laptop, computer, intelligent voice interaction device, smart home appliance, smart wearable device, aircraft, etc. 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, content distribution networks, big data and artificial intelligence platforms, etc.

[0070] It is understandable that the requesting party and the archiving party may be the same party or different parties.

[0071] Exemplarily, in a scenario where both parties are the same party, the requesting party may be the corresponding administrator on the archiving party side, and the administrator may issue a corresponding request through a terminal device.

[0072] Exemplarily, in a scenario where the two are different parties, the requesting party may be a third party (such as an administrator corresponding to another institution, who may issue a corresponding request through a terminal device), and the archiving party may be a specific database, etc.

[0073] It should be noted that Figure 3 The number of terminals corresponding to the requesting party 301, the number of servers corresponding to the blockchain node 302, and the number of servers corresponding to the archiving party 303 are merely illustrative, and any number of terminals and servers may be provided according to actual needs.

[0074] In one embodiment of the present application, the blockchain-based data processing method can be interactively executed by the requester 301, the blockchain node 302, and the archiver 303.

[0075] Exemplarily, the requesting party sends a block archiving request containing a target block height to the blockchain node, where the target block height is used to represent the largest block height among multiple blocks to be archived.

[0076] Correspondingly, the blockchain node receives the block archiving request sent by the requester; then, based on the target block height and the block storage capacity of a single archive file, the target block to be archived is determined from multiple blocks to be archived; then, the target block to be archived is written from the local blockchain to the archive file, and the position of the target block to be archived in the written archive file is recorded to generate an index file; then, the archive file and the index file are transferred to the archiver corresponding to the block archiving request.

[0077] Correspondingly, the archiver receives the archive files and index files sent by the blockchain node, and then stores the received archive files and index files.

[0078] It should be noted that in the specific implementation of this application, user-related data is involved. When the 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.

[0079] The following is a detailed description of various implementation details of the technical solution of the embodiment of the present application:

[0080] See also Figure 4 , Figure 4 FIG. 1 is a flowchart of a data processing method based on blockchain shown in an embodiment of the present application. The data processing method based on blockchain can be executed by blockchain node 302. Figure 4 As shown, the data processing method based on blockchain includes at least S401 to S404, which are described in detail as follows:

[0081] S401, receiving a block archiving request containing a target block height sent by a requesting party; wherein the target block height is used to represent the maximum block height among multiple blocks to be archived.

[0082] In the embodiment of the present application, when the requesting party has a block archiving requirement, a block archiving request containing a target block height can be generated, and the block archiving request containing the target block height can be sent to the blockchain node; accordingly, the blockchain node receives the block archiving request containing the target block height sent by the requesting party.

[0083] In the embodiment of the present application, the block archiving request containing the target block height is used to instruct the blockchain node to archive multiple blocks to be archived on the local blockchain, and they need to be archived to the block corresponding to the target block height.

[0084] For example, if the target block height contained in the block archiving request is 100, the blockchain node needs to start archiving from the next block adjacent to the currently archived block until it archives the block corresponding to the block height 100.

[0085] S402, determining a target block to be archived from multiple blocks to be archived based on the target block height and the block storage capacity of a single archive file.

[0086] In the embodiment of the present application, after the blockchain node receives the block archiving request, it can determine the target block to be archived from multiple blocks to be archived based on the target block height and the block storage capacity of a single archive file.

[0087] In the embodiment of the present application, an archive file refers to a file used to store blocks. It can be understood that a single archive file refers to each archive file, and each archive file has a fixed block storage capacity.

[0088] Exemplarily, the block storage capacity may be the number of blocks that each archive file may store; for example, each archive file may store 10,000 blocks.

[0089] Exemplarily, the block storage capacity can be the maximum space that each archive file can store; for example, each archive file has 10G of storage space. In actual applications, the size of each block may be different, so the number of blocks stored in each archive file may be different. Usually, each archive file can store multiple blocks.

[0090] In the embodiment of the present application, the target block to be archived refers to a block to be archived determined from multiple blocks to be archived. The number of the target blocks to be archived may be the same as or different from the number of the multiple blocks to be archived (i.e., the number of the target blocks to be archived is less than the number of the multiple blocks to be archived).

[0091] S403, writing the target block to be archived from the local blockchain into the archive file, and recording the position of the target block to be archived in the written archive file to generate an index file.

[0092] In the embodiment of the present application, the blockchain node determines a target block to be archived from multiple blocks to be archived, and then writes the target block to be archived from the local blockchain into the archive file, and records the position of the target block to be archived in the written archive file to generate an index file.

[0093] Exemplarily, the local blockchain and the archive file may be for the same database; for example, the storage area corresponding to the local blockchain is storage area A in database 1, and the storage area corresponding to the archive file is storage area B in database 1, where storage area A and storage area B are different.

[0094] Exemplarily, the local blockchain and the archive file may be for different databases; for example, the repository corresponding to the local blockchain is database 1, while the repository corresponding to the archive file is database 2.

[0095] In the embodiment of the present application, the index file refers to a file that records the position of the target file to be archived in the archive file to which it is written.

[0096] For example, if the 100 target to-be-archived blocks with block heights 100-199 are written into archive file 1, then the generated index file contains the positions of the 100 target to-be-archived blocks with block heights 100-199 in archive file 1 respectively.

[0097] In the embodiment of the present application, the archive files and index files can be in a one-to-one, one-to-many, many-to-one or many-to-many relationship.

[0098] For example, the target block to be archived is written into the archive file by the local blockchain, and an archive file 1 is generated. Optionally, there is also an index file, where index file 1 is used to record the position of the target block to be archived in the archive file 1 written thereto.

[0099] For another example, the target block to be archived is written into the archive file by the local blockchain, and an archive file 1 is generated. Optionally, there are two index files, where index file 1 is used to record the position of part of the target block to be archived in the archive file 1 written thereto, and index file 2 is used to record the position of other parts of the target block to be archived in the archive file 2 written thereto.

[0100] For another example, the target block to be archived is written into the archive file by the local blockchain, generating two archive files 1-2. Optionally, there is one index file, where index file 1 is used to record the position of the target block to be archived in the archive file 1 written thereto, and is also used to record the position of the target block to be archived in the archive file 2 written thereto.

[0101] For another example, the target block to be archived is written into the archive file by the local blockchain, generating two archive files 1-2. Optionally, there are also two index files, where index file 1 is used to record the position of the target block to be archived in the archive file 1 written thereto, and index file 2 is used to record the position of the target block to be archived in the archive file 2 written thereto.

[0102] The difference between the local blockchain and the archived file as described in the above embodiment; wherein:

[0103] Exemplarily, the target block to be archived is written into the archive file by the local blockchain, which may mean that the target block to be archived changes in the storage area of ​​the same database; for example, following the above example, the target block to be archived is moved out of the storage area A in the stored database 1 and stored in the storage area B in the database 1.

[0104] Exemplarily, the target block to be archived is written into the archive file by the local blockchain, which may mean that the target block to be archived changes in different databases; for example, following the above example, the target block to be archived is moved out of the stored database 1 and stored in the database 2.

[0105] It should be noted that, in actual applications, the correspondence between archive files and index files can be flexibly adjusted according to specific application scenarios.

[0106] S404, transferring the archive file and the index file to the archiver corresponding to the block archive request.

[0107] In the embodiment of the present application, the blockchain node writes the target block to be archived from the local blockchain into the archive file, and records the position of the target block to be archived in the written archive file, generates an index file, and then can transfer the archive file and the index file to the archiving party corresponding to the block archiving request.

[0108] It can be understood that the blockchain node transfers the archive files and index files to the archiver corresponding to the block archive request, that is, the archive files and index files in the database corresponding to the blockchain node side are transferred to the database corresponding to the archiver side. After the transfer, the archive files and index files in the database corresponding to the blockchain node side will no longer exist, while the archive files and index files will be stored in the database corresponding to the archiver side.

[0109] In one embodiment of the present application, the block archiving request also contains identification information of the archiving party. The identification information is used to uniquely identify the archiving party, including but not limited to the name, identification number, etc. Accordingly, the process of transferring the archived file and the index file to the archiving party corresponding to the block archiving request in S404 may include:

[0110] Transfer archive files and index files to archivers with matching identification information.

[0111] In one embodiment of the present application, the process of transferring the archive file and the index file to the archiver corresponding to the block archive request in S404 may include:

[0112] Transfer the index file to the archiver corresponding to the block archive request;

[0113] After detecting that the index file is successfully transferred to the archiver, the archive file is transferred to the archiver.

[0114] That is, in the optional embodiment, the blockchain node first transfers the index file to the archiving party corresponding to the block archiving request, and after detecting that the index file is successfully transferred to the archiving party, it starts the transfer of the archive file to successfully transfer the archive file to the archiving party. In short, there is a time sequence relationship between the transfer of the index file and the archive file, in which the time of the index file transfer is before the time of the archive file transfer.

[0115] By implementing the optional embodiments, the situation in which the archive file is transferred first and the index file is transferred later is avoided, where a corresponding request such as a block query request is received, but an error is reported because the block in the archive file cannot be queried based on the index file because the archive file has been transferred, thereby ensuring the stability of the blockchain node.

[0116] In the embodiment of the present application, the target block to be archived is determined by the blockchain node and written into the archive file from the local blockchain, and the position of the target block to be archived in the archive file written is recorded, an index file is generated, and the archive file and the index file are transferred to the archiving party, thereby realizing the rapid archiving of the block to be archived. At the same time, since the position of the target block to be archived in the archive file written is recorded, it is more convenient for the later management of the block, such as query and recovery, and is suitable for a wide range of scenarios.

[0117] In one embodiment of the present application, another blockchain-based data processing method is provided, and the blockchain-based data processing method can be executed by the blockchain node 302. Figure 5 As shown, the blockchain-based data processing method may include S501, S401 to S402, and S404.

[0118] S501 is described in detail as follows:

[0119] S501, obtaining the starting offset and writing length of the target block to be archived in the archive file to be written, taking the starting offset and writing length as the position of the target block to be archived in the archive file to be written, and generating an index file.

[0120] In an embodiment of the present application, a blockchain node can obtain the starting offset and write length of the target block to be archived in the archive file written thereto during the process of writing the target block to be archived into the archive file, wherein the obtained starting offset and write length of the target block to be archived in the archive file written thereto are used as the position of the target block to be archived in the archive file written thereto, and then an index file can be generated based on the starting offset and write length of the target block to be archived in the archive file written thereto.

[0121] In the embodiment of the present application, the starting offset refers to the first write position of the target block to be archived in the archive file to which it is written, which is usually related to the target archive block written into the archive file before the target block to be archived.

[0122] In the embodiment of the present application, the write length refers to the total length of the target to-be-archived block written into the archive file.

[0123] Exemplarily, the index file is represented by In, then In={[block 0, starting offset, write length][block 1, starting offset, write length][block 3, starting offset, write length]...}

[0124] In one embodiment of the present application, the target block to be archived includes a block header and a block body. Accordingly, in S501, the starting offset and the write length of the target block to be archived in the archive file written thereto are obtained, and the starting offset and the write length are used as the position of the target block to be archived in the archive file written thereto, and the process of generating an index file may include:

[0125] Get the starting offset and write length of the block header and block body in the archive file to which they are written;

[0126] Generate an index file based on the starting offset and write length corresponding to the block header, and the starting offset and write length corresponding to the block body.

[0127] That is, in an optional embodiment, the blockchain node obtains the starting offset and write length of the block header in the archive file written thereto and the starting offset and write length of the block body in the archive file written thereto, wherein the starting offset and write length of the block header in the archive file written thereto are used as the position of the block header in the archive file written thereto, and the starting offset and write length of the block body in the archive file written thereto are used as the position of the block body in the archive file written thereto, and then an index file can be generated based on the starting offset and write length of the block header in the archive file written thereto and the starting offset and write length of the block body in the archive file written thereto.

[0128] By implementing the optional embodiment, the index file generated based on the starting offset and write length of the block header and block body in the archive file written respectively is more fine-grained, which is convenient for later query and recovery of blocks and is suitable for a wide range of scenarios.

[0129] In one embodiment of the present application, the block body includes multiple transactions. Accordingly, the process of obtaining the starting offset and the write length of the block body in the archive file to which it is written may include:

[0130] The starting offsets and write lengths of the multiple transactions in the archive file written thereto are obtained, and the starting offsets and write lengths of the multiple transactions in the archive file written thereto are used as the starting offsets and write lengths of the block body in the archive file written thereto.

[0131] That is, in an optional embodiment, the blockchain node obtains the starting offset and write length of multiple transactions in the archive file written thereto, respectively, to obtain the starting offset and write length of the block body in the archive file written thereto.

[0132] By implementing the optional embodiment, the index file generated based on the starting offsets and write lengths of multiple transactions in the archive files written thereto is more fine-grained, which is convenient for later query and recovery of blocks and is applicable to a wide range of scenarios.

[0133] It should be noted that Figure 5 For detailed description of S401 to S402 and S404, please refer to Figure 4 S401 to S402 and S404 shown are not described in detail here.

[0134] In the embodiment of the present application, the blockchain node can easily and quickly generate an index file by using the starting offset and the write length as the position of the target block to be archived in the archive file to be written.

[0135] In one embodiment of the present application, another blockchain-based data processing method is provided, and the blockchain-based data processing method can be executed by the blockchain node 302. Figure 6 As shown, the blockchain-based data processing method may include S601 to S603, S401 to S402, and S404.

[0136] In the embodiment of the present application, there are multiple target blocks to be archived.

[0137] It is understandable that the blocks on the local blockchain of a blockchain node can be divided into ordinary blocks and configuration blocks. Among them, ordinary blocks refer to blocks used to store transactions, and usually ordinary blocks store a large amount of data; while configuration blocks refer to some specific blocks that are inconvenient to delete, which can be blocks used to store data related to the local blockchain configuration. Usually, the amount of data stored in configuration blocks is small. Optionally, the configuration-related data can be consensus strategies, etc.

[0138] Therefore, in the embodiment of the present application, the blockchain node can detect whether there is a configuration block in multiple target blocks to be archived to obtain a detection result, and then perform corresponding processing based on the detection result. Exemplarily, the blockchain node can detect whether there is a configuration block in multiple target blocks to be archived based on the configuration block information.

[0139] S601 to S603 are described in detail as follows:

[0140] S601, if it is detected based on the configuration block information that there is a configuration block in multiple target blocks to be archived, then other target blocks to be archived except the configuration block are selected from the multiple target blocks to be archived as the target blocks to be archived; wherein the configuration block is used to store data related to the local blockchain configuration.

[0141] S602, writing the selected target block to be archived from the local blockchain into the archive file.

[0142] S603, recording the position of the selected target block to be archived in the archive file to be written, and generating an index file.

[0143] In the embodiment of the present application, the blockchain node detects whether there is a configuration block in multiple target blocks to be archived to obtain a detection result, and then performs corresponding processing based on the detection result, including the following two situations:

[0144] Case 1: If the detection result indicates that there is a configuration block among multiple target blocks to be archived, other target blocks to be archived except the configuration block can be selected from the multiple target blocks to be archived as target blocks to be archived, and then the selected target blocks to be archived are written from the local blockchain to the archive file, and the position of the selected target blocks to be archived in the written archive file is recorded to generate an index file.

[0145] Case 2: If the detection result indicates that there is no configuration block in the multiple target blocks to be archived, the multiple target blocks to be archived are written from the local blockchain into the archive file, and the positions of the multiple target blocks to be archived in the written archive file are recorded respectively to generate an index file.

[0146] That is, in the embodiment of the present application, the blockchain node writes ordinary blocks from the local blockchain into the archive file, and records the position of the ordinary blocks in the archive file written thereto to generate an index file.

[0147] It should be noted that Figure 6 For detailed description of S401 to S402 and S404, please refer to Figure 4 S401 to S402 and S404 shown are not described in detail here.

[0148] In the embodiment of the present application, the blockchain node archives the ordinary blocks on the local blockchain, and does not archive the configuration blocks due to the small amount of data. The archiving flexibility is high and it is suitable for a wide range of scenarios.

[0149] In one embodiment of the present application, another blockchain-based data processing method is provided, and the blockchain-based data processing method can be executed by the blockchain node 302. Figure 7 As shown, the blockchain-based data processing method may include S701 to S702, S401, and S403 to S404.

[0150] In the embodiment of the present application, the blockchain node determines the target block to be archived from multiple blocks to be archived based on the target block height and the block storage capacity of a single archive file. The target block to be archived can be determined from multiple blocks to be archived based on the target block height, the block storage capacity of a single archive file, the maximum allowed archive height, and the maximum block height of the currently archived blocks.

[0151] In the embodiment of the present application, the maximum allowed archiving height refers to the maximum block height in the blocks that can be archived. Exemplarily, M is used to represent the maximum allowed archiving height, that is, M=NQ, where N refers to the latest block height on the local blockchain, and Q refers to the number of blocks on the local blockchain that are not allowed to be archived, which can usually be set flexibly. At the same time, according to actual applications, the blocks included in the number of blocks on the local blockchain that are not allowed to be archived can be ordinary blocks and / or configuration blocks.

[0152] For example, suppose the latest block height N on the local blockchain is 91000, and the number of blocks that are not allowed to be archived Q is 1000, then the maximum allowed archiving height M = 91000-1000 = 90000, that is, the maximum block height that can be archived is 90000.

[0153] In the embodiment of the present application, the maximum block height among the currently archived blocks refers to the maximum block height among the currently archived blocks.

[0154] For example, if 59999 blocks have been archived, the maximum block height among the archived blocks is 59999.

[0155] Exemplarily, the blockchain node may detect the size relationship between the target block height and the maximum block height in the currently archived blocks based on the target block height.

[0156] Exemplarily, the blockchain node can detect the number of archive files corresponding to multiple blocks to be archived written into the archive file based on the target block height and the block storage capacity of a single archive file.

[0157] Exemplarily, the blockchain node can detect the size relationship between the target block height and the maximum allowed archiving height based on the target block height.

[0158] S701 to S702 are described in detail as follows:

[0159] S701, if it is detected that the target block height is greater than the maximum block height among the currently archived blocks and less than the maximum allowed archive height, and at the same time there are a specified number of blocks to be archived among the multiple blocks to be archived that cannot meet the block storage capacity of a single archive file, then determine the other blocks to be archived except the specified number of blocks to be archived from the multiple blocks to be archived.

[0160] S702: Use other blocks to be archived as target blocks to be archived.

[0161] In the embodiment of the present application, if the blockchain node detects that the target block height is greater than the maximum block height among the currently archived blocks and less than the maximum allowed archiving height, and at the same time, there are a specified number of blocks to be archived among the multiple blocks to be archived that cannot meet the block storage capacity of a single archive file, then other blocks to be archived except the specified number of blocks to be archived are determined from the multiple blocks to be archived. At this time, the other blocks to be archived determined are the target blocks to be archived.

[0162] It can be understood that the existence of a specified number of blocks to be archived among the multiple blocks to be archived cannot meet the block storage capacity of a single archive file, which means that the total number of corresponding blocks to be archived is greater than the block storage capacity of a single archive file, but there is a part of the number of blocks to be archived that cannot meet the block storage capacity of a single archive file.

[0163] For example, let's assume that the target block height is 79999, the maximum block height of the currently archived blocks is 59999, the maximum allowed archive height is 90000, and the block storage capacity of a single archive file is 15000 blocks. Obviously, 59999<79999<90000, and because the 5000 to-archive blocks from 75000 to 79999 cannot satisfy the storage capacity of a single archive file of 15000, 15000 to-archive blocks from 60000 to 79999 are selected as the target to-archive blocks.

[0164] In one embodiment of the present application, if any of the following situations is detected, an archive failure result is generated and returned to the requesting party:

[0165] Case 1: It is detected that the target block height is less than the maximum block height among the currently archived blocks.

[0166] For example, let the target block height be 50000, and the maximum block height in the currently archived blocks is 59999. Obviously, 50000<59999, and archiving cannot be completed at this time, and an archiving failure result can be generated and returned to the requester.

[0167] Case 2: It is detected that the total number of blocks to be archived is less than the block storage capacity of a single archive file.

[0168] For example, let's assume that the target block height is 69999, the maximum block height of the currently archived blocks is 59999, and the block storage capacity of a single archive file is 15,000 blocks. Obviously, the 10,000 blocks to be archived from 60,000 to 69999 cannot satisfy the storage capacity of a single archive file of 15,000. In this case, archiving cannot be completed, and an archiving failure result can be generated and returned to the requester.

[0169] Case 3: It is detected that the target block height is greater than the maximum allowed archive height.

[0170] For example, suppose the target block height is 90005 and the maximum allowed archiving height is 90000. Obviously, 90005>90000, then archiving cannot be completed at this time, and an archiving failure result can be generated and returned to the requesting party.

[0171] It should be noted that Figure 7 For detailed description of S401, S402 to S404, please refer to Figure 4 S401, S402 to S404 shown are not described in detail here.

[0172] In the embodiment of the present application, the blockchain node determines the target block to be archived from multiple blocks to be archived through the target block height, the block storage capacity of a single archive file, the maximum allowed archive height, and the maximum block height in the currently archived blocks. A more accurate target block to be archived can be determined more accurately, thereby ensuring the accuracy of block archiving.

[0173] In one embodiment of the present application, another blockchain-based data processing method is provided, and the blockchain-based data processing method can be executed by the blockchain node 302. Figure 8 As shown, the blockchain-based data processing method may further include S801 to S802 after S404.

[0174] S801 to S802 are described in detail as follows:

[0175] S801, if a block query request containing a specified block height is received from a requesting party, and it is detected that the block with the specified block height is not on the local blockchain, a block query request containing the specified block height is sent to the archiving party; wherein the block query request is used by the archiving party to obtain the block with the specified block height from the archive file corresponding to the specified block height based on the index file corresponding to the specified block height, and return the obtained block.

[0176] S802, sending the received block to the requesting party.

[0177] In the embodiment of the present application, when the requesting party has a block query demand, a block query request containing a specified block height can be generated, and the block query request containing the specified block height can be sent to the blockchain node; accordingly, the blockchain node receives the block query request containing the specified block height sent by the requesting party, and detects whether the block of the specified block height is on the local blockchain.

[0178] In the embodiment of the present application, the blockchain node detects whether the block of the specified block height is on the local blockchain, including the following two situations:

[0179] Case 1: if it is detected that the block of the specified block height is not on the local blockchain, a block query request containing the specified block height is sent to the archiver; accordingly, the archiver receives the block query request containing the specified block height sent by the blockchain node, and based on the index file corresponding to the specified block height, obtains the block of the specified block height from the archive file corresponding to the specified block height, and returns the block of the specified block height to the blockchain node; accordingly, the blockchain node receives the block of the specified block height returned by the archiver, and returns the block of the specified block height to the requester.

[0180] That is, in an optional embodiment, if the blockchain node detects that the block of the specified block height is not on the local blockchain, then the block of the specified block height has been archived to the archiver, and a query needs to be performed from the archiver to obtain the block of the specified block height.

[0181] Exemplarily, when the archiver obtains a block of a specified block height from an archive file corresponding to the specified block height based on an index file corresponding to the specified block height, the block of the specified block height may be directly returned to the requester.

[0182] By implementing the optional embodiment, after obtaining the block of the specified block height, the archiving party directly returns the block of the specified block height to the requesting party, which can improve the query efficiency of the specified block height.

[0183] Case 2: If it is detected that the block of the specified block height is on the local blockchain, the block of the specified block height is obtained from the local blockchain and returned to the requesting party.

[0184] That is, in an optional embodiment, if the blockchain node detects that the block of the specified block height is on the local blockchain, it can query the local blockchain to obtain the block of the specified block height.

[0185] It should be noted that Figure 8 For detailed description of S401 to S404, please refer to Figure 4 S401 to S404 shown, and S801 to S802 may be executed earlier or later than any step of S401 to S404, which will not be described in detail here.

[0186] In the embodiment of the present application, after the blockchain node detects that the block of the specified block height has been archived, it queries the block of the specified block height from the archiver to return the queried block of the specified block height, thereby ensuring the success rate of the block query.

[0187] In one embodiment of the present application, another blockchain-based data processing method is provided, and the blockchain-based data processing method can be executed by the blockchain node 302. Fig. 9 As shown, the blockchain-based data processing method may further include S901 to S902 after S404.

[0188] S901 to S902 are described in detail as follows:

[0189] S901, receiving multiple sets of blocks to be restored sent by the archiving party; wherein the multiple sets of blocks to be restored are generated after the archiving party receives a block restoration request containing a target block height interval sent by the requesting party.

[0190] In the embodiment of the present application, when the requesting party has a block recovery demand, a block recovery request containing a target block height interval can be generated, and the block recovery request containing the target block height interval can be sent to the archiving party; accordingly, the archiving party receives the block recovery request containing the target block height interval sent by the requesting party, and generates multiple sets of blocks to be recovered, and then sends the multiple sets of blocks to be recovered to the blockchain node, wherein the generation process of multiple sets of blocks to be recovered is described in the following embodiment; accordingly, the blockchain node receives the multiple sets of blocks to be recovered sent by the archiving party.

[0191] S902, restore a specified number of blocks corresponding to each set of blocks to be restored on the local blockchain.

[0192] In the embodiment of the present application, the blockchain node receives multiple sets of blocks to be restored sent by the archiving party, and then can restore the specified number of blocks corresponding to each set of blocks to be restored on the local blockchain.

[0193] In one embodiment of the present application, the specified number of blocks contained in each set of blocks to be recovered are sorted from small to large according to the block height. For example, assuming that the target height interval is 80000-50000, and assuming that each set of blocks to be recovered contains 10000 blocks, the blocks contained in the multiple sets of blocks to be recovered are 70001-80000, 60001-70000, 50001-60000, and 50000 respectively (the number of blocks contained in the last set of blocks to be recovered can be flexibly adjusted according to the specific application scenario, for example, the last set of blocks to be recovered in the example contains 1 block).

[0194] Accordingly, the process of restoring the specified number of blocks corresponding to each set of blocks to be restored on the local blockchain in S902 may include:

[0195] For each block set to be restored, if it is detected that the block heights of a specified number of blocks included in the block set to be restored are discontinuous, a configuration block satisfying the block height continuity is obtained from the configuration file;

[0196] Complete block recovery on the local blockchain based on the acquired configuration block and the specified number of blocks contained in the set of blocks to be recovered.

[0197] As described in the above embodiment, when archiving, a common block is selected for archiving, then when the block is restored, the configuration block needs to be restored together. It can be understood that in the above embodiment, the configuration block can be written into the configuration file, which is stored in the database corresponding to the blockchain node side.

[0198] Therefore, in an optional embodiment, for each set of blocks to be recovered, the blockchain node can detect whether the block heights of a specified number of blocks contained in the set of blocks to be recovered are continuous. If they are not continuous, it indicates that there are configuration blocks that need to be recovered. If they are continuous, it indicates that there are no configuration blocks that need to be recovered.

[0199] Among them, in an optional embodiment, for each set of blocks to be recovered, the blockchain node can obtain a configuration block that satisfies the block height continuity from the configuration file, and then complete the block recovery on the local blockchain based on the obtained configuration block and the specified number of blocks contained in the set of blocks to be recovered.

[0200] For example, following the previous example, taking the block set 70001-80000 to be recovered as an example, if the block heights 70005 and 71500 in 70001-80000 are configuration blocks, then the blockchain node obtains the blocks with block heights 70005 and 71500 from the configuration file, and then completes block recovery on the local blockchain based on block heights 70001-70004, 70005, 70006-71499, 71500, and 71501-80000.

[0201] It should be noted that the requesting party mentioned in each embodiment may be the same requesting party or different requesting parties; in actual application, it can be flexibly adjusted according to the specific application scenario.

[0202] It should be noted that Fig. 9 For detailed description of S401 to S404, please refer to Figure 4 S401 to S404 shown, while S901 to S902 can be executed earlier or later than any step of S401 to S404, and will not be described in detail here.

[0203] In the embodiment of the present application, after receiving multiple sets of blocks to be recovered sent by the archiving party, the blockchain node recovers the specified number of blocks corresponding to each set of blocks to be recovered on the local blockchain, so that block recovery can be completed simply and quickly.

[0204] It should be noted that Figures 4 to 9 The embodiment shown is explained from the perspective of blockchain nodes. Figures 10 to 14 The implementation details of the technical solution of the embodiment of the present application are elaborated in detail from the perspective of the archiving party:

[0205] See also Fig.10 , Fig.10 is a flowchart of a data processing method based on blockchain shown in an embodiment of the present application. The data processing method based on blockchain can be executed by the archiving party 303. Fig.10 As shown, the blockchain-based data processing method at least includes S1001 to S1002, which are described in detail as follows:

[0206] S1001, receiving an archive file and an index file sent by a blockchain node; wherein the archive file is generated by the blockchain node according to a target block to be archived in a local blockchain, and the index file is obtained by recording the position of the target block to be archived in the archive file.

[0207] In the embodiment of the present application, the blockchain node receives a block archiving request containing a target block height sent by the requesting party, and then generates an archive file based on the target block to be archived in the local blockchain, and records the position of the target block to be archived in the archive file to generate an index file, and then sends the archive file and the index file to the archiver, wherein the generation process of the archive file and the index file please refer to the introduction of the aforementioned embodiment; accordingly, the archiver receives the archive file and the index file sent by the blockchain node.

[0208] S1002: Store the received archive files and index files.

[0209] In the embodiment of the present application, the archiver receives the archive files and index files sent by the blockchain node, and then can store the received archive files and index files.

[0210] In one embodiment of the present application, the process of storing the received archive files and index files in S1002 may include:

[0211] Obtain the maximum block height among multiple archive files stored; wherein the multiple archive files come from multiple different blockchain nodes;

[0212] If the minimum block height in the received archive file is greater than the maximum block height, the received archive file and index file are stored.

[0213] That is, in an optional embodiment, the archiving party receives the archive file and the index file, and then can perform detection based on the received archive file and the multiple stored archive files to obtain a detection result, and then perform corresponding processing based on the detection result.

[0214] It is understandable that, since the same blockchain may correspond to multiple blockchain nodes, in an optional embodiment, multiple blockchain nodes corresponding to the same blockchain may initiate a block archiving request for the same blockchain to the archiving party; accordingly, the multiple archived files stored by the archiving party may come from multiple blockchain nodes corresponding to the same blockchain.

[0215] For example, since the blocks corresponding to the same blockchain are the same, in an optional embodiment, any one of the multiple blockchain nodes corresponding to the same blockchain initiates a block archiving request to the archiving party, and as long as the archiving of any one of the multiple blockchain nodes to the archiving party is successful, the other blockchain nodes in the multiple blockchain nodes can delete the target block to be archived on their own local blockchain.

[0216] For example, suppose blockchain 1 corresponds to 3 blockchain nodes 1-3, and the latest block height on blockchain 1 is 35,000.

[0217] Assume that blockchain node 1 initiates a block archiving request with a target block height of 9999 to the archiving party, and the block is successfully archived to the archiving party. Then, blockchain nodes 2-3 no longer need to initiate a block archiving request with a target block height of 9999 to the archiving party separately. They only need to delete blocks 0-9999 on their local blockchain 1.

[0218] Assume that blockchain node 2 initiates a block archiving request with the target block height 19999 to the archiving party, and the block is successfully archived to the archiving party. Then, blockchain nodes 1 and 3 no longer need to initiate a block archiving request with the target block height 19999 to the archiving party separately. They only need to delete blocks 10000-19999 on their local blockchain 1.

[0219] Assume that blockchain node 3 initiates a block archiving request containing the target block height 29999 to the archiving party, and the block is successfully archived to the archiving party. Then, blockchain nodes 2-3 no longer need to initiate a block archiving request containing the target block height 29999 to the archiving party separately. They only need to delete blocks 20000-29999 on their respective local blockchains 1.

[0220] For example, although the blocks corresponding to the same blockchain are the same, different blockchain nodes can decide their own archiving status. Therefore, in an optional embodiment, a certain blockchain node among the multiple blockchain nodes corresponding to the same blockchain initiates a block archiving request to the archiving party, and the certain blockchain node successfully archives to the archiving party, which has nothing to do with whether other blockchain nodes among the multiple blockchain nodes are archived, that is, other blockchain nodes among the multiple blockchain nodes do not need to delete the target to-be-archived blocks on their own local blockchains.

[0221] Among them, in the optional embodiment, the archiving party performs detection based on the received archived file and the stored multiple archived files to obtain the detection result, and then performs corresponding processing based on the detection result, including the following two cases:

[0222] Case 1: If it is detected that the smallest block height in the received archive file is greater than the largest block height among the multiple archive files stored, it means that the archiver has not currently stored an archive file similar to the received archive file, so the received archive file and index file need to be stored at this time.

[0223] That is, in case 1, no blockchain node among the multiple blockchain nodes corresponding to the same blockchain has repeatedly initiated a block archiving request containing the same target block height to the archiving party, and the archiving party can now perform the archiving.

[0224] Case 2: If it is detected that the smallest block height in the received archive file is less than or equal to the largest block height among the multiple archive files that have been stored, it means that the archiver has currently stored an archive file similar to the received archive file, so there is no need to store the received archive file and index file at this time.

[0225] That is, in situation 2, at least two of the multiple blockchain nodes corresponding to the same blockchain repeatedly initiate block archiving requests containing the same target block height to the archiving party. In this case, the archiving party does not need to repeat the archiving.

[0226] Exemplarily, the archiver may send archived notification information to other blockchain nodes except the blockchain node corresponding to the first block archive request containing the target block height initiated to the archiver, so as to avoid repeated archiving of other blockchain nodes.

[0227] By implementing the optional embodiment, after detecting that the smallest block height in the received archive file is greater than the maximum block height, the archiver stores the received archive file and index file, thereby avoiding duplicate storage and saving storage space.

[0228] In one embodiment of the present application, the process of storing the received archive files and index files in S1002 may include:

[0229] Obtaining identification information of the blockchain corresponding to the received archive file;

[0230] If it is detected that the identification information matches any file directory in multiple file directories, the received archive files and index files are stored in the matching file directory; wherein each file directory is used to represent the identification information of the corresponding blockchain.

[0231] That is, in an optional embodiment, the archiver receives the archive file and the index file, and then can obtain the identification information of the blockchain corresponding to the received archive file, and match them with multiple file directories based on the obtained identification information, and then perform corresponding processing based on the matching results.

[0232] It is understandable that the archiving party can archive blocks on different blockchains. Therefore, in an optional embodiment, different blockchains can be distinguished by different file directories, for example, file directory 1 corresponds to blockchain 1, and file directory 2 corresponds to blockchain 2. Among them, the file directory can be calculated based on the identification information of the blockchain; illustratively, the identification information of the blockchain can be obtained by hashing the genesis block in the blockchain, and in actual applications, it can be flexibly adjusted according to the specific application scenario.

[0233] Among them, in the optional embodiment, the archiving party matches the acquired identification information with multiple file directories, and then performs corresponding processing based on the matching result, including the following two cases:

[0234] Case 1: If the obtained identification information matches any file directory among multiple file directories, it indicates that the received archive file and index file belong to the blockchain corresponding to the matching file directory. At this time, the received archive file and index file can be stored in the matching file directory.

[0235] Case 2: If the obtained identification information does not match all the file directories in the multiple file directories, it means that the received archive files and index files do not belong to the blockchain corresponding to the existing multiple file directories, so no processing is required, or a new file directory can be generated (generated using the method described above), and the received archive files and index files can be stored in the newly generated file directory.

[0236] By implementing an optional embodiment, after detecting that the identification information matches any file directory in multiple file directories, the archiver stores the received archive files and index files in the matching file directory, which is convenient for classification management, provides strong support for subsequent block query or recovery, and can improve the efficiency of subsequent block query or recovery.

[0237] In the embodiment of the present application, after the archiver receives the archive file and index file sent by the blockchain node, the archiver stores the received archive file and index file, thereby realizing the rapid archiving of the blocks to be archived. At the same time, since the position of the target block to be archived in the archive file written is recorded, it is more convenient for the subsequent management of the blocks such as query and recovery, and is suitable for a wide range of scenarios.

[0238] In one embodiment of the present application, another blockchain-based data processing method is provided, which can be performed by the archiving party 303. Fig.11 As shown, the blockchain-based data processing method may further include S1101 to S1104 after S1002.

[0239] S1101 to S1104 are described in detail as follows:

[0240] S1101, if a block recovery request containing a target block height interval is received from a requesting party, the block heights of a specified number of blocks that each set of blocks to be recovered must include are determined based on the target block height interval.

[0241] In an embodiment of the present application, when the requesting party has a block recovery requirement, a block recovery request containing a target block height interval can be generated, and the block recovery request containing the target block height interval can be sent to the archiving party; accordingly, the archiving party receives the block recovery request containing the target block height interval sent by the requesting party, and can then determine the block heights of a specified number of blocks that each set of blocks to be recovered must include based on the target block height interval.

[0242] For example, let the target height interval be 80000-50000, and let the specified number corresponding to each set of blocks to be recovered be 10000, that is, each set of blocks to be recovered can contain a maximum of 10000 blocks. Then, the block heights corresponding to the four sets of blocks to be recovered 1-4 are determined to be 70001-80000, 60001-70000, 50001-60000, and 50000, respectively.

[0243] S1102, based on the index file corresponding to the target block height interval, obtain the block corresponding to the block height contained in the target block height interval from the archive file corresponding to the target block height interval.

[0244] In the embodiment of the present application, the archiver receives a block recovery request containing a target block height interval sent by the requester, and then can obtain the block corresponding to the block height contained in the target block height interval from the archive file corresponding to the target block height interval based on the index file corresponding to the target block height interval.

[0245] For example, following the above example, based on the index file corresponding to the target height interval 80000-50000, the blocks corresponding to the block heights contained in the target height interval 80000-50000 are obtained from the archive file corresponding to the target height interval 80000-50000.

[0246] S1103, generating each set of blocks to be recovered based on the acquired blocks and the block heights of a specified number of blocks that each set of blocks to be recovered needs to include.

[0247] In the embodiment of the present application, the archiving party obtains the block height corresponding to the block height contained in the target block height interval and the block height of a specified number of blocks that each set of blocks to be restored must contain, and can generate each set of blocks to be restored.

[0248] For example, following the above example, the blocks contained in the four to-be-recovered block sets 1-4 are 70001-80000, 60001-70000, 50001-60000, and 50000 respectively.

[0249] S1104, sending each set of blocks to be recovered to the blockchain node corresponding to the block recovery request, so that the blockchain node corresponding to the block recovery request recovers a specified number of blocks corresponding to each set of blocks to be recovered on the local blockchain.

[0250] In the embodiment of the present application, the archiving party generates each set of blocks to be recovered, and then can send each set of blocks to be recovered to the blockchain node corresponding to the block recovery request; accordingly, the blockchain node corresponding to the block recovery request receives each set of blocks to be recovered sent by the archiving party, and recovers the specified number of blocks corresponding to each set of blocks to be recovered on the local blockchain.

[0251] For example, following the above example, the blockchain node recovers blocks 70001-80000, 60001-70000, 50001-60000, and 50000 contained in the four block sets 1-4 to be recovered on the local blockchain.

[0252] In one embodiment of the present application, after the process of sending each set of blocks to be recovered to the blockchain node corresponding to the block recovery request in S1104, the following may also be included:

[0253] Delete the archive files corresponding to the target block height range;

[0254] After detecting that the archive file corresponding to the target block height interval is successfully deleted, the index file corresponding to the target block height interval is deleted.

[0255] That is, in the optional embodiment, the archiving party first deletes the archive file corresponding to the target block height interval, and after detecting that the archive file corresponding to the target block height interval is successfully deleted, it starts deleting the index file corresponding to the target block height interval. In short, there is a time sequence relationship between the deletion of the archive file and the index file, in which the time of deleting the archive file is before the time of deleting the index file.

[0256] By implementing the optional embodiment, the phenomenon of low recovery efficiency caused by recovery errors but index files being deleted when the index files are deleted first and the archive files are deleted later is avoided, and the recovery efficiency of the blocks is further guaranteed.

[0257] It should be noted that Fig.11 For detailed description of S1001 to S1002, please refer to Fig.10 S1001 to S1002 are shown, and S1101 to S1104 can be executed earlier or later than any step of S1001 to S1002, which will not be described in detail here.

[0258] In the embodiment of the present application, the archiving party can easily and quickly generate each set of blocks to be recovered based on the acquired blocks and the block height of the specified number of blocks that each set of blocks to be recovered must contain, thereby providing strong support for block recovery.

[0259] In one embodiment of the present application, another blockchain-based data processing method is provided, which can be performed by the archiving party 303. Fig.12 As shown, the blockchain-based data processing method may include S1201 to S1202, S1101 to S1103, and S1001 to S1002.

[0260] In the embodiment of the present application, the specified number of blocks contained in each set of blocks to be restored are sorted from small to large according to the block height.

[0261] For example, following the previous example, block set 1 to be recovered = [70001, 70002, 70003...79998, 79999, 80000], block set 2 to be recovered = [60001, 60002, 60003...69998, 69999, 70000], block set 3 to be recovered = [50001, 50002, 50003...59998, 59999, 60000], and block set 4 to be recovered =

[50000] .

[0262] S1201 to S1202 are described in detail as follows:

[0263] S1201, obtaining the block height of the starting block contained in each set of blocks to be recovered, and obtaining the block heights of multiple starting blocks.

[0264] S1202, in descending order of the block heights of the multiple starting blocks, each set of blocks to be recovered is sent to the blockchain node corresponding to the block recovery request.

[0265] For example, following the above example, the block height of the starting block of block set 1 to be recovered is 70001, the block height of the starting block of block set 2 to be recovered is 60001, the block height of the starting block of block set 3 to be recovered is 50001, and the block height of the starting block of block set 4 to be recovered is 50000. Then, in the order of the block heights of the multiple starting blocks from large to small, block set 1 to be recovered is sent to the blockchain node, then block set 2 to be recovered is sent to the blockchain node, then block set 3 to be recovered is sent to the blockchain node, and then block set 4 to be recovered is sent to the blockchain node.

[0266] In one embodiment of the present application, the process of sending each set of blocks to be recovered to the blockchain node corresponding to the block recovery request in sequence according to the block heights of the multiple starting blocks from large to small in S1202 may include:

[0267] Each set of blocks to be recovered is written into the cache area in sequence according to the block heights of the multiple starting blocks from large to small; wherein the cache area is used for after each set of blocks to be recovered is successfully written into the cache area, the blockchain node corresponding to the block recovery request reads each set of blocks to be recovered from the cache area according to the writing order of each set of blocks to be recovered, so as to recover the specified number of blocks corresponding to each set of blocks to be recovered read on the local blockchain.

[0268] Among them, in an optional embodiment, the archiving party writes each set of blocks to be recovered into the cache area in sequence according to the block heights of multiple starting blocks from large to small; accordingly, after each set of blocks to be recovered is successfully written into the cache area, the blockchain node corresponding to the block recovery request can read each set of blocks to be recovered from the cache area according to the writing order of each set of blocks to be recovered, so as to recover the specified number of blocks corresponding to each set of blocks to be recovered read on the local blockchain.

[0269] That is, in an optional embodiment, there is a timing relationship between the archiving party writing the multiple sets of blocks to be recovered into the cache area and the blockchain node reading the multiple sets of blocks to be recovered from the cache area, wherein the time when the multiple sets of blocks to be recovered are written into the cache area is before the time when the blockchain node reads the multiple sets of blocks to be recovered from the cache area.

[0270] By implementing the optional embodiment, the error-prone phenomenon of the archiving party writing the set of blocks to be recovered and the blockchain node reading the set of blocks to be recovered in parallel is avoided, thereby ensuring the accuracy of block recovery.

[0271] It should be noted that Fig.12 For detailed description of S1101 to S1103, please refer to Fig.11 S1101 to S1103 shown, Fig.12 For detailed description of S1001 to S1002, please refer to Fig.10 S1001 to S1002 shown are not described in detail here.

[0272] In the embodiment of the present application, the archiving party sends each set of blocks to be recovered to the blockchain node corresponding to the block recovery request in sequence according to the block heights of multiple starting blocks from large to small, thereby avoiding the phenomenon of recovery errors caused by sending multiple blocks to be recovered at the same time and ensuring the accuracy of block recovery.

[0273] In one embodiment of the present application, another blockchain-based data processing method is provided, which can be performed by the archiving party 303. Fig.13 As shown, the blockchain-based data processing method may further include S1301 to S1303 after S1002.

[0274] S1301 to S1303 are described in detail as follows:

[0275] S1301, if a block query request for a specified block height is received from a blockchain node, and it is detected that a block of the specified block height is stored in a compressed archive file corresponding to the specified block height, the compressed archive file is decompressed to obtain a decompressed archive file.

[0276] S1302, based on the index file corresponding to the specified block height, obtain the block of the specified block height from the decompressed archive file.

[0277] S1303, returning the acquired block to the blockchain node.

[0278] In an embodiment of the present application, the blockchain node can send a block query request containing a specified block height to the archiving party; accordingly, the archiving party receives the block query request for the specified block height sent by the blockchain node, and detects whether the block of the specified block height is in the compressed archive file to obtain a detection result, and then performs corresponding processing based on the detection result.

[0279] In the embodiment of the present application, the archiving party detects whether the block of the specified block height is in the compressed archive file to obtain a detection result, and then performs corresponding processing based on the detection result, including the following two situations:

[0280] Case 1: If it is detected that the block of the specified block height is in the compressed archive file, it is necessary to decompress the compressed archive file to obtain the decompressed archive file, and based on the index file corresponding to the specified block height, obtain the block of the specified block height from the decompressed archive file, and then return the obtained block of the specified block height to the blockchain node.

[0281] Case 2: If it is detected that the block of the specified block height is in the decompressed archive file, the block of the specified block height is obtained from the decompressed archive file based on the index file corresponding to the specified block height, and then the obtained block of the specified block height is returned to the blockchain node.

[0282] In one embodiment of the present application, before decompressing the compressed archive file in S1301 to obtain the decompressed archive file, the following may also be included:

[0283] If it is detected that there is an archive file that has not been accessed within a specified period of time among the stored multiple archive files, the unaccessed archive file is compressed to obtain a compressed archive file.

[0284] That is, in an optional embodiment, the archiving party may detect the time when the stored multiple archived files are accessed to obtain a detection result, and then perform corresponding processing on the multiple archived files based on the detection result.

[0285] In the optional embodiment, the archiving party detects the time when the stored multiple archived files are accessed to obtain a detection result, and then performs corresponding processing on the multiple archived files based on the detection result, which may include the following two situations:

[0286] Case 1: If it is detected that there is an archive file that has not been accessed within a specified period of time among the multiple archive files stored, the archive file that has not been accessed is compressed to obtain a compressed archive file.

[0287] Case 2: if it is detected that each of the multiple archive files stored is accessed within a specified time period, no processing is required at this time.

[0288] It should be noted that the blockchain nodes mentioned in each embodiment may be the same blockchain node or different blockchain nodes; in actual applications, they can be flexibly adjusted according to specific application scenarios.

[0289] It should be noted that Fig.13 For detailed description of S1001 to S1002, please refer to Fig.10 S1001 to S1002 shown, and S1301 to S1303 can be executed earlier or later than any step of S1001 to S1002, which will not be described in detail here.

[0290] In the embodiment of the present application, the archiving direction blockchain node returns a block of a specified block height, thereby ensuring the success rate of block query.

[0291] The following is a detailed description of a specific scenario of an embodiment of the present application:

[0292] 1. Introduce archive files and index files.

[0293] 1.1. The file name of the archive file is: xxxxxxxxxxxxxxxxxxxx (usually 20 bytes in length), because common blockchains (developed based on golang) highly use uint64 data type, the maximum value of the field of this data type is 20 bytes in length (the file name length can be adapted according to the actual development language and the data type used according to this rule), and then add .fdb as the file suffix (to indicate fileDB); for example 00000000000000000001.fdb (referred to as xxx.fdb file).

[0294] Exemplarily, the file name of the xxx.fdb file is set to the block height of the first block stored in the file after conversion according to the file name rule. This setting allows the user to see the xxx.fdb file where the first block in a batch of consecutive blocks is located through the file; for example, the xxx.fdb file contains 5 blocks with block heights of 0, 1, 2, 3, and 4, then the file name can be 00000000000000000000.fdb.

[0295] 1.2. File size of archived files:

[0296] For example, a single xxx.fdb file storing blocks has a certain size limit. ChainMaker (a blockchain provided for a certain enterprise) is limited according to the size of xxx.fdb. For example, each xxx.fdb is limited to 1024MB, regardless of how many blocks are stored. In actual applications, the storage space size of a single xxx.fdb file can be flexibly adjusted according to the specific application scenario.

[0297] Exemplarily, a single xxx.fdb file storing blocks may also be set to store a certain number of blocks, for example, each xxx.fdb file stores 100 blocks; in actual applications, the number of blocks in a single xxx.fdb file may be flexibly adjusted according to specific application scenarios.

[0298] 1.3. The index information corresponding to the archived file is stored in KVDB. The structure of the index information is as follows:

[0299]

[0300] For example, the xxx.fdb file contains 10 blocks with block heights of 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9. Suppose it is divided into two xxx.fdb files, then the inclusion relationship between xxx.fdb and blocks can be shown in Table 1:

[0301]

[0302]

[0303] Table 1

[0304] It can be understood that an archive file (ie, xxx.fdb file) can be generated based on the included blocks, and an index file (eg, xxx.ldb file in leveldb) can be generated based on the included object indexes.

[0305] 1.4. Please refer to Fig.14 , which is a schematic diagram of the block structure in the xxx.fdb file.

[0306] like Fig.14 As shown, the serialized texts of multiple blocks constitute the xxx.fdb file, that is, a single xxx.fdb file includes the serialized texts of multiple blocks, wherein the serialized text of each block includes the serialized text of the block header, the serialized text of the transaction, and the serialized text of other objects in the block (such as read-write sets, etc.).

[0307] 1.5. Please refer to Fig.15 , schematic diagram of archive files and index files stored in a block file storage database.

[0308] like Fig.15 As shown, the bfdb file directory includes multiple xxx.fdb files, and the xxx.fdb.END file is the xxx.fdb file being written. When the size of the xxx.fdb.END file being written reaches the limited size, it is renamed to the xxx.fdb file, and a new xxx.fdb.END file is generated at the same time. The Blockdb file directory includes multiple xxx.ldb files. For example, the folder corresponding to the Blockdb file directory uses the database leveldb (a type of KVDB).

[0309] 2. Introduce the implementation environment.

[0310] See also Fig.16 , mainly including blockchain nodes and storage warehouses.

[0311] Exemplarily, there are N blockchain nodes (referred to as nodes) for blockchain 1, and N nodes for blockchain 2. Each node includes an RPC server (remote procedure call server) and a database for on-chain storage. Optionally, the node can store data in a BFDB manner.

[0312] Exemplarily, there are N storage warehouses, each of which includes an archive center or a database for off-chain storage. Optionally, the archive center can store data in a BFDB manner. The archive center is a data storage warehouse that transfers data from the chain to the off-chain data storage warehouse, responsible for storing and managing block data services, and provides an interface for querying data, including querying blocks, block headers, transactions and other information.

[0313] like Fig.16 As shown in the figure, each blockchain node can interact with the storage warehouse to implement functions such as archiving / recovery; among them:

[0314] 2.1. The block data of the same blockchain in the blockchain is basically the same, so multiple blockchain nodes of the same blockchain can share the same data.

[0315] 2.2. A single archiving center can connect to multiple blockchains, and the data of different blockchains need to be stored separately to facilitate data management of different blockchains.

[0316] For example, since a single archive center may correspond to multiple blockchains, for ease of management, Fig.15 The "bfdb" file directory in the corresponding blockchain can be represented as the hash of the genesis block. Further, the hash can be converted into a hexadecimal string for easy display, such as Fig.17 The file directory shown in "3e78a93a94fb12df26e6ca9d1ee6a7608c226d205999969769f86e6e5268c151".

[0317] 2.3. The relationship between the archive center and the blockchain nodes can be one-to-one, one-to-many, many-to-one or many-to-many.

[0318] 2.4. Archive file compression: The archive center should support compression of infrequently accessed xxx.fdb files, such as Fig.17 The compressed_data file directory in the , where the sub-file directories can also use the hexadecimal hash of the blockchain's genesis block to classify the compressed archive files of different blockchains.

[0319] For example, the compressed archive file is still in units of xxx.fdb and is directly compressed as a whole. After compression, the corresponding archive file in the block_data file directory is deleted (such as 00000000000000000001.fdb, which is not deleted for the convenience of display in the figure). Here, the suffix .7z represents the use of the 7z compression algorithm. In actual applications, the compression algorithm can be flexibly selected. At the same time, the compression mark is recorded in the leveldb corresponding to the system_info file directory.

[0320] 2.5. Reading archived files after compression: After the archive center compresses the archived files, it still supports reading, but the reading process requires the compressed archived files to be decompressed before reading.

[0321] For example, if the read data is in 00000000000000000001.fdb.7z, then the file needs to be decompressed into 00000000000000000001.fdb and stored in Fig.17 Optionally, after 00000000000000000001.fdb is used up, if it is not accessed within a specified time period, the archive file can be deleted.

[0322] 3. Based on Fig.16 The implementation environment shown in the figure introduces the block migration process.

[0323] See also Fig.18 ,like Fig.18 As shown, the blockchain-based data processing method includes at least S1801 to S1803, which are described in detail as follows:

[0324] S1801, the interactive tool sends a migration request (i.e., a dump request) to the blockchain node, where the migration request is used to request a block.

[0325] S1802, the blockchain node returns the block to the interactive tool based on the migration request.

[0326] S1803, the interactive tool forwards the block to the storage warehouse.

[0327] In the embodiment of the present application, the interactive tool is responsible for the interaction between the blockchain node and the archive center, which encapsulates the interface calling method of the blockchain node and the archive center. Optionally, the interactive tool can be a small tool program that runs independently, or it can also be integrated into other programs; in actual applications, the implementation form of the interactive tool can be flexibly adjusted according to the specific application scenario.

[0328] like Fig.18 As shown in the figure, the RPC server corresponding to the blockchain node can provide query services to the outside world, and the on-chain storage can clean up the block data; the storage warehouse can provide query services to the outside world and save the block data at the same time.

[0329] At this point, the block transfer is completed, and the transfer process is simple and easy to implement.

[0330] 4. Based on Fig.16 The implementation environment shown introduces the block archiving process.

[0331] See also Fig.19 ,like Fig.19 As shown, the blockchain-based data processing method includes at least S1901 to S1903, which are described in detail as follows:

[0332] S1901, the interactive tool sends an archiving request to the blockchain node, where the archiving request is used to request a block and is deleted after the block is archived.

[0333] S1902, the blockchain node returns the block to the interactive tool based on the archiving request.

[0334] S1903, the interactive tool forwards the block to the storage warehouse.

[0335] In the embodiment of the present application, the interactive tool is responsible for the interaction between the blockchain node and the archive center. It encapsulates the interface calling method of the blockchain node and the archive center, and is usually an independently running small tool program.

[0336] like Fig.19 As shown in the figure, the RPC server corresponding to the blockchain node can provide query services to the outside world, and the on-chain storage can clean up the block data; the storage warehouse can provide query services to the outside world and save the block data at the same time.

[0337] It can be understood that block archiving means that after migrating data from the blocks on the chain to the off-chain, the blocks on the chain need to be deleted in order to save disk storage space.

[0338] See also Fig. 20 , still taking the aforementioned ChainMaker as an example, the block height in ChainMaker's BFDB is 1 greater than the block height in the blockchain, that is, when the block height is 0, the block number in BFDB is 1.

[0339] like Fig. 20 As shown, where:

[0340] 4.1、 Fig. 20 Multiple xxx.fdb files are given as examples, namely: 000000000000000000001.fdb file, 00000000000000176519.fdb file, 00000000000000352658.fdb file, 000000000000000528797.fdb file, and 000000000000000704936.fdb file, etc.

[0341] It is understandable that the granularity at the time of archiving is all the blocks of an xxx.fdb file; for example, first archive the 00000000000000000001.fdb file in one go, and then archive the 00000000000000176519.fdb file until reaching the target archiving height in the archiving request received by the blockchain node (i.e., the target block height in the foregoing embodiment).

[0342] 4.2. The blockchain node will verify the target archiving height: archivePivot < targetArchivePivot < the maximum archiving height allowed by the blockchain node (i.e., the maximum allowed archiving height in the foregoing embodiment). Where archivePivot refers to the maximum block height in the currently archived blocks, and targetArchivePivot refers to the target archiving height; the maximum archiving height allowed by the blockchain node = the latest block height of the blockchain node - unarchive_block_height, where unarchive_block_height refers to the number of blocks not allowed to be archived.

[0343] 4.3. After receiving the target archiving height, the blockchain node will make adjustments based on the block heights of the xxx.fdb files in the bfdb folder (e.g., data / ut-conf / bfdb in the above figure), that is, the target archiving height expected by the user will be different from the actual archiving height, and the actual archiving height will be automatically converted to a block height less than or equal to the target archiving height and closest to the last block in xxx.fdb.

[0344] For example, still taking the Fig. 20 data database as an example, assume that the current archivePivot is 176517, as shown in Table 2, and at the same time assume that unarchive_block_height is 100:

[0345]

[0346] Table 2

[0347] The actual archiving calculation method is shown in Table 3:

[0348]

[0349]

[0350] Table 3

[0351] For easier understanding, please refer to Fig.21 , as Fig.21 shown, where:

[0352] 4.4.1.1. The longest horizontal axis represents the block height of the node. The value increases from left to right, which means that the node block height keeps increasing. Fig.21 The highest reached 400,000.

[0353] 4.4.1.2. There are two types of squares on the horizontal axis. The small squares represent config blocks, and the large squares represent ordinary blocks. A group of large squares connected together represent a group of ordinary blocks. Fig.21 The dot in the middle stands for "block file split point", which indicates the last block of each xxx.fdb.

[0354] 4.4.1.3. The arrow with archive written on the horizontal axis indicates that the archiving direction is to archive one by one along the block height on the blockchain node from low to high, and discontinuous archiving of jumping block heights is not allowed (except for configuration blocks).

[0355] 4.4.1.4. The small squares scattered on the horizontal axis represent the configuration blocks that appear randomly on the nodes. The most common configuration block is the genesis block.

[0356] 4.4.1.5. The horizontal axis is also marked with:

[0357] 4.4.1.5.1, archivePivot(50000): represents the maximum block height of the currently archived blocks of the blockchain node, that is, the block 50000 is archived, and the block 50000 has also been archived.

[0358] 4.4.1.5.2, targetArchivePivot(80000): represents the target archive height, that is, the block height that the user wants to archive to. It is understandable that the target archive height cannot be the configuration block, because configuration block archiving is not allowed in this embodiment, otherwise the request will report an error, and you only need to change the target archive height.

[0359] 4.4.1.5.3, unarchiveBlockHeight (100000): represents the number of blocks that the blockchain node is not allowed to archive, which is the same as the unarchive_block_height in the previous embodiment, to avoid too many archived blocks affecting the normal operation of the node. The unarchive_block_height can be flexibly configured in ChainMaker, and the default value can be 300000.

[0360] 4.4.1.5.4、 Fig.21The figure shows the status of the node when the blockchain node receives the target archive height of targetArchivePivot(80000). The node will delete the data of the corresponding block on the node from archivePivot(50000) until it processes targetArchivePivot(80000).

[0361] 4.4.2. From Table 2, we can see that the actual archivePivot is less than or equal to the block height of the last block of the most recent xxx.fdb file. Therefore, the archivePivot in the BFDB archiving scheme is only allowed to fall on the "block filesplit point". Fig.21 The status shown in the figure is that the archive point is archived from archivePivot(50000) to targetArchivePivot(80000).

[0362] 4.4.3. At the same time, save the configuration blocks encountered in the middle to Fig. 20 store_block in the configuration block, that is, when archiving, there is no need to deliberately avoid the configuration block as targetArchivePivot.

[0363] 4.4.4. The block height of archive blocks increases continuously, and discontinuous archive blocks are not allowed.

[0364] It can be understood that, as described in the aforementioned embodiment, the blockchain is composed of multiple continuous blocks; therefore, in order to continue to maintain the order between the blocks in the blockchain, continuous blocks are also used for archiving when archiving blocks, thereby ensuring the accuracy of subsequent archived block queries, management, etc.

[0365] 4.4.5. After receiving the archiving request, the blockchain node calculates the actual archiving height according to the received target archiving height after checking the block height, and then calculates the index information pointing to the xxx.fdb file in blockdb and resultdb in turn according to the xxx.fdb file name, and then stores it in the xxx.block.archiving.json file and xxx.result.archiving.json file in the bfdb / archiving file directory (result is a database similar to the block database in ChainMaker), such as Fig. 22 Middle frame line part.

[0366] 4.4.6. The archiving service in the blockchain node will scan the bfdb / archiving file directory every once in a while, and delete the corresponding data in blockdb and resultdb according to the xxx.block.archiving.json file and xxx.result.archiving.json file (the xxx.json file records the block index information to be deleted and the original data of the block to be transferred to the index database, as well as the key-value pairs of block height and block hash (used for data verification during data recovery), and then delete the corresponding xxx.fdb file under bfdb.

[0367] At this point, the archiving of the block is completed, and the archiving process is simple and easy to implement.

[0368] 5. Based on Fig.16 The implementation environment shown introduces the block query process.

[0369] See also Fig.23 ,like Fig.23 As shown, the blockchain-based data processing method includes at least S2301 to S2302, which are described in detail as follows:

[0370] S2301, the interactive tool sends a query request to the blockchain node, where the query request is used to query the block.

[0371] S2302: If the queried block has been archived, the interactive tool sends a query request to the storage warehouse.

[0372] In the embodiment of the present application, block-related data can be queried from a blockchain node or a storage warehouse, such as obtaining a block, obtaining a block header, obtaining a transaction, etc. The interactive tool can first obtain it from the blockchain node, and then obtain it from the storage warehouse if the blockchain node returns that it has been archived.

[0373] At this point, the query of the block is completed, and the query process is simple and easy to implement.

[0374] 6. Based on Fig.16 The implementation environment shown introduces the block recovery process.

[0375] See also Fig.24 ,like Fig.24 As shown, the blockchain-based data processing method includes at least S2401 to S2403, which are described in detail as follows:

[0376] S2401, the interactive tool sends a block acquisition request (i.e., a block recovery request) to the storage repository.

[0377] S2402, the storage repository returns the block to the interactive tool based on the block recovery request.

[0378] S2403, the interactive tool sends a block recovery request and a block to the blockchain node.

[0379] Exemplarily, when a blockchain node performs block recovery, it can verify the block to be recovered (based on the block height and hash data left in the blockchain node during archiving), and reject block recovery requests containing blocks that failed verification. The block height of the recovered block is required to be less than the maximum block height archivePivot in the currently archived blocks of the blockchain node. Each time the blocks are pushed, the block height between each batch needs to be reduced, but the block height within a single batch is increased (for example, in this recovery, assuming that the range of recovered blocks is 80,000 to 50,000, and 10,000 blocks are pushed per batch, it needs to be pushed 4 times, and the push method of the blocks when pushing blocks to the blockchain node is: 70001 to 80,000, 60001 to 70,000, 50001 to 60,000, 50,000.

[0380] See also Fig.25 , the pushed recovery block node will be temporarily stored after receiving it Fig.25 In the restoring file directory, such as Fig.25 The middle frame line part, including:

[0381] 6.1.1、 Fig.25 The 00000000000000000001.fdb file stores the block.

[0382] 6.1.2、 Fig.25 The corresponding index information is stored in 00000000000000000001.restoring.json.

[0383] 6.2. The blockchain node starts processing files in the bfdb / restoring directory some time after the last data recovery RPC call is completed, to avoid receiving block recovery requests when the blockchain node is merging data in the restoring directory into bfdb. The blockchain node will check the temporarily stored blocks in the bfdb / restoring directory at regular intervals. When Max(blockheight) in the bfdb / restoring directory == archivePivot (archive block height of the node), it will merge this part of the blocks in the bfdb / restoring directory into bfdb, first move bfdb / restoring / xxx.fdb to bfdb / xxx.fdb, and then write the index information to Fig. 20 In the store_block file directory.

[0384] For better understanding, please refer to Fig.26 , as Fig.26 shown, where:

[0385] 6.3.1. genesisBlock < targetRestorePivot < archivePivot, where targetRestorePivot represents the block height to which restoration is desired;

[0386] 6.3.2. During restoration, the configuration block is included, and the block heights of the restored blocks decrease continuously from high to low. Discontinuous restoration of blocks is not allowed.

[0387] 6.3.3. The block heights of the restored blocks decrease continuously. Discontinuous blocks are not allowed. The blocks in the bfdb / restoring file directory can be discontinuous, but the block heights must be continuous when transferred to bfdb. The transfer unit is all the blocks in the xxx.fdb file.

[0388] It can be understood that, as introduced in the foregoing embodiments, a blockchain is composed of multiple consecutive blocks; therefore, in order to restore each block in the blockchain to its original state, consecutive blocks are also used for restoration when restoring blocks, thereby ensuring the stability of the blockchain.

[0389] 6.3.4. When restoring blocks, the BFDB index information deleted when writing back to the archive is rewritten, and it remains the same after block restoration and before node block archiving.

[0390] 6.3.5. Fig.26 is roughly the same as Fig.21 , except that the archive arrow to the right becomes a restore arrow to the left, which indicates that the restore block height is from high to low. For other details, please refer to Fig.21 and so on.

[0391] Thus, the restoration of blocks is completed, and the restoration process is simple and easy to implement.

[0392] Fig. 27 is a block diagram of a blockchain-based data processing device shown in an embodiment of the present application. As Fig. 27 shown, the blockchain-based data processing device includes:

[0393] A receiving module 2701, configured to receive a block archiving request containing a target block height sent by a requesting party; wherein, the target block height is used to represent the maximum block height among multiple blocks to be archived;

[0394] A determination module 2702 is configured to determine a target block to be archived from the plurality of blocks to be archived based on the target block height and the block storage capacity of a single archive file;

[0395] The writing and generating module 2703 is configured to write the target block to be archived from the local blockchain into the archive file, and record the position of the target block to be archived in the archive file written thereto, and generate an index file;

[0396] The transfer module 2704 is configured to transfer the archive file and the index file to the archiver corresponding to the block archive request.

[0397] In one embodiment of the present application, the writing and generating module 2703 is specifically configured as follows:

[0398] The starting offset and the writing length of the target block to be archived in the archive file written thereto are obtained, and the starting offset and the writing length are used as the position of the target block to be archived in the archive file written thereto to generate the index file.

[0399] In one embodiment of the present application, the target block to be archived includes a block header and a block body; the writing and generating module 2703 is further specifically configured as follows:

[0400] Obtaining the starting offset and writing length of the block header and the block body in the archive file to which they are written respectively;

[0401] The index file is generated based on the starting offset and the write length corresponding to the block header, and the starting offset and the write length corresponding to the block body.

[0402] In one embodiment of the present application, there are multiple target blocks to be archived; the writing and generating module 2703 is specifically configured as follows:

[0403] If it is detected based on the configuration block information that there is a configuration block in the multiple target blocks to be archived, then other target blocks to be archived except the configuration block are selected from the multiple target blocks to be archived as the target blocks to be archived; wherein the configuration block is used to store data related to the local blockchain configuration;

[0404] Writing the selected target block to be archived from the local blockchain into the archive file;

[0405] The position of the selected target block to be archived in the archive file to be written is recorded to generate the index file.

[0406] In one embodiment of the present application, the determination module 2702 is specifically configured as follows:

[0407] If it is detected that the target block height is greater than the maximum block height of the currently archived blocks and less than the maximum allowed archiving height, and at the same time, there are a specified number of blocks to be archived among the multiple blocks to be archived that cannot satisfy the block storage capacity of the single archive file, then determine other blocks to be archived except the specified number of blocks to be archived from the multiple blocks to be archived;

[0408] The other blocks to be archived are used as the target blocks to be archived.

[0409] In one embodiment of the present application, the blockchain-based data processing device further includes a detection module configured to:

[0410] If any of the following situations is detected, an archive failure result is generated and returned to the requesting party:

[0411] Detecting that the target block height is less than the maximum block height among currently archived blocks;

[0412] It is detected that the total number of the plurality of blocks to be archived is less than the block storage capacity of the single archive file;

[0413] It is detected that the target block height is greater than the maximum allowed archive height.

[0414] In one embodiment of the present application, the detection module is specifically configured as follows:

[0415] Detecting the size relationship between the target block height and the maximum block height in currently archived blocks based on the target block height; or

[0416] Based on the target block height and the block storage capacity of the single archive file, detecting the number of archive files corresponding to the multiple to-be-archived blocks written into the archive file; or

[0417] The size relationship between the target block height and the maximum allowed archiving height is detected based on the target block height.

[0418] In one embodiment of the present application, the transfer module 2704 is specifically configured as follows:

[0419] Transferring the index file to the archiving party corresponding to the block archiving request; and

[0420] After detecting that the index file is successfully transferred to the archiving party, the archive file is transferred to the archiving party.

[0421] In one embodiment of the present application, the blockchain-based data processing device further includes a query module configured to:

[0422] If a block query request containing a specified block height is received from the requesting party, and it is detected that the block of the specified block height is not on the local blockchain, a block query request containing the specified block height is sent to the archiving party; wherein the block query request is used by the archiving party to obtain the block of the specified block height from the archive file corresponding to the specified block height based on the index file corresponding to the specified block height, and return the obtained block;

[0423] The received block is sent to the requesting party.

[0424] In one embodiment of the present application, the blockchain-based data processing device further includes a recovery module configured to:

[0425] Receiving multiple sets of blocks to be restored sent by the archiving party; wherein the multiple sets of blocks to be restored are generated after the archiving party receives a block restoration request containing a target block height interval sent by the requesting party;

[0426] Restore a specified number of blocks corresponding to each set of blocks to be restored on the local blockchain.

[0427] In one embodiment of the present application, the specified number of blocks contained in each set of blocks to be recovered are sorted from small to large according to block height; the recovery module is specifically configured as follows:

[0428] For each block set to be restored, if it is detected that the block heights of a specified number of blocks included in the block set to be restored are discontinuous, a configuration block satisfying the block height continuity is obtained from a configuration file;

[0429] Block recovery is completed on the local blockchain based on the acquired configuration block and a specified number of blocks included in the set of blocks to be recovered.

[0430] Fig.28 FIG. 1 is a block diagram of a data processing device based on blockchain, which is shown in an embodiment of the present application. Fig.28 As shown, the blockchain-based data processing device includes:

[0431] The receiving module 2801 is configured to receive an archive file and an index file sent by a blockchain node; wherein the archive file is generated by the blockchain node according to a target block to be archived in a local blockchain, and the index file is obtained by recording the position of the target block to be archived in the archive file;

[0432] The storage module 2802 is configured to store the received archive files and index files.

[0433] In one embodiment of the present application, the blockchain-based data processing device further includes a recovery module configured to:

[0434] If a block recovery request containing a target block height interval is received from the requesting party, the block heights of a specified number of blocks that each set of blocks to be recovered must include are determined based on the target block height interval;

[0435] Based on the index file corresponding to the target block height interval, obtaining the block corresponding to the block height contained in the target block height interval from the archive file corresponding to the target block height interval;

[0436] Generate each set of blocks to be restored based on the acquired blocks and the block heights of a specified number of blocks that each set of blocks to be restored needs to include;

[0437] Each of the to-be-recovered block sets is sent to the blockchain node corresponding to the block recovery request, so that the blockchain node corresponding to the block recovery request recovers a specified number of blocks corresponding to each of the to-be-recovered block sets on the local blockchain.

[0438] In one embodiment of the present application, the specified number of blocks contained in each set of blocks to be recovered are sorted from small to large according to block height; the recovery module is specifically configured as follows:

[0439] The sending each set of blocks to be recovered to the blockchain node corresponding to the block recovery request includes:

[0440] Obtaining the block height of the starting block contained in each set of blocks to be recovered, and obtaining the block heights of multiple starting blocks;

[0441] In descending order of the block heights of the multiple starting blocks, each set of blocks to be recovered is sent to the blockchain node corresponding to the block recovery request in turn.

[0442] In one embodiment of the present application, the recovery module is specifically configured as follows:

[0443] Each set of blocks to be recovered is written into the cache area in sequence according to the block heights of the multiple starting blocks from large to small; wherein the cache area is used for, after each set of blocks to be recovered is successfully written into the cache area, the blockchain node corresponding to the block recovery request reads each set of blocks to be recovered from the cache area according to the writing order of each set of blocks to be recovered, so as to recover the specified number of blocks corresponding to each set of blocks to be recovered read on the local blockchain.

[0444] In one embodiment of the present application, the blockchain-based data processing device further includes a deletion module configured to:

[0445] Deleting the archived files corresponding to the target block height interval; and

[0446] After detecting that the archive file corresponding to the target block height interval is successfully deleted, the index file corresponding to the target block height interval is deleted.

[0447] In one embodiment of the present application, the blockchain-based data processing device further includes a query module configured to:

[0448] If a block query request for a specified block height is received from the blockchain node, and it is detected that a block of the specified block height is stored in a compressed archive file corresponding to the specified block height, the compressed archive file is decompressed to obtain a decompressed archive file;

[0449] Based on the index file corresponding to the specified block height, obtaining the block of the specified block height from the decompressed archive file;

[0450] Return the acquired block to the blockchain node.

[0451] In one embodiment of the present application, the blockchain-based data processing device further includes a compression module configured to:

[0452] If it is detected that there is an archive file that has not been accessed within a specified period of time among the multiple archive files stored, the unaccessed archive file is compressed to obtain the compressed archive file.

[0453] In one embodiment of the present application, the storage module 2802 is specifically configured as follows:

[0454] Obtaining a maximum block height among a plurality of stored archive files; wherein the plurality of archive files are from a plurality of different blockchain nodes;

[0455] If the minimum block height in the received archive file is greater than the maximum block height, the received archive file and index file are stored.

[0456] In one embodiment of the present application, the storage module 2802 is specifically configured as follows:

[0457] Obtaining identification information of the blockchain corresponding to the received archive file;

[0458] If it is detected that the identification information matches any file directory in a plurality of file directories, the received archive files and index files are stored in the matching file directory; wherein each file directory is used to represent the identification information of the corresponding blockchain.

[0459] It should be noted that the apparatus provided in the aforementioned embodiment and the method provided in the aforementioned embodiment belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment.

[0460] An embodiment of the present application also provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the blockchain-based data processing method as described above.

[0461] Fig.29 It is a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application.

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

[0463] like Fig.29 As shown, computer system 2900 includes a central processing unit (CPU) 2901, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 2902 or the program loaded from the storage part 2908 to the random access memory (RAM) 2903, such as executing the method in the above embodiment. In RAM 2903, various programs and data required for system operation are also stored. CPU 2901, ROM 2902 and RAM 2903 are connected to each other through bus 2904. Input / output (I / O) interface 2905 is also connected to bus 2904.

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

[0465] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 2909, and / or installed from the removable medium 2911. When the computer program is executed by the central processing unit (CPU) 2901, various functions defined in the system of the present application are executed.

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

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

[0468] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0469] Another aspect of the present application further provides a computer-readable medium having a computer program stored thereon, which implements the blockchain-based data processing method as described above when the computer program is executed by a processor. The computer-readable medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0470] Another aspect of the present application further provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable medium. The processor of the computer device reads the computer instruction from the computer-readable medium, and the processor executes the computer instruction, so that the computer device executes the data processing method based on blockchain provided in each of the above embodiments.

[0471] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A data processing method based on blockchain, characterized in that: include: Receiving a block archiving request including a target block height sent by a requester; wherein the target block height is used to represent the maximum block height among multiple blocks to be archived; Determining a target block to be archived from the multiple blocks to be archived based on the target block height and the block storage capacity of a single archive file; Writing the target block to be archived from the local blockchain into the archive file, and recording the position of the target block to be archived in the written archive file to generate an index file; The archive file and the index file are transferred to the archive party corresponding to the block archive request.

2. The method according to claim 1, characterized in that The step of recording the position of the target to-be-archived block in the archive file to be written and generating an index file includes: The starting offset and the writing length of the target block to be archived in the archive file written thereto are obtained, and the starting offset and the writing length are used as the position of the target block to be archived in the archive file written thereto to generate the index file.

3. The method according to claim 2, characterized in that The target block to be archived includes a block header and a block body; the obtaining of the starting offset and the writing length of the target block to be archived in the archive file written thereto, taking the starting offset and the writing length as the position of the target block to be archived in the archive file written thereto, and generating the index file, comprises: Obtaining the starting offset and writing length of the block header and the block body in the archive file to which they are written respectively; The index file is generated based on the starting offset and the write length corresponding to the block header, and the starting offset and the write length corresponding to the block body.

4. The method according to claim 1, characterized in that There are multiple target blocks to be archived; and writing the target blocks to be archived from the local blockchain into the archive file includes: If it is detected based on the configuration block information that there is a configuration block in the multiple target blocks to be archived, then other target blocks to be archived except the configuration block are selected from the multiple target blocks to be archived as the target blocks to be archived; wherein the configuration block is used to store data related to the local blockchain configuration; Writing the selected target block to be archived from the local blockchain into the archive file; The step of recording the position of the target to-be-archived block in the archive file to be written and generating an index file includes: The position of the selected target block to be archived in the archive file to be written is recorded to generate the index file.

5. The method according to claim 1, characterized in that The step of determining a target block to be archived from the plurality of blocks to be archived based on the target block height and the block storage capacity of a single archive file includes: If it is detected that the target block height is greater than the maximum block height of the currently archived blocks and less than the maximum allowed archiving height, and at the same time, there are a specified number of blocks to be archived among the multiple blocks to be archived that cannot satisfy the block storage capacity of the single archive file, then determine other blocks to be archived except the specified number of blocks to be archived from the multiple blocks to be archived; The other blocks to be archived are used as the target blocks to be archived.

6. The method according to claim 1, characterized in that The method further comprises: If any of the following situations is detected, an archive failure result is generated and returned to the requesting party: Detecting that the target block height is less than the maximum block height among currently archived blocks; It is detected that the total number of the plurality of blocks to be archived is less than the block storage capacity of the single archive file; It is detected that the target block height is greater than the maximum allowed archive height.

7. The method according to claim 6, characterized in that The method further comprises: Detecting the size relationship between the target block height and the maximum block height in currently archived blocks based on the target block height; or Based on the target block height and the block storage capacity of the single archive file, detecting the number of archive files corresponding to the multiple to-be-archived blocks written into the archive file; or The size relationship between the target block height and the maximum allowed archiving height is detected based on the target block height.

8. The method according to claim 1, characterized in that The transferring the archive file and the index file to the archive party corresponding to the block archive request includes: Transferring the index file to the archiving party corresponding to the block archiving request; and After detecting that the index file is successfully transferred to the archiving party, the archive file is transferred to the archiving party.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: If a block query request containing a specified block height is received from the requesting party, and it is detected that the block of the specified block height is not on the local blockchain, a block query request containing the specified block height is sent to the archiving party; wherein the block query request is used by the archiving party to obtain the block of the specified block height from the archive file corresponding to the specified block height based on the index file corresponding to the specified block height, and return the obtained block; The received block is sent to the requesting party.

10. The method according to any one of claims 1 to 8, characterized in that The method further comprises: Receiving multiple sets of blocks to be restored sent by the archiving party; wherein the multiple sets of blocks to be restored are generated after the archiving party receives a block restoration request containing a target block height interval sent by the requesting party; Restore a specified number of blocks corresponding to each set of blocks to be restored on the local blockchain.

11. The method according to claim 10, characterized in that The specified number of blocks contained in each set of blocks to be restored are sorted from small to large according to the block height; The restoring a specified number of blocks corresponding to each set of blocks to be restored on the local blockchain includes: For each block set to be restored, if it is detected that the block heights of a specified number of blocks included in the block set to be restored are discontinuous, a configuration block satisfying the block height continuity is obtained from a configuration file; Block recovery is completed on the local blockchain based on the acquired configuration block and a specified number of blocks included in the set of blocks to be recovered.

12. A data processing method based on blockchain, characterized in that: include: Receive an archive file and an index file sent by a blockchain node; wherein the archive file is generated by the blockchain node according to a target block to be archived in a local blockchain, and the index file is obtained by recording the position of the target block to be archived in the archive file; The received archive files and index files are stored.

13. The method according to claim 12, characterized in that The method further comprises: If a block recovery request containing a target block height interval is received from the requesting party, the block heights of a specified number of blocks that each set of blocks to be recovered must include are determined based on the target block height interval; Based on the index file corresponding to the target block height interval, obtaining the block corresponding to the block height contained in the target block height interval from the archive file corresponding to the target block height interval; Generate each set of blocks to be restored based on the acquired blocks and the block heights of a specified number of blocks that each set of blocks to be restored needs to include; Each of the to-be-recovered block sets is sent to the blockchain node corresponding to the block recovery request, so that the blockchain node corresponding to the block recovery request recovers a specified number of blocks corresponding to each of the to-be-recovered block sets on the local blockchain.

14. The method according to claim 13, characterized in that The specified number of blocks contained in each set of blocks to be restored are sorted from small to large according to the block height; The sending each set of blocks to be recovered to the blockchain node corresponding to the block recovery request includes: Obtaining the block height of the starting block contained in each set of blocks to be recovered, and obtaining the block heights of multiple starting blocks; In descending order of the block heights of the multiple starting blocks, each set of blocks to be recovered is sent to the blockchain node corresponding to the block recovery request in turn.

15. The method according to claim 14, characterized in that The sending each set of blocks to be recovered to the blockchain node corresponding to the block recovery request in sequence according to the block heights of the multiple starting blocks from small to large includes: Each set of blocks to be recovered is written into the cache area in sequence according to the block heights of the multiple starting blocks from large to small; wherein the cache area is used for, after each set of blocks to be recovered is successfully written into the cache area, the blockchain node corresponding to the block recovery request reads each set of blocks to be recovered from the cache area according to the writing order of each set of blocks to be recovered, so as to recover the specified number of blocks corresponding to each set of blocks to be recovered read on the local blockchain.

16. The method according to claim 13, characterized in that After sending each set of blocks to be recovered to the blockchain node corresponding to the block recovery request, the method further includes: Deleting the archived files corresponding to the target block height interval; and After detecting that the archive file corresponding to the target block height interval is successfully deleted, the index file corresponding to the target block height interval is deleted.

17. A data processing device based on blockchain, characterized in that: include: A receiving module, configured to receive a block archiving request containing a target block height sent by a requester; wherein the target block height is used to represent the maximum block height among a plurality of blocks to be archived; A determination module, configured to determine a target block to be archived from the plurality of blocks to be archived based on the target block height and the block storage capacity of a single archive file; A writing and generating module, configured to write the target block to be archived from the local blockchain into the archive file, and record the position of the target block to be archived in the archive file written thereto, and generate an index file; The transfer module is configured to transfer the archive file and the index file to the archive party corresponding to the block archive request.

18. A data processing device based on blockchain, characterized in that: include: A receiving module, configured to receive an archive file and an index file sent by a blockchain node; wherein the archive file is generated by the blockchain node according to a target block to be archived in a local blockchain, and the index file is obtained by recording the position of the target block to be archived in the archive file; The storage module is configured to store the received archive files and index files.

19. An electronic device, characterized in that: include: one or more processors; A memory for storing one or more programs, which, when executed by the electronic device, enables the electronic device to implement the blockchain-based data processing method as described in any one of claims 1 to 16.

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

Images