Blockchain data recovery method, device and electronic equipment

Abstract

A blockchain data recovery method is applied to a node device; the node device is equipped with multiple storage systems for storing blockchain data; among them, the blockchain data includes block transaction data and at least one other type of blockchain data; the target storage system for storing the block transaction data in the multiple storage systems supports the Write-Ahead Log (WAL) mode; the method includes: in response to a first event for recovering the other type of blockchain data, reading the WAL log file corresponding to the block transaction data stored in the target storage system; recovering the block transaction data based on the WAL log file, and executing the recovered block transaction data to generate the other type of blockchain data; writing the generated other type of blockchain data into each storage system for storing the other type of blockchain data in the multiple storage systems respectively.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a blockchain data recovery method, an apparatus, and an electronic device. Background Art

[0002] Blockchain technology, also known as distributed ledger technology, is a new technology in which several computing devices jointly participate in "recording accounts" and jointly maintain a complete distributed database. Due to the characteristics of blockchain technology, such as decentralization, openness and transparency, each computing device can participate in database records, and data synchronization can be quickly carried out between computing devices, blockchain technology has been widely applied in many fields. Summary of the Invention

[0003] This specification proposes a blockchain data recovery method, which is applied to a node device; the node device is equipped with multiple storage systems for storing blockchain data; wherein, the blockchain data includes block transaction data and at least one other type of blockchain data; the target storage system for storing the block transaction data in the multiple storage systems supports the Write-Ahead Log (WAL) mode; the method includes:

[0004] In response to a first event for recovering the other type of blockchain data, read the WAL log file corresponding to the block transaction data stored in the target storage system;

[0005] Recover the block transaction data based on the WAL log file, and execute the recovered block transaction data to generate the other type of blockchain data;

[0006] Write the generated other type of blockchain data into each of the storage systems for storing the other type of blockchain data in the multiple storage systems.

[0007] Optionally, the method further includes:

[0008] Determine whether the latest block number C of the other type of blockchain data stored in each storage system is less than the latest block number N of the block transaction data stored in the target storage system; if so, generate the first event.

[0009] Optionally, the latest block number C is the minimum value of the latest block numbers of the other type of blockchain data stored in each storage system;

[0010] Before determining whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system, the following steps are also included:

[0011] Calculate the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in each storage system to obtain the latest block number C.

[0012] Optionally, the data identifiers of the blockchain data stored in the multiple storage systems include the block numbers corresponding to the blockchain data.

[0013] Optionally, the data identifiers of the blockchain data stored in the multiple storage systems adopt a unified data format.

[0014] Optionally, the data identifier adopts the data format of the LSN log sequence number of the WAL log file.

[0015] Optionally, reading the WAL log file corresponding to the block transaction data stored in the target storage system includes:

[0016] Read the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the block number range (C, N] composed of the latest block number C and the latest block number N respectively;

[0017] Restoring the block transaction data based on the WAL log file and executing the restored blockchain transaction to generate the other types of blockchain data includes:

[0018] Based on the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the read block number range (C, N], restore the block transaction data in the blocks represented by each block number, and execute the restored block transaction data to generate the other types of blockchain data corresponding to the block transaction data in the blocks represented by each block number.

[0019] Optionally, determining whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system includes:

[0020] Periodically determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system; or,

[0021] In response to an instruction triggered by a user for recovering other types of blockchain data, determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system.

[0022] Optionally, the other types of blockchain data include one or more combinations shown below:

[0023] The block header data of the block corresponding to the block transaction data;

[0024] The transaction receipt corresponding to the block transaction data;

[0025] After the block transaction data is executed, the account status data corresponding to the blockchain accounts in the blockchain.

[0026] Optionally, the method further includes:

[0027] In response to a second event for recovering the block transaction data, recover the block transaction data based on the WAL log file, and write the recovered block transaction data into the target storage system.

[0028] Optionally, the method further includes:

[0029] Determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; if so, generate the second event.

[0030] Optionally, determining whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold includes:

[0031] Periodically determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; or,

[0032] In response to an instruction triggered by a user for recovering the block transaction data, determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold.

[0033] This specification also proposes a blockchain data recovery device, which is applied to a node device; the node device is equipped with multiple storage systems for storing blockchain data; wherein, the blockchain data includes block transaction data and at least one other type of blockchain data; the target storage system for storing the block transaction data among the multiple storage systems supports the Write-Ahead Log (WAL) mode; the device includes:

[0034] A reading module, in response to a first event for recovering other types of blockchain data, reads the WAL log file corresponding to the block transaction data stored in the target storage system;

[0035] A recovery module recovers the block transaction data based on the WAL log file and executes the recovered block transaction data to generate the other types of blockchain data;

[0036] A writing module writes the generated other types of blockchain data into respective storage systems among the multiple storage systems for storing the other types of blockchain data.

[0037] Optionally, the device further includes:

[0038] A first determination module determines whether the latest block number C among the block numbers corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N among the block numbers corresponding to the block transaction data stored in the target storage system; if so, generates the first event.

[0039] Optionally, the latest block number C is the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in each storage system;

[0040] The determination module further:

[0041] Before determining whether the latest block number C among the block numbers corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N among the block numbers corresponding to the block transaction data stored in the target storage system, calculates the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in each storage system to obtain the latest block number C.

[0042] Optionally, the data identifier of the blockchain data stored in the multiple storage systems includes the block number corresponding to the blockchain data.

[0043] Optionally, the data identifiers of the blockchain data stored in the multiple storage systems adopt a unified data format.

