METHOD AND APPARATUS FOR PROPAGATING BLOCKS IN A BLOCKCHAIN ​​NETWORK

Abstract

To provide method and apparatus that can be adapted to increases in block size and number of transactions in block propagation between miners in a block-chain network.SOLUTION: A method includes sending information about its ordered list of transactions to other mining nodes while a mining node is engaged in searching for a POW for its candidate block, sending header information including a coin-based transaction, a hash value, and a timestamp to the other mining nodes when it finds a POW, if it receives the header information from another mining node, constructing a new block based on the stored ordered list of transactions for the mining node, validating the new block, and if valid, discarding its candidate block and continuing the search for a POW for the next block.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to blockchain networks, and in particular to the propagation of blocks between miner nodes. [Background technology]

[0002] In a proof-of-work blockchain system, when a miner finds a valid block, it attempts to quickly communicate its success to all other miners. This involves propagating information about the block to all mining nodes throughout the blockchain network. In some cases, this may involve sending the full block data. In some cases, this may involve sending the block header and transaction list information. The receiving miner validates the new block by hashing the header and verifying that it matches the hash value provided by the successful miner.

[0003] As block sizes and transaction numbers increase, delays in block propagation can exacerbate the problems of temporary forks and orphan blocks, which are costly for miners and the system as a whole. [Brief explanation of the drawings]

[0004] By way of example, reference is made to the following accompanying drawings which illustrate exemplary embodiments of the present application:

[0005] [Figure 1] 1 illustrates an exemplary block structure of a blockchain network.

[0006] [Figure 2] 1 shows a flowchart of an exemplary method for block propagation.

[0007] [Figure 3A]1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3B] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3C] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3D] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3E] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3F] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3G] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3H] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3I] 1 illustrates a sequence of messages and operations in an exemplary implementation of block propagation according to the present application.

[0008] [Figure 4] A simple example of a mining node is shown in block diagram form.

[0009] Like reference numbers in the figures are used to denote like elements and features. DETAILED DESCRIPTION OF THE INVENTION

[0010] In one aspect, a computer-implemented method of block propagation in a blockchain network may be provided, the method comprising: While hashing the first block header of the first candidate block at the first mining node, sending a first message to other mining nodes specifying the transaction and its order within a first ordered set included in the first candidate block; receiving a second message identifying the transaction and its order in a second ordered list contained in a second candidate block being mined by a second mining node; may include:

[0011] In some implementations, receiving the second message includes storing the second ordered set of transactions in a memory at the mining node in association with a second mining node identifier.

[0012] In some implementations, the method includes receiving, from the second mining node, second block header information indicating successful achievement of proof-of-work for the coinbase transaction and the second candidate block, the second block header information including at least a timestamp and a nonce; constructing a second block header based on the second ordered set of transactions, the coinbase transactions, and the second block header information; verifying the second candidate block by hashing the second block header to verify the proof-of-work; In some cases, the constructing step includes determining a Merkle root from the second ordered set of transactions and the coinbase transactions.

[0013] In some implementations, the method includes discovering a proof-of-work associated with a nonce in the first block header of the first candidate block by hashing the first block header to produce a hash value below a mining difficulty threshold, resulting in: Sending the coinbase transaction from the first candidate block and first block header information to the other mining nodes, the first block header information including at least a timestamp and the nonce; adding the first candidate block to a local copy of the blockchain; In some cases, the first block header information excludes at least some header fields. In some cases, the first mining node does not resend the first ordered set of transactions to the other mining nodes after discovering the proof-of-work.

[0014] In some implementations, the method may include a first construction step of selecting and ordering transactions from a memory pool, where in some implementations the method constructs a candidate block, generating the first ordered set of transactions, and adding a coinbase transaction.

[0015] In some implementations, the first message includes a first template identifier based on a first mining node identifier and a block-level indicator, and in some examples, the first template identifier is obtained from a hash of the concatenation of (a) the first mining node identifier and (b) a hash value associated with a previous block in the blockchain.

