Double-spend check

Abstract

A computer-implemented method comprising: partitioning a set of unspent transaction output points (UTXOs) of a blockchain into at least two partitions; performing, in parallel in each of the at least two partitions, a search for output points of previous blockchain transactions referenced by inputs of a first blockchain transaction; partitioning a set of spent transaction output points (STXOs) of the blockchain into at least two partitions; performing, in parallel in each of the at least two partitions, a search for output points of previous blockchain transactions referenced by inputs of the first blockchain transaction.

Description

Technical Field

[0001] This disclosure relates to a method, system, and computer program for determining whether the inputs of a blockchain transaction have been examined. Background Technology

[0002] The unspent transaction outpoint set is a dynamic collection of unspent transaction outpoints that is not necessarily consistent across the network. New members are added as members are removed from the set. As part of transaction verification, blockchain nodes (e.g., Bitcoin nodes) need to check if a transaction's input is in their unspent transaction outpoint set, i.e., whether it has been spent. If the transaction's input is in the unspent transaction outpoint set, the outpoint is spendable, allowing the blockchain node to continue verifying other inputs / outpoints of the transaction, or to verify the transaction if all its inputs have been verified. If the transaction's input is not in the unspent transaction outpoint set, the outpoint may be unspent (spent or not a valid outpoint), or the blockchain node may not have seen the outpoint yet. This check requires a lookup operation within the set. This set is typically large. Summary of the Invention

[0003] According to one aspect disclosed herein, a computer-implemented method is provided, comprising: partitioning a set of unspent transaction outpoints (UTXOs) of a blockchain into at least two partitions; and performing in parallel a search for the outpoints of a previous blockchain transaction referenced by the input of a first blockchain transaction in each of the at least two partitions.

[0004] The set of unspent transaction output points can also be referred to as the unspent transaction output set. Transaction outputs are referenced using a combination of the transaction identifier (TxID) of the transaction containing the output and the index of the output within that transaction. This combination of the TxID and the index is called an output point. Attached Figure Description

[0005] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which: Figure 1 This is a schematic block diagram of a system for implementing blockchain. Figure 2 The illustrations show some examples of transactions that can be recorded in a blockchain. Figure 3 This is a schematic block diagram of some node software used for processing transactions. Figure 4 It is a flowchart of the method. Detailed Implementation

[0006] 1. Cost Check Some examples described in this article perform lookup operations to check if the inputs of a transaction are in the UTXO set. This can be performed by blockchain nodes (e.g., Bitcoin nodes) as part of transaction verification. The examples described in this article provide a method for improving the efficiency of lookup operations. In some examples, efficiency is improved by A) splitting the lookup operation into multiple smaller lookup operations. In some examples, efficiency is improved by B) performing the lookup operation within a spent transaction. In some examples, A) and B) are performed in parallel.

[0007] Double-spending checks are performed during blockchain (e.g., Bitcoin) transaction verification. As blockchain networks (e.g., the Bitcoin network) scale, the size of the UTXO set will become increasingly large. For example, a Teranode block will be able to spend at least 600 million UTXOs, so the set needs to be able to handle at least that number of transactions. Therefore, even simple lookups can become a significant bottleneck in terms of transaction throughput. To overcome this potential bottleneck, two efficiency improvements, as described in this paper, can be used: A) By partitioning the UTXO set (within a Bitcoin node) into multiple parts, the lookup operation is broken down into smaller operations.

[0008] B) Perform a lookup operation on the spent output set (not the unspent output set).

[0009] These two improvements can be implemented individually or together and executed in parallel for maximum efficiency.

[0010] A) Discussed in Section 1.1, B) Discussed in Section 1.2.

[0011] 1.1 Partitioning the UTXO set The set of unspent transaction output points is a dynamic collection of unspent transaction outputs that is not necessarily consistent across the network. New members are added as members are removed from the set. The set of unspent transaction output points can be partitioned in a variety of different ways using different schemes. Searches can then be performed in parallel within each partition, reducing the amount of time spent performing lookup operations. As described in this paper, operations performed "in parallel" can be performed with at least partial (and in some cases, complete) overlap in time.

