Block propagation of poisoned transactions in a blockchain network

Abstract

Methods and apparatus for propagating blocks in a blockchain network. At a first mining node, while hashing a first block header of a first candidate block, the first mining node sends a first message to other mining nodes specifying a transaction and its order in a first ordered set of transactions included in the first candidate block. To prevent other nodes from relying on the first mining node having validated the transactions in the candidate block, the first mining node develops the first ordered set with one or more invalid transactions to create a poisoned ordered set and provides an encrypted list identifying the invalid transactions. Once a proof-of-work for the candidate block is found, the first mining node provides a decryption key to decrypt the encrypted list and identify the invalid transactions. The first mining node can also provide replacement transactions for the invalid transactions.

Description

Technical Field

[0001] This disclosure relates to blockchain networks, and more specifically to the propagation of blocks among mining nodes. Background Technology

[0002] In a proof-of-work blockchain system, when a valid block is found, the mining node attempts to quickly communicate its success to all other mining nodes. This involves propagating information about the block to all mining nodes across the blockchain network. In some cases, this might involve sending the complete block data. In others, it might involve sending the block header and a list of transactions. The receiving mining node verifies the new block by hashing the header and confirming that it matches the hash provided by the successful mining node.

[0003] As block size and transaction volume increase, block propagation delays exacerbate the problems of temporary forks and orphaned blocks. These situations are costly for both mining nodes and the system as a whole. Solutions to block propagation delays should be developed to prevent the potential violation of consensus rules. Summary of the Invention

[0004] In one aspect, a computer-implemented method for 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, the first message specifying transactions and their order in a first ordered set contained in the first candidate block; and receiving a second message identifying transactions and their order in a second ordered set contained in a second candidate block mined by a second mining node.

[0005] On the other hand, a method for block propagation in a blockchain network is described. This method may include constructing a first candidate block at a first mining node, the first candidate block containing 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 within the poisoned ordered set, and encrypting the list to produce an encrypted list of invalid transactions; and simultaneously hashing the first block header while sending a first message to other mining nodes, the first message containing the poisoned ordered set and the encrypted list of invalid transactions.

[0006] In some implementations, the method may also include the first mining node finding a proof-of-work for the first block header and thus sending a decryption key for an encrypted list of invalid transactions.

[0007] In some implementations, placing one or more invalid transactions involves inserting one or more invalid transactions into a first ordered set of transactions.

[0008] In some implementations, placing one or more invalid transactions includes, for each invalid transaction in the one or more invalid transactions, replacing the corresponding valid transaction in the first ordered set. In some cases, the encrypted list of invalid transactions also includes the corresponding valid transactions. 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, replacing one or more invalid transactions in the poisoned ordered set with the corresponding valid transactions, in order to reconstruct the first ordered set and generate the first candidate block.

[0009] In some implementations, one or more invalid transactions may include transactions that violate at least one validity criterion stipulated by the blockchain protocol of the blockchain network.

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

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

[0012] In some implementations, the method may further include a first mining node finding a proof of work for the first block header and thus sending the proof of work and a decryption key for an encrypted list of invalid transactions, wherein the proof of work includes raw transactions from the first candidate block, and a nonce and timestamp from the first block header.

[0013] 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 mined by a second mining node, while hashing the first block header; and receiving a second encrypted list identifying invalid transactions in the second poisoned ordered set. In some cases, the method further includes verifying transactions in the second poisoned ordered set and a set identifying one or more invalid transactions in the second poisoned ordered set. In some examples, the method may then further include receiving the original transaction, decryption key, and second block header information from a second mining node indicating successful completion of proof-of-work with respect to a second candidate block, wherein the second block header information includes at least a timestamp and a random number; decrypting the second encrypted list using the decryption key; determining that the second encrypted list identifies invalid transactions identical to invalid transactions in the set of one or more invalid transactions; assembling a second block header based on the original transaction, the second block header information, and the second poisoned ordered set, which is modified to replace one or more invalid transactions in the second poisoned ordered set; and verifying the second candidate block by hashing the second block header to verify the proof-of-work.

[0014] On the other hand, a computing device may be provided for implementing 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 processor to perform one or more of the methods described herein.

[0015] In another aspect, a computer-readable medium may be provided storing processor-executable instructions for implementing a first mining node for mining blocks on a blockchain, the processor-executable instructions including, when executed by one or more processors, instructions that cause the processor to perform at least one method described herein. Attached Figure Description

[0016] Reference will now be made to the accompanying drawings by way of example, which illustrate exemplary embodiments of this application, wherein:

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

[0018] Figure 2 A flowchart illustrating an example method for block propagation is shown;

[0019] Figures 3A-3I The sequence of messages and operations in an example implementation of block propagation according to this application is illustrated schematically;

[0020] Figure 4 An example method of block propagation in a blockchain network is illustrated in the form of a flowchart;

[0021] Figure 5 An example method for verifying blocks in a blockchain network is illustrated in the form of a flowchart; and

[0022] Figure 6 A simplified example of a mining node is shown in the form of a block diagram.