[0016] In some implementations, the first message and the second message include compressed transaction identifiers that designate transactions in the first ordered list of transactions and transactions in the second ordered set of transactions, and in some examples, the compressed transaction identifiers are truncated transaction identifiers.

[0017] In some implementations, the first ordered list of transactions in the first message is encrypted, and a decryption key for decrypting the first ordered list of transactions is provided to the other miners only if the first mining node discovers a proof-of-work for the first candidate block.

[0018] In another aspect, a computing device may be provided that implements a first mining node for mining blocks on a blockchain, the computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processors to perform one or more of the methods described herein.

[0019] In yet another aspect, a computer-readable medium may be provided having processor-executable instructions stored thereon for implementing a first mining node for mining blocks in a blockchain network, the processor-executable instructions, when executed by one or more processors, causing the processors to perform at least one of the methods described herein.

[0020] Other exemplary embodiments of the present disclosure will become apparent to those skilled in the art from a reading of the following detailed description in conjunction with the drawings.

[0021] As used herein, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including the listed elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements.

[0022] As used herein, the term "at least one of ... or ..." is intended to cover all possible combinations and subcombinations of the listed elements, including the listed elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements, and does not necessarily require all elements.

[0023] This application refers to hashing or a hash function, which is intended to include any one of a number of cryptographic hash functions that, when applied to any data set or "message," deterministically generate a unique fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, or equivalents thereof. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2. Hereinafter, references to a miner hashing a block or candidate block will be understood to mean applying a cryptographic hash function to the header portion of the candidate block.

[0024] As used herein, the term "blockchain" is understood to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin, as exemplified by the Bitcoin SV protocol, may be referenced herein for convenience and illustrative purposes; however, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are encompassed within the scope of the present invention.

[0025] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed 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 contains at least one input and at least one output. Each block contains a hash of the previous block, and these blocks are strung together to create a permanent, immutable record of all transactions written to the blockchain since its origin. Transactions contain small programs known as scripts. Scripts embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0026] A blockchain is implemented by a network of nodes. Each node is a computing device with a network connection and running software that implements the applicable blockchain protocol. Nodes validate transactions and propagate them to other nodes in the network. Dedicated network nodes, called "mining nodes" or "miners," collect sets of unconfirmed, or pending, transactions into blocks and attempt to "mine" the blocks. Mining, in these examples, refers to solving a proof-of-work (POW) before other miners in the network successfully solve their respective block's proof-of-work. In the Bitcoin example, POW involves hashing a block header containing a nonce until the result is below a threshold set by a mining difficulty parameter. The nonce is repeatedly incremented, and hashing is repeated until the result is below the threshold or the miner receives a nonce successfully mined by another miner. Variations on the mining process are familiar to those skilled in the art.

[0027] A standard block contains two data structures: a block header and transactions. FIG. 1 schematically illustrates an exemplary block structure 100 from the Bitcoin protocol. The block structure 100 includes a block header 102 and a payload 104. The block header 102, in this example, includes fields for a version number 106, a hash value 108 of the previous block, a Merkle root 110, a timestamp 112, a target mining difficulty parameter 114, and a nonce 116. The hash value 108 of the previous block connects this block to the previous block in a chain, thereby creating a "blockchain" structure that links successive blocks together through cryptographic hashes. The Merkle root 110 represents a Merkle tree structure based on all transactions contained in the block. The nonce 116 is an arbitrary value that mining nodes can repeatedly increment or decrement to change the contents of the block header 102 to generate different hash results when mining.

[0028] Payload 104 includes a transaction count value 118 and a list of transactions 120. List of transactions 120 may, in some implementations, be a list of transaction ID numbers.

[0029] If a mining node successfully finds a block header that produces a hash result that is below the threshold, it proceeds to notify other nodes with an updated inventory message containing the successful hash result value, which can then request a copy of the new block and independently verify its validity.

