Short transaction identifier conflict detection and coordination

Abstract

A method and apparatus for resolving conflicts of short transaction identifiers in a blockchain network. The method may include receiving a set of short transaction identifiers from a sending node. The receiving node locates a corresponding full transaction identifier for each short transaction identifier in a memory pool. For at least one short transaction identifier, a receiving party identifies a conflict. The receiving party then sends a message to the sending node requesting a resolution of the conflict regarding the at least one short transaction identifier, and receives conflict resolution data from the sending node enabling identification of a corresponding valid full transaction identifier for the at least one short transaction identifier. The receiving party may send an intermediate Merkle tree hash with its resolution request, and the conflict resolution data may include information identifying which of the hashes is incorrect.

Description

Technical Field

[0001] The present disclosure relates to blockchain networks. Background Art

[0002] It may be advantageous to devise methods and systems for reducing the bandwidth consumed by chunk data and increasing the speed of propagation when chunk data is propagated; however, such methods and systems may introduce the possibility of conflicts that need to be efficiently resolved. Summary of the invention

[0003] In one aspect, a computer-implemented method for resolving short transaction identifier conflicts in a blockchain network may be provided. The method may include: receiving block data from a sending node, including a block Merkle root and a set of short transaction identifiers from the sending node; for each short transaction identifier, locating a corresponding full transaction identifier in a memory pool; calculating a Merkle tree based on the full transaction identifier, the Merkle tree having a Merkle root; determining that the calculated Merkle root does not match the block Merkle root; sending a Merkle tree hash from an intermediate layer of the Merkle tree to the sending node; receiving resolution data from the sending node, the resolution data identifying which of the Merkle tree hashes is incorrect; and, repeating the sending of the Merkle tree hashes and the receiving of the resolution data until the conflict is resolved.

[0004] In some implementations, each short transaction identifier may be a truncation of its corresponding full transaction identifier.

[0005] In some implementations, the solution data can include a flag for each of the Merkle tree hashes of the intermediate layers, the flag indicating whether the Merkle tree hash is valid.

[0006] In some implementations, the resolution data can include a full transaction identifier of a portion of the bottom layer of the Merkle tree.

[0007] In some implementations, the intermediate layer can be a layer of the Merkle tree between the identified mismatching Merkle hash and a bottom layer of the Merkle tree.

[0008] In some implementations, the method may further include: selecting the intermediate layer.

[0009] In some implementations, the Merkle tree hash can include a partial Merkle tree hash.

[0010] In some implementations, receiving block data can include receiving, from the sending node, a preemptive set of Merkle tree hashes from a selected level of the Merkle tree.

[0011] In another aspect, a computing device for resolving short transaction identifier conflicts in a blockchain network may be provided. The computing device may include: one or more processors; a memory; and computer executable instructions stored in the memory, which, when executed by the one or more processors, cause the processors to perform one or more of the methods described herein.

[0012] In yet another aspect, a computer-readable medium storing processor-executable instructions for resolving short transaction identifier conflicts in a blockchain network may be provided, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processors to perform at least one method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, in which:

[0014] Figure 1 An example method for resolving short transaction identifier conflicts is shown in flowchart form;

[0015] Figure 2 Another example method for resolving short transaction identifier conflicts is shown in flowchart form;

[0016] Figure 3 Another example method for resolving short transaction identifier conflicts is shown in flowchart form;

[0017] Figure 4 shows a simplified example of a Merkle tree structure; and

[0018] Figure 5 A simplified example of a Merkle tree structure with an incorrect TXID is shown.

[0019] The same reference numbers are used throughout the drawings to represent the same elements and features. DETAILED DESCRIPTION

[0020] In one aspect, a computer-implemented method for resolving short transaction identifier conflicts in a blockchain network may be provided. The method may include: receiving block data from a sending node, including a block Merkle root and a set of short transaction identifiers from the sending node; for each short transaction identifier, locating a corresponding full transaction identifier in a memory pool; calculating a Merkle tree based on the full transaction identifier, the Merkle tree having a Merkle root; determining that the calculated Merkle root does not match the block Merkle root; sending a Merkle tree hash from an intermediate layer of the Merkle tree to the sending node; receiving resolution data from the sending node, the resolution data identifying which Merkle tree hash is incorrect; and repeating the sending of the Merkle tree hash and the receiving of the resolution data until the conflict is resolved.

[0021] In some implementations, each short transaction identifier may be a truncation of its corresponding full transaction identifier.

