CN109902071B

CN109902071B - Service log storage method, system, device and equipment

Info

Publication number: CN109902071B
Application number: CN201910101178.8A
Authority: CN
Inventors: 杨新颖
Original assignee: Alibaba Group Holding 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: 2020-06-30
Anticipated expiration: 2039-01-31
Also published as: CN109902071A

Abstract

A method, system, device and equipment for storing service log are disclosed. The database basic service side processes the business data and immediately generates a corresponding business log recording the specific operation mode. The service log is sent to the enhanced database service provider, the enhanced database service provider writes the service log into the block chain type account book for storage, and the basic database service provider provides the service for storing the service log which can be hidden but not tampered and can be verified by cryptography.

Description

Service log storage method, system, device and equipment

Technical Field

The embodiment of the specification relates to the technical field of information, in particular to a method, a system, a device and equipment for storing a service log.

Background

The current core transaction systems themselves each contain a corresponding service database. These databases, acting as the basic service providers, already can meet normal business requirements.

When the core transaction system performs operations such as adding, deleting, modifying, checking and the like on a database basic service side, corresponding service logs can be generated at the same time, the logs reflect operation records of the transaction system on service data, and the service logs are generated at any moment, are large in quantity and are not concerned when problems occur. However, when a database basic service provider fails, data recovery is often performed by using the service log, but it is difficult to know whether the service log is tampered by a person or has an error.

Based on this, there is a need for a non-tamperable and verifiable service log storage scheme.

Disclosure of Invention

In view of the problems that it is difficult to know whether a business log of a self-service party has errors and cannot be verified in an existing database basic service party, in a first aspect, an embodiment of the present specification provides a business log storage method, apparatus and device, where the method is applied to a system that includes a database basic service party and a centralized database enhanced service provider that stores business logs by a plurality of data blocks, and specifically includes:

the database basic server side sends a service log to be stored to a database enhanced service provider, wherein the service log is used for recording the operation record of the database basic server side on service data;

the database enhanced service provider receives the service log to be stored and determines the hash value of the service log; when a preset blocking condition is reached, determining at least one service log to be written into a data block, and generating an nth data block including a hash value of the data block and the service log, 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; when N is greater than 1, determining the hash value of the Nth data block according to the content of a service log to be written in the data block and the hash value of the (N-1) th data block, and generating the Nth data block comprising the hash value of the Nth data block and the service log, wherein the block height of the data block is monotonically increased based on the sequence of blocking time;

the database enhancement service provider returns a hash value to a database basic server, wherein the hash value comprises a hash value of the service log and/or a hash value of the block height of the service log;

and the database basic service side receives and stores the hash value of the returned service log.

Correspondingly, the embodiment of the specification also provides a business log storage system, which comprises a database basic service party and a centralized database enhanced service provider for storing business logs through a plurality of data blocks, wherein in the system,

In a second aspect, embodiments of the present specification further provide another service log storage method for enhancing a service provider by using a centralized database storing service logs through a plurality of data blocks, the method including:

receiving a service log to be stored, and determining a hash value of the service log;

when a preset blocking condition is reached, determining at least one service log to be written into a data block, and generating an nth data block including a hash value of the data block and the service log, 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 content of the service log to be written in the data block and the hash value of the (N-1) th data block, and generating the Nth data block comprising the hash value of the Nth data block and the service log, wherein the block height of the data block is monotonically increased based on the sequence of blocking time.

Correspondingly, an embodiment of the present specification further provides a service log storage apparatus, which is configured to enhance a service provider by using a centralized database that stores service logs through a plurality of data blocks, where the apparatus includes:

the receiving module is used for receiving the service log to be stored and determining the hash value of the service log;

the generating module, when a preset blocking condition is reached, determines at least one service log to be written into a data block, and generates an nth data block including a hash value of the data block and the service log, specifically including:

The database basic service side processes the business data and immediately generates a corresponding business log recording the specific operation mode. The service log is sent to the enhanced database service provider, the enhanced database service provider writes the service log into the block chain type account book for storage, and the basic database service provider provides the service for storing the service log which can be hidden but not tampered and can be verified by cryptography.

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 flowchart of a service log storage 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 service log according to an embodiment of the present disclosure;

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

