A method and related equipment for recovering blockchain data

Abstract

This application provides a method and related equipment for recovering blockchain data, enabling more efficient recovery. The method includes: creating a monitoring service program on a computer device and configuring the monitoring service program to monitor block files in the blockchain directory; establishing a named pipe between the monitoring service program and the blockchain client based on the block file storage path, the blockchain client name, and the monitoring service program name; encapsulating the operation entry point in the blockchain client for reading and writing block files; when the monitoring service program detects non-blockchain modification operations on the block files, recording the changes to the block files; and if the blockchain client is already running, sending the recorded changes to the blockchain client via the named pipe.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a method and related equipment for recovering blockchain data. Background Technology

[0002] Currently, each blockchain client needs to download the entire block to its local computer. The amount of block data in the blockchain itself is very large, and as the blockchain develops, the amount of block data will continue to increase.

[0003] However, in practical applications, when a user uninstalls the blockchain client from their local computer and needs to reinstall the software, or when a user accidentally deletes block files on their local computer, the entire blockchain data file needs to be downloaded. This can be time-consuming and inefficient. Therefore, how to make data recovery in the blockchain faster and more efficient is a problem that needs to be solved. Summary of the Invention

[0004] This application provides a method and related equipment for recovering blockchain data, which can improve the efficiency of blockchain data recovery.

[0005] A first aspect of this application provides a method for recovering blockchain data, comprising: creating a monitoring service program on a computer device, and setting up a function in the monitoring service program to monitor block files under a blockchain directory, the monitoring service program starting automatically upon startup of the computer device, the blockchain directory being a directory generated when a blockchain client is installed on the computer device; establishing a named pipe between the monitoring service program and the blockchain client based on the storage path of the block files, the name of the blockchain client, and the name of the monitoring service program; encapsulating an operation entry point in the blockchain client for reading and writing block files; when the monitoring service program detects that a non-blockchain entity has modified the block files, recording the change information of the block files through the monitoring service program; if the blockchain client has started, sending the change information recorded by the monitoring service program to the blockchain client via the named pipe, so that the blockchain client receives the change information through the operation entry point and restores the block files based on the change information.

[0006] Optionally, creating the monitoring service program on the computer device includes: assigning values ​​to two fields of the SERVICE_TABLE_ENTRY dispatch table structure using the following function:

[0007] SERVICE_TABLE_ENTRY ServiceTable[];

[0008] ServiceTable[0].lpServiceName = "The name of the service";

[0009] ServiceTable[0].lpServiceProc=ServiceMain;

[0010] The first field, ServiceTable[0].lpServiceName, is the name of the monitoring service program, and the second field, ServiceTable[0].lpServiceProc, is a pointer to the entry function of the monitoring service program. The monitoring service program is created by calling the system function StartServiceCtrlDispatcher(ServiceTable), which is used to register the entry function of the monitoring service program.

[0011] Optionally, the function of setting up monitoring of block files under the blockchain directory in the monitoring service program includes: setting up monitoring of the block directory through the function ReadDirectoryChangesW to determine the modified block files, obtaining the name of the modified block files through the function pFileNotifyInfo->FileName, determining the change type of the modified block files through the switch function, and storing the change information of the modified block files through the storage structure. The change type includes deleting files, adding files, modifying files, and renaming files.

[0012] Optionally, establishing a named pipe between the monitoring service program and the blockchain client based on the path where the block file is stored, the name of the blockchain client, and the name of the monitoring service program includes:

[0013] Multiple fast string hash functions are used to calculate the path where the block file is stored, resulting in multiple hash values. These hash values ​​are then concatenated to obtain a concatenated hash value, where each hash value is a 4-byte integer. The named pipe is established using the following function: Pipe_name = fasthash(path) + block + blockservice; where Pipe_name represents the name of the named pipe, fasthash(path) represents the concatenated hash value, block represents the name of the blockchain client, and blockservice represents the name of the monitoring service program.

[0014] Optionally, the operation entry point for reading and writing block files in the encapsulated blockchain client includes: setting a write interface function `Void virtual Write(string name1, char*buff1, uint64 size1)`, where `name1` represents the filename to be written, `buff1` represents the data buffer to be written, and `size1` represents the file size to be written; the write interface function is used to write block files. Also, setting a read interface function `Void virtual Read(string name2, char*buff2, uint64 size2)`, where `name2` represents the filename to be read, `buff2` represents the data storage area to be read, and `size2` represents the file size to be read; the read interface function is used to read block files.