[0023] The same reference numerals are used in the accompanying drawings to denote the same elements and features. Detailed Implementation

[0024] Other exemplary embodiments of this disclosure will be apparent to those skilled in the art upon review of the following detailed description in conjunction with the accompanying drawings.

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

[0026] In this application, the phrase “...or at least one of ...” is intended to cover any one or more of the listed elements, including any one of the individually listed elements, any sub-combination, or all elements, rather than excluding any additional elements or requiring all elements.

[0027] This application relates to hashing or hash functions, and aims to include any of a plurality of cryptographic hash functions that, when applied to any set of data or "messages," deterministically produce a unique, fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, or equivalent. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2. The following reference to a mining node hashing a block or candidate block should be understood as meaning applying a cryptographic hash function to the header of a candidate block.

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

[0029] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets among participants in the blockchain system and includes at least one input and at least one output. Each block header contains the hash of the previous block, allowing blocks to be chained together to create a permanent, immutable record of all transactions written into the blockchain from the outset. Transactions contain applets called scripts embedded in their inputs and outputs, specifying how and by whom the transaction's outputs can be accessed. These scripts are written using a stack-based scripting language.

[0030] Blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and executing software that implements the applicable blockchain protocol. Nodes confirm transactions and propagate them to other nodes in the network. Specialized network nodes (called "mining nodes") collect a set of unconfirmed transactions (i.e., pending transactions) into a block and attempt to "mine" that block. In these examples, mining refers to solving a proof-of-work (PoW) before any other mining node in the network successfully solves it for its corresponding block. This random number is repeatedly incremented and hashed until the result is less than a threshold or until the mining node receives notification that another mining node has succeeded. Variations in the mining process are familiar to those skilled in the art.

[0031] A typical block contains two data structures: a block header and a transaction. Figure 1 An example block structure 100 is illustrated graphically. Block structure 100 includes a block header 102 and a payload 104. The block header 102 in this example includes fields for version number 106, previous block hash 108, Merkle root 110, timestamp 112, target difficulty parameter 114, and random number 116. The previous block hash 108 appends the blockchain to the previous block in the chain, thus creating a “blockchain” structure that links consecutive blocks together through cryptographic hashing. The Merkle root 110 refers to a Merkle tree structure based on all transactions contained in the block. The random number 116 is an arbitrary value; mining nodes can repeatedly increment or decrement this arbitrary value to change the content of the block header 102, thereby producing different hash results during mining.

[0032] Payload 104 includes a transaction count value 118 and a transaction list 120. In some implementations, the transaction list 120 may be a list of transaction ID numbers.

[0033] When a mining node successfully finds a block header that produces a hash result below a threshold, it notifies other nodes with an updated inventory message that includes the successful hash result value. The other nodes then request a copy of the new block and independently verify its validity.

[0034] Fast block propagation

[0035] The blockchain ecosystem is maturing to provide greater availability by significantly increasing transaction volume and, consequently, block size. As blocks become larger, exceeding 128MB in some cases, the time required to propagate successfully mined new blocks to other nodes across the network increases. This propagation delay comes at a cost. First, if the new block proves valid, mining nodes unaware of the successful block will continue to futilely attempt to mine their own candidate blocks. Second, the delay in propagation and verification can increase the likelihood of (temporary) forks and orphaned blocks.

[0036] It will be understood that in many blockchain protocols, mining nodes do not send a complete copy of the block, but instead send the hash result in an inventory message. Receiving mining nodes determine they have not seen the so-called new block and send a GETBLOCK (get block) or GETDATA (get data) message to the successful mining node. The successful mining node does not send a complete copy of the block, but instead sends the block header, a transaction count field from the payload, and an ordered list of transactions included in the block. This ordered list may include a set of complete transaction IDs (TXIDs) of the transactions. In some embodiments, the TXID can be a fixed-length hash of the transaction. For example, the TXID can be a 256-bit (32-byte) number obtained by hashing the transaction using SHA-256. The receiving node can reassemble the complete block by retrieving the identified transaction from the mempool using the identified transaction's TXID.

[0037] However, with modern block sizes growing to over 128MB, the amount of data to be transferred can still be significant if the number of transactions is large. For example, a block containing 500,000 transactions would have an ordered list of TXIDs of 16MB.

[0038] Therefore, in one aspect, this application describes a method and system for a blockchain network, in which mining nodes, while hashing their candidate blocks, provide information about their respective candidate blocks to other mining nodes. In this way, each mining node utilizes the time delay between the discovery of a successful block to provide other mining nodes with detailed information about the structure and content of the candidate blocks. By providing this information in advance, when a successful block is discovered, the successful mining node only needs to send information from the block header, and in some cases, the original transaction, to ensure that all other nodes can assemble and verify the complete new block. This data may only be a few hundred bytes. This improves the speed at which successful new blocks propagate throughout the network.

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

