System and method for parallel verification of blockchain transactions

Abstract

A computer-implemented method for verifying a block at a node in a network of nodes, the node implementing a blockchain that complies with a blockchain protocol. The method includes serially determining that in each of a plurality of transactions, each unspent transaction output referenced as an input is unique, and based on the determination, assigning each of the plurality of transactions to one of two or more parallel processors, and verifying in parallel by the two or more parallel processors whether the transactions in the plurality of transactions comply with a transaction-level verification standard. The node also determines that the block satisfies the block-level verification standard. If the transaction complies with the transaction-level verification standard and the block complies with the block-level verification standard, the block is deemed valid, and the node forwards the block to one or more peer nodes in the network.

Description

Technical Field

[0001] The present invention generally relates to blockchain transactions, and more particularly to methods and devices capable of rapidly verifying and propagating blocks in a blockchain network. Background Art

[0002] As used herein, the term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers, including but not limited to blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof.

[0003] A blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed computer-based system consisting of blocks, which consist of transactions. Each transaction (TX) is a data structure that encodes the transfer of control of a digital asset between participants in a blockchain system, and includes at least one input and at least one output. Each block contains a hash of the previous block, so that the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its inception. Transactions contain small programs, called scripts, embedded in the inputs and outputs of the transaction, which specify how and by whom the output of the transaction can be accessed.

[0004] A network node that receives a new transaction will quickly attempt to push that transaction to other nodes in the network. Before a new transaction is transmitted 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 under the applicable protocol.

[0005] In order to write transactions to the blockchain, a node that receives a block "validates" the block and all transactions in it to ensure that they meet the formal requirements of the protocol. For example, a node that receives a new block may check to confirm that the block data structure adheres to applicable syntactic rules, that the block has a timestamp that meets age requirements, that the block is within specified size limits, and other such criteria. The node also confirms that each transaction in the block is valid.

[0006] The criteria for validating a transaction can be long.

[0007] One of the potential bottlenecks associated with blockchain implementations is the time it takes for nodes to complete block validation, which includes verifying all transactions in a block. Latency can hinder and impede the use of blockchain for fast, high-volume processing.

[0008] Therefore, there are technical problems associated with verifying blockchain transactions, including the speed, efficiency and resource requirements involved in the process of verifying blocks. The verification and subsequent propagation of blocks requires energy, time and effort from nodes in the network, and improvements to the process would be very beneficial not only in terms of network performance and speed, but also in relation to the amount of resources required. It is desirable to provide improved methods and apparatus that enable faster propagation of blocks in a blockchain network. Such an improved solution has now been devised. Summary of the invention

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

[0010] The present application provides an improved device and method. The method may be a method for verifying blocks. These blocks may be blocks of blockchain transactions. The present invention may determine whether a block is valid or invalid more quickly. Faster verification reduces waste of resources because blocks are propagated through the system more quickly. In addition, less time and resources will be wasted on verification and propagation of competing blocks that will eventually fall into conflict and lose to earlier blocks. The present invention may enable parallelization of some transaction-level verification operations. Confirmation of unspent transaction outputs (UXTOs) that are unique to all transactions in a block may not be parallelized to avoid costly synchronization between parallel processors.

[0011] Additionally or alternatively, the present application may describe a computer-implemented method. The method may be described as a verification method. The method may include a method for verifying a block in a network of nodes implementing a blockchain. The blockchain may comply with a blockchain protocol, or operate in association with a blockchain protocol. The block may include multiple (blockchain) transactions. The method may include: determining that the block complies with a block-level verification standard; and serially determining that in each transaction of the multiple transactions, each unspent transaction output (UTXO) referenced as an input is unique, and based on the determination, assigning each transaction in the multiple transactions to one of two or more parallel processors, and verifying in parallel by the two or more parallel processors that the transactions in the multiple transactions comply with the transaction-level verification standard.

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

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

[0014] In some implementations, allocating each of the plurality of transactions to one of the 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 between the two or more parallel processors using a first-come first-serve algorithm. In some example implementations, allocating includes determining a processing cost associated with each transaction, and allocating the transactions to load balance the processing costs between the two or more parallel processors. The processing cost of each transaction may be based on the number of script operations in the transaction. The processing cost of each transaction may also be based on a weighted sum of the script operations, wherein each script operation has an associated weight based on a computational complexity of the script operation.

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

