CN111784350B

CN111784350B - Meeker tree corresponding to building block, simple payment verification method and device

Info

Publication number: CN111784350B
Application number: CN202010581368.7A
Authority: CN
Inventors: 杨新颖
Original assignee: Ant Chain Technology Co ltd
Current assignee: Ant Chain Technology Co ltd
Priority date: 2019-01-31
Filing date: 2019-01-31
Publication date: 2024-11-29
Anticipated expiration: 2039-01-31
Also published as: CN110033264A; CN110033264B; CN111784350A

Abstract

A method and device for building block-corresponding Meeker tree and simple payment verification are disclosed. If a transaction written to the blockchain is sensitive to be unpublished, then the transaction in the blockchain may be replaced with a transaction hash of the transaction and an associated merkel tree construction, simple payment verification, based on the replaced transaction hash may be performed.

Description

Meeker tree corresponding to building block, simple payment verification method and device

Technical Field

The embodiment of the specification relates to the technical field of information, in particular to a method and a device for verifying simple payment of a merkel tree corresponding to a building block.

Background

A blockchain network is a decentralized, distributed data storage system that is engaged by multiple nodes. Once data is written into the blockchain on each node, on one hand, the data is disclosed in the whole network, and on the other hand, the data written into the blockchain is difficult to delete and tamper. Based on the method, the blockchain technology has a great application prospect in the field of data storage.

In addition, in practice, the centralized device may also store data in a manner similar to a blockchain storage (which may be regarded as a centralized blockchain storage), where the blocks in the blockchain are the same as the generation principle of the blocks in the blockchain. Obviously, if the data written into the class blockchain is to be deleted, unless the centralized device deletes the entire class blockchain stored. Therefore, the centralized blockchain-like storage is also suitable for application to data logging services. The blockchain storage and other centralized blockchain-like storage are collectively referred to herein as blockchain storage.

However, in practice, some content (referred to herein as sensitive content) once written to the block chain can have harmful consequences that are difficult to eliminate.

Assuming that the above-mentioned sensitive content is deleted from the block chain, it is easy to affect the accuracy of Simple Payment Verification (SPV) for other data (data located in the same block as the sensitive content), thereby affecting the normal operation of the data certification service.

Based on the above, how to not only make the sensitive content of the writing block chain not be disclosed, but also not influence the normal operation of the certification service for other data is a technical problem to be solved by the prime.

Disclosure of Invention

In order to prevent sensitive content written into a block chain from being disclosed and not to affect normal operation of a certification service for other data, the embodiment of the specification provides a method and a device for constructing a merkel tree and simply paying and verifying corresponding to a block, which have the following technical scheme:

According to an aspect 1 of the embodiments of the present disclosure, there is provided a method for building a merkel tree corresponding to a block, including:

Aiming at a target block in a block chain, acquiring a label of the target block;

Reading data from each transaction storage location in the target block if the tag of the target block is a designated tag, wherein the designated tag characterizes at least one sensitive transaction stored in the target block, and for each sensitive transaction the sensitive transaction has been replaced with suppressed data comprising a transaction hash of the sensitive transaction;

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 a transaction hash corresponding to the transaction storage position;

if the data read from the transaction storage location is determined to comprise the concealed data, extracting a transaction hash from the concealed data comprising the read data as a transaction hash corresponding to the transaction storage location;

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.

According to an aspect 2 of the embodiments of the present disclosure, there is provided an apparatus for building a merkel tree corresponding to a block, including:

The acquisition module is used for acquiring a label of a target block in a block chain aiming at the target block;

the system comprises a target block, a reading module, a transaction storage location, a transaction hash module and a transaction hash module, wherein the target block is provided with a label, and the transaction storage location is used for storing transaction hash data;

The first processing module is used for carrying out hash calculation on the transaction included in the read data if the data read from the transaction storage position is determined to include the transaction, so as to obtain a transaction hash corresponding to the transaction storage position;

A second processing module that extracts a transaction hash from the concealed data included in the read data as a transaction hash corresponding to the transaction storage location if it is determined that the data read from the transaction storage location includes the concealed data;

And the construction module is used for constructing a Meissuer tree corresponding to the target block based on the transaction hashes respectively corresponding to the transaction storage positions in the target block.

