CN111444216A - Data block deleting method based on centralized block chain type account book - Google Patents

Abstract

A data block deleting method based on a centralized block chain type account book is disclosed. When any user wants to delete historical data which is submitted to the centralized block chain type account book before the user, a block deletion request can be sent to the database server side, and the database server side is requested to delete the database containing the historical data specified by the user from the centralized block chain type account book. Because there is coupling between the data blocks adjacent to each other in the ledger, the data blocks are usually deleted from the created data block in sequence, and after deletion, the created data block needs to be regenerated to keep the block hash of the ledger configuration information and the last deleted data block. In addition, considering that the data block includes not only the history data submitted by the user, but also the history data submitted by other users, the deletion operation can be performed after the signature confirmation of each user involved in the data block to be deleted is collected.

Description

A data block deletion method based on a centralized blockchain ledger

technical field

The embodiments of this specification relate to the field of information technology, and in particular, to a method for deleting data blocks based on a centralized blockchain ledger.

Background technique

The centralized blockchain ledger, which is different from the decentralized blockchain ledger (such as the blockchain that is distributed and maintained by each node in the blockchain network), refers to the local database maintained by the centralized database server. Sometimes, the centralized blockchain ledger is also referred to as the Ledger Data Base (Ledger DB).

The centralized blockchain ledger is a new storage solution improved on the basis of the blockchain storage solution, which can overcome the problems of low throughput and long response time of blockchain storage. The service object of the centralized blockchain ledger is usually enterprise-level users. Users generally register an account on the database server, and encapsulate the business data generated by their own business into business transactions through the account, and submit the business transaction to the database server. The database service Based on a certain block-forming strategy, the terminal packages several business transactions into data blocks and writes them to the centralized block chain ledger for storage.

In the centralized block chain ledger, similar to the traditional block chain, the data blocks are linked in sequence according to the block time sequence, and each data block carries the root of the Merkle tree composed of the business transactions in the data block. Hash value, in addition, the block header of the next data block carries the block hash of the previous data block (that is, the hash value obtained by hashing the block header), thus ensuring business transactions in the centralized block chain ledger cannot be easily tampered with. It should also be noted that the data block with serial number 1 (ie the first database) in the centralized blockchain ledger is the creation data block, which generally carries the configuration information of the centralized blockchain ledger (such as the creation time of the ledger). , account book maintainer information, account book validity period, etc.).

In practical applications, sometimes users want to delete their business data that has been generated for too long from the centralized blockchain ledger, thereby saving the storage fee that needs to be paid to the database server. To this end, a data block deletion method based on a centralized blockchain ledger is required.

SUMMARY OF THE INVENTION

The embodiments of the present application are proposed to solve the technical problem that the existing centralized blockchain ledger does not support deleting the database.

In order to solve the above-mentioned technical problems, the embodiments of the present application are implemented as follows:

According to the first aspect of the embodiments of this specification, a method for deleting data blocks based on a centralized block chain ledger is provided, which is applied to a database server, where the database server maintains a centralized block chain ledger, and the method includes: :

Receive block delete requests sent by any user account;

Determine the set of data blocks to be deleted specified by the block deletion request; the set of data blocks to be deleted includes N data blocks to be deleted with sequence numbers from 1 to N, and N>1;

According to each transaction corresponding to the set of data blocks to be deleted, determine the relevant at least one other user account;

Obtain the signature generated by the user account for the block deletion request; and obtain the signature generated by each other user account for the block deletion request;

After it is determined that all signatures are obtained, the set of data blocks to be deleted is deleted from the centralized blockchain ledger, and the creation data block is regenerated; wherein, the regenerated creation data block contains the original creation data block carrying The ledger configuration information of , and the block hash corresponding to the Nth data block to be deleted.

According to a second aspect of the embodiments of this specification, a data block deletion device based on a centralized blockchain ledger is provided, which is applied to a database server, where the database server maintains a centralized blockchain ledger, and the device includes :

The receiving module receives the block deletion request sent by any user account;