[0040] Mining nodes use a mempool as a source of new transactions to build candidate blocks. The mempool is also used when validating new blocks from other mining nodes, as each block contains an ordered list of transactions. This ordered list identifies transactions using unique transaction identifiers such as TXIDs. Therefore, receiving mining nodes retrieve transactions from the ordered list, validate the block against block-level criteria, and validate the transactions against transaction-level criteria. In this way, mining nodes can prevent double-spending and other attacks.

[0041] To illustrate aspects of this application, reference is now made to... Figure 2 , Figure 2An example method 200 for blockchain mining is illustrated in flowchart form. Method 200 is implemented by a mining node. The mining node may be implemented on a computing device that may include one or more processing units. As those skilled in the art will understand, the processing unit may include a dedicated processing unit with dedicated hardware designed to perform computational operations associated with blockchain mining at significant speed and efficiency. However, it may also include, or alternatively include, a general-purpose computing device. The computing device includes processor-executable software comprising processor-readable instructions that, when executed, cause one or more processing units to perform the described operations. The computing device includes memory and network connectivity to the associated hardware and software to obtain network connectivity and to send and receive messages according to applicable network protocols.

[0042] Method 200 involves selecting a set of transactions from the mempool of unconfirmed transactions in operation 202 to build candidate blocks. Selection can be based on the age of the transactions or any other factor. The transactions form an ordered list. The mining node also determines the Merkle root based on the ordered list of transactions, forming the block header, including setting an initial value for the random number in the block header.

[0043] In operation 204, the mining node begins repeatedly hashing the block header and incrementing a random number as part of a Proof-of-Work (PoW) search that satisfies the difficulty setting. While participating in the PoW search for candidate blocks for the mining node, the mining node sends information about its ordered list of transactions to other mining nodes, as indicated in operation 206. Simultaneously with operation 204, the mining node also receives messages from other mining nodes containing information about ordered lists of corresponding transactions in candidate blocks being processed by those nodes, as indicated in operation 208. It will be understood that although operations 204, 206, and 208 are shown sequentially, they generally occur in parallel. The ordered list of corresponding transactions received from other mining nodes is stored locally by the mining node. The mining node may store this information in a table or other data structure.

[0044] The search for POW continues until a mining node successfully finds it, as indicated in operation 210, or receives a notification from another mining node that has found the POW, as indicated in operation 212. If a mining node finds the POW, in operation 214, it sends some header information to other mining nodes to propagate the block details. It is worth noting that mining nodes are not required to send a payload. However, mining nodes can send the original transaction.

[0045] If a mining node receives header information from another mining node, in operation 216, the mining node assembles a new block based on a stored ordered list of transactions used by that mining node. If the original transaction is received, it is added to the block, and the mining node can build a Merkle tree to confirm the Merkle root is valid. Then, in operation 218, the mining node verifies the new block; if the new block is invalid, the mining node can discard it and continue searching its own Proof-of-Work (PoW). Note that there may be some validity checks that, if they fail, can prompt the mining node to take other actions, such as requesting additional data from successful mining nodes, which will be described later. If the block is verified, in operation 220, the block is added to the blockchain and propagated to other mining nodes. The mining node then returns to operation 202 to build new candidate blocks and restart the search.

[0046] It will be understood that the described method of pre-distributing candidate block information, which ensures that each mining node knows the ordered list of transactions of every other mining node, guarantees that only a minimal amount of information needs to be propagated after a Proof-of-Work (PoW) is found. This ensures that mining nodes have the information they need to validate new blocks as quickly as possible, thereby reducing the time wasted searching for PoW if another mining node has already succeeded. Mining nodes have a strong incentive to propagate and validate new blocks as quickly as possible so that they can continue searching for the next block. When pre-distributing the ordered list of transactions during a period of approximately ten minutes between consecutive blocks, there is less concern about potential delays due to network latency.

[0047] In one example implementation, an ordered list of transactions from candidate blocks can be conveyed to another mining node by adding sorting information to the transaction data packet. Each mining node can uniquely identify each other mining node. In one example implementation, a message uniquely identifying the mining node and the block level it is processing can be sent, and this message lists the TXIDs of the mining node's candidate blocks in sequence.

[0048] In another example implementation, the messaging protocol can provide the ability to append transactions to an ordered list of mining nodes, remove or delete transactions from the ordered list, replace transactions with another transaction, or reorder transactions. Normally, a mining node might only use an "add" message for an ordered list of specified transactions. However, there are situations where a mining node might want to remove or replace transactions. For example, subsequently received information might indicate a potential double-spending issue in the transaction or some other potential problem related to the transaction's validity. As another example, a mining node might cycle through all increments of the random number and might want to reorder or otherwise adjust transactions to change the Merkle root, thereby changing the header to continue mining blocks. The exact format of the message structure may vary depending on the implementation.

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

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

[0051]

[0052] Among them, TXID i [0:n] represents "TXID" i The first n bytes. Furthermore, the probability that a message containing N compressed TXIDs will contain one or more collisions can be represented as:

[0053]

[0054] For example, if a block contains one million transactions, resulting in a message containing one million compressed TXIDs (N = 1,000,000), then the probability of a collision is:

[0055] P(>0collisionsin1,000,000TxIDs)=0.0000000271

