CN110046281A

CN110046281A - A kind of data adding method, device and equipment

Info

Publication number: CN110046281A
Application number: CN201910100186.0A
Authority: CN
Inventors: 杨新颖; 俞本权
Original assignee: Alibaba Group Holding Ltd
Current assignee: Ant Chain Technology Co ltd
Priority date: 2019-01-31
Filing date: 2019-01-31
Publication date: 2019-07-23
Anticipated expiration: 2039-01-31
Also published as: CN110046281B

Abstract

Disclose a kind of data adding method, device and equipment.Under the scene for carrying out the storage of centralization to data record in a manner of data block chain in service side, the cryptographic Hash of the data block determined in each data block comprising the cryptographic Hash by last data block and the data record for itself being included, the provider of data service can not easily make a change the data of storage.User can initiate data upload in the form of instruction, to then can carry out Hash calculation when server-side receives addition instruction to the data record in instruction, obtain cryptographic Hash and be back to user.When user needs, cryptographic Hash need to be only inputted, so that it may which whether the data record inquired in the data record of oneself, and the whole data block chain of verifying at any time is correct, ensure that the integrality of user data, improves user experience.

Description

Data adding method, device and equipment

Technical Field

The embodiment of the specification relates to the technical field of information, in particular to a data adding method, device and equipment.

Background

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

In this situation, after the user uploads the data to the server, the user may wish to have a way to verify the data without knowing whether the server modifies the data or whether the data stored in the server is damaged or lost. In practical applications, because the amount of data generated by users is very large, for example, in some enterprise-level-oriented database services, such as audit logs, supply chains, government supervision, consumption records and other application scenarios, it is not easy for an enterprise user to verify and query whether an error occurs in own data.

Based on this, there is a need for a data addition scheme that facilitates user authentication.

Disclosure of Invention

To solve the problems that it is difficult for a user to know whether data stored by the user in the existing data storage is error or not and the data cannot be verified, and to implement centralized data storage and improve user experience, embodiments of the present specification provide a data adding method, apparatus, and device, where the method is applied to a centralized database service provider that stores data by a plurality of data blocks, and specifically includes:

receiving an adding instruction of a user for adding a data record, wherein the adding instruction comprises the data record to be added;

determining the hash value of the data record to be added, and returning the hash value to a user;

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;

the data block comprises at least one data record except for the initial data block, each data block comprises a hash value of a previous data block and a hash value of a data block determined by the data record contained in the data block, and the block height of the data block is monotonically increased based on the sequence of the blocking time.

Correspondingly, the present specification further provides a data adding device, which is applied in a centralized database service provider that stores data by a plurality of data blocks, and the device includes:

the receiving module is used for receiving an adding instruction of a user for adding a data record, wherein the adding instruction comprises the data record to be added;

the determining module is used for determining the hash value of the data record to be added;

the returning module returns the hash value to the user;

the cache module is used for storing the data record to be added into a local cache so as to write the data record into a new data block when a preset blocking condition is met;

In a scenario where a server performs centralized storage on data records in a data block chain manner, each data block includes a hash value of a previous data block and a hash value of its own data block determined by the data record included in itself, and a provider of a data service cannot easily change stored data. The user can initiate data uploading in the form of an instruction, so that when the server receives the adding instruction, the server can perform hash calculation on the data record in the instruction to obtain a hash value and return the hash value to the user. When a user needs the data, the user only needs to input the hash value, and can inquire the data record of the user at any time and verify whether the data record on the whole data block chain is correct or not, 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 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 system architecture involved in the current art;

fig. 2 is a schematic flow chart of a data adding method provided in an embodiment of the present specification;

FIG. 3 is a flow diagram 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 description;

FIG. 5 is a schematic diagram of another system architecture referred to in embodiments of the present description;

fig. 6 is a schematic structural diagram of a data adding device provided in an embodiment of the present specification;

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

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

Detailed Description

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.

It should be noted that, in the current server architecture, the database server may be a client individual user directly interfaced with the server, or may be a client individual user interfaced with some application servers, and the database server interfaces with the application server. As shown in fig. 1, fig. 1 is a schematic diagram of a system architecture involved in the prior art.

