Method and apparatus for safe symbiotic mining

Abstract

Methods and apparatus for splitting storage and validation functions from mining functions in a blockchain network. Storage and validation nodes create candidate blocks. Mining nodes provide hashing power for mining candidate blocks and receive resources from the storage and validation nodes for successful mining of a candidate block. Atomic exchange mechanisms are used to prevent loss and fraud and to minimize use of bandwidth by the mining nodes.

Description

Technical Field

[0001] This disclosure relates to blockchain networks, and in particular mining within blockchain networks. Background Technology

[0002] Mining nodes are key components of a blockchain network. They safeguard the network, ensuring transactions are valid and that all participating nodes conform to the current blockchain protocol. Before transactions and blocks are propagated throughout the blockchain network, nodes verify transactions and blocks containing those transactions according to established validity criteria.

[0003] As the network scales and proof-of-work searches become computationally more difficult, mining functions require significant computing power (sometimes referred to as "hashpower"). The number and size of transactions also mean that verification and propagation functions require substantial computation, storage, and bandwidth. It would be advantageous to find better mechanisms for constructing blockchain networks and blockchain nodes, and / or the operations performed by these nodes, to meet these demands while still ensuring transaction security without the need for trusted intermediaries. Summary of the Invention

[0004] In one aspect, a computer-implemented method for mining in a blockchain network, the blockchain network including non-mining nodes and multiple mining nodes, may be provided. The method may include: generating a candidate block comprising multiple transactions by the non-mining nodes, the multiple transactions including source transactions and mining node transactions, the source transactions including a first output associated with the non-mining nodes, the mining node transactions including the first output of the source transactions as input, and the mining node transactions including a second output associated with a first mining node; determining a payload digest of the candidate block; sending the payload digest, the mining node transactions, and a first digest path of the mining node transactions to the first mining node; receiving a proof-of-work solution of the candidate block from the first mining node; and propagating the candidate block on the blockchain network.

[0005] In some implementations, sending may not include sending the source transaction to the first mining node. In some cases, sending may include sending the candidate block header of the candidate block, the candidate block header including the payload digest.

[0006] In some implementations, the source transaction and the mining transaction are not propagated on the blockchain network and are not included in the mempool until the proof-of-work solution of the candidate block is received.

[0007] In some implementations, sending may include sending the hash of the source transaction and a second digest path of the source transaction to the first mining node.

[0008] The method may further include, at the first mining node, verifying whether the mining node transaction is included in the candidate block based on the payload digest and the first digest path. In this case, in some instances, sending includes sending the hash of the source transaction and a second digest path of the source transaction to the first mining node, and verification includes verifying whether the source transaction is included in the candidate block based on the payload and the second digest path.

[0009] In some implementations, the payload digest includes a Merkle root, the first digest path includes a first Merkle path, and the first Merkle path includes a minimal set of hashes for reconstructing the Merkle root from the mining node transaction.

[0010] In some implementations, generation may include: generating a second candidate block by the non-mining node, comprising a second plurality of transactions, the second plurality of transactions including the source transaction and a second mining node transaction, the second mining node transaction including a first output of the source transaction as input, and the second mining node transaction including another output associated with a second mining node different from the first mining node.

[0011] In another aspect, this application describes a computer-implemented method for mining in a blockchain network, the blockchain network including non-mining nodes and mining nodes. The method may include: receiving, at the mining node, a candidate block header, a payload digest of the candidate block, a mining node transaction, and a first digest path of the mining node transaction from the non-mining nodes; verifying, based on the payload digest and the first digest path, whether the mining node transaction is included in the candidate block; repeatedly mining the candidate block header with consecutive random values ​​inserted into the candidate block header until a proof-of-work is found; and sending, to the non-mining nodes, a random value at least corresponding to the proof-of-work.

[0012] In another aspect, this application provides a method for mining in a blockchain network, the blockchain network including non-mining nodes and multiple mining nodes. The method may include: generating candidate blocks comprising multiple transactions by the non-mining nodes; sending at least a candidate block header of the candidate blocks to the multiple mining nodes; receiving a hash of a proof-of-work solution from a first mining node among the multiple mining nodes, the proof-of-work solution including the candidate blocks, the candidate blocks including a random number; hashing the hash of the proof-of-work solution to generate a proof-of-work result, and determining whether the proof-of-work result satisfies a difficulty setting; generating a mining node transaction in response to the proof-of-work result satisfying the difficulty setting, the mining node transaction having an output associated with the first mining node and locked by the proof-of-work solution; receiving the proof-of-work solution from the first mining node; and completing and propagating the candidate blocks on the blockchain network.