[0044] Optionally, the data identifier adopts the data format of the LSN log sequence number of the WAL log file.

[0045] Optionally, the reading module:

[0046] Reads the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the block number range (C, N] formed by the latest block number C and the latest block number N respectively;

[0047] The recovery module:

[0048] Based on the WAL log files corresponding to the block transaction data in the blocks represented by the block numbers in the read block number range (C, N], recover the block transaction data in the blocks represented by the block numbers, and execute the recovered block transaction data to generate the other types of blockchain data corresponding to the block transaction data in the blocks represented by the block numbers.

[0049] Optionally, the first determination module:

[0050] Periodically determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system; or,

[0051] In response to an instruction triggered by the user to recover the other types of blockchain data, determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system.

[0052] Optionally, the other types of blockchain data include one or more of the following combinations:

[0053] The block header data of the block corresponding to the block transaction data;

[0054] The transaction receipt corresponding to the block transaction data;

[0055] After the block transaction data is executed, the account status data corresponding to the blockchain accounts in the blockchain.

[0056] Optionally, the writing module further:

[0057] In response to a second event for recovering the block transaction data, recover the block transaction data based on the WAL log file, and write the recovered block transaction data into the target storage system.

[0058] Optionally, the device further includes:

[0059] A second determination module, which determines whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; if so, generate the second event.

[0060] Optionally, the second determination module:

[0061] Periodically determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; or,

[0062] In response to an instruction triggered by a user to recover the block transaction data, determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold.

[0063] In the above technical solutions, on the one hand, since among the multiple storage systems carried by the blockchain, only the target storage system for storing block transaction data may support the write-ahead log (WAL) mode, while the storage systems for storing other types of blockchain data corresponding to the block transaction data do not need to repeatedly enable the WAL mode; therefore, for a node device carrying multiple storage systems, only one WAL log file corresponding to the block transaction data needs to be stored and maintained, and there is no need to store and maintain multiple WAL log files, which can significantly reduce the storage overhead of the node device when storing multiple types of blockchain data;

[0064] On the other hand, since other types of blockchain data corresponding to the block transaction data stored in the node device are uniformly recovered based on the WAL log file corresponding to the block transaction data; for a node device carrying multiple storage systems, there is no need to perform data recovery separately based on the WAL log files corresponding to each storage system; therefore, the performance overhead of the node device when recovering multiple types of blockchain data can be significantly reduced. Description of the Drawings

[0065] Figure 1 is a flowchart of a method for recovering blockchain data provided by an exemplary embodiment;

[0066] Figure 2 is a schematic structural diagram of an electronic device provided by an exemplary embodiment;

[0067] Figure 3 is a block diagram of a device for recovering blockchain data provided by an exemplary embodiment. Detailed Description of the Embodiment

[0068] Here, the exemplary embodiments will be described in detail, and the examples are shown in the 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 consistent with one or more embodiments of this specification. On the contrary, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0069] It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily executed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step for description in other embodiments.

[0070] Blockchains are generally divided into three types: public blockchains, private blockchains, and consortium blockchains. In addition, there can be combinations of the above multiple types, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain, etc.

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

[0072] On the contrary, for a private blockchain, the write permission of the network is controlled by a certain organization or institution, and the data read permission is subject to organizational regulations. Simply put, a private blockchain can be a weakly decentralized system, which has strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a specific institution.

[0073] A consortium blockchain is a blockchain that lies between a public blockchain and a private blockchain and can achieve "partial decentralization". Each node in a consortium blockchain usually has a corresponding entity organization or institution; the nodes join the network through authorization and form an interest-related alliance to jointly maintain the operation of the blockchain.

[0074] Based on the basic characteristics of the blockchain, a blockchain is usually composed of several blocks. Timestamps corresponding to the creation time of each block are respectively recorded in these blocks, and all the blocks strictly form an ordered data chain in time according to the timestamps recorded in the blocks.

[0075] For the real data generated in the physical world, it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain. The node devices in the blockchain perform consensus processing on the received transactions, and after reaching a consensus, the node device acting as the accounting node in the blockchain packages this transaction into a block and persists the evidence in the blockchain.

[0076] Among them, the consensus algorithms supported in the blockchain may include:

[0077] The first type of consensus algorithm, that is, a consensus algorithm in which node devices need to compete for the right to record transactions in each round of the accounting cycle; for example, consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS);

[0078] The second type of consensus algorithm, that is, a consensus algorithm in which accounting nodes are elected in advance for each round of the accounting cycle (without competing for the right to record transactions); for example, consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT).

[0079] In a blockchain network using the first type of consensus algorithm, any node device competing for the right to record transactions can execute the transaction after receiving it. Among the node devices competing for the right to record transactions, one node device may win in the process of competing for the right to record transactions in this round and become the accounting node. The accounting node can package the received transaction together with other transactions to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus.

[0080] In a blockchain network using the second type of consensus algorithm, the node device with the right to record transactions has been agreed upon before this round of accounting. Therefore, after receiving a transaction, if the node device itself is not the accounting node in this round, it can send the transaction to the accounting node. For the accounting node in this round, it can execute the transaction during or before the process of packaging the transaction together with other transactions to generate the latest block. After generating the latest block, the accounting node can send the latest block or the block header of the latest block to other node devices for consensus.

[0081] As described above, no matter which consensus algorithm the blockchain adopts as shown above, the accounting node in this round can package the received transaction to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus verification. If other node devices receive the latest block or the block header of the latest block and there is no problem after verification, they can append the latest block to the end of the original blockchain, thus completing the accounting process of the blockchain. During the process of other nodes verifying the new block or block header sent by the accounting node, they can also execute the transactions included in the block.