According to the 3 rd aspect of the embodiments of the present specification, there is provided a simple payment verification method, including:

receiving a verification request, wherein the verification request comprises a target transaction identifier;

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 the method of the 1 st aspect;

and based on the constructed Meicher tree, performing simple payment verification on the transaction corresponding to the target transaction identifier.

According to the 4 th aspect of the embodiments of the present specification, there is provided a simple payment verification apparatus comprising:

The receiving module receives a verification request, wherein the verification request comprises a target transaction identifier;

The construction module is used for determining a block where the transaction corresponding to the target transaction identifier is located in a block chain of the construction module according to the verification request, and constructing a merkel tree corresponding to the block based on the method of the 1 st aspect;

and the verification module is used for carrying out simple payment verification on the transaction corresponding to the target transaction identifier based on the constructed Meeker tree.

In the technical solution provided in the embodiments of the present disclosure, if a transaction written into a block chain is a sensitive transaction (including a sensitive content that is not easy to disclose), the transaction in the block chain may be replaced by a hidden data including a transaction hash of the transaction. In one aspect, the transaction hash of the transaction is calculated by using a one-way hash algorithm (i.e., a hash algorithm) on the transaction, and the transaction cannot be deduced from the transaction hash of the transaction, so replacing the transaction with the suppressed data corresponds to irrecoverably suppressing the plaintext content of the transaction that is disclosed in the block chain. On the other hand, the transaction is replaced by the hidden data, so that the stability of the merkel tree corresponding to the block where the transaction is located is not affected, and the accuracy of simple payment Verification (SIMPLIFIED PAYMENT Verification, SPV) for other transactions (transactions in the same block as the transaction) is not affected, thereby ensuring the normal operation of the data storage and Verification service.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the embodiments of the disclosure.

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

Drawings

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

FIG. 1 is a schematic diagram of the structure of a Meeker tree provided by the present description;

FIG. 2 is a flow chart of a method of concealing transactions involving a chain of blocks provided by embodiments of the present disclosure;

FIG. 3 is a schematic diagram of a process for constructing suppressed data provided by embodiments of the present description;

FIG. 4 is a schematic diagram of another process for constructing suppressed data provided by embodiments of the present disclosure;

FIG. 5 is a flow chart of a method for concealing transactions involving a chain of blocks provided by embodiments of the present disclosure;

FIG. 6 is a schematic diagram of content fields and identification fields provided by an embodiment of the present disclosure;

FIG. 7 is a flow chart of a method for concealing transactions written to a blockchain according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of suppressed data including non-sensitive content provided by an embodiment of the present disclosure;

FIG. 9 is a flow chart of a method for concealing transactions involving a chain of blocks provided by embodiments of the present disclosure;

FIG. 10 is a flow chart of a method for concealing transactions involving a chain of blocks provided by embodiments of the present disclosure;

fig. 11 is a flowchart of a method for constructing a merkel tree corresponding to a block according to an embodiment of the present disclosure;

FIG. 12 is a flow chart of a method for concealing transactions involving a chain of blocks provided by embodiments of the present disclosure;

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;

FIG. 14 is a flow chart of a simple payment verification method provided by an embodiment of the present disclosure;

FIG. 15 is a schematic diagram of an apparatus for concealing transactions involving a chain of blocks according to an embodiment of the present disclosure;

FIG. 16 is a schematic diagram of an apparatus for concealing transactions involving a chain of blocks according to the present invention;

FIG. 17 is a schematic diagram of an apparatus for concealing transactions involving a chain of blocks according to the present invention;

FIG. 18 is a schematic diagram illustrating an apparatus for concealing transactions involving a chain of blocks according to the present invention;

FIG. 19 is a schematic diagram of an apparatus for concealing transactions involving a chain of blocks according to the present invention;

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;

Fig. 21 is a schematic structural view of a simple payment verification apparatus provided in the embodiment of the present specification;