[0016] Additionally or alternatively, the present application describes a computing device within a network of nodes implementing a blockchain, the computing device being used to verify a block that complies with a blockchain protocol, the block containing multiple transactions. The computing device may include: a network interface for providing a network connection to a network of nodes implementing a blockchain, and receiving a block that complies with the blockchain protocol and contains multiple transactions; a block-level verification module for determining that the block complies with a block-level verification standard; an input uniqueness confirmation module for serially determining that in each transaction of a plurality of transactions, each unspent transaction output referenced as an input is unique; two or more parallel processors for verifying in parallel whether a transaction in a plurality of transactions complies with a transaction-level verification standard; and a transaction allocation unit for allocating transactions in a plurality of transactions between two or more parallel processors for verification. If the transaction complies with the transaction-level verification standard and the block complies with the block-level verification standard, the network interface forwards the block to one or more peer nodes in the network.

[0017] Additionally or alternatively, the present application may describe a non-transitory processor-readable medium having stored thereon processor-executable instructions that, when executed, cause one or more processors to perform one or more of the processes and / or operations described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Any features described with respect to one aspect or embodiment of the invention may also be applicable to one or more other aspects or embodiments. These and other aspects of the invention will become clear and illustrated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0019] Figure 1 An example blockchain network of nodes is shown;

[0020] Figure 2 Schematically illustrates an example block verification process in a node;

[0021] Figure 3 An example of a block verification method is shown in the form of a flow chart; and

[0022] Figure 4 A block diagram of a node used to validate blocks in a blockchain network is shown. DETAILED DESCRIPTION

[0023] In the present 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 individually, in any subcombination or all the elements, and does not necessarily exclude additional elements.

[0024] In the present application, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one listed element alone, any subcombination, or all elements, without necessarily excluding any other elements, and without necessarily requiring the presence of all elements.

[0025] First reference Figure 1 , Figure 1 An example blockchain network 100 associated with a blockchain is shown in block diagram form. The blockchain network is a peer-to-peer open membership network that anyone can join without invitation or consent from other members. Distributed electronic devices running an instance of a blockchain protocol (under which the blockchain network 100 runs) can participate in the blockchain network 100. Such distributed electronic devices can be referred to as nodes 102.

[0026] 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 (e.g., desktop computers, laptop computers, tablet computers), servers, mobile devices (e.g., smartphones), wearable computers (e.g., smart watches), or other electronic devices.

[0027] The nodes 102 of the blockchain network 100 are connected to each other using suitable communication technologies, which may include wired and wireless communication technologies. In many cases, the blockchain network 100 is implemented at least in part on the Internet, and some individual nodes 102 may be located in geographically dispersed locations.

[0028] Nodes 102 maintain a global ledger of all transactions on the blockchain. The global ledger is a distributed ledger, and each node 102 can store a complete copy or a partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. Those of ordinary skill in the art will understand the details of implementing and operating a blockchain network.

[0029] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how and who can access the outputs of the transaction. The output of a transaction can be an address to which the value is transferred as a result of the transaction. The value is then associated with that output address as an unspent transaction output. Subsequent transactions can take that address as an input to spend or disperse that value.

[0030] The rapid propagation of blocks helps to avoid wasting the efforts of the verification nodes. By providing a solution that enables faster verification and therefore propagation of blocks, the present invention provides enhanced network performance. The solution reduces the required computation time and effort, thereby reducing the energy required by the network. The solution provides a more efficient network in terms of resources and time, ultimately providing an improved (blockchain) network.

[0031] In current implementations of blockchains, each node that receives a block first validates the block before sending the block to other nodes. The time required to validate a block slows down the propagation of blocks through the network. Note that some implementations of blockchains, including evolutions of existing protocols, may provide block validation only by a subset of nodes rather than by every node in the network. However, block validation by a majority of nodes may still be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0032] Validating a block involves confirming that the block meets the specified standards set by the applicable blockchain protocol. In addition to confirming that the block itself meets the specified standards, each transaction within the block can also be evaluated for compliance with transaction-level standards.

[0033] Specific examples of block-level standards include:

[0034] The block data structure is syntactically valid.

[0035] The block header hash is less than the target difficulty (strengthening proof of work).

[0036] The block timestamp is less than two hours in the future (allowing for time error).

[0037] Block size is within acceptable range.

[0038] The first transaction (and only the first one) is the coinbase creation transaction.

[0039] All transactions within the block are valid.