[0030] The blockchain ecosystem is maturing toward increasing transaction volume and, consequently, ease of use due to significantly increased block sizes. As blocks grow larger, exceeding 128MB in some cases, propagating a successfully mined new block to other nodes throughout the network can take a significant amount of time. Propagation delays are costly. First, miners unaware of the successfully mined block will continue to attempt to mine their own candidate block, a wasted effort if the new block proves valid. Second, propagation and validation delays can increase the likelihood of (temporary) forks and orphaned blocks.

[0031] It is understood that in many blockchain protocols, miners do not send full copies of blocks, but instead send hash results in inventory messages. The receiving mining node determines that it is unaware of this suspected new block and sends a GETBLOCK or GETDATA message to the successful miner. Rather than sending a full copy of the block, the successful miner sends the block header, transaction content fields from the payload, and an ordered list of transactions contained in the block. The ordered list may include a set of full transaction ID numbers (TXIDs) for the transactions. In some embodiments, the TXIDs may be fixed-length hashes of the transactions. The TXIDs may be 256-bit (32-byte) numbers obtained by hashing the transactions using, for example, SHA-256. The receiving node may reconstruct the full block by retrieving the identified transactions from a memory pool (mempool) using their TXIDs.

[0032] However, with modern block sizes increasing to over 128MB, the size of the data to be transmitted can still be substantial if the transaction count is large. For example, a block containing 500,000 transactions may have an ordered list of TXIDs that is 16MB.

[0033] Thus, in one aspect, this application describes a method and system for a blockchain network in which mining nodes provide information about their respective candidate blocks to other miners as they hash their candidate blocks. In this method, each miner takes advantage of the time delay between successful block discovery—approximately 10 minutes in the Bitcoin example—to provide other miners with details about the structure and contents of the candidate block. By providing this information in advance, when a successful block is found, the successful miner only needs to transmit information from the block header, and in some cases, the coinbase transaction, to ensure that all other nodes can reconstruct and verify the complete new block. This data can be as little as a few hundred bytes. This improves the speed at which successful new blocks propagate throughout the network.

[0034] It is understood that unconfirmed transactions propagate and are verified through a network of nodes before becoming confirmed by being included in a valid block. In this unconfirmed state, the unconfirmed transactions are held in memory. This memory may be referred to as a "mempool." In some implementations, each miner may maintain its own copy of the mempool and may select a set of transactions from the mempool to reconstruct a candidate block. In some alternative architectures, the mempool may be implemented as a distributed mempool across multiple nodes. In some architectures, dedicated nodes may be utilized by the blockchain network to manage the mempool and provide transactions to mining nodes for inclusion in candidate blocks. This application contemplates using the methods and apparatus with any such variations in the blockchain network. For simplicity of explanation, it is assumed herein that each mining node maintains its own mempool of unconfirmed transactions.

[0035] Mining nodes use the memory pool as a source of new transactions for constructing candidate blocks. Mining nodes may also use the memory pool when validating new blocks from other miners, since each block contains an ordered list of transactions. The ordered list may identify transactions by unique transaction identifiers, such as TXIDs. Thus, the receiving mining node reads transactions from the ordered list, validates the block against block-level criteria, and validates the transactions against transaction-level criteria. In this way, miners defend against double-spend and other attacks.

[0036] To explain aspects of the present application, reference is now made to FIG. 2. FIG. 2 illustrates, in flowchart form, one exemplary method 200 of blockchain mining. Method 200 is performed by a mining node. A mining node may be implemented on a computing device that may include one or more processing units. As will be appreciated by those skilled in the art, the processing unit may include a special-purpose processing unit having dedicated hardware designed to perform computational operations associated with blockchain mining with significant speed and efficiency. However, it may also or alternatively include a general-purpose computing device. The computing device includes processor-executable software that 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 for sending and receiving messages according to applicable network protocols.

[0037] Method 200 includes, at operation 202, selecting a set of transactions from a memory pool of unconfirmed transactions to build a candidate block. The selection may be based on the age of the transactions, the fee payable to mine the transactions, or any other factor. The transactions form an ordered list of transactions. The mining node further determines a Merkle root based on the ordered list of transactions and forms a block header, which includes setting an initial value for a nonce in the header.

