Short transaction identifier collision detection and coordination

Abstract

The invention discloses a method and a device for solving short transaction identifier conflicts in a block chain network. The method may include receiving a set of short transaction identifiers from a transmitting node. And the receiving node locates a corresponding complete transaction identifier for each short transaction identifier in the memory pool. For at least one short transaction identifier, a recipient identifies a conflict. Then, the recipient sends a message to the sending node, the message requesting a solution for the conflict with respect to the at least one short transaction identifier, and receives conflict resolution data from the sending node, enabling identification of a corresponding valid complete transaction identifier for the at least one short transaction identifier. The recipient may send the intermediate Merkel tree Hash with its solution request, and the conflict resolution data may include information identifying which of the Hash is incorrect.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 202080035860.2 (PCT international application number PCT / IB2020 / 053436), application date April 10, 2020, and name “Short Transaction Identifier Conflict Detection and Coordination”. Technical Field

[0002] The present disclosure relates to blockchain networks, and more particularly to the propagation of blocks between network nodes. Background Art

[0003] In some consensus-based blockchain systems, specialized network nodes, upon discovering a valid block, attempt to quickly and successfully communicate it to all other network nodes. This involves broadcasting information about the block across the blockchain network to all specialized network nodes. In some cases, this may involve sending the complete block data. In others, this may involve sending both the block header and a list of transactions. Receiving network nodes validate the new block by hashing the block header and confirming that it matches the hash provided by the successful network node.

[0004] As block size and transaction counts increase, delays in block propagation exacerbate the problems of temporary forks and orphaned blocks. These situations are costly to network nodes and the system as a whole.

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

[0006] In one aspect, a computer-implemented method for resolving short transaction identifier conflicts in a blockchain network may be provided, comprising: 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 hash and the receiving of the resolution data until the conflict is resolved.

[0007] Optionally, each short transaction identifier is a truncation of its corresponding full transaction identifier.

[0008] Optionally, 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.

[0009] Optionally, the solution data comprises a full transaction identifier that is part of the bottom layer of the Merkle tree.

[0010] Optionally, the intermediate layer is a layer of the Merkle tree between the identified mismatched Merkle hash and a bottom layer of the Merkle tree.

[0011] Optionally, the method further includes: selecting the intermediate layer.

[0012] Optionally, the Merkle tree hash comprises a partial Merkle tree hash.

[0013] Optionally, receiving block data comprises receiving, from the sending node, a preemptive set of Merkle tree hashes from a selected level of the Merkle tree.

[0014] In another aspect, a computer-implemented method for resolving short transaction identifier conflicts in a blockchain network may be provided, comprising: 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 locating comprises: for at least one short transaction identifier, identifying a conflict; sending a message to the sending node, the message requesting a conflict resolution for the 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 the at least one short transaction identifier.

[0015] Optionally, the sending comprises sending a solution request message including the at least one short transaction identifier.

[0016] Optionally, the conflict resolution data includes a corresponding valid complete transaction identifier.

[0017] In another aspect, a computer-implemented method for resolving short transaction identifier conflicts in a blockchain network may be provided, comprising: determining a set of short transaction identifiers corresponding to full transaction identifiers stored in a memory pool, and confirming that no short transaction identifier in the short transaction identifier set causes a conflict within the memory pool (i.e., confirming that no short transaction identifier in the short transaction identifier set causes a conflict within the memory pool); sending block data to a receiving node, including a block Merkle root and the set of short transaction identifiers; receiving, from the receiving node, a Merkle tree hash from an intermediate layer of a Merkle tree; comparing the received Merkle tree hash with a locally generated Merkle tree hash of the intermediate layer of the Merkle tree to identify which of the received Merkle tree hashes is incorrect; and sending resolution data to the receiving node, the resolution data identifying which of the received Merkle tree hashes is incorrect and providing one or more full transaction identifiers so that the incorrect Merkle tree hash can be corrected.

[0018] Optionally, each short transaction identifier is a truncation of its corresponding full transaction identifier.

[0019] Optionally, the solution data comprises a flag for each of the received Merkle tree hashes of the intermediate layer, the flag indicating whether the Merkle tree hash is valid.

[0020] Optionally, the solution data comprises a full transaction identifier that is part of the bottom layer of the Merkle tree.

[0021] Optionally, the received Merkle tree hash comprises a partial Merkle tree hash.

[0022] Optionally, the method further comprises: repeating the receiving Merkle tree hash and the sending solution data for other layers of the Merkle tree until the receiving node has a correct complete transaction identifier for calculating the block Merkle root of a block.