[0015] Optionally, the method further includes: setting up an independent data area in the blockchain, the independent data area being used to store the unique identification information of each computer device and the corresponding block data; if the blockchain client is not started, the monitoring service program associates the change information with the unique identification information of the computer device and stores it in the independent data area, so that after the monitoring service program is started, it can obtain the change information from the blockchain based on the unique identification information of the computer device.

[0016] Optionally, the method further includes: receiving a user's uninstallation request for the blockchain client via the computer device; uninstalling the blockchain client in response to the download request and setting the attribute of the blockchain directory to a hidden attribute; and changing the attribute of the blockchain directory to a non-hidden attribute if it is necessary to reinstall the blockchain client on the computer device.

[0017] A second aspect of this application provides a recovery apparatus, comprising: a creation unit, configured to create a monitoring service program on a computer device and configure the monitoring service program to monitor block files under a blockchain directory, the monitoring service program starting automatically upon startup of the computer device, the blockchain directory being a directory generated when a blockchain client is installed on the computer device; an establishment unit, configured to establish a named pipe between the monitoring service program and the blockchain client based on the storage path of the block files, the name of the blockchain client, and the name of the monitoring service program; an encapsulation unit, configured to encapsulate the operation entry point in the blockchain client used for reading and writing block files; a recording unit, configured to record the change information of the block files through the monitoring service program when the monitoring service program detects that a non-blockchain entity has modified the block files; and a transceiver unit, configured to send the change information recorded by the monitoring service program to the blockchain client via the named pipe if the blockchain client has started, so that the blockchain client receives the change information through the operation entry point and restores the block files based on the change information.

[0018] In summary, it can be seen that in the embodiments provided in this application, a monitoring service program is created on a computer device, and the monitoring service program is configured to monitor block files under the blockchain directory. The monitoring service program starts automatically when the computer device starts, and the blockchain directory is a directory generated when the blockchain client is installed on the computer device. A named pipe is established between the monitoring service program and the blockchain client based on the storage path of the block files, the name of the blockchain client, and the name of the monitoring service program. An operation entry point for reading and writing block files in the blockchain client is encapsulated. When the monitoring service program detects that a non-blockchain entity has modified the block files, it records the change information of the block files. If the blockchain client has started, the change information recorded by the monitoring service program is sent to the blockchain client via the named pipe, so that the blockchain client receives the change information through the operation entry point and restores the block files based on the change information. Through the embodiments of this application, by designing a monitoring service program to constantly monitor the change information of block files and send this change information to the blockchain client for incremental recovery, the recovery efficiency of blockchain data is improved. Attached Figure Description

[0019] Figure 1 A flowchart illustrating a possible method for recovering blockchain data, provided as an embodiment of this application;

[0020] Figure 2A schematic diagram illustrating one possible embodiment of a recovery device provided in this application;

[0021] Figure 3 This is a schematic diagram of the hardware structure of a possible recovery device provided in an embodiment of this application;

[0022] Figure 4 A schematic diagram illustrating a possible embodiment of an electronic device provided in this application;

[0023] Figure 5 This is a schematic diagram illustrating one possible embodiment of a computer-readable storage medium provided in this application. Detailed Implementation

[0024] This application provides a method and related equipment for recovering blockchain data, which can improve the efficiency of blockchain data recovery.

[0025] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The technical solutions of the embodiments of this application will now be clearly and completely described in conjunction with the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0026] Please see Figure 1 The flowchart illustrates a possible method for recovering blockchain data according to an embodiment of this application, specifically including:

[0027] 101. Create a monitoring service program on the computer device;

[0028] Since blockchain clients can be closed by users, it's impossible to monitor all block files. We also want a program that can continuously reside on the computer and start automatically upon computer startup. Therefore, in this embodiment, a service program is designed to ensure that it starts with the computer device, thus enabling uninterrupted monitoring of all block files. Like ordinary applications, the service program needs a main function as its entry point. However, unlike ordinary applications, a service program needs to immediately call `StartServiceCtrlDispatcher` in its main function to register a service entry function, `ServiceMain`. The purpose of `ServiceMain` is to place the tasks to be executed within this function and execute them in a loop; this is the service program's working function. Before `ServiceMain` executes tasks, the `SERVICE_TABLE_ENTRY` dispatch table structure needs to be assigned a value. For ease of description, this embodiment refers to the designed service program for monitoring block files as a monitoring service program.

[0029] Specifically, the monitoring service program is created as follows: Values ​​are assigned to two fields of the SERVICE_TABLE_ENTRY dispatch table structure using the following functions:

[0030] SERVICE_TABLE_ENTRY ServiceTable[];