[0038] At operation 204, the mining node begins iterative hashing of the block header and incrementing the nonce as part of its search for a POW that satisfies the mining difficulty setting. While engaged in searching for a POW for its candidate block, as indicated by operation 206, the mining node transmits information about its ordered list of transactions to other mining nodes. As indicated by operation 208, the mining node also receives messages from other mining nodes while operation 204 is in progress. The messages include information about the respective ordered lists of transactions in the candidate block being worked on by those other mining nodes. While operations 204, 206, and 208 are shown serially, it will be understood that they generally occur in parallel. The information received from other miners about their respective ordered lists of transactions is stored locally by the mining node. The mining node may store the information in a table or other data structure.

[0039] The search for the POW continues until the mining node successfully finds a POW, as indicated by operation 210, or until it receives notification from another mining node that it has found a POW, as indicated by operation 212. If the mining node finds a POW, it sends some header information to the other mining nodes to propagate the block details, as indicated by operation 214. In particular, it does not need to send a payload; it does, however, send a coinbase transaction.

[0040] If a mining node receives header information from another mining node, it constructs a new block based on the stored ordered list of transactions for the mining node in operation 216. If a coinbase transaction is received, the transaction is added to the block, and the mining node can construct a Merkle tree to ensure that the Merkle root is valid. The mining node then validates the new block in operation 218, and if valid, may discard the new block and continue searching for its own proof of work. There may be certain validity checks, and failure may prompt the mining node to take other actions, such as requesting additional data from a successful mining node, as described below. If the block is validated, it is added to the blockchain in operation 220 and propagated to additional mining nodes. The mining node returns to operation 202 to construct a new candidate block and begin the search anew.

[0041] The described method of pre-distributing candidate block information so that each miner knows the ordered list of each other miner's transactions ensures that only a minimal amount of information needs to be propagated after the POW is discovered. This ensures that mining nodes have the information they need to validate a new block as quickly as possible, thereby reducing the time wasted searching for the POW when another miner has already succeeded. Mining nodes have every incentive to propagate and validate a new block as quickly as possible so that they can move on to searching for the next block. When pre-distributing an ordered list of transactions with a period of approximately 10 minutes between successive blocks, potential delays due to network latency are of minimal concern.

[0042] In one exemplary implementation, an ordered list of transactions from a candidate block may be communicated to another miner by adding ordering information to a transaction data packet. Each miner can uniquely identify each other miner. In one exemplary implementation, a message may be sent that uniquely identifies the miner and the block level the miner is working on and lists the TXIDs of the miner's candidate blocks, in order.

[0043] In another example implementation, the messaging protocol may provide for miners to attach transactions to an ordered list, remove or delete transactions from the ordered list, replace a transaction with another transaction, or reorder transactions. In the normal course of events, miners may only use “add” messages that specify an ordered list of transactions. However, there are several cases in which a miner may remove or replace a transaction. For example, subsequently received information may indicate a possible double-spend for one of the transactions or some other possible problem with its validity. In another example, a miner may cycle through all increments of the nonce and may wish to reorder or adjust transactions to change the header in order to change the Merkle root and thereby continue mining blocks. The detailed format of the message structure may vary depending on the implementation.

[0044] Further compression of block-propagated messages can be achieved by shortening the TXID string. The TXID is, in some instances, a 32-byte string. However, in some cases, a compressed TXID may be used, which relies on transmitting only a portion of the TXID. In one example, only the first 8 bytes are transmitted.

[0045] The first 8 bytes of a TXID are not guaranteed to uniquely identify a transaction, but the chances of two TXIDs colliding, both within a single message or in general, are small. Given that the SHA256 output is a pseudo-random 256-bit string, the exact chance of a collision between two random TXIDs, i.e., the chance that any two TXIDs have the same first 4 bytes, is:

number