[0023] Optionally, the sending of resolution data includes: sending data for identifying which of the received Merkle tree hashes is incorrect; receiving from the receiving node additional Merkle tree hashes from a layer lower than the middle layer in the Merkle tree; identifying additional Merkle tree hashes in the additional Merkle tree hashes that do not match the corresponding locally generated Merkle tree hash; and sending the one or more complete transaction identifiers used to generate the corresponding locally generated Merkle tree hash.

[0024] 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 one or more processors to perform one or more of the methods described herein.

[0025] 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, wherein the processor-executable instructions, when executed by one or more processors, cause the one or more processors to perform at least one method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0027] Figure 1 An example block structure of a blockchain network is shown;

[0028] Figure 2 A flowchart illustrating an example method of block propagation;

[0029] Figures 3A-3I schematically illustrates a sequence of messages and operations in an example implementation of block propagation according to the present application;

[0030] Figure 4 An example method for resolving short transaction identifier conflicts is shown in the form of a flowchart;

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

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

[0033] Figure 7 A simplified example of a Merkle tree structure is shown;

[0034] Figure 8 shows a simplified example of a Merkle tree structure with an incorrect TXID; and

[0035] Figure 9 A simplified example of a blockchain node is shown in block diagram form.

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

[0037] 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; computing a Merkle tree based on the full transaction identifier, the Merkle tree having a Merkle root; determining that the computed 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.

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

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

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

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

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

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

[0044] 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 for the conflict regarding the 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 the at least one short transaction identifier.

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

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

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

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

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

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

[0051] In this application, the phrase "at least one of..." is intended to encompass any one or more of the listed elements, including any one of the listed elements alone, in any subcombination, or all of the elements, without necessarily excluding any additional elements, nor necessarily requiring all elements.

[0052] This application will refer to hashing or hash functions, which are intended to include any of a number of cryptographic hash functions that deterministically produce a unique, fixed-length alphanumeric string when applied to an arbitrary set of data or "messages." 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. Any reference below to "a network node hashing a block or candidate block" will be understood to mean applying a cryptographic hash function to the block header portion of a candidate block.

[0053] In this document, the term "blockchain" is understood to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchains and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variations. It should be noted that the present invention is not limited to use with a specific blockchain, and alternative blockchain implementations and protocols fall within the scope of the present invention.

[0054] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer system composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the 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 chained together to create a permanent, unchangeable record of all transactions written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs. These programs specify how and by whom the transaction's outputs can be accessed. On some platforms, these scripts are written in a stack-based scripting language.

[0055] Blockchains are implemented on a network of nodes. Each node is a computing device with network connectivity and running software that implements the applicable blockchain protocol. Nodes validate transactions and propagate them to other nodes in the network. Specialized network nodes collect sets of unconfirmed transactions (i.e., pending transactions) into blocks and attempt to "mine" that block. In these examples, mining refers to solving the consensus mechanism before any other network node in the network successfully solves the consensus mechanism for its corresponding block. For example, in some examples, mining refers to solving the proof-of-work (PoW) before any other network node in the network successfully solves the PoW for its corresponding block. In some examples, the consensus mechanism involves hashing a block header containing a nonce until the result is less than a threshold set by a difficulty parameter. The nonce is repeatedly incremented and the hashing process is repeated until the result is less than the threshold or until the network node receives notification that another network node has succeeded. Variations in the mining process will be familiar to those of ordinary skill in the art.

[0056] A typical block contains two data structures: block header and transactions. Figure 1 An example block structure 100 from some blockchain protocols is diagrammatically illustrated. Block structure 100 includes a block header 102 and a payload 104. In this example, block header 102 includes fields for a version number 106, a previous block hash 108, a Merkle root 110, a timestamp 112, a target difficulty parameter 114, and a nonce 116. The previous block hash 108 links the block to the previous block in the chain, creating a "blockchain" structure that links successive blocks together via cryptographic hashes. The Merkle root 110 refers to a Merkle tree structure based on all transactions contained in the block. The nonce 116 is an arbitrary value that network nodes can repeatedly increment or decrement to change the contents of block header 102, thereby producing different hash results when mining.

[0057] The payload 104 includes a transaction count value 118 and a transaction list 120. In some implementations, the transaction list 120 can be a list of transaction ID numbers.

[0058] When a network node successfully finds a block header that produces a hash result less than the threshold, it proceeds to notify other nodes with an updated inventory message that includes the successful hash result value. Other nodes then request a copy of the new block and independently verify its validity.

[0059] Block propagation

[0060] The blockchain ecosystem has matured to provide increased availability through a massive increase in transaction volume and, consequently, in block size. As blocks become larger (in some cases exceeding 128MB), it takes longer to propagate a successfully mined new block to other nodes throughout the network. This delay in propagation comes at a cost. First, network nodes unaware of the creation of a successfully mined block will continue to attempt to mine their own candidate blocks, a wasted effort if the new block proves to be valid. Second, delays in propagation and verification can lead to an increased likelihood of (temporary) forks and orphan blocks.

[0061] It will be appreciated that in many blockchain protocols, network nodes do not send a full copy of the block, but rather a hashed result in an inventory message. The receiving network node determines that it has not yet seen this supposedly new block and sends a GETBLOCK or GETDATA message to the successful network node. The successful network node does not send a full copy of the block, but rather sends the block header, the transaction count field from the payload, and an ordered list of transactions included in the block. The ordered list may include a set of complete transaction ID numbers (TXIDs) for the transactions. In some embodiments, the TXID may be a fixed-length transaction hash. For example, the TXID may be a 256-bit (32-byte) number obtained by hashing the transaction using SHA-256. The receiving node can reconstruct the complete block by retrieving the identified transaction from the memory pool by its TXID.

[0062] However, with modern block sizes growing to 128MB and exceeding the size of the data to be transferred, this can still be quite large if the transaction count is large. For example, a block containing 500,000 transactions would have a 16MB ordered list of TXIDs.

[0063] Thus, in one aspect, this application describes methods and systems for a blockchain network in which network nodes provide information about their respective candidate blocks to other network nodes simultaneously with hashing their candidate blocks. In this way, each network node exploits the time delay between discovering a successful block to provide detailed information about the candidate block structure and content to other network nodes. By providing this information in advance, when a successful block is found, the successful network node only needs to send information from the block header and, in some cases, the original transaction (also known as the coinbase transaction or the genesis transaction) to ensure that all other nodes can assemble and verify the complete new block. This data can be as little as a few hundred bytes. This increases the speed with which successful new blocks are propagated throughout the network.

[0064] It will be understood that unconfirmed transactions are propagated and verified by the network of nodes before being confirmed by inclusion in a valid block. During this unconfirmed state, unconfirmed transactions are stored in memory. This memory may be referred to as a "memory pool." In some implementations, each network node may maintain its own copy of the memory pool, from which it can select a set of transactions to assemble a candidate block. In some alternative architectures, the memory pool may be implemented as a distributed memory pool across multiple nodes. In some architectures, the blockchain network may employ dedicated nodes to manage the memory pool and provide transactions to network nodes for inclusion in candidate blocks. This application contemplates the use of the described methods and apparatus with any such variations in the blockchain network architecture. For simplicity of explanation, it is assumed that each network node maintains its own memory pool of unconfirmed transactions.

[0065] Network nodes use the mempool as a source of new transactions for building candidate blocks. Network nodes can also use the mempool when validating new blocks from another network node, as each block contains an ordered list of transactions. The ordered list can identify transactions by unique transaction identifiers (e.g., TXIDs). Therefore, the receiving network node retrieves the transactions from the ordered list, validates the block according to block-level criteria, and then validates the transactions according to transaction-level criteria. In this way, network nodes prevent double-spend attacks and other attacks.

[0066] To illustrate one aspect of the present application, reference is now made to Figure 2, which illustrates an example method 200 for blockchain mining in the form of a flowchart. The method 200 is implemented by a network node. The network node can be implemented on a computing device, which can include one or more processing units. As will be understood by those skilled in the art, the processing unit can include a dedicated processing unit with specialized hardware designed to perform the computing operations associated with blockchain mining with significant speed and efficiency. However, the processing unit can also or alternatively include a general-purpose computing device. The computing device includes processor-executable software, which includes processor-readable instructions that, when executed, cause one or more processing units to perform the described operations. The computing device includes memory and a network connection with associated hardware and software for obtaining a network connection and sending and receiving messages according to an applicable network protocol.

[0067] Method 200 includes, at operation 202, selecting a set of transactions from a memory pool of unconfirmed transactions to construct a candidate block. This selection may be based on the age of the transactions and factors addressed for mining the transactions. These transactions form an ordered list of transactions. The network node also determines a Merkle root based on the ordered list of transactions and forms a block header, including setting an initial value for a random number in the block header.

[0068] In operation 204, as part of searching for a consensus that satisfies the difficulty setting, the network node begins rehashing block headers and begins incrementing a nonce. While searching for consensus on its candidate block, the network node sends information about its ordered transaction list to other network nodes, as shown in operation 206. While operation 204 is ongoing, the network node also receives messages from other network nodes that include information about the corresponding ordered transaction lists in the candidate blocks being processed by these network nodes, as shown in operation 208. It should be understood that while operations 204, 206, and 208 are shown sequentially, they typically occur in parallel. The information received from other network nodes about the corresponding ordered transaction lists is stored locally by the network node. The network node may store this information in a table or other data structure.

[0069] The search for consensus continues until the network node successfully finds consensus (as shown in operation 210), or until it receives notification from another network node that it has found consensus (as shown in operation 212). If the network node finds consensus, it then sends some block header information to other network nodes in operation 214 to disseminate the block details. Notably, no payload needs to be sent. However, the original transaction can be sent.

[0070] If a network node receives block header information from another network node, then, in operation 216, it assembles a new block based on the node's stored ordered transaction list. If the original transaction is received, it is added to the block, and the network node can construct a Merkle tree to confirm that the Merkle root is valid. Then, in operation 218, the network node verifies the new block; if invalid, it can discard the new block and continue searching for its own consensus. Note that certain validity checks may exist, and if they fail, the network node can be prompted to take other actions, such as requesting additional data from the successful network node, as described later. If the block is verified, then, in operation 220, it is added to the blockchain and propagated to other network nodes. The network node then returns to operation 202 to construct a new candidate block and restart the search.

[0071] It will be appreciated that the described method of pre-distributing candidate block information so that each network node knows the ordered transaction lists of each other network node ensures that only a minimal amount of information needs to be propagated after consensus is found. This ensures that network nodes obtain the information they need to validate new blocks as quickly as possible, thereby reducing the time wasted searching for consensus if another network node has already succeeded. Network nodes have a strong incentive to propagate and validate new blocks as quickly as possible so that they can continue searching for the next block. When pre-distributing ordered transaction lists during the approximately 10-minute period between successive blocks, potential delays due to network latency are less of a concern.

[0072] In one example implementation, an ordered list of transactions from a candidate block can be transmitted to another network node by adding sorting information to the transaction data packet. Each network node is able to uniquely identify each other network node. In one example implementation, a message can be sent that uniquely identifies the network node and the block level at which the network node is working, and lists the TXIDs of the network node's candidate blocks in order.

[0073] In another example implementation, the messaging protocol may provide for appending a transaction to a network node's ordered list, removing or deleting a transaction from an ordered list, replacing a transaction with another transaction, or reordering transactions. In normal operation, a network node will likely only use "add" messages that specify an ordered list of transactions. However, there are some situations in which a network node may wish to remove or replace a transaction. For example, subsequently received information may indicate a potential double spend with one of the transactions or some other potential issue with its validity. As another example, a network node may loop through all increments of a nonce and may wish to reorder or otherwise adjust transactions to change the Merkle root, and thus the block header, in order to continue mining blocks. The precise format of the message structure may vary depending on the implementation.

[0074] Further compression of block propagation messages can be achieved by shortening the TXID string. In some examples, the TXID is a 32-byte string. However, in some cases, a compressed TXID can be used, which relies on sending only a portion of the TXID. In one example, only the first eight bytes are sent.

[0075] Although the first 8 bytes of a TXID are not guaranteed to uniquely identify a transaction, the probability of two TXIDs colliding, either within a single message or in general, is very small. Given that SHA256 outputs a pseudo-random 256-bit string, the exact probability of two random TXIDs colliding, that is, the probability that any two TXIDs have the same first 4 bytes, is:

[0076]

[0077] Among them, TXID i [0:n] means 'TXID i Furthermore, the probability that a message containing N compressed TXIDs will contain one or more collisions can be expressed as:

[0078]

[0079] As an example, if a block contains one million transactions, such that the message contains one million compressed TXIDs (N=1,000,000), then the probability of a collision is:

[0080] P(>0 collisions in 1,000,000 TxIDs) = 0.0000000271

[0081] The probability is so small that even if a collision occurs, the message recipient can simply request the same message in uncompressed form. Alternatively, the sending network node can first check to confirm that the ordered set of compressed TXIDs does not contain any collisions before transmitting, and if any collision is detected, send the message with the uncompressed TXID. A flag or other signal in the message can indicate whether the TXID in the payload is in compressed or uncompressed format.

[0082] According to the process described herein, each network node involved in a blockchain network may receive a message from each of the other network nodes specifying an ordered list of transactions that comprise a candidate block for that other network node. To keep track of this information, each network node may store an ordered list associated with a corresponding network node identity. The network node identity may be determined by an IP address or some other unique identifier. In one example implementation, each network node maintains a table or similar data structure in which each row is associated with one of the transactions in the memory pool and each column is associated with a network node in the network. Sequential information may then be stored in the cells of the table, indicating for each network node the order in which the network node ranks the transactions in its candidate block. It will be understood that not all transactions have an order value because not all transactions are included in every candidate block. The following table illustrates a simplified example of a network node sorting data table:

[0083] TXID network node ID A B C D <![CDATA[TX1]]> 1 2 1 1 <![CDATA[TX2]]> 2 1 3 4 <![CDATA[TX3]]> 3 3 2 2 <![CDATA[TX4]]> 4 4 4 5 <![CDATA[TX5]]> 5 5 5 3

[0084] In this simplified example table, there are four network nodes with network node IDs A, B, C, and D. Each network node has received and verified transactions TX1, TX2, TX3, TX4, and TX5. The table can be updated to add transactions to the network node's ordered list, replace a transaction in the sequence with another transaction, or remove a transaction from the ordered list, which may result in adjusting the order of the remaining transactions in the ordered list.

[0085] When a network node (e.g., network node A) receives a block header message from, for example, network node C indicating that a block has been found, network node A constructs a Merkle tree based on the TXID and the order specified for network node C. Network node A hashes the block header to verify the hash value. If the block is verified, network node A constructs a complete block with transaction data in the specified order, adds it to the blockchain, and constructs a new candidate block to continue mining.

[0086] In some example implementations, the block header sent by the successful network node does not contain all fields. For example, the block header sent by the successful network node may only contain a nonce and a timestamp, along with the hash value obtained by network node C when hashing the full block header. The receiving network node can add the missing fields, such as the version, the prev_block hash, the Merkle root that the network node has calculated, and the difficulty setting. The reconstructed block header can then be verified by hashing it and comparing it to the received hash value.

[0087] In some example implementations, once a candidate block is constructed, messages from network nodes indicating the ordered list of transactions for their respective candidate blocks are automatically sent. In some other example implementations, the ordered list information is provided in response to a request from another network node.

[0088] In some implementations, a template identifier TmID may be defined. The template identifier is specific to the network node and block level so as to effectively refer to a specific candidate block, i.e., a specific ordered list of transactions. Any message from a network node related to its ordered list of transactions may include the template identifier to ensure that the receiving network node associates the change with the correct specific ordered list of transactions. In one implementation, the template identifier may be a hash of the network node identifier (miner ID) and the previous block (prev_block) field in the block header, i.e., the hash of the previous block:

[0089] TmID=H(prev block||miner ID)

[0090] This ties the template identifier to the block level and to a specific network node.

[0091] Each message associated with an ordered list of transactions may include a template identifier and may also include a sequence number. The sequence number may be an unsigned integer value that indicates the order of messages from one network node relative to one another. This ordering helps message recipients uniquely determine the TXID sequencing for a particular network node in the event that some messages are not received or are received out of order.

[0092] As described above, the network node ID can be the IP address of the network node or some other unique identifier for the network node. In some embodiments, when a network node connects to the network, an initial authentication operation may occur, resulting in a unique network node ID being associated with the network node. The authentication operation may include a handshake operation in which each network node provides a public key and a digital signature. Authentication is associated with verification of the digital signature. In some cases, the network node ID can be based on a public key, a digital signature, or some combination thereof.

[0093] In some cases, the handshake operation during the authentication phase may include establishing a shared secret key between network nodes. Many techniques exist for establishing a shared secret key. Subsequent messaging (e.g., messaging related to the ordered list of transactions) can be encrypted for confidentiality and to reduce the possibility of man-in-the-middle attacks on the mining process.

[0094] Now refer to Figures 3A-3I , Figures 3A-3IThe figure schematically illustrates exemplary operating states of two network nodes and message delivery flows therebetween according to an implementation of the present application.

[0095] exist Figure 3A , it will be seen that a first network node 302 (i.e., network node A) and a second network node 304 (i.e., network node B) are part of a blockchain network, and that there is an existing blockchain 306. In this example, both the first network node 302 and the second network node 304 have locally stored copies of the blockchain 306. The blockchain 306 has a specific "height" or block level.

[0096] like Figure 3B As shown, network nodes 302 and 304 each select a transaction set from their respective memory pools to construct a candidate block. Specifically, first network node 302 constructs a first candidate block 308 containing a first ordered transaction set, and second network node 304 constructs a second candidate block 310 containing a second ordered transaction set. The first and second ordered sets may or may not contain the same transactions and may or may not have the transactions in the same or partially the same order, because network nodes 302 and 304 are free to select any transactions they wish from the memory pool and group the transactions in any order they wish.

[0097] like Figure 3C As shown, network nodes 302, 304 begin mining corresponding candidate blocks 308, 310 in an attempt to find a random number that will result in a hash of the block header that is less than a threshold set by the difficulty.