[0012] One way to partition a collection can be chronologically, where members (i.e., UTXOs) are sorted based on their creation time (block height), and new members of the collection are added to the latest part of the partition (or, if a previous part is full, to a new part). Each part can have a fixed or variable size, depending on a variable (e.g., block height). Given an output point, it is passed to each part for lookup operations. The outputs from all lookup operations are aggregated using an OR operator to obtain a final result that determines the validity of the entire transaction.

[0013] Another implementation is to stop all operations when one of the outputs of the lookup operation indicates that an entry has been found.

[0014] Another way to partition a collection is based on output point references (TXID and index), such as alphabetical order. The advantage of this partitioning scheme is that, given an output point, it is only passed to one part of the collection to perform a lookup operation based on the output point's TXID. While it doesn't require much parallelization of lookups, it does require a pre-sorted collection of outputs that doesn't incur transaction costs.

[0015] Once the set of unspent transaction output points is partitioned, searches can be performed in parallel across at least two partitions to find output points of previous blockchain transactions referenced by the inputs of the first blockchain transaction. If a search in a partition of the unspent transaction output point set returns a positive result, this indicates that the output point is spendable. The method can then proceed to verify other input / output points, or if the input / output point is the final input / output point in the transaction, the method can proceed to verify the transaction. If a search in a partition of the unspent transaction output point set returns a positive result, this indicates that the output point may be unspent (already spent or not a valid output), or that the output point may not have been seen yet.

[0016] 1.2 Set of Spent Transaction Output Points In this article, a spent output or spent output point refers to a transaction output that has been effectively spent by the input of a subsequent transaction. The set of spent transaction outpoints (STXOs) is a list of spent outputs (also called spent output points). Unlike the set of unspent transaction outpoints, the set of spent transaction outpoints (STXOs) is an append-only set. That is, once an output is added as a member of the STXO set, it will remain a member forever, and the size of this set monotonically increases with the size of the blockchain. When performing double-spending checks, the check against the set of unspent transaction outpoints is to look for a guaranteed positive result. The check against the STXO set is to look for a guaranteed negative result. In other words, once a match is received from the STXO set, it can be determined that the input / output point has been spent, and therefore the double-spending check fails. If the input of a blockchain transaction references an output point of a previous blockchain transaction in the blockchain's STXO, it can be determined that the input / output point of the blockchain transaction has been spent, and therefore the double-spending check fails. The transaction can then be rejected by the blockchain nodes.

[0017] However, if no match is found in the STXO set, the UTXO set still needs to be checked. In some examples, the lookup in the STXO set is performed in parallel with the lookup in the UTXO set as a supporting operation (this can be useful because a lookup in the STXO set may not provide definitive results). When a match is found in the STXO set, the lookup of the unspent transaction output point set for other output points in the complete transaction can stop, which saves some computation.

[0018] In some examples, the size of the lookup set can be reduced by retaining only the most recently spent transactions (a smaller set than the entire STXO set). The risk of a successful double-spend attempt (where the network has both versions of the transaction simultaneously) typically occurs only for a short period (e.g., the first few seconds) when the transaction first appears on the network. After this, the transaction will be seen on all nodes, and the double-spend attempt is unlikely to succeed. The cost of adding a fast lookup on this small set is negligible, and the lookup of the unspent transaction output point set for other output points in the complete transaction can stop when a match is found, saving some computation.

[0019] As described above in the section on partitioning the set of unspent transaction output points, the STXO set (or limited to the STXO set of transactions spent in the most recent period) can be partitioned into multiple parts to parallelize the lookup operations. A similar partitioning scheme as described above can be used.

[0020] The STXO set can be partitioned chronologically, where members (i.e., STXOs) are sorted based on their creation time (block height), and new members of the set are added to the latest part of the partition (or, if a previous part is full, to a new part). Each part can have a fixed or variable size, depending on a variable (e.g., block height). When an output point is given, it is passed to each partition to perform lookup operations in the partition's STXO set. The outputs from all lookup operations are aggregated using an OR operation to obtain a final result that determines the validity of the entire transaction.

