WO2023160077A1

WO2023160077A1 - Blockchain data recovery method and apparatus, and electronic device

Info

Publication number: WO2023160077A1
Application number: PCT/CN2022/135120
Authority: WO
Inventors: 俞本权; 陆钟豪; 卓海振
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-02-25
Filing date: 2022-11-29
Publication date: 2023-08-31
Also published as: CN114780285A

Abstract

A blockchain data recovery method, applied to a node device. The node device carries a plurality of storage systems for storing blockchain data, wherein the blockchain data comprises block transaction data and at least one of other types of blockchain data, and a target storage system, used for storing the block transaction data, among the plurality of storage systems supports a write ahead logging (WAL) mode. The method comprises: in response to a first event for recovering other types of blockchain data, reading a WAL log file corresponding to block transaction data stored in a target storage system; recovering the block transaction data on the basis of the WAL log file, and executing the recovered block transaction data to generate the other types of blockchain data; and respectively writing the other types of generated blockchain data into each storage system, used for storing the other types of blockchain data, among the plurality of storage systems.

Description

Block chain data recovery method and device, electronic equipment

technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a blockchain data recovery method and device, and electronic equipment.

Background technique

Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Due to the characteristics of decentralization, openness and transparency, each computing device can participate in database records, and fast data synchronization between computing devices, blockchain technology has been widely used in many fields. to apply.

Contents of the invention

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 block chain data includes block transaction data and at least one other type of block chain data; the target storage system for storing the block transaction data in the plurality of storage systems supports the write-ahead log WAL model. The method includes: reading a WAL log file corresponding to the block transaction data stored in the target storage system in response to the first event of recovering the other type of blockchain data; based on the WAL log The file restores the block transaction data, and executes the recovered block transaction data to generate the other types of block chain data; write the generated block chain data of other types into the Each of the multiple storage systems is used to store the other types of blockchain data.

Optionally, the method further includes: 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 smaller than the block number C stored in the target storage system The latest block number N among the block numbers corresponding to the block transaction data; if yes, the first event is generated.

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 the storage systems; determine the other block numbers stored in the storage systems Whether the latest block number C corresponding to the type of blockchain data is less than the latest block number N corresponding to the block transaction data stored in the target storage system, it also includes: calculating the The minimum value of the latest block number corresponding to other types of blockchain data is used to obtain the latest block number C.

Optionally, the data identification of the blockchain data stored in the plurality of storage systems includes a block number corresponding to the blockchain data.

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

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

Optionally, reading the WAL log file corresponding to the block transaction data stored in the target storage system includes: respectively reading the blocks composed of the latest block number C and the latest block number N The WAL log file corresponding to the block transaction data in the block represented by each block number in the number interval (C, N]; restore the block transaction data based on the WAL log file, and execute the restored Block chain transactions to generate the other types of block chain data, including: corresponding to the block transaction data in the block represented by each block number in the block number interval (C, N] read WAL log file, restore the block transaction data in the block represented by each block number, and execute the recovered block transaction data to generate the block transaction data in the block represented by the block number The other types of blockchain data corresponding to the block transaction data.

Optionally, determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is smaller than the latest block number N corresponding to the block transaction data stored in the target storage system, Including: periodically determining whether the latest block number C corresponding to the other types of blockchain data stored in the storage systems is smaller than the latest block number N corresponding to the block transaction data stored in the target storage system; Or, in response to user-triggered instructions for restoring the other types of blockchain data, determine whether the latest block number C corresponding to the other types of blockchain data stored in the storage systems is less than the specified The latest block number N corresponding to the block transaction data stored in the target storage system.

Optionally, the other types of blockchain data include a combination of one or more of the following: the block header data of the block corresponding to the block transaction data; the block header data corresponding to the block transaction data The transaction receipt; after the block transaction data is executed, the account status data corresponding to the block chain account in the block chain.

Optionally, the method further includes: in response to the second event of restoring the block transaction data, restoring the block transaction data based on the WAL log file, and restoring the block transaction data data, written to the target storage system.

Optionally, the method further includes: determining whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold; if so, generating the second event.

Optionally, determining whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold includes: periodically determining the block transaction data stored in the target storage system Whether the number of files or the storage capacity of the WAL log file corresponding to the data reaches the threshold; or, in response to an instruction triggered by the user to restore the block transaction data, determine that the block transaction data corresponding to the target storage system Whether the number of files or storage capacity of WAL log files reaches the threshold.