[0098] During the search for a successful consensus, network nodes 302, 304 exchange information about the ordered set of transactions in their respective candidate blocks 308, 310. Figure 3D As shown, first network node 302 can send an "add" message 312 to second network node 304, providing a first ordered list of transactions from first candidate block 308. Based on this information, second network node 304 can construct a template 314 for first candidate block 308. In some example implementations, template 314 can be a first ordered list of transactions in the form of TXIDs. In some example implementations, template 314 can be a table, examples of which are provided above. In other example implementations, template 314 can be a copy of the entire candidate block, excluding certain unavailable header fields, but including complete transaction data.

[0099] In a similar manner, the second network node 304 may send an “add” message 316 to the first network node 302 containing a second ordered list of transactions from the second candidate block 310, such as Figure 3EBased on this data, the first network node 302 constructs a template 318 of the second candidate block 310. Each network node now has their own candidate block that they continue to mine, as well as a template of the candidate block that another network node is currently processing.

[0100] Figure 3F It shows that the first network node 302 has successfully found a block header hash that meets the consensus mechanism requirements. Therefore, the first candidate block 308 with the most recently tested random number in its block header produces a valid block. Then, Figure 3G and Figure 3H First network node 302 is shown adding a new block 322 to blockchain 306 and sending a message containing raw transaction 320 and a message containing header information 324. Header information 324 includes at least a nonce and a timestamp. Header information may or may not also include other header fields, such as a merkle_root field. In some cases, this may be sent as part of header information 324, although it can be calculated by second network node 304 to enable second network node 304 to double-check its merkle root calculation. In some cases, first network node 302 sends the entire header of new block 322 to second network node 304. First network node 302 may also send a hash value obtained from hashing the header to second network node 304 so that second network node 304 can verify not only that the hash is less than a difficulty threshold, but also that it matches the hash that first network node 302 claims to have found. The hash value may be sent in raw transaction message 320, header information message 324, or a separate message.

[0101] Once the second network node 304 has the original transaction, it can complete the transaction portion of the template 314 of the first candidate block so that it can calculate the Merkle root. Based on this calculation, it can verify whether the merkle_root field is accurate and whether it is included in the block header information message 324. If not, it can complete the merkle_root field and any other missing fields, such as the version, prev_block value, and bit fields, to assemble a block header 326 for the new block 322. Other fields of the block header 326, such as the nonce and timestamp, are provided by the block header information message 324. The second network node 304 can then verify the new block by hashing the assembled block header 326.

[0102] Assuming that the block assembled at the second network node 304 is verified, the second network node 304 adds the new block 322 to its copy of the blockchain 306, as shown in FIG. Figure 3I shown.

[0103] While the above sequence shows the original transaction message 320 being sent before the block header information message 324, it will be understood that in some implementations, the block header information message 324 may be sent first, or the two messages may be combined into a single message. Other changes may be made to the order of operations or implementation details of a particular example without changing the overall functional operation of the described systems and methods.

[0104] Those skilled in the art of blockchain networks will appreciate that, in certain circumstances, blocks may be mined earlier than expected. For example, in some examples, the difficulty setting provides for a valid block to be found approximately every ten minutes, but this timing is uncertain. It is possible that a valid block may be found earlier. Furthermore, some messages disseminating transactions or transaction ordering information may experience network delays as they propagate through the network.

[0105] Therefore, although unlikely, the possibility exists that a network node finds a valid block and sends the block header information to other network nodes, but at least one of these network nodes does not have all the transactions included in the block or has an incomplete or incorrect ordered transaction list from the successful network node. When this network node attempts to verify the Merkle root field of the new block header, it will discover a mismatch, and the block will be deemed invalid. One option is for the network node to consider the block invalid and discard it. However, in another embodiment, the network node can send a request message for the Merkle leaf set (i.e., the ordered list of TXIDs) to the successful network node. After receiving the sent leaves, the network node can then determine where the error in the Merkle root calculation occurred. If the cause is incorrect or incomplete transaction ordering, the network node can update the ordering and verify the new block. If the cause is missing transactions, the network node can request new transactions and continue the verification process. Note that in some embodiments, if a network node receiving the ordered transaction list of a candidate block from another network node discovers that one of the TXIDs is missing from its memory pool, the missing transaction can be detected before successfully finding the block. In this case, the receiving network node can request a copy of the transaction and update its memory pool.

[0106] In some implementations, one or more network nodes may wish to maintain a degree of confidentiality regarding their transaction selection and ordering. In such implementations, network nodes may encrypt the ordered transaction list when distributing it during the mining phase. If a valid block is found, the network node distributes a decryption key along with the block header information and / or the original transactions, allowing the receiving network node to decrypt the ordered transaction list and validate the new block.

[0107] The following table describes an example message set for an illustrative implementation of messaging for propagating ordered transaction lists between network nodes:

[0108]

