METHOD AND SYSTEM FOR MINING BLOCKCHAIN ​​TRANSACTIONS PROVIDED BY VALIDATOR NODES

Abstract

To provide a validator node and method of operating the validator node for processing block-chain transactions.SOLUTION: A validator node typically provides multiple mining nodes with access to a set of unconfirmed transactions by providing a hash of the transaction in exchange for a token from each of the mining nodes. Validator nodes refund tokens to their mining nodes and keep the remaining tokens, if one of the multiple mining nodes successfully mines a block containing a set of unconfirmed transactions. If a miner other than one of the multiple mining nodes succeeds in mining a block before any of the multiple mining nodes is able to mine a block containing a set of unconfirmed transactions, the validator node will move a change token to each of multiple mining nodes.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to the problem of allocating network resources such as processing power and time, and more particularly to blockchain transactions. More specifically, the present invention relates to methods and devices for improving blockchain mining speed and capacity and facilitating the mining of a set of approved blockchain transfers. [Background technology]

[0002] This document uses the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers, including, but not limited to, consensus-based blockchain and transaction chain technologies, private (permissioned) and public (un-permissioned) ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While reference may be made herein to Bitcoin for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are also within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a decentralized, computer-based system composed of blocks, which in turn consist of transactions. Each transaction (Tx) is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, thereby chaining blocks together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in the transaction's inputs and outputs, which specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] A network node that receives a new transaction attempts to quickly push the transaction to other nodes in the network. Before a new transaction can be sent to other nodes, it is "validated," meaning that it is checked against a set of criteria to ensure that it meets the basic requirements for a proper transaction according to the applicable blockchain protocol.

[0005] To be written to the blockchain, transactions are assembled into blocks by mining nodes ("miners") designed to collect transactions and form them into blocks. Miners then attempt to complete a "proof of work" for the block (specifically, the block header). Miners across the blockchain network compete to be the first to assemble a block of transactions and its associated proof of work. Successful miners add their confirmed block to the blockchain, which then propagates through the network so other nodes that maintain copies of the blockchain can update their records. These nodes that receive the block also "validate" the block and all transactions within it to ensure compliance with the formal requirements of the protocol.

[0006] One of the bottlenecks associated with blockchain implementations is the delay associated with transaction confirmation. In the current Bitcoin protocol, each node that receives a new transaction confirms it before sending it to other nodes. Each full node also stores transactions locally in a mempool. Mining nodes also maintain a mempool of unconfirmed transactions from which they can assemble the next block that attempts to complete the proof of work. If they successfully complete a block that is added to the blockchain, mining nodes are compensated for their work through transaction fees (and through "minting" new Bitcoins with each block, although the amount of coins available for minting with each block is decreasing to zero over time).

[0007] It would be advantageous to enable or facilitate the use of blockchain-based networks such as Bitcoin for high-volume, high-speed transfers. However, a transaction throughput of approximately 3 per second (for one protocol at the time of writing) is insufficient to handle such electronic transfers, which currently operate at a volume of approximately 50,000 transactions per second. Therefore, it is desirable to find a solution to the speed and scalability constraints that currently limit the ability of blockchains to process large volumes of transactions. One of the scalability constraints is maintaining a memory pool for large volumes of transactions without sacrificing speed and security. These technical issues are difficult to solve. Summary of the Invention

[0008] Such a solution is currently being considered.

[0009] Thus, in accordance with the present invention, there is provided a method and apparatus as defined in the appended claims.

[0010] This application may generally relate to the allocation of network resources, such as processing power and time. The examples and embodiments provided below may use the (Bitcoin) blockchain as an example of a network in which resources need to be controlled or allocated. In particular, the present invention may address the problem of how to control future requests for resources in an efficient and secure manner. This has long been a technical challenge in network environments and can have a significant negative impact on the overall performance of the network and its ability to produce desired results within an acceptable timeframe. Another long-standing technical challenge for network environments is the problem of scalability. The issue of resource allocation and scalability is not a trivial problem.

[0011] In one or more embodiments, the present invention may address, at least in part, these technical problems. The present invention may involve the use of tokens that are assigned to different parties or participants (nodes) in a network. Control or ownership of tokens may be used as a mechanism to indicate the ability and / or availability of a network node to perform network-related tasks. Additionally or alternatively, this may be used to control, direct, or otherwise influence the activity of a node to ensure that computational resources are provided for assigned tasks.

[0012] This application may describe and disclose network nodes that belong to a decentralized network, such as a blockchain network. In a preferred embodiment, the network is a consensus-based blockchain network. Nodes may be referred to as "validator nodes." Validator nodes may maintain a large memory pool of unconfirmed transactions. The network may also include a mechanism that provides mining nodes with access to unconfirmed transactions from the memory pool. Centralizing the memory pool among a group of validator nodes, which may in some cases use decentralized storage of the memory pool, improves scalability for handling large transaction volumes. However, centralizing the memory pool can cause problems that impair mining nodes' access to unconfirmed transactions for constructing new blocks. Therefore, to expedite transaction processing, mining nodes focus solely on mining and are provided with a set of transactions worked on by the validator nodes. To enable access to transactions, validator nodes may obtain one or more tokens (which may be conveniently referred to as "deposits") from each mining node in a set of miners. Tokens (deposits) or ownership / control thereof may be returned from a validator node to a mining node if the mining node successfully mines a block. This transfer may be back to the source, i.e., the node that provided the tokens to the validator. An unsuccessful mining node may lose control of its tokens to the validator node, which may then pass control over the tokens to another node. A miner's tokens may be kept or lost if one of the other miners in the network is successful. In some cases, if no miner in a set of miners successfully mines a block, the validator node may return control over the tokens to the miner. In some cases, the validator node may modify the tokens before returning control to the miner.A token may be a digital asset. In some cases, for example, it may be part of a cryptocurrency such as Bitcoin or an alternative cryptocurrency. It may form part of or be referenced within a blockchain transaction (Tx).