fig. 22 is a schematic diagram of a computer device for configuring the apparatus of the embodiment of the present specification.

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 merkel tree (MERKLE TREES) based on each transaction in the target block, then determines a merkel path corresponding to the target transaction, and returns a hash value associated with the merkel 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 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, if the transaction 2 contains sensitive content, if the transaction 2 is directly deleted from the block chain, when simple payment verification is required for any one of the transactions 1 and 3-8, only a merkel tree can be built based on the transactions 1 and 3-8 due to lack of the 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 the transactions 1 and 3-8 are 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, receiving a hiding instruction.

The scene applied by the invention is a data evidence storage scene based on a block chain. In this scenario, data is either block-chained by a blockchain network comprising a plurality of nodes, or block-chained by a centralizing device.

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.

In a blockchain scene, each blockchain link point receives a concealment instruction, and specifically, each blockchain link point receives a concealment transaction encapsulated with the 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, 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, 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 transaction hash of the transaction corresponding to the target transaction identifier when constructing the hidden data, splice a preset front mark character to the head of the transaction hash, and determine the hidden data according to the data spliced by the front mark character and the transaction hash.

The effect of the pre-marker character described above is that, when reading data from a transaction storage location, if the transaction in the transaction storage location has been replaced with suppressed data, reading the pre-marker character in the suppressed data corresponds to the clear that the transaction storage location stores not the plaintext content of the transaction but 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 a transaction corresponding to the target transaction identifier can be obtained, a preset front mark character is spliced to the head part of the transaction hash, a preset rear mark character is spliced to the tail part of the transaction hash, remark information is spliced to the tail part of the rear mark character, and then the data spliced by the front mark character, the transaction hash, the rear mark character and the remark information are determined to be the hidden 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, receiving a hiding instruction containing a target transaction identifier, and determining a transaction storage position for storing a 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, determining the concealed data according to the concealed instruction.

And S504, replacing the transaction in the content field of the target transaction storage location with the concealed data.

S506, replacing the first identifier in the identification field of the target transaction storage location with a 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.

In practice, however, in order to avoid "hash collisions" between the transaction hash in the concealing data and the pre-marker character (i.e., the node or the centralising device cannot distinguish between whether the character read from the transaction memory location is the pre-marker character or the character in the transaction hash when executing the transaction concealing logic), the pre-marker character is typically set to a special character that is not theoretically repeatable with the transaction hash, such special character typically being long (taking up many bytes) and placing a significant burden on the node or centralising device that reads the 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, receiving a hiding instruction.

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, obtaining 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.

And S704, 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, 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, receiving a hiding instruction.

S902, acquiring 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, 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 replacing a transaction in the block chain corresponding to the target transaction identification with the suppressed data.

The expression mode adjustment model may be a preset expression mode adjustment rule, for example, the expression mode adjustment rule may be that if a Chinese character exists in the non-sensitive content, the Chinese character is replaced by pinyin. For another example, the expression adjustment rule may be to replace at least one uppercase english letter with a lowercase english letter if the uppercase english letter is present in the non-sensitive content.

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 above embodiments one to four, a permission 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, acquiring the signature of the hidden command, judging whether the acquired signature meets the specified condition, if so, executing the step S804, and if not, executing the step S806.

And S1004, determining hidden data comprising transaction hashes of transactions corresponding to the target transaction identifications according to the hidden instructions, and replacing the transactions corresponding to the target transaction identifications in a block chain with the hidden 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 embodiments of the present disclosure, as shown in fig. 11, includes:

s1100, for each transaction storage location in the target block, reading data from the transaction storage location.

If it is determined that the data read from the transaction storage location includes a transaction, then hash calculation is performed on the transaction included in the read data to obtain a transaction hash corresponding to the transaction storage location.

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, based on the transaction hashes corresponding to the transaction storage positions in the target block, building a Meissuer tree corresponding to 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 except the transaction corresponding to the target transaction identifier is indicated, the label of the target block does not need to be changed, and if the target block is not the designated label, the label of the target block does not contain the hidden data, and the label of the target block needs to be modified into the designated label.

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, receiving a hidden instruction.

And S1202, determining the concealed data according to the concealed instruction.

And S1204, replacing the transaction corresponding to the target transaction identification in the block chain with the concealed data.

And S1206, determining the label of the block where the transaction corresponding to the target transaction identifier is located 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, acquiring a label of a target block in a block chain aiming at the target block.