This specification also proposes a blockchain data recovery device, which is applied to node equipment; the node equipment is equipped with multiple storage systems for storing blockchain data. Wherein, the block chain data includes block transaction data and at least one other type of block chain data; the target storage system for storing the block transaction data in the plurality of storage systems supports the write-ahead log WAL model. The device includes: a reading module, which reads the WAL log file corresponding to the block transaction data stored in the target storage system in response to the first event of restoring the other types of blockchain data; Module, restores the block transaction data based on the WAL log file, and executes the recovered block transaction data to generate the other types of block chain data; writes the module, and generates the other types of block chain data The block chain data are respectively written into each storage system used to store the other types of block chain data in the plurality of storage systems.

Optionally, the device further includes: a first determining module, which determines whether the latest block number C among the block numbers corresponding to the other types of blockchain data stored in the storage systems is smaller than the target The latest block number N among the block numbers corresponding to the block transaction data stored in the storage system; if yes, the first event is generated.

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. The determination module further: after determining whether the latest block number C corresponding to the other types of blockchain data stored in the storage systems is smaller than the latest block number C corresponding to the block transaction data stored in the target storage system Before number N, 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.

Optionally, the reading module: respectively read the blocks represented by the block numbers in the block number interval (C, N] formed by the latest block number C and the latest block number N] The WAL log file corresponding to the block transaction data in the block; the recovery module: based on the block transaction data corresponding to the block in the block represented by each block number in the block number interval (C, N] read WAL log file, restore the block transaction data in the blocks represented by the block numbers, and execute the recovered block transaction data to generate the block transaction data in the blocks represented by the block numbers The other types of blockchain data corresponding to the block transaction data.

Optionally, the first determining module: periodically determine whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is smaller than the block transaction stored in the target storage system The latest block number N corresponding to the data; or, in response to the user-triggered instruction for restoring the other types of blockchain data, determine the corresponding block number of the other types of blockchain data stored in the storage systems Whether the latest block number C is smaller than the latest block number N corresponding to the block transaction data stored in the target storage system.

Optionally, the writing module further: in response to the second event of restoring the block transaction data, restore the block transaction data based on the WAL log file, and restore the block transaction data The transaction data is written into the target storage system.

Optionally, the device further includes: a second determining module, determining whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold; if so, generating the second event.

Optionally, the second determination module: periodically determines whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold; or, in response to user-triggered targeting The instruction for recovering the block transaction data determines whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold.

Among the above technical solutions, on the one hand, due to the multiple storage systems carried by the blockchain, only the target storage system used to store the transaction data of the block supports the write-ahead log WAL mode, and is used to store the transaction data related to the block Corresponding storage systems for other types of blockchain data do not need to repeatedly enable the WAL mode. Therefore, for a node device equipped with multiple storage systems, only one WAL log file corresponding to the block transaction data can be stored and maintained, and it is no longer necessary to store and maintain multiple WAL log files, which can significantly reduce The storage overhead of node devices when storing various blockchain data.

On the other hand, because other types of blockchain data corresponding to the block transaction data stored by the node device are restored in a unified manner based on the WAL log file corresponding to the block transaction data; for nodes equipped with multiple storage systems As far as the device is concerned, it is no longer necessary to perform data recovery based on the WAL log files corresponding to each storage system; therefore, the performance overhead of node devices when restoring multiple blockchain data can be significantly reduced.

Description of drawings

Fig. 1 is a flow chart of a method for recovering blockchain data provided by an exemplary embodiment;

Fig. 2 is a schematic structural diagram of an electronic device provided by an exemplary embodiment;

Fig. 3 is a block diagram of a block chain data recovery device provided by an exemplary embodiment.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. Implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps 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; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there can be a combination of the above types, such as private chain + alliance chain, alliance chain + public chain, etc.

Among them, the public chain has the highest degree of decentralization. Participants joining the public chain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each node is free to join or exit the network and perform related operations.

On the contrary, the private chain, the write permission of the network is controlled by an 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 internal use by specific institutions.

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

Based on the basic characteristics of the blockchain, the blockchain is usually composed of several blocks. Time stamps corresponding to the creation time of the block are respectively recorded in these blocks, and all blocks form a time-ordered data chain in strict accordance with the time stamps recorded in the block.

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, and the node devices in the blockchain will perform consensus processing on the received transactions , and after a consensus is reached, the node device in the blockchain as the bookkeeping node will package the transaction into a block and store the certificate persistently in the blockchain.

Among them, the consensus algorithms supported in the blockchain can include: the first type of consensus algorithm, that is, the consensus algorithm that node devices need to compete for the accounting rights of each round of accounting cycle, for example, proof of work (Proof of Work, POW ), proof of equity (Proof of Stake, POS), delegated proof of equity (Delegated Proof of Stake, DPOS) and other consensus algorithms; the second type of consensus algorithm is to pre-elect accounting nodes for each round of accounting cycle (no need to compete Bookkeeping rights) consensus algorithms; for example, consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT).