[0109] The receiving network node modifies the candidate block template corresponding to the template identifier in the message.For a particular template identifier, messages received out of order according to sequence numbers may be queued until an intervention message is received.

[0110] Most likely, the receiving network node has the applicable transaction corresponding to the TXID in its memory pool, but if transactions are missing, it can request a copy of any missing transactions.

[0111] It should be understood that the illustrative messaging protocol described above is one example implementation.

[0112] Short Transaction Identifier Conflict and Reconciliation

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

[0114] 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 straightforward to identify the full TXID(s) that match the short TXID in the memory pool.

[0115] Using short TXIDs can be useful in the context of block propagation, both for candidate blocks before consensus is found and for mined blocks after consensus is found. Short TXIDs can also be useful in other contexts where a large number of transaction identifiers are being sent.

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

[0117]

[0118] In the above expression, Pc 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:

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

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

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

[0122] Second, the receiving node can 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 are not in the sending node's 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.

[0123] Third, a conflict can arise from a situation where the sending node's mempool has a full TXID mapped to a short TXID that 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 case is not detected 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 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.

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

[0125] refer to Figure 4 , which illustrates, in flowchart form, an example method 400 for resolving short transaction identifier conflicts at a sending node. In some example implementations, the operations described in 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.

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

[0127] Method 400 includes, at operation 402, converting the TXID 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 fraction of the full 256 bits to save bandwidth without creating excessive risk of collisions. In some cases, N is 32 bits.

[0128] In operation 404, the sending node determines whether the short TXID results in a conflict. The sending node may do this by searching the mempool for full TXIDs for each short TXID to ensure that only one full TXID has a matching first 32 bits with the short TXID. If no conflict results, the sending node transmits a message containing the short TXID in the ordered list. This message may be a block propagation message.

[0129] 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 may be a supplement to the block propagation message. In another example, the message with conflict resolution data may be a modification to the block propagation message. The conflict resolution data may include identifying the transaction within the ordered list that caused the conflict and providing the full TXID of that transaction. The full TXID information may include inserting the full TXID into the appropriate field of the message. The full TXID information may include inserting the remaining portion of the TXID into the appropriate field so that, when combined with the short TXID, the full TXID is generated. The full TXID information may include sending an additional portion of the TXID that is short enough to resolve the conflict without sending the entire TXID. The fact that a conflict has occurred may be signaled in the block propagation message. For example, the message may 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 the conflict resolution data.

[0130] Now refer to Figure 5, which illustrates, in flowchart form, an example method 500 at a receiving node for resolving short transaction identifier conflicts. In some example implementations, the operations described in 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.

[0131] Method 500 includes receiving a message containing a short TXID at operation 502. In some embodiments, the message may be a block propagation message. At 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 truncated full TXID, the receiving node searches its memory pool for a full TXID whose first four bytes match the short TXID.

[0132] 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 maps to more than one full TXID in the memory pool. If so, the receiving node requests conflict resolution data from the sending node. Specifically, the receiving node may send a conflict message to the sending node identifying the short TXID that caused the conflict. In response, the sending node may provide conflict resolution data in the message, e.g., the full TXID, a remaining portion of the full TXID, or a sufficient portion of the full TXID to resolve the conflict.

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

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

[0135] Method 600 includes, at operation 602, receiving a message containing 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. At 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 truncated full TXID, the receiving node searches its memory pool for a full TXID whose first four bytes match the short TXID.

[0136] 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 maps to more than one full TXID in the memory pool. If so, the receiving node requests conflict resolution data from the sending node. Specifically, the receiving node may send a conflict message to the sending node identifying the short TXID that caused the conflict. In response, the sending node may provide conflict resolution data in the message, e.g., the full TXID, a remaining portion of the full TXID, or a sufficient portion of the full TXID to resolve the conflict.

[0137] After no conflicts are identified or any identified conflicts have been resolved, in operation 610, the receiving node constructs a Merkle tree corresponding to the ordered list of transactions based on the complete TXID 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, 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.

[0138] 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 7 , which shows a simple example of a Merkle tree 700.

[0139] The Merkle tree is constructed by recursively concatenating and hashing the contents of the child nodes until the root node is reached. The concatenation and hashing of two child nodes provides the contents of the parent node in the upper layer. For example, in the case of the Merkle tree 700, represented as T i The leaf nodes are each TXID. TXID itself is the hash of the transaction data. Taking T3 and T4 as an example, connect them and perform hashing to find the content of the node above N 32=H(T3||T4). 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 continuing the connection and hashing process 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.

[0140] It will be understood 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. Figure 8 , which shows a Merkle tree 700 ( Figure 7 ) Merkle tree 800 of the same structure. Merkle tree 800 has a root node 802 and five levels labeled from 0 to 4. The leaf node at level 4 includes an incorrect TXID 804, as indicated by the "x" symbol. The nodes marked with an "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.