[0021] Another way to partition a set of STXOs (or scaled-down STXOs) is based on output point references (TXID and index), such as alphabetical order. The advantage of this partitioning scheme is that, given an output point, it is only passed to one part of the partitions to perform a lookup operation based on the output point's TXID. While it doesn't require parallelization of many lookups, it does require a pre-sorted set of STXOs.

[0022] Once the STXO set (or the most recent STXO set) is partitioned, searches can be performed in parallel across at least two partitions to find the output point of a previous blockchain transaction referenced by the input of the first blockchain transaction. If the search in a partition of the STXO set (or the most recent STXO set) returns a positive result, this indicates that the output point is unspendable. The method can then continue to reject transactions. If the search in a partition of the STXO set (or the most recent STXO set) returns a negative result, this indicates that the output point may be spendable or that the output point does not exist.

[0023] Table 1 summarizes the different search results in the unspent transaction output point set and the STXO set.

[0024]

[0025] Table 1: Summary of different search results in the unspent transaction output point set and the STXO set.

[0026] Figure 4 A flowchart of the method is shown. This method can be executed, for example, by a blockchain node or a device located at a blockchain node.

[0027] At S1, the method includes partitioning the blockchain's UTXO set into at least two partitions.

[0028] At S2, the method includes performing a search in parallel in each of at least two partitions for the output point of a previous blockchain transaction referenced by the input of the first blockchain transaction.

[0029] 2. Exemplary System Overview A blockchain is a distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely publicized. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Apart from the so-called "coinbase transaction," each transaction points to a previous transaction in a sequence that can span one or more blocks and return to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating new blocks is often called "mining," which involves each of the multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on a defined, ordered, and verified set of pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of a block can be achieved by publishing only the block header.

[0030] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing timestamped entries; and / or sorting index pointers by time. Additional layered functionalities on the blockchain can also be implemented. For example, blockchain protocols can allow the storage of additional user data or data indexes within transactions. There is no pre-specified limit to the maximum data capacity that can be stored in a single transaction, thus allowing increasingly complex data to be incorporated. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

[0031] In the "output-based" model (sometimes called the UTXO-based model), a given transaction's data structure includes one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of digital assets, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies the future redemption conditions of the output. A locking script is a predicate that defines the conditions necessary to verify and transfer digital tokens or assets. Each input to a transaction (other than coinbase transactions) includes a pointer (i.e., a reference) to such outputs in a previous transaction and may also include an unlocking script used to unlock the locking script pointing to the output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying the amount of digital assets and includes a locking script defining one or more conditions for unlocking that output. The second (target) transaction includes at least one input and an unlocking script, the at least one input including a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0032] In this model, when a second (target) transaction is sent to the blockchain network for propagation and recording, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the conditions defined in one or more of the locking script of the first transaction. Another condition will be that the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid based on any of these conditions will not propagate the transaction (as a valid transaction, but possibly registering it as invalid) nor include it in a new block to be recorded in the blockchain.

[0033] Another transaction model is the account-based model. In this case, the amount of each transaction is not defined by referring to the UTXO of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes and is continuously updated.

[0034] Figure 1 An exemplary system 100 for implementing blockchain 150 is shown. System 100 may include a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 (typically referred to as “miners”), which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0035] Each blockchain node 104 includes peer computer devices, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs), as well as other devices, such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable memory in the form of non-transitory computer-readable media. The memory may include one or more memory cells that employ one or more memory media, such as magnetic media like hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0036] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Rather, blockchain 150 can be pruned as long as each blockchain node 150 stores the block header of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a specific transaction protocol throughout.

[0037] Blockchain node 104 can be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Blockchain node 104 can be configured to create block 151 and store a corresponding copy of the same blockchain 150 in its corresponding memory. Blockchain node 104 can also maintain an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as a “mempool.” In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of transactions that node 104 has accepted as valid, and for that set of transactions, node 104 is forced not to accept any other transactions attempting to spend the same output.

[0038] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring financial assets, although this is certainly a common application. More generally, spending can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when the current transaction 152j is created or even sent to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0039] Due to the resources involved in transaction verification and publication, each blockchain node 104 typically takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a single user terminal or a networked set of user terminals.

[0040] Each blockchain node 104's memory stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role and process transactions 152 according to the blockchain node protocol. It should be understood that any action attributed herein to the blockchain node 104 can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or lower layers such as the operating system layer or protocol layer, or any combination of these layers.