[0022] In some implementations, the solution data can include a flag for each Merkle tree hash of the intermediate layer that indicates whether the Merkle tree hash is valid.

[0023] In some implementations, the resolution data can include a full transaction identifier that is part of the bottom layer of the Merkle tree.

[0024] In some implementations, the intermediate layer can be a layer of the Merkle tree between the identified mismatching Merkle hash and a bottom layer of the Merkle tree. In some cases, the method can include selecting the intermediate layer.

[0025] In some implementations, the Merkle tree hash can include a partial Merkle tree hash.

[0026] In some implementations, receiving the block data can include receiving, from a sending node, a preemptive set of Merkle tree hashes from a selected layer of the Merkle tree.

[0027] In another aspect, the present application provides a computer-implemented method for resolving short transaction identifier conflicts in a blockchain network. The method may include: receiving a set of short transaction identifiers from a sending node; for each short transaction identifier, locating a corresponding full transaction identifier in a memory pool, wherein the locating includes: for at least one short transaction identifier, identifying a conflict; sending a message to the sending node, the message requesting a resolution to the conflict regarding at least one short transaction identifier; and receiving conflict resolution data from the sending node, enabling identification of a corresponding valid full transaction identifier for at least one short transaction identifier.

[0028] In some implementations, the sending can include sending a solution request message including at least one short transaction identifier.

[0029] In some implementations, the conflict resolution data can include a corresponding valid complete transaction identifier.

[0030] In another aspect, a computing device for resolving short transaction identifier conflicts in a blockchain network may be provided. The computing device may include a memory, one or more processors, and computer executable instructions that, when executed, cause the processor to perform one or more of the methods described herein.

[0031] In yet another aspect, a computer-readable medium storing processor-executable instructions for resolving short transaction identifier conflicts in a blockchain network may be provided, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processor to perform at least one method described herein.

[0032] Other example embodiments of the present disclosure will become apparent to those of ordinary skill in the art by reviewing the following detailed description in conjunction with the accompanying drawings.

[0033] In the present application, the term “and / or” is intended to cover all possible combinations and subcombinations of the listed elements, including any one, any subcombination or all of the elements listed individually, and does not necessarily exclude additional elements.

[0034] In the present application, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination or all elements, without necessarily excluding any additional elements and without necessarily requiring all elements.

[0035] This application will refer to hashing or hash functions, which are intended to include any of a number of cryptographic hash functions that, when applied to an arbitrary set of data or "messages", deterministically produce a unique fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, or equivalent. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0036] In this document, the term "blockchain" is understood to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variations.

[0037] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system that consists of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in a blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so blocks are linked together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed.

[0038] Blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and executing software that implements the applicable blockchain protocol. Nodes validate transactions and propagate them to other nodes in the network.

[0039] Short Transaction Identifier Conflicts and Coordination

[0040] As described above, block propagation is a case where it may be advantageous to save bandwidth and increase propagation speed by using compressed transaction identifiers (i.e., short TXIDs). A short TXID may be a truncated TXID, as described above, where the short TXID is a portion of a full TXID. The example given above proposes using the first 4 bytes (32 bits) of a 256-bit full TXID. Short TXIDs of other lengths may be used in other implementations.

[0041] More generally, a short TXID can be any mapping of a full TXID to a shorter length identifier. The mapping function deterministically maps a full TXID to its corresponding short TXID; however, the probability that two different full TXIDs map to the same short TXID is non-zero. In the examples used in this article, the proposed mapping uses a portion of the full TXID (e.g., a truncated TXID), in part because it is very simple to identify the full (one or more) TXIDs that match the short TXID in the memory pool.

[0042] Using short TXIDs may be useful in the context of block propagation. Short TXIDs may also be useful in other contexts where a large number of transaction identifiers are being sent.

[0043] It should be understood that the use of short TXIDs saves bandwidth and speeds up block propagation, but introduces the risk of collisions. That is, there is a certain non-zero probability that a short TXID maps to more than one full TXID. The fewer bits used in the short TXID, the higher the probability of a collision. The probability of a collision in a single block can be expressed as:

[0044]

[0045] In the above expression, P c is the probability of a collision, n is the number of bits used for the short TXID, and t is the number of transactions in a block. Assuming an average transaction size of 400 bytes, a collision is expected to occur in 1 / P c As an example, consider the case of 1GB blocks or 1TB blocks:

[0046] n bits 1GB(2.5M txs) 1TB(2.5B txs) 32-bit 1718 2.26 40 438,805 440 48 bits 112,589,991 112,590 56 bits 28,823,037,615 28,823,038 64-bit 7,378,697,629,484 7,378,697,629

[0047] It will be appreciated that even with a short 32-bit TXID and 1 GB blocks, relatively few collisions can be expected to occur.

[0048] There are three potential scenarios where a conflict may occur. First, the sending node may identify a conflict. For example, when calculating a short TXID, the sending node may identify two matches in the short TXID. As another example, the sending node may search each short TXID in its memory pool to see if it matches more than one full TXID in the memory pool.

[0049] Second, the receiving node may identify conflicts. For example, due to propagation time delays associated with transactions or block data, the receiving node may have transactions in its memory pool that the sending node does not have in its memory pool. In this case, when attempting to locate the corresponding full TXID in its memory pool, the receiving node will determine that the short TXID matches more than one full TXID.

[0050] Third, a conflict may be caused by a situation where the sending node's mempool has a full TXID mapped to a short TXID, where that full TXID is not in the receiving node's mempool (typically the case when the receiving node requests a missing transaction), but the receiving node's mempool has a different full TXID that happens to map to the same short TXID. This third situation will not be identified by either node when mapping the short TXID to the full TXID. Instead, the sending node will discover this situation when it attempts to validate the block data and discovers that the Merkle root calculated for the transaction's block does not match the Merkle root provided by the sending node. However, there is no way to determine which transaction was incorrectly mapped due to the conflict based on this information.

[0051] This application provides methods to resolve all three conflict situations.

[0052] refer to Figure 1, which illustrates an example method 400 for resolving short transaction identifier conflicts at a sending node in the form of a flow chart. In some example implementations, the operations described in the method 400 are performed by one or more processors as processor-executable instructions executed by the one or more processors. The instructions may be embodied in a software application or module, and in some cases stored in a memory accessible to one or more processors.

[0053] The method 400 may be implemented in the context of a block propagation. The block may include a block header and an ordered list of transaction identifiers, i.e., TXIDs.

[0054] Method 400 includes: In operation 402, the TXID is converted to a short TXID using an applicable mapping function. In this example, the mapping function may include truncating the full TXID. In some implementations, the full TXID may be 256 bits and may be generated by hashing the transaction content using a suitable hash function (e.g., SHA-256). The full TXID may be truncated by retaining only the first N bits of the TXID, where N is a suitable ratio of the full 256 bits to save bandwidth without generating excessive risk of collisions. In some cases, N is 32 bits.

[0055] In operation 404, the sending node determines whether the short TXID causes a conflict. The sending node can do this by searching the full TXID of the memory pool for each short TXID to ensure that only one full TXID has the first 32 bits that match the short TXID. If no conflict is generated, the sending node sends a message containing the short TXID in the ordered list. The message can be a block propagation message.

[0056] If a conflict is detected in operation 404, then in operation 408, the sending node signals the conflict and sends a message with conflict resolution data. In one example, the message with conflict resolution data can be a supplement to the block propagation message. In another example, the message with conflict resolution data can be a modification to the block propagation message. The conflict resolution data can include identifying the transaction that caused the conflict within the ordered list and providing complete TXID information for the transaction. The complete TXID information can include inserting the complete TXID in a suitable field of the message. The complete TXID information can include inserting the remainder of the TXID into a suitable field so that when combined with the short TXID, a complete TXID is generated. The complete TXID information can include sending a sufficiently short additional portion of the TXID to resolve the conflict without sending the entire TXID. The fact that a conflict has occurred can be signaled in the block propagation message. For example, the message can include a dedicated flag for signaling that a conflict has occurred, and if the flag is set, an index of the short TXID that caused the conflict and a field containing conflict resolution data are also included.

[0057] Reference now Figure 2 , which illustrates in the form of a flow chart an example method 500 for resolving short transaction identifier conflicts at a receiving node. In some example implementations, the operations described in the method 500 are performed by one or more processors as processor-executable instructions executed by the one or more processors. The instructions may be embodied in a software application or module and in some cases stored in a memory accessible to one or more processors.

[0058] Method 500 includes: In operation 502, a message including a short TXID is received. In some embodiments, the message may be a block propagation message. In operation 504, the receiving node converts the short TXID to a full TXID based on a mapping function. In this example, where the short TXID is a truncation of the full TXID, the receiving node searches its memory pool to find a full TXID whose first four bytes match the short TXID.

[0059] In operations 506 and 508, the receiving node determines whether any of the short TXIDs causes a conflict, i.e., whether one of the short TXIDs is mapped to more than one complete TXID in the memory pool. If so, the receiving node requests conflict resolution data from the sending node. In particular, the receiving node may send a conflict message identifying the short TXID that caused the conflict to the sending node. In response, the sending node may provide conflict resolution data in the message, e.g., a complete TXID, a remaining portion of a complete TXID, or a portion of a complete TXID sufficient to resolve the conflict.

[0060] Now refer to Figure 3 , which illustrates an example method 600 for resolving a short transaction identifier conflict according to a third scenario. In this scenario, neither the sending node nor the receiving node can detect the conflict because the two conflicting full TXIDs are located in respective different memory pools. The conflict can be inferred from the fact that the Merkle tree root calculated by the receiving node does not match the Merkle tree root provided by the sending node in the block propagation message. To identify the conflict, the receiving node and the sending node can use the Merkle tree structure to find out the transactions involved in the conflict.

[0061] In some example implementations, the operations described in method 600 are performed by one or more processors at the receiving node as processor-executable instructions executed by the one or more processors. The instructions may be embodied in a software application or module and in some cases stored in a memory accessible to one or more processors.

[0062] Method 600 includes: In operation 602, receiving a message including a short TXID. In some embodiments, the message may be a block propagation message. Operation 602 also includes receiving block header information, such as a Merkle tree root for an ordered list of transactions. In operation 604, the receiving node converts the short TXID to a full TXID based on a mapping function. In this example, where the short TXID is a truncation of the full TXID, the receiving node searches its memory pool to find a full TXID whose first four bytes match the short TXID.

[0063] In operations 606 and 608, the receiving node determines whether any of the short TXIDs causes a conflict, i.e., whether one of the short TXIDs is mapped to more than one complete TXID in the memory pool. If so, the receiving node requests conflict resolution data from the sending node. In particular, the receiving node may send a conflict message identifying the short TXID that caused the conflict to the sending node. In response, the sending node may provide conflict resolution data in the message, e.g., a complete TXID, a remaining portion of a complete TXID, or a portion of a complete TXID sufficient to resolve the conflict.

[0064] After no conflicts are identified or any identified conflicts have been resolved, in operation 610, the receiving node builds a Merkle tree corresponding to the ordered list of transactions based on the complete TXIDs identified in operation 604. In operation 612, the receiving node evaluates whether the calculated Merkle tree root matches the Merkle tree root provided by the sending node. If so, then the receiving node has verified the contents of the block and can proceed to verify the block and / or propagate the block to the next node, or in the case of candidate block propagation, it can simply store the candidate block in memory as described above.

[0065] If the calculated Merkle root does not match the Merkle root provided by the sending node, the mismatch may be caused by a conflict. To resolve the conflict, the sending node and the receiving node can narrow down the possible transactions by exchanging the intermediate Merkle tree hash data. For the purpose of explanation, we will now also refer to Figure 4 , which shows a simple example of a Merkle tree 700.

[0066] The Merkle tree is constructed by recursively concatenating and hashing the contents of child nodes until a root node is reached. The concatenation and hashing of two child nodes both provide the contents of the parent node in the upper layer. For example, in the case of Merkle tree 700, represented as T i The leaf nodes of TXID are each TXID. TXID itself is the hash of transaction data. 3 and T 4 For example, concatenate them and hash them to find the content of the node above N 32 =H(T3 ||T 4 ). If the leaf node is located at level 4 of the Merkle tree 700, then the node N32 is located at level 3 of the Merkle tree 700. 21 The hash of the child node that is determined to be connected is as follows: N 21 =H(N 31 ||N 32 ). The nodes of the Merkle tree 700 are constructed by connecting and hashing in a recursive, breadth-first, bottom-up manner until the root node 702 is found. The root node 702 is located at level 0 of the Merkle tree 700.

[0067] It will be appreciated that any change to a leaf node, e.g., an incorrect TXID, will affect all related nodes in the path from the Merkle tree 700 up to the root node 702. Referring now also to Figure 5 , which shows a Merkle tree 700 ( Figure 4 ) is a Merkle tree 800 of the same structure as in the previous example. The Merkle tree 800 has a root node 802 and five layers labeled from 0 to 4. The leaf node at layer 4 includes an incorrect TXID 804, as indicated by the "x" symbol. The nodes labeled "o" have the correct TXID and / or the correct Merkle tree hash. It will be noted that the incorrect TXID 804 results in an incorrect Merkle tree hash marked by the 'x' symbol in the path up to the Merkle tree root node 802 (which is also incorrect). The hash is "incorrect" in the sense that it does not match the expected hash that would result from having the correct TXID instead of the incorrect TXID 804.