[0013] In an additional aspect, this application describes a computer-implemented method for mining in a blockchain network, the blockchain network including non-mining nodes and mining nodes. The method may include: receiving, by the mining node, a candidate block header from the non-mining nodes, the candidate block comprising a plurality of transactions; repeatedly mining the candidate block header with consecutive random values ​​inserted into the candidate block header until a proof-of-work is found; sending the hash of the proof-of-work to the non-mining nodes; receiving mining node transactions from the non-mining nodes, the mining node transactions having an output associated with the mining node and unlocked by the proof-of-work; and propagating the mining node transactions on the blockchain network.

[0014] In another aspect, a computing device for implementing nodes in a blockchain network can be provided. The computing device may include a memory, one or more processors, and computer-executable instructions that, when executed, cause the processor to perform one or more of the methods described herein.

[0015] In another aspect, a computer-readable medium may be provided storing processor-executable instructions for operating nodes in a network, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processors to perform at least one of the methods described herein.

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

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

[0018] 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 elements listed separately, any sub-combination or all of the elements, and does not necessarily exclude any additional elements, nor does it necessarily require all elements.

[0019] This application will refer to hashes or hash functions, which are intended to include any of a plurality of cryptographic hash functions that, when applied to any set of data or "message," 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 names. Example hash functions include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0020] In this document, the term "blockchain" is understood to include all forms of electronic, computer-based distributed ledgers. These distributed ledgers include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. Although example blockchain protocols may be discussed below for illustrative purposes, this application is not limited to use with any particular blockchain or blockchain protocol falling within the scope of this application, as well as alternative blockchain implementations and protocols.

[0021] A blockchain is a peer-to-peer electronic ledger implemented using a decentralized, distributed, computer-based system. A blockchain consists of blocks, and blocks are composed of transactions. Each transaction is a data structure that, in addition to other possible information, encodes the transfer of control over digital resources within the blockchain system and includes at least one input and at least one output. Transactions may include applets called scripts embedded in their inputs and outputs, specifying how and under what conditions the transaction's outputs can be accessed. On some platforms, these scripts are written using stack-based scripting languages. Access to digital resources, and the ability to further distribute some or all of them, is governed by unlocking conditions on the outputs. While many other conditions can be imposed, typical conditions often involve a digital signature using a private key that corresponds to a public key used to lock the output.

[0022] Each block header includes a summary of the block content (such as in Merklegen form), and each block header includes a hash of the previous block header, so that the blocks are chained together to create a permanent, immutable record of all transactions that have been written into the blockchain since its creation.

[0023] Blockchain is implemented through a network of nodes. Each node is a computing device with a network connection and execution software that implements the applicable blockchain protocol. Nodes verify transactions and propagate these transactions 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 the proof-of-work (POW) before any other mining node in the network successfully solves its respective block. In some examples, POW involves hashing a block header that includes a random number until the hash result is below a threshold set by a difficulty parameter. The random number is repeatedly incremented and hashed repeatedly until the result is below the threshold, or until the mining node receives notification that another mining node has succeeded. Variations of the mining process will be familiar to those skilled in the art.

[0024] As mentioned above, mining nodes are crucial for securing the blockchain network. Genesis transactions do not have inputs (or more accurately, empty or null input fields). Genesis transactions have certain characteristics that distinguish them from regular transactions. For example, each valid block includes only one genesis transaction. Each genesis transaction does not cost any inputs (or input fields, if present, do not affect the transaction). Genesis transactions are "proof-of-work transactions" because they can only be created by mining nodes that have successfully mined a block (i.e., completed proof-of-work).

[0025] In at least one example blockchain, hashing the block header to find the Proof-of-Work (PoW) is a double hash, which can be referred to in this paper as the notation H. 2 (·) indicates the hash function used. In some such examples, the hash function used is SHA-256. Other blockchain networks may use different hashes.

[0026] In the early stages of blockchain development, "full nodes" were often considered ideal because they could perform all the functions of mining, verification, blockchain storage, and propagation. As blockchain networks matured, different computational requirements emerged for mining, storage, verification, and propagation. Mining requires significant computing power for hashing, storage requires substantial disk space, verification requires high-speed computational throughput and fast-access memory, and propagation requires high-bandwidth connections with as many other nodes as possible in the blockchain network to attempt to implement a small-world network model. Separating some of these functions and automating them through specialized node construction and operation can be advantageous. However, any separation of functions should avoid introducing trust issues between nodes, which would necessitate third-party oversight or trusted intermediaries between nodes to maintain the decentralized nature of the blockchain network.