If the tag of the target block is a designated tag, then data is read from each transaction storage location in the target block for that transaction storage location S1302.

If it is determined that the data read from the transaction storage location includes a transaction, then a hash calculation is performed on the transaction included in the read data to obtain a transaction hash corresponding to the transaction storage location.

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

S1308, based on the transaction hash corresponding to each transaction storage position in the target block, building a Meissuer tree corresponding to the target block.

Further, for each transaction storage location in the target block, determining 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-marker character, and determining that the data read from the transaction storage location includes suppressed data if the data read from the transaction storage location includes the pre-marker character.

Or 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 first identifier, and determining that the data read from the transaction storage location includes suppressed data if the identification field in the data read from the transaction storage location includes a second identifier.

In the seventh embodiment, the transaction hash may be extracted from the concealed data included in the read data by determining, as the transaction hash, data located after the pre-marker character in the concealed data included in the read data, or by determining, as the transaction hash, data of a specified length located after the pre-marker character in the concealed data included in the read data.

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

In this way, the tag of the target block may be obtained by determining the sequence number M of the target block, and reading the value of the mth binary bit from the binary string as the tag 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, wherein 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 Meeker tree corresponding to the block based on the method shown in FIG. 11 or FIG. 13;

And S1404, based on the constructed Meeker 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 configured to determine, based on the concealment instruction, concealment data comprising a transaction hash for a 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, extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to a concealment condition included in the concealment instruction, and determines concealment 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, splices the non-sensitive content to the tail of the post-marker character, and determines the data spliced by the transaction hash, the post-marker character and the non-sensitive content as the concealed data.

The determining module 1502 adjusts the expression of the non-sensitive content based on a preset expression adjustment model, and determines the hidden data according to the transaction hash and the adjusted non-sensitive content.

The determining module 1502 obtains the signature of the hidden command and determines whether the obtained signature meets a specified condition, if so, determines the hidden data according to the hidden command, and if not, refuses the hidden command.

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:

The system comprises a receiving module 1601, a hiding instruction, a processing module and a processing module, wherein the hiding instruction comprises a target transaction identifier and a hiding condition, and 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;

The determining module 1603 splices a preset post-marked character to the tail of the transaction hash, splices the non-sensitive content to the tail of the post-marked character, and determines the data spliced by the transaction hash, the post-marked character and the non-sensitive content as the hidden data.

The determining module 1603 adjusts the expression mode of the non-sensitive content based on a preset expression mode adjustment model, and determines the 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 the specified condition, if yes, determining hidden data according to the hidden command, and if not, rejecting the hidden command.

The signature of each authority is assigned with a 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.

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:

the system comprises a receiving module 1701, a hiding instruction, a storage module and a display module, wherein the hiding instruction comprises a target transaction identifier and hiding conditions, and the hiding conditions are used for determining sensitive contents in transactions 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.

The adjustment determining module 1703 is configured to splice a preset post-tag character to a tail of the transaction hash, splice the adjusted non-sensitive content to a tail of the post-tag character, and determine data spliced by the transaction hash, the post-tag character, and the adjusted non-sensitive content as concealed data.

The adjustment determining module 1703 obtains the signature of the hidden command and determines whether the obtained signature meets a specified condition, if so, determines hidden data according to the hidden command, and if not, refuses the hidden command.

The signature of each authority is assigned with a 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.

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, wherein the concealing instruction 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.

The signature of each authority is assigned with a weight;

The first processing module 1803 obtains a transaction hash of the transaction corresponding to the target transaction identifier, splices a preset front mark character into the head of the transaction hash, and determines hidden data according to data spliced by the front mark character and the transaction hash.

The first processing module 1803 splices a preset post-tag character to the tail of the transaction hash, splices remark information to the tail of the post-tag character, and determines the data spliced by the pre-tag character, the transaction hash, the post-tag character and the remark information as hidden data.

The first processing module 1803 obtains a transaction hash of the transaction corresponding to the target transaction identifier, extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to the concealment condition included in the concealment instruction, and determines concealment data according to the transaction hash and the non-sensitive content.

The first processing module 1803 splices a preset post-tag character to the tail of the transaction hash, splices the non-sensitive content to the tail of the post-tag character, and determines the data spliced by the transaction hash, the post-tag character and the non-sensitive content as the concealed data.

The first processing module 1803 adjusts the expression mode of the non-sensitive content based on a preset expression mode adjustment model, and determines 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.

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 that receives a concealment instruction, the concealment instruction comprising a target transaction identity;

A determining module 1902, configured to determine, according to the concealment instruction, concealment data, where the concealment data includes a transaction hash of a 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 a transaction corresponding to the target transaction identifier, splices a preset front mark character into the head of the transaction hash, and determines hidden data according to data spliced by the front mark character and the transaction hash.

The determining module 1902 splices a preset post-marker character to the tail of the transaction hash and splices remark information to the tail of the post-marker character, and determines the data spliced by the pre-marker character, the transaction hash, the post-marker character and the remark information as hidden data.

The determining module 1902 obtains a transaction hash of the transaction corresponding to the target transaction identifier, extracts non-sensitive content from the transaction corresponding to the target transaction identifier according to the concealment condition included in the concealment instruction, and determines concealment data according to the transaction hash and the non-sensitive content.

The determining module 1902 is configured to splice a preset post-marker character to a tail of the transaction hash, splice the non-sensitive content to a tail of the post-marker character, and determine data spliced by the transaction hash, the post-marker character and the non-sensitive content as hidden data.

The determining module 1902 adjusts the expression mode of the non-sensitive content based on a preset expression mode adjustment model, and determines the hidden data according to the transaction hash and the adjusted non-sensitive content.

The determining module 1902 obtains the signature of the hidden command and determines whether the obtained signature meets the specified condition, if yes, determines hidden data according to the hidden command, and if not, refuses the hidden command.

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.

The signature of each authority is assigned with a weight;

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 for reading data from each transaction storage location in the target block if the tag of the target block is a designated tag, wherein the designated tag characterizes at least one sensitive transaction stored in the target block, which has been replaced with hidden data comprising a transaction hash of the sensitive transaction for each 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 that is located after the pre-marker character in the concealed data included in the read data, or determines, as a transaction hash, data of a specified length that is located after the pre-marker character in the concealed data included in the read data.

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.

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 reads the value of the mth binary bit from the binary string as the tag 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:

the receiving module 2101 receives a verification request, wherein 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 condition includes that the number of data records to be stored reaches a number threshold, for example, a new block is generated every time a thousand data records are received, and one thousand data records are written into the block, or a time interval from the last blocking time reaches a time threshold, for example, every 5 minutes, a new 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 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, where the block height of the nth block is N, and the block height may be generated in other manners.

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 contain a data record, the hash value is any given hash value, the block height is blknum =0, and for example, the generation trigger condition of the initial block is consistent with the trigger condition of other blocks, but the hash value of the initial block is determined by hashing all 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 embodiment of the present disclosure further provides a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor, where the processor implements the functions of the methods shown in fig. 2, 5, 7, 9-14 when executing the program.

Fig. 22 illustrates a more detailed hardware architecture of a computing device provided by embodiments of the present disclosure, which may include a 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 (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, dynamic storage, 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 embodiments of the present disclosure also provide a computer readable storage medium having a computer program stored thereon, which when executed by a processor, implements the functions of the methods shown in fig. 2, 5, 7, 9-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.

Claims

1. A method for constructing a Merkle tree corresponding to a block, comprising:

For a target block in the blockchain, obtaining a label of the target block;

If the label of the target block is a specified label, then obtaining a transaction hash corresponding to each transaction storage location in the target block; wherein the specified label indicates that at least one sensitive transaction has been stored in the target block, and for each sensitive transaction, the sensitive transaction has been replaced with anonymized data including the transaction hash of the sensitive transaction;

For each transaction storage location, read data from the transaction storage location and determine its data type. If the read data includes anonymized data, extract a transaction hash from the anonymized data as the transaction hash corresponding to the transaction storage location.

Based on the transaction hashes corresponding to the transaction storage locations in the target block, a Merkle tree corresponding to the target block is constructed.

2. According to the method of claim 1, the operation of replacing the sensitive transaction stored in the target block with the anonymized data is as follows:

Determining a transaction hash of the sensitive transaction;

splicing a preset front mark character to the header of the transaction hash; the front mark character is a character used to mark before the transaction hash;

Determine the anonymized data based on the data formed by concatenating the preceding mark character and the transaction hash;

The sensitive transactions are replaced with determined anonymized data.

3. The method according to claim 2, determining the anonymized data according to the data concatenated by the preceding mark character and the transaction hash, specifically comprising:

Splicing a preset post-mark character to the end of the transaction hash, and splicing the remark information to the end of the post-mark character; the post-mark character is a character used to mark after the transaction hash;

The data formed by concatenating the front mark character, the transaction hash, the rear mark character and the remark information is determined as the anonymized data.

4. The method according to claim 2 or 3, determining that the transaction storage location stores anonymized data, specifically comprises:

If the data stored in the transaction storage location includes the preceding marking character, it is determined that the transaction storage location stores anonymized data.

5. The method of claim 2, extracting the transaction hash from the anonymized data, specifically comprising:

Determine and extract the data after the preceding mark character in the anonymized data as a transaction hash;

Alternatively, data of a specified length after the preceding mark character in the anonymized data is determined as a transaction hash and extracted.

6. The method of claim 3, extracting the transaction hash from the anonymized data, specifically comprising:

The data between the front mark character and the back mark character in the anonymized data is determined as a transaction hash and extracted.

7. The method of claim 1, wherein for each transaction storage location in the block chain, the transaction storage location stores a content field and an identification field, wherein the content field includes the transaction or anonymized data generated based on the transaction;

Wherein, when the content field includes a transaction, the identification field includes a first identifier, and when the content field includes anonymized data generated based on the transaction, the identification field includes a second identifier;

Determine that the transaction storage location stores anonymized data, including:

If the identification field in the data stored in the transaction storage location includes the second identifier, it is determined that the transaction storage location stores anonymized data.

8. The method of claim 1, further comprising:

If the data read includes a transaction, a one-way hash algorithm is used to perform a hash calculation on the transaction to obtain a transaction hash corresponding to the transaction storage location.

9. The method of claim 1, further comprising:

If the label of the target block is not a specified label, a Merkle tree corresponding to the target block is constructed in a default manner;

The default method is to use the hash value of each transaction stored in the target block as a leaf node to construct a Merkle tree.

10. The method as claimed in claim 9, assuming that the block chain includes N blocks, the value of the i-th binary bit of the pre-created binary number string is the label of the i-th block in the block chain, i∈[1,N];

Obtaining the label of the target block includes:

Determine the sequence number M of the target block;

The value of the Mth binary bit is read from the binary number string as the label of the target block.

11. A simple payment verification method, comprising:

receiving a verification request; the verification request including a target transaction identifier;

According to the verification request, determine the block where the transaction corresponding to the target transaction identifier is located in its own blockchain, and construct a Merkle tree corresponding to the block based on the method described in any one of claims 1 to 10;

Based on the constructed Merkle tree, a simple payment verification is performed on the transaction corresponding to the target transaction identifier.

12. A device for constructing a Merkle tree corresponding to a block, comprising:

An acquisition module, for a target block in a block chain, acquires a label of the target block;

The reading module obtains a transaction hash corresponding to each transaction storage location in the target block if the tag of the target block is a specified tag; wherein the specified tag indicates that at least one sensitive transaction has been stored in the target block, and for each sensitive transaction, the sensitive transaction has been replaced with anonymized data including the transaction hash of the sensitive transaction;

The processing module reads data from each transaction storage location and determines the data type thereof, and if the read data includes anonymized data, extracts a transaction hash from the anonymized data as the transaction hash corresponding to the transaction storage location;

A construction module is used to construct a Merkle tree corresponding to the target block based on the transaction hashes corresponding to the transaction storage locations in the target block.

13. A simple payment verification device, comprising:

A receiving module receives a verification request; the verification request includes a target transaction identifier;

A construction module, which determines, according to the verification request, in its own blockchain, the block where the transaction corresponding to the target transaction identifier is located, and constructs a Merkle tree corresponding to the block based on the method described in any one of claims 1 to 10;

The verification module performs simple payment verification on the transaction corresponding to the target transaction identifier based on the constructed Merkle tree.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 11 when executing the program.