[0068] Return now Figure 3 If the calculated Merkle root does not match the Merkle root provided by the sending node, then in operation 614, the receiving node sends the Merkle tree hash from the intermediate layer of the calculated Merkle tree. The message can be constructed to indicate the Merkle tree layer and contain an ordered list of Merkle tree hashes. For example, still referring to Figure 5 , the receiving node can send the data structure signaling layer 2 and provide four Merkle tree hashes from the layer 2 nodes.

[0069] The sending node receives the provided intermediate layer Merkle tree hashes and compares them to the Merkle tree hashes from its own Merkle tree calculation. The sending node then transmits data to the receiving node to identify which Merkle tree hashes are incorrect. For example, the sending node may send an index value pointing to the incorrect hash. In this example, in the case of four hashes, the sending node may transmit a two-bit value indicating which hash is incorrect. In some cases, the sending node may send a binary signal indicating whether each hash is correct or incorrect. In this example, for example, such a signal may be 0,1,0,0. This may allow the sending node to signal if there is more than one incorrect hash.

[0070] Thus, in operation 616, the receiving node receives a message from the sending node indicating which of the Merkle tree hashes is incorrect. The receiving node can then narrow its search to the subtree below the incorrect Merkle tree hash. Thus, if the conflict has not been resolved, as indicated by operation 618, the receiving node can send another message to the sending node in operation 614, the other message having a Merkle tree hash from further down within the subtree. For example, the receiving node can signal that it is sending four Merkle tree hashes (in this case, TXIDs) from layer 4 within the subtree. In some implementations, the receiving node signals which subtree it is, for example by including in its message data identifying that the subtree root is at layer 2, index 1. In some other implementations, the sending node can infer that subsequent messages are related to the subtree at layer 2, index 1, because this is the subtree that the sending node identified as incorrect.

[0071] In this example, after sending the four TXIDs from the subtree to the sending node, the receiving node then receives a message indicating which of the TXIDs is incorrect and providing conflict resolution data. For example, the conflict resolution data may include the correct full TXID. Alternatively, the sending node may send the full transaction.

[0072] It will be appreciated that the above example is a simplified illustration using a particularly small Merkle tree. For larger trees, the receiving node and / or the sending node can weigh the number of hashes transmitted versus the number of round trip communications. Consider that in the case of a terabyte block containing approximately 2.5 billion transactions, the Merkle tree will have 32 layers. Each layer is twice as large as its parent. The size of the layer is determined by 2 n × 32 bytes are given. However, because only part of the intermediate level within the subtree is sent, each message contains only 2 kelements, where k is the depth within the subtree. In the case of a 32-level tree, to resolve conflicts in 3 round trips of message passing, the receiving node will need to traverse 11 levels deep each time, which involves sending about 64kB of Merkle tree hash data per round trip. To reduce this to two round trips, the receiving node will traverse 16 levels deep and will send about 2MB per message.

[0073] It will be appreciated that this can be performed by having the sending node send the correct Merkle tree hash from the intermediate layer, and having the receiving node reply by indicating which of them do not match the calculated Merkle tree hash.

[0074] In one variation, a probabilistic approach can be used to further reduce the amount of data transmission. Instead of sending the entire 32-byte hash value for each Merkle tree hash, a node can send only 8 bytes, i.e., 25% of the hash value. In this case, the probability of a false positive is 1 in 18,446,744,073,709,551,616. The result of this unlikely event is that the search will not find conflicting transactions. In this case, the search protocol can be restarted using 16 bytes or using the full 32 bytes. The probability of a false positive is low enough that in some cases, only 4 bytes of Merkle tree hash can be used.

[0075] In yet another variation, the sending node may preemptively send some higher-level portion of the Merkle tree. For example, when sending a block propagation message, the sending node may include a partial Merkle tree hash (e.g., 4 bytes) of an intermediate layer (e.g., layer 10). The cost of such a transmission is 4kB. Then a single round-trip resolution of a conflict (in the case of a 1GB block) would only require a 12-level deep subtree, costing 16kB.

[0076] Preemptively sending the Merkle tree intermediate layer hash data may be particularly useful in the case of an anticipated attack scenario. Additionally, if the receiving node has advance information about the intermediate layer, it can change its request method based on the number of collisions it identifies.