[0027] In one aspect, this application describes a blockchain system and method in which mining functions are performed by mining nodes, and some other functions (such as storage and verification functions) are performed by non-mining nodes. In some cases, non-mining nodes may perform verification and propagation functions. In some cases, non-mining nodes may perform verification and storage functions. In some cases, non-mining nodes may perform all the functions of a full node except for mining. In such systems and methods, non-mining nodes store or access a pool of pending transactions and the blockchain, and construct one or more candidate blocks for mining by the mining nodes. The mining nodes perform hash operations to find proof-of-work for candidate blocks provided to the mining nodes by one of the non-mining nodes. The non-mining nodes and the mining nodes are not necessarily owned or controlled by the same entity. In such processes, non-mining nodes may transfer resources to the mining nodes due to the work done by the mining nodes in successfully mining blocks.

[0028] To maintain the security of the mining protocol and prevent malicious or fraudulent operations, the mining process can be reconfigured to be performed jointly by multiple entities, such as dedicated mining nodes and separate storage and verification nodes (i.e., non-mining nodes). This reconfiguration of operations within the mining process between separate nodes can be designed to ensure atomic exchanges between non-mining nodes and mining nodes. An atomic exchange is an exchange in which a first node and a second node each possess data or resources needed by the other node, and the exchange occurs only when an event occurs, and not under other circumstances. An exchange is considered atomic if the possible outcomes are either both events occurring (the mutual exchange of data or resources) or neither event occurring. A significant technical challenge lies in configuring the nodes, their interactions, and the communication processes to ensure atomic exchanges occur. In some examples, double hashing operations in proof-of-work operations can be used to provide proof of knowledge, and this double hashing can be used as a prerequisite for establishing an atomic exchange. In some cases, candidate blocks can be constructed by non-mining nodes to include at least one transaction establishing an atomic exchange, and the mining node can verify this transaction before mining.

[0029] The terms “non-mining node” and “storage and verification node” may be used interchangeably in this specification.

[0030] In one example implementation, a non-mining node provides candidate blocks to multiple mining nodes. Upon receiving a message from one of the mining nodes indicating the establishment of a verifiable proof of success, rather than receiving the actual solution to the Proof-of-Work (PoW), the non-mining node can generate a mining transaction and provide it to the successful mining node. This mining transaction transfers control of the resources to the successful mining node under the condition of public knowledge. It should be noted that the mining transaction is generated only by the non-mining node in response to determining that the mining node has provided a verifiable proof of knowledge confirming that the PoW solution has been determined by the mining node.

[0031] One of the challenges facing blockchain networks is the need for rapid propagation of transactions and blocks across the network. This requires high-bandwidth connections between nodes. In some cases, bandwidth can be limited, leading to propagation delays and consequently network bottlenecks. It would be beneficial to provide methods and systems for mining blockchain transactions that mitigate the problems caused by low-bandwidth connections at mining nodes.

[0032] By offloading most of the bandwidth consumption to non-mining nodes, the methods and systems described in this paper can be used to minimize the data sent to and received from mining nodes.

[0033] Some of the systems and methods described below enable the separation of storage and mining functions, and provide a mining market in which mining nodes can compete to solve the Proof-of-Work (PoW) of blocks prepared by non-mining nodes. It may not be necessary to provide mining nodes with complete candidate blocks, and it may be possible to rely on non-mining nodes to propagate completed blocks. In some cases, non-mining nodes may provide mining nodes with partial candidate block headers (e.g., providing Merkle root and other fields, but not random numbers and timestamps). Mining nodes can then insert random numbers and timestamps and hash the candidate block headers to search for PoW solutions. Attached Figure Description

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

[0035] Figure 1 A simplified example of a partial blockchain network with segmented mining nodes and storage / verification nodes is shown;

[0036] Figure 2 An example method for mining on a blockchain network is illustrated in the form of a flowchart;

[0037] Figure 3 An example Merkle tree is illustrated graphically.

[0038] Figure 4 Another simplified example of a partial blockchain network with segmented mining nodes and storage / verification nodes is shown;

[0039] Figure 5 This illustrates another example of mining on a blockchain network in the form of a flowchart; and

[0040] Figure 6 A simplified example of computing nodes in a blockchain network is shown in the form of a block diagram.

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

[0042] Separate mining and verification to minimize bandwidth usage

[0043] Now for reference Figure 1 , Figure 1An example of a partial blockchain network 100 is illustrated graphically. The partial blockchain network includes storage and verification nodes 102 (i.e., non-mining nodes) and multiple mining nodes 104 (labeled 104a, 104b, 104c, and 104n, respectively). Storage and verification nodes 102 construct candidate blocks. This includes determining the Merkle root and partially completing the candidate block header. The random number and timestamp fields in the candidate block header may be empty. Storage and verification nodes 102 provide each mining node 104 with at least the header of the candidate blocks, and these mining nodes 104 perform a Proof-of-Work (PoW) search by inserting random numbers and timestamps and hashing the candidate block headers. In some implementations, storage and verification nodes 102 may also provide the TxIDs of the transactions included in the block, along with the candidate block headers. In some example implementations, storage and verification nodes 102 may act as mining pool managers and may assign a portion of the random number search space to each mining node 104. In some example implementations, the storage and verification nodes 102 do not specify any part of the random number search space, and the mining nodes 104 can compete with each other in terms of finding solutions. In some example implementations, one or more mining nodes 104 form a mining pool.