In the blockchain network using the first type of consensus algorithm, the node devices competing for the bookkeeping right can execute the transaction after receiving the transaction. Among the node devices competing for bookkeeping rights, there may be a node device that wins the current round of competition for bookkeeping rights and becomes a bookkeeping node. The accounting node can package the received transaction 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.

In the blockchain network using the second type of consensus algorithm, the node equipment with bookkeeping rights has been agreed before the current round of bookkeeping. Therefore, after the node device receives the transaction, if it is not the accounting node of the current round, it can send the transaction to the accounting node. For the bookkeeping nodes of this round, the transaction can be executed during or before the process of packaging the transaction with other transactions to generate the latest block. After the accounting node generates the latest block, it can send the latest block or the block header of the latest block to other node devices for consensus.

As mentioned above, no matter which consensus algorithm the blockchain adopts, the bookkeeping nodes of this round can package the received transactions to generate the latest block, and will generate the latest block or the latest block The block header is sent to other node devices for consensus verification. If other node devices receive the latest block or the block header of the latest block and verify that there is no problem, the latest block can be appended to the end of the original blockchain to complete the accounting process of the blockchain. In the process of verifying the new block or block header sent by the bookkeeping node, other nodes can also execute the transactions contained in the block.

In the field of blockchain, an important concept is account (Account); taking Ethereum as an example, Ethereum usually divides accounts into two types: external accounts and contract accounts; external accounts are accounts directly controlled by users, also known as It is a user account; while a contract account is an account created by a user through an external account and contains a contract code (that is, a smart contract).

Of course, for some blockchain models derived from the Ethereum-based architecture (such as Ant Blockchain), the account types supported by the blockchain can also be further expanded, which is not specifically limited in this manual.

For accounts in the blockchain, a structure is usually used to maintain the account status of the account. When a transaction in a block is executed, the state of the account associated with the transaction in the blockchain usually also changes.

Taking Ethereum as an example, the account structure usually includes fields such as Balance, Nonce, Code, and Storage. in:

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

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 only be processed once, effectively avoiding replay attacks;

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.

The Storage field is used to maintain the storage content of the account (the default field value is empty); for the contract account, an independent storage space is usually allocated to store the storage content of the contract account; the independent storage space is usually It is called the account storage of the contract account. The storage content of the contract account is usually built into a data structure of MPT (Merkle Patricia Trie) tree and stored in the above-mentioned 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 . 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. Wherein, for the external account, the field values of the Code field and the Storage field shown above are all null values.

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

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

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

For the blockchain data that needs to be stored and maintained in the blockchain, Ethereum has designed three MPT trees, namely the MPT state tree, MPT transaction tree and MPT receipt tree. Among them, in addition to the above three MPT trees, there is actually a Storage tree built based on the storage content of the contract account.

The MPT state tree is an MPT tree organized by the account state (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 the MPT tree organized by the transaction (receipt) receipt corresponding to each transaction generated after the transaction in the block is executed. The hash values of the root nodes of the MPT state tree, MPT transaction tree and MPT receipt tree shown above will eventually be added to the block header of the corresponding block.

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

The following uses the MPT state tree as an example for illustration.

Every time the blockchain generates the latest block, after the transactions in the latest block are executed, the account status of the accounts (which can be external accounts or contract accounts) related to these executed transactions in the blockchain, usually It will also change accordingly. For example, when a "transfer transaction" in a block is executed, the balances of the transfer-out account and transfer-in account related to the "transfer transaction" (that is, the field value of the Balance field of these accounts) are usually also Will change accordingly.

After the transaction of the node device in the latest block generated by the blockchain is completed, because the account status in the current blockchain has changed, the node device needs to use the current account status data of all accounts in the blockchain. Build an MPT state tree to maintain the latest state of all accounts in the blockchain.

That is, whenever a latest block is generated in the blockchain, and after the transaction in the latest block is executed, the account status in the blockchain changes, the node device needs to be based on all accounts in the blockchain The latest account status data rebuilds an MPT status tree.

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

In practical applications, since the blockchain usually connects with various business systems outside the chain for multi-party data and workflow collaboration (independent of business); for example, a business system A connected to the blockchain, Relevant business data can be published to the blockchain to drive another business system B that is connected to the blockchain to perform further business processing based on the business data; and for different types of blockchain data, the multi-party data In the process of cooperating with the workflow, the actual functions may be different from each other; when node devices store and maintain blockchain data, they usually carry multiple storage systems and store different types of blockchain data in the in different storage systems.

For example, in one example, the node device can be equipped with three different storage systems, which store block data, state data (that is, the above account status data), and index data corresponding to the above two types of data (such as the hash of the above two types of data) value), which are stored in different storage systems. (5 copies of WAL are examples respectively).

