SYSTEM AND METHOD FOR PARALLEL VERIFICATION OF BLOCKCHAIN ​​TRANSACTIONS

Abstract

To provide a computer-implemented method for validating a block at a node within a network of nodes implementing a blockchain conforming to a blockchain protocol, Bitcoin protocol, or an alternative.SOLUTION: A method includes: determining, serially, that each unspent transaction output referenced as an input in each of the plurality of transactions in a block is unique; based on that determination allocating each transaction to one of two or more parallel processors; and verifying, in parallel, by the two or more parallel processors, that the transactions comply with transaction-level validation criteria. A node also determines that the block meets block- level validation criteria. If the transactions comply with transaction-level validation criteria and the block complies with block-level validation criteria, the block is deemed valid and the node forwards the block to one or more peer nodes in the network.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates generally to blockchain transactions, and more particularly to methods and devices that enable rapid validation and propagation of blocks in a blockchain network. [Background technology]

[0002] Herein, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers, including, but not limited to, blockchain and transaction chain technologies, permissioned and unpermissioned 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 Bitcoin may be referred to herein for convenience and explanation, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed, computer-based system composed of blocks of transactions. Each transaction (TX) is a data structure that encodes the transfer of control of a digital asset 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, so that blocks are chained together to form a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs. Scripts specify how and by whom transaction outputs can be accessed. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

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

[0005] For a transaction to be written to the blockchain, it is assembled into a block by a node (a "miner"). Miners are designed to collect transactions and form them into a block. The miner then attempts to complete a "proof of work" for the block. Multiple miners compete across the blockchain network to be the first to assemble a block of transactions and complete the associated proof of work for that block. A successful miner adds its approved block to the blockchain, and the block is propagated throughout the network. Other nodes holding copies of the blockchain can then update their records. Those nodes that receive a block also "validate" the block, ensuring all transactions in it comply with the protocol's formal requirements. For example, a node receiving a new block may check to ensure that the block data structure follows applicable syntax rules, that the block has a timestamp that complies with age requirements, that the block is within predetermined size limits, and other such criteria. It also verifies that every transaction in the block is valid. Examples of standards applicable to the Bitcoin protocol are defined in the Bitcoin Core client functions CheckBlock and CheckBlockHeader.

[0006] The criteria for validating a transaction can be lengthy, for example the conditions applicable in the Bitcoin protocol can be seen in detail in the functions AcceptToMemoryPool, CheckTransaction and CheckInputs in the Bitcoin reference client.

[0007] One potential obstacle associated with blockchain implementation is the time it takes for a node to complete block validation, which includes validating all transactions in the block. This delay can hinder and impede the use of blockchain for fast, high-volume processing. Furthermore, when a miner in a Proof-of-Work (PoW) network receives notification that a block is complete before it has finished its own proof of work, the miner abandons its activity and begins attempting to construct the next block. Thus, slow validation means that miners continue their activity unnecessarily. Because mining is a processor- and energy-intensive activity, wasted mining effort is costly in terms of resources.

[0008] Thus, there are technical problems associated with validating blockchain transactions. These include issues related to the speed, efficiency, and resource requirements involved in the process of validating a block. Validation and subsequent propagation of a block requires energy, time, and effort by nodes in the network, and improvements to the process would be highly beneficial, not only in terms of network performance and speed, but also in terms of the amount of resources required. It would be desirable to provide improved methods and devices that allow for faster propagation of blocks within the Bitcoin network. Summary of the Invention

[0009] Thus, according to the present invention there is provided a method and device as defined in the appended claims.

[0010] The present application provides improved devices and methods. The method may be a method for validating a block. The block may be a block of blockchain transactions. The present invention may enable faster decisions regarding whether a block is valid or invalid. Faster validation may result in reduced wasted resources, as blocks can be propagated through the system faster. Also, less time and resources are wasted on validating and propagating conflicting blocks that ultimately result in a conflict and are superseded by an earlier block. The present invention may enable parallelization of some transaction-level validation operations. The confirmation of unique UTXOs across all transactions in a block may not be parallelized to avoid expensive synchronization between parallel processors.

[0011] Additionally or alternatively, this application may describe a computer-implemented method, which may be described as a validation method. It may include a method for validating a block within a network of nodes implementing a blockchain. The blockchain may follow or operate in conjunction with a blockchain protocol. The block may include a plurality of (blockchain) transactions. The method may include determining that the block follows block-level validation criteria, sequentially determining that each unspent transaction output, referenced as an input in each of the plurality of transactions, is unique, and based on the determination, assigning each transaction among the plurality of transactions to one of two or more parallel processors, and verifying, in parallel, by the two or more parallel processors, that the transaction among the plurality of transactions follows the transaction-level validation criteria.