[0046] where TXID i [0:n] is "TXID i Furthermore, the probability that a message containing N compressed TXIDs will contain one or more collisions is given by:

number

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

number

[0048] This probability is very small, and even if a collision occurs, the receiver of the message simply requests the same message in uncompressed form. Alternatively, the sending mining node may first check to ensure that the ordered list of compressed TXIDs does not contain a collision before sending, and if detected, send the message with the uncompressed TXID. A flag or other signal in the message may indicate whether the TXID in the payload is in compressed or uncompressed form.

[0049] According to the process described herein, each miner in the blockchain network may receive a message from each other miner specifying an ordered list of transactions to be included in the other miner's candidate block. To track this information, each miner may store the ordered list in association with its respective miner identity. Miner identity may be determined by IP address or some other unique identifier. In one exemplary implementation, each miner 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 miner in the network. The ordering information may then be stored in cells of the table indicating to each miner the order in which the miner placed transactions in its candidate block. It is understood that not all transactions have an ordering value and not all transactions are included in all candidate blocks. The following table shows one simple example of a miner's ordered data table: [Table 1]

[0050] In this simple example table, there are four miners with miner IDs A, B, C, and D. Each miner has received and validated transactions TX1, TX2, TX3, TX4, and TX5. The table can be updated to add a transaction to a miner's ordered list, to replace an out-of-order transaction with another transaction, or to remove a transaction from the ordered list, which in turn adjusts the order of the remaining transactions in the ordered list.

[0051] When a miner, such as Miner A, receives a block header message from, for example, Miner C, indicating that a block has been found, Miner A constructs a Merkle tree based on the TXID and the order specified for Miner C. Miner A hashes the block header to verify the hash value. If the block is verified, Miner A constructs a full block with the transaction data in the specified order, adds it to the blockchain, and continues mining by building a new candidate block.

[0052] In some example implementations, the block header sent by a successful miner does not include all fields. For example, it may include only the nonce and timestamp, along with the hash value obtained by miner C when hashing the full block header. The receiving miner may add missing fields such as the version, prev_block hash, the miner-computed Merkle root, and the mining difficulty setting. It can then verify the reconstructed header by hashing it and comparing it to the received hash value.

[0053] In some exemplary implementations, a message from a miner indicating the miner's ordered list of transactions for each candidate block is automatically sent once the candidate block is constructed. In some other exemplary implementations, the ordered list information is provided in response to a request from another miner.

[0054] In some implementations, a template identifier TmID may be defined. The template identifier is specific to the miner and to the block level, so that it effectively references a specific candidate block, i.e., a specific ordered list of transactions. Any message from the miner relating to the miner's ordered list of transactions may include the template identifier to ensure that the receiving miner associates the change with the correct specific ordered list of transactions. In one implementation, the template identifier may be the miner ID and a hash of the prev_block field in the block header, i.e., the hash of the previous block:

number

[0055] This ties the template identifier to the block level and to a specific miner.

[0056] Each message associated with the ordered list of transactions may include a template identifier and may further include a sequence number, which may be an unsigned integer value used to indicate the order of messages from one miner to another. The sequence helps message recipients uniquely determine the TXID order for a particular miner in the event that some messages are not received or are received out of order.

[0057] As mentioned above, the miner ID may be the IP address of the mining node or some other unique identifier for the mining node. In some embodiments, when a miner attaches to the network, an initial authentication operation may occur, which associates a unique miner ID with the mining node. The authentication operation may include a handshake operation in which each miner provides a public key and a digital signature. The authentication is coupled to verification of the digital signature. In some cases, the miner ID may be based on a public key, a digital signature, or some combination thereof.

[0058] In some examples, the handshake operation during the authentication phase may include the establishment of a shared secret between the miners. Many techniques exist for establishing the shared secret. Subsequent messages, such as those related to the ordered list of transactions, may be encrypted for confidentiality and to reduce the likelihood of man-in-the-middle attacks on the mining process.

