Method and apparatus for propagating block in block-chain 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 number of transactions grow, delays in block propagation can exacerbate the problems of temporary forks and orphan blocks, which are costly for miners and for the system as a whole. [Brief description 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 example block structure of a blockchain network.

[0006] [Diagram 2] 1 shows a flowchart of an exemplary method of 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 PREFERRED EMBODIMENTS

[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 an order for the transaction within a first ordered set included in the first candidate block; receiving a second message identifying the transaction and an ordering of the transaction in a second ordered list included 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 second block header information from the second mining node 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 generate 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, in which 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, in some examples, the first template identifier is obtained from a hash of a 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 specify transactions in the first ordered list of transactions and transactions in the second ordered set of transactions, hi 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 processor 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 recited elements, including the recited elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements, and does not necessarily require all of the elements.

[0023] This application refers to hashing or hash function, which is intended to include any one of a number of cryptographic hash functions that deterministically generate a unique fixed-length alphanumeric string when applied to any data set or "message." 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 are 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. Although 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, although it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are 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 chained together to create a permanent, immutable record of all transactions written to the blockchain since origin. Transactions contain small programs, known as scripts, that 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 scripting language based on the stack.

[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. The nodes validate transactions and propagate them to other nodes in the network. Dedicated network nodes, called "mining nodes" or "miners," collect a set of unconfirmed or pending transactions into a block and attempt to "mine" the block. Mining, in these examples, refers to solving a proof-of-work (POW) before other miners in the network succeed in solving their respective block's proof-of-work. In the Bitcoin example, the 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 that another miner has succeeded in. Variations in the mining process are well known to those skilled in the art.

[0027] A standard block contains two data structures: a block header and transactions. FIG. 1 shows a schematic of 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 includes fields for, in this example, 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 chains this block to the previous block, thereby resulting in 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 a mining node can repeatedly increment or decrement to change the contents of the block header 102 to generate different hash results when mining.

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

[0029] When 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 that contains the successful hash result value. The other nodes can then request copies of the new block and independently verify its validity.

[0030] The blockchain ecosystem is maturing towards increasing transaction volume and therefore usability due to the large increase in block sizes. As blocks get larger, exceeding 128MB in some cases, propagating a new successfully mined block to other nodes throughout the network can take a lot of time. Propagation delays are costly. First, miners who are unaware of the successfully mined block will continue to try 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 nodes determine that they are not aware of this suspect new block and send a GETBLOCK or GETDATA message to the successful miner. Instead of sending a full copy of the block, the successful miner sends the block header, the 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) of the transactions. The TXIDs may be fixed-length hashes of the transactions in some embodiments. The TXIDs may be 256-bit (32-byte) numbers obtained by hashing the transactions, for example, with SHA-256. The receiving node may reconstruct the full block by reading the identified transactions from a memory pool (mempool) by 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, the present application describes a method and system for a blockchain network in which mining nodes provide information about their respective candidate blocks to other miners while hashing their candidate blocks. In this method, each miner takes advantage of the time delay between successful block discovery, about 10 minutes in Bitcoin's 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 send 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 increases the speed at which successful new blocks propagate throughout the entire network.

[0034] It is understood that unconfirmed transactions propagate and are verified through a network of nodes before they are finalized by being included in a valid block. In this unconfirmed state, the unconfirmed transactions are held in memory. This memory may be called a "mempool." Each miner may, in some implementations, 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, a dedicated node may be utilized by the blockchain network to manage the mempool and provide transactions to mining nodes for inclusion in a candidate block. This application contemplates the use of the method and apparatus with any such variations in the blockchain network. For ease of explanation, it is assumed herein that each mining node maintains its own mempool of unconfirmed transactions.

[0035] A mining node uses the memory pool as a source of new transactions for constructing candidate blocks. A mining node may further 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. The receiving mining node then 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 flow chart form, one exemplary method 200 of blockchain mining. The method 200 is performed by a mining node. The mining node may be implemented in 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 dedicated 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 a memory and a network connection with associated hardware and software for obtaining a network connection and for sending and receiving messages according to an applicable network protocol.

[0037] The 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 of a nonce in the header.

[0038] In operation 204, the mining node begins iterative hashing of the block header and incrementing the nonce as part of the search for a POW that satisfies the mining difficulty setting. As shown by operation 206, while engaged in searching for a POW for its candidate block, the mining node transmits information about its ordered list of transactions to other mining nodes. As shown 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. Although operations 204, 206, and 208 are shown in series, it will be understood that they generally occur in parallel. The information received from other miners about the 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 a 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 details of the block, as indicated by operation 214. In particular, it does not need to send a payload; it does, however, send a coinbase transaction.

[0040] If the mining node receives header information from another mining node, in operation 216 it constructs a new block based on the stored ordered list of transactions for the mining node. If a coinbase transaction is received, it 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 may then validate the new block in operation 218 and, if valid, discard the new block and continue searching for its POW. There may be certain validity checks, and failure may prompt other actions to be taken, such as requesting additional data from successful mining nodes, as described below. If the block is validated, it is added to the blockchain in operation 220 and propagated to further 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 transactions of each other miner ensures that only a minimal amount of information needs to be propagated after the POW is found. This ensures that mining nodes have the information they need to validate a new block as soon as possible, thereby reducing the time wasted searching for a POW when another miner has already succeeded. Mining nodes have every incentive to propagate and validate a new block as soon as possible, so that they can move on to searching for the next block. When pre-distributing an ordered list of transactions during a period of about 10 minutes between successive blocks, possible delays due to network latency are of much less concern.

[0042] In one exemplary implementation, an ordered list of transactions from a candidate block may be communicated to another miner by adding order information to the 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 a miner to attach a transaction to an ordered list, remove or delete a transaction from the ordered list, replace a transaction with another transaction, or reorder transactions. In the normal course, a miner may only use an "add" message that specifies an ordered list of transactions. However, there are some cases where a miner may remove or replace a transaction. For example, information received later 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 the 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 the block-propagating message can be achieved by shortening the TXID string. The TXID is in some examples 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] While the first 8 bytes of a TXID are not guaranteed to uniquely identify a transaction, the chances of two TXIDs colliding, both within a single message or in general, are small. Given that the SHA256 output is a pseudorandom 256-bit string, the exact chance of a collision between two random TXIDs, i.e., the chance that any two TXIDs will 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 does occur, the receiver of the message simply needs to request 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. The miner identity may be determined by an 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 that indicate 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 unordered transaction with a different 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, for example from 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 its respective candidate block is sent automatically 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 that relates 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 miner. The sequence helps the message recipient to 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 of 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 with 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 operations 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 possibility 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 opening 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 the 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 the message with the private key of a pre-published 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 that have 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 that corresponds 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 of the following form:

number

number

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

[0066] In Figure 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] As shown in Figure 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. Since the miners 302, 304 are free to select which transactions from their memory pools they want and to group the transactions in whatever order they want, 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, the 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 still 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 succeeds in finding a block header hash that meets the proof-of-work requirements. Thus, the first candidate block 308 with the recently tested nonce in the header results in 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 including the coinbase transaction 320 and a message including the block header information 324. The block header information 324 includes at least the 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 to the second miner 304 a hash value obtained by hashing the block header, so that the second miner 304 can verify not only that the hash is below the mining difficulty threshold, but that it matches the hash that the first miner 302 claims to have found. The hash value may be sent in the coinbase transaction 320, in 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 can compute the Merkle root. From that computation, 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 fields, to construct a 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 that the block constructed by 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] Although 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] It may be understood by those skilled in the art of blockchain networks 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. It is possible that valid blocks may be discovered sooner. Additionally, some messages propagating transactions or transaction ordering information may experience network delays as they propagate through the network.