[0040] Specific examples of transaction-level standards include:

[0041] The transaction syntax and data structure must be correct.

[0042] Neither the input nor the output list is empty.

[0043] Each output value x and the sum of all outputs must be zero <x<21·10 6 within the range.

[0044] None of the inputs have a null value hash.

[0045] nLockTime is less than or equal to INT_MAX.

[0046] The transaction size in bytes is greater than or equal to the minimum value and less than the maximum value.

[0047] The number of signature operations is less than the signature operation limit.

[0048] The unlocking script scriptSig can only push numbers onto the stack, while the locking script scriptPubkey must match the isStandard form.

[0049] For each input, if the referenced output exists in any other transaction in the pool, the transaction must be rejected.

[0050] For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY(100) confirmations.

[0051] For each input, the referenced output must exist and cannot have been spent.

[0052] Get the input values ​​using the referenced output transaction, check if each input value and the sum is within the allowed range of value x, i.e. 0 <x<21·10 6 .

[0053] A matching transaction must exist in a block in the pool or in the main branch.

[0054] The sum of the input values ​​must be equal to or greater than the sum of the output values.

[0055] Transaction fees must be sufficient to get into a free block.

[0056] Each input’s unlocking script must be validated against the corresponding output locking script.

[0057] These example standards are illustrative and should not be construed as sufficient or necessary for all embodiments, as the specified standards may vary among different protocols and may change over time for a given protocol if changes are made to the protocol. Generally, transaction-level validation standards are specified characteristics that a transaction must have to be considered valid under the applicable blockchain protocol. Similarly, block-level validation standards are specified characteristics that a block must have to be considered valid under the applicable blockchain protocol.

[0058] According to the present application, methods and apparatus are described for accelerating block validation so that blocks can be propagated faster in a network.

[0059] In one aspect, the present application describes a node that is constructed to validate blocks by performing transaction-level validation of individual transactions in parallel. However, certain transaction-level criteria cannot be evaluated in parallel. In particular, the uniqueness of unspent transaction outputs (UTXOs) should be evaluated serially. Therefore, the node is constructed or arranged to confirm the uniqueness of the reference inputs (UTXOs) of a transaction before distributing the transaction among a set of two or more parallel processors for validating the remaining transaction-level criteria.

[0060] When the term "processor" is used in conjunction with the description of parallel processors herein, it does not necessarily mean physically distinct microprocessors, and may include any hardware or software implementation that enables parallel processing resources that can independently and in parallel perform processor functions. A parallel processor may include a processor having multiple cores. In some examples, a parallel processor may include multiple independent processing units. Parallel processors may or may not share physical memory. Regardless of the implementation, each parallel processor has a software or hardware mechanism for signaling, such as outputting a signal in response to identifying an invalid transaction. The implementation of the parallel processor also includes providing the necessary data transmission mechanism in software and / or hardware to route the allocated transaction data to the corresponding processor for local processing.

[0061] Reference now Figure 2 , Figure 2A simplified example of a block validation process 200 in a blockchain network node is schematically shown. The process 200 includes a block-level validation phase 202, in which an incoming new block is tested against block-level standards. As opposed to transactions within a block, example block-level standards, as described above, generally involve prescribed format requirements and features or restrictions that apply to the block itself. Examples include block size, block header structure or content, and similar standards.

[0062] The process 200 also includes a UTXO uniqueness confirmation module 204, which evaluates whether each input of the transaction in the new block, that is, each UTXO, is unique. If the same UTXO appears as an input multiple times in the new block, it indicates a potential double-spending problem, violating the UTXO uniqueness standard. If the UTXO uniqueness confirmation module 204 identifies a UTXO that is referenced more than once in a transaction input in the new block, the module outputs an error signal or other interrupt to indicate that the block will be rejected.

[0063] Assuming that the new block is not rejected, that is, all UTXO inputs are unique, the individual transactions are distributed among a set of parallel processors 208 by the distribution unit 206. The transaction distribution unit 206 may adopt any of a variety of possible distribution schemes for dividing the transactions in the block among the various processors 208. In some examples, the goal of the distribution scheme may be load balancing. The distribution can be characterized as "job shop scheduling", in which a set of jobs with different processing times are distributed among a set of machines / processors 208, each machine / processor 208 having its own processing capacity or power, while trying to minimize the length of the longest processing time in the processor 208. Further example details are provided below.