[0041] Any given blockchain node can be configured to perform one or more of the following operations: verifying transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node can be specialized for a particular operation. For example, node 104 can focus on transaction verification and propagation, or it can focus on block mining. In some examples, blockchain node 104 can perform more than one of these operations in parallel. Any reference to blockchain node 104 can refer to the entity configured to perform at least one of these operations.

[0042] The computer devices 102 of each of the multiple parties 103, acting as consumer users, are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities storing copies of the blockchain 150 (e.g., having already obtained a copy of the blockchain from blockchain node 104).

[0043] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on blockchain network 106. Users of the blockchain network (often referred to as “clients”) may be considered part of the system containing blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required for blockchain nodes. Instead, each party 103 may interact with blockchain network 106 to utilize blockchain 150 by connecting to blockchain node 106 (i.e., communicating with blockchain node 106). For illustrative purposes, parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in system 100, but are not shown for convenience. Each party 103 may be an individual or organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob in this document, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document may be replaced by "first party" and "second party" respectively.

[0044] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0045] The client application 105 may initially be provided to any given party 103's computer device 102 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0046] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the respondent 103 to create, authorize (e.g., sign) transactions 152 and send them to one or more Bitcoin nodes 104, which then propagate through the network of blockchain nodes 104, thus being included in blockchain 150. The other function is to report to the respondent the amount of digital assets they currently possess. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across blockchain 150.

[0047] Note: While various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented in a suite of two or more different applications, such as through an API interface or as a plugin for one application. More colloquially, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

[0048] An instance of client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also liaise with blockchain node 104 to query blockchain 150 for any transaction in which the corresponding party 103 is the recipient (or actually to check other parties' transactions in blockchain 150, since, in this embodiment, blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify transaction 152 according to a blockchain node protocol and forward transaction 152 for propagation in blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. All nodes 104 in network 106 use the same node protocol.

[0049] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the network's nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0050] Some account-based transaction models share similarities with the output-based transaction model described in this paper. For example, as mentioned above, the data fields of an account-based transaction can point to the previous transaction, which is equivalent to the input of an output-based transaction referencing the output point of the previous transaction. Therefore, both models support chaining between transactions. As another example, an account-based transaction includes a "recipient" field (specifying the account's receiving address) and a "value" field (specifying a certain amount of digital assets). The recipient and value fields together are equivalent to the output of an output-based transaction, which can be used to allocate a certain amount of digital assets to a blockchain address. Similarly, account-based transactions have a "signature" field, which includes the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes the transaction's signature. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine if the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contract" refers to a transaction containing a script configured to perform one or more actions (e.g., sending or "releasing" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions. Therefore, in some examples, a smart contract can be viewed as equivalent to a locking script for an output-based transaction (which can be triggered by a subsequent transaction) that checks whether the inputs of the subsequent transaction satisfy one or more conditions defined in the locking script.

[0051] 3. UTXO-based model Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments. It should be noted that while an exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other example blockchain networks.

[0052] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO may also contain the transaction ID of its source transaction, as well as other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 committed to node 104.

[0053] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the middle, Alice's New Affairs 152j is marked as " Tx 1 The new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In the middle, the previous transaction 152i is marked as " Tx 0 ". Tx 0 and Tx 1 It is just an arbitrary marker, and it does not necessarily mean Tx 0 The first transaction in Blockchain 151 and Tx 1 Subsequent transactions in pool 154. Tx 1 It can point to any previous (i.e. preceding) transaction that still has an unspent output 203 locked to Alice.

[0054] As used in the context of transaction sequences in this article, the terms "previous" and "subsequent" refer to the order of transactions in the sequence defined by the transaction pointers specified within the transaction (which transaction points to which other transaction, etc.). They can also be replaced with "predecessor" and "successor," "ancestor" and "descendant," or "parent" and "child," etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") that point to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. Children that arrive at blockchain node 104 before their parent are considered orphaned. Depending on the node protocol and / or node behavior, they may be discarded or buffered for a period of time to wait for their parent.