In another example, the node device can combine block header data, block transaction data, transaction receipts corresponding to block transaction data, state data (that is, the above-mentioned account status data), and index data corresponding to the above four types of data (such as The hash values of the above 4 kinds of data) are stored in different storage systems; in this case, the node device can be equipped with 5 different storage systems, which respectively store block header data, block transaction The transaction receipt, state data corresponding to the data, and the index data corresponding to the above four types of data are stored in these five different storage systems.

When node devices store different types of blockchain data in different storage systems, in order to prevent data loss due to unwritten data, each storage system can enable WAL (write ahead logging, pre-written log) mode.

Among them, the WAL mode is an efficient log algorithm. In the storage system with WAL mode enabled, all data modification for the storage system will be written into the WAL log file before being submitted to the storage system; then, through the checkpoint event triggered periodically or manually by the user, the The data stored in the WAL log file is modified and written to the storage system.

By enabling the WAL mode for the storage system on the node device, although data loss due to unwritten data can be prevented, the blockchain ledger stored by the node device often contains many different types of blockchain data. Stored in different storage systems; therefore, storing multiple WAL log files will increase the storage overhead of the node device; moreover, when the node device restores the data modification stored in multiple WAL log files to the storage system, it needs multiple times Executing the related recovery process will also increase the performance overhead of the node device.

In view of this, this manual proposes a technical solution for recovering various blockchain data by using a WAL log file stored in the node device and corresponding to the blockchain transaction data.

When implemented, the node device of the blockchain can be equipped with multiple storage systems for storing blockchain data. Wherein, the aforementioned block chain data may include block transaction data and at least one type of block chain data with other types; the target storage system used to store the block transaction data in the above-mentioned multiple storage systems may support the write-ahead log WAL model. When the node device responds to the first event of recovering the above-mentioned other types of blockchain data, 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 The log file restores the above-mentioned block transaction data. After the above-mentioned block transaction data is restored, the restored block transaction data is further executed to generate the above-mentioned other types of block chain data; then, the generated above-mentioned other Types of blockchain data are respectively written into the storage systems used to store the other types of blockchain data in the above-mentioned multiple storage systems.

In the above technical solutions, on the one hand, due to the multiple storage systems carried by the blockchain, only the target storage system for storing block transaction data supports the write-ahead log WAL mode, and for storing The storage system of other types of blockchain data corresponding to the block transaction data does not need to repeatedly enable the WAL mode. Therefore, for a node device equipped with multiple storage systems, only one WAL log file corresponding to the block transaction data can be stored and maintained, and it is no longer necessary to store and maintain multiple WAL log files, which can significantly reduce The storage overhead of node devices when storing various blockchain data.

Please refer to FIG. 1, which is a flow chart of a blockchain data recovery method provided by an exemplary embodiment. The method is applied to a block chain node device; wherein, the block chain data includes block transaction data and at least one other type of block chain data corresponding to the block transaction data; the plurality of stored The target storage system used to store the block transaction data in the system supports the write-ahead log WAL mode. The method comprises the steps of:

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

Step 104, recovering the block transaction data based on the WAL log file, and executing the recovered block transaction data to generate the other types of blockchain data;

Step 106, writing the generated blockchain data of other types into storage systems for storing the blockchain data of other types among the multiple storage systems.

In this specification, the blockchain ledger stored by the node device usually includes various types of blockchain data. The various types of blockchain data mentioned above may generally 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 block body data further includes block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, etc. wait.

In practical applications, in order to facilitate query and retrieval of stored blockchain data, in addition to the blockchain data listed above, node devices usually need to store and maintain index data corresponding to the above-mentioned various blockchain data. Wherein, the specific form of the above-mentioned index data is not particularly limited in this specification.

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, so that users can use the content summary of the above blockchain data as a query index to query and access related blockchain data in the blockchain ledger.

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

When storing and maintaining the various blockchain data listed above, the node device can be equipped with multiple storage systems, and store different types of blockchain data in different storage systems. Among them, the above-mentioned storage system can specifically include any form of storage system for persistent storage of blockchain data in the blockchain ledger; for example, in practical applications, the above-mentioned storage system can specifically be a node device carrying The database, file system, etc., are not particularly limited in this specification.

It should be noted that due to data such as block header data, transaction receipts corresponding to block transaction data, and state data (that is, the above-mentioned account state data); ) data is recovered; 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 the various types of blockchain data shown above, the above-mentioned block can be Transaction data and other types of blockchain data are stored in separate storage systems.

For example, in one example, the node device can be equipped with five different storage systems, which respectively store 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 four types of data are stored in these five different storage systems.