a first determining module, which determines a set of data blocks to be deleted specified by the block deletion request; the set of data blocks to be deleted includes N data blocks to be deleted with sequence numbers from 1 to N, and N>1;

The second determination module, according to each transaction corresponding to the set of data blocks to be deleted, determines the relevant at least one other user account;

acquiring module, acquiring the signature generated by the user account for the block deletion request; and acquiring the signature generated by each other user account for the block deletion request;

The deletion module, after confirming that all signatures are obtained, deletes the set of data blocks to be deleted from the centralized block chain ledger, and regenerates the creation data block; wherein, the regenerated creation data block contains the original creation data block. The ledger configuration information carried by the data block and the block hash corresponding to the Nth data block to be deleted.

Through the solution provided in the embodiments of this specification, when any user wants to delete the historical data submitted to the centralized blockchain ledger, he can send a block deletion request to the database server, requesting the database server to delete the data from the centralized blockchain The database containing the historical data specified by the user is deleted from the ledger. Due to the coupling between the adjacent data blocks in the ledger, it is usually necessary to delete the genesis data block in sequence and backwards. Remove the block hash of the data block. In addition, considering that the data block includes not only the historical data submitted by the user, but also the historical data submitted by other users, the deletion operation can only be performed after the signature confirmation of each user involved in the data block to be deleted needs to be collected. .

Through the embodiments of this specification, it is possible to delete historical data blocks from the centralized blockchain ledger without destroying the availability of the centralized blockchain ledger.

It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not limiting of the embodiments of the present specification.

In addition, any one of the embodiments of the present specification does not need to achieve all the above effects.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, the following briefly introduces the accompanying drawings required in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some of the embodiments described in the embodiments of the present specification. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings.

Figure 1 is a schematic diagram of a data storage system based on a centralized block chain ledger provided in this specification;

2 is a schematic flowchart of a method for deleting data blocks based on a centralized block chain ledger provided by an embodiment of this specification;

3 is a schematic flowchart of another method for deleting data blocks based on a centralized block chain ledger provided in this specification;

4 is a schematic structural diagram of a data block deletion device based on a centralized block chain ledger provided by an embodiment of this specification;

FIG. 5 is a schematic structural diagram of a device for configuring a method according to an embodiment of the present specification.

Detailed ways

Figure 1 is a schematic diagram of a data storage system based on a centralized block chain ledger provided in this specification. As shown in Figure 1, the data storage system includes a centralized database server and multiple clients. Among them, the database server is responsible for maintaining the centralized blockchain ledger, each client corresponds to an enterprise-level user (organization), and each enterprise-level user is further connected to one or more individual users.

For example, the takeaway platform and the e-commerce platform respectively register on the database server as users to obtain user accounts, and install the client provided by the database server on their own devices respectively, and log in to the user account in the client, thereby having The ability to interact with the database server.

The takeaway platform and the e-commerce platform are connected to their respective large numbers of individual users. After an individual user purchases a take-out food using the take-out client installed on his mobile phone, the device of the take-out platform will generate a take-out order record (that is, the business data generated by the take-out platform based on the business). The user account registered on the server encapsulates the order record into a transaction (similar to the blockchain, the transaction described in this article is a special data structure suitable for centralized blockchain ledger storage), and submits the transaction to the database server so that the database can The server encapsulates the transaction into the database and writes it to the centralized blockchain ledger for storage. Similarly, the e-commerce platform will encapsulate each e-commerce order generated based on the e-commerce business into a transaction and submit it to the database server.

For the convenience of description, the user mentioned later refers to the enterprise-level user served by the database server, and the user account mentioned later refers to the account registered by the enterprise-level user on the database server.

Usually, the order of transactions submitted by a user to the database server reflects the order in which the business data encapsulated by the exchange is generated, and the database server can prioritize the transactions received earlier according to the order of transactions submitted by the same user. Data block encapsulation is performed, so that in the centralized blockchain ledger, for several transactions submitted by the same user, the transaction encapsulated in the front data block is often generated earlier than the transaction encapsulated in the later database. generation time.

