Block propagation by poisoned transaction in blockchain network

Abstract

To provide a method and a device for reducing delays in block propagation between mining nodes in a blockchain network.SOLUTION: A method includes transmitting a first message specifying transactions in a first ordered set of transactions included in a first candidate block and their order to other mining nodes while hashing a first block header of the first candidate block by a first mining node, seeding the first ordered set with one or more invalid transactions to create a poisoned ordered set, transmitting an encrypted list identifying the invalid transactions to the other mining nodes, decrypting the encrypted list once a proof of work (POW) is found for the candidate block, and transmitting a decryption key to identify the invalid transactions to the other mining nodes.SELECTED DRAWING: Figure 4

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 through the blockchain network to all mining nodes. In some cases, this may involve sending the complete 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 counts increase, block propagation delays can exacerbate the problems of temporary forks and orphan blocks. These situations are costly for miners and the system as a whole. Solutions to block propagation delays need to be structured to prevent any possible violation of the consensus rules. [Brief description of the drawings]

[0004] Reference will now be made, by way of example, to the accompanying drawings which illustrate exemplary embodiments of the present application. [Figure 1] 1 illustrates an example block structure for a blockchain network. [Diagram 2] 1 shows a flowchart of an exemplary method of block propagation. [Figure 3A] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3B]1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3C] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3D] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3E] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3F] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3G] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3H] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 3I] 1 illustrates an exemplary sequence of messages and operations in an exemplary implementation of block propagation according to the present application. [Figure 4] 1 illustrates, in flowchart form, one exemplary method for block propagation in a blockchain network. [Diagram 5] 1 illustrates, in flowchart form, one exemplary method for validating blocks in a blockchain network. [Figure 6] 1 illustrates a simplified example of a mining node in block diagram form.

[0005] In the drawings, like reference numbers are used to denote like elements and features. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] In one aspect, a computer-implemented method of block propagation in a blockchain network may be provided. The method may include, while hashing a first block header of a first candidate block at a first mining node, sending a first message to other mining nodes specifying transactions in a first ordered set included in the first candidate block and their order, and receiving a second message identifying transactions in a second ordered set included in a second candidate block being mined by a second mining node and their order.

[0007] In another aspect, a method of block propagation in a blockchain network is described. The method may include, at a first mining node, constructing a first candidate block including transactions in a first ordered set, the first candidate block having a first block header, placing one or more invalid transactions in the first ordered set to create a poisoned ordered set, constructing a list identifying one or more invalid transactions in the poisoned ordered set and encrypting the list to create an encrypted list of invalid transactions, and sending a first message including the poisoned ordered set and the encrypted list of invalid transactions to other mining nodes while hashing the first block header.

[0008] In some implementations, the method may further include the first mining node finding a proof of work for the first block header and, as a result, transmitting a decryption key for the encrypted list of invalid transactions.

[0009] In some implementations, including the one or more invalid transactions includes inserting the one or more invalid transactions into the first ordered set of transactions.

[0010] In some implementations, the step of admitting the one or more invalid transactions includes, for each invalid transaction in the one or more invalid transactions, replacing a respective valid transaction in the first ordered set. In some cases, the encrypted list of invalid transactions further includes a respective valid transaction. In some cases, the method may further include, at another mining node, constructing a first candidate block by decrypting the encrypted list of invalid transactions, and replacing the one or more invalid transactions with a respective valid transaction in the poisoned ordered set to reconstruct the first ordered set and generate the first candidate block.

[0011] In some implementations, the one or more invalid transactions may include transactions that violate at least one validity criterion defined by a blockchain protocol for the blockchain network.

[0012] In some implementations, the method may further include creating, at the first mining node, at least one of the one or more invalid transactions.

[0013] In some implementations, the method may further include selecting, at the first mining node, the invalid transaction received from another mining node as one of the one or more invalid transactions.

[0014] In some implementations, the method may further include the first mining node finding a proof of work for the first block header and, as a result, transmitting the proof of work and a decryption key for the encrypted list of invalid transactions, where the proof of work includes the coinbase transaction from the first candidate block and the nonce and timestamp from the first block header.

[0015] In some implementations, the method may further include receiving a second message identifying transactions and their order in a second poisoned ordered set derived from a second candidate block being mined by the second mining node while hashing the first block header, and receiving a second encrypted list, the second encrypted list identifying invalid transactions in the second poisoned ordered set. In some cases, the method further includes validating the transactions in the second poisoned ordered set and identifying a set of one or more invalid transactions in the second poisoned ordered set. In some examples, the method may then include receiving from the second mining node a coinbase transaction, a decryption key, and second block header information indicating successful completion of the proof of work for the second candidate block, where the second block header information includes at least a timestamp and a nonce; decrypting the second encrypted list using the decryption key; determining that the second encrypted list identifies the same invalid transactions as in the set of one or more invalid transactions; assembling a second block header based on the coinbase transaction, the second block header information, and the second poisoned ordered set modified to replace the one or more invalid transactions in the second poisoned ordered set; and validating the second candidate block by hashing the second block header to validate the proof of work.

[0016] 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 a memory, one or more processors, and computer-executable instructions that, when executed, cause the processor to perform one or more of the methods described herein.

[0017] In yet another aspect, a computer-readable medium may be provided that stores processor-executable instructions for implementing a first mining node for mining blocks on a blockchain network, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processor to perform at least one of the methods described herein.

[0018] Other exemplary embodiments of the present disclosure will become apparent to those of ordinary skill in the art from the following detailed description considered in conjunction with the drawings.

[0019] In this application, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, but not necessarily excluding additional elements.

[0020] As used in this application, the phrase "at least one of ... or ..." is intended to cover any one or more of the listed elements, including only any one of the listed elements, any subcombination, or all of the elements, but not necessarily excluding any additional elements, and not necessarily requiring all of the elements.

[0021] This application refers to hashing or hash functions, which is intended to include any one of several cryptographic hash functions that, when applied to any set of data or "message," deterministically produces a unique fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, etc. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2. Any reference below 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.

[0022] As used herein, the term "blockchain" is understood to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and illustration, reference may be made herein to Bitcoin as exemplified by the Bitcoin SV protocol, but 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.

[0023] 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 the blocks are chained together to create a permanent, immutable record of all transactions that have been written to the blockchain since inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify how and by whom the output of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0024] A blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and running software implementing the applicable blockchain protocol. The nodes validate transactions and propagate them to other nodes in the network. Specialized 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 any other miner in the network succeeds in solving the Proof of Work for the respective block. In the Bitcoin example, the POW involves hashing the block header, including the nonce, until the result falls below a threshold set by a difficulty parameter. The nonce is repeatedly incremented and the hashing is repeated until the result falls below the threshold or the miner receives notification that another miner has succeeded. Variations of the mining process are familiar to those skilled in the art.

[0025] A typical block contains two data structures: a block header and a transaction. FIG. 1 shows an example block structure 100 from the Bitcoin protocol in a schematic way. 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 difficulty parameter 114, and a nonce 116. The hash value 108 of the previous block chains this block to the previous block in the chain, thereby resulting in a "blockchain" structure that links successive blocks to each other through cryptographic hashes. The Merkle root 110 refers to a Merkle tree structure based on all transactions contained in the block. The nonce 116 is an arbitrary value that a mining node can repeatedly increment or decrement to change the contents of the block header 102 so as to result in different hash results when mining.

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

[0027] If a mining node succeeds in finding a block header that results in a hash result below the threshold, it subsequently notifies other nodes using an updated inventory message that includes the successful hash result value, after which the other nodes can request a copy of the new block and independently verify its validity.

[0028] Fast Block Propagation The blockchain ecosystem is maturing to accommodate a significant increase in the volume of transactions and the associated increase in the size of blocks to provide improved usability. As blocks become larger, potentially exceeding 128MB, it takes time to propagate a new successfully mined block to other nodes throughout the network. Propagation delays are costly. First, miners who are unaware that a successfully mined block has been created will continue to try to mine their own candidate block in vain effort if the new block turns out to be valid. Second, propagation and validation delays can increase the likelihood of (temporary) forks and orphan blocks.

[0029] It will be appreciated that in many blockchain protocols, miners do not send a full copy of the block, but rather send the hash result in an inventory message. The receiving mining node determines that it has not seen this purported 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, the transaction count field from the payload, and an ordered list of the transactions contained in the block. The ordered list may include a set of complete transaction IDs (TXIDs) for the transactions. The TXIDs may be a fixed-length hash of the transactions in some embodiments. The TXIDs may be, for example, a 256-bit (32-byte) number obtained by hashing the transactions using SHA-256. The receiving node may reassemble the complete block by taking the identified transactions from the mempool by their TXIDs.

[0030] Nevertheless, as modern block sizes grow to 128MB or more, the size of the data to be transmitted can still be significant if the transaction count is large. For example, a block containing 500,000 transactions would have an ordered list of TXIDs that is 16MB.

[0031] 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 those candidate blocks. In this way, 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 send information from the block header, and possibly the coinbase transaction, to ensure that all other nodes can assemble and validate a complete new block. This data can be only a few hundred bytes. This increases the speed at which successful new blocks are propagated throughout the network.

[0032] It will be appreciated that unconfirmed transactions are propagated and validated through a network of nodes before being confirmed by inclusion in a valid block. While in this unconfirmed state, the unconfirmed transactions are held in memory. This memory may be referred to as a "mem pool." Each miner may, in some implementations, maintain its own copy of the mem pool from which it can select a set of transactions for assembling a candidate block. In some alternative architectures, the mem pool may be implemented as a distributed mem pool across several nodes. In some architectures, the blockchain network may employ specialized nodes to manage the mem pool and provide transactions to mining nodes for inclusion in candidate blocks. The present application contemplates the use of the described methods and devices with any such variations in blockchain network architecture. For simplicity of explanation, it is assumed herein that each mining node maintains its own mem pool of unconfirmed transactions.

[0033] A mining node uses the mempool as a source of new transactions for constructing candidate blocks. Because each block contains an ordered list of transactions, a mining node may further use the mempool when validating a new block from another miner. The ordered list may identify transactions by a unique transaction identifier, such as a TXID. Thus, a receiving mining node takes transactions from the ordered list, validates the block against block-level criteria, and validates the transactions against transaction-level criteria. In this way, miners prevent double-spend and other attacks.

[0034] To illustrate aspects of the present application, reference is now made to FIG. 2, which 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 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 specialized processing units 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 the 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 network connectivity and transmitting and receiving messages according to an applicable network protocol.

[0035] The method 200 includes, at operation 202, selecting a set of transactions from a mempool of unconfirmed transactions to build a candidate block. The selection may be based on the age of the transactions, the fees paid for mining 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, including setting an initial value of a nonce in the header.

[0036] In operation 204, the mining node begins repeated hashing of block headers and incrementing of nonce as part of a search for a POW that satisfies the difficulty setting. 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 indicated by operation 206. The mining node also receives messages from other mining nodes, as indicated by operation 208, while operation 204 is in progress, that contain information about the respective ordered lists of transactions in the candidate block being worked on by those mining nodes. Although operations 204, 206, and 208 are shown in sequence, it will be understood that they are generally performed in parallel. The received information about the respective ordered lists of transactions from other miners is stored locally by the mining node. The mining node may store the information in a table or other data structure.

[0037] 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 it finds a POW, the mining node sends some header information to other mining nodes to propagate the block details, in operation 214. Notably, it is not necessary to send a payload; however, it may send a coinbase transaction.

[0038] When a mining node receives header information from another mining node, it assembles a new block based on the stored ordered list of transactions for that mining node in operation 216. When a coinbase transaction is received, it is added to the block, and the mining node may build 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 invalid, discard the new block and continue searching for its own POW. Note that there may be certain validity checks that, if unsuccessful, may prompt the mining node to take other actions, 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 then returns to operation 202, constructs a new candidate block, and begins the search anew.

[0039] It will be appreciated that the described method of pre-distributing candidate block information so that each miner knows the ordered list of transactions for each other miner ensures that the amount of information that needs to be propagated after the POW is found is minimized. This ensures that mining nodes have the necessary information to validate a new block as soon as possible, thereby reducing time wasted searching for a POW when another miner has already succeeded. Mining nodes have every intention to propagate and validate a new block as quickly as possible so that they can move on to searching for the next block. Potential delays due to network latency are less of an issue when pre-distributing an ordered list of transactions during the approximately 10 minute period between successive blocks.

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

[0041] In another example implementation, the messaging protocol may provide for adding transactions to an ordered list for miners, removing or deleting transactions from an ordered list, replacing a transaction with another transaction, or reordering transactions. Typically, miners are likely to only use "add" messages that specify an ordered list of transactions. However, there are cases where a miner may wish to remove and replace transactions. For example, later received information may indicate a potential double-spend with one of the transactions, or some other potential problem with its validity. As another example, a miner may wish to cycle all increments of the nonce and reorder or otherwise adjust transactions in order to change the Merkle root and thereby change the header to continue mining the block. The exact format of the message structure may vary depending on the implementation.

[0042] Further compression of block-propagating messages may be achieved by shortening the TXID string. In some examples, the TXID is a 32-byte string. In some cases, however, a compressed TXID may be used that relies on transmitting only a portion of the TXID. In one example, only the first 8 bytes are transmitted.

[0043] While the first 8 bytes of a TXID are not guaranteed to uniquely identify a transaction, the chances of two TXIDs colliding within a single message or in general are small. Assuming that the output of SHA256 is a pseudorandom 256-bit string, the exact chance of a collision between two random TXIDs, i.e. the chance that the first 4 bytes of any two TXIDs will be the same, is:

number

[0044] Where TXID i [0:n] is "TXID i Furthermore, the probability that a message containing N compressed TXIDs contains one or more collisions can be expressed as:

number

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

number

[0046] This probability is very small, and even if a collision does occur, the message receiver may simply request the same message in uncompressed form. Alternatively, the sending mining node may first check to ensure that the ordered set of compressed TXIDs does not contain a collision before sending, and if a collision is 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 format.

[0047] According to the process described herein, each miner participating in the blockchain network may receive messages from each other miner specifying an ordered list of transactions to be included in the other miner's candidate block. To keep track of 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 mem pool and each column is associated with a miner in the network. Then, for each miner, order information may be stored in a cell of the table indicating the order in which the miner placed transactions in its candidate block. It will be understood that not all transactions will have an order value because not all transactions will be included in all candidate blocks. The following table shows one simplified example of a miner ordering data table: [Table 1]

[0048] In this simplified exemplary 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 a transaction in the order with another, or to remove a transaction from the ordered list, which can result in an adjustment to the ordering of the remaining transactions in that ordered list.

[0049] 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 builds a Merkle tree based on the TXID and the order specified for miner C. Miner A hashes the block header and verifies the hash value. If the block is verified, miner A builds a complete block with the transaction data in the specified order, adds it to the blockchain, and continues mining by building a new candidate block.

[0050] 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 complete block header. The receiving miner may add missing fields such as the version, prev_block hash, the miner-computed Merkle root, and the difficulty setting. It can then validate the reconstructed header by hashing it and comparing it to the received hash value.

[0051] In some example implementations, messaging from miners indicating their ordered lists of transactions for their respective candidate blocks is sent automatically once the candidate blocks are constructed. In some other example implementations, the ordered list information is provided in response to a request from another miner.

[0052] In some implementations, a template identifier TmID may be defined. The template identifier is specific to the miner and block level, so it can effectively refer to a specific candidate block, i.e., a specific ordered list of transactions. Any messaging from the miner that pertains to that 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 a hash of the miner identifier (Miner ID) and the prev_block field in the block header, i.e., the previous hash of the block, as follows:

number

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

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

[0055] 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, an initial authentication operation occurs when a miner connects to the network, resulting in a unique miner ID being associated with that mining node. The authentication operation may include a handshaking operation in which each miner provides a public key and a digital signature. The authentication is tied to verifying the digital signature. In some cases, the miner ID may be based on a public key, a digital signature, or some combination thereof.

[0056] In some cases, the handshaking 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 messaging, such as messaging 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.

[0057] In some embodiments, mining nodes perform an authentication procedure after connecting to the network and opening peer-to-peer connections with each other. The authentication procedure may involve sending an authentication challenge message and receiving an authentication response. Failure to receive a valid authentication response will cause a mining node to close or drop connections to other mining nodes. In some cases, mining nodes may have different endpoints for authenticated connections than normal public network connections.

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

[0059] 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 pseudorandom process. The responding mining node then signs the concatenated nonce and the message using the private key of a previously 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 a miner ID used to communicate on the blockchain network. The requesting mining node may have a whitelist or other record of miner IDs (public keys) for mining nodes connected to the blockchain network.

[0060] Once the responding mining node has signed 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.

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

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

number

[0063] In one example, the format of the authentication response message may take the following form:

number

[0064] In some implementations, the public key is an ECDSA key on the secp256k1 elliptic curve. The signature may be a signature over the concatenation of the nonce value and the contents of the message field from the authentication challenge message. The concatenation may be (nonce|message) or (message|nonce), depending on the implementation.

[0065] Reference is now made to Figures 3A-I, which diagrammatically illustrate exemplary operating states and messaging flows between two miners according to one implementation of the present application.

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

[0067] As illustrated by Fig. 3B, each of the miners 302, 304 selects a set of transactions from their respective mempools 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 transactions from the mempools they wish and group them in the order they wish, the first ordered set and the second ordered set 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 will result in the hash of the block header below a threshold set by the 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 FIG. 3D shows, the first miner 302 may send an “add” message 312 to the second miner 304 to provide a first ordered list of transactions from the first candidate block 308. From that information, the second miner 304 may build a template 314 of the first candidate block 308. In some example implementations, the template 314 may be a first ordered list of transactions in TXID format. In some example implementations, the template 314 may be a table, examples of which are provided above. In still other example implementations, the template 314 may be a copy of the complete candidate block, except for certain unavailable header fields, including the complete transaction data.

[0070] In a similar manner, the second miner 304 may send an "add" message 316 to the first miner 302 containing a second ordered list of transactions from the second candidate block 310, as shown in Figure 3E. From that data, the first miner 302 builds a template 318 of the second candidate block 310. Now, each miner has its own candidate block that it continues 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 requirement. Thus, the first candidate block 308 with the most recently tested nonce in the header becomes a valid block. Then, FIG. 3G and FIG. 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 further 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 even if the second miner 304 can calculate it so that the second miner 304 can double-check its Merkle root calculation. In some cases, the first miner 302 sends the complete block header of the new block 322 to the second miner 304. The first miner 302 may also send a hash value obtained by hashing the block header to the second miner 304 so that the second miner 304 can verify that the hash is not only below the difficulty threshold but also matches the hash that the first miner 302 claims to have found. The hash value may be sent in the coinbase transaction message 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. If the merkle_root field was included in the block header information message 324, it can verify from the calculation that the field is correct. If not, it can complete the merkle_root field, as well as any other missing fields, such as the version, prev_block value, and bit fields, to assemble 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 can then validate the new block by hashing the assembled block header 326.

[0073] Assuming the assembled block at the second miner 304 is validated, 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 info message 324, it will be appreciated that in some implementations the block header info 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 appreciate that in some cases, blocks may be mined sooner than expected. In Bitcoin, for example, difficulty settings ensure that a valid block is found approximately every 10 minutes, but the timing is not certain. It is possible to find a valid block much sooner. Additionally, some messages propagating transactions or transaction ordering information may experience network delays as they propagate through the network.

[0076] Thus, there is a small but likely possibility 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 transactions for the successful miner. When that miner tries to validate the Merkle root field of the new block header, a mismatch is found and the block is considered invalid. One option is for the miner to consider 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 roofs, i.e., an ordered list of TXIDs. Upon receiving the leaf transmission, the miner may determine where the error in the Merkle root calculation occurred. If the cause is an incorrect or incomplete ordering of transactions, the miner may update the ordering and validate a new block. If the cause is a missing transaction, the miner may request a new transaction and continue the validation process. Note that in some embodiments, if a miner that receives an ordered list of transactions for another miner's candidate block finds that it does not have one of the TXIDs in its mempool, the missing transaction may be detected before the block is successfully discovered. In that case, the receiving miner can request a copy of that transaction and update its mempool.

[0077] In some implementations, one or more miners may wish to maintain some degree of secrecy over their transaction selection and ordering. In such implementations, a miner may be able to encrypt the ordered list of transactions as it distributes 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 to enable the receiving miner to decrypt the ordered list of transactions and validate the new block.

[0078] The following table describes one set of example messages for one example implementation of messaging for propagation of ordered transaction lists among miners. [Table 2]

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

[0080] Presumably, the receiving miner has an applicable transaction in its mempool corresponding to the TXID, but if the transaction is missing, it can request a copy of the missing transaction.

[0081] It will be appreciated that the example messaging protocol described above is one example implementation.

[0082] Block propagation with poisoned transactions As a result of early propagation of candidate block details from one miner to another, another miner may rely on the validation work of one miner. That is, it is assumed that each mining node validates transactions before adding them to the mempool and builds a candidate block from those validated transactions. If a first mining node builds a candidate block from validated transactions and then sends an ordered set of block header data and transaction identifiers to a second mining node, that second mining node can conceivably choose to rely on the fact that the underlying transactions are valid because the first mining node has already done its validation work or the first mining node has not included them in the candidate block it is mining. This allows the second mining node to avoid the computational cost of the validation work. If enough mining nodes start piggybacking on the validation work of other mining nodes, the consensus-based security of the blockchain network may be compromised.

[0083] Thus, in one aspect, the present application provides a method and system for block propagation structured to prevent such reliance. In particular, a mining node that creates an ordered set of transactions for a candidate block may include one or more invalid transactions in the ordered set that is propagated to other mining nodes. Upon successful mining of a candidate block, the mining node reveals which transactions in the ordered set are invalid.

[0084] In this way, the second mining node cannot rely on the propagated block information from the first mining node in identifying validated transactions because the information has been seeded with at least one invalid transaction. An invalid transaction may be referred to as a "poisoned" transaction, and a set of ordered transactions that has been modified to include an invalid or poisoned transaction may be referred to as a "poisoned" ordered set.

[0085] The first mining node does not mine a candidate block containing a poisoned ordered set. Instead, it builds a candidate block containing an ordered set of validated transactions, which is the block header of the valid candidate block that the first mining node attempts to mine by iterating through the nonce value and modifying the timestamp and / or coinbase transaction data. However, the block data forwarded to other mining nodes during block propagation before the proof of work is the poisoned ordered set information.

[0086] In one implementation, the first mining node may reveal one or more indexes of invalid transactions by sending its one or more index data along with the POW solution data, e.g., the solution's nonce, timestamp, and coinbase data, after successfully mining a block. In another implementation, the first mining node may prove prior knowledge of invalid transactions by providing a list of one or more indexes of invalid transactions in advance. The list may be encrypted to prevent a receiving mining node from immediately repairing the poisoned ordered set, and the first mining node may provide a decryption key to decrypt the encrypted list if the first mining node finds a POW solution for the candidate block.

[0087] An invalid transaction that is added to the poisoned ordered set may be a transaction created by the mining node that is constructed to violate at least one validation criterion. In some cases, the invalid transaction may be one that the mining node received from another mining node in the other mining node's poisoned ordered set. By reusing invalid transactions used by other mining nodes, the mining node avoids recipients identifying an invalid transaction simply because it was seen only by that mining node as a single source.

[0088] The encrypted list may identify invalid transactions in the poisoned ordered set by their index in the set. In some implementations, the encrypted list further provides a replacement valid transaction for each invalid transaction. By replacing invalid transactions with valid transactions, the poisoned ordered set is restored to an ordered set that matches the candidate block. The receiving node may then fully build the Merkle tree and validate the POW solution. By providing replacement transactions rather than simply removing invalid transactions, the structure of the Merkle tree is maintained so that at least a portion of the validation and Merkle hashing work can be done by the receiving node prior to receiving the POW solution.

[0089] Reference is now made to FIG. 4, which illustrates in flow chart form one exemplary method 400 for block propagation in a blockchain network. The method 400 in this example is performed by a mining node. A mining node may be a network-connected computing device configured to mine blocks according to a managed blockchain protocol. Mining a block may include building a candidate block and then hashing the candidate block header until a POW solution is found or notification is received that another mining node has successfully mined its own candidate block. The method 400 may be implemented using processor-executable instructions stored in a memory that, when executed by a processor, causes the processor to perform the operations described below.

[0090] In operation 402, the mining node constructs a candidate block that includes the validated transactions. The transactions may be validated transactions stored in the mining node's mempool of unconfirmed but validated transactions. It may also begin mining the candidate block as soon as it is constructed, as indicated by operation 404. Mining includes hashing the candidate block header, determining if the hash result is below a difficulty threshold, and if not, iterating over the nonce value in the header or modifying the contents of the header by updating the timestamp or modifying the coinbase transaction, and then repeating. It will be appreciated that the candidate block includes an ordered set of transactions.

[0091] In operation 406, the mining node replaces one or more of the valid transactions in the copy of the ordered set of transactions with one or more invalid transactions to create a poisoned ordered set of transactions. The invalid transactions may be created by the mining node or may be copied from invalid transactions submitted by another mining node. The mining node then creates a list of indexes that identify the invalid transactions in the poisoned ordered set of transactions, as shown in operation 408.

[0092] In this example, the encrypted list may also include replacement data. The replacement data may be the TXID of the valid transaction that the invalid transaction replaced. In some cases, the replacement data may be the valid transaction itself. The replacement data allows the recipient to "repair" the poisoned ordered set of transactions by removing the invalid transactions and replacing them with their respective valid transactions to reconstruct the correct ordered set of transactions that are the basis of the candidate block. The list of indexes of invalid transactions is encrypted by the mining node.

[0093] In some other instances, the encrypted list does not include the alternative data, and the alternative data is provided by the mining node along with the POW solution if the mining node manages to find a POW solution.

[0094] The mining node propagates the poisoned ordered set and the encrypted list of transactions to other mining nodes in operation 410. The mining node may employ a messaging protocol, such as that described above, to signal transactions to be added, removed, or replaced in the poisoned ordered set.

[0095] After signaling its poisoned ordered set to other mining nodes, the mining node continues to search for a POW solution for the candidate block, as indicated by operation 412. It also monitors for notification that another mining node has found a POW solution for its own candidate block, as indicated by operation 414. If another node finds a valid block, the mining node returns to operation 402, builds a new candidate block, and tries again. If the mining node finds a POW solution, it propagates the solution and the decryption key for the encrypted list in operation 416. Other nodes on the blockchain network can then decrypt the encrypted list, repair the ordered set of transactions to build the candidate block, finish validating the candidate block, and further propagate the solution and the decryption key.

[0096] 5 illustrates an example method 500 of validating a block by a node in a blockchain network. The method 500 in this example may be performed by a mining node. A mining node may be a network-connected computing device configured to mine blocks according to a managed blockchain protocol. The method 500 may be implemented using processor-executable instructions stored in a memory that, when executed by a processor, causes the processor to perform the operations described below.

[0097] The method 500 begins at operation 502 with receiving candidate block template data and an encrypted list from a mining node. The candidate block template data may be data detailing an ordered set of transactions. In this example, the mining node is configured to send a "poisoned" ordered set of transactions, meaning that some of the transactions are invalid transactions. The candidate block template data may be received based on a message protocol such as the one described above, in which transactions may be added to, removed from, or replaced in a candidate block template associated with a particular mining node. The encrypted list, when decrypted, identifies the poisoned transactions in the candidate block template data.

[0098] In operation 504, the node may determine whether it has a copy of the identified transaction. The copy of the transaction may possibly be included in the message itself or may be obtained from the node's local mempool. In some cases, the node may not have a copy of the transaction in the candidate block template and may request a copy of any missing transactions from the mining node in operation 506.

[0099] In operation 508, the node validates any transactions that have not yet been validated. If any are identified as invalid, the node may flag them or otherwise record them as invalid, as indicated by operation 510. If the mining node is using a poisoned transaction block propagation protocol (which may be signaled in messaging associated with the propagation of the candidate block template), the node is notified that invalid transactions may have been intentionally placed in the ordered set. In addition, the node may have received an encrypted list that implicitly signals that there is at least one invalid transaction in the ordered set.

[0100] In this example, in operation 512, the node receives a notification that the mining node has found a POW solution. The notification may include the POW solution, including the nonce used, a timestamp, and any other data the node needs to reconstruct and validate the candidate block. The notification further includes a decryption key to allow the node to decrypt the encrypted list, which it does in operation 514. In some example implementations, the notification further includes substitution data indicating which valid transaction should be used in place of the invalid transaction. In some cases, the substitution data is included in the encrypted list and is revealed when decrypted.

[0101] The decoded list reveals the index of the invalid transaction. The node also has alternative data from the decoded list or from the notification of the POW solution. In operation 516, the node determines whether the index identified in the decoded list matches a transaction that the node identified as invalid in operations 508 and 510. If there is no match, in operation 518, the block is rejected as invalid. That is, if the node identifies an invalid transaction in the candidate block template data and that same transaction is not identified as invalid in the decoded list, the block contains an invalid transaction and should be rejected. In some cases, if the decoded list identifies as invalid a transaction that the node determined to be valid, a replacement may be made and the block may still be accepted, provided it meets all validation criteria.

[0102] At operation 520, the node replaces the invalid transaction with a valid transaction based on the substitution data in the decrypted list, and then completes the validation of the block at operation 522. In particular, with the valid transaction inserted in place of the invalid transaction, the node may complete building those portions of the Merkle tree, find the Merkle root, complete the block header, hash the header, and verify that the hash is below the difficulty setting.

[0103] In some implementations, the poisoned transaction index in the decrypted list is an array of varint indexes. The value 0 may be reserved as a dummy entry that a node can ignore. A mining node may insert one or more zero-valued entries to obfuscate the number of poisoned transactions in a block by padding the data.

[0104] In some embodiments, the alternative data is transmitted along with the POW solution and decryption key rather than being included in an encrypted list.

[0105] One illustrative example of a message structure for transmitting the POW solution and the decryption key is shown below:

number

[0106] In the above example, the template_id_len, template_id, and sequence_no fields identify the template to which the message pertains and ensure proper sequencing between messages related to the template. The aes_128_encryption_key field stores a decryption key to enable decryption of the encrypted list. In some cases, the decryption key may be used to decrypt encrypted AOL data.

[0107] The block_header and coinbase_tx fields store the data needed to complete the candidate block. The aol field provides any additional transactions to be added to the template, although this field may be empty.

[0108] The poison_tx_replacements field contains replacement data, i.e., transaction data to replace the invalid transactions revealed in the encrypted list.

[0109] It will be appreciated that the above message structures are examples. Other message structures may include additional, alternative, or fewer fields, depending on the implementation.

[0110] It will also be understood that some or all of the above-described operations of the various above-described exemplary methods may be performed in orders other than those illustrated and / or may be performed simultaneously without changing the overall operation of the methods.

[0111] Reference is now made to Figure 6, where a simplified mining node 600 is illustrated in block diagram form, according to one example of the present application. The mining node 600 includes a processor 602, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The mining node 600 may further include a memory 604, which may include persistent and non-persistent memory for storing values, variables, and in some cases processor-executable program instructions, and a network interface 606.

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

[0113] The various embodiments presented above are merely examples and are not meant to limit the scope of the present application in any way. Variations of the innovations described herein will be apparent to those skilled in the art, and such variations are within the intended scope of the present application. In particular, features from one or more of the above exemplary embodiments may be selected to create alternative exemplary embodiments including subcombinations of features that may not be explicitly described above. In addition, features from one or more of the above exemplary embodiments may be selected and combined to create alternative exemplary embodiments including combinations of features that may not be explicitly described 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 in this specification and claims is intended to cover and encompass all appropriate modifications in technology.

Claims

1. 1. A computer-implemented method for block validation in a blockchain network, comprising: receiving, at a first mining node, a message providing an ordered set of transactions in a candidate block being mined by a second mining node, and receiving an encrypted list associated with the ordered set of transactions; receiving a block solution from the second mining node, the block solution including a decryption key, the block solution indicating successful completion of a proof of work for the candidate block; decrypting the encrypted list using the decryption key to obtain a decrypted list, the decrypted list identifying one or more invalid transactions within the ordered set of transactions; modifying the ordered set to remove the one or more invalid transactions; constructing a block header using the block solution and the ordered set modified to remove the one or more invalid transactions; validating the block solution by hashing the block header to validate the proof of work; The method includes:

2. 2. The method of claim 1, wherein modifying the ordered set to remove the one or more invalid transactions comprises replacing the one or more invalid transactions with one or more respective valid transactions.

3. The method of claim 2 , wherein the decoded list includes the one or more respective valid transactions.

4. 3. The method of claim 2, wherein receiving the block solution comprises receiving data identifying the one or more respective valid transactions.

5. 5. The method of claim 1, wherein receiving the block solution comprises receiving a coinbase transaction and block header information, the block header information including at least a timestamp and a nonce.

6. 6. The method of claim 1, wherein the one or more invalid transactions include transactions that violate at least one validity criterion defined by a blockchain protocol for the blockchain network.

7. 7. The method of claim 1, wherein the step of receiving the message occurs while the first mining node is hashing its own candidate block header for a proof of work.

8. 8. The method according to claim 1, further comprising: at the first mining node, while hashing its own candidate block header, validating the ordered set of transactions obtained in the message and identifying the one or more invalid transactions, and wherein the decrypting step comprises verifying that the one or more invalid transactions identified by the first mining node in the ordered set match the one or more invalid transactions in the decrypted list.

9. 9. The method of claim 8, further comprising determining that the first mining node is using a poisoned transaction block propagation protocol.

10. The method of claim 1 , wherein the message includes a list of TxIDs specifying an ordered set of the transactions.

11. The method of claim 1 , wherein the decoded list includes an index of the one or more invalid transactions.

12. 1. A computing device implementing a mining node for validating blocks on a blockchain network, comprising: one or more processors; Memory, computer executable instructions stored in said memory; wherein the computer-executable instructions, when executed by the one or more processors, cause the processors to perform the method of any one of claims 1 to 11. Computing device.

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

Images