Detailed Description
As mentioned above, in practical applications, sensitive content, once written to a chain of blocks, can have harmful consequences that are difficult to eliminate.
For example, zhang three defaults the Li four, and uploads the text file of the defamation to the blockchain network for certification, resulting in the text file being written into the blockchain, causing irrevocable damage to the reputation of the Li four. For another example, company a steals company B's business secret and submits the stolen business secret to a centralized device using a blockchain-like storage mode for verification, resulting in the business secret being written into the blockchain, and in order to eliminate the hazard, the centralized device can only delete the stored entire blockchain-like, which is too costly.
The transaction (transaction) described in the present specification refers to a piece of data written in a block chain. A transaction is a data structure agreed in the blockchain protocol or blockchain-like protocol, and a piece of data is required to be packaged into a transaction in order to store the data in the blockchain.
In a block chain based data certification scenario, once a transaction is written into a block chain, it is difficult to delete and tamper. However, in practical application, if the transaction of writing the block chain is subsequently determined to include sensitive content which is not suitable for disclosure, how to ensure that the block chain storage service operates normally becomes a difficult technical problem if the sensitive content of writing the block chain is not disclosed.
It should be noted that, assuming that the sensitive transaction (the transaction containing the sensitive content) written into the block chain is deleted directly, it is easy to cause that the data certification service running based on the block chain cannot run normally. The specific reasons are as follows:
common blockchain techniques (blockchain or centralized blockchain-like) tend to support simple pay SPV verification. SPV is a pointer to a transaction that verifies whether the transaction has been written to a chain of blocks. The principle of SPV is that a verification request requests a data storage party (a blockchain node or a centralized device) to verify whether a certain transaction (called a target transaction) is written into a blockchain, the data storage party firstly locates a block (called a target block) where the target transaction is located, then builds a Merkle tree (Merkle trees) based on each transaction in the target block, then determines a Merkle path corresponding to the target transaction, and returns a hash value associated with the Merkle path corresponding to the target transaction to the verification request party. And verifying whether the Hash value returned by the data storage party is correct or not by the request party, namely, according to the Hash value returned by the data storage party and the Hash value of the target transaction, calculating the root Hash of the Meckel tree according to the Hash value of the target transaction, judging whether the calculated root Hash is consistent with the root Hash in the block head of the target block, and if so, confirming that the verification is passed, and proving that the target transaction is really written into the block chain.
Fig. 1 is a schematic diagram of the structure of a merkel tree provided in the present description. As shown in fig. 1, in the merkel tree, each leaf node corresponds one-to-one to each transaction stored in the target block. The hash value on each leaf node is a transaction hash obtained by hashing the corresponding transaction. And for each parent node, the hash value on the parent node is obtained by carrying out hash operation on the hash values on two child nodes of the parent node.
Suppose a target transaction 1. The verification requester needs to verify whether transaction 1 is written in the chain of blocks. Thus, the validation request sends a request to any data store that first determines the target block and builds a merkel tree as shown in fig. 1. The data store then determines that the Hash value associated with the corresponding mekerr path for transaction 1 is Hash2, hash10, hash14 and returns Hash2, hash10, hash14 to the verification requester. The verification requester can calculate the root Hash of the merkel tree according to the merkel path corresponding to the transaction 1 according to the Hash1 (transaction Hash of the transaction 1), the Hash2, the Hash10 and the Hash14, and then, if the verification requester finds that the calculated root Hash is consistent with the root Hash stored in the block header of the target block, the verification requester determines that the transaction 1 is actually written into the block chain.
Obviously, the data store typically needs to build a merkel tree based on each transaction in the target block before triggering a simple payment verification for the target transaction. Thus, the hash value associated with the merkel path corresponding to the target transaction can be returned to the verification requester, so that the SPV is carried out on the target transaction. This also means that any one of transactions 1-8 is tampered with or deleted and the root Hash of the merkel tree (i.e., hash 1-8) changes, resulting in a simple payment verification failure.
For example, as shown in fig. 1, transaction 2 contains sensitive content, if transaction 2 is directly deleted from the block chain, when simple payment verification is required for any one of transactions 1 and 3-8, only a merkel tree can be built based on transactions 1 and 3-8 due to lack of transaction 2, so that the root hash of the built merkel tree is inconsistent with the root hash stored in the block header of the target block, which results in failure of simple payment verification, and an erroneous conclusion that neither transaction 1 nor transaction 3-8 is uplink is obtained.
Therefore, the invention can realize the concealment of a certain transaction in the block chain on the premise that the simple payment verification in the block chain system does not form interference. The core technical means of the invention is to replace the transaction (sensitive transaction) which needs to be concealed in the block chain with concealed data comprising the transaction hash of the transaction. In this way, the disclosure of the clear content of the transaction can be stopped without interfering with the smooth operation of the block-chain based simple payment verification system.
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.
The following describes in detail the technical solutions provided by the embodiments of the present specification with reference to the accompanying drawings.
Example 1
Fig. 2 is a flow chart of a method for concealing transactions involving a chain of writing blocks according to an embodiment of the present disclosure, comprising the steps of:
s200: a conceal instruction is received.
The scene applied by the invention is a data evidence storage scene based on a block chain. In this scenario, data is block-chained by a blockchain network comprising a plurality of nodes, or block-chained by a centralizing device.
In a blockchain scenario, the execution subject of the method may be each blockchain node; in a blockchain-like scenario, the execution subject of the method may be a centralized device.
In this specification, the concealing instruction comprises a target transaction identity, which is typically a transaction identity of a sensitive transaction comprising sensitive content. Of course, the method shown in FIG. 1 may also conceal non-sensitive transactions written to the chain of blocks, and thus the target transaction identification may in theory be a transaction identification of any transaction.
It should be noted that the transaction identifier of the transaction is used to uniquely identify the transaction. Specifically, the transaction identifier of the transaction may be a transaction hash obtained after the transaction is hashed, or may be a unique number allocated to the transaction.
In step S200, the conceal instruction may be issued by a user. The user may be a user uploading sensitive content or may be a subject (e.g., court, victim, etc.) who has the right to conceal sensitive content.
Under the block chain scene, each block chain link point receives a hidden instruction, which can be specifically: each block link point receives a concealment transaction that encapsulates a concealment instruction. Each block chain node executes the hiding instruction in a manner of executing the hiding transaction, and after the hiding transaction is executed, each block chain node writes the hiding transaction into the block chain for verification.
S202: and determining the concealed data according to the concealed instruction.
In this specification, the concealed data includes at least a transaction hash of a transaction corresponding to the target transaction identification.
S204: and replacing the transaction corresponding to the target transaction identification in the block chain with the concealed data.
In this specification, the transaction corresponding to the target transaction identifier in the block chain is replaced by the concealed data, which may specifically be:
firstly, determining a block (called a target block) where the transaction corresponding to the target transaction identifier is located in a block chain, and then replacing the transaction stored in the transaction storage position corresponding to the target transaction identifier in the target block with the concealed data.
A block chain is actually a storage structure formed by connecting a plurality of blocks in chronological order of the blocks. For each block, there are multiple transaction storage locations in the block. The transaction storage location refers to a storage space or a storage address in a block for storing transactions. Assuming 100 transactions are written in the blockchain, there are also 100 transaction storage locations in the blockchain for storing the 100 transactions, respectively.
In this specification, according to the target transaction identifier, traversal may be performed in a block chain to search for a transaction corresponding to the target transaction identifier, that is, to locate a transaction storage location where the transaction corresponding to the target transaction identifier is located. And deleting the transaction corresponding to the target transaction identifier from the positioned transaction storage location, and storing the concealed data into the positioned transaction storage location.
Further, since the transaction efficiency is low in locating the transaction in the blockchain in a traversal manner according to the target transaction identifier, in the present specification, any transaction written into the blockchain may be pre-recorded, and the corresponding relationship between the transaction identifier of the transaction and the transaction storage location in the blockchain where the transaction is located may be separately recorded outside the blockchain.
For any transaction written into the block chain, the transaction storage location of the transaction in the block chain is generally the height of the block in which the transaction is located (i.e., the cis-position number of the block in the block chain) and the offset of the transaction in the block. For example, after the chunk packed with transaction a is written to the 4 th chunk in the blockchain, i.e., the height of the chunk packed with transaction a is 5, and the offset of transaction a in the chunk is 120, then the transaction storage location corresponding to transaction a may be (5, 120).
In this specification, in a blockchain-like scenario, the centralization device may also encapsulate the concealing instruction into a concealing transaction write blockchain.
In addition, in a blockchain or blockchain-like scenario, the concealment transaction written into the blockchain encapsulates not only the concealment instruction, but also a data hash of the concealment data.
By the method described in fig. 2, concealment of sensitive content in a written block chain may be achieved. Further, since the manner of concealment of the sensitive content is to replace the sensitive transaction including the sensitive content with the transaction hash concealed data including the sensitive transaction, the normal SPV is not affected.
In addition, the suppressed data may include more information in addition to the transaction hash of the transaction corresponding to the target transaction identification.
Specifically, fig. 3 is a schematic diagram of a process for constructing suppressed data according to an embodiment of the present disclosure. Each node can acquire the transaction hash of the transaction corresponding to the target transaction identifier when constructing the hidden data; splicing a preset front mark character to the head of the transaction hash; and determining the hidden data according to the data formed by the hash splice of the front marking character and the transaction.
The effect of the preceding marker characters is that, when reading data from a transaction storage location, if the transaction of the transaction storage location has been replaced with suppressed data, reading the preceding marker characters in the suppressed data corresponds to a clear: "the transaction storage location stores not the plaintext content of the transaction, but rather the transaction hash".
Since the transaction hash is typically a fixed-length string, the remark information may be further added after the transaction hash in the suppressed data. Thus, after the transaction hash in the suppressed data is read, the remainder of the suppressed data is the remark information.
Note that the remark information may specifically be information added to achieve a specific service requirement. For example, the remark information may be "hidden" indicating that the transaction to which the target transaction identification corresponds has been suppressed. When the user inquires the transaction corresponding to the target transaction identifier, the remark information can prompt the user that the transaction is invisible.
Further, fig. 4 is a schematic diagram of another process for constructing suppressed data according to an embodiment of the present disclosure. When the hidden data is constructed, a transaction hash of the transaction corresponding to the target transaction identifier can be obtained; splicing a preset front marking character to the head of the transaction hash, splicing a preset rear marking character to the tail of the transaction hash, and splicing remark information to the tail of the rear marking character; and then determining the data spliced by the front marking character, the transaction hash, the rear marking character and the remark information as the concealed data.
The effect of the post-marker character described above is that when the remarked information (or the non-sensitive content mentioned later) is included in the suppressed data, the data reading does not need to be performed according to the fixed length value of the transaction hash, but the transaction hash in the suppressed data is separated from the remarked information (the non-sensitive content) using the post-marker character to distinguish.
It should be noted that the front marking character and the rear marking character may be specified according to actual needs. For example, the front marker character may be "0E" and the rear marker character may be "0F".
Example two
In the present specification, the pre-marker character and the post-marker character described in the first embodiment may not be included in the suppressed data, and the transaction or the suppressed data stored in a certain transaction storage location may be marked by other means.
Specifically, for each transaction storage location in the block chain, a content field is created in the transaction storage location, the content field is used for storing a transaction or the concealed data generated based on the transaction, and an identification field is used for storing a first identifier or a second identifier, and whether the transaction or the concealed data is in the content field is identified.
Wherein the identification field comprises a first identifier when the content field comprises a transaction and a second identifier when the content field comprises suppressed data generated based on the transaction.
FIG. 5 is a flow chart of another method for concealing transactions involving a chain of blocks according to an embodiment of the present disclosure, comprising the steps of:
s500: and receiving a hiding instruction containing the target transaction identifier, and determining a transaction storage position for storing the transaction corresponding to the target transaction identifier as the target transaction storage position.
In this specification, for each transaction storage location in a chain of blocks, the transaction storage location stores a content field and an identification field, the identification field containing a first identifier if the content field contains a transaction.
S502: and determining the concealed data according to the concealed instruction.
S504: the transaction in the content field of the target transaction storage location is replaced with the suppressed data.
S506: and replacing the first identifier in the identification field of the target transaction storage location with the second identifier.
For example, the first identifier may occupy a two-byte "FF" and the second identifier may be a two-byte "00".
The beneficial effects of embodiment two are analyzed here. In a first embodiment, the marking of whether the transaction or the concealed data is stored in a certain transaction storage location is performed by stitching the pre-marking characters before the transaction hash in the concealed data.
However, in practice, to avoid "hash collisions" between the transaction hash in the concealing data and the pre-marker characters (i.e., the node or the centralising device cannot distinguish between whether the characters read from the transaction memory location are pre-marker characters or characters in the transaction hash when executing the transaction concealing logic), the pre-marker characters are typically set to special characters that are not theoretically repeatable with the transaction hash, such special characters typically being long (occupying many bytes) and placing a significant burden on the node or centralising device that reads data from the transaction memory location.
For this reason, if the method in the second embodiment is adopted, the pre-label character is not used to splice with the transaction hash, but two independent fields, namely, a content field and an identification field, are divided in the transaction storage location, where the content field is used to store the transaction or the concealed data replaced by the transaction after being concealed, and the identification field stores an identifier for identifying whether the transaction or the concealed data is in the content field. Thus, only a short identifier is written in the identification field, so that the mark distinction of whether the transaction or the hidden data is stored in a certain transaction storage position can be realized.
Fig. 6 is a schematic diagram of a content field and an identification field provided in an embodiment of the present disclosure. Assuming that the content field of the transaction storage location 1 in the target tile stores the transaction and the content field of the transaction storage location 2 stores the suppressed data, as shown in fig. 6, then the identification may be based on the identification field.
Example III
Based on the first and second embodiments, the composition of the suppressed data may also be optimized.
FIG. 7 is a flow chart of another method for concealing transactions written to a blockchain according to an embodiment of the present disclosure, comprising the steps of:
s700: a conceal instruction is received.
In this specification, the concealment instruction may specifically include a target transaction identification and a concealment condition. Wherein the concealment condition is used for determining sensitive content in a transaction corresponding to the target transaction identifier.
Further, the concealing condition may be sensitive location information for characterizing a location of the sensitive content in a transaction corresponding to the target transaction identification. For example, the sensitive location information may be byte range information (1, 6) indicating that the 1 st byte to 6 th byte content in the transaction corresponding to the target transaction identification is sensitive content.
S702: and acquiring the transaction hash of the transaction corresponding to the target transaction identifier, and extracting non-sensitive content from the transaction corresponding to the target transaction identifier according to the hiding condition included by the hiding instruction.
The non-sensitive content is the content except the sensitive content in the transaction corresponding to the target transaction identifier.
S704: and determining hidden data according to the transaction hash and the non-sensitive content.
In step S704, the suppressed data may include only the transaction hash and the non-sensitive content. Since transaction hashes are typically of fixed length, confusion of transaction hashes with the non-sensitive content generally does not occur.
Furthermore, in combination with the first embodiment, there are several cases:
1. the suppressed data may also include pre-marker characters therein.
2. The suppressed data may also include pre-and post-marker characters.
Wherein a post-marker character may be used to distinguish the transaction hash from the non-sensitive content.
3. The suppressed data may further include a pre-marker character, a first post-marker character, a second post-marker character, and remark information.
Wherein a first post-marker character may be used to distinguish the transaction hash from the non-sensitive content and a second post-marker character may be used to distinguish the non-sensitive content from the remark information.
S706: and replacing the transaction corresponding to the target transaction identification in the block chain with the concealed data.
In this way, on the premise of hiding the sensitive content in the transaction corresponding to the target transaction identifier, the non-sensitive content in the transaction corresponding to the target transaction identifier can be reserved, as shown in fig. 8.
Example IV
Based on the third embodiment, the method for generating the suppressed data may be further optimized.
Fig. 9 is a flow chart of a method for concealing transactions involving a chain of blocks according to an embodiment of the present disclosure, comprising the steps of:
s900: a conceal instruction is received.
S902: and acquiring the transaction hash of the transaction corresponding to the target transaction identifier, and extracting non-sensitive content from the transaction corresponding to the target transaction identifier according to the hiding condition included by the hiding instruction.
S904: and adjusting the expression mode of the non-sensitive content based on a preset expression mode adjustment model, and determining hidden data according to the transaction hash and the adjusted non-sensitive content.
S906: and replacing the transaction corresponding to the target transaction identification in the block chain with the concealed data.
The expression adjustment model may specifically be a preset expression adjustment rule, for example, the expression adjustment rule may be: if there is a Chinese character in the non-sensitive content, the Chinese character is replaced with pinyin. As another example, the expression adjustment rule may be: and if the capital English letters exist in the non-sensitive content, replacing at least one capital English letter with a lowercase English letter.
The expression adjustment model may specifically be an intelligent model trained in advance according to a machine learning algorithm.
In summary, the expression adjustment model is used for adjusting the expression of the non-sensitive content, so that the information conveyed by the non-sensitive content after adjustment is within the coverage range of the information conveyed by the non-sensitive content before adjustment.
Preferably, the information conveyed by the non-sensitive content after adjustment is consistent with the information conveyed by the non-sensitive content before adjustment, i.e. the information conveyed by the non-sensitive content after adjustment is not lost.
In order to avoid the situation, the expression mode of the non-sensitive content written in the hidden data is adjusted, so that the hidden sensitive content cannot be cracked according to the adjusted non-sensitive content no matter how the non-sensitive content is tried.
Example five
Based on the first to fourth embodiments described above, a rights verification mechanism may be introduced.
FIG. 10 is a flow chart of a method for concealing transactions involving a chain of blocks according to an embodiment of the present disclosure, comprising the steps of:
s1000: receiving a hiding instruction;
s1002: and acquiring the signature of the hidden command, judging whether the acquired signature meets the specified condition, if so, executing the step S1004, and if not, executing the step S1006.
S1004: and according to the hiding instruction, determining hiding data of transaction hash of the transaction corresponding to the target transaction identifier, and replacing the transaction corresponding to the target transaction identifier in a block chain with the hiding data.
S1006: rejecting the hidden instruction.
In practical applications, the suppressed instruction may be required to have a signature that satisfies specified conditions. Each blockchain node or centralizing device executes the concealing instruction when determining that the signature of the concealing instruction meets a specified condition.
Specifically, the specified conditions may include, but are not limited to, the following three cases:
1. and if the transaction corresponding to the target transaction identifier is a transaction written into the blockchain, the signature of the hidden command is the signature of the blockchain node. At this time, the specified condition is that the number of acquired signatures is greater than a specified number.
For example, where there are 10 nodes in the blockchain network, the specified number may be set to 5, the hide instruction must be approved by more than 5 nodes to be valid.
2. If the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the appointed condition is that the acquired signature comprises signatures of at least two authority parties.
Specifically, in practice, the authority may include a court, a controller of the centralized equipment, a business party for which the data storage service of the centralized equipment is directed, and the like.
3. A weight is assigned to the signature of each authority in advance. If the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the specified condition is that the sum of weights corresponding to the obtained signatures is larger than the specified weight.
For example, a court may be assigned a weight of 100, a controller of the centralized facility may be assigned a weight of 50, and a business may be assigned a weight of 40. Meanwhile, the assigned weight is set to 60.
Example six
Based on the methods in the first to fifth embodiments, the method for constructing a merkel tree corresponding to a block provided in the embodiment of the present disclosure, as shown in fig. 11, includes:
s1100: for each transaction storage location in the target block, data is read from the transaction storage location.
S1102: if the data read from the transaction storage position is determined to comprise the transaction, carrying out hash calculation on the transaction included in the read data to obtain the transaction hash corresponding to the transaction storage position.
S1104: if it is determined that the data read from the transaction storage location includes the concealed data, a transaction hash is extracted from the concealed data included in the read data as a transaction hash corresponding to the transaction storage location.
S1106: and constructing a merkel tree corresponding to the target block based on the transaction hashes respectively corresponding to the transaction storage positions in the target block.
Example seven
Based on the sixth embodiment, after the transaction corresponding to the target transaction identifier is suppressed, the tag of the block where the transaction corresponding to the target transaction identifier is located may be further determined as the specified tag.
In this specification, at least some of the tiles in the chain of tiles may have a label for marking the presence of at least one suppressed transaction in that tile.
In particular, a specified tag may be agreed to be used to characterize the presence of at least one suppressed transaction in a block. After replacing the transaction corresponding to the target transaction identifier with the concealed data, it may be determined whether the tag of the block (target block) where the transaction corresponding to the target transaction identifier is located has a tag, and if not, a designated tag is assigned to the target block. If the label exists, further judging whether the label is a designated label. If the target block is the designated label, the fact that other hidden sensitive transactions exist in the target block besides the transaction corresponding to the target transaction identifier is explained, and the label of the target block does not need to be changed; if the tag is not specified, indicating that the target block does not contain suppressed data, the tag of the target block needs to be modified to the specified tag.
As such, the labels of the blocks in the block chain are either 1 or 0. If the specified tag is 1, then its tag is 1 when the block contains suppressed data, and 0 when the block does not contain suppressed data. If the specified tag is 0, then its tag is 0 when the block contains suppressed data and 1 when the block does not contain suppressed data.
The function of determining the label of the block where the target transaction identifier corresponds to the transaction place as the designated label is to lighten the calculation burden of the blockchain node or the centralizing equipment. Specifically, if the block containing the hidden data is not marked, as in the method shown in fig. 11, when the merkel tree needs to be built for the target block, the blockchain node or the centralization device does not determine whether the target block contains the hidden data, and then, for each transaction storage location in the target block, whether the transaction storage location stores the transaction or the hidden data has to be determined sequentially, so that a transaction hash corresponding to the transaction storage location is obtained by adopting different strategies. When there are many blocks of the merkel tree that need to be constructed and few sensitive transactions that are suppressed, much computing resources are wasted if the method shown in fig. 11 is performed for each block.
In the seventh embodiment, before the merkel tree corresponding to any block is built, whether the block contains the suppressed data may be first determined according to the tag of the block, so that when there is no suppressed sensitive transaction in the target block, the merkel tree corresponding to the target block may be built by default (instead of the method shown in fig. 11), and thus, the computing resources may be saved.
FIG. 12 is a flow chart of a method for concealing transactions involving a chain of blocks according to an embodiment of the present disclosure, comprising the steps of:
s1200: a conceal instruction is received.
S1202: and determining the concealed data according to the concealed instruction.
S1204: and replacing the transaction corresponding to the target transaction identification in the block chain with the concealed data.
S1206: and determining the label of the block where the target transaction identifier corresponds to the transaction place as a designated label.
Fig. 13 is a flowchart of another method for constructing a merkel tree corresponding to a block according to an embodiment of the present disclosure, including the following steps:
s1300: and aiming at a target block in the block chain, acquiring a label of the target block.
S1302: if the tag of the target block is a designated tag, data is read from each transaction storage location in the target block for that transaction storage location.
S1304: if the data read from the transaction storage position is determined to comprise the transaction, carrying out hash calculation on the transaction included in the read data to obtain the transaction hash corresponding to the transaction storage position.
S1306: if it is determined that the data read from the transaction storage location includes the concealed data, a transaction hash is extracted from the concealed data included in the read data as a transaction hash corresponding to the transaction storage location.
S1308: and constructing a merkel tree corresponding to the target block based on the transaction hashes respectively corresponding to the transaction storage positions in the target block.
Further, for each transaction storage location in the target block, if the data read from the transaction storage location does not include the pre-marker character, determining that the data read from the transaction storage location includes a transaction; if the data read from the transaction memory location includes the pre-marked character, it is determined that the data read from the transaction memory location includes suppressed data.
Or if the identification field in the data read from the transaction storage location includes a first identifier, determining that the data read from the transaction storage location includes a transaction; if the identification field in the data read from the transaction storage location includes a second identifier, it is determined that the data read from the transaction storage location includes suppressed data.
In the seventh embodiment, the method for extracting the transaction hash from the concealed data included in the read data may specifically be that data located after the pre-marker character in the concealed data included in the read data is determined as the transaction hash and extracted; or determining the data with the specified length behind the front mark character in the concealed data included in the read data as transaction hash and extracting.
Wherein the specified length is a fixed length of the transaction hash.
In the seventh embodiment, data between the front marker character and the rear marker character in the concealed data included in the read data may be determined as transaction hash and extracted.
In a seventh embodiment, if the tag of the target block is not the specified tag, a default manner is adopted to construct a merkel tree corresponding to the target block.
In a seventh embodiment, further, a binary string may be created in advance, and assuming that the block chain includes N blocks, the binary string has at least N binary bits, and the value of the i-th binary bit of the binary string is the label of the i-th block in the block chain, i e [1, N ].
Thus, the tag mode of obtaining the target block may be to determine the sequence number M of the target block; and reading the value of the Mth binary bit from the binary number string as a label of the target block.
Fig. 14 is a flowchart of a simple payment verification method provided in the embodiment of the present disclosure, including the following steps:
s1400: receiving a verification request; the verification request comprises a target transaction identifier;
s1402: determining a block where the transaction corresponding to the target transaction identifier is located in a block chain of the block chain according to the verification request, and constructing a merkel tree corresponding to the block based on a method shown in fig. 11 or fig. 13;
s1404: and based on the constructed Meicher tree, performing simple payment verification on the transaction corresponding to the target transaction identifier.
Fig. 15 is a schematic structural diagram of an apparatus for concealing transactions written to a block chain according to an embodiment of the present disclosure, wherein for each transaction storage location in the block chain, a content field and an identification field are stored, and if the content field includes a transaction, the identification field includes a first identifier, the apparatus includes:
a receiving module 1501 for receiving a command containing a target transaction identifier, and determining a transaction storage location for storing a transaction corresponding to the target transaction identifier as a target transaction storage location;
A determining module 1502 for determining, based on the concealing instruction, concealing data; the hidden data comprises a transaction hash of the transaction corresponding to the target transaction identifier;
a processing module 1503 replaces the transaction in the content field of the target transaction storage location with the suppressed data and replaces the first identifier in the identification field of the target transaction storage location with the second identifier.
The hiding instruction further comprises a hiding condition for determining sensitive content in the transaction corresponding to the target transaction identifier;
the determining module 1502 obtains a transaction hash of a transaction corresponding to the target transaction identifier, and extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to a concealment condition included in the concealment instruction; and determining hidden data according to the transaction hash and the non-sensitive content.
The hiding condition is sensitive position information and is used for representing the position of sensitive content in the transaction corresponding to the target transaction identifier.
The determining module 1502 splices a preset post-marker character to the tail of the transaction hash; splicing the non-sensitive content to the tail of the post-marker character; and determining the data spliced by the transaction hash, the post-marked character and the non-sensitive content as the concealed data.
The determining module 1502 adjusts a model based on a preset expression mode, and adjusts the expression mode of the non-sensitive content; and determining hidden data according to the transaction hash and the adjusted non-sensitive content.
The determining module 1502 obtains a signature of the concealing instruction and determines whether the obtained signature meets a specified condition; if yes, determining hidden data according to the hidden command; if not, rejecting the hidden instruction.
If the transaction corresponding to the target transaction identifier is a transaction written into the blockchain, the signature of the hidden command is a signature of a blockchain node, and the specified condition is that the number of acquired signatures is larger than the specified number.
If the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the appointed condition is that the acquired signature comprises signatures of at least two authority parties.
The signature of each authority is assigned with a weight;
if the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the specified condition is that the sum of weights corresponding to the obtained signatures is larger than the specified weight.
The apparatus further comprises:
the transaction write module 1504 writes a chain of suppressed transactions, in which the suppressed instructions are encapsulated, to a chain of blocks.
The transaction write module 1504 writes a chain of suppressed transactions that encapsulates the data hashes of the suppressed data and the suppressed data.
The apparatus further comprises:
the tag determination module 1505 determines the tag of the block where the target transaction identifier corresponds to the transaction place as the specified tag.
For any block in the block chain, if the block does not contain the suppressed data, the tag of the block is not the specified tag.
Let the block chain include N blocks, the value of the ith binary bit of the pre-created binary string be the label of the ith block in the block chain, i E [1, N ].
FIG. 16 is a schematic diagram of an apparatus for concealing transactions involving a chain of write blocks according to the present invention, comprising:
a receiving module 1601 that receives a concealment instruction; the hiding instruction comprises a target transaction identifier and a hiding condition, wherein the hiding condition is used for determining sensitive content in a transaction corresponding to the target transaction identifier;
the acquisition and extraction module 1602 acquires a transaction hash of a transaction corresponding to the target transaction identifier, and extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to a concealment condition included in the concealment instruction;
A determining module 1603 for determining the hidden data according to the transaction hash and the non-sensitive content;
the processing module 1604 replaces the transaction in the chain of blocks corresponding to the target transaction identification with the suppressed data.
For each transaction storage location in a chain of blocks, storing a content field and an identification field, the content field comprising a transaction or suppressed data generated based on the transaction;
wherein the identification field comprises a first identifier when the content field comprises a transaction and a second identifier when the content field comprises suppressed data generated based on the transaction.
The hiding condition is sensitive position information and is used for representing the position of sensitive content in the transaction corresponding to the target transaction identifier.
The determining module 1603 splices a preset post-marking character to the tail of the transaction hash; splicing the non-sensitive content to the tail of the post-marker character; and determining the data spliced by the transaction hash, the post-marked character and the non-sensitive content as the concealed data.
The determining module 1603 adjusts the model based on a preset expression mode, and adjusts the expression mode of the non-sensitive content; and determining hidden data according to the transaction hash and the adjusted non-sensitive content.
The determining module 1603 obtains the signature of the hidden command and determines whether the obtained signature meets a specified condition; if yes, determining hidden data according to the hidden command; if not, rejecting the hidden instruction.
If the transaction corresponding to the target transaction identifier is a transaction written into the blockchain, the signature of the hidden command is a signature of a blockchain node, and the specified condition is that the number of acquired signatures is larger than the specified number.
If the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the appointed condition is that the acquired signature comprises signatures of at least two authority parties.
The signature of each authority is assigned with a weight;
if the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the specified condition is that the sum of weights corresponding to the obtained signatures is larger than the specified weight.
The apparatus further comprises:
the tag determination module 1605 determines the tag of the block where the transaction corresponding to the target transaction identifier is located as the designated tag.
For any block in the block chain, if the block does not contain the suppressed data, the tag of the block is not the specified tag.
Let the block chain include N blocks, the value of the ith binary bit of the pre-created binary string be the label of the ith block in the block chain, i E [1, N ].
The apparatus further comprises:
the transaction write module 1606 writes the suppressed transaction, which is encapsulated with the suppressed instruction, to a chain of blocks.
The transaction writing module 1606 writes the concealed transaction into a chain of blocks that encapsulates the data hash of the concealed instruction and the concealed data.
FIG. 17 is a schematic diagram of an apparatus for concealing transactions involving a chain of write blocks according to the present invention, comprising:
a receiving module 1701 for receiving a concealing instruction; the hiding instruction comprises a target transaction identifier and a hiding condition, wherein the hiding condition is used for determining sensitive content in a transaction corresponding to the target transaction identifier;
the acquisition and extraction module 1702 acquires a transaction hash of a transaction corresponding to the target transaction identifier, and extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to a concealment condition included in the concealment instruction;
an adjustment determining module 1703, configured to adjust a representation of the non-sensitive content based on a preset representation adjustment model, and determine hidden data according to the transaction hash and the adjusted non-sensitive content;
The processing module 1704 replaces the transaction in the chain of blocks corresponding to the target transaction identifier with the suppressed data.
For each transaction storage location in a chain of blocks, storing a content field and an identification field, the content field comprising a transaction or suppressed data generated based on the transaction;
wherein the identification field comprises a first identifier when the content field comprises a transaction and a second identifier when the content field comprises suppressed data generated based on the transaction.
The hiding condition is sensitive position information and is used for representing the position of sensitive content in the transaction corresponding to the target transaction identifier.
The adjustment determining module 1703 splices a preset post-marking character to the tail of the transaction hash; splicing the adjusted non-sensitive content to the tail of the post-marking character; and determining the data spliced by the transaction hash, the post-marking character and the adjusted non-sensitive content as the concealed data.
The adjustment determining module 1703 obtains a signature of the concealing instruction and determines whether the obtained signature meets a specified condition; if yes, determining hidden data according to the hidden command; if not, rejecting the hidden instruction.
If the transaction corresponding to the target transaction identifier is a transaction written into the blockchain, the signature of the hidden command is a signature of a blockchain node, and the specified condition is that the number of acquired signatures is larger than the specified number.
If the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the appointed condition is that the acquired signature comprises signatures of at least two authority parties.
The signature of each authority is assigned with a weight;
if the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the specified condition is that the sum of weights corresponding to the obtained signatures is larger than the specified weight.
The apparatus further comprises:
the tag determination module 1705 determines, as a specified tag, a tag of a block where the transaction corresponding to the target transaction identifier is located.
For any block in the block chain, if the block does not contain the suppressed data, the tag of the block is not the specified tag.
Let the block chain include N blocks, the value of the ith binary bit of the pre-created binary string be the label of the ith block in the block chain, i E [1, N ].
The apparatus further comprises:
the transaction write module 1706 writes a chain of suppressed transactions into which the suppressed instruction is encapsulated.
The transaction write module 1706 writes a chain of suppressed transactions that encapsulates a data hash of the suppressed data and the suppressed instruction.
FIG. 18 is a schematic diagram of an apparatus for concealing transactions involving a chain of write blocks according to the present invention, comprising:
a receiving module 1801 for receiving a concealing instruction; the hidden command comprises a target transaction identifier;
the acquisition judging module 1802 acquires the signature of the concealing instruction and judges whether the acquired signature meets a specified condition;
the first processing module 1803, if yes, determines, according to the concealment instruction, concealment data including a transaction hash of a transaction corresponding to the target transaction identifier, and replaces the transaction corresponding to the target transaction identifier in a block chain with the concealment data;
the second processing module 1804, if not, denies the conceal instruction.
If the transaction corresponding to the target transaction identifier is a transaction written into the blockchain, the signature of the hidden command is a signature of a blockchain node, and the specified condition is that the number of acquired signatures is larger than the specified number.
If the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the appointed condition is that the acquired signature comprises signatures of at least two authority parties.
The signature of each authority is assigned with a weight;
if the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the specified condition is that the sum of weights corresponding to the obtained signatures is larger than the specified weight.
The first processing module 1803 obtains a transaction hash of the transaction corresponding to the target transaction identifier; splicing a preset front mark character to the head of the transaction hash; and determining hidden data according to the data formed by the hash splice of the front marking character and the transaction.
The first processing module 1803 splices a preset post-marking character to the tail of the transaction hash, and splices remark information to the tail of the post-marking character; and determining the data spliced by the front marking character, the transaction hash, the rear marking character and the remark information as the concealed data.
For each transaction storage location in a chain of blocks, storing a content field and an identification field, the content field comprising a transaction or suppressed data generated based on the transaction;
wherein the identification field comprises a first identifier when the content field comprises a transaction and a second identifier when the content field comprises suppressed data generated based on the transaction.
The hiding instruction further comprises a hiding condition for determining sensitive content in the transaction corresponding to the target transaction identifier;
the first processing module 1803 obtains a transaction hash of a transaction corresponding to the target transaction identifier, and extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to a concealment condition included in the concealment instruction; and determining hidden data according to the transaction hash and the non-sensitive content.
The hiding condition is sensitive position information and is used for representing the position of sensitive content in the transaction corresponding to the target transaction identifier.
The first processing module 1803 splices a preset post-marking character to the tail of the transaction hash; splicing the non-sensitive content to the tail of the post-marker character; and determining the data spliced by the transaction hash, the post-marked character and the non-sensitive content as the concealed data.
The first processing module 1803 adjusts a model based on a preset expression mode, and adjusts the expression mode of the non-sensitive content; and determining hidden data according to the transaction hash and the adjusted non-sensitive content.
The apparatus further comprises:
The tag determination module 1805 determines, as the specified tag, the tag of the block where the transaction corresponding to the target transaction identifier is located.
For any block in the block chain, if the block does not contain the suppressed data, the tag of the block is not the specified tag.
Let the block chain include N blocks, the value of the ith binary bit of the pre-created binary string be the label of the ith block in the block chain, i E [1, N ].
The apparatus further comprises:
the transaction write module 1806 writes a chain of suppressed transactions that encapsulates the suppressed instruction.
The transaction writing module 1806 writes a hidden transaction into a chain of blocks, the hidden transaction being packaged with a hash of the hidden instruction and the data of the hidden data.
FIG. 19 is a schematic diagram of an apparatus for concealing transactions involving a chain of write blocks according to the present invention, comprising:
a receiving module 1901 for receiving a conceal instruction; the hidden command comprises a target transaction identifier;
a determining module 1902, configured to determine, based on the concealing instruction, concealed data; the hidden data comprises a transaction hash of the transaction corresponding to the target transaction identifier;
the processing module 1903 replaces the transaction corresponding to the target transaction identifier in the block chain with the concealed data, and determines the label of the block where the transaction corresponding to the target transaction identifier is located as the designated label.
The determining module 1902 obtains a transaction hash of the transaction corresponding to the target transaction identifier; splicing a preset front mark character to the head of the transaction hash; and determining hidden data according to the data formed by the hash splice of the front marking character and the transaction.
The determining module 1902 splices a preset post-marking character to the tail of the transaction hash, and splices remark information to the tail of the post-marking character; and determining the data spliced by the front marking character, the transaction hash, the rear marking character and the remark information as the concealed data.
For each transaction storage location in a chain of blocks, storing a content field and an identification field, the content field comprising a transaction or suppressed data generated based on the transaction;
wherein the identification field comprises a first identifier when the content field comprises a transaction and a second identifier when the content field comprises suppressed data generated based on the transaction.
The hiding instruction further comprises a hiding condition for determining sensitive content in the transaction corresponding to the target transaction identifier;
The determining module 1902 obtains a transaction hash of a transaction corresponding to the target transaction identifier, and extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to a concealment condition included in the concealment instruction; and determining hidden data according to the transaction hash and the non-sensitive content.
The hiding condition is sensitive position information and is used for representing the position of sensitive content in the transaction corresponding to the target transaction identifier.
The determining module 1902 splices a preset post-marking character to the tail of the transaction hash; splicing the non-sensitive content to the tail of the post-marker character; and determining the data spliced by the transaction hash, the post-marked character and the non-sensitive content as the concealed data.
The determining module 1902 adjusts a model based on a preset expression mode, and adjusts the expression mode of the non-sensitive content; and determining hidden data according to the transaction hash and the adjusted non-sensitive content.
The determining module 1902 obtains a signature of the concealing instruction, and determines whether the obtained signature meets a specified condition; if yes, determining hidden data according to the hidden command; if not, rejecting the hidden instruction.
If the transaction corresponding to the target transaction identifier is a transaction written into a block chain, the signature of the hidden command is a signature of a block chain link point, and the specified condition is that the number of acquired signatures is larger than the specified number.
If the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the appointed condition is that the acquired signature comprises signatures of at least two authority parties.
The signature of each authority is assigned with a weight;
if the transaction corresponding to the target transaction identifier is a transaction written into a blockchain-like, the specified condition is that the sum of weights corresponding to the obtained signatures is larger than the specified weight.
For any block in the block chain, if the block does not contain the suppressed data, the tag of the block is not the specified tag.
Let the block chain include N blocks, the value of the ith binary bit of the pre-created binary string be the label of the ith block in the block chain, i E [1, N ].
The apparatus further comprises:
the transaction write module 1904 writes a chain of suppressed transactions into which the suppressed instruction is packaged.
The transaction write module 1904 writes a chain of suppressed transactions that encapsulates the data hash of the suppressed data and the suppressed data.
Fig. 20 is a schematic structural diagram of an apparatus for building a merkel tree corresponding to a block according to an embodiment of the present disclosure, including:
an acquiring module 2001, for a target block in a block chain, acquiring a tag of the target block;
a reading module 2002 that reads data from each transaction storage location in the target block if the tag of the target block is a specified tag; wherein the specified tag characterizes at least one sensitive transaction stored in the target block, for each sensitive transaction, the sensitive transaction having been replaced with suppressed data comprising a transaction hash of the sensitive transaction;
the first processing module 2003 performs hash calculation on the transaction included in the read data if it is determined that the data read from the transaction storage location includes a transaction, to obtain a transaction hash corresponding to the transaction storage location;
the second processing module 2004 extracts, if it is determined that the data read from the transaction storage location includes the suppressed data, a transaction hash from the suppressed data included in the read data as a transaction hash corresponding to the transaction storage location;
the construction module 2005 constructs a merkel tree corresponding to the target block based on the transaction hashes corresponding to the transaction storage locations in the target block.
The operation of replacing the sensitive transaction stored in the target block with the suppressed data is as follows:
determining a transaction hash of the sensitive transaction;
splicing a preset front mark character to the head of the transaction hash;
determining hidden data according to the data formed by splicing the front marking characters and the transaction hash;
the sensitive transaction is replaced with the determined concealed data.
Determining hidden data according to the data formed by splicing the front marking characters and the transaction hash, wherein the method specifically comprises the following steps:
splicing a preset post-marking character to the tail of the transaction hash, and splicing remark information to the tail of the post-marking character;
and determining the data spliced by the front marking character, the transaction hash, the rear marking character and the remark information as the concealed data.
The first processing module 2003 determines that the data read from the transaction storage location includes a transaction if the data read from the transaction storage location does not include the pre-marking character;
the second processing module 2004 determines that the data read from the transaction memory location includes suppressed data if the data read from the transaction memory location includes the pre-marked character.
The second processing module 2004 determines, as a transaction hash, data located after the pre-marker character among the concealed data included in the read data and extracts the transaction hash; or determining the data with the specified length behind the front mark character in the concealed data included in the read data as transaction hash and extracting.
The second processing module 2004 determines, as a transaction hash, data between the front and rear marker characters among the suppressed data included in the read data.
For each transaction storage location in a chain of blocks, storing a content field and an identification field, the content field comprising a transaction or suppressed data generated based on the transaction;
wherein the identification field comprises a first identifier when the content field comprises a transaction and a second identifier when the content field comprises suppressed data generated based on the transaction;
the first processing module 2003 determines that the data read from the transaction storage location includes a transaction if the identification field in the data read from the transaction storage location includes a first identifier;
The second processing module 2004 determines that the data read from the transaction memory location includes suppressed data if the identification field in the data read from the transaction memory location includes a second identifier.
The building module 2005 builds a merkel tree corresponding to the target block by default if the tag of the target block is not a specified tag.
Setting the block chain to comprise N blocks, wherein the value of the ith binary bit of the binary number string which is created in advance is the label of the ith block in the block chain, i epsilon [1, N ];
the acquiring module 2001 determines the sequence number M of the target block; and reading the value of the Mth binary bit from the binary number string as a label of the target block.
Fig. 21 is a schematic structural diagram of a simple payment verification device according to an embodiment of the present disclosure, including:
a receiving module 2101 that receives a verification request; the verification request comprises a target transaction identifier;
a building module 2102, configured to determine, according to the verification request, a block where the transaction corresponding to the target transaction identifier is located in a block chain of the building module, and build a merkel tree corresponding to the block based on a method shown in fig. 11 or fig. 13;
The verification module 2103 performs simple payment verification for the transaction corresponding to the target transaction identifier based on the constructed merkel tree.
A centralized storage scheme based on a block-like chain is as follows:
s1, receiving data records to be stored, and determining hash values 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.
And S2, when the preset blocking condition is reached, determining each data record in the block to be written, and generating an N-th block containing the hash value of the block and the data record.
The preset blocking conditions include: the number of data records to be stored reaches a number threshold, for example, a new block is generated each time one thousand data records are received, and one thousand data records are written into the block; alternatively, the time interval from the last block forming time reaches a time threshold, for example, every 5 minutes, a new block is generated, and the data record received within the 5 minutes is written into the block.
Here, N refers to the sequence number of the block, in other words, in the embodiment of the present specification, the block is in the form of a block chain, and is arranged in sequence based on the time of forming the block, which has a strong timing characteristic. Wherein the block heights of the blocks monotonically increase based on the order of the block forming times. The block height may be a sequence number, and at this time, the block height of the nth block is N; block heights may also be generated in other ways.
When n=1, the block at this time is the initial block. The hash value and block height of the initial block are given based on a preset manner. For example, the initial block does not include a data record, and the hash value is any given hash value, and the block height blknum=0; for another example, the generation trigger condition of the initial block is identical to the trigger condition of the other blocks, but the hash value of the initial block is determined by hashing all the contents in the initial block.
When N >1, since the content and the hash value of the previous block have been determined, at this time, the hash value of the current block (nth block) may be generated based on the hash value of the previous block (i.e., nth-1 th block), for example, in a feasible manner, determining the hash value of each data record to be written into nth block, generating a merck tree according to the arrangement sequence in the blocks, splicing the root hash value of the merck tree with the hash value of the previous block, 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 can be obtained by splicing the hash values of the previous block and the hash value of the whole data record according to the sequence of the data records in the block, and the hash operation can be performed on the word strings obtained by splicing to generate the hash value of the block.
By the above-described generation method of the blocks, each block is determined by a hash value, and the hash value of the block is determined by the content and sequence of the data record in the block and the hash value of the previous block. The user can initiate verification based on the hash value of the block at any time, and the modification of any content in the block (including the modification of the data record content or sequence in the block) can cause the inconsistency between the hash value of the block calculated during verification and the hash value generated during the generation of the block, so that verification failure is caused, and the non-falsification under centralization is realized.
The centralized storage of data records in a blockchain manner is achieved by generating a block comprising a number of data records and recording hash values at the time of block generation. In this data storage mode, the hash value of each block depends on the hash value of the previous block and the content of the data record contained in the previous block. The user can inquire the data record at any time based on the storage form, and can verify the hash value of the appointed block or the appointed data record according to the hash value, so that the integrity of the user data is ensured, and the user experience is improved.
The embodiments of the present disclosure also provide a computer device, which at least includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the functions of the methods shown in fig. 2, 5, 7, 9 to 14 when executing the program.
FIG. 22 illustrates a more specific hardware architecture diagram of a computing device provided by embodiments of the present description, which may include: processor 2210, memory 2220, input/output interfaces 2230, communication interfaces 2240, and a bus 2250. Wherein processor 2210, memory 2220, input/output interface 2230, and communication interface 2240 implement communication connections among each other within the device via bus 2250.
The processor 2210 may be implemented by a general-purpose CPU (Central Processing Unit ), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc. for executing related programs to implement the technical solutions provided in the embodiments of the present disclosure.
Memory 2220 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory ), static storage devices, dynamic storage devices, or the like. Memory 2220 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 2220 and executed by processor 2210.
The input/output interface 2230 is used for connecting with an input/output module to realize information input and output. 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.
The communication interface 2240 is used to connect to a communication module (not shown in the figure) to enable communication interaction between the device and 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 2250 includes a path that communicates information between various components of the device, such as processor 2210, memory 2220, input/output interface 2230, and communication interface 2240.
It is noted that although the above-described devices illustrate only processor 2210, memory 2220, input/output interface 2230, communication interface 2240, and bus 2250, the device may include other components necessary to achieve proper operation in an implementation. 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 embodiments also provide a computer readable storage medium having stored thereon a computer program which when executed by a processor performs the functions of the methods shown in fig. 2, 5, 7, 9 to 14.
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 and apparatus embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, with reference to the description of the method embodiments in part. 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.