[0059] In some embodiments, mining nodes perform an authentication procedure after attaching to the network and establishing peer-to-peer connections with each other. The authentication procedure may include sending an authentication challenge message and receiving an authentication response. Failure to receive a valid authentication response results in the mining node closing or dropping the connection to the other mining node. In some cases, mining nodes may have a different endpoint for the authentication connection than their normal public network connection.

[0060] In one exemplary implementation, the authentication challenge message involves the requesting mining node sending a message to the responding mining node. The message is a message that the responding mining node has not seen before. In some cases, the message may be a random code or string of characters. The content of the message is not important, but the responding mining node must not have seen the content before. Therefore, it cannot reuse previously generated material.

[0061] Upon receiving the authentication challenge message, the responding mining node concatenates the received message with a nonce value. The nonce value may be generated by the responding mining node using any pseudo-random process. The responding mining node then signs the concatenated nonce and message using the private key of a pre-issued public-private key pair. In these examples, the public-private key pair is associated with a miner identity. In some cases, the public key may be the miner ID used in communications on the blockchain network. The requesting mining node may have a whitelist or other record of the miner IDs (public keys) of mining nodes attached to the blockchain network.

[0062] Once the responding mining node signs the concatenated nonce and message with its private key, it then generates and sends an authentication response message. The authentication response message may include the public key, e.g., the miner ID, the nonce value used, and the generated digital signature. The requesting mining node may receive the authentication response message and use the public key to verify that the mining node is the owner of the public key and that the public key matches a key on the whitelist corresponding to the particular mining node.

[0063] The authentication response message may be sent along with a corresponding authentication challenge message, so that the responding mining node may mutually authenticate the identity of the requesting mining node.

[0064] In one example, the format of the authentication challenge message may be in the following format:

number

number

[0065] 3A-3I, which diagrammatically illustrate exemplary operational states and message flows between two miners according to implementations of the present application.

[0066] 3A, it can be seen that a first miner 302, Miner A, and a second miner 304, Miner B, are part of a blockchain network, and that there is an existing blockchain 306. Both the first miner 302 and the second miner 304 have locally stored copies of the blockchain 306 in this example. The blockchain 306 is at a particular "height" or block level.

[0067] 3B, each of the miners 302, 304 selects a set of transactions from their respective memory pools to construct a candidate block. Specifically, the first miner 302 constructs a first candidate block 308 containing a first ordered set of transactions, and the second miner 304 constructs a second candidate block 310 containing a second ordered set of transactions. Because the miners 302, 304 are free to select which transactions from their memory pools they wish and group them in whatever order they wish, the first and second ordered sets may or may not contain the same transactions and may or may not have them in the same or partially the same order.

[0068] As shown in FIG. 3C, miners 302, 304 begin mining each candidate block 308, 310 in an attempt to find a nonce that results in a hash of the block header that is less than a threshold set by the mining difficulty.

[0069] While searching for a successful proof-of-work, miners 302, 304 exchange information about the ordered set of transactions in their respective candidate blocks 308, 310. As shown in FIG. 3D , the first miner 302 may send an “add” message 312 to the second miner 304, providing a first ordered list of transactions from the first candidate block 308. From that information, the second miner 304 may construct a template 314 of the first candidate block 308. In some exemplary implementations, the template 314 may be a first ordered list of transactions in TXID format. In some exemplary implementations, the template 314 may be a table, examples of which are provided above. In yet other exemplary implementations, the template 314 may be a copy of the complete candidate block, including the complete transaction data, except for certain unavailable header fields.

[0070] In a similar manner, the second miner 304 may send the first miner 302 an "add" message 316 containing a second ordered list of transactions from the second candidate block 310, as shown in Figure 3E. From that information, the first miner 302 builds a template 318 of the second candidate block 310. Now, each miner has their own candidate block that they each continue to mine, and templates of candidate blocks that other miners are working on.

