CN112632055A - Business record deleting method based on credible account book database - Google Patents
Business record deleting method based on credible account book database Download PDFInfo
- Publication number
- CN112632055A CN112632055A CN202110033646.XA CN202110033646A CN112632055A CN 112632055 A CN112632055 A CN 112632055A CN 202110033646 A CN202110033646 A CN 202110033646A CN 112632055 A CN112632055 A CN 112632055A
- Authority
- CN
- China
- Prior art keywords
- record
- data block
- database
- business
- account book
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/219—Managing data history or versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2246—Trees, e.g. B+trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Abstract
The application discloses a business record deleting method based on a credible account book database. When a user wants to delete some unimportant business records submitted to the trusted account book database before the user wants to delete the unimportant business records, the user can send a business record deletion request to the database server side to request the database server side to delete the unimportant historical business records from the trusted account book database. Because there is coupling between the data blocks adjacent to each other in the trusted ledger database, the data blocks are usually deleted from the created ledger data block in sequence, and after deletion, the created ledger data block needs to be regenerated so as to retain block hash between the ledger configuration information and the last deleted data block.
Description
Technical Field
The embodiment of the specification relates to the technical field of information, in particular to a business record deleting method based on a trusted account book database.
Background
The credible account book database is a novel storage scheme obtained by improvement on the basis of a block chain storage scheme, can overcome the problems of low throughput, long response time and the like of decentralized block chain storage, and can meet the credible storage requirement of a user on data.
The credible account book database is maintained locally by a centralized database server, the service object of the credible account book database is usually an enterprise-level user, the user registers an account at the database server, the business data generated by the self business is encapsulated into business records through the registered account, the business records are submitted to the database server, and after the database server receives the business records, the received business records are written into the local credible account book database for storage.
In the trusted account book database, that is, according to a certain blocking condition, received business records are packed into individual data blocks according to batches, each data block calculates a root hash of a tacler tree based on all the business records encapsulated in the block, the root hash is written into a block header of the data block, and the block header of a next data block contains a hash value of a previous data block (that is, a hash value obtained by performing hash calculation on the block header). In this case, the trusted account book database actually belongs to a block chain type account book, and it can be ensured that it is difficult to tamper with part of business records in the trusted account book database. It should be further noted that the data block with sequence number 1 in the trusted account book database (i.e. the first database) is a creation data block, and configuration information of the trusted account book database (e.g. account book creation time, account book maintenance party information, and account book validity period) is generally carried in the data block.
In practical application, sometimes a user wants to delete some unimportant business records which are owned and generated too long from the trusted account book database, so as to save storage cost required to be paid to a database server. Therefore, a service record deleting method based on the credible ledger database is needed.
Disclosure of Invention
The embodiment of the application is provided for solving the technical problem that the existing credible account book database does not support database deletion.
In order to solve the above technical problem, the embodiment of the present application is implemented as follows:
according to the 1 st aspect of the embodiments of the present specification, there is provided a method for deleting business records based on a trusted account book database, which is applied to a database server, where the database server maintains the trusted account book database and other trusted account book databases;
the method comprises the following steps:
receiving a service record deleting request sent by user equipment;
determining a data block set to be deleted and an important service record set to be reserved according to the service record deletion request; the data block set to be deleted comprises N data blocks to be deleted, wherein the serial numbers of the N data blocks to be deleted are from 1 to N, and N is more than 1;
according to the sequence of all important business records in the credible account book database, sequentially storing each important business record in the important business record set into other credible account book databases from first to last;
after the important business record set is saved, deleting the data block set to be deleted from the credible account book database, and regenerating the created data blocks; and the newly generated created data block comprises the account book configuration information carried by the original created data block and the block hash corresponding to the Nth data block to be deleted.
According to the 2 nd aspect of the embodiments of the present specification, there is provided a method for verifying existence of an important service record, which is applied to a user equipment, the method including:
acquiring an important service record to be verified from a database server side, and calculating the record hash of the important service record;
sending the record hash of the important record to a database server, and receiving a global Merck tree path corresponding to the record hash returned by the database server;
calculating the root hash of the global Mercker tree based on the record hash of the important record and the global Mercker tree path;
and comparing the calculated root hash with the stored root hash, and if the root hash is consistent with the stored root hash, determining that the important business record passes the existence verification.
Through the scheme provided in the embodiment of the description, when a user wants to delete some unimportant business records submitted to the trusted account book database before the user wants to delete the unimportant business records, the user can send a business record deletion request to the database server side to request the database server side to delete the unimportant historical business records from the trusted account book database. Because there is coupling between the data blocks adjacent to each other in the trusted ledger database, the data blocks are usually deleted from the created ledger data block in sequence, and after deletion, the created ledger data block needs to be regenerated so as to retain block hash between the ledger configuration information and the last deleted data block. In addition, important business records in the deleted data block need to be saved in other trusted account book databases. In this way, the important business records stored separately are not in the original trusted account book database, but are still trusted for the user.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of embodiments of the invention.
In addition, any one of the embodiments in the present specification is not required to achieve all of the effects described above.
Drawings
In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present specification, and other drawings can be obtained by those skilled in the art according to the drawings.
FIG. 1 is a schematic diagram of a trusted ledger database-based data storage system provided herein;
fig. 2 is a schematic flowchart of a method for deleting business records based on a trusted ledger database according to an embodiment of the present specification;
FIG. 3 is a flow chart of a method for verifying the existence of important business records provided in the present specification;
fig. 4 is a schematic structural diagram of a business record deleting device based on a trusted ledger database according to an embodiment of the present specification;
fig. 5 is a schematic structural diagram of an important service record presence verification apparatus provided in the present specification;
fig. 6 is a schematic structural diagram of a service record integrity verification apparatus provided in this specification;
fig. 7 is a schematic diagram of a device for configuring the method of the embodiments of the present description.
Detailed Description
Fig. 1 is a schematic diagram of a data storage system based on a trusted ledger database provided in the present specification. As shown in fig. 1, the data storage system includes a centralized database server and a plurality of clients. The database server is responsible for maintaining a trusted account book database, each client corresponds to an enterprise-level user (organization), such as an enterprise-level user a, an enterprise-level user B, and an enterprise-level user C, and each enterprise-level user further connects with one or more individual users, such as an individual user a, an individual user B, an individual user C, and an individual user d.
For example, the takeout platform and the e-commerce platform are respectively used as users to register on the database server to obtain user accounts, and install clients provided by the database server on own equipment to log in the user accounts in the clients, so that the takeout platform and the e-commerce platform have the capability of performing data interaction with the database server.
The take-out platform and the electronic commodity platform are respectively connected with a large number of individual users. After a certain individual user purchases a takeout food by using a takeout client installed on a mobile phone, equipment of a takeout platform generates a takeout order record (namely business data generated by the takeout platform based on business), the takeout platform encapsulates the order record into a record (similar to a business record in the field of block chains, wherein the record is a special data structure suitable for storing a credible account book database) through a user account registered at a database server by the takeout platform, and submits the record to the database server so that the database server encapsulates the record into the record and writes the record into the credible account book database for storage. Similarly, the e-commerce platform encapsulates each e-commerce order generated based on the e-commerce business into a record and submits the record to the database server.
For convenience of description, the user described hereinafter refers to an enterprise-level user served by the database server, and the user account described hereinafter refers to an account registered by the enterprise-level user at the database server.
Generally, the sequence of business records submitted to a database server by a user reflects the sequence of business data generated by recording the encapsulated business data, and the database server can store all the business records into a credible account book database in sequence according to the sequence of the business records submitted by the same user.
Therefore, if a user wants to delete a business record generated too long (the business data packaged by the historical business records often has no use value) from the trusted account book database in order to save storage cost, the user equivalently requests the database server to delete each data block packaged with the historical business records.
It should be noted that, for each data block in the trusted account book database, the block header of the data block usually contains the root hash of the merkel tree formed by all the business records in the block (for ensuring that all the business records in the data block cannot be tampered), and once any business record in the data block is deleted, the data block loses the meaning of evidence storage.
It should be further noted that, there is a coupling property between consecutive and adjacent data blocks in the trusted account book database, and the block head of the subsequent data block carries the hash value corresponding to the block head of the previous data block, so that even if a plurality of historical service records requested to be deleted by a certain user only relate to individual and discontinuous data blocks, the database server can only select to continuously delete data blocks backwards from the created data block from the operational aspect until the effect of deleting all historical service records requested to be deleted by the user from the trusted account book database is achieved.
In addition, considering that the 1 st data block (created data block) in the trusted ledger database needs to carry ledger configuration information of the trusted ledger database, if a string of data blocks is deleted from the created data block from the trusted ledger database (including deleting the original created data block), the created data block needs to be regenerated.
The regenerated created data block may contain the ledger configuration information carried by the original created data block, and a block hash corresponding to the data block containing the last ordinal (nth) of the deletion (so as to match the block hash of the nth data block carried by the retained (N + 1) th data block, thereby retaining the coupling between the (N + 1) th data block and the deleted data block).
In addition, for some historical important business records (referred to as important business records, important standards can be determined by users, for example, business records related to large transaction amount can be regarded as important business records), the users do not want to delete the important business records, but because the business records in the credible ledger database are packaged into data blocks and stored in time sequence, if some unimportant business records are deleted, the important business records in the same data block have to be deleted from the credible ledger database.
For this reason, in one or more embodiments of the present specification, the set of important business records is separately saved before deleting the data block (because of the chronological order of the business records in the trusted account book database, the important business records cannot be saved back to the trusted account book database, and only can be separately saved). Meanwhile, in order to ensure the credibility of the additionally stored important business records for the user (the user worrys about that the database server side tampers the important business records), the global merkel tree of the credible ledger database can be generated before the database server side deletes the data blocks, and the root hash of the global merkel tree is returned to the user for storage. In this way, although the separately stored important business records are not in the trusted ledger database, due to the existence of the global merkel tree, the user equipment can verify whether the important business records are tampered by the database server side by using the root hash of the global merkel tree.
In addition, a global merkel tree may not be generated in advance, but each important business record in the important business record set is sequentially stored in other trusted account book databases maintained by the database server from beginning to end according to the sequence of the important business records in the trusted account book database.
In order to make those skilled in the art 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 drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of protection.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
Fig. 2 is a schematic flowchart of a method for deleting business records based on a trusted ledger database according to an embodiment of the present specification, including the following steps:
s200: and receiving a service record deleting request sent by the user equipment.
The main execution body of the method flow shown in fig. 2 is a centralized database server. The database server side not only comprises a credible account book database, but also comprises other credible account book databases. The credible account book database and other credible account book databases are two databases which are mutually independent and are based on the same storage scheme.
In this embodiment of the present specification, the service record deletion request may not be a data structure of a service record, but is a request packet sent by a client to a server based on a traditional client/server architecture. And the database server processes the service record deleting request.
S202: and determining a data block set to be deleted and an important service record set to be reserved according to the service record deletion request.
In some embodiments, the service record deletion request may carry the sequence number range [1, N ] of the data block to be deleted and the record identifier of each service record to be retained.
In still other embodiments, the service record deletion request may carry a record identifier of each service record to be deleted, and the database server determines the set of data blocks to be deleted and the set of important service records to be retained based on the record identifier.
S208: and after the important business record set is saved, deleting the set of data blocks to be deleted from the credible ledger database, and regenerating the created data blocks.
The database server side can store the important service record set additionally, and it should be noted that if the user has an encryption requirement for the important service record, the database server side can encrypt and store the important service record set.
Furthermore, each important business record in the important business record set can be sequentially and additionally stored into other trusted account book databases maintained by the database server according to the storage sequence of the important business record in the trusted account book database. In this way, a new credible account book database is additionally set for the user, and is exclusively used for storing important business records left from historical business records. In this way, the database server may not need to construct a global merkel tree of the trusted ledger database and return the global merkel tree to the user root hash before deleting the data blocks.
Before deleting a data block, the database server may perform integrity verification on the 1-N data blocks to be deleted (i.e., the 1 st to nth data blocks are deduced again in a multi-disk service recording manner to ensure the coupling of each service record inside the data block and the coupling between the data blocks), and delete the data block after determining that no error exists.
And the newly generated created data block comprises the account book configuration information carried by the original created data block and the block hash corresponding to the Nth data block to be deleted. The original creation data block is a deleted data block with sequence number 1.
It should be noted here that the ledger configuration information may refer to any information related to ledger configuration. For example, an account book creating business record for creating an account book includes information such as an account book creating time and an account book creator identifier. The block hash corresponding to the data block generally refers to a hash value obtained by performing hash calculation on a block header of the data block.
In this embodiment, the regenerated created data block may be stored to the storage location where the deleted nth data block originally exists (i.e., before being spliced to the (N + 1) th data block).
Through the embodiment of the specification, the usability of the credible ledger database can still not be damaged under the condition that the historical data blocks are deleted from the credible ledger database.
The storage location of the business record in the trusted ledger database may specifically refer to a sequence number (or block height) of a data block where the business record is located and a specific location (i.e. offset) of the business record in the data block.
In addition, in this specification embodiment, a block hash corresponding to the regenerated created data block may be written into a service record log corresponding to the block deletion service record, and the block deletion service record and the corresponding service record log may be written into the trusted account book database together. In this case, the regenerated founder data block does not need to be spliced to the (N + 1) th data block, but is stored separately, and the regenerated founder data block can be queried according to the service record log.
In addition, in a trusted account book database scenario, each user account may have a corresponding status, for example, the authority of each user account may change frequently, and each change means that the status corresponding to the user account changes. For another example, each user account may have a fund balance, and the balance is consumed when the user account initiates the service record, so that the fund balance state corresponding to the user account may also change.
The collection of state information corresponding to all user accounts is called world state. Each database in the ledger corresponds to a world state.
In a trusted account book database scenario, state information corresponding to each user account is not specially recorded, and in a case that the trusted account book database is complete, a world state corresponding to each data block can be deduced from a first data block copy service record in an account book source tracing manner.
In the method flow shown in fig. 2, if the 1 st to nth data blocks are deleted, it means that the world states corresponding to the 1 st to nth data blocks cannot be derived by means of multi-disc service recording. Therefore, the world state information corresponding to the 1 st to Nth data blocks can be written into the newly generated created data block, so that the preservation of the world state information is realized. Or only the world state information corresponding to the nth data block can be written into the regenerated created data block, so that the world state of the deleted first N data blocks can be proved to be coupled with the world state of the (N + 1) th data block and not be tampered.
In addition, in some embodiments of the present specification, an associated state tree is configured for the trusted account book database, and the state tree is used for dynamically recording, for each business keyword, the number of business records corresponding to the business keyword stored in the trusted account book database. Since the state tree is updated each time a data block is written into the account book, and blocking of the data block means that the business records in the data block are inevitably stored in the account book, it is equivalent to that each data block corresponds to a state tree indicating the world state (i.e. the number of business records stored by the account book corresponding to each business keyword) when the data block is blocked. And each data block carries the root hash of the corresponding state tree, so that the corresponding state tree can be ensured not to be tampered, and the number of the stored service records corresponding to a certain service keyword read from the state tree is credible.
Specifically, the method is realized in such a way that:
the database server also maintains a state tree; aiming at each leaf node in the state tree, a key corresponding to the leaf node is a service key word, and a value corresponding to the leaf node is the number of service records containing the service key word; different leaf nodes correspond to different keys; and the database server side updates the state tree whenever writing a data block into the credible account book database, and writes the root hash of the updated state tree into the data block.
Further, the newly generated created data block also includes a state tree root hash carried by the nth data block to be deleted; or the regenerated creation data block also comprises state trees corresponding to the 1 st to N data blocks to be deleted respectively.
Accordingly, the integrity of the business record can be verified in the following way:
acquiring an integrity verification request sent by user equipment; the integrity verification request comprises a service keyword specified by the user equipment; performing a business record counting operation so as to count a first number of business records containing the business keyword from a credible ledger database; determining values corresponding to leaf nodes taking the service keywords as keys based on a state tree corresponding to the created data blocks as a second quantity; determining values corresponding to the leaf nodes taking the service keywords as keys based on the state tree corresponding to the last data block as a third quantity; calculating the difference between the third quantity and the second quantity as a fourth quantity; and judging whether the first quantity is consistent with the fourth quantity, and if so, returning a verification success result to the user equipment. And if the judgment result is negative, the business record counting operation is executed again.
Fig. 3 is a schematic flowchart of a method for verifying existence of an important service record provided in this specification, including the following steps:
s300: and obtaining the important business record to be verified from a database server side, and calculating the record hash of the important business record.
The method shown in fig. 3 is applied to a user equipment. If the user is worried that the database server side falsifies the important business records which are additionally stored, the existence of the business records can be verified based on the method flow shown in fig. 3.
The existence of the business record means that the business record is deleted from the trusted ledger database, but the business record is still anchored in the trusted ledger database, and this anchoring means that if the business record is tampered, the root hash of the global merkel tree of the trusted ledger database will be changed.
S302: and sending the record hash of the important record to a database server, and receiving a global Merck tree path corresponding to the record hash returned by the database server.
The global Merck tree is constructed by arranging record Hash of each business record in the credible account book database into leaf nodes according to the time sequence of evidence storage and based on the leaf nodes.
The global merkel tree path corresponding to a record hash is a path formed by other record hashes that need to be known when the root hash is calculated based on the record hash.
S304: and calculating the root hash of the global Mercker tree based on the record hash of the important record and the global Mercker tree path.
S306: and comparing the calculated root hash with the stored root hash, and if the root hash is consistent with the stored root hash, determining that the important business record passes the existence verification.
And if the calculated root hash is consistent with the root hash stored by the user equipment (namely the root hash of the global Mercker tree which is returned to the user equipment by the database server before the data block is deleted), the fact that the important service record is not tampered by the database server is proved, and the existence verification is passed.
And if the two are inconsistent, the database server is proved to tamper the important business record and fail to pass the existence verification.
Fig. 4 is a schematic structural diagram of a service record deleting device based on a trusted ledger database provided in an embodiment of the present specification, and is applied to a database server, where the database server maintains the trusted ledger database; establishing and storing a global Merck tree in advance based on the record Hash of all service records in the credible account book database, and sending the root Hash of the global Merck tree to user equipment for storage;
the device comprises:
the receiving module 401 receives a service record deletion request sent by user equipment;
a determining module 402, configured to determine, according to the service record deletion request, a set of data blocks to be deleted and a set of important service records to be reserved; the data block set to be deleted comprises N data blocks to be deleted, wherein the serial numbers of the N data blocks to be deleted are from 1 to N, and N is more than 1;
a deleting module 403, configured to delete the set of data blocks to be deleted from the trusted ledger database after saving the set of important business records, and regenerate a created data block; and the newly generated created data block comprises the account book configuration information carried by the original created data block and the block hash corresponding to the Nth data block to be deleted.
Fig. 5 is a schematic structural diagram of an apparatus for verifying existence of an important service record provided in this specification, applied to a user equipment, the apparatus including:
an obtaining module 501, configured to obtain an important service record to be verified from a database server, and calculate a record hash of the important service record;
a sending and receiving module 502, configured to send the record hash of the important record to a database server, and receive a global merkel tree path returned by the database server and corresponding to the record hash;
a calculating module 503, configured to calculate a root hash of the global merkel tree based on the record hash of the important record and the global merkel tree path;
the comparison module 504 compares the calculated root hash with the stored root hash, and if the root hash is consistent with the stored root hash, it is determined that the important service record passes the existence verification.
Fig. 6 is a schematic structural diagram of a service record integrity verification apparatus provided in this specification, which is applied to a database server and includes:
an obtaining module 601, configured to obtain an integrity verification request sent by a user equipment; the integrity verification request comprises a service keyword specified by the user equipment;
an execution module 602, configured to perform a business record counting operation to count a first number of business records containing the business keyword from a trusted ledger database;
the determining module 603 determines values corresponding to leaf nodes taking the service keywords as keys as a second quantity based on the state tree corresponding to the created data block; determining values corresponding to the leaf nodes taking the service keywords as keys based on the state tree corresponding to the last data block as a third quantity;
a calculating module 604, configured to calculate a difference between the third number and the second number as a fourth number;
the determining and processing module 605 determines whether the first quantity is consistent with the fourth quantity, and if so, returns a successful verification result to the ue.
Embodiments of the present specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the functions of the database server or the user device when executing the program.
Fig. 7 is a more specific hardware structure diagram of a computing device provided in an embodiment of the present specification, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
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 a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
Embodiments of the present specification also provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the functions of a database server or a user equipment.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic 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, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The systems, methods, modules or units described in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the method embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to the partial description of the method embodiment for relevant points. The above-described method embodiments are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present specification. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.
Claims (14)
1. A business record deleting method based on a credible account book database is applied to a database server, wherein the database server maintains a credible account book database and other credible account book databases;
the method comprises the following steps:
receiving a service record deleting request sent by user equipment;
determining a data block set to be deleted and an important service record set to be reserved according to the service record deletion request; the data block set to be deleted comprises N data blocks to be deleted, wherein the serial numbers of the N data blocks to be deleted are from 1 to N, and N is more than 1;
according to the sequence of all important business records in the credible account book database, sequentially storing each important business record in the important business record set into other credible account book databases from first to last;
after the important business record set is saved, deleting the data block set to be deleted from the credible account book database, and regenerating the created data blocks; and the newly generated created data block comprises the account book configuration information carried by the original created data block and the block hash corresponding to the Nth data block to be deleted.
2. The method according to claim 1, wherein the service record deletion request carries a sequence number range [1, N ] of the data block to be deleted and a record identifier of each service record to be retained.
3. The method of claim 1, the database server-side further maintaining a state tree; aiming at each leaf node in the state tree, a key corresponding to the leaf node is a service key word, and a value corresponding to the leaf node is the number of service records containing the service key word; different leaf nodes correspond to different keys; and the database server side updates the state tree whenever writing a data block into the credible account book database, and writes the root hash of the updated state tree into the data block.
4. The method as claimed in claim 3, wherein the regenerated created data block further includes a state tree root hash carried by the nth data block to be deleted.
5. The method as claimed in claim 3, wherein the regenerated created data blocks further include status trees corresponding to the 1 st to nth data blocks to be deleted.
6. A method for verifying the existence of important service records in any one of claims 1-5, applied to a user equipment, the method comprising:
acquiring an important service record to be verified from a database server side, and calculating the record hash of the important service record;
sending the record hash of the important record to a database server, and receiving a global Merck tree path corresponding to the record hash returned by the database server;
calculating the root hash of the global Mercker tree based on the record hash of the important record and the global Mercker tree path;
and comparing the calculated root hash with the stored root hash, and if the root hash is consistent with the stored root hash, determining that the important business record passes the existence verification.
7. The method of claim 6, further comprising:
and if the important business records are inconsistent, determining that the important business records do not pass the existence verification.
8. A business record integrity verification method is applied to a database server side, and deletes data blocks from a credible ledger database in advance based on the method of any one of claims 3-5, and comprises the following steps:
acquiring an integrity verification request sent by user equipment; the integrity verification request comprises a service keyword specified by the user equipment;
performing a business record counting operation so as to count a first number of business records containing the business keyword from a credible ledger database;
determining values corresponding to leaf nodes taking the service keywords as keys based on a state tree corresponding to the created data blocks as a second quantity; determining values corresponding to the leaf nodes taking the service keywords as keys based on the state tree corresponding to the last data block as a third quantity;
calculating the difference between the third quantity and the second quantity as a fourth quantity;
and judging whether the first quantity is consistent with the fourth quantity, and if so, returning a verification success result to the user equipment.
9. The method of claim 8, further comprising:
and if the judgment result is negative, re-executing the service record counting operation.
10. A business record deleting device based on a credible account book database is applied to a database server, wherein the database server maintains the credible account book database and other credible account book databases;
the device comprises:
the receiving module is used for receiving a service record deleting request sent by user equipment;
the determining module is used for determining a data block set to be deleted and an important service record set to be reserved according to the service record deleting request; the data block set to be deleted comprises N data blocks to be deleted, wherein the serial numbers of the N data blocks to be deleted are from 1 to N, and N is more than 1;
the deleting module is used for sequentially storing each important business record in the important business record set into the other credible account database from first to last according to the sequence of each important business record in the credible account database; deleting the set of data blocks to be deleted from the credible account book database, and regenerating the created data blocks; and the newly generated created data block comprises the account book configuration information carried by the original created data block and the block hash corresponding to the Nth data block to be deleted.
11. A device for verifying the existence of important service records in any one of claims 1-5, applied to a user equipment, the device comprising:
the acquisition module acquires important business records to be verified from a database server side and calculates the record hash of the important business records;
the sending and receiving module is used for sending the record hash of the important record to a database server and receiving a global Mercker tree path corresponding to the record hash returned by the database server;
the calculation module is used for calculating the root hash of the global Mercker tree based on the record hash of the important record and the global Mercker tree path;
and the comparison module is used for comparing the calculated root hash with the stored root hash, and if the root hash is consistent with the stored root hash, determining that the important business record passes the existence verification.
12. A business record integrity verification device, which is applied to a database server and deletes a data block from a trusted account book database in advance based on the method of any one of claims 3 to 5, the business record integrity verification device comprises:
the acquisition module acquires an integrity verification request sent by user equipment; the integrity verification request comprises a service keyword specified by the user equipment;
the execution module is used for executing business record counting operation so as to count a first number of business records containing the business keywords from a credible account book database;
the determining module is used for determining values corresponding to the leaf nodes taking the service keywords as keys as a second quantity based on the state tree corresponding to the created data blocks; determining values corresponding to the leaf nodes taking the service keywords as keys based on the state tree corresponding to the last data block as a third quantity;
the calculating module is used for calculating the difference value between the third quantity and the second quantity to be used as a fourth quantity;
and the judgment processing module is used for judging whether the first quantity is consistent with the fourth quantity, and if so, returning a verification success result to the user equipment.
13. 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 method of any one of claims 1-5,8-9 when executing the program.
14. 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 method of any one of claims 6-7 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110033646.XA CN112632055A (en) | 2021-01-12 | 2021-01-12 | Business record deleting method based on credible account book database |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110033646.XA CN112632055A (en) | 2021-01-12 | 2021-01-12 | Business record deleting method based on credible account book database |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112632055A true CN112632055A (en) | 2021-04-09 |
Family
ID=75294077
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110033646.XA Pending CN112632055A (en) | 2021-01-12 | 2021-01-12 | Business record deleting method based on credible account book database |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112632055A (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108664221A (en) * | 2018-05-11 | 2018-10-16 | 北京奇虎科技有限公司 | A kind of data proof of possession method, apparatus and readable storage medium storing program for executing |
| CN109191124A (en) * | 2018-08-16 | 2019-01-11 | 北京京东尚科信息技术有限公司 | Block chain network, dispositions method and storage medium |
| US20190213333A1 (en) * | 2017-12-01 | 2019-07-11 | Alan Health And Science D/B/A Onpaceplus | Decentralized data authentication system for creation of integrated lifetime health records |
| CN110147410A (en) * | 2019-04-18 | 2019-08-20 | 阿里巴巴集团控股有限公司 | Data verification method, system, device and equipment in a kind of piece of chain type account book |
| CN110163006A (en) * | 2019-04-18 | 2019-08-23 | 阿里巴巴集团控股有限公司 | Signature verification method, system, device and equipment in a kind of piece of chain type account book |
| CN110599346A (en) * | 2019-09-20 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Block chain information acquisition method and related equipment |
| CN111459948A (en) * | 2020-06-15 | 2020-07-28 | 支付宝(杭州)信息技术有限公司 | Data block deleting method based on centralized block chain type account book |
| CN111506580A (en) * | 2020-06-15 | 2020-08-07 | 支付宝(杭州)信息技术有限公司 | Transaction storage method based on centralized block chain type account book |
-
2021
- 2021-01-12 CN CN202110033646.XA patent/CN112632055A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190213333A1 (en) * | 2017-12-01 | 2019-07-11 | Alan Health And Science D/B/A Onpaceplus | Decentralized data authentication system for creation of integrated lifetime health records |
| CN108664221A (en) * | 2018-05-11 | 2018-10-16 | 北京奇虎科技有限公司 | A kind of data proof of possession method, apparatus and readable storage medium storing program for executing |
| CN109191124A (en) * | 2018-08-16 | 2019-01-11 | 北京京东尚科信息技术有限公司 | Block chain network, dispositions method and storage medium |
| CN110147410A (en) * | 2019-04-18 | 2019-08-20 | 阿里巴巴集团控股有限公司 | Data verification method, system, device and equipment in a kind of piece of chain type account book |
| CN110163006A (en) * | 2019-04-18 | 2019-08-23 | 阿里巴巴集团控股有限公司 | Signature verification method, system, device and equipment in a kind of piece of chain type account book |
| CN110599346A (en) * | 2019-09-20 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Block chain information acquisition method and related equipment |
| CN111459948A (en) * | 2020-06-15 | 2020-07-28 | 支付宝(杭州)信息技术有限公司 | Data block deleting method based on centralized block chain type account book |
| CN111506580A (en) * | 2020-06-15 | 2020-08-07 | 支付宝(杭州)信息技术有限公司 | Transaction storage method based on centralized block chain type account book |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110188096B (en) | Index creating method, device and equipment for data record | |
| US20210160053A1 (en) | Merkle tree construction methods and apparatuses and simplified payment verification methods and apparatuses | |
| CN109902086B (en) | Index creation method, device and equipment | |
| US20210049595A1 (en) | Transaction method and system based on centralized settlement and block chain storage | |
| CN110162662B (en) | Verification method, device and equipment for data records in block chain type account book | |
| CN109951290B (en) | Time service authentication method, device and equipment for chain type account book | |
| US11108547B2 (en) | Methods and apparatuses for reading blockchain data | |
| US20210158340A1 (en) | Methods and apparatuses for concealing transaction written to blockchain | |
| CN111459948B (en) | Transaction integrity verification method based on centralized block chain type account book | |
| CN110837502B (en) | Data storage method, device and equipment in block chain type account book | |
| CN110008203B (en) | Data clearing method, device and equipment | |
| CN110019278B (en) | Data verification method, device and equipment | |
| US20210160054A1 (en) | Methods and systems for reading data based on plurality of blockchain networks | |
| US11005648B2 (en) | Blockchain-type data storage | |
| TW202040477A (en) | Personal asset change record storage method, system, device and equipment | |
| CN111444216A (en) | Data block deleting method based on centralized block chain type account book | |
| CN111506580B (en) | Transaction storage method based on centralized block chain type account book | |
| CN113535720A (en) | Index creating method, device and equipment in block chain type account book | |
| CN111046052B (en) | Method, device and equipment for storing operation records in database | |
| CN110347678B (en) | Financial data storage method, system, device and equipment | |
| CN110750533A (en) | Data storage method, device and equipment based on multiple service attributes | |
| CN110727679A (en) | Cooperative tracking method, system, device and equipment for court case | |
| CN111464319B (en) | Transaction storage and signature verification method based on centralized block chain type account book | |
| CN110362570B (en) | Data storage method, device and equipment | |
| CN112364010B (en) | Method and device for verifying existence of important business record |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |