Blockchain transaction data field verification

Abstract

A computer-implemented method for generating a secondary transaction identifier for a target transaction, the secondary transaction identifier enabling a querying user to determine whether the target transaction includes a candidate data field. The method includes identifying a set of data fields for the target transaction, each data field including corresponding data for the transaction; generating a transaction hash tree. Each data field is hashed to generate a corresponding one of a plurality of leaf hash values ​​of the transaction hash tree. A root hash value of the transaction hash tree includes the secondary transaction identifier.

Description

Technical Field

[0001] The present disclosure relates to a method for enabling a querying user to verify whether a transaction within a block of a blockchain includes a candidate data field. Background Art

[0002] Blockchain refers to a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. The blockchain consists of a series of data blocks, where each block includes one or more transactions. Each transaction refers back to the previous transaction in the sequence, tracing back to the genesis block at the beginning of the blockchain. Transactions can be included in new blocks by submitting them to the network through a process called "mining", which involves solving cryptographic puzzles based on a pool of pending transactions waiting to be included in a block.

[0003] Transactions in a blockchain are usually used to transfer digital assets, i.e. data used as a store of value. However, blockchains can also be used to layer additional functionality on top of the blockchain. For example, a blockchain protocol can allow for the storage of additional user data in a transaction output. Modern blockchains are constantly increasing the maximum amount of data that can be stored in a single transaction, allowing for the incorporation of more complex data. This can be used, for example, to store electronic documents or even audio or video data in a blockchain.

[0004] Each node in the network can have any one, two, or all of the following three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions throughout the network nodes. Mining nodes mine transactions into blocks. Storage nodes each store their own copy of the mined blocks in the blockchain. In order to record a transaction in the blockchain, one party sends the transaction to one of the nodes in the network for propagation. The mining nodes that receive the transaction can compete to mine the transaction into a new block. Each node is configured to comply with the same node protocol, which will include one or more conditions for confirming that the transaction is valid. Invalid transactions will not be propagated or mined into blocks. Assuming that the transaction has been verified to be valid and thus accepted on the blockchain, the additional user data will therefore continue to be stored at each node in the P2P network as an immutable public record.

[0005] Each block in a blockchain typically contains a summary of all transactions in that block. This summary is generated using a "Merkle tree". A Merkle tree is a hash tree that contains cryptographic hash values. The term "Merkle tree" is sometimes used in the literature to refer to a binary hash tree, and although Merkle's original disclosure was not limited to binary hash trees, other places in the literature also use "hash tree" and "Merkle tree" as synonyms. The former definition is adopted in this article. The term "tree" refers to a branching data structure with a "root" at the top and "leaves" at the bottom. A Merkle tree is constructed by recursively hashing pairs of nodes until only one hash value exists, which is called the root or Merkle root. The root hash value represents the overall digital fingerprint of the entire set of transactions in the block, providing an efficient process to verify whether a transaction is included in the block. In order to prove that a specific transaction is included in the block, the node only needs to produce a relatively small number of hash values, forming a certification path or "Merkle path" connecting the specific transaction to the root of the tree. Summary of the invention

[0006] In most blockchain ecosystems, the functions and capabilities of the various types of nodes will vary. For example, a blockchain network node may have access to more computing resources, allowing them to store a full copy of the blockchain and verify all incoming transactions, while a regular user of the blockchain may have a more lightweight client for creating and broadcasting payments.

[0007] Nodes can use Merkle trees or hash trees to verify that a given transaction was mined into the blockchain. This is known in the art as Simplified Payment Verification (SPV), but is not limited to verifying payment transactions. This verification method typically requires a node (perhaps running only a lightweight client) to obtain the full transaction data, hash it, and perform a "Merkle proof."

[0008] Currently, SPV methods work well for lightweight clients that need to verify the presence of a small amount of data (such as an image file) in the blockchain. However, as the size of the blockchain ecosystem grows, transaction sizes may increase significantly, and the size of arbitrary data packets embedded in them may also increase significantly. This is a problem when verifying transactions where the entire transaction needs to be hashed, especially for lightweight clients, which means they may need to retrieve a large (e.g., megabyte or kilobyte) transaction to verify the presence of a smaller (e.g., kilobyte) data packet in a transaction on the blockchain.

[0009] Therefore, a node (e.g., a lightweight client) needs to be able to prove the existence of a partial transaction (e.g., a smaller data packet) without having to obtain the full transaction.

[0010] According to one aspect disclosed herein, there is provided a computer-implemented method for generating a secondary transaction identifier for a target transaction, the secondary transaction identifier enabling a querying user to determine whether the target transaction includes a candidate data field; the method is performed by a generating user and includes: identifying a set of data fields for the target transaction, each data field including corresponding data for the transaction; generating a transaction hash tree, wherein the transaction hash tree includes: i) a leaf layer, the leaf layer including a plurality of leaf hash values, wherein each data field is hashed to generate a corresponding one of the plurality of leaf hash values; ii) one or more inner layers, each of the one or more inner layers including a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of the lowest inner layer is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer including the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a cascade of the inner hash value of the highest inner layer of the one or more inner layers.

[0011] The present disclosure recognizes another way in which a Merkle tree, or more generally a hash tree, can be utilized to allow a node (i.e., a querying user) to verify individual data fields of a transaction. A transaction is split (or parsed) into a set of data fields for generating a hash tree, i.e., different parts of a transaction are identified as separate data fields. The root of the hash tree serves as a novel secondary identifier for the transaction. A querying user (e.g., who may only operate a lightweight client) can use the secondary identifier to perform a proof to prove the presence of a (small) data field in a transaction without having to obtain the full transaction data and hash it.

[0012] A secondary transaction identifier can be generated by any user who has access to the full transaction data. For example, the generating user can be a user of the blockchain network (e.g., Alice who has generated the transaction), or indeed a user who has been provided to or is able to view the transaction outside the blockchain.

[0013] According to another aspect disclosed herein, a method for enabling a querying user to determine whether a target transaction within a block of a blockchain includes a candidate data field is provided; the method is performed by a submitting user and includes: obtaining a secondary transaction identifier of the target transaction; submitting the secondary transaction identifier to a transaction to be included in a block of the blockchain, wherein the secondary transaction identifier has been generated by the following steps: identifying a set of data fields of the target transaction, each data field including corresponding data of the transaction; generating a transaction hash tree, wherein the transaction hash tree includes: i) a leaf layer, the leaf layer including a plurality of leaf hash values ​​sorted according to a set of ordered data fields, wherein for each data field hashing to generate a corresponding one of the plurality of leaf hash values; ii) one or more internal layers, each of the one or more internal layers comprising a plurality of internal hash values, wherein each internal hash value in each internal layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each internal hash value of the lowest internal layer of the one or more internal layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a cascade of the internal hash values ​​of the highest internal layer of the one or more internal layers.

[0014] The secondary transaction identifier may be stored on-chain for access by the querying user. Additionally or alternatively, Tx 1 The secondary transaction identifier can be recorded in different transactions Tx 2 The secondary transaction identifier may be recorded by the blockchain network node in the generated transaction.

[0015] Any user may record the secondary transaction identifier on-chain (i.e., cause it to be included on the blockchain). For example, a blockchain network node may include it in a transaction generated in a block (the same block or a different block containing the target transaction). Alternatively, a party (e.g., Alice) may cause the identifier to be included in a block of the blockchain by transmitting a (valid) transaction containing the secondary transaction identifier to one or more nodes to be mined into the blockchain.

[0016] According to another aspect disclosed herein, there is provided a computer-implemented method for verifying whether a candidate secondary transaction identifier of a target transaction within a block of a blockchain has been generated according to a specified protocol, the method being performed by a verifying user and comprising: obtaining the candidate secondary transaction identifier; identifying a set of data fields of the target transaction, each data field comprising corresponding data of the transaction; generating a transaction hash tree, wherein the transaction hash tree comprises: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each data field is hashed to generate a corresponding leaf hash value; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of the lowest inner layer is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a cascade of the inner hash values ​​of the highest inner layer; verifying whether the secondary transaction identifier matches the candidate secondary transaction identifier.

[0017] This allows any user (e.g., a node of a blockchain network) with access to the full transaction to verify that the generating user has used the correct protocol (e.g., correct identification of the transaction data fields and correct generation of the hash tree) to generate the secondary transaction identifier. Once it is verified that the recording user has used the correct protocol, the validating node can attest to that fact, for example, by notifying other blockchain users such as the querying user.

[0018] According to another aspect disclosed herein, a computer-implemented method for determining whether a target transaction within a block of a blockchain includes a candidate data field is provided, the method being performed by a querying user and comprising: obtaining a candidate leaf hash value, wherein the candidate leaf hash value is a hash value of the candidate data field; obtaining a candidate secondary transaction identifier for the target transaction, wherein the secondary transaction identifier is generated by identifying a set of data fields of the target transaction, each data field including corresponding data of the transaction, and generating a transaction hash tree, wherein a root layer of the transaction hash tree includes the secondary transaction identifier; obtaining a certification path for the candidate data field, wherein the certification path includes a set of ordered hash values, and wherein the set of ordered hash values ​​includes at least one leaf hash value and one or more sets of internal hash values, each set of internal hash values ​​belonging to a corresponding internal layer of the transaction hash tree; performing a hash tree certification using the obtained candidate leaf hash value, the obtained candidate secondary transaction identifier, and the obtained certification path for the candidate data field, the execution generating the secondary transaction identifier; wherein the determination is based on whether the secondary transaction identifier matches the candidate secondary transaction identifier.

[0019] As described above, the SPV method is currently used to verify whether a transaction exists on a blockchain. In this method, each transaction in a block forms a leaf of a hash tree. In contrast, the present disclosure uses a separate data field as a leaf of a hash tree to verify whether one of these data fields exists. When N data fields are hashed and summarized in a root hash value, a querying user can check whether any one of the data fields (candidate data fields) is included in the hash tree (and thus the transaction) by performing a hash tree proof (called a Merkle proof when the hash tree is a Merkle tree). To this end, a certification path, also called a hash tree path (and also called a Merkle path when the hash tree is a Merkle tree), is provided to the querying user. The querying user recursively hashes the candidate data fields using the continuous hash values ​​of the hash tree path until a candidate secondary transaction identifier (root hash value) is generated. The secondary transaction identifier is as unique as the underlying hash function used to generate it. Therefore, due to the characteristics of the hash function, if the candidate data field is part of the same transaction, the candidate secondary transaction identifier will only be the same as the secondary transaction identifier of the transaction. If the candidate secondary transaction identifier and the obtained secondary transaction identifier match, the querying user can be sure that the candidate data field is part of the transaction.

[0020] According to another aspect disclosed herein, there is provided a computer-implemented method for generating a secondary block identifier for a block of a blockchain, wherein the block includes a set of transactions, the secondary block identifier enabling a querying user to determine whether the set of transactions includes a candidate data field; the method is performed by a generating user and includes: for each transaction in the set of transactions, obtaining a corresponding secondary transaction identifier; generating a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, the leaf layer including a plurality of leaf hash values, wherein each leaf hash value corresponds to a corresponding one of the secondary transaction identifiers; ii) one or more inner layers, each of the one or more inner layers including a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer in the one or more inner layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer including the secondary block identifier, wherein the secondary block identifier is generated by hashing a cascade of the inner hash values ​​of a highest inner layer in the one or more inner layers.

[0021] Here, the individual secondary transaction identifiers for each transaction within a block serve as leaves of a "tree of transaction hash trees". That is, each secondary transaction identifier is itself the root hash value of a transaction hash tree. The root of a tree of transaction hash trees (also called a transaction set hash tree) serves as a secondary block identifier because it is a compression of all transactions within a block. A secondary block identifier can be generated by any user who can obtain (e.g., generate) all secondary transaction identifiers. For example, a generating user can be a blockchain network node that has generated a secondary transaction identifier. Alternatively, the secondary transaction identifier can be extracted from a transaction that includes a secondary transaction identifier (e.g., a generating transaction).

[0022] It should be noted that there are other ways to identify a block, such as block header, block height, block depth, and block number. However, the term "block identifier" is used throughout to refer to the (Merkle) root of the hash tree. For example, a secondary block identifier is the root of a transaction tree.

[0023] According to another aspect disclosed herein, a method for enabling a querying user to determine whether a set of transactions within a block of a blockchain includes a candidate data field is provided; the method is performed by a submitting user and comprises: obtaining a secondary block identifier of the block including the set of transactions; submitting the secondary block identifier to a transaction to be included in a block of the blockchain, wherein the secondary block identifier has been generated by the following steps: for each transaction in the set of transactions, obtaining a corresponding secondary transaction identifier; generating a transaction set hash tree, wherein the transaction set hash tree comprises: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each leaf hash value corresponds to A corresponding one of the secondary transaction identifiers; ii) one or more internal layers, each of the one or more internal layers comprising multiple internal hash values, wherein each internal hash value in each internal layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each internal hash value of the lowest internal layer of the one or more internal layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary block identifier, wherein the secondary block identifier is generated by hashing a cascade of the internal hash value of the highest internal layer of the one or more internal layers.

[0024] Likewise, any user with access to secondary transaction identifiers (e.g., a user who has generated those identifiers) may generate secondary block identifiers.

[0025] According to another aspect disclosed herein, there is provided a computer-implemented method for verifying whether a candidate secondary block identifier of a block of a blockchain has been generated according to a specified protocol, wherein the block includes a set of transactions, wherein the method is performed by a verifying user and includes: obtaining the candidate secondary block identifier; for each transaction in the set of transactions, obtaining a corresponding secondary transaction identifier; generating a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, wherein the leaf layer includes a plurality of leaf hash values, wherein each leaf hash value corresponds to a corresponding one of the secondary transaction identifiers; ii) one or more inner layers, wherein each inner layer of the one or more inner layers includes a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, wherein the root layer includes the secondary block identifier, wherein the secondary block identifier is generated by hashing a cascade of the inner hash values ​​of a highest inner layer of the one or more inner layers; verifying whether the secondary block identifier matches the candidate secondary block identifier.

[0026] This allows any user with access to the full contents of each transaction in the transaction (e.g., a node of a blockchain network such as a storage node) to verify that the generating user has used the correct protocol (e.g., correct generation of the transaction set hash tree) to generate the secondary block identifier.

[0027] According to another aspect disclosed herein, there is provided a computer-implemented method for determining whether a block of a blockchain includes a target transaction, the target transaction including a candidate data field, wherein the block includes a set of transactions, the set of transactions including the target transaction, the method being performed by a querying user and comprising: obtaining: i) a candidate leaf hash value, wherein the candidate leaf hash value is a hash value of the candidate data field; ii) a candidate secondary transaction identifier of the target transaction; iii) a certification path of the candidate data field; performing a hash tree proof using i), ii) and iii) to generate a secondary transaction identifier; obtaining iv) a candidate secondary block identifier; v) a certification path of the candidate secondary block identifier; and obtaining iv) a candidate secondary block identifier using i v), v) and the generated secondary transaction identifier perform hash tree proof to generate a secondary block identifier; obtain: vi) a candidate primary transaction identifier of the target transaction; vii) a candidate primary block identifier of the block including the set of transactions; viiii) an authentication path of the primary block identifier; use vi), vii) and viii) to perform hash tree proof to generate a primary block identifier; wherein the determination is based on the following conditions: a) whether the generated secondary transaction identifier matches the candidate secondary transaction identifier; b) whether the generated secondary block identifier matches the candidate secondary block identifier; c) whether the generated primary block identifier matches the candidate primary block identifier.

[0028] Upon confirming that the candidate block identifier and the generated block identifier (for each primary and secondary version) match each other, the querying user can be confident that the block that has been mined into the blockchain includes the target transaction and that the target transaction includes the candidate data field. This is because both the primary block identifier and the secondary block identifier are constructed from the same input data (transactions), which is trusted due to the proof-of-work consensus. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0030] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0031] Figure 2Some examples of transactions that may be recorded in a blockchain are schematically shown;

[0032] Figure 3 is a schematic block diagram of another system for implementing a blockchain;

[0033] Figure 4 This is a schematic diagram of the Merkle tree;

[0034] Figure 5 shows a data block D in a tree represented by a root R using a Merkle path 1 Merkle existence proof of ;

[0035] Figure 6 This is a schematic diagram of the transaction Merkle tree;

[0036] Figure 7 is the block Merkle tree T B Schematic diagram of its root R B Included in the header of a valid block;

[0037] Figure 8 This is a schematic diagram of a block, where the transaction Merkle tree T M The root of the tree R M Included in the generation transaction;

[0038] Figure 9a and Figure 9b A complete lightweight version of the exemplary academic paper data stored in the transaction is shown separately. DETAILED DESCRIPTION

[0039] Figure 1 An exemplary system 100 for implementing a blockchain 150 is generally shown. The system 100 includes a packet-switched network 101, typically a wide area internet such as the Internet. The packet-switched network 101 includes a plurality of nodes 104, which are arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each node 104 includes a processing device including one or more processors, such as one or more central processing units (CPUs), accelerator processors, specific application processors, and / or field programmable gate arrays (FPGAs). Each node also includes a memory, i.e., a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or electrically erasable programmable read-only memory (EEPROM), and / or optical media such as an optical disk drive.

[0040] The blockchain 150 includes a series of data blocks 151, wherein a corresponding copy of the blockchain 150 is maintained at each of a plurality of nodes in the P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the value of a digital asset belonging to the user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0041] At least some of the nodes 104 play the role of forwarding nodes 104F, which forward and thereby propagate transactions 152. At least some of the nodes 104 play the role of storage nodes 104S (sometimes also referred to as "full copy" nodes), each of which stores in a respective memory a respective copy of the same blockchain 150. A given node 104 may be a forwarding node 104, a storage node 104S, or any combination of nodes therein.

[0042] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. Typically, the current transaction can be any transaction in the pool 154 or any block 151. Although the previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, the previous transaction 152i does not have to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in the logical sequence linked by the pointer, and not necessarily the creation time or sending time in the time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of isolated transactions below). The previous transaction 152i can also be called a predecessor transaction or predecessor transaction.

[0043] The input of the current transaction 152j also includes the signature of the user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to the new user 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amount among multiple users (one of which may be the original user 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0044] The above may be referred to as an "output-based" transaction protocol, sometimes also referred to as an unspent transaction output (UTXO) protocol (where outputs are referred to as UTXOs). A user's total balance is not defined by any one number stored in the blockchain; instead, the user requires a special "wallet" application 105 to collate all of the user's UTXO values, which are scattered across many different transactions 152 on the blockchain 151.

[0045] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by reference to the UTXO of the previous transaction in the past transaction sequence, but rather by reference to the absolute account balance. The current state of all accounts is stored separately to the blockchain and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as the "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, if the data field contains the ID of the previous transaction, then the data field can point to the previous transaction.

[0046] Regardless of the type of transaction protocol adopted, when a user 103 wishes to execute a new transaction 152j, he wishes to send the new transaction from his computer terminal 102 to one of the nodes 104 of the P2P network 106 (now typically a server or data center, but in principle it can be another user terminal). This node 104 checks whether the transaction is valid according to the node protocol applied at each of the nodes 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the overall transaction model. The node protocol typically requires the node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i pointed to by the input of the new transaction. In some transaction protocols, the conditions may be defined at least in part by custom scripts included in the inputs and / or outputs. Alternatively, this may be determined solely by the node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of nodes 104.

[0047] In the output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it is validly redeemed by the input of another subsequent transaction 152j according to the node agreement. Another condition for the transaction to be valid is that the output of the previous transaction 152i that it attempts to spend or redeem has not been spent / redeemed by another valid transaction. Similarly, if invalid, the transaction 152j will not be propagated or recorded in the blockchain. This prevents double spending, that is, the spender spends the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at any time.

[0048] The node 104M that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution causes the output of the hash value to satisfy the condition). The transaction pool 154 for which the winner has solved the puzzle is then recorded in the blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S, based on the announced solution of the winner having been checked at each such node. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, the block 151 cannot be modified because it is identified and maintained by each of the storage nodes 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes an order on the block 151. Since the transaction 152 is recorded in an ordered block at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0049] It should be noted that the different nodes 104M competing to solve a puzzle at any given time may be doing so based on different snapshots of the pool of unmined transactions 154 at any given time, depending on when they began their search for a solution. The person solving the corresponding puzzle first defines the transactions 152 to be included in a new block 151n and updates the current pool of unmined transactions 154. The nodes 104M then continue to compete to create blocks from the newly defined unfinished pool 154, and so on. In addition, there is a protocol for resolving any "forks" that may occur, where two nodes 104M solve a puzzle within a short time of each other, thereby propagating conflicting views of the blockchain. In short, the fork with the longest direction becomes the final blockchain 150.

[0050] Each forwarding node 104M and / or storage node 104S may also take the form of a server or data center. However, in principle, any given node 104 may take the form of a user terminal or a group of user terminals networked together.

[0051] The memory of each node 104 stores software configured to run on the processing device of the node 104 to perform its corresponding role according to the node protocol and process transactions 152. It should be understood that any action attributed to the node 104 in this article can be performed by software running on the processing device of the corresponding computer device. In addition, the term "blockchain" used in this article refers to a general term for a general type of technology and is not limited to any specific proprietary blockchain, protocol or service.

[0052] The computer device 102 of each of the multiple parties 103 playing the role of consumer users is also connected to the network 101. They act as payers and payees in transactions, but do not necessarily participate in mining or broadcasting transactions on behalf of other parties. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system, but for convenience, they are not illustrated. Each party 103 can be an individual or an organization. For illustrative purposes only, in this article, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this article can be replaced with "first party" and "second party" respectively.

[0053] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0054] The client application or software 105 may be initially provided to the computer device 102 of any given party 103 via a suitable computer-readable storage medium, for example downloaded from a server, or via a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable disk drive, floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0055] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding user party 103 to create, sign and send transactions 152 to be propagated throughout the network of nodes 104 and thus included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

[0056] An instance of the client application 105 on each computer device 102 is operably coupled to at least one of the forwarding nodes 104F of the P2P network 106. This can enable the wallet function of the client 105 to send the transaction 152 to the network 106. The client 105 can also contact one, some or all of the storage nodes 104 to query the blockchain 150 for any transactions for which the corresponding party 103 is a recipient (or indeed to check the transactions of other parties in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to the transaction protocol. Each node 104 runs software that is configured to verify that the transaction 152 is valid according to the node protocol, and forward the transaction 152 in the case of the forwarding node 104F to propagate such transactions throughout the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in the blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes to exist within it). All nodes 104 in the network 106 use the same node protocol (although they may distinguish and process different transaction subtypes according to the rules defined for the subtype, and different nodes may also play different roles to implement different corresponding aspects of the protocol).

[0057] As described above, the blockchain 150 includes a series of blocks 151, each of which includes a set of one or more transactions 152 created through the proof-of-work process as described above. Each block 151 also includes a block pointer 155, which points to the previously created block 151 in the blockchain to define the order of the blocks 151. The blockchain 150 also includes a valid transaction pool 154, which is waiting to be included in a new block through the proof-of-work process. Each transaction 152 includes a pointer to a previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can be branched). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 in the early stage of the blockchain 150 point to the genesis block 153, rather than the previous transaction.

[0058] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She will then send the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which it is connected. For example, this may be the forwarding node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives a new transaction 152j, it will process it according to the node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets certain conditions for becoming "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions may be configurable on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by a combination of the script and the node protocol.

[0059] If the newly received transaction 152j passes the validity test (i.e., under the condition of being “valid”), any storage node 104S that receives the transaction 152j will add the new valid transaction 152 to the pool 154 in the copy of the blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives the transaction 152j will then propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, the transaction 152j is assumed to be valid, which means that the transaction will soon be propagated throughout the P2P network 106.

[0060] Each transaction 152 includes pointers to earlier transactions, so the order of transactions is also recorded immutably.

[0061] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx" for short) is the basic data structure of a blockchain 150 (each block 151 includes one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments.

[0062] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not been redeemed). The UTXO specifies the amount of digital assets (a means of storing value). It may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include an indicator of the size of the input field 202 and the output field 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is a hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152.

[0063] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 Alice’s new transaction 152j is labeled “Tx 1 ”. This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least part of such amount to Bob. Figure 2 In the previous transaction 152i, it is marked as "Tx 0 "Tx 0 and Tx 1 Just an arbitrary marker, it does not necessarily mean Tx 0 Refers to the first transaction in blockchain 151 and Tx 1 Refers to the next transaction in pool 154. Tx 1 May point to any previous (ie, preceding) transaction that still has unspent output 203 locked to Alice.

[0064] When Alice creates her new transaction Tx 1 , or at least when she sends this new transaction to the network 106, the previous transaction Tx 0 may already be valid and included in blockchain 150. The transaction may have been included in one of the blocks 151 at this time, or may still be waiting in pool 154, in which case the transaction will be included in a new block 151 soon. Alternatively, Tx 0 and Tx 1 can be created and sent together to the network 102; or, if the node protocol allows buffering of "orphan" transactions, Tx 0 Even in Tx 1Sent afterwards. The terms "previous" and "subsequent" as used in the context of transaction sequences herein refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transactions, etc.). They can equally be replaced with "predecessor" and "successor", "predecessor" and "descendant" or "parent" and "child", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given node 104. However, subsequent transactions (descendant transactions or "child transactions") pointing to previous transactions (predecessor transactions or "parent transactions") will not be valid unless the parent transaction is valid. A child transaction that arrives at a node 104 before a parent transaction is considered an orphan transaction. Depending on the node protocol, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0065] Previous transaction Tx 0 One of the one or more outputs 203 includes a particular UTXO, denoted as UTXO 0 . Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that must be satisfied by the unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following conditions: The unlocking script in the input of a subsequent transaction includes a cryptographic signature of the party to whom the previous transaction was locked.

[0066] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "Script" (with a capital S). The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it may contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0067] Thus in the example shown, Tx 0 Output 203 of the UTXO 0 Includes locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , to redeem UTXO 0 (Strictly speaking, this is to make it possible for attempts to redeem UTXO 0 Subsequent transactions are valid). A ] contains Alice's public key P from her public-private key pair A .Tx 1The input 202 includes a pointer to Tx 1 A pointer to a transaction (e.g., by its transaction ID (TxID 0 ), which in the embodiment is the entire transaction Tx 0 Tx 1 The input 202 includes the Tx 0 Identify UTXO 0 The index of the 0 It is identified among any other possible outputs of Tx 1 The input 202 further includes an unlocking script <Sig P A >, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0068] When a new transaction Tx 1 Upon reaching node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing two scripts:

[0069] <Sig P A > <P A >||[Checksig P A ]

[0070] Where "||" represents concatenation, "<...>" represents putting data on the stack, and "[...]" represents a function consisting of an unlocking script (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack, rather than concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (Included in Tx 0 ) to authenticate Tx 1 The locking script in the input of Tx contains the signature of Alice when she signed the expected part of the data. The expected part of the data itself (the "message") also needs to be included in Tx 0 In order to perform this authentication. In an embodiment, the signed data includes the entire Tx 0 (Therefore there is no need to include a separate element to specify in plain text the portion of the data being signed, since that already exists).

[0071] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Basically, if Alice has signed a message by cryptographically using her private key, then given Alice's public key and the message in plaintext (unencrypted message), other entities such as node 104 can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and stamping this onto the plaintext version of the message as a signature, thereby enabling any holder of the public key to authenticate the signature.

[0072] If Tx 1 The unlocking script in satisfies Tx 0 One or more conditions specified in the locking script of tx (so, in the example shown, if 1 Alice's signature is provided and authenticated), then node 104 considers Tx 1 If it is a storage node 104S, this means it will be added to the transaction pool 154. If it is a forwarding node 104F, it will trade Tx 1 is forwarded to one or more other nodes 104 in the network 106 so that it will be propagated throughout the network. 1 Valid and included in blockchain 150, which will put Tx 0 UTXO in 0 Defined as spent. Note that Tx 1 Only valid if you spend an unspent transaction output 203. If you try to spend an output that has already been spent by another transaction 152, then even if all other conditions are met, Tx 1 Therefore, node 104 also needs to check the previous transaction Tx 0 152 has been spent (has formed a valid input to another valid transaction). This is one of the reasons why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database marking the UTXO 203 of transactions 152 that have been spent, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in blockchain 150.

[0073] Note that in a UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave" part of the amount defined as spent in a UTXO while spending another part. However, the amount of a UTXO can be split between multiple outputs of the next transaction. For example, Tx 0 UTXO 0 The amount defined in Tx 1 Therefore, if Alice does not want to split UTXO 0All the amount defined in Tx is given to Bob, and she can use the remaining amount in Tx 1 You can use the second output of the coin to make change for yourself or pay another party.

[0074] Note also that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another invalidation ground in most transaction models. Therefore, such a transaction will not be propagated or mined into block 151.

[0075] Alice and Bob's digital assets consist of unspent UTXO locked to them in any transaction 152 anywhere in the blockchain 150. Therefore, typically, the assets of a given party 103 are scattered across the UTXO of various transactions 152 throughout the blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate together the various UTXO values ​​that are locked to the respective parties and have not yet been spent in other subsequent transactions. This can be achieved by querying a copy of the blockchain 150 stored at any storage node 104S (e.g., a storage node 104S that is closest or best connected to the respective party's computer device 102).

[0076] Note that script code is usually represented schematically (i.e. not in precise language). For example, you could write [ChecksigP A ] means [Checksig P A ]=OP_DUP OP_HASH160 <pa>OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a scripting language specific opcode. OP_CHECKSIG (also known as "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in the transaction verified by the 'sig' input. As another example, OP_RETURN is a scripting language opcode for creating an unspendable output of a transaction, which can store metadata in the transaction, thereby immutably recording the metadata in the blockchain 150. For example, the metadata may include files that need to be stored in the blockchain.

[0077] Signature P A is a digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific piece of data. In embodiments, for a given transaction, the signature will sign a portion of the transaction inputs and all or a portion of the transaction outputs. The specific portion of the output that is signed depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at signing time).

[0078] The locking script is sometimes referred to as "scriptPubKey", which means that it includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", which means that it provides the corresponding signature. However, more generally speaking, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily include authenticating the signature. More generally speaking, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0079] Figure 3 A system 100 for implementing a blockchain 150 is shown. In addition to the additional functionality, the system 100 is similar to Figure 1 The content shown is substantially the same. One or more nodes 104 of the network may include software 301 for generating a secondary transaction identifier of a target transaction 152 to be recorded in a block 151 of a blockchain 150. A computer device of one or more parties (e.g., Alice and / or Bob) may include the software.

[0080] Figure 3 Also shown is a block diagram of software that may include one or more modules. The identification module 302 is configured to obtain a target transaction, for example, a target transaction may be received from a forwarding node 104F of the network, and a set of data fields of the target transaction may be identified. Each data field in the set includes data of the target transaction. For example, one or more data fields may include payment-related data. The set of data fields together constitute a complete transaction. If the transaction includes media content, one or more data fields may include part or all of the media content. The tree generation module 303 is configured to generate a hash tree using the set of data fields. The set of data fields is input to an algorithm to generate a hash tree (e.g., a Merkle tree). The hash tree includes a root hash value, which is used as a secondary transaction identifier of the target transaction in the following discussion. The recording module 304 is configured to record the secondary transaction identifier (root hash value) in the first transaction field (generated transaction) of the block 152. Then, the block is recorded in the blockchain.

[0081] Secondary transaction identifiers enable a querying user to check whether a data field (referred to herein as a candidate data field) exists within a target transaction without having to obtain or access the full transaction. For example, a client application 105 of a user (e.g., Bob) may not have sufficient capabilities to obtain a complete transaction. For example, Bob may wish to initially check whether a target transaction includes media content (e.g., a movie clip) without having to obtain a complete transaction. As another example, a node may wish to check the payment portion of a transaction without storing the rest of the transaction. As another example, a node (e.g., a storage node) may wish to prune a transaction. Here, pruning means replacing at least a portion of a transaction with a hash value of the original data. However, the node may still need to prove to the querying user that the transaction contains a candidate data field (e.g., a spendable output of a transaction) that has now been "pruned" (i.e., replaced with a hash value).

[0082] In order to check whether the target transaction contains the candidate data field, the querying user (e.g., Bob 103b) obtains the candidate data field (or its hash value), the secondary transaction identifier of the target transaction, and the authentication path (or hash path). The authentication path includes a set of hash values ​​obtained from a hash tree. The querying user traverses the hash tree using the hash value of the candidate data field and the hash value of the authentication path to obtain the candidate secondary transaction identifier. If the candidate secondary transaction identifier matches the obtained secondary transaction identifier, the transaction contains the candidate data field, and vice versa. In other words, the querying user can check whether the candidate data field constitutes part of the transaction represented by the secondary transaction identifier. It should be noted that traversing the hash tree does not require a complete transaction, only the hash value of the candidate data field and the hash partner of the subsequently generated hash value. Refer to the following Figure 5 Describe the process in more detail.

[0083] trade

[0084] At a high level, a transaction Tx is a message that may include inputs and outputs that transfers ownership of a digital asset from a first set of addresses to a second set of addresses (which may or may not include one or more addresses in the first set).

[0085] One particular blockchain protocol uses transactions with fields including one or more of the following versions: txin_count, txin, txout_count, txout, and locktime. Other protocols may use transactions that include some or none of these fields. The techniques disclosed herein are applicable to any blockchain protocol, and the fields discussed below are used only as examples.

[0086] The version field is an integer (e.g., a 4-byte integer) that indicates a set of protocol rules followed by the creator of the transaction. The txin_count field is a positive integer (e.g., between 1 byte and 9 bytes) that specifies the number of inputs in the transaction.

[0087] The txin field is an array of transaction inputs. Each input includes one or more of the following subfields: outpoint - a structure of a pair (TxID, n) indicating the UTXO being spent, including: txid_prev - the transaction identifier TxID of the UTXO being spent (e.g., a 32-byte string); vout - the output index of the UTXO being spent (e.g., a 4-byte integer) n; scriptSigLen - the integer length of the unlocking script (in bytes), up to 10,000 bytes; scriptSig - the structure of the unlocking script, which can include many individual elements; sequence - an integer indicating the current version of the transaction (e.g., a 4-byte integer).

[0088] The txout_count field is a positive integer (between 1 byte and 9 bytes) that specifies the number of outputs in the transaction. The txout field is an array of the transaction outputs. Each output can include one or more of the following subfields: value - an integer indicating the value of the output (e.g., an 8-byte integer); scriptPubKeyLen - an integer length of the locking script (in bytes), up to 10,000 bytes; scriptPubKey - the structure of the locking script, which can include many individual elements; locktime - an integer indicating the earliest time (e.g., a 4-byte integer) after which the transaction can be included in a block.

[0089] It should be understood that in this exemplary protocol, the only fields of a transaction that may contain considerable data are the script fields, namely scriptSig and scriptPubKey. Therefore, these two fields are the most important when solving the problem of lightweight proof of existence computation of large data.

[0090] An example of a transaction including one input and one output is shown below, where the public key and its RIPEMD-160 hash are referenced by the symbols P and H(P), respectively.

[0091]

[0092]

[0093] A querying user may wish to check the version of a transaction to see if the transaction (or every transaction in a block) was made using the same version or protocol. A querying user may wish to check txin_count to perform analysis of the blockchain, such as for research purposes. A querying user may wish to check only the output of a transaction to check the validity of the output (e.g., a digital asset may have been spent).

[0094] A transaction can be uniquely identified using a hash or double hash of the transaction data. For example, a transaction can be identified by its SHA-256 double hash. The transaction identifier TxID can be written, for example, as a function of a given transaction Tx

[0095] TxID:=H 2 (Tx),

[0096] Where H is a hash function (e.g., a SHA-256 cryptographic hash function). It should be noted that the collision-resistant properties of such cryptographic hash functions mean that a complete transaction message m=Tx is required to generate the correct TxID. In other words, if an alternative message Tx′ is hashed, an alternative identifier TxID′ will be generated, provided that Tx′≠Tx.

[0097] Generate Transaction

[0098] The first transaction in a block differs from the structure described above for general transactions. This is also called a "generation" transaction. Generation transactions differ from the general form only in the txin-count and txin fields. The txin_count field includes the integer "01" because a generation transaction includes a single input. The txin field itself differs from non-generation transactions in several of its subfields, as described below. Since no UTXO is spent in this case, the subfields for the output point are: txid_prev - a null value (all zeros, e.g., a 32-byte value of zeros) indicating the lack of a previous output point; vout - a value (e.g., 0xffffff) indicating the lack of a previous output point. The scriptSigLen field is the integer length of the unlocking script in bytes, up to 100 bytes. Since there is no UTXO to "unlock", the scriptSig field is constructed from two fields: the height field - the block height of the block containing the transaction (e.g., 4 bytes); generation_script - arbitrary data, up to 96 bytes. The last field is the sequence field - an integer (e.g., 4 bytes) indicating the current version of the transaction.

[0099] The generation_script field of a generation transaction can be used by the user to include arbitrary data in the transaction.

[0100] Block

[0101] A block is a data structure that includes a set of transactions and optional additional fields related to how the block was appended (mined) to the blockchain. The fields of a block for a specific blockchain protocol can be summarized as blockheader, txn_count, and txns. A block header is a structure that contains information about how a block of data was mined, when it was mined, and its contents. This includes one or more of the following six subfields: version – an integer (e.g., a 4-byte integer) indicating a set of protocol rules used for block verification; prev_block – a double hash of the previous block header (e.g., a 32-byte SHA-256); Merkle_root – a double hash derived from the Merkle tree of transactions (e.g., a 32-byte SHA-256); timestamp – an integer (e.g., a 4-byte integer) encoding the Unix time at which the block header was generated; Nbits – an integer (e.g., a 4-byte integer) encoding the target difficulty required for the block to be mined; nonce – an integer (e.g., a 4-byte integer) that selects the block header hash to achieve the desired difficulty. The txn_count field is a variable-sized integer indicating the number of transactions in the block. The txns field is a structure that includes transaction data for the complete list of transactions included in the block. The first transaction in this list is always the generation transaction, and the remaining transactions follow the general transaction structure described above.

[0102] Merkle Tree

[0103] A Merkle tree, also called a binary hash tree, is a special form of a hash tree. Each node in the tree (shown by a circle) has an index pair (i,j), denoted N(i,j). The index i,j is a numeric label associated with a specific position in the tree. A characteristic of a Merkle tree is that the construction of each of its nodes is governed by the following equation:

[0104]

[0105] Where k = (i + j - 1) / 2 and H is a cryptographic hash function.

[0106] Figure 4 A binary hash tree 400 constructed according to these equations is shown in FIG. Figure 4 It is shown that the case i=j corresponds to leaf node 401, which is just data D i The hash value of the corresponding i-th block of . The i≠j case corresponds to an internal node 402 or a root node 403, which is generated by recursively hashing and cascading child nodes in the tree until a specific node or root node is reached. In this article, the leaf nodes of the hash tree are also referred to as leaf hash values. Similarly, internal nodes and root nodes are also referred to as internal hash values ​​or root hash values.

[0107] The construction of the Merkle tree requires the use of a cryptographic hash function. In general, a hash function is considered cryptographically secure if it has the following properties:

[0108] 1) Anti-image – given h = H(m), it is computationally difficult to find m;

[0109] 2) Second preimage resistance – given h = H(m) and m, it is computationally difficult to find m′ such that H(m′) = h;

[0110] 3) Collision resistance—it is computationally difficult to find a pair of messages m and m′ such that H(m) = H(m′).

[0111] The primary transaction identifier TxID of a transaction is generated using such a hash function, and therefore the identifier inherits the properties of the hash function digest. The root of the hash tree has very similar properties to the TxID, because the uniqueness of the hash tree root can be reduced to the uniqueness of the underlying cryptographic hash function. This is beneficial because the root can be used as an identifier for the data, which is as unique as an identifier generated by hashing the data if the same hash function is used in both cases.

[0112] In most applications, the main function of a hash tree is to facilitate the proof of certain data blocks D i 404 is N data blocks Given a hash tree root and a candidate data block D i In the case of , it can be considered as a "proof of existence" of the block in the set. This type of proof mechanism is called a hash tree proof (or a Merkle proof of a Merkle tree), and consists of obtaining a set of hash values, called a given data block D i and the hash value or certification path (or Merkle path) of the root R. The certification path of a data block is the minimum list of hashes required to reconstruct the root R by repeated hashing and cascading. If the validator knows all blocks D 1 ,…,D N , a proof of existence can be performed. However, this does require a much larger storage overhead than the certification path itself, and requires the entire dataset to be available to the verifier.

[0113] The hash tree not only proves that the data field D i The existence of this data set also proves that it is In addition, when the transaction is on the blockchain, the hash tree proves that the data field D i It is part of the transaction recorded on the blockchain.

[0114] Figure 5 shows a data block D in a tree represented by a root R using a Merkle path 1 Merkle existence proof. Given the Merkle root R, we can prove that the data block D 1 belongs to the set denoted by R

[0115] 1) Get the Merkle root R from a trusted source.

[0116] 2) Get a Merkle path Γ from the source. In this case, Γ is the set of hash values:

[0117] Γ={N(2,2),N(3,4),N(5,8)}.

[0118] 3) Use D 1 The Merkle proof for Γ calculation is as follows:

[0119] a. Hash (or double-hash, depending on the implementation) the data block to obtain: N(1,1) = H(D 1 ).

[0120] b. Concatenate with N(2,2) and hash to obtain: N(1,2) = H(N(1,1)||N(2,2)).

[0121] c. Concatenate with N(3,4) and hash to obtain: N(1,4) = H(N(1,2)||N(3,4)).

[0122] d. Concatenate with N(5,8) and hash to get the root: N(1,8) = H(N(1,4)||N(5,8)),

[0123] R′=N(1,8).

[0124] e. Compare the calculated root R′ with the root R obtained in (1):

[0125] I. If R′=R, then confirm that D exists in the tree 1 , thereby confirming the data set

[0126] II. If R′≠R, the proof fails and D cannot be confirmed 1 yes Members of.

[0127] This means that for a given block D 1 The Merkle tree can be efficiently traversed "upwards" using only the minimum necessary hashes by performing a Merkle proof with the root R. This is an efficient mechanism for providing a proof of existence for some data that is part of the dataset represented by the Merkle tree and its root. For example, if data D 1 corresponds to a blockchain transaction, and the root R is publicly available as part of the block header, then it can be quickly proven that the transaction was included in the block.

[0128] In the following, the tuple (D, R, Γ) is used to indicate that a data group D is a set represented by the root R A hash tree proof of part of .

[0129] Transaction tree generation algorithm

[0130] As described above, the present disclosure provides a method for generating a secondary transaction identifier for a transaction, which is used to determine whether the transaction includes specific data called a "candidate data field". Since in most blockchain protocols, each transaction is associated with a primary transaction identifier that is usually generated by hashing (or double hashing) the complete transaction, it is called a secondary transaction identifier.

[0131] The method includes: splitting the transaction fields one by one into a set of data groups (or data fields) that can be used as leaves of a hash tree (e.g., a Merkle tree), where the root of the hash tree corresponds to the secondary transaction identifier. In this article, splitting is equivalent to identifying the data fields of the transaction. In other words, the transaction does not actually have to be "split". Instead, different parts of the transaction can be identified (e.g., assigned) as different data fields in the set of data fields. The secondary transaction identifier will be unique to a given transaction (e.g., a unique 256-bit digital representation (hash value) of a given transaction). The hash value can be used to verify whether any individual field is a valid leaf of the hash tree without having to obtain the entire group (i.e., the complete transaction).

[0132] Given a transaction Tx, one way to verify that it has been mined into the blockchain is to verify that its corresponding TxID (primary transaction identifier) ​​appears in the block. This check can be done by performing a hash tree proof (e.g., a Merkle proof) to verify that the transaction corresponding to TxID is part of the set of transactions represented by the hash root in the block header. However, this check requires the verifier to first obtain the complete transaction message m=Tx and confirm that TxID=H(Tx) actually holds for a given Tx and a hypothetical TxID, where H is a hash function. This may be problematic for some users of the blockchain, especially when the user implements a lightweight client and / or the message m is large.

[0133] In the example, a secondary transaction identifier MTxID can be generated that conforms to the following definition: MTxID:=F(Tx, TxID). Algorithm F is used as a one-way function to generate a secondary transaction identifier from two input messages Tx and TxID. Assume that TxID can be written as a function of the transaction message Tx

[0134] TxID: =H 2 (Tx), which means that MTxID can be written as a function of a single message m=Tx in the following way: MTxID(Tx,H 2 (Tx)):=F(Tx). Algorithm F includes a hash tree generator. The algorithm takes as input the complete transaction Tx and returns a hash digest MTxID, which can be used as a secondary identifier for the transaction. The secondary identifier can be a 256-bit hash digest. It should be understood that in this scheme, the secondary identifier MTxID does not replace the primary identifier TxID. To strengthen this, the design of algorithm F includes, for example, using a typical double hash function H 2 (Tx) Generate TxID, which binds a secondary identifier to a primary identifier.

[0135] The method for generating the secondary transaction identifier MTxID can be divided into three main stages, as described below.

[0136] Input: Tx

[0137] F(Tx):

[0138] 1) Calculate TxID: = H 2 (Tx).

[0139] 2) Group Tx into a group Ordered data grouping

[0140] 3) Use this group Generate a binary hash tree T with the groups as leaves and calculate its root R.

[0141] Output: MTxID = R

[0142] In this example, the hash tree is a binary hash tree (i.e., a Merkle tree). However, in general, any n-ary hash tree can be used, where n refers to the number of branches of the tree. For example, in a binary hash tree, two child nodes are hashed to form a parent node; in a ternary hash tree, three child nodes are hashed to form a parent node, and so on.

[0143] Phase 1: Calculate TxID

[0144] The generating user may receive a transaction from one or more different parties (or nodes) of the blockchain network. For example, the transaction may be transmitted directly to the generating user by one node of the network or via one or more different nodes. The generating user may be a blockchain network node that intends to record the transaction in a block of the blockchain.

[0145] The method may include generating a primary transaction identifier by hashing the transaction. The first stage is a SHA-256 double hash calculation performed on Tx, generating a primary transaction identifier TxID. Other hash functions may be used, and in some examples only a single hash calculation is performed. Typically, the Tx message itself does not explicitly include the TxID. Therefore, subsequent stages require this explicit pre-computation of the TxID so that the hash tree can be constructed in a way that explicitly encodes this primary identifier.

[0146] Phase 2: Divide Tx into ordered data sets

[0147] The transaction data including the message Tx is divided into discrete groups that can be used as leaves of the hash tree T. The transaction can be split into its existing fields. Most of these fields contain simple numeric data, which are usually very small in size - usually between 1 byte and 32 bytes. Therefore, the focus of the increased overall transaction size will be related to the sigScript and scriptPubKey fields, which are related to inputs (unlocks) and outputs (locks), respectively. Three categories can be used to distinguish transaction fields: input fields, output fields, and other fields. In some examples, the transaction is split into these three categories, for example, one data field includes all input fields, one data field includes all output fields, and one data field includes other fields. The input fields and output fields can be divided into non-script fields and script fields, the non-script fields include numeric data, and the script fields include script data.

[0148] The following table shows how a transaction can be broken down into a set of data fields.

[0149]

[0150] This table shows that a Tx message can be split into its component fields in several ways to form a set of packets.

[0151] In some examples, a transaction can be split into: at least one data field including input data of the transaction (e.g., txid_prev); at least one data field including output data of the transaction (e.g., value); at least one data field including non-input data and non-output data (i.e., other data, such as version) of the transaction. Each data field can consist of only one type of data, such as only input data.

[0152] In other examples, the transaction can be split into more data fields. For example, the set of data fields may include: at least one data field including script input data of the transaction (e.g., scriptSig); at least one data field including non-script input data of the transaction (e.g., vout); at least one data field including script output data of the transaction (e.g., scriptPubkey); at least one data field including non-script output data of the transaction (e.g., scriptPubKeyLen).

[0153] The transaction Tx can be split into the following ordered data groups:

[0154] D 1 = <version>、

[0155] D 2 =<txin_count>、

[0156] D 3 =<txout_count>、

[0157] D 4 = <locktime>、

[0158] D 5 =<txid_prev>|| <vout> || <scriptsiglen> || <sequence> 、

[0159] D 6 ＝ <scriptsig> 、

[0160] D 7 ＝ <value> || <scriptpubkeylen> 、

[0161] D 8 ＝ <scriptpubkey>.

[0162] If each group D i The choice to split the data in this way has several benefits. First, all non-script inputs are concatenated to form group D 5 , and similarly, concatenate all non-script outputs to form D 7 This means that each input and output of a transaction is split into exactly two parts – a non-script component and a script component. In a binary hash tree this is particularly advantageous as it means that each input and output can be paired as sibling leaves. Inputs and outputs can therefore be completely separated from other fields, and the script component and non-script component of each input or output can also be separated. This means that given a very large script, the non-script component can still be verified by executing a hash tree proof without having to process the larger script itself.

[0163] In addition to these fields, the TxID may also be included as a leaf in the hash tree T. According to the above example, this means including the data field D 9 = <txid>In general, there can be many inputs and many outputs in a transaction, and each input and output can be split into two components by algorithm F. Therefore, the data blocks in the tree T The total number will be given by the following equation

[0164]

[0165] where n in and n out are the number of transaction inputs and outputs, respectively. In some examples, all other data fields can be concatenated to form a single data field. This can reduce the total number of leaves to N = 2 + 2 (n in +n out ).

[0166] In the absence of So that N = 2 k In this case, you can add empty padding data 2 k -N>0 data packets to ensure that the binary hash tree has enough leaves. The padding can be empty data or 2 of the TxID k -N copies in order to strengthen the link between the primary transaction identifier and the final secondary identifier MTxID.

[0167] A given transaction may include multiple inputs and / or multiple outputs. Each input may include script data and non-script data. Similarly, each output may include script data and non-script data. Transactions may be split such that one data field includes all script data from each input, and one data field includes all non-script data from each input. Output data may be similarly partitioned. Alternatively, one or more data fields combined may include all script data from each input, and one or more data fields combined may include all non-script data from each input. Likewise, output data may be similarly partitioned.

[0168] In some cases, it may be necessary to extract partial data from a given field and use it as an additional leaf of the hash tree T. An example of data that can be extracted from the scriptSig field is the signature<Sig(P,m)> , and an example of data that can be extracted from the scriptPubKey field is the public key hash<H(P)> In the example, one or both of these may be extracted to form separate data fields. Extracting these data elements from the script and including them as additional data groupings in the hash tree allows for lightweight verification of the participants in the transaction and their signatures without having to process additional data.

[0169] As another example, an identifier for the transaction type may be included as a leaf in the hash tree. This is not a field or data element included in the transaction message in a TxID-like sense, but may be identified by a standard interpretation of the message based on a standard transaction type (e.g., pay to public key hash (P2PKH), pay to script hash (P2SH), or non-standard). Including a data element representing the transaction type would allow lightweight users to identify important information about the transaction without having to retrieve or analyze it locally.

[0170] In some cases, blockchain network nodes will generate secondary transaction identifiers, such as when mining transactions into the blockchain. It may be desirable to split transactions in the simplest way for blockchain network nodes to implement. A good candidate would be to use a fixed number of leaves per tree (e.g., N = 2). k ), and split the transaction message N into data packets to generate a hash tree so that m = m 1 ||m 2 ||…||m N , where the common group size scales linearly with the total transaction size.

[0171] Alternatively, a common grouping size S for the data leaves of the hash tree can be fixed. Transactions can then be split into a desired number of groups N. This option can be used to ensure that low-bandwidth lightweight verification utilities are not compromised by choosing an appropriately small S.

[0172] The method includes: splitting the transaction into a set of ordered data fields, each data field including corresponding data of the transaction. The transaction message Tx can be divided into a set of ordered data leaves As mentioned above, this can be done in a number of ways.

[0173] Phase 3: Use Generate a hash tree T and calculate the root R

[0174] The method includes: using the set of data fields as leaves of a transaction hash tree. The transaction hash tree includes a leaf layer, one or more internal layers, and a root layer. The leaf layer includes a plurality of leaf nodes (also referred to as leaf hash values, because each node is a hash summary). Each leaf node is generated by hashing a corresponding data field of a transaction. At least one leaf hash value is based on a primary transaction identifier. In some examples, one or more leaf hash values ​​are generated by hashing a primary transaction identifier. In some examples, one or more data fields of the transaction are concatenated with the primary transaction identifier and then hashed to generate a corresponding leaf hash value. Each internal layer includes a plurality of internal nodes (or internal hash values). Each internal hash value in a given internal layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer. For example, the first or lowest internal layer (i.e., an internal layer directly connected to a leaf layer) includes an internal node generated by hashing a concatenation of at least two leaf hash values. For a binary hash tree, two nodes from a given layer are concatenated and then hashed to generate a node of the next layer. For an n-ary hash tree, n nodes from a given layer are concatenated and then hashed to generate a node of the next layer. The root layer includes the root of the transaction tree, i.e., the secondary transaction identifier. The secondary transaction identifier is generated by hashing the concatenation of the inner hash values ​​of the highest layer in one or more inner layers (i.e., the inner layer directly connected to the root layer).

[0175] The secondary transaction identifier (the root of the transaction hash tree) may be included in the block's generation transaction. The block may then be recorded in the blockchain. Alternatively, as described below, the secondary transaction identifier may be included in a transaction transmitted to a blockchain network node via one or more nodes of the network.

[0176] Algorithm F uses an ordered set of data groups And construct a hash tree T by using these groups as leaves. Figure 6 An exemplary structure of a binary hash tree is shown. In this example, the first four data fields D 1 ,…,D 4 It is the other fields of the transaction, followed by the data field 2×(n in +n out ) is represented as script D 5 ,D 6 Field Data and Non-Script D 7 ,D 8 The remaining data fields include at least one field D 9 ,D 10 , which contains the TxID and N=2 up to some integer k k Any filling required D N .

[0177] Given these N data fields as leaves, the hash tree generation algorithm creates a Merkle tree T. The Merkle tree can be built using the same algorithm used to generate primary transaction identifiers. This means that T is built in the same way as its root R B (Primary Transaction Identifier) ​​Transaction tree T found in the block header B The transaction tree T is described in detail below. B It should be noted that between the hash tree T and the existing T B In , the data fields can be double-hashed to generate the leaves of the tree. This is useful for lightweight proofs of existence. Alternatively, the data fields can be single-hashed to generate the leaves of the tree. The difference is that the leaves of T are groups of fields that comprise a single transaction. And T B The leaves of are the individual transactions included in a given block. Preferably, the order of the leaves in the hash tree is exactly the same as the order of the groupings specified in phase 3.

[0178] Instead of storing the entire hash tree, a node (e.g., software running at a node) can parse a transaction message Tx into an ordered set of leaves and simply store them along with the root R. Alternatively, the entire hash tree can be stored. By keeping only the ordered leaves and root, the storage overhead increases by only 32 bytes for R compared to storing Tx, and the tree can be built from this information at any time. This small storage overhead can also be reduced if the node chooses to store data in groups, as it usually does, and simply builds the tree and its root from the groups when needed.

[0179] If the secondary transaction identifier is generated by a blockchain network node, the blockchain network node may include it in the generation transaction of the block. If the secondary transaction identifier is generated by a user other than the blockchain network node (e.g., Alice), the user may include it in a transaction that is propagated through the network to be mined into the block by the blockchain network node. As another example, the secondary transaction identifier may be generated by a user who is not connected to the blockchain network but has access rights to the target transaction. The user may transmit the secondary transaction identifier to one or more parties (which may or may not be connected to the blockchain network) via, for example, the Internet. The secondary transaction identifier (the root of the transaction hash tree) may be recorded (i.e., written to commit) in the generation transaction of a block (the same block or a different block containing the target transaction). The block may then be recorded in the blockchain. The secondary transaction identifier may be submitted to a transaction other than the generation transaction. For example, a user may obtain a secondary transaction identifier, include it in a transaction (e.g., a script of a transaction), and transmit the transaction to one or more nodes of the network to be mined into the blockchain. The user who generates the secondary transaction identifier may additionally or alternatively store the identifier in a local memory.

[0180] Candidate data field validation

[0181] As described above, the secondary transaction identifier allows a querying user to check whether a transaction includes a candidate data field. The querying user requires the candidate data field (or its hash value), the secondary transaction identifier, and the hash tree path (or authentication path) in order to perform such a check. The generating user may transmit one or more of these required elements to the querying user. Alternatively, the querying user may obtain one or more elements from another user or from the blockchain itself (e.g., the secondary transaction identifier may be obtained from the generating transaction).

[0182] In some examples, the generating user may wish to prove to the querying user that the transaction includes the candidate data field without revealing the entire transaction (or the querying user may only wish to check whether the transaction includes the candidate data field). In this case, the generating user may transmit the candidate data field to the querying user.

[0183] A hash tree path includes an ordered set of hash values. The set of hash values ​​includes at least a leaf hash value. The set may also include one or more internal hash values. The number of internal hash values ​​depends on the number of data fields into which the transaction is split and the type of hash tree (e.g., whether the hash tree is a binary hash tree, a ternary hash tree, etc.).

[0184] The querying user uses the candidate data field (or its hash value) and the hash path to determine (by performing a hash tree proof) whether the root of the hash tree generated using those elements matches the transaction's secondary transaction identifier. If the root matches the secondary transaction identifier, the querying user can be confident that the transaction includes the candidate data field due to the uniqueness of the underlying hash function.

[0185] The hash tree proof includes concatenating the hash value of the candidate data field with at least one leaf hash value in the set of ordered hash values ​​(hash tree path). This produces an internal hash value (or internal node of the hash tree). The generated internal hash value is then concatenated with one or more hash values ​​in the hash tree path (or a single hash value if the hash tree is a binary hash tree). The concatenated internal hash values ​​are then hashed to generate the next hash value. Depending on the size of the hash tree (e.g., the number of data fields), the next hash value may be another internal hash value or a root hash value. If the next hash value is another internal hash value, one or more internal hash values ​​from the hash tree path are concatenated and the result is hashed until the root hash value is generated. It should be noted that each hash value in the hash tree path is used only once.

[0186] The root hash value is equivalent to a candidate secondary transaction identifier. If the candidate secondary transaction identifier matches the obtained secondary transaction identifier, then the candidate data field will form part of the transaction. An indication (e.g., TRUE or FALSE) may be output (e.g., to a user via a user device) to indicate whether the candidate data field forms part of the transaction. The output may be a visual or audio alert.

[0187] In some examples, a transaction includes content data (e.g., media data). One or more data fields may include content data. The content data may be, for example, image data (e.g., a picture), sound data (e.g., a song), video data (e.g., a movie), or document data (e.g., a text document or pdf). A candidate data field may be a data field that includes data. Thus, this may allow a party to verify whether a transaction includes the content.

[0188] In some examples, the user providing the secondary transaction identifier and the generation of the candidate data fields may be a trusted node of the network.

[0189] It should be noted that "user" herein is not limited to an end user or consumer. For example, in an embodiment, a querying user may be a consumer 103 such as Alice 103a. A user's query is also not limited to manually initiated queries. In an embodiment, a query may be performed by an automated process run by a user. For example, the process may be an automated process run by a node 104 that only wishes to check the payment portion of each transaction they are verifying or mining.

[0190] Transaction Tree Verification Algorithm

[0191] One party (i.e., the verifying user) can execute a verification algorithm V that is complementary to the transaction tree generation algorithm F F . This verification algorithm will allow the validator Alice to check whether the other party Bob has correctly used the generation algorithm to generate the candidate MTxID. Verification Algorithm V F (MTxID, Tx) takes two inputs, Bob's candidate identifier MTxID and transaction Tx, which should be identified by MTxID. The algorithm can output TRUE or FALSE (or some other indication) to indicate whether the candidate identifier MTxID has been correctly generated. The output can be output to the user via the user device (e.g., as a visual or audio alert).

[0192] The verification algorithm can be written as follows:

[0193] Input: MTxID, Tx

[0194] V F (MTxID,Tx):

[0195] 1) Calculate TxID: = H 2 (Tx).

[0196] 2) Use the same process as Algorithm F to group Tx into a group Ordered data grouping The calculated TxID is at least one of the packets.

[0197] 3) Use this group Generate a binary Merkle tree T with the groups of as leaves and calculate the Merkle root R.

[0198] 4) Check if R and MTxID are equal:

[0199] 4.1 If R = MTxID, return "TRUE".

[0200] 4.2 If R≠MTxID, return "FALSE".

[0201] Output: "TRUE" or "FALSE"

[0202] This algorithm is applicable when the protocol specifies that a binary hash tree should be used to generate secondary transaction identifiers. However, in general, as described above, any n-ary hash tree may be used.

[0203] The querying party (Alice) can obtain the candidate secondary transaction identifier MTxID from the generating user (Bob) or from another node of the network. Alternatively, the validator can obtain the candidate MTxID by extracting the candidate from the block of the blockchain (recall that the secondary transaction identifier can be recorded in the generating transaction of the block).

[0204] This verification algorithm allows any network peer to independently verify that the MTxID confirmed by another peer has been correctly and honestly calculated according to the generation algorithm F. F When performing verification, the verifier knows the generation algorithm F and the complete transaction data Tx corresponding to the candidate MTxID. For example, the generation algorithm and / or the transaction can be distributed among the nodes of the network.

[0205] Trust MTxID

[0206] One purpose of generating a secondary transaction identifier MTxID:=R is to allow the lightweight client Alice to verify that a transaction field or data element of interest exists on the blockchain without having to retrieve and interpret the full transaction.

[0207] However, the client does not necessarily trust the publicly known MTxID. For example, if Alice receives the value of MTxID from an untrusted party, Bob, Alice cannot determine whether Bob has used the correct generation function F. The reason is that it is not possible to prove that a certain data packet D i It is a set of ordered transactions corresponding to the transaction Tx on the blockchain. Membership involves two conditions:

[0208] 1) Proof in Used to calculate the root hash value R=MTxID (as described above).

[0209] 2) Prove that MTxID corresponds to the mined transaction Tx, identified by TxID.

[0210] Performing a hash proof (e.g., a Merkle proof) on the transaction's hash tree T is sufficient only to satisfy the first of these two conditions. The solution to this trust problem of MTxIDs is called a "layer 2 protocol" that provides a direct on-chain link between the two identifiers TxID and MTxID for a given transaction.

[0211] Generating users can build additional hash trees T M (Tree of hash trees), and its root hash value R M Included as a data element in the script that generates the transaction. M This can be done in parallel with the aggregation of transactions as part of the mining process for each new block. M Only a relatively small 32-byte value needs to be stored in the generated transaction.

[0212] The protocol may include the following stages:

[0213] 1) Generate a user to receive a set of Transactions are mined into the next block.

[0214] 2) According to the existing blockchain protocol, The candidate blocks are sorted.

[0215] 3) Generate two hash trees:

[0216] 3.1) Generate a block hash tree T with each transaction as a leaf in the order determined by (2) B This step is done using the standard method of generating a block hash tree. This phase involves generating a corresponding primary transaction identifier for each transaction by hashing the transaction.

[0217] 3.2) Generate the transaction hash tree T using the MTxID of each transaction as a leaf in the order determined by (2) M The order of MTxIDs is the same as the order of the corresponding Txs in (3.1), and each is created using the function MTxID i =F(Tx i )generate.

[0218] 4) Record each root in the candidate block:

[0219] 4.1) Tree T B Root R B Recorded in the Merkle_root field of the candidate block header.

[0220] 4.2) Tree T M Root R M Recorded in the field of the candidate block generation transaction.

[0221] R M Recorded in one or more fields of the candidate block generation transaction, for example, recorded in an output script of the transaction.

[0222] As with the verification algorithm above, the verifying user can use the same set of transactions to generate a tree of transaction hash trees and verify the tree T M The generating root R M Is it equal to generate user generated root.

[0223] Figure 7 An exemplary block hash tree T is shown B 700. As shown, each transaction 701 is hashed to construct T B The corresponding leaf 702 of B Included in the block header of a valid block.

[0224] Figure 8 An exemplary composition of a block is shown, where the transaction hash tree T M The root of the tree R M Included in the script field of the generated transaction. In addition, the block hash tree T is also shown B , whose root R B Stored in the block header.

[0225] The protocol allows the establishment of links between the TxIDs of transactions included in a block and their corresponding MTxIDs, which are verified by the nodes of the blockchain network. This is because it is always the same blockchain network node that creates the list of transactions in a block (using R B ) and its corresponding list of MtxIDs (in R T denoted by ), all of which are stored on the blockchain. In any block, the Proof of Work (PoW) consensus algorithm ensures that R B The value of and the corresponding tree T B Credible. B The trust in R M The value of is also trusted because it is consistent with the information protected by PoW.

[0226] This is because both trees are based on the same input data and a set of transactions. The set of transactions is constructed as information protected by the PoW consensus algorithm. Therefore, any network node (including lightweight clients) can verify the required one-to-one correspondence between TxID and MtxID.

[0227] As described above, a generating user may implement a "layer 2 protocol" in which a secondary block identifier is generated. A layer 2 protocol is a protocol implemented "on top" of a base blockchain protocol. The base protocol is not affected by (or does not even need to be "aware of") such layer 2 protocols. Layer 2 protocols are simply additional and extended parts of a built blockchain protocol.

[0228] The secondary block identifier is the root of the transaction set hash tree (or tree of transaction hash trees). Each leaf of the transaction set hash tree can be a secondary transaction processing identifier for a different transaction within the block (depending on the number of transactions within the block, one or more hash values ​​can be used as padding). The same generating user can generate a secondary transaction identifier and a secondary block identifier. Alternatively, a first generating user can generate a secondary transaction identifier, while a different second generating user can generate a secondary block identifier. For example, a first generating user can include a secondary transaction identifier in a first transaction and transmit it over the network. Similarly, a second generating user can perform the same operation on a different second transaction. A third generating user can obtain the secondary transaction identifiers of the first transaction and the second transaction, as well as the secondary transaction identifiers of one or more different transactions, and then generate a secondary block identifier.

[0229] If any user (verifying user) has access to the transactions used by the generating user to generate the secondary transaction identifier and / or the secondary block identifier, these users can verify that these identifiers were generated correctly, i.e. according to the protocol of the blockchain. The verifying user can obtain the transaction from, for example, the source of the transaction or a full or partial copy of the blockchain. The process repeated by the verifying user is the same as the process that the generating user should have completed if the protocol was followed correctly. If the secondary transaction identifier matches the one produced by the generating user, the verifying user can prove that it has been generated correctly. The same applies to the secondary block identifier.

[0230] The secondary transaction identifier and the secondary block identifier may be submitted to the same transaction or different transactions to be mined into the blockchain. If the secondary transaction identifier is generated by a blockchain network node, the blockchain network node may include it in the generation transaction of the block. If the secondary transaction identifier is generated by a user other than the blockchain network node (e.g., Alice), the user may include it in the transaction propagated through the network to be mined into the block by the blockchain network node. As another example, the secondary transaction identifier may be generated by a user who is not connected to the blockchain network but has access rights to the target transaction. The user may transmit the secondary transaction identifier to one or more parties (which may or may not be connected to the blockchain network) via, for example, the Internet. The secondary transaction identifier (the root of the transaction hash tree) may be recorded in (i.e., written to or submitted to) the generation transaction of the block (the same block or a different block containing the target transaction). The block may then be recorded in the blockchain. The secondary transaction identifier may be submitted to a transaction other than the generation transaction. For example, a user may obtain a secondary transaction identifier, include it in a transaction (e.g., a script of a transaction), and transmit the transaction to one or more nodes of the network to be mined into the blockchain. A user generating a secondary transaction identifier may additionally or alternatively store the identifier in local memory.

[0231] The same submitting user may submit a secondary transaction identifier and a secondary block identifier for inclusion in a block (the same block or a different block) of the blockchain. Alternatively, a first submitting user may submit a secondary transaction identifier to a transaction, while a different second submitting user may submit a secondary block identifier to a transaction (e.g., to generate a transaction).

[0232] Proof of Existence

[0233] Any individual field of a transaction can be checked to see if it exists on the blockchain without the full transaction using the following set of existence proofs:

[0234] 1) Get (D i ,R,Γ), where R = MTxID. That is, verify the candidate data field D i is part of a transaction that has R as its secondary identifier.

[0235] 2) Get (MTxID, R M ,Γ). That is, verify that the candidate secondary transaction identifier MTxID is a hash certificate with R M The hash tree T as its root M part of a tree.

[0236] 3) Get (TxID, R B ,Γ). That is, verify that the candidate transaction identifier TxID is a hash with R B The block hash tree T as its root B part of.

[0237] 4) Test R M and R B Are they in the same block? This can be determined by checking the blocks on the blockchain.

[0238] Optionally, the existence proof may include verifying that the TxID and MTxID are located at the T B and T M The same leaf node position.

[0239] These tests are sufficient to prove that D i is part of the transaction Tx. Furthermore, these tests only require relatively small (32-bit) hash values, which is feasible for lightweight clients. This means that any thin client can perform such lightweight proofs of existence without having to obtain the full transaction data. It should be noted that the same proofs of existence detailed above can be performed on a single (e.g., SHA-256) hash value of the data block itself. This would be H(D i ) instead of D i In many cases, such a proof on a hash of data will be preferable as it allows efficient proof of the existence of the data without providing or revealing the data itself.

[0240] The querying user may wish to know whether the candidate data field is part of a transaction included in a block of the blockchain. The querying user requires at least a hash value of the candidate data field (which may be provided to the user, or the querying user may be provided with the candidate data field which the user then hashes). In addition, the authentication path (or hash tree path) of the secondary transaction identifier is also required.

[0241] In order to implement the Layer 2 proof of existence, the querying user also needs the candidate secondary block identifier and the certification path of the candidate secondary block identifier. In addition, the following are required: the candidate primary transaction identifier of the target transaction; the candidate primary block identifier of the block that includes a set of transactions; and the certification path of the primary block identifier.

[0242] Each or part of the above requirements may be provided to the querying user by the generating user or another node of the blockchain network. Alternatively, it may be obtained from the blockchain itself (e.g., from a complete or partial copy of the blockchain). As another example, a party separate from the blockchain (e.g., a service provider) may access and provide one or more requirements.

[0243] Calculation of absence period

[0244] Blockchain network nodes participating in the protocol will only be able to use R M The encoded form provides the network with valuable MTxID information about the blocks they mine. In some cases, not every blockchain network node will participate in the protocol. Blockchain network nodes M that participate in the protocol can include another (32-byte) hash value R in the script field of the transaction they generate M Inter The value R M Inter is the third hash tree T M Inter The additional tree is constructed in the same way as T M Same as M, but in the interim between blocks successfully mined by M, the MTxID will be used for each transaction in the order it was mined. Although this requires an additional 32 bytes to be stored by the blockchain network nodes in their generated transactions, it does mean that they can provide a trusted MTxID and therefore a lightweight proof of existence without the involvement of other blockchain network nodes. This is also because all the necessary information for verification is stored on-chain.

[0245] Example use cases

[0246] Reference below Figure 9a and Figure 9b Provides examples of generating candidate data fields that users wish to verify whether a transaction includes. Transactions can be used to store content data that is not related to the transfer of digital assets. For example, some transactions may include data in the OP_RETURNscriptPubkey field that may not be related to the digital asset recipient address. Because the content data is separated from data that is explicitly related to the transfer of digital assets, in many cases, users may only want to verify the existence of a transaction fragment within the blockchain without downloading the complete transaction data.

[0247] Assume Alice is an SPV node that keeps a record of block header information and the generation script data of the generation transactions from the blockchain network nodes participating in the protocol. Assume Bob is such a blockchain network node, he also has a complete copy of the blockchain. Consider a transaction Tx1 on the blockchain, which contains a digital version of an academic paper. The document data is contained in two separate OP_RETURN outputs scriptPubKey fields, where the title and abstract are contained in the first OP_RETURN (output 1), and the rest of the article is contained in the second OP_RETURN (output 2), as shown in Figure 9a shown.

[0248] Alice knows the TxID of Tx1, but does not have the complete transaction data. Alice wants access to Tx1 and requests access from Bob, however Bob wants to be paid in return for providing Alice with the complete transaction data. On the other hand, Alice does not want to pay Bob until she is certain that the transaction data she will receive will contain the file. Bob can provide this certainty by sending Alice a preview along with a lightweight proof of existence. Bob first sends Alice the transaction data of Tx1 (minus most of the article), and then replaces the data after the second OP_RETURN (output 2) with the SHA256 hash of the data (see Figure 9b ).

[0249] On the one hand, Alice wants to verify that the header and digest (fragment of the transaction) she received have not been altered, but Bob does not want to provide the full transaction. Bob needs to prove that the data Alice received is stored on the blockchain without Alice downloading the transaction or any other data (block headers and generation data) that the SPV wallet can provide.

[0250] The lightweight proof of existence can be used to verify that the lightweight version of Tx1 sent by Bob is unchanged (i.e. from the blockchain). In addition to the lightweight Tx1, Bob also provides a hash proof, i.e. Bob provides a sequence hash value according to the method outlined above, enabling Alice to verify the tree root R stored in the generation transaction of the block in which Tx1 is stored. M To verify the received data (see Figure 9a ). Since Alice has R M , so she can perform a hash proof to verify the integrity of the data sent by Bob.

[0251] Alice is convinced that Bob has sent her a fragment of the complete academic paper, and she may want to see the full transaction, in which case she can request the full transaction data. Upon receiving the missing data (i.e. the full transaction), Alice can perform a final check by checking that the data in the second OP_RETURN (output 2) hashes to the same string as the given OP_RETURN (output 2) data in the lightweight transaction. Alternatively, Alice can hash the full transaction and check it against the TxID she had at the beginning.

[0252] As another example, a party may wish to prune data from a transaction, for example, to comply with personal data requirements or to save storage space. However, the party may still need to prove to other parties that the transaction contains candidate data fields (e.g., spendable outputs of the transaction). The transaction's secondary transaction identifier allows any party to verify that a pruned transaction contains candidate data fields. The pruned data (e.g., personal information) can be replaced with a hash of the pruned data. Pruning may be required due to the increase in the amount of data that can be stored in an OP_RETURN data or script field. Therefore, if a node wishes to verify that a pruned transaction includes a candidate data field, the hash of the pruned data can be provided to the party to be used as a leaf node in the hash tree.

[0253] It should be understood that the above embodiments are described by way of example only.

[0254] According to a first embodiment of the teachings disclosed herein, there is provided a computer-implemented method for generating a secondary transaction identifier for a target transaction, the secondary transaction identifier enabling a querying user to determine whether the target transaction includes a candidate data field; the method is performed by a generating user and includes: identifying a set of data fields for the target transaction, each data field including corresponding data for the transaction; generating a transaction hash tree, wherein the transaction hash tree includes: i) a leaf layer, the leaf layer including a plurality of leaf hash values, wherein each data field is hashed to generate a corresponding one of the plurality of leaf hash values; ii) one or more inner layers, each of the one or more inner layers including a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer in the one or more inner layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer including the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a cascade of the inner hash value of a highest inner layer in the one or more inner layers.

[0255] In some examples, the method may include receiving the transaction from one or more nodes of the blockchain network. For example, one or more end users. The transaction may be a transaction based on a UTXO model. Alternatively, the transaction may be a transaction based on an account model.

[0256] In some examples, each set of internal hash values ​​consists of a single hash value (e.g., the hash tree is a binary hash tree). Alternatively, each set of internal hash values ​​may include two or more hash values ​​(e.g., if the hash tree is a ternary hash tree, it includes two hash values).

[0257] According to a second optional embodiment, a method according to the first embodiment may be provided, wherein the method may include submitting the secondary transaction identifier to the blockchain.

[0258] The generating user may be a node of the zone header chain network. The querying user may be a terminal user or a node of a different type of the network.

[0259] According to a third optional embodiment, a method according to the first embodiment or the second embodiment may be provided, wherein the method may include one, some or all of the following: submitting the secondary transaction identifier to a transaction to be included in a block of the blockchain; submitting the secondary transaction identifier to a generated transaction to be included in a block of the blockchain; transmitting the secondary transaction identifier to a node of a blockchain network; storing the secondary transaction identifier in a memory of a generating user's computing device.

[0260] Logically, the generation transaction may be the first transaction in the block.

[0261] According to a fourth embodiment of the teachings disclosed herein, there is provided a method for enabling a querying user to determine whether a target transaction within a block of a blockchain includes a candidate data field; the method is performed by a submitting user and comprises: obtaining a secondary transaction identifier for the target transaction; submitting the secondary transaction identifier to a transaction for inclusion within a block of the blockchain, wherein the secondary transaction identifier has been generated by: identifying a set of data fields for the target transaction, each data field including corresponding data for the transaction; generating a transaction hash tree, wherein the transaction hash tree comprises: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values ​​sorted according to a set of ordered data fields, wherein the leaf hash values ​​are the leaf hash values ​​of the leaf hash values; hashing each data field in the transaction to generate a corresponding one of the multiple leaf hash values; ii) one or more internal layers, each of the one or more internal layers comprising multiple internal hash values, wherein each internal hash value in each internal layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each internal hash value of the lowest internal layer is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a cascade of the internal hash value of the highest internal layer in the one or more internal layers.

[0262] According to a fifth optional embodiment, a method according to the fourth embodiment may be provided, wherein the acquisition may include at least one of the following: generating the secondary transaction identifier; receiving the secondary transaction identifier from a node of the blockchain network; receiving the secondary transaction identifier from a node outside the blockchain network.

[0263] According to a sixth optional embodiment, a method according to the fourth or fifth embodiment may be provided, wherein the submitting may include submitting the secondary transaction identifier to a generation transaction within a block of the blockchain.

[0264] According to a seventh optional embodiment, a method according to any one of the first to sixth embodiments may be provided, wherein the transaction hash tree may be a binary hash tree, wherein each internal hash value in the lowest internal layer is generated by hashing the concatenation of two different leaf hash values, each internal hash value in each internal layer is generated by hashing the concatenation of two hash values ​​from a lower layer, and wherein the highest internal layer includes two internal hash values.

[0265] In case the hash tree is a binary hash tree, each set of internal hash values ​​consists of a single internal hash value.

[0266] According to an eighth optional embodiment, a method according to any one of the first to seventh embodiments may be provided, wherein the method may include transmitting an authentication path of the candidate data field to the querying user, wherein the authentication path includes a set of ordered hash values, and wherein the set of ordered hash values ​​includes at least one leaf hash value and one or more groups of internal hash values, each group of internal hash values ​​belonging to a corresponding layer in the internal layers of the transaction hash tree.

[0267] According to a ninth optional embodiment, a method according to any one of the first to eighth embodiments may be provided, wherein the method may include transmitting the candidate data field or its hash value instead of at least one other data field of the target transaction to the querying party.

[0268] For example, the same node may transmit the candidate data field and the secondary transaction identifier simultaneously.The node may be a trusted node.

[0269] In some examples, only the candidate fields of the target transaction and not any other data fields are transmitted to the querying party.

[0270] According to a tenth optional embodiment, a method according to any one of the first to ninth embodiments may be provided, wherein the set of data fields may include: i) at least one data field including input data of the target transaction; ii) at least one data field including output data of the target transaction; iii) at least one data field including non-input data and non-output data of the target transaction.

[0271] In some examples, each data field may include only one type of data, such as input data, output data, or other data (ie, non-input data and non-output data).

[0272] According to an eleventh optional embodiment, a method according to any one of the first to tenth embodiments may be provided, wherein the set of data fields may include: i) at least one data field including script input data of the target transaction; ii) at least one data field including non-script input data of the target transaction; iii) at least one data field including script output data of the target transaction; iv) at least one data field including non-script output data of the target transaction.

[0273] According to a twelfth optional embodiment, a method according to any one of the first to eleventh embodiments may be provided, wherein one or both of the following two items: the target transaction may include data corresponding to multiple inputs, and wherein for each of the inputs, the set of data fields includes: at least one data field including script data of the input; at least one data field including non-script data of the input; and / or the target transaction may include data corresponding to multiple outputs, and wherein for each of the outputs, the set of data fields includes: at least one data field including script data of the output; at least one data field including non-script data of the output.

[0274] According to a thirteenth optional embodiment, a method according to any one of the first to twelfth embodiments may be provided, wherein the set of data fields may include: i) at least one data field including one or more signatures; ii) at least one data field including script input data of the target transaction other than signatures; iii) at least one data field including one or more public key hash values; iv) at least one data field including script output data of the target transaction other than public key hash values.

[0275] According to a fourteenth optional embodiment, a method according to any one of the first to thirteenth embodiments may be provided, wherein at least one data field in the set of data fields may include a primary transaction identifier of the target transaction, and / or at least one data field in the data fields is attached with the primary transaction identifier of the target transaction.

[0276] In some examples, each data field may be appended with the primary transaction identifier. Alternatively, each data field that does not include the primary transaction identifier may be appended with the primary transaction identifier.

[0277] According to a fifteenth optional embodiment, a method according to any one of the first to fourteenth embodiments may be provided, wherein the primary transaction identifier may be generated by hashing the target transaction.

[0278] The primary transaction identifier may be generated by double hashing the target transaction.

[0279] According to a sixteenth optional embodiment, a method according to any one of the first to fifteenth embodiments may be provided, wherein the identifying may include identifying a set of fixed number of data fields.

[0280] According to a seventeenth optional embodiment, a method according to any one of the first to fifteenth embodiments may be provided, wherein the identification may include identifying a set of data fields, each data field including a fixed amount of data.

[0281] According to an eighteenth optional embodiment, a method according to any one of the first to seventeenth embodiments may be provided, wherein the target transaction may include content data, and wherein the candidate data field includes at least a portion of the content data.

[0282] According to a nineteenth optional embodiment, a method according to any one of the first to eighteenth embodiments may be provided, wherein the content data includes one, some or all of the following: image data; sound data; video data; text data.

[0283] According to a twentieth embodiment of the teaching disclosed herein, a computer device is provided, the computer device comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, and the code is configured to execute the method described in any one of the first to third embodiments and / or any one of the eighth to nineteenth embodiments when on the processing device.

[0284] According to a twenty-first embodiment of the teachings disclosed herein, there is provided a computer program contained in a computer-readable memory and configured to, when run on a computer device, execute a method according to any one of the first to third embodiments and / or any one of the eighth to nineteenth embodiments.

[0285] According to a twenty-second embodiment of the teaching disclosed herein, there is provided a computer device, comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to execute a method according to any one of the fourth to nineteenth embodiments when on the processing device.

[0286] According to a twenty-third embodiment of the teachings disclosed herein, there is provided a computer program embodied on a computer readable memory and configured to, when run on a computer device, perform a method according to any one of the fourth to nineteenth embodiments.

[0287] According to a twenty-fourth embodiment of the teachings disclosed herein, there is provided a computer-implemented method for verifying whether a candidate secondary transaction identifier of a target transaction within a block of a blockchain has been generated according to a specified protocol, the method being performed by a verifying user and comprising: obtaining the candidate secondary transaction identifier; identifying a set of data fields of the target transaction, each data field comprising corresponding data of the transaction; generating a transaction hash tree, wherein the transaction hash tree comprises: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each data field is hashed to generate a corresponding leaf hash value; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of the lowest inner layer is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a cascade of the inner hash values ​​of the highest inner layer; verifying whether the secondary transaction identifier matches the candidate secondary transaction identifier.

[0288] According to a twenty-fifth optional embodiment, a method according to the twenty-fourth embodiment may be provided, wherein the acquisition includes one or more of the following items: receiving the candidate secondary transaction identifier from a node of the blockchain network; receiving the candidate secondary transaction identifier from a node outside the blockchain network; extracting the candidate secondary transaction identifier from a transaction within a block of the blockchain.

[0289] According to a twenty-sixth embodiment of the teachings disclosed herein, there is provided a computer device, comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to, when on the processing device, execute a method according to any one of the twenty-fourth and twenty-fifth embodiments.

[0290] According to a twenty-seventh embodiment of the teachings disclosed herein, there is provided a computer program embodied on a computer readable memory and configured to, when run on a computer device, perform a method according to any one of the twenty-fourth and twenty-fifth embodiments.

[0291] According to the twenty-eighth embodiment of the teachings disclosed herein, there is provided a computer-implemented method for determining whether a target transaction within a block of a blockchain includes a candidate data field, the method being performed by a querying user and comprising: obtaining a candidate leaf hash value, wherein the candidate leaf hash value is a hash value of the candidate data field; obtaining a candidate secondary transaction identifier for the target transaction, wherein the secondary transaction identifier is generated by identifying a set of data fields of the target transaction, each data field including corresponding data of the transaction, and generating a transaction hash tree, wherein a root layer of the transaction hash tree includes the secondary transaction identifier; obtaining a certification path for the candidate data field, wherein the certification path includes a set of ordered hash values, and wherein the set of ordered hash values ​​includes at least one leaf hash value and one or more sets of internal hash values, each set of internal hash values ​​belonging to a corresponding internal layer of the transaction hash tree; performing a hash tree certification using the obtained candidate leaf hash value, the obtained candidate secondary transaction identifier, and the obtained certification path for the candidate data field, the execution generating the secondary transaction identifier; wherein the determination is based on whether the secondary transaction identifier matches the candidate secondary transaction identifier.

[0292] In some examples, the obtaining of the hash value of the candidate data field may include obtaining the candidate data field and hashing the candidate data field. Alternatively, the obtaining may include, for example, receiving the hash value of the candidate data field from a recorder or another node.

[0293] According to a twenty-ninth optional embodiment, a method according to the twenty-eighth embodiment may be provided, wherein the execution of the hash tree proof includes: hashing the concatenation of the candidate leaf hash value and the at least one leaf hash value in the set of ordered hash values; and then, repeating the following process: hashing the concatenation of the previous hash processing result and the next set of internal hash values ​​in the one or more sets of internal hash values ​​in the authentication path until the last internal hash value in the one or more sets of internal hash values ​​is hashed after being concatenated with the previous hash processing, wherein the secondary transaction identifier is the result of the final hash processing.

[0294] According to a thirtieth optional embodiment, a method according to the twenty-eighth or twenty-ninth embodiment may be provided, wherein obtaining the candidate leaf hash value comprises: receiving the candidate leaf hash value; or receiving the candidate data field and hashing the candidate data field to generate the candidate leaf hash value.

[0295] According to a thirty-first optional embodiment, a method according to any one of the twenty-eighth to thirtieth embodiments may be provided, wherein obtaining the candidate secondary transaction identifier includes at least one of the following items: receiving the secondary transaction identifier from a node of the blockchain network; receiving the secondary transaction identifier from a node outside the blockchain network; extracting the secondary transaction identifier from a transaction within a block of the blockchain.

[0296] According to a thirty-second embodiment of the teaching disclosed herein, a computer device is provided, the computer device comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, and the code is configured to execute a method according to any one of the twenty-eighth to thirty-first embodiments when on the processing device.

[0297] According to a thirty-third embodiment of the teachings disclosed herein, there is provided a computer program embodied on a computer readable memory and configured to, when run on a computer device, perform a method according to any one of the twenty-eighth to thirty-first embodiments.

[0298] According to a thirty-fourth embodiment of the teachings disclosed herein, there is provided a computer-implemented method for generating a secondary block identifier for a block of a blockchain, wherein the block includes a set of transactions, and the secondary block identifier enables a querying user to determine whether the set of transactions includes a candidate data field; the method is performed by a generating user and includes: for each transaction in the set of transactions, obtaining a corresponding secondary transaction identifier; generating a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, the leaf layer including a plurality of leaf hash values, wherein each leaf hash value corresponds to a corresponding one of the secondary transaction identifiers; ii) one or more inner layers, each of the one or more inner layers including a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer in the one or more inner layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer including the secondary block identifier, wherein the secondary block identifier is generated by hashing a cascade of the inner hash value of the highest inner layer in the one or more inner layers.

[0299] The primary block identifier may also be referred to as a primary block Merkle root. The secondary block identifier may also be referred to as a secondary block Merkle root.

[0300] According to a thirty-fifth optional embodiment, a method according to the thirty-fourth embodiment may be provided, wherein the method may include one, some or all of the following: submitting the secondary block identifier to a transaction to be included in a block of the blockchain; submitting the secondary block identifier to a generated transaction to be included in a block of the blockchain; transmitting the secondary block identifier to a node of a blockchain network; storing the secondary transaction identifier in a memory of a generating user's computing device.

[0301] In some examples, the block hash tree and / or the transaction set hash tree is a binary hash tree.

[0302] According to a thirty-sixth optional embodiment, a method according to the thirty-fourth or thirty-fifth embodiment may be provided, wherein obtaining the corresponding secondary transaction identifiers includes one or more of the following items: generating one, some or all of the corresponding secondary transaction identifiers; receiving one, some or all of the corresponding secondary transaction identifiers from a node of the blockchain network; receiving one, some or all of the corresponding secondary transaction identifiers from a node outside the blockchain network; extracting one, some or all of the corresponding secondary transaction identifiers from at least one transaction within a block of the blockchain.

[0303] According to a thirty-seventh embodiment of the teachings disclosed herein, there is provided a computer device, comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to execute a method according to any one of the thirty-fourth to thirty-sixth embodiments when on the processing device.

[0304] According to a thirty-eighth embodiment of the teachings disclosed herein, there is provided a computer program, the computer program being embodied on a computer-readable memory and being configured to, when run on a computer device, perform a method according to any one of the thirty-fourth to thirty-sixth embodiments.

[0305] According to a thirty-ninth embodiment of the teachings disclosed herein, there is provided a method for enabling a querying user to determine whether a set of transactions within a block of a blockchain includes a candidate data field; the method is performed by a submitting user and includes: obtaining a secondary block identifier of the block including the set of transactions; submitting the secondary block identifier to a transaction to be included in a block of the blockchain, wherein the secondary block identifier has been generated by the following steps: for each transaction in the set of transactions, obtaining a corresponding secondary transaction identifier; generating a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, the leaf layer including a plurality of leaf hash values, wherein each leaf hash value corresponding to a corresponding one of the secondary transaction identifiers; ii) one or more internal layers, each of the one or more internal layers comprising a plurality of internal hash values, wherein each internal hash value in each internal layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each internal hash value of the lowest internal layer of the one or more internal layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary block identifier, wherein the secondary block identifier is generated by hashing a cascade of the internal hash values ​​of the highest internal layer of the one or more internal layers.

[0306] According to a fortieth optional embodiment, a method according to the thirty-ninth embodiment may be provided, wherein the submission may include submitting the secondary transaction identifier to a generation transaction within a block of the blockchain.

[0307] According to a forty-first optional embodiment, a method according to the thirty-ninth or fortieth embodiment may be provided, wherein the method may include: obtaining a primary block identifier of the block including the set of transactions; submitting the secondary transaction identifier to the generation transaction of the block of the blockchain; wherein the primary block identifier is generated by the following steps: for each transaction in the set of transactions, generating a corresponding primary transaction identifier by hashing the transaction; generating a block hash tree, the block hash tree comprising: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each leaf hash value corresponds to one of the primary transaction identifiers; ii) one or more internal layers, each of the one or more internal layers comprising a plurality of internal hash values, wherein each internal hash value in each internal layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each internal hash value of the lowest internal layer in the one or more internal layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, the root layer comprising the block identifier, wherein the block identifier is generated by hashing a cascade of the internal hash value of the highest internal layer in the one or more internal layers.

[0308] According to a forty-second embodiment of the teaching disclosed herein, a computer device is provided, the computer device comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to execute a method according to any one of the thirty-ninth to forty-first embodiments when on the processing device.

[0309] According to a forty-third embodiment of the teaching disclosed herein, there is provided a computer program, the computer program being embodied on a computer-readable memory and being configured to, when run on a computer device, perform a method according to any one of the thirty-ninth to forty-first embodiments.

[0310] According to a forty-fourth embodiment of the teachings disclosed herein, there is provided a computer-implemented method for verifying whether a candidate secondary block identifier of a block of a blockchain has been generated according to a specified protocol, wherein the block includes a set of transactions, wherein the method is performed by a verifying user and includes: obtaining the candidate secondary block identifier; for each transaction in the set of transactions, obtaining a corresponding secondary transaction identifier; generating a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, wherein the leaf layer includes a plurality of leaf hash values, wherein each leaf hash value corresponds to a corresponding one of the secondary transaction identifiers; ii) one or more inner layers, wherein each inner layer of the one or more inner layers includes a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a cascade of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a cascade of at least two different leaf hash values; iii) a root layer, wherein the root layer includes the secondary block identifier, wherein the secondary block identifier is generated by hashing a cascade of the inner hash value of the highest inner layer of the one or more inner layers; verifying whether the secondary block identifier matches the candidate secondary block identifier.

[0311] According to the forty-fifth optional embodiment, a method according to the forty-fourth embodiment may be provided, wherein the acquisition includes one or more of the following items: receiving the candidate secondary block identifier from a node of the blockchain network; receiving the candidate secondary block identifier from a node outside the blockchain network; extracting the candidate secondary block identifier from a transaction of a block of the blockchain.

[0312] According to a forty-sixth embodiment of the teachings disclosed herein, there is provided a computer device, the computer device comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to execute a method according to any one of the forty-fourth to forty-fifth embodiments when on the processing device.

[0313] According to a forty-seventh embodiment of the teachings disclosed herein, there is provided a computer program, which is contained on a computer-readable memory and is configured to, when run on a computer device, perform a method according to any one of the forty-fourth to forty-fifth embodiments.

[0314] According to a forty-eighth embodiment of the teachings disclosed herein, there is provided a computer-implemented method for determining whether a block of a blockchain includes a target transaction, the target transaction including a candidate data field, wherein the block includes a set of transactions, the set of transactions including the target transaction, the method being performed by a querying user and comprising: obtaining: i) a candidate leaf hash value, wherein the candidate leaf hash value is a hash value of the candidate data field; ii) a candidate secondary transaction identifier of the target transaction; iii) a certification path of the candidate data field; performing a hash tree proof using i), ii) and iii) to generate a secondary transaction identifier; obtaining iv) a candidate secondary block identifier; v) a certification path of the candidate secondary block identifier; Perform hash tree proof using iv), v) and the generated secondary transaction identifier to generate a secondary block identifier; obtain: vi) a candidate primary transaction identifier of the target transaction; vii) a candidate primary block identifier of the block including the set of transactions; viii) a certification path of the primary block identifier; perform hash tree proof using vi), vii) and viii) to generate a primary block identifier; wherein the determination is based on the following conditions: a) whether the generated secondary transaction identifier matches the candidate secondary transaction identifier; b) whether the generated secondary block identifier matches the candidate secondary block identifier; c) whether the generated primary block identifier matches the candidate primary block identifier.

[0315] According to a forty-ninth optional embodiment, a method according to the forty-eighth embodiment may be provided, wherein the determination is also based on the following condition: whether the block including the set of transactions includes the candidate primary block identifier and the candidate secondary block identifier.

[0316] According to a fiftieth embodiment of the teachings disclosed herein, a computer device is provided, the computer device comprising: a memory, the memory comprising one or more memory units; a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to execute a method according to any one of the forty-eighth to forty-ninth embodiments when on the processing device.

[0317] According to a fifty-first embodiment of the teaching disclosed herein, there is provided a computer program, which is contained on a computer-readable memory and is configured to, when run on a computer device, execute a method according to any one of the forty-eighth to forty-ninth embodiments.

[0318] According to another embodiment disclosed herein, a method may be provided that includes the actions of generating a user, querying the user, any third parties that may be involved, and a network of nodes.

[0319] According to another embodiment disclosed herein, a system may be provided, comprising: a computer device for use by a generating user; a computer device for use by a submitting user; a computer device for use by a verifying user; a computer device for use by a querying user, a computer device for use by any third party, and a node network.

[0320] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.< / txid> < / scriptpubkey> < / scriptpubkeylen> < / value> < / scriptsig> < / sequence> < / scriptsiglen> < / vout> < / locktime> < / version> < / pa>

Claims

1. A computer-implemented method for generating a secondary transaction identifier for a target blockchain transaction, the secondary transaction identifier enabling a querying user to determine whether the target blockchain transaction includes a candidate data field ； The method is performed by a generating user and includes: A set of data fields identifying the target blockchain transaction, each data field comprising corresponding data of the blockchain transaction; Generate a transaction hash tree, the transaction hash tree comprising: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each data field is hashed to generate a corresponding one of the plurality of leaf hash values; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a concatenation of at least two different leaf hash values; iii) a root layer, said root layer comprising said secondary transaction identifier, wherein said secondary transaction identifier is generated by hashing a concatenation of said inner hash values ​​of a highest inner layer of said one or more inner layers.

2. The method according to claim 1, comprising one, some or all of the following: submitting the secondary transaction identifier to a blockchain transaction for inclusion in a block of the blockchain; submitting the secondary transaction identifier to a generation transaction for inclusion in a block of the blockchain; transmitting the secondary transaction identifier to a node of a blockchain network; The secondary transaction identifier is stored in a memory of a generating user's computing device.

3. The method of claim 1 or 2, comprising submitting the secondary transaction identifier to the blockchain.

4. A computer-implemented method for enabling a querying user to determine whether a target blockchain transaction within a block of a blockchain includes a candidate data field ； The method is performed by a submitting user and includes: Obtaining a secondary transaction identifier of the target blockchain transaction; submitting the secondary transaction identifier to a blockchain transaction for inclusion in a block of the blockchain, Wherein the secondary transaction identifier has been generated by the following steps: A set of data fields identifying the target blockchain transaction, each data field comprising corresponding data of the blockchain transaction; Generate a transaction hash tree, the transaction hash tree comprising: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values ​​ordered according to a set of ordered data fields, wherein each data field is hashed to generate a corresponding one of the plurality of leaf hash values; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a concatenation of at least two different leaf hash values; iii) a root layer, said root layer comprising said secondary transaction identifier, wherein said secondary transaction identifier is generated by hashing a concatenation of said inner hash values ​​of a highest inner layer of said one or more inner layers.

5. The method according to claim 4, wherein the obtaining comprises at least one of the following: generating the secondary transaction identifier; receiving the secondary transaction identifier from a node of the blockchain network; The secondary transaction identifier is received from a node external to the blockchain network.

6. The method according to claim 4 or 5, wherein the submitting include: Submitting the secondary transaction identifier to a generation transaction within a block of the blockchain.

7. A method according to claim 1 or 4, wherein the transaction hash tree is a binary hash tree, wherein each inner hash value in the lowest inner layer is generated by hashing a cascade of two different leaf hash values, each inner hash value in each inner layer is generated by hashing a cascade of two hash values ​​from a lower layer, and wherein the highest inner layer includes two inner hash values.

8. The method according to claim 1 or 4 includes transmitting the authentication path of the candidate data field to the querying user, wherein the authentication path includes a set of ordered hash values, and wherein the set of ordered hash values ​​includes at least one leaf hash value and one or more sets of internal hash values, each set of internal hash values ​​belonging to a corresponding layer in the internal layers of the transaction hash tree.

9. The method of claim 1 or 4, comprising transmitting the candidate data field or a hash value thereof to the querying user instead of at least one other data field of the target blockchain transaction.

10. The method according to claim 1 or 4, wherein the set of data fields include: i) at least one data field comprising input data of the target blockchain transaction; ii) at least one data field comprising output data of the target blockchain transaction; iii) at least one data field comprising non-input data and non-output data of the target blockchain transaction.

11. The method according to claim 1 or 4, wherein the set of data fields include: i) at least one data field comprising script input data of the target blockchain transaction; ii) at least one data field comprising non-script input data of the target blockchain transaction; iii) at least one data field comprising script output data of the target blockchain transaction; iv) at least one data field comprising non-script output data of the target blockchain transaction.

12. The method according to claim 1 or 4, wherein one or both of the following: The target blockchain transaction includes data corresponding to a plurality of inputs, and wherein for each of the inputs, the set of data fields include: at least one data field comprising said input script data; at least one data field comprising said input non-script data; and / or The target blockchain transaction includes data corresponding to a plurality of outputs, and wherein, for each of the outputs, the set of data fields includes: at least one data field including script data for the output; At least one data field comprising non-script data for said output.

13. The method according to claim 1 or 4, wherein the set of data fields include: i) at least one data field including one or more signatures; ii) at least one data field comprising script input data of the target blockchain transaction other than a signature; iii) at least one data field comprising one or more public key hash values; iv) at least one data field comprising script output data of the target blockchain transaction other than a public key hash.

14. The method according to claim 1 or 4, in, A primary transaction identifier is generated by hashing the target blockchain transaction.

15. The method of claim 14, wherein at least one of the set of data fields comprises the primary transaction identifier of the target blockchain transaction, and / or at least one of the data fields is appended with the primary transaction identifier of the target blockchain transaction.

16. The method according to claim 1 or 4, wherein the set of data fields identifying the target blockchain transaction include: Identifies a fixed number of data fields.

17. The method according to claim 1 or 4, wherein the set of data fields identifying the target blockchain transaction include: Identifies a set of data fields, each of which includes a fixed amount of data.

18. The method of claim 1 or 4, wherein the target blockchain transaction includes content data, and wherein the candidate data field includes at least a portion of the content data.

19. The method of claim 18, wherein the content data comprises one, some or all of the following: - image data; - sound data; - video data; -Text data.

20. A computer device for generating a user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be run on the processing device, the code being configured to execute the method according to any one of claims 1 to 3 and 7 to 19 when on the processing device.

21. A computer-readable storage medium having computer-readable code encoded thereon, which is configured to execute the method according to any one of claims 1 to 3, 7 to 19 when executed on a computer device generating a user.

22. A computer device for use by a submitting user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to execute the method according to any one of claims 4 to 19 when on the processing device.

23. A computer-readable storage medium having computer-readable code encoded thereon, configured to, when executed on a submitting user's computer device, perform the method of any one of claims 4 to 19.

24. A computer-implemented method for verifying whether a candidate secondary transaction identifier for a target blockchain transaction within a block of a blockchain has been generated according to a specified protocol, the method being performed by a verifying user, and include: Obtaining the candidate secondary transaction identifier; A set of data fields identifying the target blockchain transaction, each data field comprising corresponding data of the blockchain transaction; Generate a transaction hash tree, the transaction hash tree comprising: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each data field is hashed to generate a corresponding leaf hash value; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer, each inner hash value of a lowest inner layer is generated by hashing a concatenation of at least two different leaf hash values; iii) a root layer, said root layer comprising said secondary transaction identifier, wherein said secondary transaction identifier is generated by hashing a concatenation of said inner hash values ​​of a highest inner layer; Verifying whether the secondary transaction identifier matches the candidate secondary transaction identifier.

25. The method of claim 24, wherein the obtaining comprises one or more of: receiving the candidate secondary transaction identifier from a node of the blockchain network; Receiving the candidate secondary transaction identifier from a node external to the blockchain network; The candidate secondary transaction identifier is extracted from a blockchain transaction within a block of the blockchain.

26. A computer device for use in authenticating a user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to execute the method according to claim 24 or 25 when on the processing device.

27. A computer-readable storage medium having computer-readable code encoded thereon, which is configured to perform the method of claim 24 or 25 when executed on a computer device of an authenticating user.

28. A computer-implemented method for determining whether a target blockchain transaction within a block of a blockchain includes a candidate data field, the method being performed by a querying user, and include: Obtaining a candidate leaf hash value, wherein the candidate leaf hash value is a hash value of the candidate data field; Obtaining a candidate secondary transaction identifier for the target blockchain transaction, wherein the secondary transaction identifier is generated by identifying a set of data fields for the target blockchain transaction, each data field comprising corresponding data of the blockchain transaction, and generating a transaction hash tree, wherein a root layer of the transaction hash tree comprises the secondary transaction identifier; obtaining a certification path for the candidate data field, wherein the certification path comprises a set of ordered hash values, and wherein the set of ordered hash values ​​comprises at least one leaf hash value and one or more sets of internal hash values, each set of internal hash values ​​belonging to a corresponding internal layer of the transaction hash tree; performing a hash tree attestation using the obtained candidate leaf hash value, the obtained candidate secondary transaction identifier, and the obtained authentication path of the candidate data field, the performing generating a secondary transaction identifier; Wherein the determination is based on whether the secondary transaction identifier matches the candidate secondary transaction identifier.

29. The method according to claim 28, wherein said performing said hash tree proof include: hashing a concatenation of the candidate leaf hash value and the at least one leaf hash value in the set of ordered hash values; Then, repeating the process of hashing a concatenation of a previous hash processing result and a next set of internal hash values ​​in the one or more sets of internal hash values ​​in the authentication path until a last internal hash value in the one or more sets of internal hash values ​​is hashed after being concatenated with the previous hash processing, wherein the secondary transaction identifier is a final hash processing result.

30. The method according to claim 28 or 29, wherein the step of obtaining the candidate leaf hash value is: include: Receiving the candidate leaf hash value; or The candidate data field is received, and hash processing is performed on the candidate data field to generate the candidate leaf hash value.

31. The method of claim 28, wherein obtaining the candidate secondary transaction identifier comprises at least one of the following: receiving the secondary transaction identifier from a node of the blockchain network; Receiving the secondary transaction identifier from a node external to the blockchain network; The secondary transaction identifier is extracted from a blockchain transaction within a block of the blockchain.

32. A computer device for use by a querying user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be run on the processing device, the code being configured to execute the method according to any one of claims 28 to 31 when on the processing device.

33. A computer-readable storage medium having computer-readable code encoded thereon, which is configured to perform the method of any one of claims 28 to 31 when executed on a computer device of a querying user.

34. A computer-implemented method for generating a secondary block identifier for a block of a blockchain, wherein the block includes a set of blockchain transactions, the secondary block identifier enabling a querying user to determine whether the set of blockchain transactions includes a candidate data field ； The method is performed by a generating user and includes: For each blockchain transaction in the set of blockchain transactions, obtaining a corresponding secondary transaction identifier, wherein the secondary transaction identifier is generated according to the method of claim 1; Generate a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each leaf hash value corresponds to a respective one of the secondary transaction identifiers; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a concatenation of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary chunk identifier, wherein the secondary chunk identifier is generated by hashing a concatenation of the internal hash values ​​of a highest internal layer among the one or more internal layers.

35. The method of claim 34, comprising one, some or all of the following: submitting the secondary block identifier to a blockchain transaction for inclusion in a block of the blockchain; submitting the secondary block identifier to a generation transaction for inclusion in a block of the blockchain; Transmitting the secondary block identifier to a node of a blockchain network; The secondary transaction identifier is stored in a memory of a generating user's computing device.

36. The method of claim 34 or 35, wherein obtaining the corresponding secondary transaction identifier comprises one or more of the following: generating one, some or all of said corresponding secondary transaction identifiers; receiving one, some or all of the respective secondary transaction identifiers from a node of the blockchain network; receiving one, some or all of the respective secondary transaction identifiers from a node external to the blockchain network; One, some or all of the corresponding secondary transaction identifiers are extracted from at least one blockchain transaction within a block of the blockchain.

37. A computer device for generating a user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be run on the processing device, the code being configured to execute the method according to any one of claims 34 to 36 when on the processing device.

38. A computer-readable storage medium having computer-readable code encoded thereon, configured to, when executed on a computer device generating a user, perform the method of any one of claims 34 to 36.

39. A computer-implemented method for enabling a querying user to determine whether a set of blockchain transactions within a block of a blockchain includes a candidate data field ； The method is performed by a submitting user and includes: obtaining a secondary block identifier of the block including the set of blockchain transactions; submitting the secondary block identifier to a blockchain transaction for inclusion in a block of the blockchain, The secondary block identifier is generated by: For each blockchain transaction in the set of blockchain transactions, obtaining a corresponding secondary transaction identifier, wherein the secondary transaction identifier is generated according to the method of claim 1; Generate a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each leaf hash value corresponds to a respective one of the secondary transaction identifiers; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a concatenation of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary chunk identifier, wherein the secondary chunk identifier is generated by hashing a concatenation of the internal hash values ​​of a highest internal layer among the one or more internal layers.

40. The method of claim 39, wherein said submitting include: Submitting the secondary transaction identifier to a generation transaction within a block of the blockchain.

41. The method according to claim 39 or 40, wherein include: obtaining a primary block identifier of the block including the set of blockchain transactions; submitting the secondary transaction identifier to the generation transaction of the block of the blockchain; The primary block identifier is generated by the following steps: For each blockchain transaction in the set of blockchain transactions, generating a corresponding primary transaction identifier by hashing the blockchain transaction; Generate a block hash tree, the block hash tree comprising: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each leaf hash value corresponds to one of the primary transaction identifiers; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a concatenation of at least two different leaf hash values; iii) a root layer, said root layer comprising said chunk identifier, wherein said chunk identifier is generated by hashing a concatenation of said inner hash values ​​of a highest inner layer among said one or more inner layers.

42. A computer device for use by a submitting user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be run on the processing device, the code being configured to execute the method according to any one of claims 39 to 41 when on the processing device.

43. A computer readable storage medium having computer readable code encoded thereon, configured to, when executed on a submitting user's computer device, perform the method of any one of claims 39 to 41.

44. A computer-implemented method for verifying whether a candidate secondary block identifier of a block of a blockchain has been generated according to a specified protocol, wherein the block includes a set of blockchain transactions, wherein the method is performed by a validating user, and include: Obtaining the candidate secondary block identifier; For each blockchain transaction in the set of blockchain transactions, obtain a corresponding secondary transaction identifier, wherein the secondary transaction identifier is Generated according to the method of claim 1; Generate a transaction set hash tree, wherein the transaction set hash tree includes: i) a leaf layer, the leaf layer comprising a plurality of leaf hash values, wherein each leaf hash value corresponds to a respective one of the secondary transaction identifiers; ii) one or more inner layers, each of the one or more inner layers comprising a plurality of inner hash values, wherein each inner hash value in each inner layer is generated by hashing a concatenation of at least two hash values ​​from a lower layer, and each inner hash value of a lowest inner layer of the one or more inner layers is generated by hashing a concatenation of at least two different leaf hash values; iii) a root layer, the root layer comprising the secondary chunk identifier, wherein the secondary chunk identifier is generated by hashing a concatenation of the inner hash values ​​of a highest inner layer of the one or more inner layers; Verifying whether the secondary chunk identifier matches the candidate secondary chunk identifier.

45. The method of claim 44, wherein the acquiring comprises one or more of: Receiving the candidate secondary block identifier from a node of the blockchain network; Receiving the candidate secondary block identifier from a node external to the blockchain network; The candidate secondary block identifier is extracted from a blockchain transaction of a block of the blockchain.

46. ​​A computer device for use in authenticating a user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to execute the method according to claim 44 or 45 when on the processing device.

47. A computer readable storage medium having computer readable code encoded thereon, which is configured to perform the method of claim 44 or 45 when executed on a computer device of an authenticating user.

48. A computer-implemented method for determining whether a block of a blockchain includes a target blockchain transaction, the target blockchain transaction including a candidate data field, wherein the block includes a set of blockchain transactions, the set of blockchain transactions including the target blockchain transaction, the method being performed by a querying user, and include: Obtain: i) a candidate leaf hash value, wherein the candidate leaf hash value is a hash value of the candidate data field; ii) a candidate secondary transaction identifier of the target blockchain transaction; iii) an authentication path of the candidate data field; A hash tree proof is performed using i) and iii) to generate a secondary transaction identifier, where the secondary transaction identifier is Generated according to the method of claim 1; Obtaining iv) a candidate secondary block identifier; v) an authentication path of the candidate secondary block identifier; Performing a hash tree proof using v) and the generated secondary transaction identifier to generate a secondary block identifier; Obtaining: vi) a candidate primary transaction identifier of the target blockchain transaction; vii) a candidate primary block identifier of the block including the set of blockchain transactions; viii) an authentication path of the primary block identifier; wherein the primary transaction identifier is generated by hashing the target blockchain transaction; Using vi), and viii), performing a hash tree proof to generate a primary block identifier; wherein the primary block identifier is generated by the following steps: for each blockchain transaction in the set of blockchain transactions, generating a corresponding primary transaction identifier by hashing the blockchain transaction; The determination is based on the following conditions: a) whether the generated secondary transaction identifier matches the candidate secondary transaction identifier; b) whether the generated secondary block identifier matches the candidate secondary block identifier; c) whether the generated primary block identifier matches the candidate primary block identifier.

49. The method of claim 48, wherein the determination is further based on whether the block including the set of blockchain transactions includes the candidate primary block identifier and the candidate secondary block identifier.

50. A computer device for use by a querying user, the device include: a memory, the memory comprising one or more memory units; and A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to execute the method according to claim 48 or 49 when on the processing device.

51. A computer-readable storage medium having computer-readable code encoded thereon, which is configured to perform the method of claim 48 or 49 when executed on a computer device of a querying user.

Images