fig. 6 is a schematic structural diagram of a service log storage 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 flowchart illustrating another service log storage method provided in 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 infrastructure may be a client individual user directly connected to the database infrastructure, or may be a client individual user connected to some application server, and the database infrastructure is connected to the application server. As shown in fig. 1, fig. 1 is a schematic diagram of a system architecture involved in the prior art. Basic operations (including adding, deleting, searching and the like) of the application server on the business data are carried out on the database basic service side, and the generated business logs are generally stored locally on the database basic service provider. In this embodiment, the database system needs to drop a part of the load to be responsible for the storage and management of the service log.

In order to better release the load of a database basic service party, improve the overall efficiency of a transaction system, and better store and manage a service log, an embodiment of the present specification provides a database serving the database, that is, a database enhanced service provider referred to in the embodiment of the present specification, and the overall architecture is as shown in fig. 5, and fig. 5 is a schematic diagram of another system architecture provided in the embodiment of the present specification. The MySQL, PostgreSQL, MongoDB and the like are basic service providers of databases, and the database systems can provide basic services of operations such as adding, deleting, modifying and the like for common transaction systems. Meanwhile, the data processing system and the data processing method also have the corresponding service operation logs for the operations stored locally, wherein the 'binlog', 'xlog' and 'journallog' are service logs generated by various different types of databases. The operation log records the operation record of the database basic service provider on the service data. The system for providing further services for the database basic service provider is the database enhanced service provider provided in the embodiments of the present specification, which is a legger server in the schematic diagram.

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 flowchart of a business log storage method provided in an embodiment of this specification, and is applied to a system including a database base server and a centralized database enhanced service provider that stores business logs by multiple data blocks, where the process specifically includes the following steps:

s201, a database basic service party sends a service log to be stored to a database enhanced service provider, wherein the service log is used for recording operation records of the database basic service party on service data.

The sending may be synchronous sending, that is, each time a new service log is generated, the service log is sent to the database enhanced service provider at the same time. It may also be sent asynchronously, e.g., during off-peak times of daily traffic processing, to send traffic logs. In asynchronous transmission, each service log should contain a timestamp. The operation mode for updating the database is usually recorded in the service log, for example, SQL statements for changing database tables or changing contents, etc., which may reflect the operation records of the base service side of the database for the service data.

S201, a database enhanced service provider receives a service log to be stored and determines a hash value of the service log; and when a preset blocking condition is reached, determining at least one service log to be written into the data block, and generating an Nth data block comprising the hash value of the data block and the service log.

The preset blocking condition comprises the following steps: when the number of the service logs to be stored reaches a number threshold, for example, a new data block is generated every time ten service logs are received, ten service logs are written into the block according to the sequence of the time stamps of the service logs, and the method is more suitable for asynchronous transmission of the service logs; or, the time interval from the last blocking time reaches the time threshold, for example, a new data block is generated every 5 minutes, and the service log received in the 5 minutes is written into the block according to the reception time, which is more suitable for synchronous transmission of the service log. Obviously, if no new traffic log is received at regular intervals, it may not be necessary to generate new data blocks at this time.

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, for example, large integer data obtained by symmetric encryption conversion of blocking time is taken as the block height, and the large integer data monotonically increases based on time.

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 a service log, the hash value is any given hash value, and the block height blknum is 0; for another example, the generation trigger condition 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 the contents of all the traffic logs 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 service log 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 entire service log may be obtained by performing concatenation and hashing in the order of the service logs in the block, the hash value of the previous data block and the hash value of the entire service log may be concatenated, and the hash value of the nth data block may be generated by performing hash operation on the concatenated string.

S205, the database enhancement service provider returns a hash value to the database basic server, wherein the hash value comprises the hash value of the service log and/or the hash value of the block height of the service log.

That is, each time a service log is written into a block, the hash value corresponding to one service log is returned to the database basic service side, and the hash value of the data block described in the service log can also be returned to the database basic service side. So that the database base server can query or verify based on the hash value, etc.