[0031] ServiceTable[0].lpServiceName = "The name of the service";

[0032] ServiceTable[0].lpServiceProc=ServiceMain;

[0033] The first field, ServiceTable[0].lpServiceName, is the name of the monitoring service program, and the second field, ServiceTable[0].lpServiceProc, is a pointer to the entry function. The monitoring service program is then created by calling the system function StartServiceCtrlDispatcher(ServiceTable). The system function StartServiceCtrlDispatcher is used to register the entry function of the monitoring service program.

[0034] It should be explained that the prototype of the StartServiceCtrlDispatcher function is

[0035] BOOL StartServiceCtrlDispatcher(

[0036] LPSERVICE_TABLE_ENTRY lpServiceStartTable);

[0037] Its parameter is a pointer to a SERVICE_TABLE_ENTRY structure; the SERVICE_TABLE_ENTRY structure has two fields: the first field stores the internal name of the service, and the second field is a pointer to the service entry function. After the StartServiceCtrlDispatcher function completes, it starts the service by calling the service entry function.

[0038] 102. Configure the monitoring service program to monitor block files under the blockchain directory;

[0039] On Windows devices, if this is the first time installing the blockchain client, the client will set the storage location for the blockchain block data, and the monitoring service program will be informed of this storage location information. Therefore, the main function of the monitoring service program (service_main) is to configure the monitoring of block files in the block directory. The specific method for configuring the monitoring function is as follows:

[0040] Void service_main(){

[0041] char*dir = the storage path of the blockchain block file.

[0042] The `service_main()` function is the entry point for the registered monitoring service program, and `dir` is the storage path of the blockchain block files provided during the installation of the blockchain client.

[0043] The storage path handle of the block file is obtained through the system function CreateFile. The specific implementation function is as follows:

[0044] HANDLE hDir=::CreateFile(dir,FILE_LIST_DIRECTORY,FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,FILE_FLAG_BACKUP_SEMANTICS,NULL);

[0045] Here, the handle is an identifier used to identify an object or item; FILE_LIST_DIRECTORY is used to represent the file directory; FILE_SHARE_READ|FILE_SHARE_WRITE is used to indicate that shared access to the file is allowed; OPEN_EXISTING indicates that the file must already exist; and FILE_FLAG_BACKUP_SEMANTICS indicates that the system performs a backup or restore operation for opening or creating the file.

[0046] Then, a storage structure is created using the function FILE_NOTIFY_INFORMATION*pFileNotifyInfo. This storage structure is used to store change information of block files under the block directory.

[0047] Since the monitoring directory requires continuous monitoring, if the monitoring were in the client process, a separate thread would typically be created to perform the monitoring. However, in this embodiment, because the monitoring is performed within the monitoring service program, and the monitoring service program and the blockchain client are separate processes, the absence of the monitoring service program does not affect the blockchain client. Therefore, monitoring can be performed directly within the monitoring service program.

[0048] In this embodiment, the ReadDirectoryChangesW function can be used to monitor files and directories. This function can detect changes to a file within the target directory, i.e., the block directory. The specific implementation function is as follows:

[0049] do{

[0050] bRet=::ReadDirectoryChangesW(hDirectory,pFileNotifyInfo,

[0051] dwBufferSize, TRUE

[0052] FILE_NOTIFY_CHANGE_FILE_NAME,

[0053] FILE_NOTIFY_CHANGE_DIR_NAME,

[0054] FILE_NOTIFY_CHANGE_ATTRIBUTES,

[0055] FILE_NOTIFY_CHANGE_CREATION,

[0056] FILE_NOTIFY_CHANGE_LAST_WRITE,

[0057] &dwRet, NULL, NULL); where bRet represents the change information of block files under the block directory, hDirectory represents the handle of the block directory, pFileNotifyInfo points to the storage structure, dwBufferSize represents the buffer size, true represents the monitored subdirectory, FILE_NOTIFY_CHANGE_FILE_NAME represents the modified file name; FILE_NOTIFY_CHANGE_DIR_NAME represents the modified directory; FILE_NOTIFY_CHANGE_ATTRIBUTES represents the modified file attributes; FILE_NOTIFY_CHANGE_CREATION represents the created file; and FILE_NOTIFY_CHANGE_LAST_WRITE represents the last time the file was written.

[0058] The modified chunk file is then retrieved using the function pFileNotifyInfo->FileName, and a switch function is used to determine the type of change to that chunk file, where the type of change includes...

[0059] Delete files, add files, modify files, and rename files:

[0060] pFileNotifyInfo->FileName

[0061] switch(pFileNotifyInfo->Action)

[0062] {

[0063] case FILE_ACTION_REMOVED:

[0064] case FILE_ACTION_ADDED:

[0065] case FILE_ACTION_MODIFIED:

[0066] case FILE_ACTION_RENAMED_OLD_NAME:

[0067] while(true);

[0068] Among them, FILE_ACTION_REMOVED is used to indicate the deletion of a file, FILE_ACTION_ADDED is used to indicate the addition of a file, FILE_ACTION_MODIFIED is used to indicate the modification of a file, and FILE_ACTION_RENAMED_OLD_NAME is used to indicate the renaming of a file.

[0069] Through the above monitoring and judgment, the monitoring service program can monitor the changes in the block files under the blockchain directory.

[0070] 103. Based on the storage path of the block file, the name of the blockchain client, and the name of the monitoring service program, establish a named pipe between the monitoring service program and the blockchain client;

[0071] In this embodiment, data communication between the monitoring service program and the blockchain client needs to be considered. Named pipes are used for inter-process communication in this embodiment. The most important aspect of named pipes is coordinating the pipe names between the two programs, ensuring that the pipe names do not conflict with those of other programs. Therefore, the pipe name in this paper can be a combination of the hash value of the blockchain block data storage path, the blockchain program name, and the service name of the service program. This ensures that both the monitoring service program and the blockchain client know how to calculate the named pipe, while also preventing name conflicts with named pipes used by other processes on the computer device.

[0072] The specific implementation steps include: using multiple fast string hash functions to calculate the path where the block file is stored to obtain multiple hash results, and concatenating the multiple hash results to obtain a concatenated hash value. Each hash result is a 4-byte integer. In this embodiment, the fast string hash function can be BKDRHash, APHash, DJBHash, JSHash, RSHash, SDBMHash, PJWHash, or ELFHash; the specific function is not limited here.

[0073] Then, create a named pipe using the following function:

[0074] Pipe_name=fasthash(path)+block+blockservice;

[0075] Here, Pipe_name represents the name of the named pipe, fasthash(path) represents the concatenation of hash values, block represents the name of the blockchain client, and blockservice represents the name of the monitoring service program.

[0076] 104. Encapsulate the entry point for reading and writing block files in the blockchain client;

[0077] It's important to note that the blockchain client itself needs to read and write block files. Considering that the blockchain client needs to obtain block file read / write information and send it to the monitoring service program, and also receives information from the monitoring service program about block file deletions and modifications, it's necessary to encapsulate the read / write operations on the blockchain file. That is, all operations should pass through an encapsulation layer, thus providing a unified entry point for block file read / write operations. The specific implementation function is as follows:

[0078] Class BlockFile{

[0079] Public:

[0080] Virtual~BlockFile(){}

[0081] Void virtual Write(string name1,char*buff1,uint64 size1){

[0082] Pipe.write(name,"write");

[0083] }

[0084] This interface is used to write blocks. The "Virtual" setting indicates that the destructor `BlockFile()` is virtual, facilitating future integration and functionality expansion. `name1` represents the filename, `buff1` represents the data buffer to be written, and `size1` is the size of the data buffer. `Pipe.write` is used to call the encapsulated named pipe to notify the monitoring service program of information.

[0085] Void virtual Read(string name2,char*buff2,uint64 size2){

[0086] Pipe.write(name,"write");

[0087] }

[0088] Correspondingly, this interface is used to read block data, and using virtual functions allows for convenient overloading to implement different functionalities. Here, `name2` represents the filename, `buff2` represents the data storage area, and `size2` represents the size of the data storage area.

[0089] Void virtual Recv(string name,string operation){}

[0090] This interface is used to receive message notifications from the monitoring service program via named pipes. `name` represents the name of the changed block file, and `operation` specifies the actual add, delete, or modify operation performed on the changed block file. For each operation, the corresponding file is checked; if it's deleted, it's downloaded again; if it's modified, the modified block file is downloaded.

[0091] Optionally, to prevent developers from forgetting to use the unified interface to operate on block files, resulting in block file operations being performed without notifying the service program, this embodiment hooks the file read / write operations of the current process when the blockchain program starts. This allows the hook function to detect all file operations. Upon receiving a file operation, it first determines whether the operated file is a block file. If so, it checks the call stack information to see if it matches the encapsulated interface. If they match, it indicates that the unified encapsulated interface was used for the operation; otherwise, the developer has mistakenly used a read / write operation, so the operation returns a failure, and the error is written to the log file to inform the developer.

[0092] 105. When the monitoring service program detects that non-blockchain entities have modified the block file, it records the changes to the block file.

[0093] It's important to note that the purpose of monitoring is to record modifications to block files within the blockchain directory, primarily to prevent non-blockchain programs from manipulating these files. Monitoring reveals all operations performed by the blockchain client itself on the block files within the blockchain directory. Simultaneously, operations by users, other software, or viruses on the block files in the blockchain directory can also be monitored; for example, user error leading to the deletion of a file in the blockchain directory. The blockchain client and the monitoring service communicate. Any block file operation performed by the blockchain is communicated to the monitoring service via inter-process communication, indicating which file in the blockchain directory was added, deleted, or modified. After detecting modifications to the block files, the monitoring service excludes operations performed by the blockchain client itself, leaving only non-blockchain operations. These non-blockchain operations are recorded and communicated to the blockchain client, which can then download a new, updated file to correct any erroneous operations by other users or software.

[0094] Optionally, in the monitoring service program, if it is not a blockchain client that deletes the block file in the blockchain, a pop-up window will be displayed to inform the user that the current file deletion operation will result in the loss of the blockchain block file, so as to inform the user not to delete files at will.

[0095] 106. If the blockchain client has been started, the change information recorded by the monitoring service program is sent to the blockchain client via the named pipe, so that the blockchain client can receive the change information through the operation entry and restore the block file according to the change information.

[0096] If the blockchain client is already running, it receives change information through the operation entry point and restores the block file based on the change information. Specifically, based on the type of change, the blockchain client's block file restoration operation is as follows:

[0097] Modification: For blockchain clients, each block has a file hash value, so the client will calculate the hash of the modified file and download a new file from the blockchain network;

[0098] Delete: For files that have already been deleted, download a new file from the blockchain network;

[0099] Adding: For newly added files, simply delete them.

[0100] If you want to change the name, you need to check if the file has been modified. If it has, you need to download a new file. If it hasn't been modified, just rename it to the original file name.

[0101] Modify directory: Change to the original directory.

[0102] It should be noted that if the current blockchain client is not running, once the monitoring service program starts and detects any file additions, deletions, or modifications in the blockchain directory, the monitoring service program will record all operations in chronological order. The following recording method can be used:

[0103] Modification: Record the paths of all modified files. For any given file, it is only necessary to record whether it has been modified once, rather than how many times it has been modified.

[0104] Deletion: For deleted files, record which files were deleted;

[0105] Add: For added files, record which files were added;

[0106] For files that have been renamed, record the original filename and the new filename. Alternatively, you can check the file modification history to see if any changes were made to the renamed file. If no changes were made, you can simply restore the original name. If changes were made, you will need to download a new file.

[0107] Modify directory: Record changes made to the directory.

[0108] Furthermore, even when the blockchain client program is not running, and the monitoring service program records the changes and writes them to the computer device, there is still a possibility of user accidental deletion leading to the loss of block files. Therefore, the blockchain can be used to store this change information. When the blockchain client program starts, it retrieves this change information from the blockchain to recover the blockchain block files. Optionally, in this embodiment, a user-independent data area can be designed within the blockchain. This data area does not participate in blockchain computation; it is only used to store user information and is not publicly accessible. Only the respective user can see their data. It should be noted that in practical applications, a blockchain user may log in to the blockchain client on multiple computer devices. Since each computer device has an independent disk, and the location of the stored block files may differ, it is necessary to distinguish each computer device. In this embodiment, the unique identifier information of the computer device is used to distinguish the changes to the block files of the blockchain client installed on each computer device. This unique identifier information may include MAC address, CPU serial number, or disk serial number, etc., which are not specifically limited here. In summary, within the independent data area of ​​the blockchain, the unique identification information of the acquired computer device and the location information of the blockchain block file can be associated and stored in the blockchain.

[0109] Optionally, when a user uninstalls the blockchain client, the blockchain's block directory is set to a hidden directory, thus protecting the block files within and preventing subsequent deletion of the block directory by the user. That is, when the blockchain uninstaller executes, it only deletes all installed components and other data, hiding the block directory without deleting the block files. When the blockchain client is reinstalled, it reads the independent data area of ​​the computer device and obtains the device's unique identifier. Based on this identifier, it reads the blockchain's stored information, including the location of the block directory on the device. After obtaining the location information, since the block directory is a hidden file, its file attributes need to be changed to non-hidden. The blockchain client can then download the latest block data (i.e., the changed block data) based on previously downloaded blocks, while already downloaded blocks can be reused, enabling rapid recovery of blockchain data. It's important to note that for block design, the block header information (including block size number, hash value, etc.) and the block content can be stored separately. This way, blockchain clients will frequently access historical block header information, but not historical block data. This design hides previously downloaded block data, preventing accidental deletion by users or viruses, while the header data of historical blocks can be copied for use by the blockchain program.

[0110] Optionally, in this embodiment, the monitoring service program and the blockchain client can perform bidirectional monitoring. The monitoring service program monitors the block data of the blockchain client, and after the blockchain client starts, it also monitors whether the monitoring service program has started normally. If it has not started, it will start the monitoring service program. Simultaneously, both the monitoring service program and the blockchain client program will monitor the named pipe, which allows them to detect whether the other has been created. If one party finds that the other does not exist through the named pipe, it will create the other's program. It should be noted that the monitoring service program does not actively create the blockchain client, but the blockchain client actively creates the monitoring service program. Normally, the monitoring service program starts with the computer device; only in special circumstances where problems occur will the blockchain client need to create the monitoring service program.

[0111] In this embodiment of the application, by designing the blockchain block file, it is ensured that the block file downloaded once can be reused subsequently, avoiding the need to download the block file repeatedly when reinstalling the software, thus making the recovery of the blockchain block file more efficient.

[0112] The method for recovering blockchain data in the embodiments of this application has been described above. The recovery device in the embodiments of this application is described below.

[0113] Please see Figure 2 One embodiment of the recovery device in this application includes:

[0114] The creation unit 201 is used to create a monitoring service program on a computer device and set the function of monitoring block files under the blockchain directory in the monitoring service program. The monitoring service program starts automatically when the computer device is started. The blockchain directory is a directory generated when a blockchain client is installed on the computer device.

[0115] The creation unit 201 is also used to establish a named pipe between the monitoring service program and the blockchain client based on the path where the block file is stored, the name of the blockchain client, and the name of the monitoring service program.

[0116] Encapsulation unit 202 is used to encapsulate the operation entry point for reading and writing block files in the blockchain client;

[0117] The recording unit 203 is used to record the change information of the block file through the monitoring service program when the monitoring service program detects that there is a non-blockchain modification operation on the block file;

[0118] The transceiver unit 204 is used to send the change information recorded by the monitoring service program to the blockchain client via the named pipe if the blockchain client has been started, so that the blockchain client can receive the change information through the operation entry and restore the block file according to the change information.

[0119] above Figure 2 The recovery device in the embodiments of this application has been described from the perspective of modular functional entities. The recovery device in the embodiments of this application is described in detail below from the perspective of hardware processing. Please refer to [link / reference]. Figure 3 One embodiment of the recovery device 300 in this application includes:

[0120] Input device 301, output device 302, processor 303, and memory 304 (where the number of processors 303 can be one or more). Figure 3 (Taking a processor 303 as an example). In some embodiments of this application, the input device 301, output device 502, processor 303, and memory 304 can be connected via a bus or other means, wherein... Figure 3 Taking the example of a connection between China and Israel via a bus.

[0121] Specifically, by calling the operation instructions stored in memory 304, processor 303 executes the following steps:

[0122] A monitoring service program is created on a computer device, and the monitoring service program is configured to monitor block files under the blockchain directory. The monitoring service program starts automatically when the computer device is started. The blockchain directory is a directory generated when a blockchain client is installed on the computer device.

[0123] Based on the path where the block file is stored, the name of the blockchain client, and the name of the monitoring service program, establish a named pipe between the monitoring service program and the blockchain client;

[0124] Encapsulate the operation entry point for reading and writing block files in the blockchain client;

[0125] When the monitoring service program detects that there is a non-blockchain modification operation on the block file, the monitoring service program records the change information of the block file.

[0126] If the blockchain client has been started, the change information recorded by the monitoring service program is sent to the blockchain client via the named pipe, so that the blockchain client can receive the change information through the operation entry and restore the block file according to the change information.

[0127] By calling the operation instructions stored in memory 304, processor 303 is also used to execute... Figure 1 Any of the methods in the corresponding embodiments.

[0128] Please see Figure 4 , Figure 4 A schematic diagram illustrating an embodiment of the electronic device provided in this application.

[0129] like Figure 4 As shown, this application embodiment provides an electronic device, including a memory 410, a processor 420, and a computer program 411 stored in the memory 420 and executable on the processor 420. When the processor 420 executes the computer program 411, it performs the following steps:

[0130] A monitoring service program is created on a computer device, and the monitoring service program is configured to monitor block files under the blockchain directory. The monitoring service program starts automatically when the computer device is started. The blockchain directory is a directory generated when a blockchain client is installed on the computer device.

[0131] Based on the path where the block file is stored, the name of the blockchain client, and the name of the monitoring service program, establish a named pipe between the monitoring service program and the blockchain client;

[0132] Encapsulate the operation entry point for reading and writing block files in the blockchain client;

[0133] When the monitoring service program detects that there is a non-blockchain modification operation on the block file, the monitoring service program records the change information of the block file.

[0134] If the blockchain client has been started, the change information recorded by the monitoring service program is sent to the blockchain client via the named pipe, so that the blockchain client can receive the change information through the operation entry and restore the block file according to the change information.

[0135] In practical implementation, when the processor 420 executes the computer program 411, it can achieve... Figure 1 Any of the corresponding implementation methods in the embodiments.

[0136] Since the electronic device described in this embodiment is a device used to implement a recovery device in the embodiments of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in the embodiments of this application. Therefore, how the electronic device implements the method in the embodiments of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiments of this application falls within the scope of protection of this application.

[0137] Please see Figure 5 , Figure 5 This is a schematic diagram illustrating an embodiment of a computer-readable storage medium provided in this application.

[0138] like Figure 5 As shown, this embodiment provides a computer-readable storage medium 500 on which a computer program 511 is stored. When the computer program 511 is executed by a processor, it performs the following steps:

[0139] A monitoring service program is created on a computer device, and the monitoring service program is configured to monitor block files under the blockchain directory. The monitoring service program starts automatically when the computer device is started. The blockchain directory is a directory generated when a blockchain client is installed on the computer device.

[0140] Based on the path where the block file is stored, the name of the blockchain client, and the name of the monitoring service program, establish a named pipe between the monitoring service program and the blockchain client;

[0141] Encapsulate the operation entry point for reading and writing block files in the blockchain client;

[0142] When the monitoring service program detects that there is a non-blockchain modification operation on the block file, the monitoring service program records the change information of the block file.

[0143] If the blockchain client has been started, the change information recorded by the monitoring service program is sent to the blockchain client via the named pipe, so that the blockchain client can receive the change information through the operation entry and restore the block file according to the change information.

[0144] In practical implementation, when the computer program 511 is executed by the processor, it can achieve the following: Figure 1 Any of the corresponding implementation methods in the embodiments.

[0145] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0146] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0148] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0149] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0150] This application also provides a computer program product, which includes computer software instructions that, when executed on a processing device, cause the processing device to perform actions such as... Figure 1 The process flow in the wind farm digital platform design method in the corresponding embodiment.