[0082] In the field of blockchain, an important concept is the account; taking Ethereum as an example, Ethereum usually divides accounts into two categories: external accounts and contract accounts; an external account is an account directly controlled by a user, also known as a user account; while a contract account is an account containing contract code created by a user through an external account (i.e., a smart contract).

[0083] Of course, for some blockchain models derived from the Ethereum architecture (such as Ant Blockchain), the account types supported by the blockchain can be further extended, which will not be specifically limited in this specification.

[0084] For the accounts in the blockchain, an account state is usually maintained through a structure. When the transactions in a block are executed, the states of the accounts related to the transactions in the blockchain usually also change.

[0085] Taking Ethereum as an example, the structure of an account usually includes fields such as Balance, Nonce, Code, and Storage. Among them:

[0086] The Balance field is used to maintain the current account balance of the account;

[0087] The Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can and can only be processed once, effectively avoiding replay attacks;

[0088] The Code field is used to maintain the contract code of the account; in practical applications, only the hash value of the contract code is usually maintained in the Code field; therefore, the Code field is usually also called the Codehash field.

[0089] The Storage field is used to maintain the storage content of the account (the default field value is empty); for a contract account, an independent storage space is usually allocated to store the storage content of the contract account; this independent storage space is usually called the account storage of the contract account. The storage content of the contract account is usually constructed into a Merkle Patricia Trie (MPT) tree data structure and stored in the above independent storage space; among them, the MPT tree constructed based on the storage content of the contract account is usually also called the Storage tree. And the Storage field usually only maintains the hash value of the root node of the Storage tree; therefore, the Storage field is usually also called the Storage Root hash field. Among them, for an external account, the field values of the Code field and the Storage field shown above are both null values.

[0090] For most blockchain models, the data structure of Merkle tree is usually used; or, based on the data structure of Merkle tree, to store and maintain blockchain data.

[0091] Among them, for node devices, the blockchain data that needs to be stored and maintained usually includes block data and account status data corresponding to blockchain accounts in the blockchain; and the block data further includes block header data, block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, and so on. It should be noted that in actual applications, in addition to storing and maintaining blockchain data, node devices also need to store and maintain index data corresponding to blockchain data.

[0092] For example, taking Ethereum as an example, Ethereum uses the MPT tree as a data organization form to organize and manage important data such as account status and transaction information. Among them, the MPT tree is a variant of the Merkle tree that combines the tree structure of the Trie dictionary tree.

[0093] Ethereum designs three MPT trees for the blockchain data that needs to be stored and maintained in the blockchain, namely the MPT state tree, the MPT transaction tree, and the MPT receipt tree. Among them, in addition to the above three MPT trees, there is actually also a Storage tree constructed based on the stored content of contract accounts.

[0094] The MPT state tree is an MPT tree organized by the account status (state) data of all accounts in the blockchain; the MPT transaction tree is an MPT tree organized by the transaction (transaction) data in the blockchain; the MPT receipt tree is an MPT tree organized by the transaction (receipt) receipts corresponding to each transaction generated after the transactions in the block are executed. The hash values of the root nodes of the MPT state tree, the MPT transaction tree, and the MPT receipt tree shown above will ultimately be added to the block header of the corresponding block.

[0095] Among them, both the MPT transaction tree and the MPT receipt tree correspond to the block, that is, each block has its own MPT transaction tree and MPT receipt tree. And the MPT state tree is a global MPT tree, which does not correspond to a specific block, but covers the account status data of all accounts in the blockchain.

[0096] The following takes the MPT state tree as an example for illustration.

[0097] Every time a new block is generated in the blockchain, after the transactions in the new block are executed, the account statuses of the relevant accounts (which can be external accounts or contract accounts) in the blockchain usually change accordingly;

[0098] For example, after a "transfer transaction" in a block is executed, the balances of the transferor account and the transferee account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) usually change accordingly.

[0099] After the transactions in the latest block generated by the blockchain are executed by the node device, since the account status in the current blockchain has changed, the node device needs to construct an MPT state tree based on the current account status data of all accounts in the blockchain to maintain the latest status of all accounts in the blockchain.

[0100] That is, whenever a latest block is generated in the blockchain and the transactions in the latest block are executed, resulting in a change in the account status in the blockchain, the node device needs to reconstruct an MPT state tree based on the latest account status data of all accounts in the blockchain.

[0101] In other words, each block in the blockchain has a corresponding MPT state tree; this MPT state tree maintains the latest account status of all accounts in the blockchain after the transactions in the block are executed.

[0102] In practical applications, since the blockchain usually interfaces with various off-chain business systems for multi-party data and workflow collaboration (irrelevant to the business); for example, a business system A that interfaces with the blockchain can publish relevant business data to the blockchain to drive another business system B that interfaces with the blockchain to perform further business processing based on this business data.

[0103] The actual roles of different types of blockchain data may vary during the multi-party data and workflow collaboration process; when storing and maintaining blockchain data, the node device usually deploys multiple storage systems and stores different types of blockchain data in different storage systems.

[0104] For example, in one example, the node device can deploy 3 different storage systems and store block data, state data (i.e., the above-mentioned account status data), and index data corresponding to the above two types of data (such as the hash values of the above two types of data) in different storage systems. (Five WALs are exemplified respectively)