Therefore, if a user wants to delete transactions that have been generated for too long (the business data encapsulated by these historical transactions is often of no use value) from the centralized blockchain ledger for the sake of saving storage costs, it is quite At the requesting database server, each data block encapsulated with these historical transactions will be deleted.

It should be noted that, on the one hand, for each data block in the centralized blockchain ledger, the block header of the data block usually contains the root hash of the Merkle tree composed of all transactions in the block (used to ensure this All transactions in the data block cannot be tampered with), once any transaction in the data block is deleted, the data block will lose its significance. The transactions contained in each data block are not only from the same user. Therefore, even if a user only requests to delete the historical transactions submitted by himself, the data block server can only choose to delete all historical transactions involving these historical transactions at the operational level. The data block is deleted.

It should also be noted that there is coupling between successively adjacent data blocks in the centralized blockchain ledger, and the block header of the next data block carries the hash value corresponding to the block header of the previous data block. The multiple historical transactions requested to be deleted by each user only involve individual discontinuous data blocks. From the operational level, the database server can only choose to continuously delete data blocks from the genesis data block until the deletion requested by the user is realized. All historical transactions are deleted until the effect is reached.

In addition, considering that the first data block (genesis data block) in the centralized blockchain ledger often needs to carry the ledger configuration information of the centralized blockchain ledger, if the When the data block starts to delete a series of data blocks (including the deletion of the original data block), the creation data block needs to be regenerated.

The regenerated genesis data block can contain the ledger configuration information carried by the original genesis data block, as well as the block hash corresponding to the data block containing the deleted last sequence bit (Nth) (so as to be consistent with the retained N+1th data). The block hash of the Nth data block carried by the block is matched, thereby preserving the coupling between the N+1th data block and the deleted data block).

In order for those skilled in the art to better understand the technical solutions in the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described in detail below with reference to the accompanying drawings in the embodiments of the present specification. Obviously, the described implementation Examples are only some of the embodiments of the present specification, but not all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this specification should fall within the scope of protection.

The technical solutions provided by the embodiments of the present specification will be described in detail below with reference to the accompanying drawings.

2 is a schematic flowchart of a method for deleting data blocks based on a centralized block chain ledger provided by an embodiment of this specification, including the following steps:

S200: Receive a block deletion request sent by any user account.

The execution subject of the method process shown in FIG. 2 is the centralized database server.

In the embodiment of this specification, the block deletion request may not be a data structure of a transaction, but a request message sent by a client to a server based on a traditional client/server architecture. The data block server processes the block deletion request.

S202: Determine a set of data blocks to be deleted specified by the block deletion request.

The set of data blocks to be deleted specified by the block delete request can be determined in various ways. It should be emphasized that, in the method embodiment shown in FIG. 2 , no matter what method is used to determine the set of data blocks to be deleted, the set of data blocks to be deleted needs to meet the following requirements: including N pieces of data to be deleted with serial numbers from 1 to N. block, N>1.

For example, the user account may carry the set of transaction identifiers to be deleted in the block deletion request, which is used to specify which historical transactions the user account requests to delete. The data block server may, according to the set of transaction identifiers to be deleted carried in the block deletion request, add all data blocks that encapsulate a transaction corresponding to any transaction identifier in the set of transaction identifiers to be deleted to the set of data blocks to be deleted.

For another example, the user account may carry the sequence number range [1, N] of the data block to be deleted in the block deletion request, so that the database server can determine the first data block to the Nth data block as the data block to be deleted.

S204: Determine at least one other related user account according to each transaction corresponding to the set of data blocks to be deleted.

The so-called related at least one other user account refers to: for each transaction corresponding to the set of data blocks to be deleted, the account of the owner of the data encapsulated by the exchange (that is, the user who submitted the transaction to the database server before), is It belongs to the relevant user account; and the relevant user account other than the user account that sends the block delete request is called the relevant other user account.

S206: Acquire a signature generated by the user account for the block deletion request; and acquire a signature generated by each other user account for the block deletion request.

Generally speaking, when the user account sends a block deletion request to the database server, it also sends the signature generated for the block deletion request to the database server. The database server can verify the signature provided by the user account, and after the verification is passed, it can be determined that the signature generated by the user account for the block deletion request is obtained.