And S207, the database basic service side receives and stores the hash value of the returned service log.

By the above-mentioned data block generation method, 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 the service log in the data block and the hash value of the previous data block. The user can initiate correctness verification on the whole account book at any time based on the hash value of the data block, or perform existence verification on the hash value of the service log, or modify any content (including modification on the content or sequence of the service log in the data block) in any data block, which causes inconsistency between the hash value of the data block calculated during verification and the hash value generated during generation of the data block, thereby causing verification failure, and realizing non-falsification of the service log written in the block.

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

In a specific embodiment, the database base server may send the service log to be stored to the database enhanced service provider based on a pre-established communication protocol. Namely, the service operation log can be sent 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.

For example, a service log sent by any database basic service party carries an ID, so that the database enhanced service provider can generate a special account book for each database basic service party; for another example, a service log sent by any database basic service party carries a service ID, so that the database enhanced service provider can generate an account book for one service.

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. Further, for better security, the service log may be encrypted and then sent, so that the encrypted service log is stored in the database enhancing service. 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.

After the service log is written into the data block, the service log is stored in the Ledger system in a non-tampered manner, at this time, if the database basic service side needs the service log, an acquisition request for acquiring the service log may be sent, where the acquisition request includes a block height or a time point, for example, a request instruction GET (& v, timestamp) or GET (& v, blkhight) is sent, where timestamp is a time point specified by the database basic service side, and blkhight is a specified block height. And the database enhancement service provider can take the generated data block with the block height or before the time point as a target data block and return the service log contained in the target data block.

If there is a communication mechanism between the database infrastructure service provider and the Ledger system, for example, the Ledger system can know which service logs are the service logs of the database infrastructure service provider through the database infrastructure service provider, at this time, only the service logs of the database infrastructure service provider in the target data block can be returned, and all the service logs in the target data block do not need to be returned.

After the service log is stored, some related index information may be re-established, for example, because the service log is stored in the data block, and there is no hash value of the service log. Therefore, in order to conveniently find any service log, an index which takes the hash value of the service log as a key and takes the block height of the data block where the service log is located and the offset of the service log in the data block where the service log is located as values can be established and stored. Therefore, the service log can be inquired more conveniently. 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 database base server, so that the database base server may also conveniently query or verify any service log according to the index.

In the query process, the block height of the data block where the service log is located, the offset of the service log in the data block where the service log is located or the full service log text can be obtained through query based on the hash value input by the database basic service side, or the block height of the data block corresponding to the hash value of the obtained data block is obtained through query, and a query result is 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 database basic service party. The hash value here may be a hash value of a service log 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 exemplary lists several query modes provided by the embodiments of the present specification, where the database basic service party inputs a query instruction, and the query instruction may have different parameters specified by the database basic service party:

firstly, inputting a hash value of a data block, inquiring by a database enhanced service provider, and returning all data plaintexts in the data block; or, the hash value of the service log is input, and the database enhanced service provider returns the service log plaintext, which may be specifically implemented by using a query command SELECT (khush, & v), and when the database enhanced service provider receives a corresponding query command, the foregoing query logic is executed based on the hash value to return a result.

Secondly, inputting a hash value of the service log, querying by a database enhanced service provider based on the hash value, returning the block height of a data block where the service log is located and the offset in the data block, specifically, using a query instruction SELECT (khush, & v, FULL);

and thirdly, inputting the hash value of the data block, querying by the database enhanced service provider based on the hash value, and returning the block height. In particular, it may be implemented using a query instruction SELECT (khush, & v, BLK).

Of course, there may be a case where the database basic service provider inputs a hash value, and the database enhanced service provider cannot query the corresponding result. For example, the database basic service side inputs a hash value corresponding to a service log, and the service side cannot inquire the result, at this time, if the hash value is correct, the database basic service side can reasonably suspect that the service log corresponding to the hash has been changed, possibly tampered, or data loss may occur.