Thus, in this specification embodiment, when the user is an application server, the database service provider may be the database server shown in fig. 1; when the user is a client-side individual user, the database service provider may be a server side entity including an application server and a database server. In any case, the storage of the data is completed at the database service provider, and the operation (including adding, deleting, checking and the like) on the data is also performed at the database service provider based on the instruction of the user, the user data and the operation result on the data are stored at the database service provider, and the data cannot be stored locally or on other devices of the user. In other words, the database service provider in the present specification provides data services in a centralized form.

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

s201, receiving an adding instruction of adding data records by a user, wherein the adding instruction comprises the data records to be added.

The data records to be added may be text documents, videos, pictures and the like uploaded by the terminal user when the data records are directly oriented to the terminal user, may also be service records obtained after the application server performs processing based on the request of the terminal user, and may also be operation logs and the like generated when the application server performs various kinds of addition, deletion, modification and check on the database server.

The following are exemplary instructions for adding records provided by embodiments of the present specification: APPEND (v, & khush): and adding the data record and returning the hash value of the data record. Where "v" is a data record that a user can enter or specify a path.

S203, determining the hash value of the data record to be added, and returning the hash value to the user.

S205, 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; the data block comprises at least one data record except for the initial data block, each data block comprises a hash value of a previous data block and a hash value of a data block determined by the data record contained in the data block, and the block height of the data block is monotonically increased based on the sequence of the blocking time.

Specifically, the scenario in the embodiments of the present specification is applied to a centralized database service provider that stores data by a plurality of data chunks, where the preset blocking condition includes: when the number of data records to be stored reaches a number threshold, for example, a new data block is generated every time one thousand data records are received, and one thousand data records are written into the block; alternatively, a time interval from the last blocking 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. And when the blocking condition is met, extracting each data record to be written into the data block from the cache, and generating an Nth data block containing the hash value of the data block and the data record.

N here refers to a sequence number of the data block, that is, in the embodiment of the present specification, the data block is arranged in a block chain manner, and is arranged in sequence based on the blocking time, so that the data block has a strong timing characteristic. The block height of the data block is monotonically increased based on the sequence of the blocking time. The block height may be a sequence number, and at this time, the block height of the nth data block is N; the block height may also be generated in other ways.

When N is 1, the data block at this time is the initial data block. The hash value and the block height of the initial data block are given based on a preset mode. For example, the initial data block does not contain data records, the hash value is any given hash value, and the block height blknum is 0; for another example, the trigger condition for generation of the initial data block is consistent with the trigger conditions of other data blocks, but the hash value of the initial data block is determined by hashing all of the contents in the initial data block.

When N >1, since the content and hash value of the previous data block have already 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, one possible way is to determine the hash value of each data record to be written into the nth data block, generate a mercker tree in the order of arrangement in the blocks, concatenate the root hash value of the mercker tree with the hash value of the previous data block, and generate the hash value of the current block again using the hash algorithm. For example, the hash value of the data block may be generated by concatenating the data records in the order of the data records in the block and hashing the concatenated data records to obtain the hash value of the entire data record, concatenating the hash value of the previous data block and the hash value of the entire data record, and performing a hash operation on the concatenated string.