[0105] In another example, the node device can store the block header data, block transaction data, transaction receipts corresponding to the block transaction data, state data (i.e., the above-mentioned account state data), and index data corresponding to the above four types of data (such as the hash values of the above four types of data) in different storage systems respectively; in this case, the node device can be equipped with five different storage systems, and store the block header data, block transaction data, transaction receipts corresponding to the block transaction data, state data, and index data corresponding to the above four types of data in these five different storage systems respectively.

[0106] When the node device stores different types of blockchain data in different storage systems it is equipped with, in order to prevent data loss caused by data not being written, each storage system can enable the WAL (write ahead logging) mode.

[0107] Among them, the WAL mode is an efficient logging algorithm. In a storage system with the WAL mode enabled, all data modifications to the storage system will be written to the WAL log file first before being committed to the storage system; then, through periodically triggered or user-manually triggered checkpoint events, the data modifications stored in the WAL log file will be written to the storage system.

[0108] By enabling the WAL mode for the storage systems equipped on the node device, although it can prevent data loss caused by data not being written, in the blockchain ledger stored by the node device, there are often multiple different types of blockchain data that need to be stored in different storage systems; therefore, storing multiple copies of WAL log files will increase the storage overhead of the node device; moreover, when the node device restores the data modifications stored in multiple WAL log files to the storage system, it needs to execute the relevant recovery process multiple times, which will also increase the performance overhead of the node device.

[0109] In view of this, this specification proposes a technical solution for recovering multiple types of blockchain data by using a single WAL log file corresponding to the blockchain transaction data stored in the node device.

[0110] In implementation, the node device of the blockchain can be equipped with multiple storage systems for storing blockchain data; among them, the above-mentioned blockchain data can include block transaction data and at least one other type of blockchain data; the target storage system for storing the block transaction data among the above multiple storage systems can support the write ahead log WAL mode;

[0111] When the node device responds to a first event for recovering other types of blockchain data as described above, it can read the WAL log file corresponding to the block transaction data stored in the target storage system; then, based on the read WAL log file, recover the block transaction data. After the block transaction data is recovered, further execute the recovered block transaction data to generate the other types of blockchain data; then, write the generated other types of blockchain data into each of the multiple storage systems for storing the other types of blockchain data in the storage system.

[0112] In the above technical solution, on the one hand, among the multiple storage systems carried by the blockchain, only the target storage system for storing block transaction data can support the write-ahead log (WAL) mode, while the storage systems for storing other types of blockchain data corresponding to the block transaction data do not need to repeatedly enable the WAL mode; therefore, for a node device carrying multiple storage systems, it can only store and maintain one WAL log file corresponding to the block transaction data, and no longer needs to store and maintain multiple WAL log files, which can significantly reduce the storage overhead of the node device when storing multiple types of blockchain data;

[0113] On the other hand, since the other types of blockchain data corresponding to the block transaction data stored in the node device are uniformly recovered based on the WAL log file corresponding to the block transaction data; for a node device carrying multiple storage systems, it no longer needs to perform data recovery based on the WAL log files corresponding to each storage system respectively; therefore, it can significantly reduce the performance overhead of the node device when recovering multiple types of blockchain data.

[0114] Please refer to Figure 1 , Figure 1 which is a flowchart of a method for recovering blockchain data provided by an exemplary embodiment. The method is applied to a blockchain node device; wherein, the blockchain data includes block transaction data and at least one other type of blockchain data corresponding to the block transaction data; the target storage system for storing the block transaction data in the multiple storage systems supports the write-ahead log (WAL) mode; the method includes the following steps:

[0115] Step 102, in response to a first event for recovering the other types of blockchain data, read the WAL log file corresponding to the block transaction data stored in the target storage system;

[0116] Step 104, based on the WAL log file, recover the block transaction data and execute the recovered block transaction data to generate the other types of blockchain data;

[0117] Step 106: Write the generated blockchain data of other types into the respective storage systems for storing the blockchain data of other types in the multiple storage systems.

[0118] In this specification, the blockchain ledger stored in the node device usually includes various different types of blockchain data. The above-mentioned various different types of blockchain data usually can include block data, account status data corresponding to blockchain accounts in the blockchain, and so on; among them, the block data usually includes block header data and block body data; the above-mentioned block body data further includes block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, and so on.

[0119] In practical applications, to facilitate querying and retrieving the stored blockchain data, in addition to the above-listed blockchain data, the node device usually also needs to store and maintain index data corresponding to the above various blockchain data. Among them, the specific form of the above index data is not particularly limited in this specification;

[0120] For example, for a blockchain system that supports content addressing of the blockchain data stored in the blockchain ledger, specifically, the content summary (such as hash value) of the above blockchain data can be used as the index data of the blockchain data, so that users can use the content summary of the above blockchain data as a query index to query and access the relevant blockchain data in the blockchain ledger;

[0121] For a blockchain system that does not support content addressing of the blockchain data stored in the blockchain account, specifically, the data identifier (such as data number) set by the blockchain system for the stored blockchain data can be used as the index data of the blockchain data, so that users can use the data identifier of the above blockchain data as a query index to query and access the relevant blockchain data in the blockchain ledger.

[0122] When the node device stores and maintains the above-listed various blockchain data, it can carry multiple storage systems and store different types of blockchain data in different storage systems. Among them, the above storage system can specifically include any form of storage system for persistently storing the blockchain data in the blockchain ledger; for example, in practical applications, the above storage system can specifically be a database, a file system, etc. carried by the node device, which is not particularly limited in this specification.