[0071] FIG. 3F shows that the first miner 302 successfully finds a block header hash that meets the proof-of-work requirements. Therefore, the first candidate block 308, which has the most recently tested nonce in its header, yields a valid block. FIGS. 3G and 3H show that the first miner 302 adds a new block 322 to the blockchain 306 and sends a message containing the coinbase transaction 320 and block header information 324. The block header information 324 includes at least a nonce and a timestamp. It may or may not also include other block header fields, such as a merkle_root field. In some cases, this may be sent as part of the block header information 324, allowing the second miner 304 to double-check its Merkle root calculation, even if it can be calculated by the second miner 304. In some cases, the first miner 302 sends the second miner 304 the full block header of the new block 322. The first miner 302 may send the hash value obtained by hashing the block header to the second miner 304. As a result, the second miner 304 can verify that not only is the hash below the mining difficulty threshold, but that it matches the hash that the first miner 302 claims to have discovered. The hash value may be sent within the coinbase transaction 320, within the block header information message 324, or in a separate message.

[0072] Once the second miner 304 has the coinbase transaction, it can complete the transaction portion of the template 314 of the first candidate block and therefore calculate the Merkle root. From that calculation, it can verify that the merkle_root field is correct if it was included in the block header information message 324. If not, it can complete the merkle_root field and other missing fields, such as the version, prev_block value, and bit field, to construct the block header 326 of 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 miner 304 may then verify the new block by hashing the constructed block header 326.

[0073] Assuming the block constructed at the second miner 304 is verified, the second miner 304 then adds the new block 322 to its copy of the blockchain 306, as shown in FIG. 3I.

[0074] While the above sequence shows the coinbase transaction message 320 being sent before the block header information message 324, it is understood that in some implementations the block header information message 324 may be sent first, or both messages may be combined into a single message. Other variations in the order of operations or implementation details of a particular instance may be made without changing the overall functional operation of the described systems and methods.

[0075] Those skilled in the art of blockchain networks will understand that in some cases, blocks may be mined sooner than expected. In Bitcoin, for example, the mining difficulty setting provides for the discovery of valid blocks approximately every 10 minutes, but the timing is not deterministic. Valid blocks can be discovered much earlier. Additionally, some messages carrying transaction or transaction ordering information may experience network delays as they propagate through the network.

[0076] Thus, although unlikely, a valid block may be discovered by a miner and its header information may be sent to other miners, but at least one of those miners may not have all the transactions included in the block or may have an incomplete or incorrect ordered list of the successful miner's transactions. When the miner attempts to verify the Merkle root field of the new block header, a mismatch may be found, and the block may be considered invalid. One option is to determine the block as invalid and discard it. However, in another embodiment, the miner may send a request message to a successful miner for a set of Merkle leaves, i.e., an ordered list of TXIDs. Upon receiving the set of leaves, the miner may then determine where the error occurred in the Merkle root calculation. If the cause is an incorrect or incomplete order of transactions, the miner may update the order and verify a new block. If the cause is a missing transaction, the miner may request a new transaction and continue the verification process. In some embodiments, if a miner receiving another miner's ordered list of transactions for a candidate block finds that it does not have one of the TXIDs in its own memory pool, the missing transaction may be detected before successfully discovering the block. The receiving miner can then request a copy of the transaction and update its own memory pool.

[0077] In some implementations, one or more miners may wish to maintain some secrecy over their transaction selection and ordering. In such implementations, miners may be able to encrypt their ordered list of transactions as they distribute them during the mining phase. When a valid block is found, the miner distributes a decryption key along with the header information and / or coinbase transaction, allowing the receiving miner to then decrypt the ordered list of transactions and verify the new block.

[0078] The following table shows one set of example messages for one illustrative implementation of messages for the propagation of ordered transactions between miners. [Table 2-1] [Table 2-2]

[0079] The receiving miner modifies the candidate block template corresponding to the template identifier in the message. According to the sequence number, messages received out of sequence for a particular template identifier may be queued until an intervening message is received.

[0080] Presumably, the receiving miner has the appropriate transaction corresponding to the TXID in its memory pool, but if the transaction is missing, it can request a copy of any missing transactions.