By the above-mentioned manner of generating 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 the sequence of 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 modification of any content in the data block (including modification of data record content or sequence 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 centralized non-tampering is realized.

The data records are stored in a centralized manner in a data block chain manner by generating data blocks comprising a certain number of data records and recording hash values when the data blocks are generated. In this data storage manner, the hash value of each data block depends on the hash value of the previous data block and the content of the data record contained in itself. The user can inquire own data record at any time based on the storage form, and can verify the hash value of the appointed data block or the appointed data record according to the hash value, so that the integrity of the user data is ensured, and the user experience is improved.

Further, in the process of adding data, the service party may also provide a signature of a corresponding service platform, specifically including the following ways: 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 recognized by the service party. Specifically, the user may request the service party to provide the signature in an add instruction, and the following is an exemplary instruction provided in this specification to return a signed add record: and (v, & khush, CERT) returning the hash value corresponding to the data record and returning the signature certificate of the service party.

After the data record is stored, some relevant index information may also be re-established, e.g., because the data record is stored in the data block, there is no hash value for the data record. Therefore, in order to conveniently find any data record, an index which takes the hash value of the data record as a key, and takes the block height of the data block where the data record is located and the offset of the data record in the data block as values can be established and stored. Therefore, the data records can be inquired more conveniently. It should be noted that the creation of the index information may be performed asynchronously with respect to the chunking, 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 data record plaintext may be queried based on the hash value input by the user, or the block height of the data block corresponding to the hash value of the obtained data block may be queried, and the query result may be returned.

The specific query mode can be realized by a query instruction. The query instruction includes 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 traversal query on the data block or perform query on a pre-established index.

The following exemplifies several query modes provided by the embodiments of the present specification:

firstly, inputting a hash value of a data block, and returning all data plaintexts in the data block; or, the hash value of the data record is input, and the plaintext of the data record is returned, specifically, the hash value may be input and the plaintext of the data record may be returned by using a query instruction SELEC T (khash, & v), and when the service side receives the corresponding query instruction, the service side executes the foregoing query logic based on the hash value to return the result.

Secondly, inputting a hash value of a data record, returning a block height of a data block where the data record is located, and an offset in the data block, which can be specifically implemented by using a query instruction SELECT (khush, & v, FULL);

thirdly, inputting the hash value of the data block and returning the block height according to the block hash. In particular, it may be implemented using a query instruction SELECT (khush, & v, BLK).

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

Of course, in other types of database operations provided by embodiments of the present specification, such as querying, purging, verifying, and suppressing, among other database operations, the server-side signed certificate may also be included in the returned result.

In addition to the query, the user may also actively initiate verification on a plurality of data blocks already existing in the database, specifically, the user may initiate a verification instruction, where the verification instruction specifies which data blocks need to be verified through a parameter, for example, one data block may be specified through a hash value or a block height, and whether the verification is correct is initiated on a plurality of data blocks before or after the data block; or, a data record is designated by the hash value, and whether the data record exists in the database is verified. The result of the verification is a "present" or "absent" and a "correct" or "incorrect" such metadata. The following exemplary provides several confirmation methods provided by the embodiments of the present specification:

first, a hash value is input, a data block is determined from the hash value, and verification is performed on the data block to obtain a verification result, which may be implemented by a verification instruction VERIFY ('khush', & v).

Secondly, inputting a hash value, determining a corresponding data block from 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 to an initial data block, specifically, by a verification instruction VERIFY ('khush', & v, -1), generally speaking, the initial block height is "0" or "1", and therefore, -1 may also be other values lower than the initial block height.

Thirdly, inputting a hash value, determining a corresponding data block by the hash value, and verifying a specified number of data blocks from the determined data block onward, which can be specifically implemented by a verification instruction VERIFY ('khush', & v, blknum).

Fourthly, inputting the block height and the number to be verified, and verifying the specified number of data blocks from the data block corresponding to the block height in the past, specifically, the verification can be realized by a verification instruction VERIFY (blkh, & v, blknum).

The result returned during verification is a "yes" or "no" metadata, and as mentioned above, the service provider may also add the signature of the service provider during this process, and the generation manner of the signature is described above. Specifically, a parameter "CERT" representing a signature of the service party may be added at the end of any verification instruction, for example: VERIFY ('khush', & v, blknum, CERT), with a server signature in the returned result.

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 further generates an index in advance, for example, an index of a block height and a block timestamp, an index of a hash value and a record timestamp of the data record, or an index of a hash value and a block time of the data block, etc., when the data block is blocked, the server may further provide a corresponding time query manner, that is, the server may query the corresponding block height or hash value from the data block or the index by the time value, or query the corresponding time value by the hash value or the block height, and the following exemplarily lists several time-based query manners provided by the embodiments of this specification:

first, inputting a block height, and querying a blocking TIME of a data block corresponding to the block height, which may be specifically implemented by a TIME query instruction TIME (blknum, & v).

Secondly, inputting a hash value, and returning a timestamp corresponding to the hash value, where the hash value may be a hash value of a data block or a hash value of a data record, and specifically, the hash value may be implemented by a TIME query instruction TIME ('khush', & v).

Third, entering a time value, returning the block height of the last data block before the time value, or returning the hash value of the last data record before the time value and the block height of the data block where the data record is located, may be specifically implemented by the time query instruction LTIME ('timestamp', & v).

In this embodiment of the present specification, if the user no longer needs the service, the entire clearing of data may be performed before the service is ended. For example, the user enters the ledger ID and the server clears the ledger, for example, by a clear command pull (lgid), or the user also enters a time period, the server first archives the ledger, and after the time period, the server clears the ledger, for example, by a clear command pull (lgid).

And as the data of the user is continuously increased, the storage space is more and more occupied, or some long-time historical data are no longer valuable to the user, the database server can also perform corresponding partial clearing on the data block based on the requirement of the user. Partial purging may be performed on a block high or time point basis.

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

For another example, the user specifies the book ID and the time point, 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 that need to be cleared, and then clears the data blocks that are determined to need to be cleared, which may be implemented by a clear command PURGE (i, d-a, 'timestamp').

Before the partial removal is performed, because the hash value of the first data block of the removed data block chain is generated based on the hash value of the previous data block, at this time, a pseudo initial data block needs to be generated, and the hash value of the pseudo initial data block is equal to the hash value of the determined last data block needing to be removed, so that errors can be avoided when verification is performed later. The hash value of the last data block may be obtained by querying from a pre-established index, or may be obtained by sequentially calculating from the initial data block, or by querying from the data block.

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

In addition, partially purged data is typically backed up for the user. Based on this, during the process of partial clearing by the user, verification for confirming that the data needing partial clearing is needed can be inserted. Fig. 3 is a schematic flow chart of an exemplary partial purge provided by an embodiment of the present disclosure, as shown in fig. 3. In the schematic diagram, the user inputs the time point, and specifically, the generation time of the data block closest to the time point may be obtained by first querying, then the block height of the data block corresponding to the generation time is obtained, the pseudo initial data block is generated and signed, and then the partial clearing operation is performed.

In practical applications, some data (referred to herein as sensitive data) once written into a data block can have deleterious consequences. For example, company a uploads data with a data record with a leaf XX, a gender male and a id number of 123456, and the id number of the data record reveals user privacy and needs to be concealed.

Since the modification or cleaning of any data record in the solution provided by the embodiment of the present specification can cause the verification of other data blocks to be erroneous, the embodiment of the present specification also provides a method for hiding sensitive data, and specifically, the core technical means is to replace the data record in which the information to be hidden in the data block is located with the hash value of the data record. In this way, disclosure of the sensitive information can be stopped without disturbing smooth operation of the data block system.

Specifically, the user may directly specify the position of the information to be concealed, or in practical applications, the user may issue a concealed information instruction carrying the position information. The position information here includes the block height of the data block, the offset of the data record in the block height, the offset of the information to be suppressed in the data record, the length of the information to be suppressed, and so on.

For example, an exemplary suppress 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 suppress 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, and information determined by the length of the beginning at the offset specified in the data record is suppressed.

The information obtained by replacing or removing the hidden information is no longer used as a data record, and may be called remark information. In the process of hiding information, a feasible way is to determine a hash value of a data record in which the information to be hidden 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 data formed by splicing the front marker character, the transaction hash, the rear marker character and the remark information as the hidden data record. Fig. 4 is a schematic diagram of a process for constructing a suppressed data record according to an embodiment of the present disclosure, as shown in fig. 4.

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

In addition, it should be noted that the hiding of the history data record is a relatively strict operation. It often symbolizes the disclosure of some information that triggers laws and regulations or violates morals, and also often concludes that mandatory processing of information is required after adjustment or trial by multiple parties. Therefore, when performing the above-mentioned clearing operation, one possible way is to: the clear operation requires a certain signature weight.

For example, for an operation instruction issued by a general user, the background default signature weight is 30, the signature weight useful for a service party or other transaction systems is 60, the signature weight for a state enforcement agency issuing an operation instruction such as a court is 120, and the signature weight required for a clearing operation is preset to be 100. The execution weight of an operation may be the sum of the signature weights of the participants, and in general, the participants may be set not to exceed 2. In this embodiment, at least two digital signatures of authorities (e.g., a transaction system side and a database server side) associated with the data records are required to be performed. That is, the database server can perform clearing only after the transaction system side initiates a clearing instruction and signs and the database server side receives the clearing instruction and signs. And the clearing instruction initiated by the end user cannot be executed even if the database service side performs signature authorization because the signature weight is not enough.

Further, the database server may also provide other database service modes, such as:

during the filing period, retrieving the user data book, which is realized by retrieving an instruction record (lgid), wherein the book refers to a set containing all data blocks;

returning the block height of the current last data block, which is realized by an instruction GETHEIGHT (& v);

return user ledger ID, 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 method provided by the present application. However, the form of the operation instruction is not limited to the form proposed in the embodiments of the present specification, and in practice, the form of the operation instruction for data may be various, and only the service mode proposed in the present application may be implemented. And the query instruction only provides an external form convenient for user operation, and the execution mode of the query instruction is still dependent on the execution mode corresponding to each instruction when the server receives the instruction and executes the instruction.

Further, after generating the data blocks, the server may also give a corresponding timestamp for each block. For example, a national time service center interface is introduced, and the block is output by adopting a credible timestamp when the block is output. Thus, the index can be built depending on the time stamp.

In one embodiment, for any data block, if there is a receiving timestamp in the data records in the block, for example, the server gives a receiving timestamp when receiving the data records, the data records may be sorted according to the receiving timestamp, and each data record is assigned a sorting sequence number; or the sequence numbers may be assigned directly in the order in which the data records were received and reset after blocking so that the sequence numbers are assigned partially within the next data block.

After the sequence number is determined, the sequence number and the hash value may be concatenated according to the determined hash value of each data record. Specifically, a substring with a specified length may be added to the head or the tail of the hash value to place a sequence number, generate a time-series hash string of the data record, and then establish a first index table containing a correspondence between a blocking timestamp of the data block and the time-series hash string of the data record according to the sequence of the sorted 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 have inserted a corresponding sequence number string, where "0 x" is used to identify the next sequence number, where "0001" is the sequence number, "hash 1" 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 manner, the significand of the timestamp is fully retained. The "0 x" can be used to identify the subsequent part as the sequence number, which is convenient for parsing.

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 the index table, each data record has both the blocking time of the written block and the sequence accepted by the server, so that some data records with precedence correlation can be conveniently inquired and traced based on the index table.

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 sorted according to the receiving timestamp, and each data record is assigned a sorting sequence number; or the sequence numbers may be assigned directly in the order in which the data records were received and reset after blocking so that the sequence numbers are assigned partially within the next data block.

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

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, 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), although a few time significands are sacrificed.