[0151] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0152] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0153] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

[0155] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0156] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0157] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for recovering blockchain data, characterized in that, include: A monitoring service program is created on a computer device, and the monitoring service program is configured to monitor block files under the blockchain directory. The monitoring service program starts automatically when the computer device is started. The blockchain directory is a directory generated when a blockchain client is installed on the computer device. Establish a named pipe between the monitoring service program and the blockchain client based on the path where the block file is stored, the name of the blockchain client, and the name of the monitoring service program; Encapsulate the operation entry point for reading and writing block files in the blockchain client; In a blockchain program, file read and write operations are hooked when the program starts. The hook function is aware of all file operations. After the file operation is detected, it first determines whether the file being operated on is a block file. If it is, it continues to check its call stack information to see if it is consistent with the encapsulated interface. If it is consistent, it means that the unified encapsulated interface is being called. Otherwise, it means that the developer has misused the read and write operation, and the operation is returned as a failure. The blockchain client will notify the monitoring service program of any block file operation in the blockchain directory through the inter-process communication mechanism. After the monitoring service program detects the modification operation of the block file, it will exclude the operation of the blockchain client itself and the remaining operation is a non-blockchain operation. When the monitoring service program detects that there is a non-blockchain modification operation on the block file, the monitoring service program records the change information of the block file. If the blockchain client has been started, the change information recorded by the monitoring service program is sent to the blockchain client via the named pipe, so that the blockchain client can receive the change information through the operation entry and restore the block file according to the change information.