Further, the database server may determine the set of data blocks to be deleted specified by the block deletion request after determining to obtain the signature generated by the user account for the block deletion request.

In the embodiment of this specification, the database server may, for each other user account determined, send a query message to the other user account, to inquire whether the other user account allows the block deletion request, if the other user account If the account agrees to delete these data blocks to be deleted, the signature for the block deletion request can be returned to the database server. Of course, the database server needs to verify and pass each signature received before it can determine that the signature of each other user account has been obtained.

In addition, in the embodiment of this specification, the database server may also be configured with M accounts of the administrator, where M is greater than 0. Deleting a centralized blockchain ledger may also require permission from a certain number of administrator accounts. Therefore, before it is determined that all the signatures are obtained, the signature generated by at least one manager account corresponding to the centralized blockchain ledger for the block deletion request can be obtained.

The number of signatures of the manager account to be acquired may be equal to M or less than M, and may be set according to actual needs.

S208: After it is determined that all signatures are obtained, delete the set of data blocks to be deleted from the centralized block chain ledger, and regenerate the genesis data block.

In the embodiment of this specification, acquiring all the signatures means not only acquiring the signatures of the user account, but also acquiring the signatures of each other user account.

Before deleting the data block, the data block server can first perform integrity verification on the 1-N data blocks to be deleted (that is, through the method of re-examination transaction, the 1-Nth data block is deduced again to ensure that the internal The coupling of each transaction and the coupling between data blocks), and then delete it after confirming that it is correct.

The regenerated genesis data block contains the ledger configuration information carried by the original genesis data block and the block hash corresponding to the Nth data block to be deleted. The original data block refers to the deleted data block with sequence number 1.

It should be noted here that the ledger configuration information may refer to any information related to the ledger configuration. For example, a ledger creation transaction for creating a ledger contains information such as the ledger creation time and the ledger creator ID. The block hash corresponding to the data block generally refers to the hash value obtained by hashing the block header of the data block.

In this embodiment of the present specification, the regenerated genesis data block may be stored to the storage location where the deleted Nth data block is originally located (ie, before being spliced to the N+1th data block).

Through the solution provided in the embodiments of this specification, when any user wants to delete the historical data submitted to the centralized blockchain ledger, he can send a block deletion request to the database server, requesting the database server to delete the data from the centralized blockchain The database containing the historical data specified by the user is deleted from the ledger. Due to the coupling between the adjacent data blocks in the ledger, it is usually necessary to delete the genesis data block in sequence and backwards. Remove the block hash of the data block. In addition, considering that the data block includes not only the historical data submitted by the user, but also the historical data submitted by other users, the deletion operation can only be performed after the signature confirmation of each user involved in the data block to be deleted needs to be collected. .

Through the embodiments of this specification, it is possible to delete historical data blocks from the centralized blockchain ledger without destroying the availability of the centralized blockchain ledger.

In addition, in the embodiment of this specification, the block deletion request may specifically be a data structure of a block deletion transaction. In this way, the database server also needs to write the block deletion transaction into the centralized blockchain ledger. Further, the storage location information of the block deletion transaction in the centralized blockchain ledger can also be written into the regenerated genesis data block (specifically, the block header is written), so that according to the regenerated genesis data block You can locate the corresponding block deletion transaction for review.

The block deletion transaction can carry the following information: the identity of the user account requesting to delete the data block, the request time, the range of the data block requested to be deleted, etc.

The storage location of the transaction in the centralized blockchain ledger can specifically refer to the serial number (or block height) of the data block where the transaction is located and the specific location of the transaction in the data block (that is, the offset offset).

In addition, in the embodiment of this specification, the block deletion transaction and all the obtained signatures can be written into the centralized block chain ledger in an associated form, so that the authorization records of all parties are also stored as evidence.

In addition, in the embodiment of this specification, the block hash corresponding to the regenerated genesis data block can be written into the transaction log corresponding to the block deletion transaction, and the block deletion transaction and the corresponding transaction log can be written into the centralized block together Chained ledger. In this case, the regenerated genesis data block does not need to be spliced before the N+1th data block, but is stored separately, and the regenerated genesis data block can be queried according to the transaction log.