The index creation may be performed immediately at the time of block output or asynchronously. The index itself may be used for some lookup or statistical operations, for example, to count the number of data records in a certain time period, so as to avoid performing traversal counting from the data block, which is more convenient.

In addition, when data is stored using a block-chained ledger, one ledger usually includes a plurality of data blocks in succession. In practical applications, the data blocks are often numbered using natural sequence numbers. For example, the initial data block has a block height of 1, and each subsequent data block is added with a block height of 1. Based on this, the embodiments of the present specification further provide a block height creating method, specifically, a blocking time of a data block is determined, then a symmetric encryption algorithm is adopted to convert the blocking time into integer data, the integer data is used as the block height of the data block, and the earlier the blocking time is, the smaller the integer data is.

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

For example, for a chunk time "20 xx-01-1903: 14: 07.938576", after symmetric encryption, it can be converted to a large integer "1547838847938", which is "1547838847938" because the integer data monotonically increases over time. The block height of the data block can be used to identify the data block. In this specification, the block height is monotonically increased based on the blocking time, so that even if large integer data is used, the order between them is still from small to large, reflecting the order between the data blocks. For example, if the blocking time of the next data block is "20 xx-01-1903: 16: 07.235125", it can be converted into another larger large integer "1547838848125" by using a preset symmetric encryption algorithm.