2. The method according to claim 1, characterized in that, The creation of the monitoring service program on the computer device includes: The following functions assign values ​​to two fields of the SERVICE_TABLE_ENTRY dispatch table structure: SERVICE_TABLE_ENTRY ServiceTable[]; ServiceTable[0].lpServiceName = "The name of the service"; ServiceTable[0].lpServiceProc = ServiceMain; Wherein, the first field ServiceTable[0].lpServiceName is the name of the monitoring service program, and the second field ServiceTable[0].lpServiceProc is a pointer to the entry function of the monitoring service program; The monitoring service program is created by calling the system function StartServiceCtrlDispatcher(ServiceTable), which is used to register the entry function of the monitoring service program.

3. The method according to claim 1, characterized in that, The function of setting the monitoring of block files under the blockchain directory in the monitoring service program includes: The storage path handle of the block file is obtained through the system function CreateFile; A storage structure is created using the function FILE_NOTIFY_INFORMATION *pFileNotifyInfo. This storage structure is used to store change information of block files under the blockchain directory. The format of the storage structure is FILE_NOTIFY_INFORMATION. The blockchain directory is monitored by the function ReadDirectoryChangesW to identify modified block files. The name of the modified block file is obtained by the function pFileNotifyInfo->FileName. Then, the change type of the modified block file is determined by the switch function, and the change information of the modified block file is stored in the storage structure. The change type includes deleting files, adding files, modifying files, and renaming files.