In addition, in the centralized blockchain ledger scenario, each user account can have a corresponding state. For example, the permissions of each user account may change frequently, and each change means that the state corresponding to the user account changes. For another example, each user account may have a fund balance, and the user account needs to consume the balance to initiate a transaction. In this way, the state of the fund balance corresponding to the user account will also change.

The set of state information corresponding to all user accounts is called the world state. Each database in the ledger corresponds to a world state.

In the centralized blockchain ledger scenario, the status information corresponding to each user account is usually not specifically recorded. When the centralized blockchain ledger is complete, the first data block can be traced through the ledger. Review the transaction and deduce the world state corresponding to each data block.

In the method flow shown in Figure 2, if the 1st-Nth data blocks are deleted, it means that the world states corresponding to the 1st-Nth data blocks cannot be deduced by means of re-examination transactions. To this end, the world state information corresponding to the 1st to the Nth data blocks can be written into the regenerated genesis data block, thereby realizing the retention of the world state information. Alternatively, only the world state information corresponding to the Nth data block can be written into the regenerated genesis data block, so as to prove the world state of the first N data blocks deleted and the world state of the N+1th data block Coupling, not tampered with.

Figure 3 is a schematic flowchart of another method for deleting data blocks based on a centralized block chain ledger provided in this specification, including the following steps:

S300: Receive a block deletion request sent by any user account.

S302: Determine the set of data blocks to be deleted specified by the block deletion request.

The to-be-deleted data block set includes N to-be-deleted data blocks with sequence numbers from 2 to N, where N≥2;

S304: Determine at least one other related user account according to each transaction corresponding to the set of data blocks to be deleted.

S306: Acquire a signature generated by the user account for the block deletion request; and acquire a signature generated by each other user account for the block deletion request.

S308: After it is determined that all signatures are obtained, delete the set of data blocks to be deleted from the centralized block chain ledger, and generate a flag data block.

The marked data block may include a block hash corresponding to the Nth data block to be deleted and a pointer object for pointing to the creation data block. In addition, the flag data block may also contain the storage location information of the block deletion transaction in the centralized block chain ledger and/or the world state information corresponding to the deleted Nth data block (or the corresponding data blocks 1-N respectively). state of the world).

Obviously, the main difference between the method flow shown in Figure 3 and the method flow shown in Figure 2 is that the genesis data block will not be deleted, so the genesis data block does not need to be regenerated, but the identification data block needs to be generated separately , which needs to be associated with the genesis data block so that the ledger configuration information in the genesis data block can be associated.

4 is a schematic structural diagram of a data block deletion device based on a centralized block chain ledger provided by an embodiment of this specification, applied to a database server, the database server maintains a centralized block chain ledger, and the device include:

Receiving module 401, receiving a block deletion request sent by any user account;

The first determination module 402 determines the set of data blocks to be deleted specified by the block deletion request; the set of data blocks to be deleted includes N data blocks to be deleted with sequence numbers from 1 to N, where N>1;

The second determination module 403, according to each transaction corresponding to the set of data blocks to be deleted, determines at least one other related user account;

Obtaining module 404, obtains the signature generated by the user account for the block deletion request; and obtains the signature generated by each other user account for the block deletion request;

The deletion module 405, after determining that all signatures have been obtained, deletes the set of data blocks to be deleted from the centralized block chain ledger, and regenerates the creation data block; wherein, the regenerated creation data block contains original The ledger configuration information carried by the world data block and the block hash corresponding to the Nth data block to be deleted.

The first determining module 402 determines the set of data blocks to be deleted according to the set of transaction identifiers to be deleted carried in the block deletion request; or according to the range of sequence numbers of the data blocks to be deleted carried in the block deletion request [1, N], N>1, determine the set of data blocks to be deleted.

The first determining module 402, after acquiring the signature generated by the user account for the block deletion request, determines the set of data blocks to be deleted specified by the block deletion request.