In this specification, in order to prevent the loss of "root data" caused by the above-mentioned "root data" not being written, the target storage system used to store "root data" (that is, block transaction data) in each storage system can open WAL model. After the WAL mode is turned on, all data modifications (such as writing new block transaction data) for the target storage system will be written to the target storage system in the form of a WAL log file before being submitted to the target storage system. The WAL log buffer corresponding to the target storage system; the log buffer can also be a persistent storage; then, when the blockchain system triggers a checkpoint event corresponding to the above target storage system, the node device can respond to the checkpoint Event, and then modify the above "root data" data stored in the WAL log file, and restore it to the target storage system.

Wherein, the above-mentioned checkpoint event refers to an event of performing data recovery on the blockchain data stored in the storage system based on the WAL log file.

For other storage systems used to store other types of blockchain data other than "root data" in each storage system, the WAL mode may not be enabled, but cross-storage based on the WAL log files corresponding to the above-mentioned target storage systems. Data recovery of the storage system; that is, a storage system that does not enable the WAL mode can also perform data recovery through the corresponding WAL log files of other storage systems that enable the WAL mode.

In this case, the blockchain system can also checkpoint events of the above-mentioned other storage systems that have not opened the WAL mode; and when the blockchain system triggers the checkpoint events corresponding to the above-mentioned other storage systems, the node device can In response to the checkpoint event, read the WAL log file corresponding to the above-mentioned target storage system for data recovery calculation, and then based on the calculation results of the data recovery calculation, cross-storage system data for other types of blockchain data stored in the other storage systems mentioned above data recovery.

In this specification, the process for the node device to recover the block transaction data stored in the above-mentioned target storage system, and the process for recovering other types of blockchain data stored in the above-mentioned other storage systems can be two The procedures that are independent of each other are not particularly limited in the execution sequence of the two in this specification.

That is to say, in practical applications, the node device can first perform the process of recovering the block transaction data stored in the above-mentioned target storage system, and then perform recovery of other types of blockchain data stored in the above-mentioned other storage systems The process of recovering other types of blockchain data stored in the above-mentioned other storage systems can also be performed first, and then the process of recovering the block transaction data stored in the above-mentioned target storage system can be performed.

It should be noted that the process of 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 above-mentioned target The process of recovering the block transaction data stored in the storage system needs to temporarily not delete the WAL log file corresponding to the above block transaction data stored in the log buffer after the above block transaction data is restored; when the node device starts Execute the process of recovering other types of blockchain data stored in the above-mentioned other storage systems, and continue to restore other types of blockchain data stored in the above-mentioned other storage systems based on the above-mentioned WAL log files, and in After recovery is complete, delete the WAL log file from the log buffer.

Among them, it also needs to be explained that due to 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 mutually independent processes; therefore, the checkpoint event triggered by the blockchain system corresponding to the above target storage system, and the trigger condition corresponding to the checkpoint event triggered by the blockchain system corresponding to the other storage systems above can also be different from each other.

Among them, for the convenience of description, the checkpoint event triggered by the blockchain system and corresponding to the above-mentioned other storage systems will be called "the first event"; the checkpoint event triggered by the blockchain system and corresponding to the above-mentioned target storage system , which will be referred to as the "second event".

In one embodiment shown, in the WAL-based data recovery mechanism, the trigger condition of the above-mentioned first event may generally include that the number of WAL log files 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 target storage system reaches a threshold.

That is, when the number of WAL log files 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 files corresponding to the block transaction data stored in the above-mentioned target storage system reaches The threshold can trigger the blockchain system to generate the above-mentioned first event.

In another embodiment shown, due to the data recovery of other types of blockchain data stored in the above-mentioned other storage systems, it is based on the WAL log files corresponding to the above-mentioned target storage systems. Data recovery is different from the local data recovery of the block transaction data stored in the target storage system based on the WAL log file; therefore, the triggering condition of the second event above can be the same as the triggering of the checkpoint event of the WAL-based data recovery mechanism Conditions vary. The trigger condition of the above-mentioned second event may specifically include that the latest block number C among the block numbers corresponding to the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems is smaller than the block transaction data stored in the above-mentioned target storage system The latest block number N in the corresponding block number.

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 smaller than the block number C in the block number corresponding to the block transaction data stored in the above-mentioned target storage system The latest block number N can trigger the blockchain system to generate the above-mentioned second event.

The following will use a specific embodiment to trigger the above-mentioned first event based on the blockchain system for the node device, and restore the other types of blockchain data stored in the above-mentioned other storage systems; and, the node device triggers the process based on the system The process of recovering the block transaction data stored in the above-mentioned target storage system for the above-mentioned second event is described separately.

In one embodiment shown, when the node device restores other types of blockchain data stored in the above-mentioned other storage systems, it can periodically determine the above-mentioned other types of blocks stored in the above-mentioned other storage systems Whether the latest block number C corresponding to the chain data is smaller than the latest block number N corresponding to the block transaction data stored in the above-mentioned target storage system; if yes, the generation of the above-mentioned first event can be triggered.