[0141] Return now Figure 6 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 8 , the receiving node can send the data structure signaling layer 2 and provide four Merkle tree hashes from the layer 2 node.

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

[0143] 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 an additional message to the sending node in operation 614, the additional message having Merkle tree hashes 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 level 4 within the subtree. In some implementations, the receiving node signals which subtree, for example by including in its message data identifying that the subtree root is at level 2, index 1. In some other implementations, the sending node can infer that subsequent messages are related to the subtree at level 2, index 1 because this is the subtree that the sending node identified as incorrect.

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

[0145] It will be understood that the above example is a simplified illustration using a particularly small Merkle tree. For larger trees, the receiving and / or sending nodes can weigh the number of hashes transmitted versus the number of round-trip communications. Considering 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 within three round trips of message passing, the receiving node would need to traverse 11 levels deep each time, which involves sending approximately 64kB of Merkle tree hash data per round trip. To reduce this to two round trips, the receiving node would traverse 16 levels deep and send approximately 2MB per message.

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

[0147] In one variation, a probabilistic approach can be used to further reduce the amount of data transmitted. Instead of sending the entire 32-byte hash value for each Merkle tree hash, a node can send only 8 bytes, or 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 consequence of this unlikely event is that the search will not find a conflicting transaction. 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 the Merkle tree hash can be used.

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

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

[0150] 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:

[0151] [block_hash:byte

[32] ,

[0152] subtree_root_layer:int,

[0153] subtree_root_index:int,

[0154] data_layer:int,

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

[32] ]

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

[0158] The response message may be an array of indices of the mismatched hashes. If the data layer is a bottom layer, such as a leaf node of a Merkle tree, then the data layer may include the TXID or raw transaction data that matches the indices of the incorrect hashes. In one example, such a response message may take the following form: [

[0160] block_hash:byte

[32] ,

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

[0162] subtree_root_layer:int,

[0163] subtree_root_index:int,

[0164] data_layer:int,

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

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

[0168] 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 from that shown and / or may be performed concurrently without changing the overall operation of those methods.

[0169] Now refer to Figure 4 , which shows in block diagram form a simplified network node 400 according to an example of the present application. The network node 400 includes a processor 402, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The network node 400 may also include a memory 404 and a network interface 606. The memory may include persistent and non-persistent memory to store values, variables, and in some cases, processor-executable program instructions.

[0170] The network node 800 may include a processor-executable blockchain application 408 containing processor-executable instructions that, when executed, cause the processor 402 to perform one or more functions or operations described herein.

[0171] The various embodiments presented above are merely examples and are in no way meant to limit the scope of this application. Variations on the innovations described herein will be apparent to those of ordinary skill in the art, and such variations are within the intended scope of this 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. Features suitable for such combinations and sub-combinations will be readily apparent to those skilled in the art upon reviewing this application as a whole. The subject matter described herein and in the claims cited is intended to encompass and include all suitable technical variations.

Claims

1. A computer-implemented method for resolving short transaction identifier conflicts in a blockchain network, comprising: Determining a set of short transaction identifiers corresponding to full transaction identifiers stored in the memory pool, and confirming that no short transaction identifier in the set of short transaction identifiers causes a conflict within the memory pool; Sending block data, including the block Merkle root and the short transaction identifier set, to the receiving node; receiving, from the receiving node, a Merkle tree hash from an intermediate layer of the Merkle tree; comparing the received Merkle tree hash with a locally generated Merkle tree hash of the intermediate layer of the Merkle tree to identify which of the received Merkle tree hashes is incorrect; as well as Resolution data is sent to the receiving node, the resolution data identifying which of the received Merkle tree hashes is incorrect and providing one or more full transaction identifiers so that the incorrect Merkle tree hash can be corrected.

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 received 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 received Merkle tree hash includes a partial Merkle tree hash.

6. The method according to claim 1 or 2, wherein: The receiving Merkle tree hash and sending solution data are repeated for other layers of the Merkle tree until the receiving node has the correct complete transaction identifier for calculating the block Merkle root of a block.

7. The method according to claim 1 or 2, wherein: The sending resolution data includes: Sending data identifying which of the received Merkle tree hashes is incorrect; receiving, from the receiving node, an additional Merkle tree hash from a layer lower than the intermediate layer in the Merkle tree; identifying an additional one of the additional Merkle tree hashes that does not match a corresponding locally generated Merkle tree hash; and The one or more complete transaction identifiers used to generate the corresponding locally generated Merkle tree hash are sent.

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

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

Images