[0081] It is understood that the above illustrative message protocol is one example implementation.

[0082] It will be understood that some or all of the above operations of the various above-described exemplary methods may be performed in a different order than that shown and / or may be performed simultaneously without changing the overall operation of the methods.

[0083] 4, a simplified mining node 400 according to an example of the present application is illustrated in block diagram form. Mining node 400 includes a processor 402, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Mining node 400 may further include memory 404, which may include permanent and non-permanent memory for storing values, variables, and in some examples, processor-executable program instructions, and a network interface 606.

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

[0085] The various embodiments described above are merely examples and are not intended to limit the scope of the present application. Various innovations described herein will be apparent to those skilled in the art, as will variations within the intended scope of the present application. In particular, features from one or more of the exemplary embodiments described above may be selected to generate alternative exemplary embodiments, including subcombinations of features not explicitly set forth above. Furthermore, features from one or more of the exemplary embodiments described above may be selected and combined to generate alternative exemplary embodiments, including combinations of features not explicitly set forth above. Features suitable for such combinations and subcombinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described and claimed herein covers and encompasses all appropriate technical modifications.

Claims

1. 1. A computer-implemented method of block propagation in a blockchain network, comprising: constructing a candidate block including a first plurality of transactions in a first order; While hashing the block header of said candidate block, sending a first message to other mining nodes specifying the first plurality of transactions and a first order of the first plurality of transactions within the candidate block; modifying the candidate block by adding a second plurality of transactions in a second order, updating the block header, and continuing the hashing; sending a second message to the other mining nodes specifying the second plurality of transactions and the second order of the second plurality of transactions in the candidate block; A method comprising:

2. 2. The method of claim 1, wherein the steps of modifying the candidate block and sending the second message are repeated for subsequent sets of transactions added to the candidate block until a block solution is found.

3. The method of claim 1 or 2, wherein the first message includes a template identifier and the second message includes the template identifier.

4. 4. The method of claim 3, wherein the first message and the second message each include a respective sequence number indicating an order of the first plurality of transactions and the second plurality of transactions.

5. The method of claim 3 or 4, wherein the template identifier is determined based on a mining node identifier and a block-level indicator.

6. 6. The method of claim 5, wherein the template identifier is obtained from a hash of the concatenation of (a) the mining node identifier and (b) a hash value associated with a previous block in a blockchain.

7. discovering a proof-of-work associated with a nonce in the block header of the candidate block by hashing the block header to produce a hash value below a mining difficulty threshold, resulting in: Sending the other mining nodes the coinbase transaction and block header information from the candidate block, the block header information including at least a timestamp and the nonce; adding the candidate block to a local copy of the blockchain; The method according to any one of claims 1 to 6, further comprising the steps of:

8. The method of claim 7 , wherein the block header information excludes at least some header fields.

9. 9. The method of claim 7 or 8, wherein the first plurality of transactions and the first order, and the second plurality of transactions and the second order, are not resent to the other mining nodes after discovering the proof-of-work.

10. 10. The method of claim 1, wherein the first message and the second message include compressed transaction identifiers specifying the first and second plurality of transactions.

11. The method of claim 10 , wherein the compressed transaction identifier is a truncated transaction identifier.

12. 12. The method according to claim 1, wherein the first message and the second message are encrypted, and a decryption key for decrypting the first message and the second message is provided to the other mining nodes only if a proof-of-work has been found for the candidate block.

13. 1. A computing device that implements a mining node that mines blocks on a blockchain network, the computing device comprising: one or more processors; Memory and computer-executable instructions stored in said memory, which, when executed by said one or more processors, cause said processors to perform the method of any one of claims 1 to 12; and 1. A computing device comprising:

14. 13. A computer-readable medium storing processor-executable instructions for implementing a mining node that mines blocks on a blockchain network, the processor-executable instructions, when executed by one or more processors, causing the processors to perform the method of any one of claims 1 to 12.

Images