For example, in a practical application, the node device may preset a check period T of the checkpiont event, and then periodically check whether the above-mentioned other storage systems meet the triggering condition of the above-mentioned checkpiont event based on the period T.

In another embodiment shown, when the node device restores other types of blockchain data stored in the above-mentioned other storage systems, it can also respond to user-triggered Data recovery instructions to determine whether the latest block number C corresponding to the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems is smaller than the latest block number N corresponding to the block transaction data stored in the above-mentioned target storage system ; If yes, it may trigger to generate the above-mentioned first event.

For example, in practical applications, in addition to periodically checking whether the above-mentioned other storage systems meet the trigger conditions of the above-mentioned checkpiont event, the user can also trigger the node device to check the above-mentioned other storage systems by manually inputting recovery instructions. Whether the trigger conditions of the above checkpiont event are met; for example, in some recovery scenarios, the user may need to perform a data rollback operation on the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems, and restore the data stored in the above-mentioned other storage systems The above-mentioned other types of blockchain data are restored to the data version corresponding to a certain historical block; in this scenario, the user can trigger the node device to check whether the above-mentioned other storage systems meet the above-mentioned checkpoint by manually inputting the recovery command. The trigger condition for the event.

Wherein, the latest block number C corresponding to the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems may specifically be the latest block number C corresponding to the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems In this case, the node device can first calculate the minimum value of the latest block number corresponding to the above-mentioned other types of blockchain data stored in the above-mentioned other storage systems, and obtain the above-mentioned latest block number C, It is further determined whether the above latest block number C is smaller than the latest block number N corresponding to the block transaction data stored in the target storage system.

In one embodiment shown, in order to facilitate the determination of the block number corresponding to the blockchain data stored in each storage system carried by the node device, the data identification of the blockchain data stored in each storage system may specifically include the above-mentioned The block number corresponding to the blockchain data; that is, the block number corresponding to the blockchain data can be directly added to the data identifier of the blockchain data; or, in the data identifier of the blockchain data, Add information indicating the block number to which the blockchain data corresponds.

In one implementation, the data identification of the blockchain data stored in each storage system carried by the node device can specifically adopt a unified data format, and in the unified data format adopted, carry the data corresponding to the blockchain data. Block number; or information indicating the block number corresponding to the blockchain data.

Among them, the above-mentioned data format is not particularly limited in this specification; for example, in one example, the data identification of the blockchain data stored in each storage system carried by the node device can uniformly use the LSN (Log Sequence Number, the data format of the log sequence number), and carry the block number corresponding to the blockchain data in the LSN of the WAL log file; or indicate the information of the block number corresponding to the blockchain data.

In this specification, when the above-mentioned first event is triggered, the node device can respond to the first event by reading the above-mentioned latest block number C and the above-mentioned latest block number C from the log buffer corresponding to the above-mentioned target storage system respectively. The WAL log file corresponding to the block transaction data in the block represented by each block number in the block number interval (C, N] formed by the block number N; then, based on the read WAL log file, restore the above-mentioned The block transaction data in the block represented by each block number in the block number interval (C, N].

When the block transaction data in the block represented by each block number in the above block number interval (C, N] is recovered, the recovered block transaction data can be further executed, and by re-executing the transaction, generate The above-mentioned other types of blockchain data corresponding to the block transaction data in the block represented by each block number in the above-mentioned block number interval (C, N].

For example, in one example, assume that the node device is equipped with five different storage systems, which respectively store 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 four types of data are stored in these five different storage systems; among them, the target storage system that stores the above block transaction data has turned on the WAL mode; then for the above other types of blocks When recovering chain data, after reading the WAL log file corresponding to the block transaction data in the block represented by each block number in the above block number interval (C, N], based on the WAL log file First restore the above-mentioned block transaction data, and after the above-mentioned block transaction data is restored, by re-executing the above-mentioned block transaction data, the block header data corresponding to the above-mentioned block transaction data, the corresponding transaction receipt, The corresponding state data and corresponding index data are restored separately.

Among them, by re-executing the transaction data in the block, the specific way to generate 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 is the blockchain field. Common knowledge will not be described in detail in this specification, and those skilled in the art can refer to the records in related technologies when assisting in the realization of the technical solutions in this specification.

In one embodiment shown, when the node device restores the block transaction data stored in the above target storage system, it can periodically determine the WAL log file corresponding to the block transaction data stored in the above target storage system Whether the number of files or the storage capacity reaches the threshold; if yes, the above-mentioned second event may be triggered to be generated.

In another embodiment shown, when the node device recovers the block transaction data stored in the target storage system, it may also respond to an instruction manually triggered by the user to restore the above block transaction data to determine Whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold; if yes, the generation of the second event above may be triggered.