[0013] One of the challenges in implementing the above validator node-initiated mining process in a real blockchain network is maintaining security of control over tokens to prevent loss or theft. In this regard, the present application describes methods and systems for controlling token distribution and control in a validator node-initiated mining process. The above methods and systems may include constructing blockchain transactions for token distribution with specific locking scripts to ensure security and loss prevention.

[0014] In further or alternative aspects, the present application may describe a computer-implemented method for processing blockchain transactions within a network of nodes. The nodes may include a validator node configured to approve unconfirmed transactions and maintain a pool of unconfirmed transactions, and a plurality of mining nodes configured to compete to complete blocks. The method may be performed by the validator node. The method may include providing a set of unconfirmed transactions to the plurality of mining nodes in exchange for tokens from each of the mining nodes; if one of the plurality of mining nodes successfully mines a block containing the set of unconfirmed transactions, returning the tokens to one of the plurality of mining nodes and retaining the remaining tokens; and if a miner other than one of the plurality of mining nodes successfully mines a block before any of the plurality of mining nodes can mine the block containing the set of unconfirmed transactions, transferring a change token to each of the plurality of mining nodes. In some implementations, the providing step includes generating a transaction for the pool of tokens from each of the mining nodes as the pooled tokens and a transaction to return the tokens and transfer the modification token, where the transaction for the pool locks control over the pooled tokens such that it requires a signature from at least one of the validator node and the mining node. In some implementations, the transaction for transferring the modification token locks control over the pooled tokens such that it requires a signature from each of the validator node and the mining node and a determination that the block height of the blockchain has increased.

[0015] In some implementations, before a miner is provided access to the set of transactions, the validator node generates a deposit transaction in which each of the mining nodes transfers control over its respective token and pools the set of tokens to the pooled output address, generates a respective claim transaction for each of the mining nodes from the pooled output address that transfers control over one of the tokens to that mining node and transfers the remaining tokens to the validator node, generates a refund transaction from the pooled output address that transfers the modification token to each mining node and transfers the modification token to the validator node, and obtains signatures from each of the mining nodes for each mining node's deposit transaction, refund transaction, and each claim transaction. In some of these implementations, the unlock script for each pooled output address of each claim transaction requires a secret value associated with the mining node to which each claim transaction should transfer tokens. In some of these implementations, if a mining node successfully mines a block containing a set of unconfirmed transactions, the method further includes extracting a secret value from the block and using the secret value to unlock each claim transaction associated with one of the plurality of mining nodes.

[0016] In some implementations, providing the set of unconfirmed transactions to a plurality of mining nodes in exchange for tokens includes broadcasting the deposit transactions on a blockchain network after obtaining signatures.

[0017] In some implementations, if the mining node successfully mines a block containing a set of unconfirmed transactions, the method further includes returning the tokens to one of the plurality of mining nodes by broadcasting a respective claim transaction associated with one of the plurality of mining nodes and retaining the remaining tokens.

[0018] In some implementations, transferring the modification token to each of the mining nodes includes broadcasting a refund transaction on the blockchain network. In some implementations, the modification token is determined as the pooled tokens minus the modification token.

[0019] In some implementations, providing the set of unconfirmed transactions to the plurality of mining nodes includes providing the mining nodes with a hash of the set of transactions that the mining nodes may attempt to solve the proof of work against. For example, the hash may be a Merkle root.

[0020] In an alternative expression, the present invention may provide a method of processing blockchain transactions within a network of nodes, the nodes including a validator node configured to approve unconfirmed transactions and maintain a pool of unconfirmed transactions, and a plurality of mining nodes configured to compete to complete blocks, the method being implemented on the validator node; providing a set of unconfirmed transactions to a plurality of mining nodes in exchange for a deposit from each of the mining nodes; If one of the plurality of mining nodes successfully mines a block containing a set of unconfirmed transactions, refunding the deposit to one of the plurality of mining nodes and keeping the remaining deposit; If a miner other than one of the plurality of mining nodes successfully mines a block before any of the plurality of mining nodes can mine a block containing a set of unconfirmed transactions, transferring the deposit minus a confirmation fee to each of the plurality of mining nodes; Includes:

[0021] In a further or alternative aspect, the present application describes a validator node configured to facilitate rapid confirmation of blockchain transactions. The validator node includes a processor, a memory that stores at least a portion of a pool of unconfirmed transactions, a network interface, and a blockchain application that includes processor-executable instructions that, when executed by the processor, cause the processor to perform any one or more of the methods described herein.

[0022] In a further or alternative aspect, the present application describes a non-transitory processor-readable medium storing processor-executable instructions for processing blockchain transactions, the processor-executable instructions, when executed by a processor, causing the processor to perform any one or more of the methods described herein.

[0023] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0024] [Figure 1] 1 illustrates an exemplary network of nodes for implementing a blockchain network. [Figure 2] 1 shows a diagram of an exemplary blockchain network including validator nodes. [Figure 3] FIG. 1 shows a diagram of an example blockchain network with an overlay network of validator nodes. [Figure 4] 1 shows a diagram of an exemplary network of validator nodes and multiple mining nodes that maintain a distributed memory pool. [Figure 5] 1 illustrates, in flowchart form, one exemplary method for validator-initiated block mining. [Figure 6] 10 illustrates, in flowchart form, another exemplary method for validator-initiated block mining. [Figure 7] 10A-10C schematically illustrate an example deposit transaction, an example claim transaction, and an example refund transaction for one implementation of validator node-initiated mining. [Figure 8] This is a flowchart showing how to mine blocks in response to validator node invitations. [Figure 9] 1 shows a simplified example of a validator node in block diagram form. DETAILED DESCRIPTION OF THE INVENTION

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

[0026] 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 listed elements only, any subcombination, or all of the elements, without necessarily excluding additional elements and without necessarily requiring all of the elements.

[0027] Reference is first made to FIG. 1, which illustrates in block diagram form an exemplary network related to a blockchain, which may be referred to herein as blockchain network 100. Blockchain network 100 is a peer-to-peer open membership network in which anyone may join without an invitation or consent from other members. Distributed electronic devices running an instance of the blockchain protocol on which blockchain network 100 operates may participate in blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrency.

[0028] The electronic devices that run the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smart watches, or other electronic devices.

[0029] The nodes 102 of the blockchain network 100 are coupled to one another using suitable communication technologies, which may include wired and wireless communication technologies. Often, the blockchain network 100 is implemented at least in part over the Internet, and some of the nodes 102 may be located in geographically dispersed locations.

[0030] Nodes 102 maintain a global ledger of all transactions on the blockchain, grouped into blocks, each containing a hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 102 may store a full or partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102 to ensure the validity of the global ledger is maintained. The details of the implementation and operation of blockchain networks, such as those using the Bitcoin protocol, are recognized by those skilled in the art.

[0031] Each transaction typically has one or more inputs and one or more outputs. Script embedded in the inputs and outputs specifies how the transaction's outputs can be accessed, and by whom. A transaction's output may be an address to which a value is transferred as a result of the transaction. This value is then associated with that output address as an unspent transaction output (UTXO). Subsequent transactions may then reference that address as an input to use or distribute that value.

[0032] Nodes 102 may be of different types or categories depending on their function. It has been suggested that there are four basic functions associated with a node 102: wallet, mining, full blockchain maintenance, and network routing. Variations of these functions may exist. A node 102 may have more than one function. For example, a "full node" provides all four functions. A lightweight node may, for example, be implemented as a digital wallet and may feature only wallet and network routing functions. A digital wallet may track block headers rather than storing the complete blockchain, which serve as an index when querying blocks.

[0033] As described above, mining nodes (“miners”) compete to create the next block in the blockchain. To assemble a block, a miner builds the block as a set of transactions from a pool of unconfirmed transactions (“mempool”). It then attempts to complete a proof-of-work for the assembled block. If the miner can complete the proof-of-work before receiving notification that other miners have created blocks and completed their proof-of-work, the miner propagates the block by sending it to peer nodes on the network. These nodes approve the block and then send it to other nodes in the network. If the miner receives notification that other blocks are completed before it finishes its proof-of-work, it abandons its efforts and begins attempting to build the next block. Rapid block propagation helps avoid wasted effort for miners and approving nodes.

[0034] In current implementations of blockchains, such as the Bitcoin network, each node that receives a block first approves the block before transmitting it to other nodes. The time required to approve a block slows the block's propagation through the network. It should be noted that while some implementations of blockchains, including evolutions of existing protocols, may provide for block approval by only a subset of nodes rather than every node in the network, block approval by most nodes may still be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0035] Approval of a block involves confirmation that the block meets a set of predetermined criteria according to the applicable blockchain protocol. Exemplary criteria applicable to the Bitcoin protocol are defined in the Bitcoin Core client functions CheckBlock and CheckBlockHeader. In addition to verifying that the block itself meets predetermined criteria, each transaction within a block may be evaluated for compliance with transaction-level criteria. For example, transaction-level criteria applied in the Bitcoin protocol are detailed in the functions AcceptToMemoryPool, CheckTransaction, and CheckInputs.

[0036] Specific examples of block-level standards under the Bitcoin protocol include: The block data structure is syntactically valid. The block header hash is less than the target difficulty (which limits the proof of work). The block timestamp is less than two hours in the future (taking into account time skew). The block size is within the allowed limits. The first transaction (and only the first transaction) is a coinbase-generated transaction. All transactions in a block are valid.

[0037] Specific examples of transaction-level criteria under the Bitcoin protocol include: · The transaction syntax and data structure must be correct. Neither the input list nor the output list is empty. Each output value x and the sum of all outputs is 0 <x<21·10 6 must be within the range. None of the inputs have a null hash. nLockTime is less than or equal to INT_MAX. The transaction size in bytes is greater than or equal to the minimum value and less than the maximum value. The number of signature operations is less than the signature operation limit. The unlock script scriptSig can only push numbers on the stack, and the lock script scriptPubkey must conform to the isStandard format. For each input, if the referenced output is present in another transaction in the pool, the transaction must be rejected. For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY(100) confirmations. For each input, the referenced output must exist and not already be in use. To get the input values, use the referenced output transactions to determine if each input value and the sum are within the tolerance range of the value x, i.e., 0 <x<21·10 6 Verify that: There must be a matching transaction in a block in the pool or in the main branch. The sum of the input values ​​must be greater than or equal to the sum of the output values. The transaction fee must be sufficient to gain entry into an empty block. · The unlock script for each input must approve the corresponding output lock script.

[0038] These example criteria are illustrative and should not be construed as sufficient or necessary for all embodiments, as certain criteria may differ in different protocols and may change over time for a given protocol as changes are made to the protocol. Generally, transaction-level approval criteria are certain characteristics that a transaction must have to be considered valid under the applicable blockchain protocol. Similarly, block-level approval criteria are certain characteristics that a block must have to be considered valid under the applicable blockchain protocol.

[0039] Some evolutions of blockchains may provide for more specialized nodes. By way of example, there may be nodes configured as storage nodes with large amounts of fast-access memory and significant network communication resources. This application proposes and describes a further type or category of node: validator nodes. Validator nodes are designed to focus on the rapid confirmation and propagation of transactions. They do not perform mining functions, but include additional functionality that enables the rapid confirmation and propagation of transactions. As such, they may be dedicated network resources. Validator nodes facilitate the increased transaction volume associated with large-scale payment processing by forming a high-speed transaction merchant network within blockchain network 100, designed to quickly confirm and propagate transactions.

[0040] Each node 102 in the network 100 typically maintains a memory pool containing unconfirmed transactions that it has recognized and that have not yet been incorporated into the blockchain by miners completing proof-of-work. The significant increase in the number of transactions resulting from their use in payment processing increases the amount of transactions stored in each memory pool. With an average transaction (TX) size of 500 bytes and a maximum of 10 4Assuming a transaction rate of TX / s, the memory pool could potentially receive ~400 GB of incoming data daily. All of this data needs to be stored in the unconfirmed transaction memory pool for a variable amount of time. Therefore, in some implementations, a network of validator nodes may use a shared memory pool implemented with a distributed hash table (DHT) to store the pool of unconfirmed transactions, rather than storing the full memory pool at each validator node. In such implementations, mining nodes and / or some other types of nodes may not necessarily need to maintain the full memory pool locally, relieving them of the burden of storing and updating very large pools of unconfirmed transactions. Instead, mining nodes and / or other types of specialized nodes may rely on the network of validator nodes to manage the maintenance of the memory pool.

[0041] Reference is now made to Figure 2, which illustrates an example implementation of a blockchain network of nodes 200. Blockchain network 200 includes a plurality of validator nodes 202 and a plurality of mining nodes 204. In this example, validator nodes 202 are physically and logically distributed throughout network 200. It is understood that blockchain network 200 may include a plurality of other types of nodes, including full nodes, simplified payment verification (SPV) nodes (e.g., wallets), and other specialized nodes with focused roles.

[0042] Another example implementation of a blockchain network 300 is shown in Figure 3, which shows validator nodes 202 forming a (logical) overlay network 302 within the blockchain network 300. The overlay network 302 may be configured to ensure fast communication between validator nodes 202 within the overlay network 302 and to ensure fast access and lookup from a shared memory pool.

[0043] Validator nodes 202 may be implemented to facilitate high-speed transaction confirmation and propagation as part of an architecture for facilitating high-volume payment processing through the blockchain network 200, 300. In this regard, validator nodes 202 focus on transaction confirmation and propagation, while mining nodes 204 focus on block mining, freed from the need to store memory pools or approve transactions.

[0044] This results in a more efficient and faster (blockchain) network. Traffic can traverse the network at an increased rate, thus significantly enhancing data transfer. Thus, the present invention provides an improved blockchain network. It also provides an enhanced network resource allocation mechanism that allows nodes to communicate and provide future availability and services. Future requests that need to be processed by the network can be directed and processed in a time- and resource-efficient manner.

[0045] This reconfiguration of the blockchain network 200, 300 to facilitate rapid transaction processing and the roles of individual nodes can create challenges in ensuring the growth of the blockchain and the non-malicious participation of various nodes. Maintaining the decentralized nature of the blockchain network 200, 300 by avoiding the imposition of control by one or more central authorities is crucial. For the network 200, 300 to function properly, mining nodes 204, validator nodes 202, and other specialized nodes should interact in a manner that allows each node to reliably perform its own function or role and to trust that other nodes reliably perform their functions or roles. Thus, interactions between validator nodes 202 and mining nodes 204 may use multiple transactions to facilitate coordination in pursuit of rapid block mining and propagation. Transactions may be configured to include coordination locking scripts that ensure security for tokens contributed by mining nodes 204 and prevent token loss.

[0046] Reference is now made to Figure 4, which schematically illustrates a plurality of mining nodes 402 (individually shown as 402a, 402b, and 402c) and an overlay network 302 including a plurality of validator nodes 202. In this example, the validator nodes 202 implement the memory pool as a shared memory pool, e.g., using a DHT, to store a large database of unconfirmed transactions in a distributed manner among the validator nodes 202. However, this is one exemplary implementation, and in some other implementations, each validator node 202 may store a complete copy of the memory pool.

[0047] Mining nodes 402 may include individual miners, such as those indicated by reference numerals 402b and 402c, or may include a mining pool including multiple miners, such as that indicated by reference numeral 402a.

[0048] The mining nodes 402 in this example do not have a full copy of the memory pool and rely on the validator nodes 202 to provide them with the materials necessary to mine a new block. In particular, one of the validator nodes 202 may invite the mining node 402 to participate in mining a new block using a set of unconfirmed transactions that the validator node 202 has access to in its memory pool. The mining node 402 may choose to agree to participate in the mining activity by receiving a set of new unconfirmed transactions. In exchange for receiving tokens from each mining node 402, the validator node 202 provides each of these with a set of transactions (or a hash of the set of transactions). If one of the participating mining nodes 402 successfully creates a new block from the set of transactions, that mining node 402 receives control over the tokens from the validator node 202 in addition to the normal fee for mining a block. Other failing mining nodes 402 lose their tokens to the validator node 202. If none of the participating mining nodes 402 succeed in creating the next block, the validator node 202 transfers a respective modification token to each of the participating mining nodes 402. The modification token may represent a contribution token modified to represent fewer resources or less time or control. If the token represents a digital asset, the modification token may represent a smaller amount of that digital asset. The digital asset may be computation time or resources, cryptocurrency, etc. The validator node 202 obtains the modification token as compensation for its effort in approving transactions and providing the mining node with a set of approved transactions. The modification token may represent the difference between the pooled tokens contributed by the mining node 402 and the modification token transferred to the mining node 402.

[0049] For ease of explanation, the following exemplary embodiments assume that a token represents an amount of cryptocurrency, but it is recognized that the application is not limited to use in that context and that the methods and systems are more generally applicable to blockchain networks where a token may represent a range of items, resources, or entities. More generally, control over a token (or a change or modification token) may mean access to computations or other resources in an amount or for a length of time represented by the token. Control over these computations or other resources may be transferred by a blockchain transaction that accompanies the token. A lock script to a blockchain transaction governs which nodes have control over the token and / or any conditions imposed on control over the token.

[0050] An exemplary flowchart illustrating an implementation of process 500 from the perspective of a validator node is shown in Figure 5. A validator node begins by inviting a set of mining nodes to join, in operation 502. The invitation provides for providing the mining nodes with a set of transactions from a shared memory pool so that the set of mining nodes can compete to build the next block of the blockchain.

[0051] A validator node may have a set of mining nodes that have previously registered as potentially interested in participating in mining blocks. The set of mining nodes may be selected by the validator node based on a list or other available information for contacting mining nodes. In some cases, the selection of mining nodes may be based on geography, i.e., nodes that are physically or logically close (in terms of the network architecture). The number of mining nodes in the set may depend on the implementation, but includes at least two mining nodes.

[0052] The solicitation of a set of mining nodes results in an agreement by at least some of the mining nodes to participate in the mining effort. In some cases, process 500 proceeds only if at least a minimum number of mining nodes agree to participate. The minimum number of participating mining nodes required may be two in some implementations and may be a higher number in some cases.

[0053] At operation 504, participating mining nodes each provide a deposit to a validator node via a deposit transaction. The collective deposits are pooled in an address collectively controlled by the validator node and the mining node, and in some scenarios by at least one of the validator node and the mining node. In exchange for the deposit and the mining node's cooperation with other elements of method 500, the validator node provides a set of transactions to the miner. It is recognized that the validator node may not provide the complete set of transactions to the mining node, and in some implementations may provide the mining node with a hash of the set of transactions. For example, the mining node may be provided with a Merkle root, using which the mining node can construct a block header that the mining node then uses to attempt to solve the proof-of-work algorithm. Using a two-step procedure, the mining node may create a coinbase transaction, which may be added to a pre-computed Merkle tree.

[0054] The validator node then waits to create the next block in the blockchain, as shown by operation 508. If the miner successfully creates the block, the validator node evaluates whether the successful miner is one of the participating miners, in operation 510. If so, in operation 512, it refunds the deposits paid by the participating mining nodes, and the validator node recovers the deposits paid by the unsuccessful participating mining nodes.

[0055] If none of the participating mining nodes succeed in creating the next block, in operation 514, the validator node refunds each of the participating mining nodes their deposit minus a confirmation fee that is significantly smaller than the deposit. The total confirmation fee is kept by the validator. In most implementations, the total confirmation fee should be smaller than the total kept deposit that the validating node would otherwise have collected in operation 512, to incentivize the validating node to select potentially successful mining nodes.

[0056] Consider the example of a validator node v inviting and acquiring three mining nodes m1, m2, and m3 to participate. Each mining node contributes a deposit d. If one of the mining nodes is successful, it receives its deposit d, and the validator node receives 2d. If none of the mining nodes are successful, they each receive d - ε, where ε is the confirmation fee. In that scenario, the validator node receives 3ε, and 2d > 3ε.

[0057] The mechanism for implementing method 500 using blockchain transactions must be configured to avoid malicious behavior or theft by any one of the participating nodes. At the same time, the peer-to-peer nature of the network should be maintained so that nodes operate without a central authority. The following example implementation illustrates such a process.

[0058] Reference is now made to FIG. 6, which illustrates a flowchart of an exemplary method 600 for mining blocks in a blockchain process. In this example, method 600 is performed by validator node v. Validator node v may be part of an overlay network of validator nodes configured to enable high-speed, high-volume confirmation and propagation of payment transactions in a blockchain network. Validator node v has access to a memory pool of unconfirmed blockchain transactions. The memory pool may be stored locally at validator node v or in a distributed manner across the network of validator nodes, such as using a DHT.

[0059] In operation 602, validator node v identifies participating mining nodes. In some implementations, this may be done by sending an invitation to a set of mining nodes and receiving responses from nodes interested in participating. In some implementations, this may be done by publishing an invitation on a list or other public bulletin board accessible to mining nodes and receiving expressions of interest from mining nodes interested in participating. Regardless of how implemented, validator node v identifies participating mining nodes.

[0060] When agreeing to participate, a mining node may provide some information to a validator node v. For example, a mining node m i (i=1,2,3) is the public key pubk i to the validator node v. In some examples, the mining node may provide a secret value s that it generated for the purpose of participating in the current mining effort. i These may each have a hash(s) of their respective secret values. i )) to validator node v, respectively.

[0061] In operation 604, the validator node generates a deposit transaction in which the participating mining nodes each provide a deposit value d, and the collective deposits are pooled in a pooled output address. In the case of three participating mining nodes, the value 3d is assigned to the pooled output address when the deposit transaction is approved and included in a block. The deposit transaction is initiated when a locking script for the pooled output address, in conjunction with at least one of the mining nodes, creates a secret value s for that at least one mining node. i In addition to the value s, it is configured to be unlockable by the validator node when a refund should be processed. i Without any authorization, it can be unlocked through signatures by all of the mining nodes and validator nodes. This unlocking may include script conditions regarding block height, making access conditional on the fact that the block has been successfully added to the blockchain before a refund can be processed. The details of the script and conditions may vary depending on the implementation and the blockchain protocol involved.

[0062] In operation 606, the validator node generates a claim transaction for each participating mining node, one of which is intended to be processed if one of the participating mining nodes associated with that claim transaction successfully mines a block using the set of transactions provided by the validator node. Each claim transaction takes the output of the deposit transaction, i.e., the pooled output address, as input and assigns a deposit fee d to the participating mining node of that claim transaction. The remainder of the pool value of the pooled output address (2d in this example) is assigned to the validator node. That is, each claim transaction is a deposit refund to the associated participating mining node as a reward for successfully mining a block, and a loss of the deposit for a failed mining node.

[0063] In operation 608, the validator node generates a refund transaction if none of the participating mining nodes successfully mines a block with the provided set of transactions. The refund transaction takes as input the pool value at the pooled output address and sends the deposit fee d minus the confirmation fee ε to each of the participating mining nodes. The cumulative confirmation fee (3ε in this example) is allocated to the validator nodes by the refund transaction.

[0064] It will be appreciated that operations 604, 606, and 608 each involve generating a transaction by a validator node, and although they are shown in order for ease of illustration, they do not have to be performed in the order shown, or even at all.

[0065] At operation 610, having generated the deposit transaction, claim transaction, and refund transaction, the validator node sends these transactions to each of the participating mining nodes. Each participating mining node signs the deposit transaction and its respective claim transaction and refund transaction. The participating mining nodes then return the signed transactions to the validator node. As shown by operation 612, the validator node receives the signed transactions from the participating mining nodes.

[0066] In operation 614, the validator node broadcasts (propagates) the signed deposit transaction throughout the blockchain network. It is recognized that it may take some time for the deposit to actually be incorporated into a block that is added to the blockchain. In fact, the deposit transaction may be one of the confirmed transactions included in the set of transactions that participating mining nodes attempt to mine. Nevertheless, propagating the deposit transaction to the blockchain network results in it being added to a memory pool and ultimately pooled in the output address where the given deposit is pooled.

[0067] Validator nodes do not propagate pre-signed claim or refund transactions; in fact, they propagate the secret value s needed to complete the unlock script for inputs from pooled output addresses. i , it cannot complete the signature of the claim transaction. As shown by operation 616, it stores the claim transaction and the refund transaction and waits for the successful completion of the new block.

[0068] If one of the participating mining nodes successfully completes the block, i.e., successfully solves the proof-of-work of the new block, then in operation 618, the validator node extracts the secret value s from the new block. i A successful mining node extracts the secret value s by placing it in a non-transaction field. i may be included in the new block. In the Bitcoin protocol, for example, the OP_RETURN code marks a transaction output as invalid and may therefore be used to convey non-transactional outputs. This can be used to convey non-transactional data within the blockchain.

[0069] Then, the secret value s i The validator node that extracted d can complete the signature on the input of the claim transaction associated with the successful mining node, and then, in operation 620, it broadcasts the claim transaction on the network. This results in refunding the deposit d to the successful mining node and allocating the remaining deposit 2d to the validator node.

[0070] While waiting for one of the participating mining nodes to create a new block, the validator node monitors whether a new block is created by another non-participating mining node, as shown by operation 622. If the block height increases, i.e., if a new block is added to the blockchain, before one of the participating mining nodes successfully solves the proof of work, the validator node signs and broadcasts a refund transaction in operation 624. In at least one implementation, signing the refund transaction may include signing it with the validator node's signature along with a secret value s0 held by the validator node. The function of the validator's secret value s0 is used to compare the mining node's secret value s0 with the validator node's secret value s0 for comparison purposes in implementing the lock / unlock script operations. iIn some implementations, a validator node may forego the use of its secret value s0 as part of the unlock script for the refund transaction.

[0071] Reference is now made to Figure 7, which shows a schematic representation of the relationship between deposit, claim and refund transactions. It will be appreciated that this example is based on the existence of three participating mining nodes m1, m2 and m3.

[0072] To further illustrate with the above example, assuming an implementation using the Bitcoin protocol, the following table details a simplified example of a deposit transaction, a request transaction, and a refund transaction.

[0073] [Table 1]

[0074] [Table 2]

[0075] [Table 3]

[0076] [Table 4] It is recognized that the above transaction details are exemplary and that the present application is not limited to implementations that use these details or to the use of the Bitcoin protocol. Other blockchain protocols and other transaction structures may be used in other implementations.

[0077] 8 illustrates, in flowchart form, an example process 800 for mining blocks in the context of a high-speed transaction blockchain network having validator nodes that maintain memory pools. Process 800 is performed by mining nodes in the network.

[0078] Process 800 begins when a mining node receives or obtains an invitation from a validator node. The invitation provides the mining node with a set of confirmed transactions for use when attempting to construct a new block. The invitation may also specify a required deposit and / or confirmation fee to be paid if none of the participating mining nodes are successful.

[0079] In operation 804, the mining node decides whether to participate. This may be based on any number of factors, including the identity of the validator node, the number of transactions offered, the transaction fees available for mining a set of transactions, or whether the mining node can verify the authenticity of the validator node, among other factors. If the mining node chooses not to participate, the mining node may reject the invitation.

[0080] If the mining node decides to participate in the mining effort, then in operation 806, the mining node determines its secret value s i A mining node creates a new secret value s for every mining effort it participates in. As shown by operation 808, the mining node also responds to the invitation from the validator node. The response may include the mining node's public key. The response includes the mining node's secret value s i It may further include a hash of

[0081] In operation 810, the mining node receives the deposit transaction, claim transaction, and refund transaction generated by the validator node. The mining node signs all three transactions with its signature. In particular, it signs the input to the deposit transaction, which provides its deposit value of d. It also signs the input to the claim transaction to use the output from the deposit transaction, and signs the input to the refund transaction to use the output from the deposit transaction. Once the transactions are signed, the mining node returns them to the validator node.

[0082] The mining node may receive a set of transactions from the validator node in operation 812. In many implementations, the mining node receives the set of transactions in the form of a hash of the set of transactions, e.g., a Merkle root.

[0083] Mining nodes then attempt to complete the proof-of-work required to successfully mine a new block using the set of transactions (or at least the hash of the set of transactions), which is done using a shared secret s i is included in the block. In some cases, depending on the blockchain protocol involved, this may be embedded in a non-transaction field. In some cases, it may be possible to put non-transaction data in the block header. In still other cases, it may be possible to put non-transaction data in transactions within a block. As noted above, the Bitcoin protocol may allow non-transaction data to be included in a block using the OP_RETURN opcode in a transaction.

[0084] If the miner successfully mines a block, i.e., completes the proof-of-work, as indicated by operation 816, the mining node propagates the block (or at least the block header) in operation 818. For example, the mining node may propagate the block header to one or more of the validator nodes, where the block is assembled, approved, stored, and propagated.

[0085] During the process of mining a block, as shown by operation 820, the mining node evaluates whether other nodes have successfully mined a new block. If another block appears on the blockchain before the mining node can complete the proof of work for its new block, it abandons its efforts to mine the new block. If the new block is completed by one of the other participating mining nodes, the mining node does not receive a refund and loses its deposit. However, if the new block is completed by a mining node other than one of the participating mining nodes, the mining node receives a partial refund of its deposit. Specifically, the mining node receives its deposit minus the confirmation fee.

[0086] Reference is now made to FIG. 9, which illustrates a simplified example of a node in block diagram form. In this example, the node is a validator node 900. The validator node 900 in this example includes a processor 902, a network interface 904, and memory 906. The validator node 400 may be implemented using any suitable computing hardware having sufficient network connectivity and processing and memory resources to perform the functions described herein. The validator node 900 may include processor-executable instructions for implementing the functions described herein. In some cases, the processor-executable instructions may be referred to as a blockchain application 920, although it will be recognized that the instructions may be implemented in one or more modules, applications, scripts, or other programming structures, depending on the hardware and operating system. The processor 902 may include a multi-core processor and / or multiple processors. The memory 906 stores data, including, in this example, an allocated portion of a DHT-based memory pool.

[0087] It will be understood that any modules, routines, processes, threads, applications, or other software components implementing the devices and processes described herein, as well as the described methods / processes for configuring a video feature extractor, may be implemented using standard computer programming techniques and languages, and the application is not limited to any particular processor, computer language, computer programming conventions, data structures, or other such implementation details.

[0088] It should be noted that the above-described embodiments are illustrative rather than limiting of the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the scope of the claim. The use of terms such as "comprising" and "comprises" does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes or consists of," and "comprising" means "comprising or consisting of." A reference to a singular element does not exclude a reference to a plural of such elements, and vice versa. The present invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0089] The above embodiment discloses the following items.

[0090] (1) A computer-implemented method comprising: providing a set of unconfirmed transactions to a plurality of blockchain mining nodes in exchange for tokens from each of the mining nodes; If one of the plurality of mining nodes successfully mines a block containing the set of unconfirmed transactions, returning the tokens to the one of the plurality of mining nodes and keeping the remaining tokens; If a miner other than one of the plurality of mining nodes successfully mines a block before any of the plurality of mining nodes can mine a block containing the set of unconfirmed transactions, transferring a change token to each of the plurality of mining nodes; A method comprising:

[0091] (2) The method of (1), wherein the providing step includes generating a transaction for the pool of tokens from each of the mining nodes as pooled tokens and a transaction for returning the tokens and transferring a change token, wherein the transaction for the pool locks control over the pooled tokens such that it requires a signature from at least one of the validator node and the mining node.

[0092] (3) The method of (2), wherein the transaction to transfer a change token locks control over the pooled tokens such that it requires a signature from each of the validator node and the mining node and a determination that the height of a block in the blockchain has increased.

[0093] (4) providing the set of unconfirmed transactions to the plurality of blockchain mining nodes; each of the mining nodes generating a deposit transaction to transfer control over its respective token and pool the collection of tokens to a pooled output address; generating, for each of the mining nodes, a respective claim transaction from the pooled output address that transfers control over one of the tokens to the mining node and transfers the remaining tokens to the validator node; generating a refund transaction from the pooled output address to transfer the change token to each mining node and to transfer the modified token to the validator node; obtaining a signature from each of the mining nodes for the deposit transaction, the withdrawal transaction, and each of the claim transactions of each mining node; The method according to any one of (1) to (3), further comprising:

[0094] (5) The method of (4), wherein the step of providing a set of unconfirmed transactions to the plurality of mining nodes in exchange for tokens from each of the mining nodes is conditioned on obtaining a signature from each of the mining nodes.

[0095] (6) The method of (4) or (5), wherein the unlocking script for the pooled output address of each of the respective claim transactions requires a secret value associated with the mining node to which the respective claim transaction should transfer the respective token.

[0096] (7) The method of (6), wherein if the one of the plurality of mining nodes successfully mines a block containing the set of unconfirmed transactions, the method further comprises the step of extracting the secret value from the block and using the secret value to unlock the respective claim transactions associated with the one of the plurality of mining nodes.

[0097] (8) The method according to any one of (4) to (7), wherein the step of providing a set of unconfirmed transactions to the plurality of mining nodes in exchange for tokens includes a step of broadcasting the deposit transactions on a blockchain network after obtaining the signatures.

[0098] (9) A method according to any one of (4) to (8), wherein if the one of the plurality of mining nodes successfully mines a block containing the set of unconfirmed transactions, the step of returning the tokens to the one of the plurality of mining nodes and retaining the remaining tokens includes a step of broadcasting the respective claim transactions associated with the one of the plurality of mining nodes.

[0099] (10) A method according to any one of (4) to (9), wherein the step of transferring the change token to each of the mining nodes includes a step of broadcasting the refund transaction on a blockchain network.

[0100] (11) The method of any one of (4) to (9), wherein the modification token is determined by subtracting the change token from the pooled token.

[0101] (12) A method according to any one of (1) to (11), wherein providing a set of unconfirmed transactions to the plurality of mining nodes includes providing hashes of the set of transactions to the mining nodes that the mining nodes may attempt to solve a proof of work for.

[0102] (13) The method of (12), wherein the hash of the set of transactions includes a Merkle root.

[0103] (14) A validator node configured to facilitate the validation of blockchain transactions, a processor; a memory that stores at least a portion of a pool of unconfirmed transactions; A network interface; a blockchain application comprising processor-executable instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1 to 13; The validator node containing the

[0104] (15) A non-transitory processor-readable medium storing processor-executable instructions for processing blockchain transactions, A non-transitory processor-readable medium, the processor-executable instructions, when executed by a processor, causing the processor to perform the method of any one of (1) to (13).

Claims

1. 1. A computer-implemented method performed by a node in a blockchain network, comprising: receiving or obtaining an invitation from a validator node, the invitation including a provision of a set of approved transactions for the node to use in constructing a block to be mined; Deciding whether to participate in mining the block; If the node decides to participate in the mining of the block, generating a secret value and responding to the invitation, the response including an identifier of the node; receiving deposit transactions, billing transactions, and refund transactions; signing the deposit transaction, the claim transaction, and the refund transaction; returning the signed transaction to the validator node; receiving the set of confirmed transactions from the validator nodes; If the node decides not to participate in the mining of the block, rejecting the invitation; A method comprising:

2. The method of claim 1 , wherein the invitation specifies a required deposit and / or an admission fee to be paid if none of the participating nodes is successful.

3. The said decision: the identity of the validator node; the number of transactions offered, the transaction fees available for mining said set of transactions; Verifying the authenticity of the validator node The method according to claim 1 or 2, wherein the method is based on at least one of the following:

4. The method of claim 1 , wherein the identifier comprises at least one of the node's public key or a hash of the private value.

5. The method of claim 1 , wherein the node signs the deposit, claim, and refund transactions with the node's signature.

6. 10. The method of claim 1, wherein the node signs an input to the deposit transaction that provides the value of the node's deposit.

7. 10. The method of claim 1, wherein the node signs an input to the claim transaction to use an output from the deposit transaction.

8. 10. The method of claim 1, wherein the node signs an input to the withdrawal transaction to use an output from the deposit transaction.

9. 2. The method of claim 1, wherein if the node mined the block, the block or block header is propagated to the validator node.

10. 10. The method of claim 1, wherein the node abandons the mining process if it is determined that another node has mined the block before the node can mine the block.

11. 1. A node configured to facilitate approval of blockchain transactions, comprising: a processor; a memory that stores at least a portion of a pool of unconfirmed transactions; A network interface; a blockchain application comprising processor-executable instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1 to 10; The node that contains the

12. 1. A non-transitory processor-readable medium storing processor-executable instructions for processing blockchain transactions, comprising: A non-transitory processor-readable medium, the processor-executable instructions, when executed by a processor, causing the processor to perform the method of any one of claims 1 to 10.

Images