CN110019278B

CN110019278B - Data verification method, device and equipment

Info

Publication number: CN110019278B
Application number: CN201910101182.4A
Authority: CN
Inventors: 杨新颖; 俞本权
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-01-31
Filing date: 2019-01-31
Publication date: 2023-07-28
Anticipated expiration: 2039-01-31
Also published as: CN110019278A

Abstract

A data verification method, device and equipment are disclosed. In the scenario where the server centers the data records in a chain of data blocks, each data block contains a hash value of its own data block determined by the hash value of the previous data block and the data record contained by itself, and the provider of the data service cannot easily make changes to the stored data. The user can verify whether the data record corresponding to the hash value exists or not at any time by inputting the hash value, and designates a specific data block to perform integral or partial data integrity verification, so that the integrity of the user data is ensured, and the user experience is improved.

Description

Data verification method, device and equipment

Technical Field

Embodiments of the present disclosure relate to the field of information technologies, and in particular, to a data verification method, device, and equipment.

Background

The current database products are generally centralized, data are generated by users, but operations such as adding, deleting, modifying and the like on the data are performed on a server side based on instructions of the users.

In this case, the user has a wish to know whether his or her own data has been damaged, lost or tampered with by a person, and a way is desired to enable such verification. However, in practical applications, the amount of data generated by the user is very large, for example, in some enterprise-level database services, such as audit logs, supply chains, government regulations, consumption records, etc., it is not easy for the enterprise user to want to verify whether the query has errors on all the data of the enterprise user.

Based on this, a convenient data verification scheme is needed.

Disclosure of Invention

Aiming at the problems that in the existing data storage, a user is difficult to know whether data stored by the user is in error or not and verification cannot be performed, in order to improve user experience in the centralized data storage, the embodiment of the specification provides a data verification method, a device and equipment, wherein the method is applied to a centralized database service provider for storing data through a plurality of data blocks and specifically comprises the following steps:

receiving a verification instruction of a user, wherein the verification instruction comprises a hash value or a data block height of a data record;

verifying whether a data record corresponding to the hash value of the data record in the verification instruction exists in the database; or verifying whether a specified number of data blocks determined by the data block height are correct or not;

and returning the verification result to the user.

Correspondingly, the embodiment of the present specification further provides a data verification device, which is applied to a centralized database service provider for storing data through a plurality of data blocks, and the device includes:

the receiving module receives a verification instruction of a user, wherein the verification instruction comprises a hash value or a data block height of a data record;

The verification module verifies whether the data record corresponding to the hash value of the data record in the verification instruction exists in the database or not; or verifying whether a specified number of data blocks determined by the data block height are correct or not;

and the return module returns the verification result to the user.

In the scenario where the server centers the data records in a chain of data blocks, each data block contains a hash value of its own data block determined by the hash value of the previous data block and the data record contained by itself, and the provider of the data service cannot easily make changes to the stored data. The user can verify whether the data record corresponding to the hash value exists or not at any time by inputting the hash value, and designates a specific data block to perform integral or partial data integrity verification, so that the integrity of the user data is ensured, and the user experience is improved.

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 the embodiments of the disclosure.

Further, not all of the effects described above need be achieved in any of the embodiments of the present specification.

Drawings

In order to more clearly illustrate the embodiments of the present description or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present description, and other drawings may be obtained according to these drawings for a person having ordinary skill in the art.

FIG. 1 is a schematic diagram of a system architecture involved in the current technology;

FIG. 2 is a schematic flow chart of a data verification method according to an embodiment of the present disclosure;

FIG. 3 is a schematic flow chart of an exemplary partial purge provided by embodiments of the present disclosure;

FIG. 4 is a schematic diagram of a process for constructing a suppressed data record according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of another system architecture involved in an embodiment of the present disclosure;

fig. 6 is a schematic structural diagram of a data verification device according to an embodiment of the present disclosure;

FIG. 7 illustrates a more specific computing device hardware architecture diagram provided by embodiments of the present disclosure;

fig. 8 is a schematic diagram of a specific generation timing certificate according to an embodiment of the present disclosure.

Detailed Description

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 drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification shall fall within the scope of protection.

It should be noted that, in the current server architecture, the database server may be a client personal user directly connected to the server, or some application servers may be connected to the client personal user, and the database server is connected to the application server. As shown in fig. 1, a schematic diagram of a system architecture involved in the current technology of fig. 1.

Thus, in the present description embodiment, when the user is an application server, the database service provider may be the database server shown in fig. 1; and when the user is a client personal user, the database service provider may be a service-end entity formed by the application server and the database server. In either case, however, the storage of the data is done at the database service provider, and the manipulation of the data (including the addition, deletion, etc.) is also performed at the database service provider based on the user's instructions, and both the user's data and the result of the manipulation of the data are stored at the database service provider, and the user's local and other devices cannot store the data. In other words, the database service provider in this specification provides data services in a centralized form.

The following describes in detail the technical solutions provided by the embodiments of the present specification with reference to the accompanying drawings. As shown in fig. 2, fig. 2 is a schematic flow chart of a data verification method according to an embodiment of the present disclosure, where the flow chart specifically includes the following steps:

s201, receiving a verification instruction of a user, wherein the verification instruction comprises a hash value or a data block height of a data record.

Specifically, a user may initiate a verification instruction, where a parameter specifies which data blocks need to be verified, for example, a hash value or a block height may specify a data block, and whether to initiate correct verification for a plurality of data blocks before or after the data block; alternatively, a data record is specified by the hash value, and it is verified whether a data record exists in the database. Several verification methods provided by the embodiments of the present specification are given below by way of example:

firstly, inputting a hash value, determining a data block by the hash value, and executing verification on the data block to obtain a verification result, wherein the verification result can be specifically realized by a verification instruction VERIFY ('khash'.

Secondly, inputting a hash value, determining a corresponding data block by the hash value or determining a data block where a data record corresponding to the hash value is located, and verifying from the determined data block forward until an initial data block, specifically, by a verification instruction VERIFY (' khash ', ' v-1), wherein the initial block height is generally "0" or "1", so that-1 may also be another value smaller than the initial block height, so that the server can know that this parameter is not a particularly small block height value, meaning that the initial data block needs to be verified until.

Thirdly, inputting a hash value, determining a corresponding data block by the hash value, and verifying the specified number of data blocks from the determined data block onwards, wherein the verification can be realized by a verification instruction VERIFY ('khash', & v, blknum).

Fourth, inputting the block height and the number to be verified, starting to VERIFY the specified number of continuous multiple data blocks from the data block corresponding to the block height, specifically, by a verification instruction VERIFY (blkh, & v, blknum).

S203, verifying whether a data record corresponding to the hash value of the data record in the verification instruction exists in the database; or, verifying whether a specified number of data blocks, as determined by the data block height, are correct.

After receiving the verification instruction, the server can analyze the instruction and obtain corresponding verification parameters including block height and hash value, and then execute predetermined verification logic according to the block height or hash value. For example, the verification manner for the data blocks may be that, starting from the data block specified by the verification instruction, the current hash value of each data block is calculated and matched with the hash value of the data block already included in the data block, and if not identical, the verification fails.

When the hash value is obtained through analysis, the server side can conduct traversing inquiry to verify whether the hash corresponds to a certain data record or not; or inquiring and acquiring the block height and the offset corresponding to the hash value from the index table, acquiring a data plaintext according to the read block height and the read offset, and further verifying according to the data plaintext.

S205, returning the verification result to the user. The result of the verification is a metadata of "have" or "none" and "correct" or "incorrect".

In the centralized database service provider according to the embodiment of the present specification, the data blocks are pre-generated by:

And receiving the data records to be stored, and determining the hash value of each data record. The data record to be stored can be various consumption records of individual users of the client, or can be business results, intermediate states, operation records and the like generated by the application server when executing business logic based on instructions of the users. Specific business scenarios may include consumption records, audit logs, supply chains, government regulatory records, medical records, and the like.

When a preset blocking condition is reached, determining each data record in the data block to be written, and generating an N data block containing the hash value of the data block and the data record.

The preset blocking conditions include: the number of data records to be stored reaches a number threshold, for example, each time one thousand data records are received, a new data block is generated, and one thousand data records are written into the block; alternatively, the time interval from the last block forming time reaches a time threshold, e.g., every 5 minutes, a new data block is generated and the data records received within the 5 minutes are written into the block.

Here, N refers to the sequence number of the data block, in other words, in the embodiment of the present specification, the data blocks are in the form of a block chain, and are arranged in sequence based on the sequence of the block forming time, which has a strong timing characteristic. Wherein the block heights of the data blocks monotonically increase based on the order of the block times. The block height may be a sequence number, and at this time, the block height of the nth data block is N; block heights may also be generated in other ways.

When n=1, that is, the data block at this time is the initial data block. The hash value and block height of the initial data block are given based on a preset manner. For example, the initial data block does not include a data record, the hash value is any given hash value, and the block height blknum=0; for another example, the generation trigger condition of the initial data block is identical to the trigger condition of the other data blocks, but the hash value of the initial data block is determined by hashing all the contents in the initial data block.

When N >1, since the content and hash value of the previous data block have been determined, at this time, the hash value of the current data block (nth data block) may be generated based on the hash value of the previous data block (i.e., nth-1 data block), for example, in a feasible manner, determining the hash value of each data record to be written into the nth block, generating a merck tree according to the arrangement order in the block, splicing the root hash value of the merck tree and the hash value of the previous data block together, and generating the hash value of the current block again by adopting the hash algorithm. For example, the hash value of the whole data record may be obtained by splicing the sequence of the data records in the block, splicing the hash value of the previous data block and the hash value of the whole data record, and performing hash operation on the string obtained by splicing to generate the hash value of the data block.

By the foregoing generation method of the data blocks, each data block is determined by a hash value, and the hash value of the data block is determined by the content and sequence of the data records in the data block and the hash value of the previous data block. The user can initiate verification based on the hash value of the data block at any time, and the modification of any content in the data block (including modification of the content or sequence of the data record in the data block) can cause inconsistency between the hash value of the data block calculated during verification and the hash value generated during data block generation, so that verification failure is caused, and therefore, the tamper-proof effect under centralization is realized.

When the user needs to specify the verification through the block height, as described above, the whole verification may be performed from the initial block, the partial verification may be performed, the verification may be performed according to the sequence number, or the verification may be performed not according to the sequence, for example, any data block is randomly fished, and the verification is passed, that is, the data block is not fished any more with the mark, until all the data blocks are verified.

The specific verification mode is as follows: for any determined data block, a data record of the data block and a hash value of a previous data block are obtained. The current hash value of the data block is calculated from the data record of the data block and the hash value of the preceding data block, where the way in which the current hash value is calculated should be consistent with the way in which the hash value of the data block is generated.

For example, the calculation method is that when generating the hash value of the data block: generating a merck tree of the data block according to the hash value and the sequence of the data records in the block, splicing the hash value of the previous data block and the root hash value of the merck tree, and carrying out hash operation on the spliced word strings to generate the hash value of the data block. Then the calculation of the current hash value should also be performed in this way at this time. The calculation method is as follows when generating the hash value of the data block: and splicing according to the sequence of the data records in the blocks, taking the hash to obtain the hash value of the whole data record, splicing the hash value of the previous data block and the hash value of the whole data record, carrying out hash operation on the word strings obtained by splicing to generate the hash value of the data block, and calculating the current hash value according to the mode.

And verifying whether the current hash value of the data block is the same as the hash value of the data block, if so, passing the verification, otherwise, failing the verification.

At this time, the service side can also add a signature of the service side in the process, and the specific mode of the signature is as follows: encrypting the verification result by using a server private key to generate a private key signature of the server on the verification result; and returning the private key signature and the verification result to the user so that the user can decrypt the private key signature by using the corresponding public key to verify, and the user can confirm that the verification result is acknowledged by the service side. Specifically, a parameter "CERT" for characterizing a service party signature may be added at the end of any verification instruction, for example: VERIFY ('khash', & v, blknum, CERT) so that the server can have the server signature in the returned result after the verification result comes out.

After the data record has been stored, some relevant index information may also be re-established, e.g. because the data record is kept in the data block, but no hash value of the data record. Therefore, in order to conveniently find any data record, the hash value of the data record can be established as a key, and the index with the block height of the data block where the data record is located and the offset of the data record in the data block where the data record is located as a value can be stored. Thus, the data record can be conveniently queried. It should be noted that, the creation of the index information may be performed asynchronously with respect to the blocking, and the index information may be sent to the user for backup, so that the user may also conveniently query or verify any data record according to the index.

In the query process, the block height of the data block where the data record is located, the offset of the data record in the data block where the data record is located or the plaintext of the data record can be queried and obtained based on the hash value input by the user, or the block height of the data block corresponding to the hash value of the data block is queried and the query result is returned.

The specific query mode can be realized by a query instruction. The query instruction comprises the hash value to be queried input by the user. The hash value here may be a hash value of a data record or a hash value of a data block, and the database service provider may perform a traversal query from the data block or may perform a query from a pre-established index.

The following examples enumerate several query approaches provided by the embodiments of the present specification:

firstly, inputting hash values of data blocks, and returning all data plaintext in the data blocks; or, the hash value of the data record is input, the plaintext of the data record is returned, specifically, the method can be realized by using a query instruction SELECT (khash, & v), and when the server receives a corresponding query instruction, the foregoing query logic is executed based on the hash value to return a result.

Secondly, inputting a hash value of the data record, returning a block height of a data block where the data record is located, and specifically, using a query instruction SELECT (khash, & v, FULL) to implement the offset in the data block;

third, the hash value of the input data chunk returns the chunk height according to the chunk hash. Specifically, the method can be implemented by using a query instruction SELECT (khash, & v, BLK).

Of course, there may be cases where the user inputs a hash value and the server cannot query the corresponding result. For example, when the user inputs a hash value corresponding to a data record and the server cannot query the result, the user may reasonably doubt that the data record corresponding to the hash has been changed, possibly tampered, or possibly lost.

Since the data record hash value or the hash value of the data block needs to be relied on for inquiry in the inquiry process. In other words, each data record needs to have a corresponding data record hash. Therefore, when a user needs to store data, a specific data record can be added through a special adding instruction for adding the data record, a server determines the hash value of the data record to be added, and returns the hash value of the data record and the block hash of the block where the data record is located to the user; and storing the data record to be added in a local cache so as to write the data record into a new data block when a preset blocking condition is met. Therefore, the user can inquire the data record according to the hash when the user needs to inquire. The following are exemplary record-adding instructions provided by embodiments of the present specification:

apend (v, & khash): and adding the data record and returning the hash value of the data record.

Further, in the storage process, the server side can also provide the signature of the corresponding service platform, which specifically comprises the following modes: encrypting the data record by adopting a server private key to generate a private key signature of the server on the data record; and returning the private key signature and the hash value of the data record to the user so that the user can decrypt the private key signature by using the corresponding public key for verification. So that the user can confirm that the hash value is acknowledged by the service. Specifically, the user may request the service to provide the signature in an add instruction, which is an instruction for an exemplary return signed add record provided by embodiments of the present description:

APPEND (v, & khash, CERT) returns the hash value corresponding to the data record and returns the signature certificate of the server.

Of course, the server signature certificate may also be included in the returned results in other types of database operations provided by embodiments of the present description, such as in other database operations such as querying, clearing, verifying, and hiding.

In another embodiment, if the content of the data block further includes a timestamp of the data block or a timestamp of the data record, or the database server side further generates the relevant index in advance, for example, when generating the index of the block height and the block timestamp, or the index of the hash value of the data record and the record timestamp, or the index of the hash value of the data block and the block time, etc., at this time, the server side may further provide a corresponding time query manner, that is, from the data block or the index, the server side queries the corresponding block height or the hash value by the time value, or queries the corresponding time value by the hash value or the block height, and the following exemplary query manners provided by the embodiments of the present specification are listed below as time-based query manners:

first, the block height is input, and the block forming TIME of the data block corresponding to the query block height can be specifically realized by a TIME query instruction TIME (blknum, & v).

Second, a hash value is input, and a timestamp corresponding to the hash value is returned, where the hash value may be a hash value of a data block or a hash value of a data record, and specifically may be implemented by a TIME query instruction TIME ('khash', & v).

Third, the time value is input, and the block height of the last data block before the time value is returned, or the hash value of the last data record before the time value and the block height of the data block where the hash value is located are returned, which may be specifically implemented by a time query instruction LTIME ('time'.

In the embodiment of the present specification, if the user no longer needs the service, the entire clearing of the data may be performed before the service is ended. For example, the user inputs the account ID, the server clears the account, for example, by a clear instruction PURGE (lgid), or the user also inputs a time period, the server files the account first, and after the time period is reached, the server clears the account, for example, by a clear instruction PURGE (day-save).

And, due to the increasing data of users, the storage space is occupied more and more, or some historical data with longer time is not valuable to users, at this time, the database server side can also perform corresponding partial clearing on the data blocks based on the requirements of the users. The partial purge may be based on block height or point in time.

For example, the user designates the account ID and the block height, and the server determines that the data blocks before the block height are all data blocks to be cleared based on the block height, and then clears the data blocks determined to be cleared, which may be specifically implemented by a clear instruction PURGE (lgid, d-a, blkbound).

For another example, the user designates the ledger ID and the time point, and the server determines the last generated data block before the time point based on the time point, determines the data blocks generated before the data block as the data blocks to be cleared, and then clears the data blocks determined to be cleared, which may be specifically implemented by a clear instruction PURGE (lgid, d-a, 'timetmp').

Before the partial erasure is performed, since the hash value of the first data block of the erased data block chain is generated based on the hash value of the previous data block, at this time, a dummy initial data block is also required to be generated, and the hash value of the dummy initial data block is equal to the hash value of the last data block determined to be erased, so that an error in the subsequent verification can be avoided. The hash value of the last data block can be obtained by inquiring from a pre-established index, or can be obtained by sequentially calculating from the initial data block, or can be obtained by inquiring from the data block.

The content in the newly generated pseudo initial data block may be empty, or some corresponding remarks may be recorded, for example, the time of generation, etc. However, the content of the dummy initial data block is independent of the hash value of the dummy initial data block. And the server may also sign the dummy initial data block.

In addition, it is common for users to backup partially purged data. Based on this, in the process of the user performing the partial removal, verification can also be inserted for the data confirming that the partial removal is required. As shown in fig. 3, fig. 3 is a schematic flow chart of an exemplary partial purge provided in the embodiments of the present disclosure. In the schematic diagram, a user inputs a time point, specifically, the generation time of the data block nearest before the time point can be queried and obtained, then the block height of the data block corresponding to the generation time is obtained, a pseudo initial data block is generated and signed, and then the partial clearing operation is executed.

In practice, some data (referred to herein as sensitive data) once written in a data block can have deleterious consequences. For example, in the data uploaded by company a, the content in one data record is "leaf XX, sex man, and identification number 123456", and the identification number in the data record relates to revealing the privacy of the user and needs to be hidden.

Since in the scheme provided in the embodiments of the present disclosure, modification or removal of any data record may simultaneously cause verification errors on other data blocks, based on this, the embodiments of the present disclosure also provide a method for concealing sensitive data, specifically, a core technical means is to replace a data record in which information to be concealed is located in a data block with a hash value of the data record. In this way, the disclosure of the sensitive information can be stopped without disturbing the smooth operation of the data block system.

Specifically, the user may directly specify the location of the information to be suppressed, or in practical applications, the user may issue a suppressed information instruction carrying the location information. The location information here includes a block height of the data block, an offset of the data recorded in the block height, an offset of the information to be suppressed in the data recorded, a length of the information to be suppressed, and the like.

For example, an exemplary suppressed information instruction may be DELETE (blkhight, txoff), under which a data record corresponding to a specified block height blkhight and a specified offset txoff is suppressed;

as another example, another exemplary conceal information instruction may be DELETE (blkhight, txoff, offset, length), under which a data record is determined by the block height blkhight and the offset txoff, concealing information determined by the length of the beginning of the offset specified in the data record.

The information obtained after replacement or removal of the suppressed information is not used as a data record anymore and may be referred to as remark information. In the process of hiding information, one feasible way is to determine a hash value of a data record where the information to be hiding is located, splice a preset front marker character to the head of the hash value, splice a preset rear marker character to the tail of the hash value, splice remark information to the tail of the rear marker character, and then determine the data spliced by the front marker character, the transaction hash, the rear marker character and the remark information as the hiding data record. As shown in FIG. 4, FIG. 4 is a schematic diagram of a process for constructing a suppressed data record according to an embodiment of the present disclosure.

It should be noted that the front marking character and the rear marking character may be specified according to actual needs. For example, the front marker character may be "0E" and the rear marker character may be "0F". The effect of the preceding marker character is that when the data record needs to be read at a later time for verification, then the preceding marker character reveals information to the node: "the storage location stores not the plain content of the data record but the hash value of the data record". At this time, the hash value may be directly read for verification. When the corresponding remark information needs to be read, the reading can be started from the rear mark character 0F, and after the sensitive information is hidden, the content in the remark information can be basically the same as the content of the data record before the hidden, or can be completely empty (namely, the content of the whole data record is completely hidden).

Furthermore, it should be noted that the concealment of the history data record is a relatively strict operation. It often symbolizes certain information disclosures that trigger laws or violate morals, and also often concludes after multiparty adjustment or judgment that forced processing of the information is required. Thus, in performing the above-described purge operation, one possible way is to: the purge operation requires a certain signature weight.

For example, for an operation instruction issued by a general user, the background default signature weight is 30, while the signature weight used by a server or other transaction system is 60, the signature weight issued by a national force-executing mechanism such as a court is 120, and the signature weight required for a clearing operation is preset to be 100. The execution weight of one operation may be the sum of the signature weights of the participants, and in general, it may be set that the participants do not exceed 2. In such an embodiment, at least two digital signatures of the authorities (e.g., transaction system side and database server side) associated with the data records are required to be performed. That is, the transaction system side is required to initiate a clearing instruction and sign, and the database server side receives the clearing instruction and signs to clear. The end user initiated clear instruction will not be executed even if the database server side signed the authorization because of insufficient signature weight.

Further, the database server may also provide other database service modes, for example:

during archiving, retrieving a user data ledger, which is realized by a retrieving instruction RECALL (lgid), wherein the ledger refers to a set containing all data blocks;

returning the block height of the current last data block through an instruction GETHEIGHT (& v);

returns the user ledger ID, is implemented by instruction GETLEDGER (& v), and so on.

In addition, it should be noted that, in the above description, various operation instructions are provided to implement the database service manner provided in the present application. However, the form of the operation instruction is not limited to the form set forth in the embodiment of the present disclosure, and in practice, the form of the operation instruction for data may be various, and only the service manner set forth in the present application may be implemented. And the query instruction provides an external form which is convenient for the user to operate, and the query instruction still depends on the execution mode corresponding to each instruction when the server receives and executes the instruction.

Further, after generating the data blocks, the server may also give a corresponding time stamp for each block. For example, a national time service center interface is introduced, and trusted time stamps are adopted for block discharging when the blocks are discharged. Thus, the time stamp can be relied upon for index creation.

In one embodiment, for any data block, if there is a reception timestamp in the data records in the block, the data records may be ordered according to the reception timestamp, and an ordering sequence number may be allocated to each data record; or the sequence numbers may be allocated directly in the order in which the data records were received and reset after blocking so that the sequence numbers are allocated internally for the next data block.

After the sequence number is determined, the sequence number and the hash value can be spliced according to the hash value of each data record which is determined. Specifically, a substring with a specified length can be added at the head or tail of the hash value to place sequence numbers, a time sequence hash character string of the data record is generated, and then a first index table containing the corresponding relation of the block time stamp of the data block and the time sequence hash character string of the data record is established according to the sequence of the sequence numbers. As shown in table 1, table 1 is a first index table related to data records provided in the embodiments of the present specification. In table 1, the first 6 bits of the hash value of the data record are inserted with a corresponding sequence number string, where "0x" is used to identify the next sequence number, "0001" is the sequence number, "hash1" is the hash value of the first piece of data in the data block, and the time on the left side is the blocking time of the data block. In this way, the number of valid bits of the timestamp is fully reserved.

TABLE 1

20xx-01-19 03:14:07.938576	0x0001Hash1
		20xx-01-19 03:14:07.938576	0x0002Hash2
20xx-01-19 03:14:07.938576	0x0003Hash3
		20xx-01-19 03:14:07.938576	……

In another embodiment, in the same way, for any data block, if there is a receiving timestamp in the data record in the block, the data records may be ordered according to the receiving timestamp, and an ordering sequence number is allocated to each data record; or the sequence numbers may be allocated directly in the order in which the data records were received and reset after blocking so that the sequence numbers are allocated internally for the next data block.

At this point, the last specified number of bits in the chunk timestamp may be eliminated for the sequence number of the write data record. In addition, a specified sequence number which is not allocated to the data record can be added into the index, and the index is written in the corresponding relation between the block time stamp and the block height of the data block. For example, a sequence number of a data record typically starts with 1, then a sequence number of "0" may be used to store the block height of a data block. As shown in table 2, table 2 is a second index table for data records provided in the embodiments of the present specification. In table 2, the last three bits of the block time on the left (assuming that the number of data records stored in one block does not exceed 1000) are used to store the sequence numbers of the data records.

TABLE 2

20xx-01-19 03:14:07.938000	Blkheight
		20xx-01-19 03:14:07.938001	Hash1
20xx-01-19 03:14:07.938002	Hash2
		20xx-01-19 03:14:07.938003	Hash3
20xx-01-19 03:14:07.938004	……

In this embodiment, although sacrificing several time-significant digits, the hash value of the data record may be read directly, and the block height of the data block may be identified by a specified sequence number (i.e., 000 in Table 2).

The index can be created immediately at the time of outputting the block or asynchronously. The index itself may be used for some searching or statistics operations, for example, counting the number of data records in a certain period of time, avoiding traversal counting from within the data block, which is more convenient.

In addition, when data is stored using a block-chained ledger, one ledger typically includes a plurality of consecutive blocks of data. In practical applications, natural sequence numbers are often used to number data blocks. For example, the block height of the initial data block is 1, and every time one data block is added subsequently, the block height is increased by 1. Based on this, the embodiment of the present disclosure further provides a block height creation manner, specifically, determining a block time of a data block, and then converting the block time into integer data by using a symmetric encryption algorithm, where the integer data is regarded as a block height of the data block, and the earlier the block time, the smaller the integer data.

Specifically, the integer here may be a large integer data, for example, a large integer of 13 bits. Thus, since the large integer is based on time symmetric encryption, when the block time of the data block is required, the block time can be obtained by the same symmetric decryption.

For example, for the chunking time "20xx-01-19 03:14:07.938576", after symmetric encryption, it can be converted to a large integer "1547838847938", which is "1547838847938" because integer data monotonically increases over time. The block height of the data block can be used as the data block at this time to identify the data block. In the present specification, the block heights are monotonically increasing based on the block formation time, so that even if large-sized data is employed, the order among the data blocks is reflected from small to large. For example, if the next chunk time of a data chunk is "20xx-01-19 03:16:07.235125," it can be converted to another larger large integer "1547838848125" using a preset symmetric encryption algorithm.

Based on this, it is also possible to determine the sequence number of each traffic log in the data block as in the foregoing manner, and splice the block height and the sequence number, generate the timing information of the traffic log containing both the block height and the sequence number, and establish the third index table of hash values and the timing information of the traffic log. As shown in table 3, table 3 is a third index table provided in the embodiments of the present specification. In this table, the large integer on the left side is timing information including block heights and sequence numbers, the block heights being obtained based on time-symmetric encryption. In the case of a chunking time accurate to the millisecond level, the third index introduces 3 decimal digits after the chunk height to identify the sequence number (i.e., defining a chunk threshold of 999), so the assumption for throughput is millions, already able to meet any practical transaction scenario. If the throughput is higher, more decimal values need to be introduced after the block height to identify the sequence numbers.

TABLE 3 Table 3

1547838847938000	1547838847938
		1547838847938001	Hash1
1547838847938002	Hash2
		1547838847938003	Hash3
1547838847938004	……

In an actual application scenario, the database service provider involved in the embodiments of the present disclosure may also provide corresponding services for the corresponding database. As shown in fig. 5, fig. 5 is a schematic diagram of another system architecture involved in an embodiment of the present description, including a database base service provider and a database enhancement service provider. For example, mySQL, postgreSQL, mongoDB is a database base service provider, and these database systems can provide services for basic add-delete-modify-check operations for common transaction systems. At the same time, they also store corresponding business operation logs for these operations locally, in which the operation records of the database base service provider on the business data are recorded. The system for providing the further service for the database basic service provider is the database enhanced service provider hedger server provided by the embodiment of the present specification.

Based on this, the present description embodiments also provide a way in which further enhanced services may be provided for database-based service providers. Specifically, when the databases MySQL, postgreSQL, mongoDB and the like generate service operation logs, the service operation logs generated by the databases can be sent to the hedger. Because the service operation logs are provided with the generation time stamps, the Ledger system can sort, block and store the service operation logs according to the generation time stamps. Thus, each database can further manage its own system operation log based on the aforementioned operation mode. The database basic service provider does not need to send to the Ledger system immediately when generating the system operation log, and can be an asynchronous sending process.

Each database basic service provider can send a service operation log to the Ledger system in a plaintext manner. The term "plaintext" as used herein refers to the business operations log sent by each database that the Ledger system can understand or partially understand. For example, a certain database and the Ledger system make a communication protocol in advance, so that the Ledger system can acquire the operation type, the operation service object and the like in the service operation log, and the Ledger system can further perform blocking according to the operation type or the operation target object when blocking, so that each database system can perform better management. In this way, if each database needs to perform query or statistics (for example, statistics on how many times data of which service object is subjected to cleaning operation), only an instruction needs to be sent, and a specific statistics or query process can be completed at the end of the hedger system.

Of course, each database basic service provider can also send the service operation log to the hedgegr system in a "ciphertext" manner. The "ciphertext" herein refers to a service operation log sent by each database that cannot be understood by the hedgegr system. In this way, each database can only read or clear the stored business operation log from the hedgegr system, and specific query or statistics needs to be executed locally at the database base service provider after reading the data.

In one implementation scenario, for example, where the data records are fee information regarding the business, the data records need to be reviewed. The method is an indispensable technical means for preventing enterprises and service parties from falsifying time stamps in a combined way to manufacture a new account book, and performing time service authentication of data blocks to authoritative time fairness institutions. The time authority may be, for example, a national time service center or an authoritative time authority licensed by the national time service center. The time service authentication is as follows: a relevant signature of the time equity is obtained, wherein the signature comprises a trusted timestamp issued by the time equity, and the trusted timestamp corresponds to a data block needing authentication.

Specifically, the service side first determines a section of ledger which needs time service authentication from the generated and stored data blocks, wherein at least one data block or a plurality of high-continuous data blocks should be contained. The determining mode can be specified based on user operation, for example, a user initiates a time service instruction, and the instruction comprises a starting block height and a block number which need time service authentication; or the service side can automatically perform the operation based on preset business logic without the specification of a user.

For example, from the finest granularity, each data block may be time-stamped. In this way, the root hash of the merck tree is the block hash value of the data block, and this way can maximally protect the authenticity of the ledger (i.e., each data block). Because of the high frequency of the outgoing blocks of the data blocks, the cost overhead of the method is relatively high for both the time service center and the service side. An alternative way is to set a certain time service preset condition, and initiate a time service request when the certain time service preset condition is met. When the newly generated data blocks are considered as the data blocks to be time-service authenticated, the time-service preset conditions may be: the data blocks to be time-stamped and authenticated reach the number threshold, or the time interval from the last time-stamped and authenticated has reached the time threshold.

The specific time service authentication mode is that the block hashes of the data blocks to be time service authenticated are connected in series according to the order of block heights, and the merck tree corresponding to the plurality of data blocks is generated based on the block hashes of the data blocks, so that the root hash of the merck tree is confirmed. And, the related information of the data block to be time-service authenticated is confirmed, for example, including information of a start block height, an end block height, or the number of data blocks, etc. The root hash of the merck tree and the related information of the data block are then sent to a time fairness mechanism. The time fairness mechanism receives the information, namely, gives a trusted time stamp, carries out digital signature authentication on the trusted time stamp, and generates a time service certificate containing the trusted time stamp and the digital signature, wherein the time service certificate can also contain related information of the data block, and the digital signature is achieved by conventional private key encryption and public key decryption.

Thus, the server may receive a series of trusted time stamps containing time equity signatures, each of which corresponds to a segment of the ledger, and based on the relevant information, may know explicitly which segment of the data block. The server may perform corresponding management and verification based on the trusted time stamp. For example, when a certain account book needs to be checked, the service party can give out a time service certificate of which the corresponding data block contains a trusted time stamp and a signature of a time fairness mechanism, and recalculate the merck root hash according to the related information contained in the time service certificate, so that the data block corresponding to the certificate can be confirmed to be impossible to be forged later, and the service party and the served party can be effectively prevented from jointly manufacturing the account book containing the false time stamp so as to avoid the corresponding audit. As shown in fig. 8, fig. 8 is a schematic diagram of a specific generation timing certificate according to an embodiment of the present disclosure.

Correspondingly, the embodiment of the present disclosure further provides a data verification device, which is applied to a centralized database service provider that stores data through a plurality of data blocks, as shown in fig. 6, and fig. 6 is a schematic structural diagram of the data verification device provided in the embodiment of the present disclosure, including:

The receiving module 601 receives a verification instruction of a user, wherein the verification instruction comprises a hash value or a data block height of a data record;

the verification module 603 verifies whether the data record corresponding to the hash value of the data record in the verification instruction exists in the database; or verifying whether a specified number of data blocks determined by the data block height are correct or not;

and a return module 605 for returning the verification result to the user.

Further, the receiving module 601 is further configured to receive data records to be stored, and determine hash values of the data records; the apparatus further includes a generating module 607 for determining each data record in the data block to be written to when a preset blocking condition is reached, and generating an nth data block including a hash value of the data block and the data record, including:

when n=1, the hash value and the block height of the initial data block are given based on a preset manner;

when N >1, determining the hash value of the N data block according to the hash value of each data record and the N-1 data block in the data block to be written, and generating the N data block containing the hash value of the N data block and each data record, wherein the block heights of the data blocks monotonically increase based on the sequence of the block forming time.

Further, the preset blocking condition includes: the number of the data records to be stored reaches a number threshold; alternatively, the time interval from the last time of blocking reaches a time threshold.

Further, the verification module 603 obtains, for any determined data block, a data record of the data block and a hash value of a previous data block; calculating to obtain the current hash value of the data block according to the data record of the data block and the hash value of the previous data block; and verifying whether the current hash value of the data block is the same as the hash value of the data block, if so, passing the verification, otherwise, failing the verification.

Further, the return module 605 returns the verification result including the database service provider signature to the user.

The embodiments of the present disclosure also provide a computer device at least including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements a data verification method shown in fig. 2 when executing the program.

FIG. 7 illustrates a more specific hardware architecture diagram of a computing device provided by embodiments of the present description, which may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 implement communication connections therebetween within the device via a bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit ), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc. for executing relevant programs to implement the technical solutions provided in the embodiments of the present disclosure.

The Memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory ), static storage device, dynamic storage device, or the like. Memory 1020 may store an operating system and other application programs, and when the embodiments of the present specification are implemented in software or firmware, the associated program code is stored in memory 1020 and executed by processor 1010.

The input/output interface 1030 is used to connect with an input/output module for inputting and outputting information. The input/output module may be configured as a component in a device (not shown) or may be external to the device to provide corresponding functionality. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various types of sensors, etc., and the output devices may include a display, speaker, vibrator, indicator lights, etc.

Communication interface 1040 is used to connect communication modules (not shown) to enable communication interactions of the present device with other devices. The communication module may implement communication through a wired manner (such as USB, network cable, etc.), or may implement communication through a wireless manner (such as mobile network, WIFI, bluetooth, etc.).

Bus 1050 includes a path for transferring information between components of the device (e.g., processor 1010, memory 1020, input/output interface 1030, and communication interface 1040).

It should be noted that although the above-described device only shows processor 1010, memory 1020, input/output interface 1030, communication interface 1040, and bus 1050, in an implementation, the device may include other components necessary to achieve proper operation. Furthermore, it will be understood by those skilled in the art that the above-described apparatus may include only the components necessary to implement the embodiments of the present description, and not all the components shown in the drawings.

The present embodiment also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements a data verification method as shown in fig. 2.

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 storage media for a computer 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, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

From the foregoing description of embodiments, it will be apparent to those skilled in the art that the present embodiments may be implemented in software plus a necessary general purpose hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be embodied in essence or what contributes to the prior art 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., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present specification.

The system, method, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for the method embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and reference is made to the description of the method embodiments for relevant points. The above-described method embodiments are merely illustrative, in that the modules illustrated as separate components may or may not be physically separate, and the functions of the modules may be implemented in the same piece or pieces of software and/or hardware when implementing the embodiments of the present disclosure. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

The foregoing is merely a specific implementation of the embodiments of this disclosure, and it should be noted that, for a person skilled in the art, several improvements and modifications may be made without departing from the principles of the embodiments of this disclosure, and these improvements and modifications should also be considered as protective scope of the embodiments of this disclosure.

Claims

1. A data verification method for use in a centralized database service provider that stores data over a plurality of data blocks, the method comprising:

returning a verification result to the user;

wherein, at the centralized database service provider, the data blocks are pre-generated by:

receiving data records to be stored, and determining hash values of the data records;

when a preset blocking condition is reached, determining each data record in the data block to be written, and generating an Nth data block containing hash values of the data block and the data records, wherein the method specifically comprises the following steps of:

2. The method of claim 1, the preset blocking condition comprising:

the number of the data records to be stored reaches a number threshold; or alternatively, the process may be performed,

the time interval from the last time of blocking reaches a time threshold.

3. The method of claim 1, verifying whether a specified number of data blocks, as determined by the data block height, are correct, comprising:

for any determined data block, acquiring a data record of the data block and a hash value of a previous data block;

calculating to obtain the current hash value of the data block according to the data record of the data block and the hash value of the previous data block;

4. The method of claim 1, returning the authentication result to the user, comprising:

and returning a verification result containing the database service provider signature to the user.

5. A data verification apparatus for use in a centralized database service provider that stores data over a plurality of data blocks, the apparatus comprising:

the return module returns the verification result to the user;

the receiving module is also used for receiving the data records to be stored and determining the hash value of each data record;

the device further comprises a generation module, when a preset blocking condition is reached, each data record in the data block to be written is determined, and an Nth data block containing hash values of the data block and the data records is generated, and the device specifically comprises:

6. The apparatus of claim 5, the preset blocking condition comprising:

the time interval from the last time of blocking reaches a time threshold.

7. The apparatus of claim 5, the verification module to obtain, for any determined data block, a data record of the data block and a hash value of a previous data block; calculating to obtain the current hash value of the data block according to the data record of the data block and the hash value of the previous data block; and verifying whether the current hash value of the data block is the same as the hash value of the data block, if so, passing the verification, otherwise, failing the verification.

8. The apparatus of claim 5, the return module to return the verification result containing the database service provider signature to the user.

9. 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 of claims 1-4 when the program is executed by the processor.