[0056] The probability is very small, and even if a collision occurs, the message receiver can simply request the same message in uncompressed form. Alternatively, the sending mining node can first check before sending to confirm that the ordered set of compressed TXIDs does not contain any collisions; if any collisions are detected, a message with uncompressed TXIDs is sent. Flags or other signals in the message can indicate whether the TXIDs in the payload are in compressed or uncompressed format.

[0057] According to the process described in this article, each mining node involved in the blockchain network can receive a message from each other mining node specifying an ordered list of transactions included in that other mining node's candidate blocks. To track this information, each mining node can store the ordered list in association with its corresponding mining node identity. The mining node identity can be determined by an IP address or some other unique identifier. In one example implementation, each mining node maintains a table or similar data structure, where each row is associated with one of the transactions in the mempool, and each column is associated with a mining node in the network. Order information can then be stored in the cells of the table, instructing each mining node on the order in which it arranges transactions in its candidate blocks. It will be understood that not all transactions will have an order value, as not all transactions are included in every candidate block. The following is a simplified example of a mining node ordering data table:

[0058] TXID Mining Node ID A B C D <![CDATA[TX1]]> 1 2 1 1 <![CDATA[TX2]]> 2 1 3 4 <![CDATA[TX3]]> 3 3 2 2 <![CDATA[TX4]]> 4 4 4 5 <![CDATA[TX5]]> 5 5 5 3

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

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

[0061] In some example implementations, the block header sent by a successful mining node does not contain all fields. For example, it might only contain a random number and a timestamp, along with the hash value obtained by mining node C when hashing the complete block header. The receiving mining node can add missing fields, such as version, prev_block hash, Merkle root calculated by the mining node, and difficulty setting. The receiving mining node can then verify the reconstructed header by hashing the reconstructed header and comparing it to the received hash value.

[0062] In some example implementations, once a candidate block is established, a message is automatically sent from the mining node indicating an ordered list of transactions for that candidate block. In other example implementations, the ordered list information is provided in response to a request from another mining node.

[0063] In some implementations, the template identifier TmID can be qualified. The template identifier is specific to the mining node and block level, thus effectively referring to a specific candidate block, i.e., an ordered list of specific transactions. Any messaging from a mining node related to its ordered list of transactions can include the template identifier to ensure that the receiving mining node will change the associated ordered list with the correct specific transactions. In one implementation, the template identifier can be a hash of the mining node identifier (mining node ID) and the prev_block field in the block header (i.e., the hash of the previous block):

[0064] TmID = H(previous block || mining node ID)

[0065] This associates the template identifier with the block level and a specific mining node.

[0066] Each message associated with an ordered list of transactions may include a template identifier and may also include a sequence number. The sequence number can be an unsigned integer value indicating the order of messages from one mining node relative to another. This ordering helps the message receiver uniquely determine the TXID order of a specific mining node in the event that some messages have not been received or that some messages have been received out of order.

[0067] As mentioned above, the mining node ID can be the mining node's IP address or some other unique identifier. In some embodiments, the initial authentication process can occur when the mining node connects to the network, which associates a unique mining node ID with that mining node. The authentication process may include a handshake, in which each mining node provides a public key and a digital signature. Authentication is linked to the verification of the digital signature. In some cases, the mining node ID may be based on a public key, a digital signature, or some combination thereof.

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

[0069] In some embodiments, mining nodes perform an authentication process after connecting to the network and establishing peer-to-peer connections with each other. The authentication process may involve sending authentication challenge messages and receiving authentication responses. Failure to receive a valid authentication response may cause a mining node to shut down or disconnect from that other mining node. In some cases, mining nodes may have endpoints for authenticated connections that are different from their usual public network connections.

[0070] In one example implementation, the authentication challenge message includes a request for the mining node to send a message to the responding mining node. This message is one that the responding mining node has not seen before. In some cases, the message may be random code or a string. The content of the message is not important, but the responding mining node should not have seen it before, so that it cannot reuse previously generated material.

[0071] Upon receiving an authentication challenge message, the responding mining node concatenates the received message with a random value. This random value can be generated by the responding mining node using any pseudo-random process. The responding mining node then signs the concatenated random number and message using the private key of a previously published public-private key pair. In these examples, the public-private key pair is related to the mining node's identity. In some cases, the public key can be the mining node ID used in communications on the blockchain network. The requesting mining node may have a whitelist or other record of the mining node IDs (public keys) of mining nodes connected to the blockchain network.

[0072] Once the responding mining node has signed the concatenated random number and message using its private key, it generates and sends an authentication response message. The authentication response message may include the public key (e.g., the mining node ID), the random value used, and the generated digital signature. The requesting mining node receives the authentication response message and can use its public key to verify that it is the owner of the public key and that the public key matches a key on a whitelist corresponding to that specific mining node.

[0073] The authentication response message can be sent together with the corresponding authentication challenge message so that the responding mining node can, in turn, authenticate the identity of the requesting mining node.

[0074] In one example, the authentication challenge message can be formatted as follows:

[0075] ###'authchallenge'

[0076] …

[0077] version:varint,

[0078] message_length:varint,

[0079] message:byte[]

[0080] …

[0081] In one example, the authentication response message can be formatted as follows:

[0082] ###'authresponse'

[0083] …

[0084] public_key_length: byte,

[0085] public_key:byte[],

[0086] client_nonce:byte

[32] ,

[0087] signature_length: byte,

[0088] signature:byte[]

[0089] …

[0090] In some implementations, the public key is an ECDSA key on the secp256k1 elliptic curve. The signature can be a signature on the concatenation of a random number and the content of the message field from the authentication challenge message. The concatenation can be (random number|message) or (message|random number), depending on the implementation.

[0091] Now for reference Figures 3A-3I , Figures 3A-3I An example operational state and message flow between two mining nodes according to the implementation of this application are illustrated in a graphical manner.

[0092] exist Figure 3A As can be seen in the example, the first mining node 302 (mining node A) and the second mining node 304 (mining node B) are part of a blockchain network, and an existing blockchain 306 exists. In this example, both the first mining node 302 and the second mining node 304 have locally stored copies of blockchain 306. Blockchain 306 has a certain "height" or block level.

[0093] like Figure 3BAs instructed, each of the mining nodes 302 and 304 selects a set of transactions from its corresponding memory pool to build candidate blocks. Specifically, the first mining node 302 builds a first candidate block 308 containing a first ordered set of transactions, and the second mining node 304 builds a second candidate block 310 containing a second ordered set of transactions. The first and second ordered sets may or may not contain the same transactions, and the transactions may or may not be in the same or partially the same order, because the mining nodes 302 and 304 are free to select any transactions they want from the memory pool and group the transactions in any order they want.

[0094] like Figure 3C As shown, mining nodes 302 and 304 begin mining the corresponding candidate blocks 308 and 310 to try to find a random number that will produce a hash of the block header that is below the threshold set by the difficulty.

[0095] While searching for a successful proof-of-work, mining nodes 302 and 304 exchange information about ordered sets of transactions in their respective candidate blocks 308 and 310. For example... Figure 3D As shown, the first mining node 302 can send an "add" message 312 to the second mining node 304, which provides a first ordered list of transactions from the first candidate block 308. Based on this information, the second mining node 304 can build a template 314 for the first candidate block 308. In some example implementations, template 314 can be a first ordered list of transactions in the form of TXIDs. In some example implementations, template 314 can be a table, as an example of a table is provided above. In yet another example implementation, template 314 can be a copy of the complete candidate block, excluding certain unavailable header fields, but including the complete transaction data.

[0096] In a similar manner, the second mining node 304 can send an "add" message 316 to the first mining node 302. This "add" message 316 contains a second ordered list of transactions from the second candidate block 310, such as... Figure 3E As shown. Based on this data, the first mining node 302 establishes a template 318 for the second candidate block 310. Now each mining node has its own candidate blocks that it continues to mine, as well as a template for a candidate block that is being processed by another mining node.

[0097] Figure 3F This shows that the first mining node 302 has successfully found a block header hash that meets the proof-of-work requirements. Therefore, the first candidate block 308, with the most recently tested random number in its header, becomes a valid block. Then... Figure 3G and Figure 3HThe diagram illustrates a first mining node 302 adding a new block 322 to blockchain 306 and transmitting a message containing the original transaction 320 and a message containing block header information 324. The block header information 324 includes at least a random number and a timestamp. It may or may not include other block header fields, such as the `merkle_root` field. In some cases, this may be sent as part of the block header information 324, even if it can be calculated by a second mining node 304, allowing the second mining node 304 to review its Merkle root calculation. In some cases, the first mining node 302 sends the complete block header of the new block 322 to the second mining node 304. The first mining node 302 may also send the hash value obtained by hashing the block header to the second mining node 304, allowing the second mining node 304 not only to verify that the hash is below a hardness threshold but also to verify that the hash matches a hash that the first mining node 302 claims to have found. The hash value may be sent in the original transaction message 320, in the block header information message 324, or in a separate message.

[0098] Once the second mining node 304 has the original transactions, it can complete the transaction portion of template 314 for the first candidate block, and thus compute the Merkle root. If the merkle_root field is included in the block header information message 324, the second mining node 304 can verify that the merkle_root field is accurate based on this computation. If it is not included, then the second mining node 304 can complete the merkle_root field and any other missing fields (e.g., 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 (e.g., random number and timestamp) are provided by the block header information message 324. The second mining node 304 can then verify the new block by hashing the assembled block header 326.

[0099] Assuming the block assembled at the second mining node 304 passes verification, the second mining node 304 adds the new block 322 to its copy of blockchain 306, as follows. Figure 3I As shown.

[0100] Although the above sequence illustrates sending the original transaction message 320 before the block header message 324, it will be understood that in some implementations, the block header message 324 may be sent first, or the two messages may be combined into a single message. Other variations in the order of operations or implementation details for a particular instance may be made without altering the overall functional operation of the described system and method.

[0101] Those skilled in the field of blockchain networks understand that, in some cases, blocks may be mined earlier than expected. It's possible to discover valid blocks earlier. Furthermore, some messages disseminating transaction or transaction ordering information may encounter network latency as they propagate through the network.

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

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

[0104] The following table describes an example message set for an illustrative implementation of message passing used to propagate an ordered list of transactions between mining nodes:

[0105]

[0106]

[0107] The receiving mining node modifies the candidate block template corresponding to the template identifier in the message. Messages not received in sequence for a specific template identifier based on their sequence number can be queued until an intermediate message is received.

[0108] It is likely that the receiving mining node has the applicable transaction corresponding to the TXID in its memory pool, but if the transaction is missing, it can request a copy of any missing transaction.

[0109] It will be understood that the above illustrative messaging protocol is an example implementation.

[0110] Block propagation with poisoned transactions

[0111] Early propagation of candidate block details from one mining node to another can lead to other mining nodes relying on the verification work of that first mining node. That is, each mining node should verify transactions before adding them to the mempool and build candidate blocks based on these verified transactions. If the first mining node builds candidate blocks based on verified transactions and then sends the block header data and an ordered set of transaction identifiers to the second mining node, it's conceivable that the second mining node's choice depends on either the underlying transaction being valid because the first mining node has already completed its verification work, or the first mining node not including the underlying transaction in the candidate block it's mining. This allows the second mining node to avoid the computational cost of verification work. If enough mining nodes begin to shoulder the verification work of other mining nodes, the consensus-based security of the blockchain network could be compromised.

[0112] Therefore, in one aspect, this application provides methods and systems for constructing blocks that prevent such dependency on propagation. Specifically, a mining node creating an ordered set of transactions for a candidate block can place one or more invalid transactions in the ordered set propagated to other mining nodes. If the candidate block is successfully mined, the mining nodes reveal which transactions in the ordered set are invalid.

[0113] In this way, the second mining node cannot rely on the block information propagated from the first mining node to identify verified transactions, because that information has already been seeded with at least one invalid transaction. Invalid transactions can be referred to as "poisoned" transactions, and an ordered set of transactions modified to include invalid or poisoned transactions can be referred to as a "poisoned ordered set".

[0114] The first mining node does not mine candidate blocks containing poisoned ordered sets. Instead, it constructs candidate blocks containing ordered sets of verified transactions. The block header is the header of the valid candidate block that the first mining node attempts to mine by iterating through random values ​​and changing timestamps and / or the original transaction data. However, the block data forwarded to other mining nodes during pre-proof-of-work block propagation is the poisoned ordered set information.

[0115] In one implementation, the first mining node can reveal the one or more indices of invalid transactions after successfully mining a block by sending data of the invalid transaction's one or more indices along with the POW solution data (e.g., the solution's random number, timestamp, and original data). In another implementation, the first mining node can demonstrate prior knowledge of invalid transactions by providing a list of one or more indices of invalid transactions in advance. This list can be encrypted to prevent the receiving mining node from immediately repairing the poisoned ordered set, and if the first mining node finds a POW solution for a candidate block, it can provide a decryption key to decrypt the encrypted list.

[0116] Invalid transactions added to a poisoned sorted set can be transactions created by a mining node that are constructed to violate at least one validation criterion. In some cases, invalid transactions can be transactions received by a mining node from another mining node and found in that other mining node's poisoned sorted set. By reusing invalid transactions that have been used by other mining nodes, mining nodes prevent recipients from identifying invalid transactions solely based on the view of that mining node as a single source.

[0117] The cryptographic list identifies invalid transactions in the poisoned sorted set by their indices. In some implementations, the cryptographic list also provides a replacement valid transaction for each invalid transaction. By replacing invalid transactions with valid ones, the poisoned sorted set is restored to a sorted set that matches the candidate block. The receiving node can then fully construct the Merkle tree and verify the POW solution. By providing replacement transactions instead of simply removing invalid transactions, the structure of the Merkle tree is maintained, allowing the receiving node to complete at least some of the verification and Merkle hashing work before receiving the POW solution.

[0118] Now for reference Figure 4 , Figure 4 An example method 400 for block propagation in a blockchain network is illustrated in flowchart form. Method 400 in this example is implemented by a mining node. The mining node can be a network-connected computing device configured to mine blocks according to a blockchain management protocol. Block mining may include building candidate blocks and then hashing the candidate block headers until a Proof-of-Work (PoW) solution is found or notification is received that another mining node has successfully mined its own candidate block. Method 400 can be implemented using processor-executable instructions stored in memory, which, when executed by a processor, cause the processor to perform the following operations.

[0119] In operation 402, the mining node builds a candidate block containing verified transactions. These transactions can be verified transactions stored in the mining node's mempool of unconfirmed but verified transactions. As indicated in operation 404, once the candidate block is built, the mining node can also begin mining it. Mining involves hashing the candidate block header, determining if the hash result is below a difficulty threshold, and if not, iterating over a random value in the header, updating the timestamp, or altering the original transaction to change the header's contents, and then repeating the process. It will be understood that a candidate block contains an ordered set of transactions.