The obtaining module 404, for each other user account determined, sends an inquiry message to the other user account for inquiring whether the other user account allows the block deletion request; and receives the signature returned by the other user account.

The block deletion request includes: a block deletion transaction constructed by the user account;

The device further includes: a writing module 406, which writes the block deletion transaction into the centralized block chain ledger; and writes the storage location information of the block deletion transaction in the centralized block chain ledger to regenerate genesis data block.

The writing module 406 writes the block deletion transaction and all the obtained signatures into the centralized block chain ledger in an associated form.

The obtaining module 404 obtains the signature generated by at least one manager account corresponding to the centralized block chain ledger for the block deletion request before determining that all the signatures have been obtained.

Embodiments of the present specification further provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the program shown in FIG. 2 or 3 when executing the program. method.

FIG. 5 shows a schematic diagram of a more specific hardware structure of a computing device provided by an embodiment of this specification. The device may include: a processor 1010 , a memory 1020 , an input/output interface 1030 , a communication interface 1040 and a bus 1050 . The processor 1010 , the memory 1020 , the input/output interface 1030 and the communication interface 1040 realize the communication connection among each other within the device through the bus 1050 .

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit, central processing unit), a microprocessor, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, and is used to execute related program to implement the technical solutions provided by the embodiments of this specification.

The memory 1020 may be implemented in the form of a ROM (Read Only Memory, read only memory), a RAM (Random Access Memory, random access memory), a static storage device, a dynamic storage device, and the like. The memory 1020 may store an operating system and other application programs. When implementing the technical solutions provided by the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1020 and invoked by the processor 1010 for execution.

The input/output interface 1030 is used to connect the input/output module to realize information input and output. The input/output/module can be configured in the device as a component (not shown in the figure), or can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, and the like.

The communication interface 1040 is used to connect a communication module (not shown in the figure), so as to realize the communication interaction between the device and other devices. The communication module can implement communication through wired means (such as USB, network cable, etc.), or can implement communication through wireless means (such as mobile network, WIFI, Bluetooth, etc.).

The bus 1050 includes a path to transfer information between the various components of the device (eg, the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040).

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include necessary components for normal operation. other components. In addition, those skilled in the art can understand that, the above-mentioned device may only include components necessary to implement the solutions of the embodiments of the present specification, rather than all the components shown in the figures.

Embodiments of the present specification further provide a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, implements the method shown in FIG. 2 or FIG. 3 .

Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology. Information may be computer readable instructions, data structures, modules of programs, 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 tape cartridges, magnetic tape disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

From the description of the above embodiments, those skilled in the art can clearly understand that the embodiments of the present specification can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of this specification or the parts that make contributions to the prior art may be embodied in the form of software products, and the computer software products may be stored in storage media, such as ROM/RAM, A magnetic disk, an optical disc, etc., includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments in this specification.

The systems, methods, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.

Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the method embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the partial description of the method embodiment. The method embodiments described above are only illustrative, and the modules described as separate components may or may not be physically separated. When implementing the solutions of the embodiments of this specification, the functions of each module may be integrated into the same module. or multiple software and/or hardware implementations. Some or all of the modules may also be selected according to actual needs to achieve the purpose of the solution in this embodiment. Those of ordinary skill in the art can understand and implement it without creative effort.

The above are only specific implementations of the embodiments of the present specification. It should be pointed out that for those skilled in the art, without departing from the principles of the embodiments of the present specification, several improvements and modifications can be made. These Improvements and modifications should also be regarded as the protection scope of the embodiments of the present specification.

Claims (15)