For example, in practical applications, in addition to periodically checking whether the above-mentioned target storage system meets the trigger conditions of the above-mentioned checkpoint event, the user can also trigger the node device to check whether the above-mentioned target storage system meets The trigger condition 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, and restore the block transaction data stored in the above target storage system to a certain The data version corresponding to a historical block. In this scenario, the user may manually input a recovery command to trigger the node device to check whether the target storage system satisfies the trigger condition of the checkpiont event.

When the above-mentioned second event is triggered, the node device can respond to the second event and read the WAL log file corresponding to the block transaction data stored in the log buffer from the log buffer corresponding to the above-mentioned target storage system; and 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.

Among the above technical solutions, on the one hand, due to the multiple storage systems carried by the blockchain, only the target storage system used to store the transaction data of the block supports the write-ahead log WAL mode, and is used to store the transaction data related to the block Corresponding storage systems for other types of blockchain data do not need to repeatedly enable the WAL mode; therefore, for node devices equipped with multiple storage systems, only one WAL log corresponding to block transaction data can be stored and maintained It is no longer necessary to store and maintain multiple WAL log files, which can significantly reduce the storage overhead of node devices when storing various blockchain data;

Corresponding to the foregoing method embodiments, the present application also provides device embodiments.

Corresponding to the above method embodiments, this specification also provides an embodiment of a block chain data recovery device.

The embodiment of the blockchain data recovery device in this specification can be applied to electronic equipment. The device embodiment can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the electronic device where it is located.

From the hardware level, as shown in Figure 2, it is a hardware structure diagram of the electronic equipment where the blockchain data recovery device in this manual is located, except for the processor, memory, network interface, and non-volatile memory shown in Figure 2 In addition to the non-volatile memory, the electronic device where the device in the embodiment is located usually may also include other hardware according to the actual function of the electronic device, which will not be repeated here.

Fig. 3 is a block diagram of a block chain data recovery device shown in an exemplary embodiment of this specification.

Please refer to FIG. 3, the block chain data recovery device 30 can be applied in the aforementioned electronic equipment shown in FIG. 2, and the node device is equipped with multiple storage systems for storing block chain data; wherein, the The block chain data includes block transaction data and at least one other type of block chain data; the target storage system for storing the block transaction data in the plurality of storage systems supports the write-ahead log WAL mode; the The device 30 includes: a reading module 301, which reads the WAL log file corresponding to the block transaction data stored in the target storage system in response to the first event of restoring the other types of blockchain data; Module 302, restore the block transaction data based on the WAL log file, and execute the recovered block transaction data to generate the other types of block chain data; write module 303, the generated Other types of blockchain data are respectively written into the storage systems used to store the other types of blockchain data among the plurality of storage systems.

In this embodiment, the device 30 further includes: a first determination module 304 (not shown in FIG. 3 ), which determines the number of block numbers corresponding to the other types of blockchain data stored in each storage system. Whether the latest block number C of the target storage system is smaller than the latest block number N in the block numbers corresponding to the block transaction data stored in the target storage system; if yes, the first event is generated.

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 the storage systems. The first determination module 304 further: after determining whether the latest block number C corresponding to the other types of blockchain data stored in the storage systems is smaller than the block number C corresponding to the block transaction data stored in the target storage system Before the latest block number N, calculate the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in the storage systems to obtain the latest block number C.

In this embodiment, the data identification of the blockchain data stored in the multiple storage systems includes the block number corresponding to the blockchain data.

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

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

In this embodiment, the reading module 301: respectively reads the block number 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] The WAL log file corresponding to the block transaction data in the block.The recovery module 302: based on the block in the block represented by each block number in the block number interval (C, N] read The WAL log file corresponding to the transaction data restores the block transaction data in the blocks represented by the block numbers, and executes the recovered block transaction data to generate the block transaction data represented by the block numbers. The other types of blockchain data corresponding to the block transaction data in the block.

In this embodiment, the first determination module 304 (not shown in FIG. 3 ): periodically determine the latest block number C corresponding to the other types of blockchain data stored in each storage system, whether is less than the latest block number N corresponding to the block transaction data stored in the target storage system; or, in response to the instruction triggered by the user to restore the other types of blockchain data, determine the Whether the latest block number C corresponding to the other types of blockchain data is smaller than the latest block number N corresponding to the block transaction data stored in the target storage system.

In this embodiment, the other types of blockchain data include a combination of one or more of the following: block header data of the block corresponding to the block transaction data; The transaction receipt corresponding to the data; after the block transaction data is executed, the account status data corresponding to the block chain account in the block chain.