[0123] It should be noted that data such as block header data, transaction receipts corresponding to block transaction data, and state data (i.e., the above-mentioned account status data) can usually be restored by re-executing the block transactions in the block (i.e., transaction replay). Therefore, the above-mentioned block transaction data can be used as the "root data" of other types of blockchain data. When the node device stores various types of blockchain data shown above, the above-mentioned block transaction data and other types of blockchain data can be stored in different storage systems respectively.

[0124] For example, in one example, the node device can be equipped with 5 different storage systems, and store the block transaction data, the block header data of the block corresponding to the block transaction data, the transaction receipts corresponding to the block transaction data, the state data, and the index data corresponding to the above 4 types of data in these 5 different storage systems respectively.

[0125] In this specification, in order to prevent the loss of the "root data" caused by the failure to write the above-mentioned "root data", the target storage system in each storage system for storing the "root data" (i.e., block transaction data) can enable the WAL mode. After enabling the WAL mode, all data modifications to the target storage system (such as writing new block transaction data) will be written into the WAL log buffer corresponding to the target storage system in the form of a WAL log file before being submitted to the target storage system. Among them, the log buffer can also be a persistent storage specifically. Then, when the blockchain system triggers a checkpoint event corresponding to the above-mentioned target storage system, the node device can respond to this checkpoint event and restore the data modifications to the above-mentioned "root data" stored in the WAL log file to the target storage system.

[0126] Among them, the above-mentioned checkpoint event refers to an event for data recovery of the blockchain data stored in the storage system based on the WAL log file.

[0127] For the other storage systems in each storage system for storing other types of blockchain data other than the "root data", the WAL mode may not be enabled, but cross-storage system data recovery can be performed based on the WAL log file corresponding to the above-mentioned target storage system. That is, the storage systems that do not enable the WAL mode can also perform data recovery through the WAL log files corresponding to other storage systems that enable the WAL mode.

[0128] In this case, the blockchain system can also handle the checkpoint events of the above-mentioned other storage systems that do not have the WAL mode enabled; when the blockchain system triggers the checkpoint events corresponding to the above-mentioned other storage systems, the node device can respond to the checkpoint events, read the WAL log files corresponding to the above-mentioned target storage system for data recovery calculation, and then, based on the calculation results of the data recovery calculation, perform cross-storage system data recovery on other types of blockchain data stored in the above-mentioned other storage systems.

[0129] In this specification, the process of the node device recovering the block transaction data stored in the above-mentioned target storage system and the process of recovering other types of blockchain data stored in the above-mentioned other storage systems can be two independent processes, and the execution order of the two is not particularly limited in this specification.

[0130] That is, in practical applications, the node device can first execute the process of recovering the block transaction data stored in the above-mentioned target storage system, and then execute the process of recovering other types of blockchain data stored in the above-mentioned other storage systems; or it can first execute the process of recovering other types of blockchain data stored in the above-mentioned other storage systems, and then execute the process of recovering the block transaction data stored in the above-mentioned target storage system.

[0131] It should be noted that since the process of the node device recovering the block transaction data stored in the above-mentioned target storage system is also completed based on the WAL log file corresponding to the above-mentioned block transaction data; therefore, if the node device first executes the process of recovering the block transaction data stored in the above-mentioned target storage system, it is necessary not to delete the WAL log file corresponding to the above-mentioned block transaction data stored in the log buffer temporarily after the above-mentioned block transaction data recovery is completed; when the node device starts to execute the process of recovering other types of blockchain data stored in the above-mentioned other storage systems, it can continue to perform data recovery on other types of blockchain data stored in the above-mentioned other storage systems based on the above-mentioned WAL log file, and then delete the WAL log file from the log buffer after the recovery is completed.

[0132] It should also be noted that since the process of the node device recovering the block transaction data stored in the above-mentioned target storage system and the process of recovering other types of blockchain data stored in the above-mentioned other storage systems are two independent processes; therefore, the triggering conditions of the checkpoint events corresponding to the above-mentioned target storage system triggered by the blockchain system and the checkpoint events corresponding to the above-mentioned other storage systems triggered by the blockchain system can also be different from each other.

[0133] Among them, for the convenience of description, the checkpoint events corresponding to the above-mentioned other storage systems triggered by the blockchain system will be referred to as "first events"; the checkpoint events corresponding to the above-mentioned target storage system triggered by the blockchain system will be referred to as "second events".

[0134] In an illustrated embodiment, based on the WAL-based data recovery mechanism, the triggering conditions of the above-mentioned first event generally may include that the number of file of the WAL log file corresponding to the block transaction data stored in the above-mentioned target storage system reaches a threshold; or, the storage capacity of the WAL log file corresponding to the block transaction data stored in the above-mentioned target storage system reaches a threshold.

[0135] That is, when the number of files of the WAL log file corresponding to the block transaction data stored in the above-mentioned target storage system reaches a threshold; or, the storage capacity of the WAL log file corresponding to the block transaction data stored in the above-mentioned target storage system reaches a threshold, the blockchain system can be triggered to generate the above-mentioned first event.

[0136] In another illustrated embodiment, since the data recovery of other types of blockchain data stored in the above-mentioned other storage systems is cross-storage system data recovery based on the WAL log file corresponding to the above-mentioned target storage system, which is different from the local data recovery of the block transaction data stored in the above-mentioned target storage system based on the WAL log file; therefore, the triggering conditions of the above-mentioned second event may be different from the triggering conditions of the checkpoint event of the WAL-based data recovery mechanism. The triggering conditions of the above-mentioned second event may specifically include that the latest block number C in the block numbers corresponding to the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems is less than the latest block number N in the block numbers corresponding to the block transaction data stored in the above-mentioned target storage system.