[0055] Previous matters Tx 0 One or more outputs 203 include a specific UTXO, tagged as UTXO 0 Each UTXO includes a value representing the amount of digital assets and a locking script that defines the conditions that the unlocking script in input 202 of a subsequent transaction must meet to make the subsequent transaction valid and thus successfully redeem the UTXO.

[0056] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "script" (with an uppercase S), which can be used by the blockchain network. The locking script specifies the information required for the transaction output 203, such as Alice's signature requirement. The locking script appears in the transaction output. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0057] Therefore, in the example shown, Tx 0 Output 203 UTXO 0 Including the locking script [Checksig] P A This locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for those who attempt to redeem) UTXO 0 Subsequent transactions are valid). [Checksig] P A Contains the public key from Alice's public-private key pair. PA The representation of (i.e., hash). Tx 1 Input 202 includes pointers to Tx 1 pointers (e.g., via their transaction IDs) TxID 0 In the implementation example, this refers to the entire transaction. Tx 0 (hash value). Tx 1 Input 202 includes Tx 0 Chinese logo UTXO 0 The index, in order to Tx 0 It is identified in any other possible output. Tx 1 Input 202 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0058] When new transactions Tx 1 Upon reaching blockchain node 104, the node applies the node protocol. This includes running the locking and unlocking scripts together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria).

[0059] It should be noted that script code is typically represented graphically (i.e., using a non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For instance, OP_RETURN is a scripting language opcode. When OP_FALSE is added before the opcode at the beginning of the locking script, the opcode creates a non-spendable output for the transaction. This output can store data within the transaction, thus immutably recording the data in the blockchain. For example, the data may include files that need to be stored in the blockchain.

[0060] Typically, the input to a transaction contains a digital signature corresponding to the public key PA. In this embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature, used to select the output to be signed (and thus fixed at the time of signing).

[0061] Locking scripts are sometimes called "scriptPubKey," referring to the fact that they typically include the public keys of the parties to whom the corresponding transaction is locked. Unlocking scripts are sometimes called "scriptSig," referring to the fact that they typically provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0062] 4. Node software Figure 3 An example of node software 350 running on each blockchain node 104 of network 106 is shown, in an example of a UTXO-based or output-based model. It should be noted that another entity can run node software 350 without being classified as a node 104 on network 106, i.e., without performing the actions required by node 104. Node software 350 may include, but is not limited to, a protocol engine 351, a script engine 352, a stack 353, an application-level decision engine 354, and a collection of one or more blockchain-related functional modules 355. Each node 104 may run node software containing one or more of the following: a consensus module 355C (e.g., proof-of-work), a propagation module 355P, and a storage module 355S (e.g., a database). Consensus module 355C may include a verification module (not shown) configured to verify transactions according to the blockchain protocol. The verification module may also be separate from consensus module 355C. One or more of these modules may operate in parallel. Node 104 may include additional modules. Protocol engine 351 is typically configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a field pointing to another previous transaction 152i is received... Tx m-1 The input of transaction 152j is the output (e.g., UTXO) of the transaction. Tx j When ), the protocol engine 351 identifier Tx j The unlock script is then passed to script engine 352. Protocol engine 351 is also based on... Tx j Pointers in the input are used to identify and retrieve. Tx i . Tx i It can be published on blockchain 150, in which case the protocol engine can retrieve it from the copy of block 151 of blockchain 150 stored at node 104. Tx i .or, Tx i It can also be published on blockchain 150. In this case, protocol engine 351 can retrieve it from the unpublished ordered transaction set 154 maintained by node 104. Tx i Regardless of the method used, script engine 351 will identify... Tx i The locked script is referenced in the output and passed to the script engine 352.

[0063] Therefore, script engine 352 has Tx i The locking script and from Tx j The corresponding input unlock script. For example, in Figure 2 The transaction marker is shown in the image. Tx 0 and Tx 1 However, the same transaction can be applied to any transaction pair. As mentioned earlier, script engine 352 runs two scripts together, which will include placing data onto stack 353 and retrieving data from stack 353 according to the stack-based scripting language used (e.g., script).