[0120] In operation 406, the mining node replaces one or more valid transactions in a copy of the ordered set of transactions with one or more invalid transactions to create a poisoned ordered set of transactions. The invalid transactions can be created by the mining node or copied from invalid transactions sent by another mining node. As indicated in operation 408, the mining node then creates an indexed list identifying the invalid transactions in the poisoned ordered set of transactions.

[0121] In this example, the encrypted list can also include replacement data. Replacement data can be the TXID of a valid transaction that has been replaced by an invalid transaction. In some cases, replacement data can be the valid transaction itself. Replacement data allows the recipient to "repair" the poisoned ordered set of transactions by removing invalid transactions and replacing them with corresponding valid transactions, thereby reconstructing a correct ordered set of transactions that forms the basis of candidate blocks. The index list of invalid transactions is encrypted by the mining nodes.

[0122] In some other examples, the encrypted list does not contain replacement data, and if the mining node manages to find the POW solution, the mining node provides the replacement data along with the POW solution.

[0123] In operation 410, the mining node propagates the poisoned ordered set and encrypted list of transactions to other mining nodes. Mining nodes can use messaging protocols (such as those described above) to signal transactions to be added, deleted, or replaced in the poisoned ordered set.

[0124] As indicated in operation 412, after signaling its poisoned ordered set to other mining nodes, the mining node continues searching for the POW solution to the candidate block. As indicated in operation 414, the mining node also monitors for notifications from another mining node that it has found the POW solution to its own candidate block. If another node finds a valid block, the mining node returns to operation 402 to create a new candidate block and try again. If the mining node finds the POW solution, in operation 416, the mining node propagates the solution and the decryption key for the encrypted list. Other nodes on the blockchain network can then decrypt the encrypted list, repair the ordered set of transactions to create a candidate block, complete the verification of the candidate block, and further propagate the solution and decryption key.

[0125] Figure 5 An example method 500 for block verification performed by nodes in a blockchain network is illustrated. This example method 500 can be implemented by a mining node. A mining node can be a network-connected computing device configured to mine blocks according to a blockchain management protocol. Method 500 can be implemented using processor-executable instructions stored in memory, which, when executed by a processor, cause the processor to perform the following operations.

[0126] Method 500 begins in operation 502 with receiving candidate block template data and an encrypted list from the 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 some transactions are invalid. The candidate block template data may be received based on a messaging protocol (as described above), where transactions can be added to, removed from, or replaced within a candidate block template associated with a specific mining node. Once decrypted, the encrypted list identifies poisoned transactions within the candidate block template data.

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

[0128] In Operation 508, the node verifies any transactions it has not yet verified. If any transactions are identified as invalid, the node can mark them or otherwise denote them as invalid, as indicated in Operation 510. If the mining node is using the poisoned transaction block propagation protocol, which can be signaled in messaging related to propagating candidate block templates, the node will be notified that invalid transactions may have been intentionally placed in the ordered set. Furthermore, the node may have received an encrypted list, which may implicitly signal the presence of at least one invalid transaction in the ordered set.

[0129] 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 random number used, the timestamp, and any other data required for the node to rebuild and verify candidate blocks. The notification also includes a decryption key that allows the encrypted list to be decrypted, as the node does in operation 514. In some example implementations, the notification also includes replacement data indicating what valid transaction should replace the invalid one. In some cases, the replacement data is included in the encrypted list and can be revealed once decrypted.

[0130] The decrypted list reveals the indices of invalid transactions. The node also has replacement data from either the decrypted list or from the POW decryption notification. In operation 516, the node determines whether the index identified in the decrypted list matches a transaction that the node identified as invalid in operations 508 and 510. If they do not match, the block is rejected as invalid in operation 518. In other words, if the node identifies an invalid transaction in the candidate block template data, and the same transaction is not identified as invalid in the decrypted list, then the block contains an invalid transaction and should be rejected. In some cases, if the decrypted list identifies a transaction that the node considers valid as invalid, a replacement can be made, and the block can still be accepted if it meets all validation criteria.

[0131] In operation 520, the node replaces invalid transactions with valid ones based on the replacement data in the decryption list. Then, in operation 522, the node completes the block verification. Specifically, in the case of inserting valid transactions to replace invalid ones, the node can complete the construction of those parts of the Merkle tree, find the Merkle root, complete the block header, hash the header, and confirm that the hash is below the difficulty setting.

[0132] In some implementations, the poisoned transaction indices in the decryption list are arrays of varint indices. Values ​​of 0 can be reserved as dummy entries that can be ignored by nodes. Mining nodes can insert one or more 0-value entries to obfuscate the number of poisoned transactions in a block by padding the data.

[0133] In some embodiments, the replacement data is sent along with the POW decryption and decryption keys, rather than being included in the encryption list.

[0134] An illustrative example of the message structure used to send the POW decryption and decryption keys is:

[0135]