[0077] Messages sent between a receiving node and a sending node may have a specified structure. As an example, a message from a receiving node to a sending node providing notification of a mismatched Merkle root and providing intermediate Merkle tree hash data may take the following form:

[0078] [block_hash:byte

[32] ,

[0079] subtree_root_layer:int,

[0080] subtree_root_index:int,

[0081] data_layer:int,

[0082] [hash0,hash1,...hashn]:byte[]

[32] ]

[0084] In the example data structure above, the message references block_hash as the identifier of the block, and uses subtree_root_layer to provide an index into a layer of the Merkle tree. If the message signals a subtree and the depth within the subtree, the number subtree_root_layer and data_layer are encoded. The layers of actual data are not strictly necessary, as it can be calculated by log2(nElements); however, for illustration purposes, they are included here. Thus, n+1 Merkle tree hashes are included.

[0085] The response message may be an array of indices of the unmatched hashes. If the data layer is a bottom layer, e.g., a leaf node of a Merkle tree, then the data layer may include TXIDs or raw transaction data that match the indices of the incorrect hashes. In one example, such a response message may take the following form: [

[0087] block_hash:byte

[32] ,

[0088] has_txs:bool, / / indicates the bottom layer of the tree and includes txs

[0089] subtree_root_layer:int,

[0090] subtree_root_index:int,

[0091] data_layer:int,

[0092] [1]:int[],[rawtx1]:byte[][] ]

[0094] The data structure may be modified appropriately to accommodate the unlikely possibility of more than one such conflict in a block.

[0095] It should be understood that some or all of the above-described operations of the various above-described example methods may be performed in an order different than that shown and / or may be performed simultaneously without changing the overall operation of those methods.

[0096] The various embodiments presented above are merely examples and are by no means meant to limit the scope of the present application. The changes in the innovations described herein will be apparent to those of ordinary skill in the art, and such changes are within the intended scope of the present application. In particular, features from one or more of the above-described example embodiments may be selected to create alternative example embodiments, which include sub-combinations of features that may not be explicitly described above. In addition, features may be selected from one or more of the above-described example embodiments and combined to create alternative example embodiments, which include combinations of features that may not be explicitly described above. Those skilled in the art will readily appreciate the features that are suitable for such combinations and sub-combinations when reviewing the present application as a whole. The subject matter described herein and in the claims cited is intended to encompass and include all suitable technical changes.

Claims

1. A computer-implemented method for resolving short transaction identifier conflicts in a blockchain network, comprising: Receive block data from the sending node, including the block Merkle root and short transaction identifier set from the sending node; For each short transaction identifier, locate the corresponding full transaction identifier in the memory pool; Calculating a Merkle tree based on the complete transaction identifier, the Merkle tree having a Merkle root; Determining that the calculated Merkle root does not match the block Merkle root; Sending a Merkle tree hash from an intermediate layer of the Merkle tree to the sending node; receiving resolution data from the sending node, the resolution data identifying which of the Merkle tree hashes is incorrect; as well as The sending of the Merkle tree hash and the receiving of the resolution data are repeated until the conflict is resolved.

2. The method according to claim 1, wherein: Each short transaction identifier is a truncation of its corresponding full transaction identifier.

3. The method according to claim 1 or 2, wherein: The solution data includes a flag for each of the Merkle tree hashes of the intermediate layer, the flag indicating whether the Merkle tree hash is valid.

4. The method according to claim 1 or 2, wherein: The solution data includes a complete transaction identifier that is part of the bottom layer of the Merkle tree.

5. The method according to claim 1 or 2, wherein: The intermediate layers are the layers of the Merkle tree between the identified mismatching Merkle hashes and the bottom layer of the Merkle tree.

6. The method according to claim 5, further comprising: The middle layer is selected.

7. The method according to claim 1 or 2, wherein: The Merkle tree hash includes a partial Merkle tree hash.

8. The method according to claim 1 or 2, wherein: Receiving block data includes receiving, from the sending node, a preemptive set of Merkle tree hashes from a selected level of the Merkle tree.

9. A computing device for resolving conflicts of short transaction identifiers in a blockchain network, the computing device comprising: one or more processors; Memory; Computer executable instructions stored in the memory, when executed by the one or more processors, cause the processors to perform the method according to any one of claims 1 to 8.

10. A computer-readable medium storing processor-executable instructions for resolving short transaction identifier conflicts in a blockchain network, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 8.

Images