[0064] Each processor 208 verifies the transactions that have been assigned to them according to the transaction-level verification criteria. The processors 208 do not require a synchronization mode between them. The processors 208 each independently verify whether the transactions they have been assigned are valid. Each processor 208 outputs a result confirming the validity of the transaction it has been assigned, and the results are added to confirm that all transactions in the block are valid. In the case where one of the processors 208 identifies a non-compliant transaction, i.e., an invalid transaction, the processor can issue an output (e.g., an interrupt or other signal) to indicate the presence of an invalid transaction. The interrupt or signal can be sent to other processors 208 so that the other processors can immediately stop testing their respective transactions and will not waste more resources on verifying transactions in blocks that are about to be rejected.

[0065] Note that the block-level criteria are shown to be tested first in the example process 200. However, it should be appreciated that the block-level validation phase 202 may occur after the transaction-level validation testing, or in some examples in parallel with the transaction-level validation testing.

[0066] Now refer to Figure 3 , Figure 3 An example method 300 for verifying a block in a blockchain network is shown in the form of a flow chart. The block contains multiple transactions, each transaction references one or more inputs, and each input is a UXTO (except for the case of coinbase generation transactions). The method 300 is implemented using suitable hardware and processor executable instructions within a node on the blockchain network.

[0067] In operation 302, the node receives a new block. The new block may be received from another (non-mining) node in the network. The current node validates the new block before forwarding it to any other node in the network. As described above, validation of the new block includes confirming that the block meets certain block-level criteria and confirming that each transaction in the block is valid.

[0068] In operation 304, the node evaluates whether the new block meets the block-level criteria. As previously described, in some embodiments, this operation 304 may be performed later in method 300, and in some cases, may be performed in parallel with other operations. Block-level criteria may include confirming whether the block structure meets syntactic requirements, whether the timestamp meets currency requirements, and whether the block size is within specified limits, etc.

[0069] If the new block meets 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 UXTOs referenced as inputs appear multiple times in the block. If so, the UXTOs are not unique and the block will be rejected. The determination of the uniqueness of UXTOs cannot be performed in parallel without using a computationally expensive synchronization scheme between parallel processing units. Therefore, operation 306 is performed serially.

[0070] In one example implementation, a hash table of reference outputs (UXTOs) in transaction inputs may be used, where each UXTO has a Boolean value initialized to false. A double spend attack occurs if a given hash table entry whose hash value has been set to true is referenced again. In this case, the UXTO is not unique, and the entire block may be considered invalid, and process 300 is aborted.

[0071] In another example implementation, a binary search tree may be used, for example, through a map structure data structure in C++. A map is an associative container that stores elements formed by a combination of a key value and a mapped value in 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.

[0072] If the UXTOs in the new block are unique, then in operation 308 the node distributes the transactions among the parallel processors.

[0073] During the serial processing of operation 306, an additional hash table may be used to track transactions that depend on other transactions within the block. In one implementation, the identifier id dep (starting from zero) is assigned to the currently analyzed transaction. If a transaction is dependent on another transaction, the transaction will be assigned the same identifier as the transaction it depends on. That is, two or more dependent transactions will have the same identifier, and each new transaction that is not dependent on any unseen transaction will have an incremented id dep Each group of dependent transactions will be pre-assigned to the same processing unit, such as id CPU =id dep moduloN, where N is the number of parallel processing units. A dependent transaction is, for example, a transaction whose input is an output of a transaction it depends on.

[0074] In the simplest implementation, the allocation of transactions between processors is based on the number of processors and the number of transactions, without taking into account differences in processor demand and / or capacity. However, in order to better balance the processing load between the available processors, in some implementations, nodes may take into account the complexity of transactions, and in particular the complexity of verifying each transaction. One measure (or proxy) of processing load is the number of script operations involved in a transaction. That is, the time required to verify a single transaction j can be considered to be proportional to the number of script operations c involved. j For example, in the case of a P2PKH transaction, c j It is the sum of the number of operations in the signature script (the input) and the number of operations in the public key script (the referenced output).

[0075] In another example, different weights w can be assigned to different script operations. For example, OP_HASH160 and OP_CHECKSIG are several orders of magnitude more complex than simple OP_EQUAL operations. Therefore, the total cost c for verifying transaction j is j Defined as its M individual weighted script operations w j The sum of:

[0076]

[0077] weight w j It can be hard - coded based on the complexity of the script operations specified or defined by the applicable blockchain protocol.

[0078] To prevent a certain form of attack on the node's computing resources, a threshold T can be set. If for any transaction j, c j > T, then the node can determine not to verify the block. The value of T can be directly proportional to the computing power of a single processing unit in the local verification node, measured in hertz or instructions per second.

[0079] The scheduling scheme S distributes the transaction verification list {c j}, 0 ≤ j < n, among the CPUs. This problem is known as job shop scheduling: n jobs {J1, J2, …, J n} with different processing times need to be scheduled on N machines with different processing capabilities, while trying to minimize the total length of the schedule U (makespan), i.e., the time required to complete parallel processing. In some implementations, the distribution of transactions among the processors can be done according to a random distribution scheme. In some implementations, the distribution can be done according to a deterministic distribution scheme.

[0080] Two example scheduling schemes include:

[0081] · FCFS (First Come First Served) distributes the transactions to the available processing units in a round - robin manner. This is a random distribution scheme. Given the t - th transaction starting from the top of the block, the core with ID t modulo N will be responsible for verification. The computational complexity of this scheduler is the lowest.

[0082] · LPT (Longest Processing Time) greedy algorithm provides a more efficient load - balancing solution and is an example of a deterministic distribution scheme. The jobs (transactions) can first be sorted by their respective processing times (the number of script operations, or the "cost" based on the sum of weighted script operations), and then assigned to the machine with the earliest end time so far, in order to balance the computational load of each processor.

[0083] In some implementations, the FCFS scheme may be vulnerable to malicious attacks that exploit the parallelism N of the validating nodes, for example, to build a block with demanding scripts every N or N / 2 transactions. To avoid this scenario, a truly random transaction verification distribution can be used at no additional cost.

[0084] The LPT algorithm achieves the following upper limit U relative to the theoretical optimal value U0:

[0085]

[0086] Note that sorting algorithms, such as Mergesort, are characterized by O(nlogn) worst-case and average time complexity. However, it is possible to j The UTXO uniqueness evaluation of operation 306 is performed simultaneously with the sorting of the values, thereby avoiding any additional computational cost.

[0087] As shown in operation 310, after the transactions are distributed among the parallel processors, the method 300 includes each of those processors independently verifying the corresponding set of distributed transactions. Once all individual transactions are verified as valid, the node can accept the block as valid, as shown in operation 312. Based on the validity of the block, accepting or designating the block as valid can result in additional functions, such as forwarding the valid block to one or more other peer nodes on the blockchain network. In some cases, the method 300 may include adding the block to the current node's locally stored copy of the blockchain.

[0088] If any processor detects an invalid transaction, the processor interrupts the verification method 300 and, as shown in operation 314, the node block is rejected as invalid.

[0089] Therefore, the present invention provides one or more technical solutions to at least one technical problem in the prior art. For example, the known blockchain arrangement does not teach the technology of serially verifying the validity of unspent transaction outputs (UTXO) in all transactions before distributing the transactions between parallel processors.

[0090] Now refer to Figure 4 , Figure 4 A simplified example of a node 400 is shown in block diagram form. The node 400 includes a plurality of processors 402, which may include two or more microprocessors, application specific integrated chips (ASICs), microcontrollers, or similar computer processing devices. The processors 402 may include multi-core processors.

[0091] Node 400 also includes memory 404, which may include persistent and non-persistent memory to store values, variables, and in some examples processor-executable program instructions, and network interface 406, which provides network connectivity via a wired or wireless network.

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

[0093] It should be understood that the devices and processes described herein and any modules, routines, processes, threads, applications, or other software components that implement the described methods / processes for configuring blockchain nodes can be implemented using standard computer programming techniques and languages. The present application is not limited to specific processors, computer languages, computer programming protocols, data structures, and other such implementation details.

[0094] It should be noted that the above embodiments illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of other elements and steps as a whole, even though these elements and steps are not listed in any claim or specification. In this specification, "comprises" means "includes or consists of...", and "comprising" means "including or consists of...". The singular reference of an element does not mean to exclude the plural reference of these elements, and vice versa. The present invention can be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a device claim that lists several means, several of these means may be embodied by the same component of hardware. The indisputable fact is that certain methods are listed in mutually different dependent claims, which does not mean that the combination of these methods cannot achieve beneficial effects.

Claims

