Detailed Description
In order for those skilled in the art to better understand the technical solutions in the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described in detail below with reference to the drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification shall fall within the scope of protection.
First, a description will be given of a block chain ledger under centralization in the embodiment of the present specification. At a centralized database service provider, a block chained ledger is generated by, as shown in fig. 1, fig. 1 is a schematic flow chart of generating a block chained ledger according to an embodiment of the present disclosure, including:
s101, receiving data records to be stored, which contain specified identification fields, and determining hash values of the data records, wherein the specified identification fields are used for identifying service attributes of the data records.
The data record to be stored can be various consumption records of individual users of the client, or can be business results, intermediate states, operation records and the like generated by the application server when executing business logic based on instructions of the users. Specific business scenarios may include consumption records, audit logs, supply chains, government regulatory records, medical records, and the like.
In each of the institutions interfacing with the database server, the business attributes are generally unique in the interfacing institutions, and based on different business scenarios, the business attributes may include a user name, a user identification number, a driver license number, a mobile phone number, a project unique number, and so on.
For example, for a third party payment mechanism, the data record is a consumption record of the user, and the service attribute at this time is a user identifier (including a mobile phone number, an identity card number, a user name, etc.), or a hash value obtained by performing a hash algorithm on the user identifier; alternatively, for government agencies, where the data records are overhead flows for multiple public items, the business attributes at that time may be unique numbers for each item.
The specific location of the specified identification field and the acquisition mode may be a database server and docking mechanism negotiated in advance. For example, when the data record provided by the docking mechanism is a standard structured data record, the specified identification field may be obtained from a specified offset in the data record, or the starting and ending positions may be identified by specific characters; or when the data records provided by the docking mechanism are unstructured data, the head containing the service attribute can be spliced at the beginning of each data record directly when the docking mechanism uploads the data records, and the database server can obtain the appointed identification field of each data record from the head directly.
And S103, when a preset blocking condition is met, determining each data record in the data block to be written, and generating an N data block containing the hash value of the data block and the data record.
The preset blocking conditions include: the number of data records to be stored reaches a number threshold, for example, each time one thousand data records are received, a new data block is generated, and one thousand data records are written into the block; alternatively, the time interval from the last block forming time reaches a time threshold, e.g., every 5 minutes, a new data block is generated and the data records received within the 5 minutes are written into the block.
Here, N refers to the sequence number of the data block, in other words, in the embodiment of the present specification, the data blocks are in the form of a block chain, and are arranged in sequence based on the sequence of the block forming time, which has a strong timing characteristic. Wherein the block heights of the data blocks monotonically increase based on the order of the block times. The block height may be a sequence number, and at this time, the block height of the nth data block is N; the block heights may also be generated in other ways, such as large integer data (typically monotonically increasing 12 to 15 bit integer data) based on symmetric encryption of the block time stamps of the data blocks, e.g., a large integer of 13 bits. Since the large integer is based on time symmetric encryption, when the block time of the data block is needed, the block time can be obtained by the same symmetric decryption.
For example, for the chunk time "20xx-01-19 03:14:07.938576", after symmetric encryption, it may be converted to a large chunk "1547838847938", where "1547838847938" may be used as the chunk height of the data chunk to identify the data chunk, since chunk data monotonically increases over time.
In the present specification, the block heights are monotonically increasing based on the block formation time, so that even if large-sized data is employed, the order among the data blocks is reflected from small to large. For example, if the next chunk time of a data chunk is "20xx-01-19 03:16:07.235125," it can be converted to another larger large integer "1547838848125" using a preset symmetric encryption algorithm.
When n=1, that is, the data block at this time is the initial data block. The hash value and block height of the initial data block are given based on a preset manner. For example, the initial data block does not include a data record, the hash value is any given hash value, and the block height blknum=0; for another example, the generation trigger condition of the initial data block is identical to the trigger condition of the other data blocks, but the hash value of the initial data block is determined by hashing all the contents in the initial data block.
When N >1, since the content and hash value of the previous data block have been determined, at this time, the hash value of the current data block (nth data block) may be generated based on the hash value of the previous data block (i.e., nth-1 data block), for example, in a feasible manner, determining the hash value of each data record to be written into the nth block, generating a merck tree according to the arrangement order in the block, splicing the root hash value of the merck tree and the hash value of the previous data block together, and generating the hash value of the current block again by adopting the hash algorithm. For example, the hash value of the whole data record may be obtained by splicing the sequence of the data records in the block, splicing the hash value of the previous data block and the hash value of the whole data record, and performing hash operation on the string obtained by splicing to generate the hash value of the data block.
In each data block, it contains a block header for storing metadata, and a block for storing data records. The block header in the data block may be used to store, for example, a parent hash, its own block hash value, version number, the root hash of the data record, a timestamp, and so on. As shown in fig. 2, fig. 2 is a schematic diagram of a chunk header according to the embodiment of the present disclosure, and of course, the format of the chunk header may be customized based on service requirements, and may further include some other information, for example, a state array for describing the state of the data record, and the like, and the chunk is used for storing plaintext of the data record or hash value of the data record.
By the foregoing generation method of the data blocks, each data block is determined by a hash value, and the hash value of the data block is determined by the content and sequence of the data records in the data block and the hash value of the previous data block. The user can initiate verification based on the hash value of the data block at any time, and the modification of any content in the data block (including modification of the content or sequence of the data record in the data block) can cause inconsistency between the hash value of the data block calculated during verification and the hash value generated during data block generation, so that verification failure is caused, and therefore, the tamper-proof effect under centralization is realized.
It should be noted that, the generation of the data block may be implemented in a coordination node in the database system, or may not be implemented in a coordination node. For example, the data system may further include other service nodes, which are dedicated to processing the generation of data blocks to implement service decoupling with respect to storage, where each generated data block is sent by the service node to the coordinator node for storage.
After a data block is acquired by a coordinator node in the database system, the data block needs to be stored. In the embodiment of the present disclosure, the storage manner adopted is to store a plurality of data blocks in the same ledger in a plurality of data nodes in a scattered manner, so as to adapt to rapid growth of the block chain ledger and reduce storage pressure of a single storage device. As shown in fig. 3, fig. 3 is a schematic flow chart of a data storage method applied to a database system according to an embodiment of the present disclosure, where the flow specifically includes the following steps:
S301, a coordination node obtains a generated data block, determines a data node corresponding to the data block according to a block hash value of the data block, distributes the data block to a corresponding data node, establishes routing information of the data block and the data node, and stores the routing information and block header information of the data block.
In a database system, there are typically a plurality of data nodes. For this purpose, the coordinator node first needs to determine to which data node a data block should be allocated. Specifically, the allocation may be based on hash values of the data blocks.
As previously described, the hash value of a data block may be calculated based on a combination of the parent hash and the hash of its own data record and stored in the block header. The hash value (hash value) is a value calculated using a hash function (hash function), and the supported algorithm includes: MACTripleDES, MD5, RIPEMD160, SHA1, SHA256, SHA384, SHA512, etc., in summary, the chunk hash value of a chunk is a short string that uniquely identifies the chunk, and slight modifications to any content in the chunk can cause large variations in the chunk hash value.
While the number of data nodes is generally fixed, each data node may have a corresponding number. Therefore, the hash value can be converted into a corresponding numerical value, and the modulo calculation is performed on the number of the data nodes, so that the data nodes corresponding to the data blocks can be determined according to the modulo result.
For example, after the number conversion of the block hash value of a data block is 100110120, the number of the data nodes is 10, and the numbers are respectively from 0 to 9, if the result of the block hash value on the modulo result is 0, the number 0 tree node can be determined to be the data node corresponding to the block hash value, and the data block can be sent to the number 0 data node for storage.
Since the block hash value of a data block generally has several hundred bits (the number of bits is determined based on the hash algorithm), a specified number of bits (for example, the last 3 bits) may be selected from the block hash value to perform numerical conversion, so as to perform modulo operation to determine the data node corresponding to the data block, thereby reducing the calculation amount.
As another example, all data nodes may also be arranged on a hash ring that is end-to-end, e.g., a hash ring from 0 to 2≡32 in size. Each data node may be located to a point on the hash ring according to its address or a hash value corresponding to the device identifier. Each chunk hash value may be located to a position on the hash ring based on the same principle, so that the data node that is encountered first may be found to be the data node to which the chunk hash value corresponds in a clockwise or counterclockwise time.
After determining the data node corresponding to a data block, a piece of routing information about the data block can be established and written into the routing table in the coordination node. Specifically, a routing table may include information such as a data block height, a block hash of the data block, a data node number corresponding to the data block, and the like, and be stored locally. As shown in table 1, table 1 is an exemplary routing table provided by embodiments of the present description.
TABLE 1
Data block height
|
Block hashing
|
Data node numbering
|
1
|
Hash1
|
1
|
2
|
Hash2
|
2
|
300
|
Hash300
|
1
|
……
|
……
|
…… |
In addition, in addition to the routing information, the coordinator node should also store the block header information of each data block.
And S303, the data node receives and stores the data block sent by the coordination node.
Through the scheme, the block chained account book is stored in a distributed mode according to the granularity of the data blocks, and metadata such as block header information and the like are stored in the coordination node, so that the storage pressure of single node equipment can be reduced, and the system is more convenient.
Meanwhile, because each data record includes a service attribute, based on this, the embodiment of the present disclosure provides a method for creating an index of a data record, which is applied to a coordination node, as shown in fig. 4, fig. 4 is a schematic flow chart of a method for creating an inverted index of a data record, where the flow chart specifically includes the following steps:
S401, acquiring a specified identification field in a data record, wherein the specified identification field is used for identifying the service attribute of the data record.
The specific location and the acquisition manner of the specified identification field are already described above, and will not be described here again.
S403, determining position information of the data record in the account book, wherein the position information comprises block height of a data block where the data record is located and offset in the data block where the data record is located.
As previously described, a block-chained ledger is composed of a plurality of data blocks, and a data block typically contains a plurality of data records. Thus, in the embodiment of the present specification, the location information specifically refers to which data block in the ledger is located when a data record is saved, and where in the data block.
In the data blocks provided in the embodiments of the present description, there are various ways to identify different data blocks, including hash values or block heights of the data blocks.
The hash value of a data block is a hash value obtained by performing hash calculation according to the hash value of the previous block and the data record of the data block, and can be used for uniquely and definitely identifying one data block. In a block chained ledger, the block height of the first data block is usually 0, and then 1 is added to the block height of each data block; alternatively, the block time of a data block may be converted into a large monotonically increasing sequence of integer data (typically 12 to 15 bits) as the block height of the data block. Thus, a data block is typically one distinct block high.
For example, in a case of a determined data block to be written into the database, in which the ordering of the data records is also fixed, so that the sequence number of a data record in the data block is also clear, when the length of the data record is a fixed unit, the sequence number can also be used to clear the location information of the data record in the data block in which it is located. That is, the sequence number may also be used to indicate the offset.
Meanwhile, in one data block, since a plurality of data records are generally included, the address offset of each data record in the data block may also be used to identify the data records in the data block, respectively. It is apparent that the address offsets of the data records are not the same in the same data block.
Of course, since the specific format of the data block is customizable (e.g., metadata information and remark information contained in the block header of the data block, the form taken by the block height of the data block, etc.) in the manner provided in the embodiments of the present disclosure, the content of the location information may also be different in different formats, which does not constitute a limitation of the present disclosure.
S405, establishing a corresponding relation between the specified identification field and the position information, and writing an index taking the specified identification field as a main key.
That is, the index is an inverted index. In the index, the primary key is a business attribute contained in the data record. The specific writing mode is that when the main key in the index does not contain the appointed identification field, an index record taking the appointed identification field as the main key is created in an index table.
And when the primary key in the index contains the appointed identification field, writing the position information into an index record where the appointed identification field is located. The writing here is not an overlay writing, but a writing in which position information is added to the value of the index record and is juxtaposed with other position information in the index record.
As shown in table 2, table 2 is an exemplary index table provided in the embodiments of the present specification. Wherein Key is a specific Value (for example, may be a user name) of the service attribute, each array of the Value part is a piece of position information, the front part in each array is high, the rear part is a serial number of the data record in the data block, and a data record can be uniquely determined through the block height and the serial number. It is easily understood that one key may correspond to a plurality of position information in the index table.
TABLE 2
Key
|
Value
|
0X123456
|
(2,08),(2,10),(300,89),(300,999)
|
344X0001
|
(5,01),(8,22)
|
……
|
…… |
The reverse index table is also stored in the coordinator node. By the above scheme, a routing table about block height and data node, and an inverted index table of service attribute and data record position information (including block height) can be obtained in the coordination node.
Based on the foregoing solution, the embodiment of the present disclosure further provides a data verification method based on inverted index, which is applied to a database system of a centralized storage block chain ledger, where the database system includes a coordination node and a plurality of data nodes, as shown in fig. 5, and fig. 5 is a flow chart of the data verification method based on inverted index provided by the embodiment of the present disclosure, where the method includes:
s501, the coordination node receives a first verification instruction containing service attributes.
The first verification instruction may be an operation instruction carrying a service attribute input by a user. Taking key as a user name, for example, VERIFY ("0X 123456", & v, -1), where '0X123456' is the user name input by the user, and the operation instruction indicates that the full data of the user "0X123456" in the ledger is verified.
S503, the coordination node obtains the position information of the data record corresponding to the service attribute based on the pre-established inverted index query.
The coordinating node can obtain the position information (2,08), (2, 10), (300,89), (300,999) of the data record corresponding to the user '0X 123456' from the index table 2 at this time, and further obtain the corresponding data record according to the position information query.
And, the first verification instruction may further include a corresponding block height parameter, and a section of the target block height section is determined by the block height parameter, for example, the user inputs the first verification instruction, VERIFY (0X 123456, & v,200, 1000) for specifying the data record of the user 0X123456 between the block height sections [200,1000] in the ledger, so as to obtain the data record corresponding to the position information (300,89), (300,999); alternatively, the user inputs a first verification command, VERIFY (0X 123456, & v, -1), for specifying a data record between the user 0X123456 at the block height interval [ -1, the current maximum block height ] in the ledger (i.e., the user's full data record).
And S505, the coordination node determines the corresponding data node according to the block height and sends the position information and the second verification instruction to the determined data node.
The second authentication instruction is defined by a communication protocol between the coordinator node and the data node, and is configured to instruct the data node to perform authentication according to the location information. For example, the first verification instruction may be forwarded, or may include only the indicator string "VERIFY", or may be an indicator character "1", or the like.
When the coordination node sends the location information, it may determine, according to the routing table 1, a data node corresponding to the block height, for example, in the routing table 1, the block height 2 corresponds to the data node 2, and the block height 300 corresponds to the data node 1.
When the coordination node forwards the position information, one mode is to forward all the position information to the data nodes, and each data node screens the position information. For example, the coordinating node forwards the location information (2,08), (2, 10), (300,89), (300,999) of the data record corresponding to "0X123456" to the data node 2, and since the data block stored in the data node includes a block header and a block body, the data node can perform local query according to the block height in the location information, perform verification, and remove the location information not located in the local data node.
In another forwarding mode, before forwarding, the coordinating node performs classification first to determine part of position information to be forwarded to a data node. For example, as can be seen from table 1, data block 2 is held by data node 2 and data block 300 is held by data node 1, so that the coordinator node determines to send location information (2,08), (2, 10) to data node 2 and, at the same time, sends location information (300,89), (300,999) to data node 1.
S507, any data node receiving the second verification instruction determines to obtain a corresponding data block according to the position information, verifies the integrity of the data block obtained by determination, and returns a second verification result to the coordination node.
At this point, each data node will perform the integrity verification of the data block locally. For example, the data node 2 receives the location information (2,08), (2, 10), at this time, the root hash of the merck tree in the data block 2 can be recalculated according to the data record in the data block 2, the root hash of the merck tree is combined with the hash value of the parent data block stored in the block header to recalculate the block hash value of the data block 2, and consistency comparison is performed with the hash value of the data block stored in the block header in advance, if the hash values are consistent, verification is passed, otherwise verification fails. For each data block, the data node may generate a corresponding second validation result and return the second validation result to the coordinator node.
And S509, the coordination node gathers the second verification results returned by the data nodes, determines that the first verification result is successful when all the second verification results are verification passing, otherwise, determines that the first verification result is failed, and returns the first verification result to the first verification instruction sender.
It is easy to understand that the verification is completed by distributing the verification on each data node, and the coordination nodes only need to summarize, so that compared with the integrity verification on the same equipment, the efficiency is greatly improved.
In the scheme provided by the embodiment of the application, the inverted index containing the corresponding relation between the service attribute and the position information is pre-established, so that the block height of the data block where the corresponding data record is located can be determined based on the service attribute contained in the first verification instruction, and further, the data nodes stored in the data block are determined, so that the integrity verification of the data block is respectively carried out on each data node, the second verification results of each data node are summarized, and the verification success is determined when the second verification results are successful.
In one embodiment, the first verification instruction may further comprise a time parameter for indicating that the blocking time of the data block to be verified should be before the time characterized by the time parameter.
One form of the time parameter may be a direct time parameter, for example, the first validation instruction is in the form of VERIFY ((0X 123456, & v, 20181001), i.e., a data record requiring acquisition of user "0X123456", and the block time (typically a timestamp) of the data block in which the data record is located is X before 10.01.2018, the target block height interval is [1, X ] assuming the block height of the nearest data block before 10.01.2018 is X.
Another form of time parameter may also be a large integer value when the block of data is high based on the large integer converted in time. For example, if the verification command is in the form of VERIFY (0X 123456, & v, 1547838848300), the data record of user "0X123456" is required, and the block height of the data block where the data record is located is not more than "1547838848300", where the target block height interval is [1,1547838848300]
In this way, the user can verify the related data records by determining the corresponding time period, for example, the user can verify the data blocks where the data records generated in one month or one day are located based on the self ID (i.e. service attribute) and the current time, and the user can filter irrelevant data blocks through the data records generated between the designated time periods, so that the verification efficiency is improved.
In one embodiment, the coordinating node may also perform integrity verification of the block header portion prior to the coordinating node sending the second verification instruction to the data node. The specific method is as follows: determining the data blocks corresponding to the block heights in the position information obtained by inquiry as the data blocks to be verified, generating the block hash of the data block according to the block hash of the previous data block (which can be obtained from the previous block header) and the root hash of the merck tree of the data block stored in the block header for each data block according to the generation sequence, and comparing the block hash with the block hash of the data block in the pre-stored block header information. In this verification method, only the information of the block header is required, and therefore, the verification method may be performed only in the coordinator node storing the information of the block header.
If the integrity verification of the block head part is consistent, distributing a second verification instruction and position information to the data node for further verification; otherwise, if the integrity verification of any block header fails, the first verification can be considered to fail, the subsequent verification is unnecessary, and the information representing that the first verification result is failed is returned to the verification instruction sender.
In one embodiment, the coordinating node may generate an integrity array in the coordinating node before receiving the second verification result for the data block returned by the data node, for recording the second verification result obtained by the data node for the data block to be verified. And the data node may return a characteristic value for characterizing failure or success when generating the second verification result. For example, verification success returns 1 and verification failure returns 0. The elements in the integrity array thus take either a value of 1 or 0. When the value of any element in the integrity array is 0, the coordination node can confirm that the first verification result is failed, and when the value of all elements in the integrity array is 1, the coordination node can confirm that the first verification result is successful, and the verification state of each data block can be recorded through the integrity array to more conveniently count the verification result.
Correspondingly, the embodiment of the specification also provides a data verification system based on inverted index, which is applied to a database system of a centralized storage block chain ledger, wherein the database system comprises a coordination node and a plurality of data nodes, and in the system,
the coordination node receives a first verification instruction containing service attributes;
the coordination node obtains the position information of the data record corresponding to the service attribute based on the pre-established inverted index query, wherein the inverted index contains the corresponding relation of the service attribute and the position information of the data record, and the position information comprises the block height of the data block where the data record is located and the offset in the data block where the data record is located;
the coordination node determines a corresponding data node according to the block height and sends the position information and a second verification instruction to the determined data node;
any data node which receives the second verification instruction determines to obtain a corresponding data block according to the position information, verifies the integrity of the data block obtained by the determination, and returns a second verification result to the coordination node;
and the coordination node gathers the second verification results returned by each data node, determines the first verification result as successful when the total second verification results are verification passing, otherwise, determines the first verification result as failure, and returns the first verification result to the first verification instruction sender.
Further, in the coordination node of the system, the inverted index is pre-established by the following method:
acquiring a specified identification field in a data record, wherein the specified identification field is used for identifying the service attribute of the data record; determining position information of the data record in an account book, wherein the position information comprises block heights of data blocks where the data record is located and offset in the data blocks where the data record is located; and establishing a corresponding relation between the specified identification field and the position information, and writing an index taking the specified identification field as a main key.
Further, in the system, the first verification instruction further includes a block height parameter, and the corresponding coordination node is used for determining a target block height section according to the block height parameter, and obtaining position information of the data record corresponding to the service attribute, which is located in the target block height section; correspondingly, the coordination node forwards the position information and the second verification instruction in the high section of the target block to each data node.
Further, in the system, before the coordination node receives the first verification instruction containing the service attribute, the coordination node is further used for acquiring the generated data block, determining the data node corresponding to the data block according to the block hash value of the data block, distributing the data block to the corresponding data node, establishing the routing information of the data block and the data node, and storing the routing information and the block header information of the data block; the data node receives and stores the data block sent by the coordination node.
Further, in the system, the data block is pre-generated by:
receiving data records to be stored, which contain specified identification fields, and determining hash values of the data records, wherein the specified identification fields are used for identifying service attributes of the data records;
when a preset blocking condition is reached, determining each data record in the data block to be written, and generating an Nth data block containing hash values of the data block and the data records, wherein the method specifically comprises the following steps of:
when n=1, the hash value and the block height of the initial data block are given based on a preset manner;
when N >1, determining the hash value of the N data block according to the hash value of each data record and the N-1 data block in the data block to be written, and generating the N data block containing the hash value of the N data block, each data record and the block forming time of the data block, wherein the block height of the data block monotonically increases based on the sequence of the block forming time.
Further, in the system, the coordination node is further configured to determine a data block to be verified according to the location information of the data record, and perform block header integrity verification on the data block to be verified according to the block header information stored in the coordination node.
On the other hand, the embodiment of the present disclosure further provides a data verification method based on inverted index, which is applied to a coordination node in a database system of a centralized storage block chain ledger, as shown in fig. 6, fig. 6 is a flow chart of the data verification method based on inverted index applied to the coordination node provided in the embodiment of the present disclosure, and includes:
s601, receiving a first verification instruction containing service attributes;
s603, acquiring position information of a data record corresponding to the service attribute based on a pre-established inverted index query, wherein the inverted index comprises a corresponding relation of the service attribute and the position information of the data record, and the position information comprises a block height of a data block where the data record is located and an offset in the data block where the data record is located;
s605, determining a corresponding data node according to the block height, and sending the position information and a second verification instruction to the determined data node;
s607, summarizing the second verification results returned by each data node, and determining that the first verification result is successful when the total second verification results are verification passing, or determining that the first verification result is failed;
S609, returning the first verification result to the first verification instruction sender.
Corresponding to another aspect, the embodiment of the present disclosure further provides a data verification device based on inverted index, which is applied to a coordination node in a database system of a centralized storage block chain ledger, as shown in fig. 7, fig. 7 is a schematic structural diagram of the data verification device based on inverted index, provided in the embodiment of the present disclosure, including:
a receiving module 701, configured to receive a first verification instruction including a service attribute;
the position query module 703 queries and obtains the position information of the data record corresponding to the service attribute based on a pre-established inverted index, wherein the inverted index contains the corresponding relation of the service attribute and the position information of the data record, and the position information comprises the block height of the data block where the data record is located and the offset in the data block where the data record is located;
the data node determining module 705 determines a corresponding data node according to the block height, and sends the position information and the second verification instruction to the determined data node;
the summarizing module 707 summarizes the second verification results returned by the data nodes, and determines that the first verification result is successful when the total second verification results are verification passing, or determines that the first verification result is failed;
The sending module 709 returns the first verification result to the first verification instruction sender.
The embodiments of the present disclosure also provide a computer device at least including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the data verification method shown in fig. 6 when executing the program.
FIG. 8 illustrates a more specific hardware architecture diagram of a computing device provided by embodiments of the present description, which may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 implement communication connections therebetween within the device via a bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit ), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc. for executing relevant programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory ), static storage device, dynamic storage device, or the like. Memory 1020 may store an operating system and other application programs, and when the embodiments of the present specification are implemented in software or firmware, the associated program code is stored in memory 1020 and executed by processor 1010.
The input/output interface 1030 is used to connect with an input/output module for inputting and outputting information. The input/output module may be configured as a component in a device (not shown) or may be external to the device to provide corresponding functionality. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various types of sensors, etc., and the output devices may include a display, speaker, vibrator, indicator lights, etc.
Communication interface 1040 is used to connect communication modules (not shown) to enable communication interactions of the present device with other devices. The communication module may implement communication through a wired manner (such as USB, network cable, etc.), or may implement communication through a wireless manner (such as mobile network, WIFI, bluetooth, etc.).
Bus 1050 includes a path for transferring information between components of the device (e.g., processor 1010, memory 1020, input/output interface 1030, and communication interface 1040).
It should be noted that although the above-described device only shows processor 1010, memory 1020, input/output interface 1030, communication interface 1040, and bus 1050, in an implementation, the device may include other components necessary to achieve proper operation. Furthermore, it will be understood by those skilled in the art that the above-described apparatus may include only the components necessary to implement the embodiments of the present description, and not all the components shown in the drawings.
The present embodiment also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the data verification 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 storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
From the foregoing description of embodiments, it will be apparent to those skilled in the art that the present embodiments may be implemented in software plus a necessary general purpose hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be embodied in essence or what contributes to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present specification.
The system, method, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for the method embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and reference is made to the description of the method embodiments for relevant points. The above-described method embodiments are merely illustrative, in that the modules illustrated as separate components may or may not be physically separate, and the functions of the modules may be implemented in the same piece or pieces of software and/or hardware when implementing the embodiments of the present disclosure. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
The foregoing is merely a specific implementation of the embodiments of this disclosure, and it should be noted that, for a person skilled in the art, several improvements and modifications may be made without departing from the principles of the embodiments of this disclosure, and these improvements and modifications should also be considered as protective scope of the embodiments of this disclosure.