1. A method for deleting data blocks based on a centralized block-chain ledger, applied to a database server that maintains a centralized block-chain ledger, the method comprising: Receive block delete requests sent by any user account; Determine the set of data blocks to be deleted specified by the block deletion request; the set of data blocks to be deleted includes N data blocks to be deleted with sequence numbers from 1 to N, and N>1; According to each transaction corresponding to the set of data blocks to be deleted, determine the relevant at least one other user account; Obtain the signature generated by the user account for the block deletion request; and obtain the signature generated by each other user account for the block deletion request; After it is determined that all signatures are obtained, the set of data blocks to be deleted is deleted from the centralized blockchain ledger, and the creation data block is regenerated; wherein, the regenerated creation data block contains the original creation data block carrying The ledger configuration information of , and the block hash corresponding to the Nth data block to be deleted. 2. The method according to claim 1, the sequence number range of the data block to be deleted specified according to the block deletion request, comprising: Determine the set of data blocks to be deleted according to the set of transaction identifiers to be deleted carried in the block deletion request; or The set of data blocks to be deleted is determined according to the sequence number range [1, N] of the data blocks to be deleted carried in the block deletion request. 3. The method of claim 1, determining the set of data blocks to be deleted specified by the block deletion request, comprising: After obtaining the signature generated by the user account for the block deletion request, determine the set of data blocks to be deleted specified by the block deletion request. 4. The method of claim 1, obtaining the signature that each other user account generates for the block deletion request, comprising: For each other user account determined, send an inquiry message to the other user account for inquiring whether the other user account permits the block deletion request; Receive the signature returned by this other user account. 5. The method of claim 1, wherein the block deletion request comprises: a block deletion transaction constructed by the user account; The method also includes: Writing the block deletion transaction into the centralized block chain ledger; and writing the storage location information of the block deletion transaction in the centralized block chain ledger into the regenerated genesis data block. 6. The method of claim 5, writing the block deletion transaction to a centralized blockchain ledger, comprising: The block deletion transaction and all the obtained signatures are written into the centralized block chain ledger in an associated form. 7. The method of claim 1, before determining that all signatures are obtained, the method further comprises: Obtain the signature generated by at least one manager account corresponding to the centralized blockchain ledger for the block deletion request. 8. A data block deletion device based on a centralized block chain ledger, applied to a database server that maintains a centralized block chain ledger, the device comprising: The receiving module receives the block deletion request sent by any user account; a first determining module, which determines a set of data blocks to be deleted specified by the block deletion request; the set of data blocks to be deleted includes N data blocks to be deleted with sequence numbers from 1 to N, and N>1; The second determination module, according to each transaction corresponding to the set of data blocks to be deleted, determines the relevant at least one other user account; acquiring module, acquiring the signature generated by the user account for the block deletion request; and acquiring the signature generated by each other user account for the block deletion request; The deletion module, after confirming that all signatures are obtained, deletes the set of data blocks to be deleted from the centralized block chain ledger, and regenerates the creation data block; wherein, the regenerated creation data block contains the original creation data block. The ledger configuration information carried by the data block and the block hash corresponding to the Nth data block to be deleted. 9. The apparatus according to claim 8, wherein the first determination module determines the set of data blocks to be deleted according to the set of transaction identifiers to be deleted carried in the block deletion request; or according to the set of data blocks to be deleted carried in the block deletion request The range of the sequence numbers of the data blocks to be deleted is [1, N], where N>1, which determines the set of data blocks to be deleted. 10 . The apparatus according to claim 8 , wherein the first determining module determines a set of data blocks to be deleted specified by the block deletion request after acquiring the signature generated by the user account for the block deletion request. 11 . 11. The apparatus of claim 8, wherein the acquisition module, for each other user account determined, sends an inquiry message to the other user account for inquiring whether the other user account allows the block deletion request ; Receive the signature returned by this other user account. 12. The apparatus of claim 8, the block deletion request comprising: a block deletion transaction constructed by the user account; The device further includes: a writing module, which writes the block deletion transaction into the centralized block chain ledger; and writes the storage location information of the block deletion transaction in the centralized block chain ledger into a regenerated one. Genesis data block. 13. The apparatus according to claim 12, wherein the writing module writes the block deletion transaction and all the obtained signatures into the centralized block chain ledger in an associated form. 14. The apparatus according to claim 8, wherein the acquisition module, before determining that all the signatures are acquired, acquires the signature generated by at least one manager account corresponding to the centralized block chain ledger for the block deletion request. 15. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the program as claimed in any one of claims 1 to 7 when the processor executes the program. method described.

Images