Further, in the storage process, the database enhanced service provider may also provide a signature of a corresponding service platform, specifically including the following ways: encrypting the hash value by adopting a server private key to generate a private key signature of the server on the hash value; and returning the private key signature and the hash value to the database basic service party. Therefore, the database basic service side can receive the private key signature and the hash value, decrypt the private key signature of the hash value by adopting the corresponding public key for verification, and can confirm that the hash value is admitted by the database enhanced service provider after the verification is passed. Specifically, the database base server may request the server to provide the signature in an add instruction, and the following is an exemplary instruction for returning an add record of the signature provided in the embodiment of the present specification:

and (v, & khush, CERT) returning the hash value corresponding to the service log and the signature certificate of the enhanced service provider of the database.

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 database basic service party may also actively initiate verification on a plurality of data blocks already existing in the database, specifically, the database basic service party may initiate a verification instruction, where the verification instruction specifies which data blocks need to be verified through a parameter, for example, a data block may be specified through a hash value or a block height, and whether correct verification is initiated on a plurality of data blocks before or after the data block; or, a service log is designated by the hash value, and whether the service log exists in the database is verified. The result of the verification is a "present" or "absent" and a "correct" or "incorrect" such metadata.

The data blocks may be verified in a manner 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 values of the data blocks already included in the data block, and if the current hash values are not identical, the verification fails.

The following exemplary shows several ways of verifying instructions 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 by the hash value or determining a data block where a service log 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, the-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 service log, or the database enhanced service provider further generates an index related to the data parameter and the time in advance, for example, a data block timing index of a block height and a blocking timestamp, or a service log timing index of a hash value of the service log and the timestamp, or an index of the hash value of the data block and the blocking time, etc., when the data block is blocked, the database enhanced service provider may further provide a corresponding time query manner. Further, in the generated time sequence index, the time sequence index can be arranged according to the time stamp sequence, so that query or statistics can be conveniently carried out.

In other words, the corresponding chunk high or hash value may be queried from the data chunk or the index by the time value, or the corresponding time value may be queried by the hash value or the chunk high, and the following exemplary lists several time-based query manners provided by the embodiments of the present specification:

first, a database basic service provider inputs a block height, and a database enhanced service provider queries 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, the database basic service side inputs a hash value, the database enhanced service side returns a timestamp corresponding to the hash value, the hash value can be a hash value of a data block or a hash value of a service log, and specifically, the hash value can be realized by a TIME query instruction TIME ('khash', & v).

Thirdly, the database basic server inputs a time value, and the database enhanced service provider returns the block height of the last data block before the time value, or returns the hash value of the last service log before the time value and the block height of the data block where the service log is located, which can be realized by the time query instruction LTIME ('timestamp', & v).

In this embodiment, if the database basic service party no longer needs the service of the service log, the service log may be cleared entirely before the service is finished. The database base server side inputs its own book ID for clearing, for example, by a clearing command pull (lgid); alternatively, the database basic service provider may further input a time length, the database enhanced service provider archives the account, and after the time length is reached, the database enhanced service provider clears the account, for example, by a clear-command PURGE (valid-archive).

And because the data of the database basic service side is continuously increased, the storage space is more and more occupied, or some long-time historical data are no longer valuable, and at the moment, the database service side can also carry out corresponding partial clearing on the data block based on the requirement of a user. Partial purging may be performed on a block high or time point basis.

For example, the database basic service side specifies the ledger ID and the block height, and the database enhanced service provider 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 database base server specifies the book ID and the time point, and the database enhancement server determines the last generated data blocks before the time point based on the time point, determines all 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 database enhanced service provider may also sign the pseudo-initial data block.

In addition, the partially cleared data can be backed up for the database base service side. Based on this, in the process of partial clearing by the database basic service side, 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 database basic service side inputs a time point, and specifically, a generation time of a data block closest to the time point is obtained by querying, a block height of the data block corresponding to the generation time is obtained, a pseudo initial data block is generated and signed, and then a partial clearing operation is performed.

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

during the filing period, retrieving a data ledger, which is a set including all data blocks, by a retrieving command record (lgid);

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 the user to operate, and the database enhanced service provider still depends on the execution mode corresponding to each instruction when receiving and executing the instruction.