[0064] By running the scripts simultaneously, the script engine 352 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 352 returns this determination to the protocol engine 351. If the script engine 352 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0065] In the output-based model, the result "TRUE" from script engine 352 is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by protocol engine 351 must also be met; for example, Tx j The total amount of digital assets specified in the input does not exceed the total amount pointed to in its output, and Tx iThe output pointed to by the transaction has not yet been spent by another valid transaction. Protocol engine 351 evaluates the results from script engine 352 along with one or more protocol-level conditions, and only verifies the transaction if all of them are TRUE. Tx j Valid. Protocol engine 351 outputs an indication of whether the transaction is valid to application-level decision engine 354. Only when... Tx j Under truly effective conditions, decision engine 354 can choose to simultaneously control consensus module 355C and propagation module 355P to execute its intended purpose. Tx j The corresponding blockchain-related functions. This includes consensus module 355C, which adds to the corresponding ordered transaction set 154 of the nodes. Tx j , used to be incorporated into block 151; and propagation module 355P, to Tx j The transaction is forwarded to another blockchain node 104 in network 106. Optionally, in an embodiment, the application-level decision engine 354 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may only choose to publish a transaction if it is valid and sufficient transaction fees are reserved.

[0066] Furthermore, it should be noted that in this paper, the terms "TRUE" and "FALSE" are not necessarily limited to returning a result represented only as a single binary number (bit), although this is indeed one possible implementation. More colloquially, "TRUE" can refer to any state indicating a successful or affirmative result, while "FALSE" can refer to any state indicating an unsuccessful or uncertain result. For example, in an account-based model, a combination of implicit protocol-level verification of the signature and an additional affirmative output from the smart contract can indicate a result of "TRUE" (the overall result is considered TRUE if both individual results are TRUE).

[0067] 7. Further comments Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.

[0068] For example, some of the embodiments described above have been based on Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 above can be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the characteristics described above for Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104.

[0069] In a preferred embodiment of the invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. It is not excluded that other network entities (or network elements) may perform only one or some of these functions, but not all of them. That is, network entities may perform the function of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered nodes of the preferred Bitcoin network 106).

[0070] In other embodiments of the invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that nodes may perform at least one or more, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, on these other blockchain networks, "node" can be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or propagate these blocks 151 to other nodes.

[0071] To put it even more colloquially, any reference above to the term "Bitcoin node" 104 can be replaced by the terms "network entity" or "network element," where such an entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element can be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0072] Some embodiments have been described based on a blockchain network used to implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is merely one type of consensus mechanism, and in general embodiments, any suitable consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is typically called a validator. Blockchain nodes can lock their tokens for a period of time to have the opportunity to become a validator. Generally, the node that locks the largest amount of tokens for the longest time is most likely to become the next validator.

[0073] It should be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided based on any one or more of the following statements.

[0074] Statement 1: A computer-implemented method comprising: partitioning a set of unspent transaction outputs (UTXOs) of a blockchain into at least two partitions; and performing in parallel a search for outputs of previous blockchain transactions referenced by inputs of a first blockchain transaction in each of the at least two partitions. According to a first embodiment of Statement 1, the method further comprises: partitioning a set of spent transaction outputs (STXOs) of the blockchain into at least two partitions; and performing in parallel a search for outputs of previous blockchain transactions referenced by inputs of the first blockchain transaction in each of the at least two partitions.

[0075] Statement 2: A computer-implemented method according to Statement 1 or the first embodiment of Statement 1, the method comprising: partitioning the UTXO set into the at least two partitions according to the corresponding block height of each of a plurality of blocks, wherein each block includes at least one output point in the UTXO set.

[0076] Statement 3: A computer-implemented method according to Statement 1 or the first embodiment of Statement 1, the method comprising: partitioning the UTXO set into the at least two partitions based on outpoint references.

[0077] Statement 4: A computer-implemented method according to any of the preceding statements or embodiments, the method comprising: partitioning the set of spent transaction output points (STXOs) of the blockchain into at least two partitions; and performing in parallel a search for output points of previous blockchain transactions referenced by the input of a second blockchain transaction in each of the at least two partitions.

[0078] Statement 5: The computer-implemented method according to Statement 4, the method comprising: partitioning the STXO set into the at least two partitions according to the corresponding block height of each of a plurality of blocks, wherein each block includes at least one output point in the STXO set.