Based on this, the sequence numbers of the service logs in the data block can be determined as in the foregoing manner, the block heights and the sequence numbers are spliced, the time sequence information of the service logs including the block heights and the sequence numbers is generated, and a third index table of the hash values and the time sequence information of the service logs is established. As shown in table 3, table 3 is a third index table provided in the examples of the present specification. In this table, the large integer on the left side is timing information including a block height and a sequence number, the block height being obtained based on time symmetric encryption. In the case of blocking time accurate to the millisecond level, the third index introduces 3 decimal digits after the block height to identify the sequence number (i.e. defining a block threshold of 999), so the assumption of throughput is in the order of millions, and any practical trading scenario can be satisfied. If the throughput is higher, more decimal systems are introduced to identify the sequence numbers after the block height.

TABLE 3

1547838847938000	1547838847938
		1547838847938001	Hash1
1547838847938002	Hash2
		1547838847938003	Hash3
1547838847938004	……

In a practical application scenario, the database service provider involved in the embodiments of the present specification 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 specification, including a database base service provider and a database enhanced service provider. For example, MySQL, PostgreSQL, MongoDB, etc. are basic service providers of databases, and these database systems can provide basic services for business systems, such as adding, deleting, modifying, etc. Meanwhile, the data base service providers and the data base service providers store corresponding business operation logs for the operations locally, and the business operation logs record operation records of the data base service providers for the business data. The system for providing further services for the database basic service provider is the database enhanced service provider Ledger server provided by the embodiment of the specification.