Further, after generating the data chunks, the database enhanced service provider may also give a corresponding timestamp for each chunk. 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 the service log in the block has a receiving timestamp, the service log may be sorted according to the receiving timestamp, and each service log is assigned a sorting sequence number; or the sequence numbers may be assigned directly in the order in which the traffic logs were received and reset after blocking so that the sequence numbers are assigned to the next portion of the 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 service log. 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 character string of the service log, and then establish a first index table including a correspondence between a blocking timestamp of the data block and the time-series hash character string of the service log according to the sequence of the sorted sequence numbers. As shown in table 1, table 1 is a first index table about a service log provided in an embodiment of the present specification. In table 1, the first 6 bits of the hash value of the service log are inserted with 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.

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 manner, for any data block, if the service log in the block has a receiving timestamp, the service log may be sorted according to the receiving timestamp, and each service log is assigned with a sorting sequence number; or the sequence numbers may be assigned directly in the order in which the traffic logs were received and reset after blocking so that the sequence numbers are assigned to the next portion of the data block.

At this time, the last designated number of bits in the blocking timestamp may be eliminated for writing the sequence number of the service log. In addition, a designated sequence number that is not assigned to the service log may be added to the index to store a correspondence between the block timestamp and the block height of the data block, and the index may be written. For example, the sequence number of the traffic log 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 the service log provided in the embodiment of the present specification. In table 2, the last three bits of the blocking time on the left side (assuming that the number of the service logs stored in one block does not exceed 1000) are used to store the sequence numbers of the service logs.

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 traffic log 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-significance bits are sacrificed.

The index creation may be performed immediately at the time of block output or asynchronously. The index itself can be used for some searching or counting operations, for example, counting the number of service logs in a certain time period, avoiding performing traversal counting from the data block, and being 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 practical applications, some service logs may contain sensitive information for privacy reasons such as business confidentiality, and the like, and the sensitive information needs to be concealed if written into a data block.

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

Specifically, the database basic service side may directly specify the position of the information to be concealed, or in practical applications, the database basic service side may also issue a concealed information instruction carrying the position information. The location information here includes the block height of the data, the offset of the service log in the block height, the offset of the information to be concealed in the service log, the length of the information to be concealed, etc.

The database enhanced service provider receives a hiding information instruction, determines the information to be hidden according to the position information, and determines the hash value of a service log in which the information to be hidden is positioned; and replacing or clearing the information to be concealed to generate a concealed service log, wherein the concealed service log comprises a hash value of the service log in which the information to be concealed is located.

For example, an exemplary suppress information instruction may be DELETE (blkhight, txoff), under which a service log is suppressed that corresponds to a specified block height blkhight and a specified offset txoff;

as another example, another exemplary suppress information instruction may be DELETE (blkhight, txoff, offset, length), under which a traffic log 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 traffic log is suppressed.

The database enhanced service provider replaces or clears the hidden information to obtain information, which is no longer used as a service log and can be called remark information. In the process of hiding the information, a feasible way is to determine a hash value of a service log 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 service log. Fig. 4 is a schematic diagram of a process for constructing a concealed service log 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 function of the pre-marked character is that when the service log needs to be read in the later verification, then the pre-marked character reveals information to the node: "the storage location stores not the plaintext content of the service log but the hash value of the service log". At this time, the hash value can be directly read for verification. When the corresponding remark information needs to be read, the remark information can be read from the rear marked 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 service log before the concealment or can be completely empty (namely, the content of the whole service log is completely concealed).

In addition, it should be noted that the hiding of the historical service log is a stricter 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 normally issued by a database basic service provider, the background default signature weight is 30, the signature weight of a database enhanced service provider is 60, the signature weight of an operation instruction issued by a national enforcement agency 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., transaction system side and database server side) associated with the transaction log are required to execute. 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. Whereas a hidden instruction initiated by the database base server may not execute because the signature weight is not sufficient.

In a second aspect, an embodiment of the present specification further provides a service log storage method, which is implemented by using a centralized database that stores service logs through multiple data blocks to enhance a service provider, as shown in fig. 8, where fig. 8 is a schematic flow diagram of another service log storage method provided in an embodiment of the present specification, and the method includes:

s801, receiving a service log to be stored, and determining a hash value of the service log;

s803, when a preset blocking condition is reached, determining at least one service log to be written into the data block, and generating an nth data block including the hash value of the data block and the service log, specifically including:

Corresponding to the second aspect, an embodiment of the present specification further provides a service log storage apparatus, which is applied to a centralized database service provider that stores data by multiple data blocks, as shown in fig. 6, where fig. 6 is a schematic structural diagram of a service log storage apparatus provided by an embodiment of the present specification, and includes:

the receiving module 601 is configured to receive service logs to be stored, and determine hash values of the service logs;

the generating module 603, when a preset blocking condition is reached, determines each service log to be written into the data block, and generates an nth data block including a hash value of the data block and the service log, specifically including:

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

Embodiments of the present specification further provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the service log storage method shown in fig. 8 when executing the program.

Fig. 7 is a more specific hardware structure diagram of a computing device provided in an embodiment of the present specification, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.

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

The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

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, and when the computer program is executed by a processor, the computer program implements the service log storage method shown in fig. 8.

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 service log storage method applied to a system including a database base server and a centralized database enhanced service provider that stores service logs through a plurality of data blocks, the method comprising:

the database basic service side receives and stores the hash value of the returned service log;

the preset blocking condition comprises the following steps: the number of the service logs to be stored reaches a number threshold; alternatively, the time interval from the last chunking time reaches a time threshold.

2. The method of claim 1, sending the traffic log to be stored to a database enhanced service provider, comprising:

sending a service log to be stored to a database enhanced service provider based on a communication protocol pre-established between the database basic service provider and the database enhanced service provider; alternatively, the first and second electrodes may be,

and symmetrically encrypting the service log to be stored, generating an encrypted service log to be stored, and sending the encrypted service log to be stored to a database enhanced service provider.

3. The method of claim 1, further comprising:

the database basic service side sends an acquisition request for acquiring the service log, wherein the acquisition request comprises a block height or a time point, and receives the service log returned by the service side;

the database enhanced service provider receives an acquisition request sent by a database basic server, obtains a block height or a time point in the acquisition request, determines a generated data block before the block height or the time point as a target data block, and returns a service log contained in the target data block.

4. The method of claim 1, further comprising:

the database enhanced service provider establishes an index which takes the hash value of the service log as a key and takes the block height of a data block where the service log is located and the offset of the service log in the data block where the service log is located as values, and stores the index; or, establishing an index with the hash of the data block as a key and the height of the data block as a value, and storing the index.

5. The method of claim 1, further comprising:

the database basic server side sends a query instruction to the database enhanced service provider side, wherein the query instruction comprises a hash value to be queried, and the hash value is a hash value of a service log or a hash value of a data block; receiving a query result returned by a database enhanced service provider;

and the database enhancement service provider receives the query instruction, queries the block height of the data block where the service log is located, the offset of the service log in the data block where the service log is located or the plaintext of the service log based on the hash value, or queries the block height of the data block corresponding to the hash value of the obtained data block, and returns a query result.

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

the database enhancement service provider encrypts the hash value by adopting a server private key to generate a private key signature of the server on the hash value; returning the private key signature and the hash value to a database basic service side;

and the database basic service side receives the private key signature and the hash value, and decrypts the private key signature of the hash value by adopting the corresponding public key so as to verify.

7. The method of claim 1, further comprising:

the database basic server side sends a verification instruction to the database enhanced service provider side, the verification instruction comprises a hash value of a service log or a block height of a data block, and the returned verification result is received;

the database enhanced service provider receives a verification instruction and verifies whether a service log corresponding to the hash value in the verification instruction exists or not; or verifying whether the specified number of data blocks determined by the data block height are correct or not, and returning a verification result.

8. The method of claim 1, when the data block further includes a timestamp of the data block or the service log, the method further comprising:

the database basic server sends a time query instruction to the database enhanced service provider, wherein the time query instruction comprises a time parameter or a data parameter, the data parameter comprises a block height or a hash value of a service log, and a return result is received;