4. The method according to claim 1, characterized in that, The step of establishing a named pipe between the monitoring service program and the blockchain client based on the storage path of the block file, the name of the blockchain client, and the name of the monitoring service program includes: Multiple fast string hash functions are used to calculate the path where the block file is stored to obtain multiple hash results, and the multiple hash results are concatenated to obtain a concatenated hash value. Each hash result is a 4-byte integer. The named pipe is created using the following function: Pipe_name = fasthash(path) + block + blockservice; Wherein, Pipe_name is used to represent the name of the named pipe, fasthash(path) is used to represent the concatenated hash value, block is used to represent the name of the blockchain client, and blockservice is used to represent the name of the monitoring service program.

5. The method according to claim 1, characterized in that, The encapsulated entry point for reading and writing block files in the blockchain client includes: Set up a write interface function `Void virtual Write(string name1, char* buff1, uint64size1)`, where `name1` represents the filename to be written, `buff1` represents the data buffer to be written, `size1` represents the file size to be written, and the write interface function is used to write to a block file. The function `Void virtual Read(string name2, char* buff2, uint64size2)` is set up, where `name2` represents the filename to be read, `buff2` represents the data storage area to be read, and `size2` represents the file size to be read. This function is used to read block files.

6. The method according to claim 1, characterized in that, The method further includes: An independent data area is set up in the blockchain, which is used to store the unique identification information of each computer device and the corresponding block data. If the blockchain client is not started, the monitoring service program associates the change information with the unique identification information of the computer device and stores it in the independent data area, so that the monitoring service program can obtain the change information from the blockchain based on the unique identification information of the computer device after it is started.