[0076] Thus, although low, it is possible that a valid block is found by a miner and the header information is sent to other miners, but at least one of those miners does not have all the transactions included in the block or has an incomplete or incorrect ordered list of the successful miner's transactions. When the miner tries to verify the Merkle root field of the new block header, it finds a mismatch and considers the block invalid. One option is to determine the block invalid and discard it. However, in another embodiment, the miner may send a request message to the 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 an ordered list of transactions of a candidate block of another miner finds that it does not have one of the TXIDs in its own memory pool, the missing transaction may be detected before it successfully finds 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. If a valid block is found, the miner distributes a decryption key along with the header information and / or coinbase transaction, which then allows the receiving miner to decrypt the ordered list of transactions and validate the new block.

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

[0079] The receiving miner modifies the candidate block template that corresponds 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 own memory pool, but if a 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 an order different from that shown and / or may be performed simultaneously without changing the overall operation of the methods.

[0083] 4, a simplified mining node 400 is illustrated in block diagram form, in accordance with an example of the present application. The 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. The 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 meant 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 combinations of features not explicitly shown 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 shown above. Features suitable for such combinations and combinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described in the present specification and claims 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 ordering 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 and updating the block header to continue the hashing; sending a second message to the other mining nodes specifying the second plurality of transactions and the second ordering of the second plurality of transactions in the candidate block; The method includes:

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 and 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 a concatenation of (a) the mining node identifier, and (b) a hash value associated with a previous block in a blockchain.

7. finding 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 to 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:

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. A method according to any preceding claim, wherein the first message and the second message include compressed transaction identifiers designating 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 implementing a mining node for mining blocks on a blockchain network, the computing device comprising: one or more processors; Memory, computer-executable instructions stored in said memory, which, when executed by said one or more processors, cause said processors to perform a method according to any one of claims 1 to 12; 2. A computing device comprising:

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

Images