[0137] That is, when the latest block number C in the block numbers corresponding to the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems is less than the latest block number N in the block numbers corresponding to the block transaction data stored in the above-mentioned target storage system, the blockchain system can be triggered to generate the above-mentioned second event.

[0138] Hereinafter, through specific embodiments, the process of the node device recovering other types of blockchain data stored in the above-mentioned other storage systems based on the blockchain system triggering the above-mentioned first event; and, the process of the node device recovering the block transaction data stored in the above-mentioned target storage system based on the above-mentioned second event triggered by the system will be described respectively.

[0139] In an illustrated embodiment, when the node device restores other types of blockchain data stored in the other storage systems, it may periodically determine whether the latest block number C corresponding to the other types of blockchain data stored in the other storage systems is less than the latest block number N corresponding to the block transaction data stored in the target storage system; if so, it may trigger the generation of the first event.

[0140] For example, in practical applications, the node device may preset an inspection period T for a checkpoint event, and then based on this period T, periodically check whether the other storage systems meet the trigger conditions for the checkpoint event.

[0141] In another illustrated embodiment, when the node device restores other types of blockchain data stored in the other storage systems, it may also respond to an instruction manually triggered by the user to restore the other types of blockchain data, and determine whether the latest block number C corresponding to the other types of blockchain data stored in the other storage systems is less than the latest block number N corresponding to the block transaction data stored in the target storage system; if so, it may trigger the generation of the first event.

[0142] For example, in practical applications, in addition to periodically checking whether the other storage systems meet the trigger conditions for the checkpoint event, the user may also trigger the node device to check whether the other storage systems meet the trigger conditions for the checkpoint event by manually inputting a restoration instruction; for example, in some restoration scenarios, the user may need to perform a data rollback operation on the other types of blockchain data stored in the other storage systems to restore the other types of blockchain data stored in the other storage systems to the data version corresponding to a certain historical block; in such a scenario, the user may trigger the node device to check whether the other storage systems meet the trigger conditions for the checkpoint event by manually inputting a restoration instruction.

[0143] Among them, the latest block number C corresponding to the other types of blockchain data stored in the other storage systems may specifically be the minimum value among the latest block numbers corresponding to the other types of blockchain data stored in the other storage systems; in this case, the node device may first calculate the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in the other storage systems to obtain the latest block number C, and then further determine whether the latest block number C is less than the latest block number N corresponding to the block transaction data stored in the target storage system.

[0144] In one of the illustrated embodiments, in order to facilitate determining the block numbers corresponding to the blockchain data stored in each storage system carried by the node device, the data identifier of the blockchain data stored in each storage system may specifically include the block number corresponding to the above-mentioned blockchain data; that is, specifically, the block number corresponding to the blockchain data may be directly added to the data identifier of the blockchain data; or, information indicating the block number corresponding to the blockchain data may be added to the data identifier of the blockchain data.

[0145] In one implementation, the data identifiers of the blockchain data stored in each storage system carried by the node device may specifically adopt a unified data format, and in the adopted unified data format, the block number corresponding to the blockchain data is carried; or information indicating the block number corresponding to the blockchain data.

[0146] Among them, the above data format is not particularly limited in this specification; for example, in one example, the data identifiers of the blockchain data stored in each storage system carried by the node device may uniformly adopt the data format of the LSN (Log Sequence Number) of the WAL log file, and by carrying the block number corresponding to the blockchain data in the LSN of the WAL log file; or information indicating the block number corresponding to the blockchain data.

[0147] In this specification, when the above first event is triggered, the node device may respond to the first event and read, from the log buffer corresponding to the above target storage system, the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the block number range (C, N] composed of the above latest block number C and the above latest block number N; then, based on the read WAL log files, restore the block transaction data in the blocks represented by each block number in the block number range (C, N].

[0148] After the block transaction data in the blocks represented by each block number in the block number range (C, N] is restored, the restored block transaction data may be further executed, and by re-executing the transactions, the above other types of blockchain data corresponding to the block transaction data in the blocks represented by each block number in the block number range (C, N] may be generated.

[0149] For example, in one example, assume that the node device is equipped with 5 different storage systems, and respectively stores the block transaction data, the block header data of the block corresponding to the block transaction data, the transaction receipt corresponding to the block transaction data, the state data, and the index data corresponding to the above 4 types of data in these 5 different storage systems; among them, the target storage system storing the above block transaction data has the WAL mode enabled; then when recovering the above other types of blockchain data, after reading the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the above block number range (C, N], the above block transaction data can be recovered based on this WAL log file, and after the above block transaction data is recovered, by re-executing the above block transaction data, the block header data corresponding to the above block transaction data, the corresponding transaction receipt, the corresponding state data, and the corresponding index data are respectively recovered.

[0150] Among them, the specific method of generating the block header data of the block, the transaction data corresponding to the above transaction data, the corresponding state data, and the corresponding index data by re-executing the transaction data in the block is common knowledge in the blockchain field and will not be elaborated in this specification. Those skilled in the art can refer to the records in related technologies when assisting in implementing the technical solutions of this specification.

[0151] In an illustrated embodiment, when the node device recovers the block transaction data stored in the above target storage system, it can periodically determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the above target storage system reaches a threshold; if so, it can trigger the generation of the above second event.

[0152] In another illustrated embodiment, when the node device recovers the block transaction data stored in the target storage system, it can also respond to an instruction manually triggered by the user to recover the above block transaction data to determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the above target storage system reaches a threshold; if so, it can trigger the generation of the above second event.