[0012] The method may further include forwarding the block to one or more peer nodes in the network if the transaction complies with the transaction-level validation criteria and the block complies with the block-level validation criteria.

[0013] In some implementations, the transaction-level validation criteria include transaction characteristics specified by the blockchain protocol, where each transaction must have the transaction characteristics to be considered valid. Similarly, in some implementations, the block-level validation criteria are block characteristics specified by the blockchain protocol, where each block must have the block characteristics to be considered valid.

[0014] In some implementations, allocating each transaction in the plurality of transactions to one of two or more parallel processors includes allocating the transactions using a random allocation scheme or a deterministic allocation scheme. In one example, the scheme includes allocating the transactions among the two or more parallel processors using a first-come, first-serve algorithm. In some example implementations, the allocating includes determining a processing cost associated with each transaction and allocating the transactions to load-balance the processing cost among the two or more parallel processors. The processing cost for each transaction may be based on the number of script operations in the transaction. The processing cost for each transaction may be further based on a weighted sum of the script operations, each script operation having an associated weight based on its computational complexity.

[0015] In some implementations, the method may include sequentially determining that each unspent transaction output referenced as an input in each of the multiple transactions is unique by determining that each unspent transaction output appears only once as an input in the multiple transactions.

[0016] Additionally or alternatively, this application describes a computing device in a network of nodes implementing a blockchain, the computing device configured to validate a block conforming to a blockchain protocol and including multiple transactions. The computing device may include: a network interface providing network connectivity to the network of nodes implementing a blockchain and receiving a block conforming to the blockchain protocol and including multiple transactions; a block-level validation module determining whether the block conforms to block-level validation criteria; an input uniqueness verification module sequentially determining that each unspent transaction output referenced as an input in each of the multiple transactions is unique; two or more parallel processors verifying in parallel that a transaction among the multiple transactions conforms to the transaction-level validation criteria; and a transaction allocation unit allocating a transaction among the multiple transactions among the two or more parallel processors for validation. If the transaction conforms to the transaction-level validation criteria and the block conforms to the block-level validation criteria, the network interface forwards the block to one or more peer nodes in the network.

[0017] Additionally or alternatively, this application may describe a non-transitory processor-readable medium storing processor-executable instructions that, when executed, cause one or more processors to perform one or more of the processes and / or actions described herein.

[0018] Any feature described with respect to one aspect or embodiment of the invention may also be used with respect to one or more other aspects / embodiments. These and other aspects of the invention will be apparent from and will be elucidated with reference to the embodiments described herein. 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]

[0019] [Figure 1] Represents an example blockchain network of nodes. [Figure 2] 10A and 10B diagrammatically represent an example of a block validation process at a node. [Figure 3] 1 illustrates an example block validation method in flow chart form. [Figure 4] FIG. 1 shows a block diagram of a node that validates blocks in a blockchain network. DETAILED DESCRIPTION OF THE INVENTION

[0020] As used herein, 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.

[0021] As used herein, 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 not necessarily all elements.

[0022] Reference is first made to FIG. 1, which illustrates in block diagram form an example of a blockchain network 100 associated with a blockchain. A blockchain network is a peer-to-peer, non-membership network that anyone can join without an invitation or consent from other members. Distributed electronic devices running instances of the blockchain protocol on which the blockchain network 100 operates may participate in the 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.

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

[0024] 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 individual nodes 102 may be located in geographically dispersed locations.

[0025] Nodes 102 maintain a global ledger of all transactions on the blockchain. 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. The details of implementing and operating a blockchain network, such as one using the Bitcoin protocol, are well understood by those skilled in the art.

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

[0027] As described above, mining nodes (“miners”) compete to create the next block on the blockchain. To assemble a block, a miner constructs the block as a set of transactions from a pool of unconfirmed transactions (“mempool”). The miner then attempts to complete proof-of-work for the block it assembled. If the miner manages to complete proof-of-work before receiving notification that any other miner has successfully produced a block and completed its proof-of-work, the miner then propagates the block by sending it to peer nodes on the network. Those nodes validate the block and then send it further to other nodes on the network. If the miner receives notification that another block has been completed before it has finished its own proof-of-work, the miner then abandons its activity and begins attempting to construct the next block.

