Method and device for spreading blocks in block chain network

Abstract

A method and apparatus for propagating blocks in a blockchain network. At the network node, upon hash processing of a first block header of the first candidate block, the network node sends a first message specifying transactions in a first ordered set of transactions included in the first candidate block and their order to other network nodes. The network node also receives a second message specifying transactions and their order included in a second ordered set in a second candidate block being mined by a second network node. If the network node successfully digs a candidate block, it notifies other network nodes by providing the original transaction, hash value, and timestamp to the other network nodes. If another network node succeeds, the network node receives information from the other network node, according to which the network node may assemble and validate a second candidate block in conjunction with a second message.

Description

[0001] This divisional application is based on a patent application with Chinese Application No. 202080035859.X (PCT International Application No. PCT / IB2020 / 053416), filed on April 9, 2020, and titled "Method and Apparatus for Propagating Blocks in a Blockchain Network". Technical Field

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

[0003] In some blockchain systems (e.g., proof-of-work blockchain systems), when a network node discovers a valid block, it attempts to successfully and quickly transmit it to all other network nodes. This involves propagating information about the block through the blockchain network to all network 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 network node verifies the new block by hashing the block header and confirming that it matches the hash value provided by the successful network node.

[0004] As the size of the block and the number of transactions increase, the latency in block propagation exacerbates the problems of temporary forks and orphan blocks. These situations are costly for network nodes and the entire system. Brief Description of the Drawings

[0005] Examples of the present application will now be described with reference to the accompanying drawings, which illustrate example embodiments of the present application, where:

[0006] Figure 1 shows an example block structure of a blockchain network;

[0007] Figure 2 shows a flowchart of an example method for block propagation;

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

[0009] Figure 4 shows a simplified example of a network node in block diagram form.

[0010] The same reference numerals are used in the drawings to denote the same elements and features.

[0011] Detailed Implementation Manner

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

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

[0014] In some implementations, the method can further include: receiving from the second network node another transaction (e.g., a coinbase transaction, also referred to as an original transaction) and second block header information, where the second block header information includes at least a timestamp and a nonce. And in response thereto: assembling a second block header based on the second ordered set of transactions, the another transaction, and the second block header information; and verifying the second candidate block by hashing the second block header. In some cases, assembling includes: determining a Merkle root from the second ordered set of transactions and the another transaction.

[0015] In some implementations, the method can further include: receiving from the second network node another transaction (e.g., a coinbase transaction, also referred to as an original transaction) and second block header information for indicating successful completion of consensus (also referred to as a consensus mechanism, proof related to consensus, e.g., proof of work) regarding the second candidate block, where the second block header information includes at least a timestamp and a nonce; assembling a second block header based on the second ordered set of transactions, the another transaction, and the second block header information; and verifying the second candidate block by hashing the second block header to verify the consensus (e.g., proof of work). In some cases, assembling includes: determining a Merkle root from the second ordered set of transactions and the another transaction.

[0016] In some implementations, the method can further include: finding a nonce that results in a hash of the block header being less than a threshold set by a difficulty by hashing the first block header of the first candidate block to produce a hash value less than the difficulty threshold, thereby: sending to other network nodes another transaction from the first candidate block and first block header information, where the first block header information includes at least a timestamp and a nonce; and adding the first candidate block to a local copy of the blockchain. Optionally, the first block header information excludes at least some block header fields. Optionally, the first network node does not re-send the first ordered set of transactions to other network nodes after finding the nonce.

[0017] In some implementations, the method may further include: finding a consensus (e.g., proof-of-work) associated with the nonce in the first block header of the first candidate block by hashing the first block header to produce a hash value less than a difficulty threshold, thereby sending to other network nodes another transaction from the first candidate block and first block header information, where the first block header information includes at least a timestamp and a nonce; and adding the first candidate block to a local copy of the blockchain. In some cases, the first block header information excludes at least some block header fields. In some cases, the first network node does not re-send the first ordered set of transactions to other network nodes after finding a consensus (e.g., proof-of-work).

[0018] In some implementations, the method may include: first constructing a first candidate block by selecting transactions from a memory pool, sorting them to create a first ordered set of transactions, and adding another transaction.

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

[0020] In some implementations, the first message and the second message contain compressed transaction identifiers, which are used to specify the transactions in the first ordered set of transactions and the transactions in the second ordered set of transactions. In some examples, the compressed transaction identifier is a truncated transaction identifier.

[0021] In some implementations, the first ordered set of transactions in the first message is encrypted, and wherein a decryption key for decrypting the first ordered set of transactions is provided to other network nodes only when the first network node finds the nonce for the first candidate block.

[0022] In some implementations, the first ordered set of transactions in the first message is encrypted, and wherein a decryption key for decrypting the first ordered set of transactions is provided to other network nodes only when the first network node finds a consensus (e.g., proof-of-work) for the first candidate block.

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

[0024] In another aspect, a computer-readable medium can be provided that stores processor-executable instructions for implementing a first network 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 method described herein.

[0025] Other example embodiments of the present disclosure will be apparent to those of ordinary skill in the art upon review of the following detailed description in conjunction with the accompanying drawings.

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

[0027] In this application, the phrase "at least one of... or..." 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 of the elements, without necessarily excluding any additional elements and without necessarily requiring all of the elements.

[0028] This application will refer to hash processing or hash functions, which are intended to include any one of a plurality of cryptographic hash functions that deterministically produce a unique fixed-length alphanumeric string when applied to any set of data or "message". The result of a hash function can be referred to as a hash value, fingerprint, hash result, or the like. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2. Any mention hereinafter of "a network node hashing a block or candidate block" will be understood to mean applying a cryptographic hash function to the block header portion of the candidate block.

[0029] In this document, 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 unpermissioned ledgers, shared ledgers, and their variants. For convenience and illustrative purposes, a particular blockchain may be referred to herein, but it should be noted that the present invention is not limited to use with a particular blockchain, and alternative blockchain implementations and protocols fall within the scope of the present invention.

[0030] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash value of the previous block, so the blocks are linked together to create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. These scripts can be written using a stack-based scripting language.

[0031] A blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and software that executes the applicable blockchain protocol. Nodes verify transactions and propagate them to other nodes in the network. Specialized network nodes collect a set of unconfirmed transactions (i.e., pending transactions) into a block and attempt to "mine" the block. In these examples, mining refers to solving a consensus mechanism (also known as consensus, proof related to consensus, e.g., proof of work) for a block before any other network node in the network successfully solves its corresponding block. In some examples, the consensus mechanism involves hashing a block header that includes a nonce until the result is less than a threshold set by a difficulty parameter. The nonce is incremented repeatedly and the hashing is repeated until the result is less than the threshold or until the network node receives notice that another network node has been successful. Variations of the mining process are familiar to those of ordinary skill in the art.

[0032] A typical block contains two data structures: a block header and transactions. Figure 1 An example block structure 100 is shown diagrammatically. 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 previous block hash value 108, a Merkle root 110, a timestamp 112, a target difficulty parameter 114, and a nonce 116. The previous block hash value 108 links this block to the previous block in the chain, creating a "blockchain" structure that links successive blocks together via cryptographic hashes. The Merkle root 110 refers to a Merkle tree structure based on all the transactions contained in the block. The nonce 116 is an arbitrary value that network nodes can repeatedly increment or decrement to change the content of the block header 102 in order to produce different hash results when mining.

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

[0034] When a network node successfully finds a block header that produces a hash result less than a threshold, it continues to notify other nodes using 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.

[0035] The blockchain ecosystem is maturing to provide increased availability through a large increase in the volume of transactions and, consequently, a large increase in the block size. As blocks become larger (in some cases exceeding 128 MB), it takes more time to propagate a newly mined block successfully to other nodes across the network. The latency in propagation comes at a cost. First, network nodes that do not know that a newly mined block has been created will continue to try to mine their own candidate blocks, which is a wasted effort if the new block is proven to be valid. Second, the latency in propagation and verification can lead to an increased likelihood of (temporary) forks and orphan blocks.

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

[0037] However, as modern block sizes grow to 128 MB and beyond the size of the data to be transmitted, it can still be a significant amount if the count of transactions is large. For example, a block containing 500,000 transactions will have a 16-MB ordered list of TXIDs.

[0038] Accordingly, on the one hand, the present application describes a method and system for a blockchain network, where network nodes provide information about their respective candidate blocks to other network nodes while hashing their candidate blocks. In this way, each network node uses the time delay between discovering successful blocks to provide other network nodes with detailed information about the candidate block structure and content. By providing this information in advance, when a successful block is found, the successful network node only needs to send information from the block header, and in some cases, another transaction (e.g., a coinbase transaction, also known as an original transaction), to ensure that all other nodes can assemble and verify the complete new block. This data may be only a few hundred bytes. This improves the speed at which successful new blocks are propagated through the entire network.

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

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

[0041] To illustrate one aspect of the present application, reference is now made to Figure 2, which shows an example method 200 of blockchain mining in the form of a flowchart. This method 200 is implemented by network nodes. The network nodes can be implemented on a computing device, which may include one or more processing units. As those skilled in the art will understand, the processing units can include dedicated processing units with dedicated hardware, which is designed to perform computational operations associated with blockchain mining at significant speeds and efficiencies. However, the processing units can also or alternatively include general-purpose computing devices. The computing device includes processor-executable software, which 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 for the associated hardware and software, which is used to obtain a network connection and send and receive messages according to applicable network protocols.

[0042] The method 200 includes: In operation 202, a set of transactions is selected from the memory pool of unconfirmed transactions to construct a candidate block. This selection can be based on the age of the transactions, the fees payable for mining the transactions, or any other factor. These transactions form an ordered list of transactions. The network node also determines the Merkle root based on the ordered list of transactions and forms a block header, including setting an initial value for the nonce in the block header.

[0043] In operation 204, as part of the search for a proof-of-work (POW) that satisfies the difficulty setting condition, the network node begins to repeatedly hash the block header and begins to increment the nonce. While searching for the POW for its candidate block, the network node sends information about its ordered list of transactions to other network nodes, as shown in operation 206. While operation 204 is in progress, the network node also receives messages from other network nodes, which include information about the corresponding ordered list of transactions in the candidate blocks that these network nodes are processing, as shown in operation 208. It should be understood that although operations 204, 206, and 208 are shown sequentially, they generally occur in parallel. The information received from other network nodes about the corresponding ordered list of transactions is stored locally by the network node. The network node can store the information in a table or other data structure.

[0044] Continue the search for the POW until the network node successfully finds the POW (as shown in operation 210), or until it receives a notification from another network node that it has found the POW (as shown in operation 212). If the network node finds the POW, then in operation 214, it sends some block header information to other network nodes to disseminate the block details. It is worth noting that there is no need to send the payload. However, the original transaction (coinbase transaction) can be sent.

[0045] If a network node receives block header information from another network node, then in operation 216, it assembles a new block based on the stored ordered list of transactions for that network node. If an original transaction (coinbase transaction) is received, the transaction is added to the block and the network node can construct a Merkle tree to confirm the Merkle root is valid. Then in operation 218, the network node validates the new block and if it is invalid, it can discard the new block and continue searching for its own POW. Note that there may be certain validity checks that, if they fail, can prompt the network node to take other actions such as requesting additional data from a successful network node, as described later. If the block is verified, then in operation 220, it is added to the blockchain and propagated to other network nodes. Then, the network node returns to operation 202 to construct a new candidate block and start the search again.

[0046] It will be understood that the method of pre-distributing candidate block information described so that each network node knows the ordered list of transactions of each other network node ensures that only a minimal amount of information needs to be propagated after the POW is found. This ensures that network nodes obtain the information required to verify new blocks as soon as possible, thus reducing the time wasted searching for POW in cases where another network node has already been successful. Network nodes have a strong incentive to propagate and verify 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 the approximately 10-minute period between successive blocks, potential delays due to network latency are less of a concern.

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

[0048] In another example implementation, the messaging protocol can provide for appending a transaction to the ordered list of a network node, removing or deleting a transaction from the ordered list, replacing a transaction with another transaction, or reordering the transactions. In the normal course, a network node will most likely only use the "add" message that specifies the ordered list of transactions. However, there are some cases where a network node may wish to remove or replace a transaction. For example, subsequently received information may indicate a potential double spend related to one of the transactions or some other potential issue related to its validity. As another example, a network node may iterate through all increments of the nonce and may wish to reorder or otherwise adjust the transactions to change the Merkle root and thus the block header to continue mining the block. The exact format of the message structure may vary depending on the implementation.

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

[0050] Although it is not guaranteed that the first 8 bytes of the TXID uniquely identify the transaction, the likelihood of two TXIDs colliding, whether in a single message or in general, is small. Given that SHA256 outputs a pseudo-random 256-bit string, the exact likelihood of two random TXIDs colliding, i.e., the likelihood that any two TXIDs have the same first 4 bytes, is:

[0051]

[0052] where TXID i [0:n] represents 'the first n bytes of TXID i '. Additionally, the likelihood that a message containing N compressed TXIDs will contain one or more collisions can be expressed as:

[0053]

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

[0055] P(>0 collisions among 1,000,000 TxIDs) = 0.0000000271

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

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

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

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

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

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

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

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

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

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

[0066] Each message related to the ordered list of transactions can include the template identifier and can also include a sequence number. The sequence number can be an unsigned integer value used to indicate the order of messages from one network node relative to each other. The ordering helps the message recipient to uniquely determine the TXID ordering for a specific network node in case some messages are not received or are received out of order.

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

[0068] In some cases, the handshake operation in the authentication phase may include establishing a shared key between network nodes. There are many techniques for establishing a shared key. Subsequent message passing (e.g., message passing related to the ordered list of transactions) can be encrypted for confidentiality and to reduce the likelihood of a man-in-the-middle attack on the mining process.

[0069] In some embodiments, network nodes perform an authentication procedure after joining the network and opening 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 may cause the network node to close or disconnect from other network nodes. In some cases, a network node may have an endpoint for an authenticated connection that is different from its usual public network connection.

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

[0071] Upon receiving the authentication challenge message, the responding network node concatenates the received message with a random numerical value. The random numerical value can be generated by the responding network node using any pseudo-random process. Then, the responding network node 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 associated with the network node identity. In some cases, the public key can be the network node ID used in communications on the blockchain network. The requesting network node may have a whitelist or other record of the network node IDs (public keys) of the network nodes joining the blockchain network.

[0072] Once the responding network 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., network node ID), the random numerical value used, and the generated digital signature. The requesting network node receives the authentication response message and can verify using the public key that the network node is the owner of the public key and that the public key matches a key on the whitelist corresponding to a particular network node.

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

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

[0075] ‘authchallenge’

[0076] …

[0077] version:varint,

[0078] message_length:varint,

[0079] message: byte[]

[0080] …

[0081] In one example, the format of the authentication response message can be in the following form:

[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 value from the authentication challenge message and the content of the message fields. Depending on the implementation, the concatenation can be (random number | message) or (message | random number).

[0091] Now referring to Figures 3A - 3I , Figures 3A - 3I schematically shows an example operational state of two network nodes according to an implementation of the present application and the message passing flow therebetween.

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

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

[0094] As Figure 3C shown, network nodes 302 and 304 begin mining their respective candidate blocks 308 and 310 to try to find a nonce that will cause the hash of the block header to be less than the threshold set by the difficulty.

[0095] During a successful search for consensus (e.g., proof-of-work), network nodes 302 and 304 exchange information about the ordered sets of transactions in their respective candidate blocks 308 and 310. As Figure 3D shown, the first network node 302 may send an "add" message 312 to the second network node 304, providing a list of the first ordered transactions from the first candidate block 308. Based on this information, the second network node 304 may construct a template 314 of the first candidate block 308. In some example implementations, the template 314 may be a list of the first ordered transactions in TXID form. In some example implementations, the template 314 may be a table, an example of which is provided above. In other example implementations, the template 314 may 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 network node 304 may send an "add" message 316 containing a list of the second ordered transactions from the second candidate block 310 to the first network node 302, as Figure 3E shown. Based on this data, the first network node 302 constructs a template 318 of the second candidate block 310. Now each network node has their own candidate block that they continue to mine, as well as a template of the candidate block that the other network node is working on.

[0097] Figure 3F Shows that the first network node 302 has successfully found a block header hash that meets the requirements of the consensus mechanism (e.g., proof-of-work). Thus, the first candidate block 308 with the most recently tested nonce in its block header produces a valid block. Then, Figure 3G and Figure 3HIt is shown that the first network node 302 adds a new block 322 to the blockchain 306 and sends a message containing the original transaction (coinbase transaction) 320 and a message containing block header information 324. The block header information 324 includes at least a nonce and a timestamp. The block header information may or may not include other block header fields, for example, a merkle_root field. In some cases, this can be sent as part of the block header information 324, although it can be calculated by the second network node 304 to enable the second network node 304 to double-check its merkle root calculation. In some cases, the first network node 302 sends the complete block header of the new block 322 to the second network node 304. The first network node 302 may also send a hash value obtained by hashing the block header to the second network node 304 so that the second network node 304 can verify not only that the hash is less than the difficulty threshold but also that it matches the hash that the first network node 302 claims to have found. The hash value can be sent in the original transaction (coinbase transaction) message 320, the block header information message 324, or a separate message.

[0098] Once the second network node 304 has the original transaction (coinbase transaction), it can complete the transaction part of the template 314 of the first candidate block and thus calculate the merkle root. Based on this calculation, it can verify whether the merkle_root field is accurate and whether this field is included in the block header information message 324. If not, it can complete the merkle_root field and any other missing fields, such as the version, prev_block value, and bits field, in order to assemble the block header 326 for the new block 322. The other fields of the block header 326, such as the nonce and the timestamp, are provided by the block header information message 324. Then, the second network node 304 can verify the new block by hashing the assembled block header 326.

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

[0100] Although the above sequence shows that the original transaction (coinbase transaction) message 320 is sent before the block header information message 324, it will be understood that in some implementations, the block header information message 324 can be sent first, or the two messages can be combined into a single message. Other variations can be made to the order of operations or implementation details of a particular instance without changing the overall functional operation of the described system and method.

[0101] Those skilled in the art of blockchain networks can understand that, in some cases, blocks can be mined earlier than expected. It is possible to find a valid block earlier. In addition, some messages that propagate transaction or transaction ordering information may encounter network latency when propagating through the network.

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

[0103] In some implementations, one or more network nodes may wish to maintain a certain confidentiality about their transaction selection and ordering. In such implementations, it is possible for the network node to encrypt the ordered list of transactions when distributing it during the mining phase. If a valid block is found, the network node distributes the decryption key along with the block header information and / or the original transaction (coinbase transaction), thus allowing the receiving network node 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 for propagating an ordered list of transactions between network nodes:

[0105]

[0106] The receiving network node modifies the candidate block template corresponding to the template identifier in the message. For a specific template identifier, messages received out of sequence according to the sequence number can be queued until an intervention message is received.

[0107] It is likely that the receiving network 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.

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

[0109] It should be understood that some or all of the above operations of the various above example methods can be performed in an order different from that shown and / or can be performed simultaneously without changing the overall operation of those methods.

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

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

[0112] The various embodiments presented above are merely examples and in no way limit the scope of the present application. Variations of the innovations described herein will be apparent to those of ordinary skill in the art, and such variations are within the scope of the present application. In particular, features from one or more of the above example embodiments can be selected to create alternative example embodiments that include sub-combinations of features that may not have been explicitly described above. Additionally, features can be selected from one or more of the above example embodiments and combined to create alternative example embodiments that include combinations of features that may not have been explicitly described above. Those skilled in the art will readily appreciate the features suitable for such combinations and sub-combinations upon reviewing the present application in its entirety. The subject matter described herein and in the recited claims is intended to cover and contain all suitable technical variations.

Claims

1. A computer-implemented method for block propagation in a blockchain network, comprising: While hashing a first block header of a first candidate block at a first network node, sending a first message to other network nodes, the first message specifying transactions in a first ordered set included in the first candidate block and the order of the transactions; And Receiving a second message, the second message identifying transactions in a second ordered set included in a second candidate block being mined by a second network node and the order of the transactions.

2. The method according to claim 1, wherein, Receiving the second message includes storing the second ordered set of transactions in association with a second network node identifier in a memory at the first network node.

3. The method according to claim 1 or 2, further comprising: Receiving another transaction and second block header information from the second network node, wherein the second block header information includes at least a timestamp and a nonce; Assembling a second block header based on the second ordered set of transactions, the another transaction, and the second block header information; and Verifying the second candidate block by hashing the second block header.

4. The method according to claim 3, wherein The assembling includes: determining a Merkle root according to the second ordered set of transactions and the another transaction.

5. The method according to claim 1, further comprising first constructing the first candidate block as follows: selecting transactions from a memory pool and sorting the transactions to create the first ordered set of transactions, and adding another transaction.

6. The method according to claim 1, further comprising: Finding a nonce that causes the hash of the block header to be less than a threshold set by a difficulty by hashing the first block header of the first candidate block to produce a hash value less than the difficulty threshold, thereby: Sending another transaction and first block header information from the first candidate block to other network nodes, wherein the first block header information includes at least a timestamp and the nonce; and Adding the first candidate block to a local copy of the blockchain.

7. The method according to claim 6, wherein, The first block header information excludes at least some block header fields.

8. The method according to claim 6 or 7, wherein, The first network node does not re-send the first ordered set of transactions to other network nodes after finding the nonce.

9. The method according to any one of claims 1 to 8, wherein, The first message includes a first template identifier based on a first network node identifier and a block level indicator.

10. The method according to claim 9, wherein, The first template identifier is obtained from a concatenated hash operation as follows: (a) the first network node identifier and (b) a concatenation of a hash value associated with the previous block in the blockchain.

11. The method according to claim 1, wherein The first message and the second message include compressed transaction identifiers for specifying transactions in the first ordered set of transactions and transactions in the second ordered set of transactions.

12. The method according to claim 11, wherein, The compressed transaction identifier is a truncated transaction identifier.

13. The method according to any one of claims 1 to 12, wherein The first ordered set of transactions in the first message is encrypted, and a decryption key for decrypting the first ordered set of transactions is provided to other network nodes only when the first network node finds a nonce for the first candidate block.

14. The method according to claim 1, wherein receiving the second message comprises receiving, while hashing the first block header, corresponding messages from a plurality of other network nodes including the second network node, wherein each of the corresponding messages identifies an ordered set of transactions in a corresponding candidate block being mined by a corresponding one of the other network nodes.

15. A computing device, the computing device comprising: one or more processors; a memory; computer-executable instructions stored in the memory, the computer-executable instructions, when executed by the one or more processors, cause the processors to execute the method according to any one of claims 1 to 14.

16. A computer-readable medium storing processor-executable instructions, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processors to execute the method according to any one of claims 1 to 14.

Images