Based on this, the present specification embodiments also provide a way that can provide further enhanced services for database base service providers. Specifically, after the service operation logs are generated by the databases such as MySQL, PostgreSQL, MongoDB, and the like, the service operation logs generated by the databases may be sent to the legger. Because the service operation logs are all 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. When the database basic service provider generates the system operation log, the database basic service provider does not need to immediately send the system operation log to the Ledger system, and the database basic service provider can be an asynchronous sending process.

Each database basic service provider can send the service operation log to the Ledger system in a clear text mode. "plaintext" herein means that the service operation log sent by each database can be understood or partially understood by the Ledger system. For example, a certain database and the Ledger system make the Ledger system know the operation type, the operation service object, and the like in the service operation log by formulating a communication protocol in advance, so that the Ledger system can further perform blocking according to the operation type or the operation target object when blocking, so as to perform better management on each database system. In this way, if each database needs to perform query or statistics on itself (for example, statistics on how many times the data of which service object is cleared), it may only need to send an instruction, and a specific statistics or query process may be completed at the end of the legger system.

Of course, each database basic service provider may also send the service operation log to the legger system in a "ciphertext" manner. The "ciphertext" refers to the fact that the Ledger system cannot understand the service operation logs sent by the databases. In this way, each database can only read or clear the stored service operation log to the Ledger system, and the specific query or statistical work needs to be performed locally at the database basic service provider after reading the data.

In one implementation scenario, for example, where the data records are cost information about a business, the data records need to be audited. When a new account book is manufactured by preventing a false-forging time stamp by combining an enterprise and a service party, time service authentication of data blocks to some authoritative time justice institutions is an indispensable technical means. The time fairness institution may be, for example, a national time service center, or an authoritative time certification institution permitted by the national time service center. Here, the time service authentication is: a signature associated with the time-fairness authority is obtained, where the signature includes a trusted timestamp issued by the time-fairness authority corresponding to the block of data requiring authentication.

Specifically, the server first determines a segment of account book that needs time service authentication from the generated and stored data blocks, wherein the segment of account book at least should contain one data block or multiple data blocks with high continuity. The determined mode can be specified based on user operation, for example, a user initiates a time service instruction, and the instruction comprises an initial block height and a block number which need to be subjected to time service authentication; or the server side can automatically perform the operation based on the preset business logic without the specification of the user.