[0028] Thus, fast propagation of blocks helps to avoid wasted effort for miners and validating nodes. By providing a solution that allows faster validation and thus block propagation, the present invention provides improved network performance. It reduces the amount of energy required by the network, as well as the amount of computation time and effort required. It provides a network that is more efficient in terms of resources and time. It ultimately provides an improved (blockchain) network.

[0029] In current implementations of blockchains, such as the Bitcoin network, each node that receives a block first validates the block before sending it to other nodes. The time it takes to validate a block slows the block's propagation through the network. Note that some implementations of blockchains, including deployments of existing protocols, may provide block validation by only a subset of nodes, rather than every node in the network. However, block validation by most nodes may still be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0030] Validating a block involves verifying that the block satisfies predetermined criteria set by the applicable blockchain protocol. Examples of 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 conforms to predetermined criteria, each transaction within the block may be evaluated for conformance to transaction-level criteria. As an example, transaction-level criteria applicable to the Bitcoin protocol may be found in detail in AcceptToMemoryPool, CheckTransaction, and CheckInputs.

[0031] Examples of block-level standards, based on the Bitcoin protocol, include: · The block data structure is syntactically valid. The block header hash is less than the target difficulty (to perform proof of work). The block timestamp is less than 2 hours in the future (to allow for time error). · The block size is within the acceptable limits. The first transaction (and only the first) is a coinbase generation transaction. All transactions in the block are valid.

[0032] Examples of transaction-level criteria, based on the Bitcoin protocol, include: · The transaction syntax and data structure must be correct. Both the input and output lists are empty. Each output value x and the sum of all outputs is 0 <x<21·10 6 must be within the range of 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 attempts is less than the signature attempt limit. The unlocking script scriptSig can only push numbers onto the stack, and the locking script scriptPubkey is in standard format. For each input, if the referenced output is present in any other 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 cannot already be in use. Use the referenced output transaction to get the input value, and the sum of each input value and the value x is within the tolerance range, i.e., 0 <x<21·10 6 Check that it is in. There must be a matching transaction in the pool or in a block on the main branch. The sum of the input values ​​must be greater than or equal to the sum of the output values. The transaction fees must be sufficient to get into an empty block. · The unlock script for each input must validate the lock script against the corresponding output.

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

[0034] According to the present application, methods and devices are described that accelerate block validation to facilitate faster propagation of blocks in a network.

[0035] In one aspect, this application describes a node structured to validate blocks by performing transaction-level validation of individual transactions in parallel. However, certain transaction-level criteria should not be evaluated in parallel. In particular, UTXO uniqueness should be evaluated serially. Thus, the node is structured or arranged to verify the uniqueness of a transaction's referenced input (UTXO) before allocating the transaction between two sets of parallel processors for validation of the remaining transaction-level criteria.

[0036] The term "processor," when used herein in connection with the description of a parallel processor, does not necessarily refer to physically distinct microprocessors, but may include any hardware or software implementation that enables parallel processing resources capable of performing processor functions independently and in parallel. A parallel processor may include a single processor having multiple cores. In some cases, a parallel processor may include multiple separate processing units. Parallel processors may or may not share physical memory. However implemented, each parallel processor includes software or hardware mechanisms for signaling, such as outputting a signal in response to identifying an invalid transaction. A parallel processor implementation also includes providing the necessary data transfer mechanisms in software and / or hardware to transfer assigned transaction data to each processor for local processing.

[0037] Referring now to Figure 2, Figure 2 diagrammatically illustrates a simple example of a block validation process 200 at a node of a blockchain network. Process 200 includes a block-level validation step 202, in which an incoming new block is tested against block-level criteria. Exemplary block-level criteria are described above and generally relate to predetermined formatting requirements and characteristics or restrictions that apply to the block itself, as opposed to the transactions within the block. Examples include block size, block header structure or content, and similar criteria.

[0038] Process 200 further includes a UTXO uniqueness verification module 204. Module 204 evaluates whether each of the inputs to the transactions in the new block, i.e., each UTXO, is unique. If the same UTXO appears more than once as an input in the new block, it indicates a potential double-spending problem and violates the UTXO uniqueness criterion. If UTXO uniqueness verification module 204 identifies a UTXO that is referenced more than once among the transaction inputs in the new block, then it outputs an error signal or other interrupt to indicate that the block should be rejected.

[0039] Provided that the new block is not rejected, i.e., all UTXOs are unique, then the individual transactions are allocated among the set of parallel processors 208 by the transaction allocation unit 206. The transaction allocation unit 206 may use any one of a number of possible allocation schemes to divide the transactions within the block among the individual processors 208. In some cases, the allocation scheme may be aimed at load balancing. The allocation may be viewed as "job shop scheduling," in which a set of jobs with varying processing times are allocated among a set of machines / processors 208, each with its own processing power or output, while attempting to minimize the length of the longest processing time among the processors 208. Further exemplary details are provided below.

[0040] Individual processors 208 validate the transactions assigned to them against transaction-level validation criteria. Processors 208 do not require a synchronization paradigm between them; that is, they each work independently to verify that the transactions assigned to them are valid. Each processor 208 outputs a result confirming the validity of its assigned transaction, and the results are added to ensure that all transactions in the block are valid. If one of the processors 208 identifies a non-conforming transaction, i.e., an invalid transaction, it may then issue an output, such as an interrupt or other signal, to indicate the presence of an invalid transaction. That interrupt or signal may be sent to the other processors 208, allowing them to immediately stop testing their respective transactions and avoid wasting further resources validating transactions in the block that should be rejected.

[0041] Although block-level criteria are shown as being tested first in the example process 200, it will be understood that the block-level validation stage 202 may occur after, or in some cases in parallel with, transaction-level validation testing.

[0042] Referring now to Figure 3, Figure 3 illustrates in flowchart form one example of a method 300 for validating a block in a blockchain network. A block includes multiple transactions, each transaction references one or more inputs, each of which is a UTXO (except in the case of a coinbase generation transaction). Method 300 is implemented using appropriate hardware and processor-executable instructions within a node in the blockchain network.

[0043] In operation 302, a node receives a new block. The new block may be received from a mining node that has generated the new block and completed proof-of-work. The new block may also be received from other (non-mining) nodes in the network. Before forwarding the new block to any other nodes in the network, the current node validates the block. As described above, validating a new block includes verifying that the block meets certain block-level criteria and verifying that each of the transactions in the block are valid.

[0044] At operation 304, the node evaluates whether the new block satisfies block-level criteria. As mentioned above, this operation 304 may be performed later in method 300 in some implementations, and in some cases may be performed in parallel with other operations. Block-level criteria may include, among other things, verifying that the block structure meets syntax requirements, that the timestamp meets currency requirements, and that the block size is within predetermined limits.

[0045] If the new block satisfies these block-level criteria, then in operation 306, the node evaluates whether the inputs to each transaction are unique. That is, the node determines whether any of the UTXOs referenced as inputs appear more than once in the block. If so, the UTXO is not unique and the block should be rejected. The determination that a UTXO is unique cannot be performed in parallel without using a computationally expensive synchronization paradigm between parallel processing units. Therefore, operation 306 is performed sequentially.

[0046] In one example implementation, a hash table of referenced outputs (UTXOs) in transaction inputs may be used, with each UTXO having a Boolean value initialized to false. A double-spend attack occurs when a given hash table entry whose value was previously set to true is referenced again. In such a case, the UTXO is not unique, the entire block is deemed invalid, and process 300 is aborted.

[0047] In another exemplary implementation, a binary search tree may be used, for example, through a map data structure in C++. A map is an associative container that stores elements formed by combinations of key values ​​and mapped values ​​according to a specific order. Given n transactions, the search, insertion, and deletion time complexity is O(logn) on average and O(n) in the worst case.

[0048] If the UTXO in the new block is unique, then in operation 308, the node allocates the transaction among the parallel processors.

[0049] An additional hash table may be used during serial processing of operation 306 to keep track of transactions that depend on other transactions in the block. dep (starting from 0) is assigned to the transaction currently being analyzed. If a transaction depends on other transactions, it will be given the same identifier as the transactions it depends on. That is, two or more dependent transactions will have the same identifier, and each new transaction that does not depend on any transactions that have yet been seen will be given an increasing id. dep Each pair of dependent transactions is pre-assigned to the same processing unit. For example, if N is the number of parallel processing units, then id CPU =id depmodulo N. A dependent transaction is one that has an input that is, for example, an output from a transaction on which it depends.

[0050] In the simplest implementation, the allocation of transactions among processors is based on the number of processors and the number of transactions, regardless of differences in processor demand and / or capabilities. However, to better balance the processing load among available processors, in some implementations, a node may take into account the complexity of the transactions, and in particular the complexity of validating each transaction. One such measure of (or proxy for) processing load is the number of scripted operations involved in a transaction. That is, the time required to validate an individual transaction j is proportional to the number of scripted operations c involved. j For example, in the case of a P2PKH transaction, c j is the number of operations in the signature script (input) plus the number of operations in the public key script (referenced output).