[0079] Statement 6: The computer-implemented method according to Statement 4, the method comprising: partitioning the STXO set into the at least two partitions based on output point references.

[0080] Statement 7: A computer-implemented method according to any of the preceding statements or embodiments, the method comprising: determining, in the STXO of the blockchain, an output point of a previous blockchain transaction referenced by an input of a third blockchain transaction; and rejecting the third blockchain transaction.

[0081] Statement 8: The computer-implemented method according to Statement 7, the method comprising: determining that the output point of a previous blockchain transaction referenced by the input of the fourth blockchain transaction is not in the STXO set; determining that the output point of the previous blockchain transaction referenced by the input of the fourth blockchain transaction is in the UTXO set; and accepting the fourth blockchain transaction.

[0082] Statement 9: The computer-implemented method according to Statement 8, the method comprising performing the following steps in parallel: determining that the output point of a previous blockchain transaction referenced by the input of the fourth blockchain transaction is not in the STXO set, and determining that the output point of the previous blockchain transaction referenced by the input of the fourth blockchain transaction is in the UTXO set.

[0083] Statement 10: A computer-implemented method according to any of the preceding statements or embodiments, the method comprising: determining that the output point of a previous blockchain transaction referenced by the input of a fifth blockchain transaction is not in the STXO set; determining that the output point of the previous blockchain transaction referenced by the input of the fifth blockchain transaction is not in the UTXO set; and determining that the output point of the fifth blockchain transaction is unspendable.

[0084] Statement 11: The computer-implemented method according to Statement 10, the method comprising performing the following steps in parallel: determining that the output of a previous blockchain transaction referenced by the output point of the fifth blockchain transaction is not in the STXO set, and determining that the output of the previous blockchain transaction referenced by the output point of the fifth blockchain transaction is not in the UTXO set.

[0085] Statement 12: A computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to perform a method according to any one of statements 1 to 11, or a first embodiment of statement 1, when executed on the processing means.

[0086] Statement 13: A computer program contained on a computer-readable storage medium and configured to perform, when run on one or more processors, the method according to any one of statements 1 to 11, or the first embodiment of statement 1.

[0087] Statement 1': A computer-implemented method, the method comprising: determining that the output point of a previous blockchain transaction referenced by the input of a first blockchain transaction is in the Spent Transaction Outpoint set (STXO) of the blockchain; and rejecting the first blockchain transaction.

[0088] Statement 2': The computer-implemented method according to Statement 1', the method comprising: determining that the output point of a previous blockchain transaction referenced by the input of the second blockchain transaction is not in the STXO set; determining that the output point of the previous blockchain transaction referenced by the input of the second blockchain transaction is in the Unspent Transaction Output Points (UTXO) set; and accepting the second blockchain transaction.

[0089] Statement 3': The computer-implemented method according to Statement 2', the method comprising performing the following operations in parallel: determining that the output point of a previous blockchain transaction referenced by the input of the second blockchain transaction is not in the STXO set, and determining that the output point of the previous blockchain transaction referenced by the input of the second blockchain transaction is in the UTXO set.

[0090] Statement 4': A computer-implemented method according to any one of statements 1' to 3', the method comprising: determining that the output point of a previous blockchain transaction referenced by the input of a third blockchain transaction is not in the STXO set; determining that the output point of the previous blockchain transaction referenced by the input of the third blockchain transaction is not in the UTXO set; and determining that the output point of the third blockchain transaction is unspendable.

[0091] Statement 5': The computer-implemented method according to Statement 4', the method comprising performing the following operations in parallel: determining that the output point of a previous blockchain transaction referenced by the input of the third blockchain transaction is not in the STXO set, and determining that the output point of a previous blockchain transaction referenced by the input of the third blockchain transaction is not in the UTXO set.

[0092] Statement 6': A computer-implemented method according to any one of statements 2' to 5', the method comprising: partitioning the UTXO set into at least two partitions; and performing in parallel a search for the output point of a previous blockchain transaction referenced by an input of a fourth blockchain transaction in each of the at least two partitions.