In this embodiment, the writing module 303 further: in response to the second event of restoring the block transaction data, restore the block transaction data based on the WAL log file, and restore all The block transaction data is written into the target storage system.

In this embodiment, the device 30 further includes: a second determination module 305 (not shown in FIG. 3 ), which determines the number of WAL log files corresponding to the block transaction data stored in the target storage system or Whether the storage capacity reaches a threshold; if so, generating the second event.

In this embodiment, the second determination module 305: periodically determines whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold; or, in response to the user The triggered instruction for recovering the block transaction data determines whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, 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 technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, 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 that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Terms used in one or more embodiments of the present specification are for the purpose of describing specific embodiments only, and are not intended to limit the one or more embodiments of the present specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a", "the", and "the" 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 includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of the present specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims

A blockchain data recovery method, 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 types of block chain 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:

reading a WAL log file corresponding to the block transaction data stored in the target storage system in response to the first event of recovering the other type of blockchain data;

Restoring the block transaction data based on the WAL log file, and executing the restored block transaction data to generate the other types of block chain data;

The generated blockchain data of other types are respectively written into each storage system used to store the blockchain data of other types among the plurality of storage systems.
The method according to claim 1, said method further comprising:

Determine whether the latest block number C in the block numbers corresponding to the other types of blockchain data stored in the storage systems is smaller than the block number C in the block number corresponding to the block transaction data stored in the target storage system The latest block number N; if yes, generate said first event.
According to the method according to claim 2, the latest block number C is the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in the storage systems;

Before determining whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is smaller than the latest block number N corresponding to the block transaction data stored in the target storage system, it also includes:

Calculating the minimum value of the latest block numbers corresponding to the other types of blockchain data stored in the storage systems to obtain the latest block number C.
According to the method according to claim 3, the data identification of the blockchain data stored in the plurality of storage systems includes a block number corresponding to the blockchain data.
According to the method according to claim 4, the data identification of the blockchain data stored in the plurality of storage systems adopts a unified data format.
According to the method according to claim 5, the data identification adopts the data format of the LSN log sequence number of the WAL log file.
According to the method according to claim 2, reading the WAL log file corresponding to the block transaction data stored in the target storage system includes:

Read respectively the WAL log corresponding to the block transaction data in the block 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 document;

Restoring the block transaction data based on the WAL log file, and executing the recovered block chain transaction to generate the other types of block chain data, including:

Based on the WAL log file corresponding to the block transaction data in the block represented by each block number in the read block number interval (C, N], restore the block corresponding to the block represented by each block number block transaction data, and execute the recovered block transaction data to generate the other types of block chain data corresponding to the block transaction data in the block represented by each block number.
According to the method of claim 2, it is determined whether the latest block number C corresponding to the other types of blockchain data stored in each storage system is smaller than the latest block number C corresponding to the block transaction data stored in the target storage system. Block number N, including:

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

In response to user-triggered instructions for restoring the other types of blockchain data, determine whether the latest block number C corresponding to the other types of blockchain data stored in the storage systems is smaller than the target The latest block number N corresponding to the block transaction data stored in the storage system.
According to the method according to claim 1 or 8, the other types of blockchain data include a combination of one or more of the following:

Block header data of a block corresponding to the block transaction data;

A transaction receipt corresponding to the block transaction data;

Account state data corresponding to the blockchain account in the blockchain after the execution of the block transaction data is completed.
The method according to claim 1, said method further comprising:

In response to the second event of restoring the block transaction data, restore the block transaction data based on the WAL log file, and write the restored block transaction data into the target storage system.
The method of claim 10, further comprising:

Determine whether the number of files or the storage capacity of the WAL log files corresponding to the block transaction data stored in the target storage system reaches a threshold; if yes, generate the second event.
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, comprising:

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

In response to the user-triggered instruction for recovering the block transaction data, determine whether the file quantity or storage capacity of the WAL log file corresponding to the block transaction data stored in the target storage system reaches a threshold.
A block chain data recovery device, applied to a node device; the node device is equipped with multiple storage systems for storing block chain data; wherein, the block chain data includes block transaction data and at least one Other types of block chain data; the target storage system for storing the block transaction data in the multiple storage systems supports the write-ahead log WAL mode; the device includes:

The reading module reads the WAL log file corresponding to the block transaction data stored in the target storage system in response to the first event of recovering the other types of blockchain data;

A recovery module, recovering the block transaction data based on the WAL log file, and executing the recovered block transaction data to generate the other types of blockchain data;

The writing module writes the generated blockchain data of other types into each storage system used to store the blockchain data of other types among the multiple storage systems.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1 to 12 by running the executable instructions.
A computer-readable storage medium, on which computer instructions are stored, wherein the steps of the method according to any one of claims 1 to 12 are implemented when the instructions are executed by a processor.