[0153] For example, in practical applications, in addition to periodically checking whether the above target storage system meets the triggering conditions of the above checkpiont event, the node device can also be triggered by the user manually inputting a recovery instruction to check whether the above target storage system meets the triggering conditions of the above checkpiont event; for example, in some recovery scenarios, the user may need to perform a data rollback operation on the blockchain transaction data stored in the above target storage system to restore the block transaction data stored in the above target storage system to the data version corresponding to a certain historical block. In such a scenario, the user can trigger the node device to check whether the above target storage system meets the triggering conditions of the above checkpiont event by manually inputting a recovery instruction.

[0154] When the above second event is triggered and generated, the node device can, in response to the second event, read from the log buffer corresponding to the above target storage system the WAL log file corresponding to the block transaction data stored in the log buffer; then, based on the read WAL log file, restore the block transaction data, and then write the restored block transaction data into the above target storage system.

[0155] In the above technical solution, on the one hand, since among the multiple storage systems carried by the blockchain, only the target storage system for storing block transaction data may support the write-ahead log (WAL) mode, and the storage systems for storing other types of blockchain data corresponding to the block transaction data do not need to repeatedly enable the WAL mode; therefore, for a node device carrying multiple storage systems, only one WAL log file corresponding to the block transaction data needs to be stored and maintained, and there is no need to store and maintain multiple WAL log files, which can significantly reduce the storage overhead of the node device when storing multiple types of blockchain data;

[0156] On the other hand, since other types of blockchain data corresponding to the block transaction data stored in the node device are uniformly restored based on the WAL log file corresponding to the block transaction data; for a node device carrying multiple storage systems, there is no need to perform data restoration based on the WAL log files corresponding to each storage system separately; therefore, the performance overhead of the node device when restoring multiple types of blockchain data can be significantly reduced.

[0157] Corresponding to the above method embodiment, the present application also provides an embodiment of a device.

[0158] Corresponding to the above method embodiment, this specification also provides an embodiment of a blockchain data recovery device.

[0159] Embodiments of the blockchain data recovery device in this specification can be applied to electronic devices. The device embodiments can be implemented through software, or through hardware or a combination of software and hardware. Taking software implementation as an example, as a logically meaningful device, it is formed by the processor of the electronic device where it is located reading the corresponding computer program instructions in the non-volatile memory into the memory for operation.

[0160] In terms of the hardware level, as Figure 2 shown, it is a hardware structure diagram of the electronic device where the blockchain data recovery device in this specification is located. In addition to Figure 2 the processor, memory, network interface, and non-volatile memory shown, the electronic device where the device is located in the embodiments usually includes other hardware according to the actual functions of the electronic device, which will not be elaborated here.

[0161] Figure 3 It is a block diagram of a blockchain data recovery device shown in an exemplary embodiment of this specification.

[0162] Please refer to Figure 3 , the blockchain data recovery device 30 can be applied to the aforementioned Figure 2 shown electronic device. The node device is equipped with multiple storage systems for storing blockchain data; among them, the blockchain data includes block transaction data and at least one other type of blockchain data; the target storage system for storing the block transaction data among the multiple storage systems supports the Write-Ahead Log (WAL) mode; the device 30 includes:

[0163] A reading module 301, in response to a first event for recovering the other type of blockchain data, reads the WAL log file corresponding to the block transaction data stored in the target storage system;

[0164] A recovery module 302, based on the WAL log file, recovers the block transaction data and executes the recovered block transaction data to generate the other type of blockchain data;

[0165] A writing module 303, writes the generated other type of blockchain data into each storage system among the multiple storage systems for storing the other type of blockchain data.

[0166] In this embodiment, the device 30 further includes:

[0167] A first determination module 304 ( Figure 3(not shown in the figure), determine whether the latest block number C among the block numbers corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N among the block numbers corresponding to the block transaction data stored in the target storage system; if so, generate the first event.

[0168] In this embodiment, the latest block number C is the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in each storage system;

[0169] The first determination module 304 further:

[0170] Before determining whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system, calculate the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in each storage system to obtain the latest block number C.

[0171] In this embodiment, the data identifiers of the blockchain data stored in the multiple storage systems include the block numbers corresponding to the blockchain data.

[0172] In this embodiment, the data identifiers of the blockchain data stored in the multiple storage systems adopt a unified data format.

[0173] In this embodiment, the data identifier adopts the data format of the LSN log sequence number of the WAL log file.

[0174] In this embodiment, the reading module 301:

[0175] Read the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the block number range (C, N] composed of the latest block number C and the latest block number N respectively;

[0176] The recovery module 302:

[0177] Based on the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the read block number range (C, N], recover the block transaction data corresponding to the blocks represented by each block number, and execute the recovered block transaction data to generate the other types of blockchain data corresponding to the block transaction data in the blocks represented by each block number.

[0178] In this embodiment, the first determination module 304 ( Figure 3 not shown in the figure):

[0179] Periodically determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system; or,

[0180] In response to an instruction triggered by the user to recover the other types of blockchain data, determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system.

[0181] In this embodiment, the other types of blockchain data include one or more combinations shown below:

[0182] The block header data of the block corresponding to the block transaction data;

[0183] The transaction receipt corresponding to the block transaction data;

[0184] After the block transaction data is executed, the account status data corresponding to the blockchain accounts in the blockchain.

[0185] In this embodiment, the writing module 303 further:

[0186] In response to a second event for recovering the block transaction data, recover the block transaction data based on the WAL log file, and write the recovered block transaction data into the target storage system.

[0187] In this embodiment, the device 30 further includes:

[0188] A second determination module 305 ( Figure 3 not shown in the figure), determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; if so, generate the second event.

[0189] In this embodiment, the second determination module 305:

[0190] Periodically determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; or,

[0191] In response to an instruction triggered by the user to recover the block transaction data, determine whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold.

[0192] The systems, devices, modules or units illustrated in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device, or a combination of any several of these devices.

[0193] In a typical configuration, a computer includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0194] The memory may include non-permanent memory in the computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of, for example, read-only memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.