the database enhanced service provider receives the time query instruction, acquires a blocking timestamp of a data block which is before the time parameter and is closest to the time parameter, and determines and returns a data parameter corresponding to the timestamp; or determining a timestamp corresponding to the data parameter and returning the timestamp.

9. The method of claim 8, prior to receiving a user's time query instruction, the method further comprising:

and the database enhanced service provider establishes a time index containing the corresponding relation between the data parameters and the time stamps so as to inquire the time parameters or the data parameters from the time index after receiving a time inquiry instruction.

10. The method of claim 9, establishing a time index containing a correspondence of data parameters and timestamps, comprising:

generating a data block time sequence index of a block height and a time stamp according to the time stamp sequence of the data block; alternatively, the first and second electrodes may be,

and generating the hash value of the service log and the service log time sequence index of the time stamp according to the time stamp sequence of the service log.

11. The method of claim 1, further comprising:

the database basic service party sends a clearing instruction to the database enhanced service provider, wherein the clearing instruction comprises a block height or a time point;

the database enhancement service provider receives a clearing instruction and determines the data block generated before the block height or the time point as a data block to be cleared; determining the hash value of the last data block in the data blocks to be cleared; and clearing the data block to be cleared, generating a pseudo initial data block and storing the pseudo initial data block, wherein the hash value of the pseudo initial data block is equal to the hash value of the last data block to be cleared.

12. The method of claim 11, determining the hash value of the last data block of the data blocks to be purged, comprising:

the database enhanced service provider inquires and acquires the hash value of the last data block in the data blocks to be cleared from a pre-established data block index; alternatively, the first and second electrodes may be,

and calculating the hash value of each data block in sequence from the initial data block according to the generation sequence of the data blocks and the service log contained in the data blocks to obtain the hash value of the last data block in the data blocks to be cleared.

13. The method of claim 1, after generating the nth data block comprising the hash value of the data block and the traffic log, the method further comprising:

the database enhanced service provider selects any data block, and determines a blocking timestamp of the selected data block, a receiving timestamp of each service log in the selected data block and a hash value of each service log;

sequencing according to the receiving time stamps of the business logs, and determining the sequencing serial numbers of the business logs in the selected data block;

for any service log, splicing the corresponding sequencing serial number and the hash value of the service log record to generate a time sequence hash character string of the service log;

and establishing a first index table containing the corresponding relation between the blocking time stamp of the data block and the time sequence hash character string of the service log according to the sequence of the sequencing sequence numbers.

14. The method of claim 1, after generating the nth data block comprising the hash value of the data block and the traffic log, the method further comprising:

sequencing according to the receiving time stamps of the service logs, and determining the sequencing serial numbers of the service logs in the data block;

removing the last designated digit in the blocking timestamp aiming at any service log, writing the corresponding sorting serial number into the blocking timestamp, and generating the blocking timestamp containing the sorting serial number;

and establishing a second index table containing the corresponding relation between the blocking timestamps of the sequencing sequence numbers and the hash values of the service logs according to the sequence of the sequencing sequence numbers.

15. The method of claim 14, further comprising:

and the database enhanced service provider adds a corresponding relation between a blocking timestamp containing a specified sequencing sequence number and the block height of the data block in the second index table.

16. The method of claim 1, further comprising:

the database enhanced service provider acquires a blocking timestamp of the data block;

converting the blocking timestamp to integer data using a symmetric encryption algorithm, wherein the integer data is monotonically increasing over time;

determining the integer data as a block height of the data block.

17. The method of claim 1, further comprising:

the database basic server side sends a hiding information instruction to the database enhanced service provider, wherein the hiding information instruction comprises position information of information to be hidden;

18. A service log storage system comprising a database base server and a centralized database enhanced service provider storing service logs by a plurality of data blocks, in which system,

19. A service log storage method for enhancing a service provider using a centralized database storing service logs through a plurality of data blocks, the method comprising:

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

20. A traffic log storage apparatus for enhancing a service provider using a centralized database storing traffic logs through a plurality of data blocks, the apparatus comprising:

21. 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 claim 19 when executing the program.