[0044] If one of the mining nodes 104 finds a Proof-of-Work (PoW) solution (i.e., finds a random number and timestamp that produce a double-hash block header less than the difficulty setting), that mining node 104 sends a message to the storage and verification node 102. Specifically, the mining node 104 sends a single hash of the block header to the storage and verification node 102. The storage and verification node 102 can then hash the single hash to prove that the result satisfies the difficulty setting, thus verifying that the mining node 104 has found a PoW solution. Subsequently, the storage and verification node 102 can create an atomic swap event with the mining node 104 by generating a transaction to transfer control of the resources to the mining node 104, the transaction having an output locked due to the need to reveal the PoW solution.

[0045] Successful mining node 104 verifies that the transaction is valid, and if the transaction is valid, mining node 104 provides the POW solution to storage and verification node 102, which then verifies and broadcasts the block.

[0046] Storage and verification node 102 has received a single hash, H(φ), of the POW solution. Therefore, storage and verification node 102 can establish a locking condition on the output of the mining node's transaction, requiring a candidate block header φ with a random number and a timestamp, which, when double-hashed, will be compared with the double hash H(φ) of the POW solution. 2(φ) Matching. In order to access the output of the mining node transaction, the mining node 104 must reveal the block header φ as the basis of the knowledge proof H(φ), which is a statement that the mining node 104 has solved the POW, and is sent by the mining node 104 to the storage and verification node 102.

[0047] It will be understood that mining node 104 can retain its disclosure of a POW solution until another mining node has mined a block, and even then, by subsequently revealing a POW solution that is no longer valuable, mining node 104 can still access the output of mining node transactions. However, storage and verification node 102 has already provided the same candidate block to multiple mining nodes, each searching for a solution. In the case where a second mining node 104 provides another solution, storage and verification node 102 then creates a second mining node transaction because the second mining node 104 has spent the same UTXO. The first mining node 104 to reveal its solution will have control over the UTXO, while other mining node transactions will be invalidated.

[0048] Now for reference Figure 2 , Figure 2 A flowchart illustrating an example method 200 for mining on a blockchain network is shown. Method 200 begins with operation 202, in which storage and verification nodes (i.e., non-mining nodes) construct candidate blocks that include transactions from a mempool. The candidate blocks also include a generative transaction whose output allocates new resources for the control of the storage and verification nodes. In operation 204, the storage and verification nodes transmit at least the candidate block header to multiple mining nodes. The term "mempool" refers to a collection of pending transactions in a blockchain network that have not yet been included in mined blocks. Any of the multiple nodes in the network (such as full nodes, verification nodes, storage nodes, or other types of nodes) can maintain a copy of the mempool, which is continuously updated as new transactions propagate through the network and as blocks are mined.

[0049] Mining nodes search for a Proof-of-Work (PoW) solution, which is a random number and a timestamp, and will generate a double-hash candidate block header that satisfies the difficulty setting. As shown by operations 208 and 210, mining nodes continue hashing until they find a solution, or until they are notified that another mining node has found and propagated the solution (either to the same candidate block or to another candidate block).

[0050] If one of the mining nodes finds a solution, in operation 212, that mining node sends a hash of the candidate block header, including the POW solution, to the storage and verification nodes. In operation 214, the storage and verification nodes evaluate whether the claimed solution meets the difficulty setting by rehashing the claimed solution to create a double hash of the candidate block header and evaluating whether this result is lower than the value set by the difficulty setting. If it is not lower than the value set by the difficulty setting, the search continues.

[0051] If the POW solution is valid, the storage and verification nodes generate a mining node transaction in operation 216. The mining node transaction includes an output locked by the public key associated with the successful mining node, and this output is locked to require that the candidate block header be a hashed candidate block header provided by the mining node. The mining node transaction is sent to the successful mining node. The mining node verifies the validity of the mining node transaction in operation 218, and once verified as valid, the mining node publishes the POW solution in operation 220. This may include sending the candidate block header to the storage and verification nodes. This may include sending a random number and a timestamp to the storage and verification nodes. Subsequently, the storage and verification nodes propagate the complete block on the blockchain network.

[0052] The aforementioned method involves establishing atomic swaps after one of the mining nodes has proven it has found a solution to the Proof-of-Work (PoW). Another approach can be used to address the technical problem of bandwidth limitations and enable the separation of mining, storage, and verification functions. In one aspect, atomic swaps can be established before mining activity. In this aspect, storage and verification nodes can specifically construct candidate blocks for each mining node. Each candidate block includes a mining node transaction with an output that can be unlocked by the mining node, i.e., an output locked by the public key associated with that mining node. To prevent mining nodes from exploiting the mining node transaction before solving the PoW, the input to the mining node transaction can be a source transaction from the same candidate block, meaning the mining node transaction can only be verified when the candidate block is mined. Properties of Merkle trees can be utilized to allow mining nodes to verify that a candidate block has been correctly constructed and includes the mining node transaction, even if the mining node does not have a complete copy of the candidate block.

[0053] In this respect, the storage and mining nodes provide the mining nodes with a partial candidate block header, including the Merkle root, but do not provide the complete block details, specifically the source transaction. However, in order for the mining node to verify that the candidate block has been correctly created and includes the mining node's transaction, the storage and mining nodes provide the mining node with a copy of the mining node's transaction and a Merkle proof of the mining node's transaction (the Merkle proof may also be referred to as the Merkle path in this document). Once the mining node finds a solution, it sends the solution (a random number and a timestamp, or equivalently, a candidate block header including these values) to the storage and verification nodes. The storage and verification nodes verify that the solution is valid and subsequently propagate the block on the blockchain network. Subsequently, both the source transaction and the mining node's transaction are valid on the blockchain, and the mining node's transaction output is available to the mining node.

[0054] Although the following description provides details about Merkle trees and uses the terms Merkle root and Merkle path, this application is not necessarily limited to Merkle trees. The term "payload summary" can be used to refer to a hash value or parameter that effectively serves as the content of the payload, thus proving the content of the payload. A Merkle root is an example of a payload summary. The term "summary path" can be used to refer to data that can be used, together with the payload summary, to prove that a particular data item is included in the payload from which the payload summary is generated. A Merkle path is an example of a summary path.

[0055] Before providing more details about the example system and methods, a brief explanation of Merkle trees and proofs is provided.

[0056] Merkel tree and proof

[0057] refer to Figure 3 ,Should Figure 3 An example of a Merkle tree 300 is shown. Each node in the tree has been assigned an index pair (i,j) and is represented as N(i,j). The indices i and j are simply numeric labels associated with a specific position in the tree. Each node can be referenced by its index pair (i,j), and each node can have an associated value given by the following formula:

[0058]

[0059] Where k = (i + j - 1) / 2 and H is the cryptographic hash function.

[0060] It is important to note that the case of i=j corresponds to a leaf node, which is only the corresponding i-th data block D. iThe hash of i ≠ j corresponds to an internal node or root node, which is generated by recursively hashing and concatenating the child nodes in the tree until a specific node or root is reached.

[0061] The construction of a Merkle tree requires the use of a cryptographic hash function. Generally, a hash function is considered cryptographically secure if it possesses the following properties:

[0062] 1. Pre-image resistant – Given h = H(m), it is computationally difficult to find m;

[0063] 2. Second preimage conflict—Given h = H(m) and m, it is computationally difficult to find m′ such that H(m′) = h; and

[0064] 3. Collision resistant – It is computationally difficult to find a pair of messages m and m′ such that H(m) = H(m′).

[0065] The transaction identifier TxID is generated using this hash function, and therefore inherits the properties of the hash function digest. It can be seen that Merkle root and TxID have very similar properties.

[0066] In most applications, the primary function of Merkle trees is to help prove certain data blocks D. i It is a list or set of N data blocks Members in. Given Merkle root and candidate data block D i In this case, this can be regarded as "proof of existence" of the block in the set.

[0067] This proof mechanism is called Merkel proof, and it involves obtaining a set of hashes, which is called a set of hashes for a given block of data D. i Merkle paths to the root R. A Merkle path to a data block is the minimum set of hashes required to reconstruct the root R by repeating hashing and concatenation. Sometimes, a Merkle path to a data block is called the "verification path" of the data block.

[0068] If the verifier knows all data blocks D1,…,D N The existence proof can then be performed simply. However, this requires significantly more storage overhead than the Merkel path and necessitates that the entire dataset be available to the verifier.

[0069] Starting with Merklegen R, it can be proven that data block D1 belongs to the set using the following example procedure.

[0070] 1. Obtain the Merkle root R and the Merkle path Γ. In this case, Γ is the set of hashes: Γ = {N(2, 2), N(3, 4), N(5, 8)}

[0071] 2. Use D1 and Γ to compute Merkel's proof, as shown below:

[0072] (a) Hash the data block (or double hash, depending on the implementation) to obtain N(1,1) = H(D1);

[0073] (b) Concatenate with N(2,2) and perform hashing to obtain

[0074] N(1,2)=H(N(1,1)||N(2,2));

[0075] (c) Concatenate with N(3,4) and perform hashing to obtain

[0076] N(1,4)=H(N(1,2)||N(3,4));

[0077] (d) The root is obtained by concatenating it with N(5, 8) and performing hashing.

[0078] R′=N(1,8)=H(N(1,4)||N(5,8));

[0079] (e) Compare the calculated root R′ with the root R. If R′ = R, then data block D1 is in the tree.

[0080] Perform a Merkle proof for a given block D1 and root R, and efficiently traverse the Merkle tree "upwards" using only the minimum number of necessary hash values.

[0081] Methods and apparatus for safe symbiotic excavation

[0082] In the following examples, the storage and verification nodes, as well as the mining node, establish atomic swaps before participating in any mining activity. In these examples, the candidate block created by the storage and verification nodes is specific to that mining node. The candidate block includes a mining node transaction that transfers control of the resource to the mining node. However, the input to the mining node transaction is also the source transaction within the candidate block, and this source transaction typically has not yet been broadcast on the blockchain network. The mining node is not provided with the complete candidate block, and specifically, not with the complete source transaction. This prevents the mining node from executing the mining node transaction unless the candidate block itself is mined, i.e., unless the mining node successfully finds the Proof-of-Work (PoW) of the candidate block.

[0083] Before participating in mining, the mining node receives a portion of the candidate block header, including the Merkle root, from the storage and verification nodes. The mining node also receives at least a copy of the mining node transaction and its Merkle path. Based on the received data, the mining node verifies whether its transaction is included in the candidate block by performing a Merkle proof.

[0084] Now for reference Figure 4 , Figure 4 An example method 400 for mining in a blockchain network using separate mining nodes and verification nodes is illustrated in the form of a flowchart. Figure 4 Some of the operations shown are performed by the storage and verification nodes, while others are performed by the mining nodes. The storage and verification nodes have a network connection to at least one mining node.

[0085] In Operation 402, the storage and validator nodes construct a partial candidate block for one of the mining nodes. In some cases, the storage and validator nodes may construct multiple candidate blocks, each for a different mining node. In some implementations, candidate blocks may contain the same transactions, but the mining node transactions are unique to each mining node. As part of constructing the candidate block, the storage and validator nodes compute the block's Merkl root and record the Merkl root value in the partially completed candidate block header. The candidate block header is only a partial candidate block header because it includes the version, previous block hash, Merkl root, and nBits value, but does not include the timestamp and random number.

[0086] symbol It can be used for completed valid blocks, symbols It can be used for partial candidate blocks that are incomplete and lack a timestamp T. X And a valid proof solution in the form of a random number X. Similarly, the symbol φ can be used to represent the block header, the symbol φ * It can be used to represent partial candidate block headers.

[0087] The candidate block header includes a creation transaction with outputs associated with the public keys of the storage and verification nodes. In other words, the creation transaction allocates resources to the storage and verification nodes. It will be understood that some blockchain protocols stipulate that resources allocated through a creation transaction cannot be transferred for a period of time after creation (typically measured in block height). In some cases, this may be referred to as the "creation expiration date."

[0088] The mining node transaction in a candidate block includes an output, which is locked using the public key of the mining node associated with the mining node transaction and the candidate block. The input to the mining node transaction is the output of the source transaction included in the candidate block. The source transaction output is controlled by the storage and verification nodes, which digitally sign the input to the mining node transaction. It should be noted that the source transaction is not included in the blockchain network's mempool and is not otherwise publicly available. Broadcasting only occurs if one of the candidate blocks of the storage and verification nodes is successfully mined. This prevents inputs from any mining node transaction from becoming valid unless and until one of the candidate blocks of the storage and verification nodes is mined, and thus prevents mining nodes from easily broadcasting their mining node transactions on the blockchain network, as verification of the mining node transaction is expected if the mining node fails to mine its candidate block.

[0089] The mining node has mining transactions available to it because, in operation 404, the storage and verification nodes send to the mining node a portion of the candidate block header, a copy of the mining node transaction from that candidate block, and the Merkel path of the mining node transaction.

[0090] In Operation 406, the mining node verifies whether its transaction is included in the candidate block associated with the received candidate block header. The mining node performs this verification by determining a Merkle proof using its transaction and its Merkle path (both received from the storage and verification nodes). The Merkle proof should produce a value that matches the Merkle root included in the partial candidate block header. If this value is produced, and if the mining transaction has an output associated with the mining node's public key, the mining node has verified that the provided partial candidate block header is legally constructed.