[0195] Computer-readable media include permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The information may be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible by a computing device. As defined herein, computer-readable media do not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0196] It should also be noted that the term "comprises", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion, such that a process, method, commodity or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, commodity or device comprising the element.

[0197] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0198] The terms used in one or more embodiments of this specification are for the purpose of describing particular embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a", "the", and "said" used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0199] It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "upon" or "in response to determining".

[0200] The above is only the preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A blockchain data recovery method, applied to a node device; the node device is equipped with a plurality of storage systems for storing blockchain data; wherein, The blockchain data includes block transaction data and at least one other type of blockchain data; The target storage system among the multiple storage systems for storing the block transaction data supports the Write-Ahead Log (WAL) mode; the method includes: In response to a first event for recovering the other type of blockchain data, reading the WAL log file corresponding to the block transaction data stored in the target storage system; Recovering the block transaction data based on the WAL log file, and executing the recovered block transaction data to generate the other type of blockchain data; Writing the generated other type of blockchain data into each of the storage systems among the multiple storage systems for storing the other type of blockchain data, where each of the storage systems does not enable the Write-Ahead Log (WAL) mode.

2. The method according to claim 1, the method further includes: Determining whether the latest block number C among the block numbers corresponding to the other type of blockchain data stored in each of the storage systems is less than the latest block number N among the block numbers corresponding to the block transaction data stored in the target storage system; If so, generating the first event.

3. The method according to claim 2, the latest block number C is the minimum value of the latest block numbers corresponding to the other type of blockchain data stored in each of the storage systems; Before determining whether the latest block number C among the block numbers corresponding to the other type of blockchain data stored in each of the storage systems is less than the latest block number N among the block numbers corresponding to the block transaction data stored in the target storage system, further includes: Calculating the minimum value of the latest block numbers corresponding to the other type of blockchain data stored in each of the storage systems to obtain the latest block number C.

4. The method according to claim 3, the data identifier of the blockchain data stored in the multiple storage systems includes the block number corresponding to the blockchain data.

5. The method according to claim 4, the data identifiers of the blockchain data stored in the multiple storage systems adopt a unified data format.

6. The method according to claim 5, the data identifier adopts the data format of the LSN (Log Sequence Number) of the WAL log file.

7. The method according to claim 2, reading the WAL log file corresponding to the block transaction data stored in the target storage system includes: Respectively reading the WAL log files corresponding to the block transaction data in the blocks represented by each block number in the block number interval (C, N] formed by the latest block number C and the latest block number N; Recovering the block transaction data based on the WAL log file, and executing the recovered blockchain transaction to generate the other type of blockchain data, includes: Based on the WAL log files corresponding to the block transaction data in the blocks represented by the block numbers in the read block number range (C, N], recover the block transaction data in the blocks represented by the respective block numbers, and execute the recovered block transaction data to generate the other types of blockchain data corresponding to the block transaction data in the blocks represented by the respective block numbers.

8. The method according to claim 2, determining whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system, includes: Periodically determining whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system; or, In response to an instruction triggered by the user for recovering the other types of blockchain data, determining whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is less than the latest block number N corresponding to the block transaction data stored in the target storage system.

9. The method according to claim 1 or 8, the other types of blockchain data include one or more combinations shown below: The block header data of the block corresponding to the block transaction data; The transaction receipt corresponding to the block transaction data; After the block transaction data is executed, the account status data corresponding to the blockchain accounts in the blockchain.

10. The method according to claim 1, the method further includes: In response to a second event for recovering the block transaction data, recover the block transaction data based on the WAL log file, and write the recovered block transaction data into the target storage system.

11. The method according to claim 10, the method further includes: Determining whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; If so, generate the second event.

12. The method according to claim 11, determining whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold, includes: Periodically determining whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold; Or, In response to an instruction triggered by the user for recovering the block transaction data, determining whether the number of files or the storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold.

13. A blockchain data recovery device is applied to a node device; the node device is equipped with a plurality of storage systems for storing blockchain data; among them, The blockchain data includes block transaction data and at least one other type of blockchain data; The target storage system for storing the block transaction data among the multiple storage systems supports the Write-Ahead Log (WAL) mode; the device includes: A reading module, in response to a first event for recovering other types of blockchain data, reads a WAL log file corresponding to the block transaction data stored in the target storage system; A recovery module recovers the block transaction data based on the WAL log file and executes the recovered block transaction data to generate the other types of blockchain data; A writing module writes the generated other types of blockchain data into respective storage systems for storing the other types of blockchain data in the multiple storage systems, and the respective storage systems do not enable the write-ahead log (WAL) mode.

14. An electronic device, comprising: A processor; A memory for storing processor-executable instructions; Wherein, the processor implements the method according to any one of claims 1-12 by running the executable instructions.

15. A computer-readable storage medium having computer instructions stored thereon, characterized in that, When the instructions are executed by the processor, the steps of the method according to any one of claims 1-12 are implemented.

Images