For example, from the finest granularity, each data block may be requested for a time service. In this way, the root hash of the merkel tree is the block hash value of the data block, and the method can protect the authenticity of the ledger (i.e. each data block) to the greatest extent. Due to the high block output frequency of the data blocks, the cost overhead is high for both the time service center and the service party. An optional mode is that a certain time service preset condition is set, and when the certain time service preset condition is met, a time service request is initiated. When the newly generated data blocks are all considered to be data blocks to be subjected to time service authentication, the time service preset condition may be: and the data blocks to be subjected to time service authentication reach a quantity threshold value, or the time interval from the last time service authentication reaches a time threshold value.

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 sequence of block height, and the merkel trees corresponding to the data blocks are generated based on the block hashes of the data blocks, so that the root hashes of the merkel trees are confirmed. And, the information related to the data block to be time-granted authenticated includes, for example, information such as the starting block height, the ending block height, or the number of data blocks. And then sending the root hash of the Mercker tree and the related information of the data block to a time fairness mechanism. The time justice organization receives the information, namely, a trusted timestamp is given, digital signature authentication is carried out on the trusted timestamp, a time service certificate containing the trusted timestamp and a digital signature is generated, the time service certificate can also contain the related information of the data block, and the digital signature mode is only conventional private key encryption and public key decryption.

Thus, the server may receive a series of trusted timestamps containing a time fair authority signature, each trusted timestamp corresponding to a segment of the ledger, and may know unambiguously which segment of the data block based on the relevant information. The server can perform corresponding management and verification based on the trusted timestamp. For example, when a certain account book needs to be audited, the server may give a time certificate that a corresponding data block in the account book includes a trusted timestamp of a time justice authority and a signature, and recalculate the tacher root hash according to related information included in the time certificate, so that it can be confirmed that the data block corresponding to the certificate is unlikely to be forged in the future, and the server and the served party can be effectively prevented from jointly manufacturing the account book including the false timestamp to avoid corresponding audit. Fig. 8 is a schematic diagram of a specific generation of a time service certificate according to an embodiment of the present disclosure, as shown in fig. 8.

Correspondingly, an embodiment of the present specification further provides a data adding device, which is applied to a centralized database service provider that stores data by a plurality of data chunks, as shown in fig. 6, fig. 6 is a schematic structural diagram of the data adding device provided in the embodiment of the present specification, and includes:

the receiving module 601 is configured to receive an adding instruction for adding a data record by a user, where the adding instruction includes a data record to be added;

a determining module 603, configured to determine a hash value of the data record to be added;

returning to the module 605, and returning the hash value to the user;

the cache module 607 is configured to store the data record to be added in a local cache, so that when a preset blocking condition is met, the data record is written into a new data block;

Further, the method further includes a writing module 609, when a preset blocking condition is reached, determining each data record in the data block to be written, and generating an nth data block including the hash value of the data block and the data record, specifically including:

when N is 1, the hash value and the block height of the initial data block are given based on a preset mode;

and when N is greater than 1, determining the hash value of the Nth data block according to the hash values of the data records to be written in the data block and the (N-1) th data block, and generating the Nth data block comprising the hash value of the Nth data block and the data records, wherein the block height of the data block is monotonically increased based on the sequence of the blocking time.

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

Further, the apparatus further includes a server signing module 611, which encrypts the data record by using a server private key to generate a server private key signature for 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.

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 executes the program to implement a data adding method shown in fig. 2.

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).

Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in 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 is executed by a processor to implement a data adding method 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 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

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

2. The method of claim 1, wherein at the centralized database service provider, the data chunks 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 to be written into the data block, and generating an nth data block containing the hash value of the data block and the data record, specifically comprising:

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

the number of data records to be stored reaches a number threshold; or,

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

4. The method of claim 1, returning the hash value to a user, comprising:

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.

5. A data adding apparatus applied in a centralized database service provider that stores data by a plurality of data chunks, the apparatus comprising:

the returning module returns the hash value to the user;

6. The apparatus according to claim 5, further comprising a writing module, when a preset blocking condition is reached, determining each data record in the data block to be written, and generating an nth data block including the hash value of the data block and the data record, wherein when N is 1, the hash value and the block height of the initial data block are given based on a preset manner; and when N is greater than 1, determining the hash value of the Nth data block according to the hash values of the data records to be written in the data block and the (N-1) th data block, and generating the Nth data block comprising the hash value of the Nth data block and the data records, wherein the block height of the data block is monotonically increased based on the sequence of the blocking time.

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

the number of data records to be stored reaches a number threshold; or,

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

8. The apparatus of claim 5, further comprising a server side signing module that encrypts the data record with a server private key, generating a server private key signature of the data record;

and the return module returns 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.

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 when executing the program implements the method of any one of claims 1 to 4.