1. A computer-implemented method for validating a block in a network of nodes implementing a blockchain conforming to a blockchain protocol, the block containing a plurality of transactions, the method comprising: Determining that the block meets the block-level verification criteria; serially determining that in each transaction of the plurality of transactions, each unspent transaction output referenced as an input is unique, and based on the determining: allocating each of the plurality of transactions to one of the two or more parallel processors, wherein allocating each of the plurality of transactions to one of the two or more parallel processors comprises: for each of the plurality of transactions, determining a processing cost for verifying that the transaction complies with a transaction-level verification standard based on a number of script operations in the transaction, and allocating the transaction to load balance the processing cost among the two or more parallel processors, and Verifying in parallel by the two or more parallel processors that transactions in the plurality of transactions comply with transaction-level verification criteria; and If the transaction meets the transaction-level validation criteria and the block meets the block-level validation criteria, the block is forwarded to one or more peer nodes in the network.

2. The method according to claim 1, wherein: The transaction-level validation criteria include transaction characteristics specified by the blockchain protocol, and wherein each transaction must have the transaction characteristics to be considered valid.

3. The method according to claim 1, wherein: The block-level validation criteria include block characteristics specified by the blockchain protocol, and wherein each block must have the block characteristics to be considered valid.

4. The method according to claim 1, wherein: Allocating each of the plurality of transactions to one of the two or more parallel processors includes allocating the transactions using a random allocation scheme or a deterministic allocation scheme.

5. The method according to claim 4, wherein: Allocating the transactions includes allocating the transactions among the two or more parallel processors using a first-come, first-served algorithm.

6. The method according to claim 1, wherein: The processing cost of each transaction is also based on a weighted sum of script operations, wherein each script operation has an associated weight based on the computational complexity of the script operation.

7. A method according to any one of the preceding claims, wherein: The serially determining that in each transaction of the plurality of transactions, each unspent transaction output referenced as an input is unique includes determining that each unspent transaction output appears only once as an input in the plurality of transactions.

8. A computing device in a network of nodes implementing a blockchain, the computing device being used to verify a block that complies with a blockchain protocol, the block containing a plurality of transactions, the computing device comprising: a network interface for providing a network connection to a network of nodes implementing a blockchain and receiving a block, the block conforming to the blockchain protocol and comprising a plurality of transactions; A block-level verification module, used to determine whether the block meets the block-level verification criteria; An input uniqueness confirmation module, configured to serially determine that each unspent transaction output referenced as an input in each of the plurality of transactions is unique; Two or more parallel processors, for verifying in parallel that transactions in the plurality of transactions comply with transaction-level verification criteria; and a transaction allocation unit, configured to allocate transactions among the plurality of transactions among the two or more parallel processors for verification, wherein allocating the transactions among the plurality of transactions among the two or more parallel processors comprises: for each transaction among the plurality of transactions, determining a processing cost for verifying that the transaction complies with a transaction-level verification standard based on a number of script operations in the transaction, and allocating the transactions to load balance the processing cost among the two or more parallel processors, Wherein, if the transaction meets the transaction-level verification criteria and the block meets the block-level verification criteria, the network interface forwards the block to one or more peer nodes in the network.

9. The computing device of claim 8, wherein: The transaction-level validation criteria include transaction characteristics specified by the blockchain protocol, and wherein each transaction must have the transaction characteristics to be considered valid.

10. The computing device of claim 8, wherein: The block-level validation criteria include block characteristics specified by the blockchain protocol, and wherein each block must have the block characteristics to be considered valid.

11. The computing device of claim 8, wherein: The transaction allocation unit allocates the transactions among the two or more parallel processors using a random allocation scheme or a deterministic allocation scheme.

12. The computing device of claim 11, wherein: Allocating the transactions includes allocating the transactions using a first-come, first-served algorithm.

13. The computing device of claim 8, wherein: The processing cost of each transaction is also based on a weighted sum of script operations, wherein each script operation has an associated weight based on the computational complexity of the script operation.

14. A computing device according to any one of claims 8 to 13, wherein: The input uniqueness confirmation module serially determines that each unspent transaction output referenced as an input in the multiple transactions is unique by determining that each unspent transaction output appears only once as an input in the multiple transactions.

15. A non-transitory processor-readable medium storing processor-executable instructions within a network of nodes implementing a blockchain, wherein: The instructions are used to verify a block that complies with a blockchain protocol, the block containing multiple transactions, and wherein the instructions cause two or more processors to execute the method according to any one of claims 1 to 7.

Images