7. The method according to claim 6, characterized in that, The method further includes: The computer device receives the user's request to uninstall the blockchain client; In response to the uninstallation request, the blockchain client is uninstalled, and the attribute of the blockchain directory is set to hidden. If the blockchain client needs to be reinstalled on the computer device, the attributes of the blockchain directory should be changed to non-hidden attributes.

8. A recovery device, characterized in that, include: A creation unit is used to create a monitoring service program on a computer device and set the function of monitoring block files under the blockchain directory in the monitoring service program. The monitoring service program starts automatically when the computer device is started. The blockchain directory is a directory generated when a blockchain client is installed on the computer device. A naming pipe is established between the monitoring service program and the blockchain client based on the path where the block file is stored, the name of the blockchain client, and the name of the monitoring service program. The encapsulation unit is used to encapsulate the operation entry point in the blockchain client for reading and writing block files; In a blockchain program, file read and write operations are hooked when the program starts. The hook function is aware of all file operations. After the file operation is detected, it first determines whether the file being operated on is a block file. If it is, it continues to check its call stack information to see if it is consistent with the encapsulated interface. If it is consistent, it means that the unified encapsulated interface is being called. Otherwise, it means that the developer has misused the read and write operation, and the operation is returned as a failure. The blockchain client will notify the monitoring service program of any block file operation in the blockchain directory through the inter-process communication mechanism. After the monitoring service program detects the modification operation of the block file, it will exclude the operation of the blockchain client itself and the remaining operation is a non-blockchain operation. A recording unit is used to record the change information of the block file when the monitoring service program detects that there is a non-blockchain modification operation on the block file; The transceiver unit is used to send the change information recorded by the monitoring service program to the blockchain client via the named pipe if the blockchain client has been started, so that the blockchain client can receive the change information through the operation entry and restore the block file according to the change information.

9. An electronic device, comprising a memory and a processor, characterized in that, When the processor is used to execute a computer management program stored in memory, it implements the steps of the method for recovering blockchain data as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer management programs thereon, characterized in that: When the computer management program is executed by the processor, it implements the steps of the method for recovering blockchain data as described in any one of claims 1 to 7.

Images