[0091] In some implementations, the storage and verification nodes can also provide the mining nodes with the hash of the source transaction and the Merkle path of the source transaction: H(T) Source ), Γ(R,T Source It should be noted that the storage and verification nodes do not provide the actual source transaction, thus not compromising security; however, the mining node can still verify the existence of the mining node's transaction input in the candidate block by determining the Merkle proof of the source transaction. Recall that the transaction's TX... ID This is given by the hash of the transaction. Therefore, although the mining node does not have the actual source transaction, it has the hash of the transaction, so the mining node can verify whether the source transaction is correctly referenced at the input of the mining node's transaction, and whether the source transaction exists in the candidate block.

[0092] Therefore, even though the storage and verification nodes provide the mining nodes with the hash and Merkle path of the source transaction, the amount of data sent by the storage and verification nodes to the mining nodes is very small compared to sending the entire candidate block. The data sent can be represented by the following tuple:

[0093] V = (R, T) Miner ,H(T Source ),Γ(R,T Miner ),Γ(R,T Source ))

[0094] In operation 408, after verifying the received data, the mining node then participates in the Proof-of-Work (PoW) search for candidate blocks. That is, the mining node inserts a random number and a timestamp into a portion of the candidate block header and hashes it according to the governing blockchain protocol in an attempt to find a value less than the difficulty threshold. As shown in operations 410 and 412, the candidate block header is continuously hashed with iterative random values ​​and timestamps until another entity finds a block, or until the mining node succeeds.

[0095] If the mining node successfully finds the Proof-of-Work (PoW), then in operation 414, the mining node sends the solution (e.g., a random number and timestamp, or equivalently, the header of a completed block) to the storage and verification nodes. The storage and verification nodes 416 quickly verify the validity of the solution and then broadcast a new block on the blockchain network.

[0096] As a result of finding a new block, the creation transaction of the storage and verification nodes is incorporated. The source transaction and the mining node transaction are also incorporated, which both provides resources to satisfy the input of the mining node transaction and transfers control of the resources to the mining node by means of the output of the mining node transaction, which is locked using the mining node's public key.

[0097] Understandably, the entire interaction between the storage and verification nodes and the mining nodes is an atomic exchange. A bidirectional information asymmetry is established between the two nodes. This asymmetry is resolved atomically when the proof-of-work is found and provided to the storage and verification nodes. This bidirectional information asymmetry is actually achieved through the careful construction of a Merkle tree, where the root R of the Merkle tree exists in the header φ of the incomplete block. * middle.

[0098] The example process described above implements a separation between mining and storage / verification functions. This separation allows for the location of mining nodes in low-bandwidth connectivity areas. It also achieves a separation of ownership and control, meaning that storage and verification nodes can operate independently of the mining node without the need for a trusted third party, as information asymmetry is created to ensure that neither node can exploit or cheat the other.

[0099] Now for reference Figure 5 , Figure 5 A simplified example blockchain network 500 is illustrated graphically. This simplified example network 500 includes storage and verification nodes 502 and mining nodes 504. It will be understood that the storage and verification nodes 502 are interconnected via high-bandwidth, fast network connections. The storage and verification nodes 502 in this example are sufficiently connected to achieve a small-world network. Mining nodes 504 are each connected to at least one storage and verification node 502. The connections between mining nodes 504 and storage and verification nodes 502 are not necessarily high-bandwidth connections, as the data communication volume on these connections is relatively small.

[0100] In some cases, one or more mining nodes 504 may be connected to at least two storage and verification nodes 502. This allows a mining node 504 to provide computing power for mining to one of the storage and verification nodes 502, enabling the mining node 504 to evaluate competing proposals from these storage and verification nodes 502 based on the mining node transactions included in their respective candidate blocks. Similarly, a storage and verification node 502 may be connected to multiple mining nodes 504 to request participation in mining from multiple possible mining nodes 504. This effectively creates market competition reflected in the mining node transactions provided by the storage and verification nodes 502.

[0101] Since no high-bandwidth connection is required between the mining node 504 and the storage and verification node 502, the storage and verification node 502 can be located where resources are optimally available to enable its functions (such as high-bandwidth, low-latency connections to other storage and verification nodes 502). The mining node 504 can be located where resources best suited to its needs (such as sufficient low-cost power for operating large mining rigs) are available, without needing to be in the same location as the storage and verification node 502.

[0102] Now for reference Figure 6 , Figure 6A simplified computing device 600 according to an example of this application is shown in block diagram form. The computing device 600 can perform one or more of the functions described above. In some examples, the computing device 600 may be a mining node. In some examples, the computing device 600 may be a storage and verification node.

[0103] The computing device 600 includes a processor 602, which may include one or more microprocessors, application-specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The computing device 600 may also include a memory 604 and a network interface 606. The memory 604 may include persistent and non-persistent memory for storing values, variables, and, in some cases, program instructions executable by the processor.

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

[0105] The various embodiments presented above are merely examples and do not imply limitation of the scope of this application. The innovative variations described herein will be apparent to those skilled in the art, and such variations fall within the scope intended to be defined by this application. In particular, features can be selected from one or more of the above-described example embodiments to create alternative example embodiments, which include sub-combinations of features that may not be explicitly described above. Furthermore, features can be selected from one or more of the above-described example embodiments and combined to create alternative example embodiments, which include combinations of features that may not be explicitly described above. Features applicable to such combinations and sub-combinations will be apparent to those skilled in the art upon reading this application in its entirety. The subject matter described herein and in the enumerated claims is intended to cover and include all technically suitable variations.

Claims

1. A computer-implemented method for mining in a blockchain network, the blockchain network comprising non-mining nodes and a plurality of mining nodes, the method comprising: The non-mining node generates a candidate block comprising multiple transactions, the multiple transactions including source transactions and mining node transactions, the source transactions including a first output associated with the non-mining node, the mining node transactions including the first output of the source transactions as input, and the mining node transactions including a second output associated with a first mining node; Determine the payload summary of the candidate blocks; Send the payload summary, the mining node transaction, and the first summary path of the mining node transaction to the first mining node; Receive the proof-of-work solution of the candidate block from the first mining node; as well as The candidate block is propagated on the blockchain network.

2. The method according to claim 1, wherein, Sending does not include sending the source transaction to the first mining node.

3. The method according to claim 1 or 2, wherein, Sending includes sending a candidate block header, which includes the payload digest.

4. The method according to claim 1, wherein, Before receiving the proof-of-work solution of the candidate block, the source transaction and the mining node transaction are not propagated on the blockchain network and are not included in the mempool.

5. The method according to claim 1, wherein, Sending includes sending the hash of the source transaction and the second digest path of the source transaction to the first mining node.

6. The method according to claim 1, wherein, The candidate blocks also include several transactions that generate new transactions, which include generated outputs associated with the non-mining node.

7. The method according to claim 1, further comprising: At the first mining node, the mining node transaction is verified to be included in the candidate block based on the payload digest and the first digest path.

8. The method according to claim 7, wherein, Sending includes sending the hash of the source transaction and a second digest path of the source transaction to the first mining node, and wherein verification includes verifying whether the source transaction is included in the candidate block based on the payload and the second digest path.

9. The method according to claim 1, wherein, The payload digest includes a Merkle root, and the first digest path includes a first Merkle path, which includes a minimal set of hashes for reconstructing the Merkle root from the mining node transaction.

10. The method according to claim 1, wherein, The generation includes: A second candidate block is generated by the non-mining node, comprising a second plurality of transactions, the second plurality of transactions including the source transaction and a second mining node transaction, the second mining node transaction including a first output of the source transaction as input, and the second mining node transaction including another output associated with a second mining node, which is different from the first mining node.

11. A computer-implemented method for mining in a blockchain network, the blockchain network comprising non-mining nodes and mining nodes, the method comprising: At the mining node, the candidate block header, the payload digest of the candidate block, the mining node transaction, and the first digest path of the mining node transaction are received from the non-mining node. The mining node transaction is verified to be included in the candidate block based on the payload digest and the first digest path. The candidate block header is repeatedly mined using consecutive random values ​​inserted into it until a proof-of-work is found. as well as Send at least a random value corresponding to the proof of work to the non-mining node.

12. A computer-implemented method for mining in a blockchain network, the blockchain network comprising non-mining nodes and a plurality of mining nodes, the method comprising: The non-mining nodes generate candidate blocks containing multiple transactions; At least the candidate block header of the candidate block shall be sent to the plurality of mining nodes; The hash of the proof-of-work solution is received from the first mining node among the plurality of mining nodes, the proof-of-work solution including the candidate block, the candidate block including a random number; The hash of the proof-of-work solution is hashed to generate the proof-of-work result, and it is determined whether the proof-of-work result meets the difficulty setting. In response to the proof-of-work result satisfying the difficulty setting, a mining node transaction is generated, the mining node transaction having an output associated with the first mining node and unlocked by the proof-of-work; Receive the proof-of-work solution from the first mining node; as well as The candidate block is completed and propagated on the blockchain network.

13. A computer-implemented method for mining in a blockchain network, the blockchain network comprising non-mining nodes and mining nodes, the method comprising: The mining node receives the candidate block header from the non-mining node, and the candidate block includes multiple transactions; The candidate block header is repeatedly mined using consecutive random values ​​inserted into it until a proof-of-work is found. Send the hash of the proof of work to the non-mining node; Receive mining node transactions from the non-mining node, the mining node transactions having outputs associated with the mining node and unlocked by the proof-of-work; as well as The mining node transactions are propagated on the blockchain network.

14. A computing device for implementing storage and verification nodes in a blockchain network, the blockchain network including multiple mining nodes, the computing device comprising: One or more processors; Storage device for storing blockchain data; as well as Computer-executable instructions stored in the memory, which, 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 storage and verification nodes in a blockchain network, the blockchain network comprising a plurality of mining nodes, the processor-executable instructions comprising instructions which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 13.

Images