[0093] Statement 7': The computer-implemented method according to statement 6', the method comprising: partitioning the UTXO set into the at least two partitions according to the corresponding block height of each of a plurality of blocks, wherein each block includes at least one output point in the UTXO set.

[0094] Statement 8': The computer-implemented method according to statement 6', the method comprising: partitioning the UTXO set into the at least two partitions based on output point references.

[0095] Statement 9': A computer-implemented method according to any one of statements 1' to 8', the method comprising: partitioning the STXO set into at least two partitions; and performing in parallel a search for the output point of a previous blockchain transaction referenced by an input of a fourth blockchain transaction in each of the at least two partitions.

[0096] Statement 10': The computer-implemented method according to statement 9', the method comprising: partitioning the STXO set into the at least two partitions according to the corresponding block height of each of a plurality of blocks, wherein each block includes at least one output point in the STXO set.

[0097] Statement 11': The computer-implemented method according to statement 9', the method comprising: partitioning the STXO set into the at least two partitions based on output point references.

[0098] Statement 12': A computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to perform a method according to any one of statements 1' to 11' when run on the processing means.

[0099] Statement 13': A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of statements 1' to 11' when run on one or more processors.

Claims

1. A computer-implemented method, the method comprising: Partition the blockchain’s set of unspent transaction output points (UTXOs) into at least two partitions; In each of the at least two partitions, a search is performed in parallel for the output point of a previous blockchain transaction referenced by the input of the first blockchain transaction; The set of Spent Transaction Output Points (STXOs) of the blockchain is partitioned into at least two partitions; In each of the at least two partitions, a search is performed in parallel for the output point of a previous blockchain transaction referenced by the input of the first blockchain transaction.

2. The computer-implemented method according to claim 1, the method comprising: The UTXO set is partitioned into at least two partitions based on the corresponding block height of each of the multiple blocks, wherein each block includes at least one output point in the UTXO set.

3. The computer-implemented method according to claim 1, the method comprising: The UTXO set is partitioned into at least two partitions based on the output point reference.

4. The computer-implemented method according to any one of the preceding claims, the method comprising: In each of the at least two partitions, a search is performed in parallel for the output point of the previous blockchain transaction referenced by the input of the second blockchain transaction.

5. The computer-implemented method according to any one of the preceding claims, the method comprising: The STXO set is partitioned into at least two partitions based on the corresponding block height of each of the multiple blocks, wherein each block includes at least one output point in the STXO set.

6. The computer-implemented method according to any one of the preceding claims, the method comprising: The STXO set is partitioned into at least two partitions based on the output point reference.

7. A computer-implemented method according to any one of the preceding claims, the method comprising: The output point of a previous blockchain transaction referenced by the input of a third blockchain transaction is determined in the STXO of the blockchain; The third blockchain transaction is rejected.

8. The computer-implemented method according to claim 7, the method comprising: Determine that the output point of the previous blockchain transaction referenced by the input of the fourth blockchain transaction is not in the STXO set; The output point of the previous blockchain transaction referenced by the input of the fourth blockchain transaction is determined in the UTXO set; Accept the fourth blockchain transaction.

9. The computer-implemented method of claim 8, the method comprising performing in parallel: determining that the output point of a previous blockchain transaction referenced by the input of the fourth blockchain transaction is not in the STXO set, and determining that the output point of the previous blockchain transaction referenced by the input of the fourth blockchain transaction is in the UTXO set.

10. The computer-implemented method according to any one of the preceding claims, the method comprising: Determine that the output point of the previous blockchain transaction referenced by the input of the fifth blockchain transaction is not in the STXO set; It is determined that the output point of the previous blockchain transaction referenced by the input of the fifth blockchain transaction is not in the UTXO set; The output point of the fifth blockchain transaction is determined to be unspendable.

11. The computer-implemented method of claim 10, the method comprising performing in parallel: determining that the output of a previous blockchain transaction referenced by the output point of the fifth blockchain transaction is not in the STXO set, and determining that the output of the previous blockchain transaction referenced by the output point of the fifth blockchain transaction is not in the UTXO set.

12. A computer device, the computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 11 when run on the processing apparatus.

13. A computer program, the computer program being contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 11 when run on one or more processors.

Images