[0136] In the example above, the `template_id_len`, `template_id`, and `sequence_no` fields identify the template associated with the message and ensure the correct ordering of messages associated with that template. The `aes_128_encryption_key` field stores the decryption key used to decrypt the encrypted list. In some cases, the decryption key can also be used to decrypt encrypted AOL data.

[0137] The `block_header` and `raw_tx` fields store the data required to complete the candidate block. The `aol` field provides any additional transactions to be added to the template; this field can be empty.

[0138] The Poison_tx_replacements field contains replacement data, that is, transaction data used to replace invalid transactions revealed in the encrypted list.

[0139] It will be understood that the aforementioned message structure is an example. Depending on the implementation, other message structures may include additional fields, alternative fields, or fewer fields.

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

[0141] Now for reference Figure 6 The diagram illustrates a simplified mining node 600 according to an example of this 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 also include a memory 604 and a network interface 606. The memory 604 may include persistent and non-persistent memory to store values, variables, and in some cases, processor-executable program instructions.

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

[0143] The various embodiments presented above are merely examples and are in no way intended to limit the scope of this application. Variations of the innovations described herein will be readily apparent to those skilled in the art, and such variations are within the scope of this application. In particular, alternative example embodiments may be created by selecting one or more features from the above example embodiments, including sub-combinations of features that may not be explicitly described above. Furthermore, alternative example embodiments may be created by selecting and combining features from one or more of the above example embodiments, including combinations of features that may not be explicitly described above. Features suitable for such combinations and sub-combinations will be readily apparent to those skilled in the art upon a comprehensive review of this application. The subject matter described herein and in the cited claims is intended to cover and encompass all suitable technical variations.

Claims

1. A computer-implemented method for block propagation in a blockchain network, comprising: At the first mining node, a first candidate block containing transactions from a first ordered set is constructed, and the first candidate block has a first block header; Place one or more invalid transactions into the first ordered set to create a poisoned ordered set; Construct a list identifying one or more invalid transactions within the poisoned ordered set, and encrypt the list to generate an encrypted list of invalid transactions; as well as While hashing the first block header, a first message is sent to other mining nodes. The first message contains the encrypted list of the poisoned ordered set and invalid transactions.

2. The method according to claim 1, further comprising: The first mining node finds the proof-of-work for the first block header and therefore sends the decryption key for the encrypted list of invalid transactions.

3. The method according to claim 1 or 2, wherein, Placing one or more invalid transactions includes inserting the one or more invalid transactions into the first ordered set of transactions.

4. The method according to claim 1 or 2, wherein, Placing one or more invalid transactions involves replacing the corresponding valid transaction in the first ordered set for each of the one or more invalid transactions.

5. The method according to claim 4, wherein, The encrypted list of invalid transactions also includes the corresponding valid transactions.

6. The method according to claim 4, further comprising: At another mining node, the first candidate block is constructed by decrypting the encrypted list of invalid transactions, and the one or more invalid transactions are replaced with corresponding valid transactions in the poisoned ordered set in order to reconstruct the first ordered set and generate the first candidate block.

7. The method according to claim 1, wherein, The one or more invalid transactions include transactions that violate at least one validity criterion stipulated by the blockchain protocol used for the blockchain network.

8. The method according to claim 1, further comprising: Create at least one of the one or more invalid transactions at the first mining node.

9. The method according to claim 1, further comprising: At the first mining node, an invalid transaction received from another mining node is selected as one of the one or more invalid transactions.

10. The method according to claim 1, further comprising: The first mining node finds a proof of work for the first block header and therefore sends the proof of work and a decryption key for the encrypted list of invalid transactions, wherein the proof of work includes the original transactions from the first candidate block, and a random number and timestamp from the first block header.

11. The method according to claim 1, further comprising: While hashing the first block header, a second message is received, the second message identifying the transactions and their order in a second poisoned ordered set, the second poisoned ordered set being derived from a second candidate block mined by a second mining node; and a second encrypted list is received, wherein the second encrypted list identifies invalid transactions in the second poisoned ordered set.

12. The method of claim 11, further comprising: Verify the transactions in the second poisoned ordered set and identify a set of one or more invalid transactions in the second poisoned ordered set.

13. The method of claim 12, further comprising: The second mining node, which indicates the successful completion of the proof-of-work for the second candidate block, receives the original transaction, decryption key, and second block header information, wherein the second block header information includes at least a timestamp and a random number; Decrypt the second encrypted list using the decryption key; The second encrypted list identifies invalid transactions that are identical to invalid transactions in the set of one or more invalid transactions; Based on the original transaction, the second block header information, and the second poisoned ordered set modified to replace one or more invalid transactions in the second poisoned ordered set, a second block header is assembled; and The second candidate block is verified by hashing the second block header to verify the proof-of-work.

14. A computing device for implementing a first mining node for mining blocks on a blockchain network, the computing device comprising: One or more processors; Memory; as well as Computer-executable instructions stored in the memory, when executed by the one or more processors, cause the processors to perform the method according to any one of claims 1 to 13.

15. A computer-readable medium storing 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 processors to perform the method according to any one of claims 1 to 13.

Images