[0051] In other examples, different weights can be assigned to different script operations. For example, OP_HASH160 and OP_CHECKSIG are much more complex than the simple OP_EQUAL operation. Thus, the overall cost c j is the M individual weighted script operations w j is defined as the sum of:

number

[0052] A threshold T can be set to prevent some forms of attacks on the node's computational resources. For any transaction j, c j>In the case of T, the node can decide not to validate the block. The value of T can be directly proportional to the calculated output of an individual processing unit in the local validation node, measured in Hertz or instructions per second.

[0053] The scheduling scheme S distributes a list {c j}, 0 ≤ j < n of transaction validations among the CPUs. This problem is known as job shop scheduling, where n jobs {J1, J2, ···, J n} with various processing times need to be scheduled for N machines with various processing outputs, while trying to minimize the overall length (makespan) of the schedule U, i.e., the time it takes for the parallel processing to complete. In some implementations, the assignment of transactions among processors may follow a random assignment scheme. In some implementations, the assignment may follow a deterministic assignment scheme.

[0054] Two example scheduling schemes include: · FCFS (First Come First Served) sequentially assigns transactions to available processing units in a round - robin like fashion. This is a type of random assignment scheme. Considering the t - th transaction from the top of the block, the core with IDt modulo N will be involved in the validation. This scheduler is at least computationally complex. The LPT (Longest Processing Time) greedy algorithm provides a more efficient load-sharing solution and is an example of a deterministic allocation scheme. Jobs (transactions) are first sorted by their respective processing times ("cost" based on the number of scripted operations or the sum of weighted scripted operations), and then can be assigned to the machine with the earliest finish time so far, in a way that balances the computational load per processor.

[0055] In some implementations, FCFS schemes may be subject to malicious attacks that exploit the degree N of parallelism of the validating nodes (e.g., building a block while requiring a script every N or N / 2 transactions). To avoid this scenario, a truly random transaction validation allocation can be used at no extra cost.

[0056] The LPT algorithm achieves the following upper bound U on the theoretical optimum U: U / U0=(4 / 3)-(1 / 3N) Sorting algorithms such as mergesort are characterized by worst-case and average time complexity of O(n log n). However, the UTXO uniqueness evaluation of operation 306 is j This may be performed while sorting the values, thereby avoiding any extra computational expense.

[0057] Having allocated the transactions among the parallel processors, method 300 then includes each of those processors independently validating each set of allocated transactions. Once all individual transactions have been validated, the node can then accept the block as valid, as indicated by operation 312. Accepting or designating a block as valid may result in further functionality based on the block's validity, such as forwarding the valid block to one or more peer nodes on the blockchain network. In some cases, this may include adding the block to a copy of the blockchain stored locally at the current node.

[0058] If any of the processors detects an invalid transaction, that processor aborts the validation method 300 and the node rejects the block as invalid, as indicated by operation 314 .

[0059] Thus, the present invention provides one or more technical solutions to at least one technical problem in the prior art. For example, known blockchain configurations do not teach a technique for sequentially verifying the validity of unspent transaction outputs (UTXOs) in all transactions prior to allocating the transactions among parallel processors. A Bitcoin forum published on October 8, 2014, appears to suggest attempting to prevent double-spending within a parallelized transaction validation process, for example, by constructing a new data structure (output set) and checking the output set structure (https: / / bitcointalk.org / index.php?topic=816199.0 [06 / 10 / 2017] “Looking Into forking the core wallet to use parallel computing to verify blocks”).

[0060] Referring now to Figure 4, Figure 4 illustrates, in block diagram form, a simplified example of a node 400. The node 400 includes multiple processors 402. The processors 402 may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The processors 402 may include multi-core processors.

[0061] The node 400 further includes a memory 404. The memory 404 may include permanent and non-transitory memory that stores values, variables, and in some cases, program instructions executable by a processor. The node 400 further includes a network interface 406 that provides network connectivity over wired or wireless networks.

[0062] The node 400 includes a processor-executable blockchain application 408 that includes processor-executable instructions that, when executed, cause the processor 402 to perform one or more of the functions or operations described herein.

[0063] It will be understood that any modules, routines, processes, threads, applications, or other software components implementing the described methods / processes to configure the devices and processes, and blockchain nodes, described herein can be implemented using standard computer programming techniques and languages, and the present application is not limited to any particular processor, computer language, computer programming specification, data structures, or other such implementation details.

[0064] It should be noted that the above embodiments illustrate rather than limit 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 words "comprising" and "comprises", and the like, do 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 "including or consisting of". A singular reference of an element does not exclude a plural reference of such elements, and vice versa. The 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 claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. 1. A computer-implemented method for validating a block containing a plurality of transactions within a network of nodes implementing a blockchain conforming to a blockchain protocol, comprising: determining that the block complies with block-level validation criteria; sequentially determining that each unspent transaction output referenced as an input in each of the plurality of transactions is unique; and based on the determination, assigning each transaction among the plurality of transactions to one of two or more parallel processors, and each transaction among the plurality of transactions that is dependent on another transaction among the plurality of transactions being assigned to the same one of the two or more parallel processors as the other transaction; concurrently verifying, by the two or more parallel processors, that the transactions in the plurality of transactions comply with transaction-level validation criteria; validating the block if the transaction complies with transaction-level validation criteria and the block complies with block-level validation criteria; A method having the following.

2. further comprising assigning an identifier to each transaction in the plurality of transactions; a transaction that depends on another transaction among the plurality of transactions is assigned the same identifier as the other transaction on which it depends, and transactions having the same identifier are assigned to the same one of the two or more parallel processors; The method of claim 1.

3. assigning an identifier to each transaction in the plurality of transactions is performed simultaneously with sequentially determining that each unspent transaction output referenced as an input in each of the plurality of transactions is unique. The method of claim 2.

4. If the transaction complies with transaction-level validation criteria and the block complies with block-level validation criteria, forwarding the block to one or more peer nodes in the network.

4. The method according to any one of claims 1 to 3.

5. the transaction-level validation criteria comprise transaction characteristics defined by the blockchain protocol; Each transaction must have the above transaction characteristics to be considered valid; 5. The method according to any one of claims 1 to 4.

6. the block-level validation criteria comprise block characteristics defined by the blockchain protocol; Each block must have the above block characteristics to be considered valid.

6. The method according to any one of claims 1 to 5.

7. assigning each transaction in the plurality of transactions to one of two or more parallel processors comprises assigning the transaction using a random assignment scheme or a deterministic assignment scheme.

7. The method according to any one of claims 1 to 6.

8. allocating the transactions includes allocating the transactions among the two or more parallel processors using a first-come, first-served algorithm. The method of claim 7.

9. assigning each transaction in the plurality of transactions to one of two or more parallel processors includes determining a processing cost associated with each transaction and assigning the transactions to load-balance the processing cost among the two or more parallel processors.

9. The method according to any one of claims 1 to 8.

10. the processing cost for each transaction is based on the number of script operations in that transaction, and optionally, the processing cost for each transaction is further based on a weighted sum of the script operations; a weight is associated with each script operation based on the computational complexity of the script operation; 10. The method of claim 9.

11. sequentially determining that each unused transaction output referenced as an input in each of the plurality of transactions is unique comprises determining that each unused transaction output appears only once as an input in the plurality of transactions.

11. The method according to any one of claims 1 to 10.

12. A computing device in a network of nodes implementing a blockchain, the computing device being configured to validate a block conforming to a blockchain protocol, the block including a plurality of transactions; a network interface that provides network connectivity to a network of nodes that implement the blockchain and receives a block that includes multiple transactions and conforms to the blockchain protocol; a block-level validation module that determines that the block complies with block-level validation criteria; an input uniqueness verification module that sequentially determines that each unspent transaction output referenced as an input in each of the plurality of transactions is unique; two or more parallel processors that verify in parallel that transactions in the plurality of transactions comply with transaction-level validation criteria; a transaction allocation unit for allocating the transactions in the plurality of transactions among the two or more parallel processors for verification; and The computing device is configured to perform the computer-implemented method of any one of claims 1 to 11. computing device.

13. If the transaction complies with transaction-level validation criteria and the block complies with block-level validation criteria, the network interface forwards the block to one or more peer nodes in the network.

13. The computing device of claim 12.

14. A non-transitory processor-readable medium storing processor-executable instructions within a network of nodes that implements a blockchain, the non-transitory processor-readable medium comprising: The instructions validate a block conforming to a blockchain protocol, the block including a plurality of transactions; The instructions cause two or more processors to perform the method of any one of claims 1 to 11. A non-transitory processor-readable medium.

Images