Data Structures for Orphaned Transactions

Abstract

A computer-implemented method performed by a blockchain node includes maintaining a data structure representing orphaned transactions, where an orphaned transaction is a blockchain transaction that has at least one parent transaction that is an unavailable transaction and / or at least one parent transaction that is a different orphaned transaction, where an unavailable transaction is a transaction that is not available to the validation pipeline of the blockchain node, where the data structure includes a directed graph of nodes and edges, where each node of the graph represents either a respective orphaned transaction or a respective unavailable transaction, and where each edge connecting each parent node to a respective child node represents usage of an output of each transaction represented by each parent node by an input of each transaction represented by each child node.

Description

[Technical field]

[0001] The present disclosure relates to methods for creating and / or maintaining data structures for representing orphaned transactions, and to the data structures themselves. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter also referred to as the "blockchain network"). The blockchain includes a chain of blocks of data, each block including one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to the preceding transaction in the sequence. The sequence may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are generated by a process known as "mining". "Mining" involves multiple nodes each competing to perform a "proof-of-work", i.e., solving a cryptographic puzzle based on the presentation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. Of note, the blockchain may be pruned at some nodes, and publication of blocks can be achieved through publication of only the block headers.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: to carry digital assets (i.e., multiple digital tokens), to order a set of entries in a virtual ledger or registry, to receive and process timestamp entries, and / or to time-sequence index pointers. A blockchain can also be used to layer additional functionality on top of a blockchain. For example, a blockchain protocol may allow additional user data or indexes to be stored on data within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction. Thus, more complex data can be incorporated. For example, this can be used to store electronic documents, or audio or video data, within the blockchain.

[0004] Nodes of the blockchain network (sometimes called "miners") perform a distributed transaction registration and validation process, which is described in detail below. Briefly, during this process, nodes validate transactions, insert them into a block template, and attempt to identify a valid proof-of-work solution for it. Once a valid solution is found, the new block is propagated to other nodes of the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes of the network for propagation. Nodes receiving the transaction compete to find a proof-of-work solution and include the validated transaction in a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not included in a block. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) thus remains registered and indexed in each node of the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that generates a new amount of digital assets, or number of tokens. Detection and rejection of invalid transactions is performed by the actions of competing nodes that act as agents of the network and are incentivized to report and block illicit activity. Widespread publication of information allows users to continuously audit node performance. By simply publishing block headers, participants can guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset that can be derived from the preceding transaction sequence. A spendable output is sometimes called an unspent transaction output (UTXO). An output may further include a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that includes a locking script that specifies the amount of a digital asset and defines one or more conditions for unlocking the output. The second target transaction includes at least one input including a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlock script meets all of one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction) (but may register an invalid transaction) and will not include it in a new block to be recorded in the blockchain. Summary of the Invention

[0008] Blockchain transactions form a chain, whereby the inputs of one transaction (the child transaction) reference the outputs of the previous transaction in the chain (the parent transaction). A chain can contain any number of transactions.

[0009] A child transaction must be validated by blockchain nodes before it can be included in a block. The process of validating a child transaction involves performing various checks on the parent transaction, such as verifying that the parent transaction exists and verifying that the amount of digital assets distributed in the child transaction's outputs is not greater than the amount of digital assets associated with the parent transaction's referenced outputs, and using the parent transaction.

[0010] However, blockchain nodes do not necessarily receive a chain of transactions in order. For example, a child transaction may arrive at a node before its parent arrives, or before its grandparent arrives. Such transactions are called orphaned transactions. In a blockchain node, a child transaction cannot be verified because the parent transaction needs to verify the child transaction.

[0011] Some blockchain protocols use a validation pipeline to process and validate transactions. A validation pipeline includes a set of processors, each performing a specific task. At least one processor is tasked with validating a child transaction based on a parent transaction. An identified bottleneck for validating transactions occurs when a child transaction enters the validation pipeline and one of its outpoints (i.e., outputs of a previous transaction referenced by an input of the child transaction) belongs to a parent transaction that has not yet been discovered by the blockchain node. This leads to a deadlock problem, where a blockchain node repeatedly tries and fails to validate the child transaction, prioritizing validation of the child transaction over the parent transaction.

[0012] According to one aspect disclosed herein, a computer-implemented method executed by a blockchain node includes: maintaining a data structure representing orphaned transactions, where an orphaned transaction is a blockchain transaction that has at least one parent transaction that is an unavailable transaction and / or at least one parent transaction that is a different orphaned transaction, where an unavailable transaction is a transaction that is not available to a validation pipeline of the blockchain node; Including, the data structure includes a directed graph of nodes and edges, each node of the graph representing either a respective orphaned transaction or a respective unavailable transaction, and each edge connecting a respective parent node to a respective child node representing a usage of an output of the respective transaction represented by the respective parent node by an input of the respective transaction represented by the respective child node; Each node of the graph is associated with a respective transaction identifier for each of the transactions represented by the node, such as: a) each of the in-degree values, each of the in-degree values ​​being as follows: i) a first value indicating that each of the transactions has an unknown number of parent transactions that are either unavailable transactions or orphaned transactions; or ii) a value of 0, indicating that each of the transactions has no parent transactions that are either unavailable or orphaned; or iii) a value indicating the number of each of said transactions' respective parent transactions that are either unavailable transactions or orphaned transactions; , and b) a list of each reference of each child node, if any, connected to the node by each edge; A method is provided, comprising:

[0013] According to another aspect disclosed herein, a data structure is provided that represents an orphaned transaction, where the orphaned transaction is a blockchain transaction that has at least one parent transaction that is an unavailable transaction and / or at least one parent transaction that is a different orphaned transaction, where the unavailable transaction is a transaction that is not available to a validation pipeline of a blockchain node; the data structure includes a directed graph of nodes and edges, each node of the graph representing either a respective orphaned transaction or a respective unavailable transaction, and each edge connecting a respective parent node to a respective child node representing a usage of an output of the respective transaction represented by the respective parent node by an input of the respective transaction represented by the respective child node; Each node of the graph is associated with a respective transaction identifier for each of the transactions represented by the node, such as: a) each of the in-degree values, each of the in-degree values ​​being as follows: i) a first value indicating that each of the transactions has an unknown number of parent transactions that are either unavailable transactions or orphaned transactions; or ii) a value of 0, indicating that each of the transactions has no parent transactions that are either unavailable or orphaned; or iii) a value indicating the number of each of said transactions' respective parent transactions that are either unavailable transactions or orphaned transactions; , and b) a list of each reference of each child node, if any, connected to the node by each edge; A data structure is provided that includes:

[0014] The present disclosure provides a novel data structure (called an "orphan pool") for representing and / or organizing orphaned transactions. The orphan pool is updated by adding or updating nodes when orphaned transactions arrive at a blockchain node. Orphaned transactions are sent to the orphan pool rather than to a validation pipeline, thus avoiding deadlock issues. Similarly, the orphan pool is updated when an orphaned transaction is released from the orphan pool to a node's validation pipeline when a required parent transaction becomes available. The data structure uses a directed graph of nodes and edges, where "node" is used in a different context to represent an element of the graph, rather than a blockchain node that creates and / or maintains the graph.

[0015] Each node in the graph ("graph node") represents a transaction in the orphan pool. More specifically, each graph node represents either an orphan transaction or an unavailable transaction. An unavailable transaction (also called an "unseen transaction") is a transaction that is not recognized (seen) by a blockchain node's validation pipeline, or in some cases, by the blockchain node as a whole. An orphan transaction is either a child transaction of an orphan transaction (i.e., the parent of the child transaction is an orphan transaction) or a child of an unseen transaction.

[0016] Each graph node may also contain the transaction represented by that node. Alternatively, the transactions may be stored elsewhere, and in some embodiments the location (e.g., memory address) of the transaction may be referenced by the graph node. [Brief description of the drawings]

[0017] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference is made by way of example only to the accompanying drawings in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates diagrammatically some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 2 is a schematic block diagram of specific node software for processing transactions. [Figure 4] FIG. 1 is a schematic block diagram of an example of a blockchain node for having an orphan pool. [Diagram 5] 1 illustrates a schematic example of an isolated pool structure. [Figure 6] Schematically shows a node (i) being added to the orphan pool and a node (ii) being updated. [Figure 7] 13A illustrates a schematic of a node being removed from an orphan pool. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] 1. Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled to the other blockchain nodes 104.

[0019] Each blockchain node 104 includes a peer computing device with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application specific processors, and / or other devices such as field programmable gate arrays (FPGAs) and application specific integrated circuits (ASICs). Each node also includes a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium or media. The memory may include one or more memory units using one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as a solid-state drive (SSD), a flash memory or an EEPROM, and / or an optical medium such as an optical disk drive.

[0020] The blockchain 150 includes a chain of blocks 151 of data, each copy of which is maintained at each of multiple nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies a quantity that represents an amount of the digital asset as an asset. In this example, the outputs are cryptographically locked by a user 103 (requiring that user's signature or other solution to unlock them and thereby redeem or spend them). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0021] Each block 151 also contains a block pointer 155 that points back to a previously generated block 151 in the chain to define a sequential order to the blocks 151. Each transaction 152 (other than coinbase transactions) contains a pointer to a previous transaction to define an order to the sequence of transactions (Note: a sequence of transactions 152 is allowed to branch). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a preceding transaction.

[0022] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 across the network 106. Each blockchain node 104 is configured to generate blocks 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is sometimes referred to as a "mempool." This term is not limited herein to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0023] In a given current transaction 152j, the input (or each of them) includes a pointer that references an output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. Using or redeeming does not necessarily mean the transfer of a financial asset, although that is certainly one common application. More generally, using can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106, but a previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by pointers, and not necessarily to the time of creation or transmission in the chronological order. Thus, it does not necessarily preclude transactions 152i, 152j from being created or sent out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0024] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to split the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may have multiple inputs and aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0025] According to a Bitcoin-like output-based transaction protocol, when an entity 103, such as an individual user or an organization, wants to act on a new transaction 152j (either manually or by an automated process used by the party), the acting entity sends the new transaction from its computer terminal 102 to a recipient. The acting party or recipient eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (these are typically servers or data centers today, but in principle other user terminals are also possible). In some examples, it is not excluded that the party 103 acting on the new transaction 152j could send the transaction directly to one or more of the blockchain nodes 104 instead of to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such output-based transaction protocols, this may involve checking that a cryptographic signature or other authentication of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the transaction 152j that the new transaction uses (or "allocates"), which will typically include at least checking that the cryptographic signature or other authentication in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may simply be fixed by the blockchain node protocol, or it may be a combination of both. In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0026] In the output-based model, the definition of whether a given allocated output (e.g., UTXO) is allocated (or spent) is whether it has already been validly redeemed by an input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated to change). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Again, because the order of transactions is defined, the account balance has a single defined state at a time.

[0027] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process called mining, which is underpinned by a "proof-of-work." At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. This typically involves looking for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle, and other types are not excluded. A property of a hash function is that it has an output that is unpredictable with respect to the input. Therefore, this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0028] The first blockchain node 104 that solves the puzzle notifies the network 106 and provides the solution as a proof. This solution can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the output of the hash satisfies the conditions). The first blockchain node 104 propagates the block to the consensus of a threshold of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. The new block 151n is also assigned a block pointer 155 to point to the previously created block 151n-1 in the chain. The significant amount of effort required to generate the proof-of-work solution, for example in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it uses or assigns the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0029] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be solving the puzzle based on different snapshots of the pool of transactions 154 that have not yet been published, depending on when they started looking for a solution or the order in which transactions were received. Whoever solves the puzzle first defines the transactions 152 that will be included in the next new block 151n, in the order in which the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to produce blocks from the newly defined ordered pool of unpublished transactions 154. There is also a protocol to resolve possible "forks", which are cases when two blockchain nodes 104 solve the puzzle within a very short time of each other and inconsistent views of the blockchain propagate between the nodes 104. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both branches.

[0030] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an additional approved amount of the digital asset in a new special type of transaction that distributes an additional defined amount of the digital asset (different from an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is usually called a "coinbase transaction", but may also be called an "initiation transaction" or "generation transaction". It typically forms the first transaction of a new block 151n. The proof-of-work signals that the node that constructed the new block intends to follow the protocol rules so that this special transaction can be redeemed later. Blockchain protocol rules may require this special transaction to mature, for example 100 blocks, before it can be redeemed. A normal (non-generating) transaction 152 often specifies an additional transaction fee in one of its outputs, further rewarding the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is described below.

[0031] Due to the resources involved in validating and publishing transactions, typically at least each of the blockchain nodes 104 takes the form of a server including one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0032] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform one or more of its roles and to process transactions 152 in accordance with the blockchain node protocol. It will be appreciated that any operation pertaining to a blockchain node 104 may be performed by software executing on the processing unit of each computing device. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0033] Also connected to the network 101 are computing devices 102 of each of a number of parties 103 that act as consumer users. These users may interact with the blockchain network but do not participate in validating transactions and building blocks. Some of these users or agents may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0034] Some or all of the parties 103 may be coupled as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called "clients") can be said to be part of the system including the blockchain network 106. However, these users are not blockchain nodes 104, as they do not perform the required role of a blockchain node. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby coupling (i.e., communicating) with the blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes, a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as the "first party" and the "second party," respectively.

[0035] The computing equipment 102 of each party 103 comprises a respective processing device comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium or media. This memory may include one or more memory units using one or more memory media, e.g., a magnetic medium such as a hard disk, an electronic medium such as a SSD, a flash memory or an EEPROM, and / or an optical medium such as an optical disk drive. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 arranged to operate on the processing device. It will be understood that any action attributed to a party 103 given herein may be performed using software executed on the processing device of each computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0036] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer readable storage media, for example downloaded from a server, or on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk, for example a CD or DVD ROM, or a removable optical drive.

[0037] The client application 105 has at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and send transactions 152 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling the amount defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0038] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may be implemented in two or more different suites of applications, interfacing, for example, via an API, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. The following is described in terms of a client application 105, but it will be understood that this is not limiting.

[0039] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust of transactions in part through its public visibility). The wallet function on each computing device 102 is configured to form and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate the transactions 152 according to the blockchain node protocol and to forward the transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol implements a given transaction model with a given node protocol. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used for all nodes 104 in the network 106.

[0040] When a given party 103, for example Alice, wants to send a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of script and node protocol.

[0041] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the blockchain ordered set 154 maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, it will soon be propagated throughout the network 106.

[0042] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, the blockchain nodes 104 begin a race to solve a proof-of-work puzzle for the latest version of their respective pools of transactions, including the new transaction 152 (note that other blockchain nodes 104 will try to solve the puzzle based on different pools 154 of transactions, but whoever is first will define the set of transactions included in the latest block 151). Eventually, the blockchain node 104 will solve the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j. Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 consists of a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0043] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore may have conflicting views of which instances are "valid" before one instance is published into a new block 151, at which point all blockchain nodes 104 agree that only the published instance is the valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one that has not yet been published in a block 151).

[0044] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol. In the account-based case, each transaction transfers by referencing an absolute account balance, rather than defining the amount to be transferred by referencing back to the UTXO of a previous transaction in the past sequence of transactions. The current state of every account is stored and constantly updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the successive transaction records (so-called "positions") of the accounts. This value is signed by the senders as part of their cryptographic signatures and hashed as part of the transaction reference calculation. In addition, an optional data field can also sign the transaction. This data field may point back to a previous transaction, for example if a previous transaction ID is included in the data field.

[0045] 2. UTXO-based model FIG. 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible implementations. It is noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0046] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes 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 that specifies the amount of the digital asset, which represents a set number of tokens on the distributed ledger. Among other information, the UTXO may also include a transaction ID for the transaction from which it originated. The transaction data structure may also include a header 201, which may include an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also include an ID for the transaction. In an 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 outstanding transaction 152 submitted to the node 104.

[0047] For example, Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice into the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0048] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least when she sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and sent to the network 106, or Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" used herein in the context of a sequence of transactions refer to the order of the transactions in a sequence defined by transaction pointers (such as which transaction points to which other transaction) specified in the transaction. They may be equally replaced by "preceding" and "inheriting" or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or node behavior.

[0049] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the following transaction for the following transaction to be validated, and thus for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction was locked.

[0050] A lock script (aka 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 "Script" (capital S) that is used by blockchain networks. A lock script specifies the information needed to use the transaction output 203, e.g., the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the lock script. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0051] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that Alice's signature SigP must be present in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A Input 202 of Tx1 includes a representation (i.e., a hash) of Tx0. Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Input 202 of Tx1 includes an index that identifies UTXO0 in Tx0, in order to identify it among any other possible outputs of Tx0. Input 202 of Tx1 further includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <SigP A The data (or "message") that Alice needs to sign in order to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0052] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenation of the two scripts.

number

[0053] The details of public-private cryptographic authentication will be well known to those skilled in the art. Essentially, if Alice signs a message with her private key, then another entity, such as node 104, can authenticate that the message must have been signed by Alice, given Alice's public key and the message in plaintext. Signatures typically allow the holder of the public key to authenticate the signature by hashing the message, signing the hash, and tagging this with the message as the signature. Thus, in embodiments, references to signing a particular piece of data or portion of a transaction, etc., may mean signing a hash of the piece of data or portion of the transaction.

[0054] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to the ordered pool of pending transactions 154. The blockchain node 104 forwards the transaction Tx1 to one or more other blockchain nodes 104 in the network 106, which will cause it to be propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines it as having spent UTXO0 from Tx0. Note that Tx1 is only valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, the blockchain node 104 must also check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO has been spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0055] If the total amount specified in all of the outputs 203 of a given transaction 152 is greater than the total amount pointed to by all of its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction is not propagated and is not included in block 151.

[0056] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" some of the amount defined in the UTXO while another amount is spent. However, an amount from a UTXO can be split into multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be split into multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0057] In particular, Alice should also typically include a fee for any Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 will likely be rejected by the blockchain nodes 104 and therefore, although technically valid, it will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transaction 152 if they do not want to). In some protocols, transaction fees do not require their own separate output 203 (i.e., they do not require a separate UTXO). Instead, the difference between the total amount indicated by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or used) by the node 104 that wins the proof-of-work competition that produces the block containing UTXO1. However, nothing in this specification necessarily precludes that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0058] Alice and Bob's digital assets consist of the UTXOs that were locked to them in any transaction 152 in the blockchain 150. Thus, typically, the assets of a given party 103 are distributed across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to compile the values ​​of all the various UTXOs that are locked to each party and that have not yet been used in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0059] Note that the scripting code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_...." represents a particular opcode in the scripting language. As an example, OP_RETURN, when preceded by OP_FALSE at the beginning of the locking script, is an opcode in the scripting language to generate an unspent output of the transaction that can store data within the transaction, thereby immutably recording the data to the blockchain 150. For example, the data can include a document that is desired to be stored in the blockchain.

[0060] Typically, the input to a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs, and all or some of the transaction outputs. The specific parts of the outputs to sign depend on the SIGHASH flag, which is a four-byte code typically included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0061] A lock script is sometimes referred to as a "scriptPubKey" to indicate that each transaction typically includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig" to indicate that it typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions under which a UTXO is redeemed include authenticating a signature. More generally, the scripting language may be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" are preferred.

[0062] 3. Node Software FIG. 3 illustrates an example of node software 450 that may be executed by each blockchain node 104 of the network 106 in the example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: an agreement module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152j (Tx j ) is received, and another preceding transaction 152i (Tx m-1 ), the protocol engine 451 executes Tx j The protocol engine 451 then identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and search for Tx i may be published on the blockchain 150. In this case, the protocol engine can obtain Txi from a copy of block 151 of the blockchain 150 stored in the node 104. i It is possible that Tx has not yet been published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 held by the node 154. iIn either case, the script engine 451 identifies the lock script in the referenced output of Txi and passes it to the script engine 452.

[0063] The script engine 452 therefore i Lock script and Tx j 2, but the same can be applied to any pair of transactions. The script engine 452 executes the two scripts together as described above, which includes placing data on the stack 453 and retrieving data according to the script language (e.g., Script) based on the stack being used.

[0064] By executing the scripts together, the script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether it "unlocks" the output in which the lock script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0065] In the output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, and Tx j the total amount of Digital Assets specified in the Outputs of does not exceed the total amount pointed to by its Inputs; iThe output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j 455C and / or the propagation module 455P to perform their respective blockchain-related functions as Tx j , which is to control the execution of Tx j and a consensus module 455C that adds Tx j Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only conditional on both that the transaction has been declared invalid and that sufficient transaction fees remain.

[0066] It is noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can represent any state that indicates a successful or positive outcome, and "false" can represent any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (where the overall outcome is considered to convey true if both individual outcomes are true).

[0067] 4. Isolated Pool FIG. 4 illustrates a schematic of components of a blockchain node 104 configured to implement embodiments of the present disclosure. The blockchain node 104 includes an orphan pool 401, a transaction pool 402, and a validation pipeline 403. It will be appreciated that the blockchain node 104 may include other components, such as a protocol engine 451, a script engine 452, as described with reference to FIG. 3, for example. The blockchain node 104 is configured to receive and validate transactions, for example, for the purpose of building blocks of transactions and propagating valid transactions to other nodes 104 of the blockchain network 106. The blockchain node 104 may use the transaction pool 402 to store transactions that have been validated, either by itself or by another node 104. The transaction pool may take the form of an ordered pool 154 (or mempool) as described above with reference to FIG. 1.

[0068] As mentioned above, transactions form a chain, and each transaction in the chain, other than the first transaction (the “coinbase transaction” or “generation transaction”), references the previous transaction in the chain. The referenced transaction is called the parent transaction, and the transaction that references the parent is called the child transaction. A child transaction can have multiple parent transactions. To validate a child transaction, the validation pipeline 403 needs each of the parent transactions referenced by the child transaction. Without the parent transactions, the validation pipeline may repeatedly attempt to validate the child transaction and fail, resulting in a deadlock problem. A parent transaction may not be available to the validation pipeline 403 because it has not yet arrived at the blockchain node 104 (i.e., is undetected by the blockchain node 104), or at least has not arrived at the validation pipeline 403. An undetected transaction is referred to herein as an unavailable transaction or an unseen transaction. Both terms can be used interchangeably.

[0069] An orphan transaction is defined herein as a child transaction that references at least one unavailable transaction and / or at least one other orphan transaction. In other words, an orphan transaction is a child transaction that belongs to a chain of transactions where at least one transaction in the chain is an unavailable transaction.

[0070] Blockchain nodes 104 are configured to store orphaned transactions in an orphan pool 401. An embodiment of the present disclosure provides a data structure that represents the orphan pool 401. The data structure can be efficiently updated to reflect and allow for changes in the orphan pool 401, including the addition of orphaned transactions to the orphan pool and the release of orphaned transactions from the orphan pool 401.

[0071] The data structure includes a number of nodes and edges in the form of a directed acyclic graph. The nodes are connected by edges. Each node is connected to at least one other node by each edge. A node may be connected to multiple other nodes by each node. Each node is a parent node, a child node, or both. Each node represents an unavailable transaction or an orphaned transaction. An edge connecting nodes represents a reference of one transaction by another transaction. That is, an edge between a child node and a parent node is formed by and represents an input of a child transaction represented by the child node that references (i.e., uses) an output of a parent transaction represented by the parent node.

[0072] The graph is used to represent the relationship between orphaned transactions and unavailable transactions known to the blockchain node 104, e.g., orphaned transactions sent to the blockchain node 104 and unavailable transactions referenced by these orphaned transactions.

[0073] Each node in the graph is associated with a transaction identifier for the transaction represented by that node. For example, the node may include the transaction identifier. In other examples, the node may include a node identifier that is based on the transaction identifier, for example, the node identifier may be a hash of the transaction identifier.

[0074] Each node of the graph includes an indegree value. As known in the art, the indegree value represents the number of edges directed to the node (i.e., toward the node). In an embodiment, the indegree value can be set as one of three types of values. The indegree value can be set as a first value (e.g., “undefined”) representing that the number of edges directed to the node is undefined, indicating that the transaction represented by the node is an unavailable transaction. Because the transaction is unavailable, the number of orphaned or unavailable parent transactions (indeed, the total number of parent transactions) is unknown. Alternatively, the indegree value can be set as a zero value (e.g., “0”) indicating that the transaction represented by the node has no parent transactions that are unavailable or orphaned. In other words, the zero value indicates that the transaction is no longer an orphaned transaction and can be released to the validation pipeline 103. Note that the zero value does not necessarily have to be the numeric value 0, but can take another form. Alternatively, the indegree value may be set as a value (eg, a positive integer) that indicates the number of parent transactions of the transaction represented by the node that are either unavailable or orphaned.

[0075] Each parent node of the graph also contains a list of references to child nodes that are connected to the parent node by edges. For example, if a parent node is connected to two child nodes, the list contains a reference to each of these two child nodes. The reference identifies the child node. In other words, the reference is a node identifier. The node identifier may be based on a transaction identifier of the transaction represented by the child node, e.g., a hash of the transaction identifier. In another example, the reference may be a memory address of the child node.

[0076] Figure 5 shows an example graph representing an example orphan pool. The graph includes two nodes 501a, 501b (shown as ovals) each representing an unavailable transaction, and four nodes 503a-d each representing an orphan transaction. The arrows are edges connecting the nodes and represent the usage of transaction outputs. In this example, each node is responsible for the usage of the transaction Tx represented by that node. i Transaction identifier TxID i In these examples, each node includes a node identifier N that can be used to reference the node. TxIDi is associated with.

[0077] As shown in Figure 5, each node has an in-degree value. The in-degree values ​​of nodes 501a and 501b, which represent unavailable transactions, are set to a first value, which in this example is "undefined." The in-degree values ​​of nodes 503a-d, which represent isolated transactions, are based on the number of parent nodes. For example, node 503a has an in-degree value of 1 because it has a single parent node, as do node 503b (which has a different parent node than node 503a) and node 503c (which has the same parent node as node 503a). Node 503d has an in-degree value of 2 because it has two parent nodes.

[0078] Figure 5 also lists the references to each parent node's children. Node 501a references node 503a, indicating that the inputs of the child transaction represented by node 503a use the outputs of the parent transaction represented by node 501a. In this example, nodes 503c and 503d do not reference any children.

[0079] As mentioned above, the orphaned pool 401 contains orphaned transactions. The orphaned transactions are temporarily held in the orphaned pool until they can be released to the validation pipeline 403. As shown in Figure 5, the orphaned transactions can be stored in the graph as part of each node. For example, node N TxID2includes Tx2. In other examples, orphaned transactions can be stored separately from the graph.

[0080] An orphaned transaction may be removed from the orphaned pool 403 for one or more other reasons, for example, because the orphaned transaction has been on the orphaned pool longer than the maximum allowed time limit. This helps to keep the orphaned pool from taking up too much memory on the blockchain node.

[0081] The blockchain node 104 is configured to update the graph as more orphaned transactions are obtained, for example from users such as Alice 103a and Bob 103b, or from other nodes 104. When an orphaned transaction (referred to as a "target orphaned transaction") is received, the blockchain node 104 determines which parent transactions are missing or are orphaned itself. The blockchain node 104 runs an algorithm (referred to herein as the "add_transaction" algorithm) with the target orphaned transaction as input to update the graph. The add_transaction algorithm determines whether the target orphaned transaction is represented by an existing node in the graph, for example, node 501a or 501b representing an unavailable transaction. For example, the algorithm can look up the transaction identifier of the target orphaned transaction. In an example where each node includes a node identifier based on the transaction identifier, for example a hash of the transaction identifier, the algorithm can look up the node identifier.

[0082] If a node exists for the target orphaned transaction, the node is updated as described below. If a node does not exist for the target orphaned transaction, the node is created and, if necessary, one or more edges are formed between the node and other nodes.

[0083] The created or updated node is called the target node. The target node is created with the necessary information, such as its in-degree value and a list of references to its child nodes, if any. The in-degree value is based on the number of parent transactions of the target orphan transaction that are missing or are themselves orphaned. Orphan transactions can be included as part of the created target node. Updating a target node may include updating one or more edges of the graph and / or updating the in-degree value of the node.

[0084] For each parent transaction of a target node that is an unavailable or orphaned transaction, the algorithm determines whether the parent transaction is represented by the respective node. If the node of the parent transaction is not found, the parent node is created. For nodes that represent unavailable transactions, the indegree value is set to the first value. A reference to the target node is added to the created parent node. If the node of the parent transaction already exists, a reference to the target node is added to the existing parent node.

[0085] FIG. 6 shows an example of the process of adding and updating a node representing a newly acquired orphaned transaction. In FIG. 6(i), an orphaned transaction Tx child For new node N TxIDchild is created and a new parent node N TxIDi In this example, the parent node represents the unavailable transaction. In Figure 6(ii), the orphan transaction Tx child For new node N TxIDchild is created, and this time the node N already exists. TxID2 is updated, Tx child The relationship between Tx1 and Tx2 is reflected.

[0086] We now move on to the process of releasing an orphaned transaction to the validation pipeline 403 for validation. The blockchain node 104 obtains a transaction (referred to as a "first transaction") that is either an unavailable transaction (i.e., a transaction that was previously unavailable) or an orphaned transaction. The blockchain node 104 is configured to run an algorithm (referred to herein as a "release_transaction" algorithm) with the first transaction as input. The release_transaction algorithm identifies a node in the graph that represents the first transaction. The node can be identified in a similar manner as described above when describing the add_transaction algorithm that determines whether a target node exists for a target node, for example, based on the transaction identifier of the first transaction. The node that represents the first transaction is referred to as the first node. If the in-degree value of the first node is set as either a first value (e.g., undefined) or a zero value (e.g., 0), the first transaction is sent to the validation pipeline 403. The first node is removed from the graph.

[0087] The release_transaction algorithm may also be configured to update each child node of the first node in response to being executed. That is, if there are nodes in the graph that represent child transactions of the first transaction, they are updated. For each child node, the release_transaction algorithm reduces an in-degree value that indicates the number of parent transactions of the child transaction that are either unavailable or orphaned. In some examples, the updated in-degree value may still indicate that the child transaction has one or more such parent transactions. In other examples, the updated in-degree value may be a zero value, which is the case when the first transaction was the only parent transaction of the child transaction. Next, the release_transaction is executed for each child node of the first node individually. This removes the child node with the updated in-degree value set as a zero value from the graph and releases the orphaned transaction represented by the child node to the validation pipeline 403. The release_transaction algorithm is thus a recursive algorithm that attempts to remove all child transactions that are not orphaned.

[0088] 7 illustrates an example of a node (shown shaded) being removed from the graph and the corresponding transaction being released to the validation pipeline 403 in response to an unavailable transaction arriving at the blockchain node 104. In this example, node N TxID1 and N TxID5 represents an unavailable transaction. Node N TxID2 , N TxID3 , N TxID4 , and N TxID6 represents an orphaned transaction. In this example, release_transaction is called with Tx1 as input. release_transaction is a collection of N TxID1 Identify the child nodes of and the corresponding transactions released into the pipeline. In this example,TxID1 has one child node N TxID2 release_transaction has N TxID2 can be released to the pipeline 403, and a node N TxID2 Then release_transaction will delete N TxID2 Identify the child nodes of and the corresponding transactions released into the pipeline. In this example, TxID2 has two child nodes N TxID3 and N TxID4 release_transaction has N TxID3 can be released to the pipeline 403, and a node N TxID3 Delete node N TxID4 The transaction corresponding to TxID5 403. Since the queue manager 404 has another parent Tx5 represented by

[0089] The release_transaction algorithm is similar to a topology reordering algorithm. The nodes in a graph can be reordered by level based on their in-degree values. For example, grandparent (level 0), parent (level 1), child (level 2), etc. The release_transaction algorithm starts with the lowest level 0 and tries to remove nodes at that level. The in-degree values ​​of the child nodes are updated. One or more nodes that belonged to level 1 may now belong to level 0. Again, the level 0 nodes are removed. The in-degree values ​​of the child nodes are updated. This process is repeated until no more child nodes can be removed.

[0090] The release_transaction algorithm does not go through the entire pool to unorphan transactions. It only identifies nodes with an associated indegree value (a zero value) and iteratively attempts to unorphan their descendant transactions. Also, the release_algorithm starts with only one detected (i.e., newly available) transaction that was undetected (i.e., previously unavailable). The iterative (and recursive) nature is inherent to the release algorithm, centralizing orphan pool management in one entity (the pool itself). The release_transaction algorithm only needs to process each orphaned transaction once.

[0091] When the release_transaction algorithm is executed, it can send multiple released transactions to the validation pipeline simultaneously, i.e. as a batch of transactions, instead of one at a time.

[0092] In some embodiments, a blockchain node 104 has multiple validation pipelines 403, each configured to perform the same operation of validating transactions. That is, a node 104 can have multiple instances of a validation pipeline. As another example, the validation pipeline 403 itself can include multiple sub-pipelines and / or multiple processors configured to perform the same operation. In other words, the validation pipeline 403 can be multi-threaded. The release_transaction algorithm can send one or more of the released transactions to the same pipeline 403, the same sub-pipeline, or the same processor. Alternatively, the released transactions can be distributed to different pipelines 403, sub-pipelines, or processors.

[0093] A particularly advantageous option is to send the chain of transactions released by the release_transaction algorithm to the same pipeline 403, sub-pipeline, or processor, which increases validation speed and reduces communication overhead, since each parent transaction in the chain is used as part of the validation of the next child transaction in the chain.

[0094] As mentioned above, release_transaction is executed to release an orphaned transaction from the orphan pool 401 and remove the corresponding node from the graph. The release_transaction algorithm may be triggered by a listener. In these examples, each unavailable transaction is associated with a listener, such as when a node representing the orphaned transaction is added to the graph. When an unavailable transaction enters the validation pipeline 403, the associated listener is triggered, which triggers the release_transaction algorithm with the unavailable transaction as input. In practice, each listener has visibility of the transactions entering the pipeline and is a piece of code that is configured to call other code, i.e., the release_transaction algorithm.

[0095] As another example, the blockchain node 104 may be configured to search the graph, e.g., at periodic intervals, for nodes that represent unavailable transactions confirmed by the validation pipeline 403. If such a node exists in the graph, a release_transaction is triggered and executed with the corresponding unavailable transaction as input.

[0096] As another example, the release_transaction algorithm may be triggered whenever a transaction successfully enters (and, optionally, passes) the validation pipeline 403. Once a transaction passes through the pipeline 403, it becomes available to the pipeline 403 for validating its child transactions. The validation pipeline 403 communicates to the orphaned pool 401 that it has seen the transaction, and asks if the orphaned pool 401 is waiting for the transaction. If the orphaned pool is waiting for the transaction, the release_transaction algorithm is triggered.

[0097] 5. Example of implementation of isolated pool This section provides specific implementation details of the described embodiments and provides examples of how to populate the pool of orphaned transactions in a blockchain node 104. An undetected transaction is defined as a transaction that has not yet been detected by the validation pipeline 403 and contains an output that is used by a transaction in the orphaned pool 401. A transaction becomes orphaned when one of its inputs unlocks an output of the undetected transaction. Furthermore, a transaction that unlocks an output of an orphaned transaction is referred to as orphaned.

[0098] The orphan pool is constructed by storing a usage graph of all unseen or orphaned transactions. A usage graph is a directed acyclic graph (DAG) whose nodes are unseen or orphaned transactions. A directed edge from node N1 to N2 represents a transaction associated with node N2 that uses an output of a transaction associated with node N1.

[0099] Each node associated with a transaction ID TxID has N TxID and contains the following information (for example, as seen in the node in Figure 5): Transaction Tx, if available The in-degree number is defined as: -undefined: the transaction itself is an undiscovered transaction; -0: The transaction is not orphaned and can be released into the pipeline; Any positive integer value: the number of undetected or orphaned parent transactions. A list of references to (e.g., the memory addresses of) the child nodes associated with the orphaned child transactions that unlock one of the current transaction's outputs.

[0100] The usage graph of an orphan pool is represented by the set of all nodes defined above. An exemplary overview of an orphan pool is given in Figure 5. In Figure 5, transaction ID TxID2 has two child nodes N TxID3 and N TxID4 Node N with a reference to TxID2 It uses some output of undiscovered transaction id TxID1 and contains transaction Tx2, so it has one parent (in=1).

[0101] In what follows, we assume that double-use attempts are handled at the pipeline level, so there is no need to perform a check on the orphan pool 401 to signal a double-use attempt.

[0102] The add_transaction procedure adds a transaction Tx child and a list of undetected or orphaned parent transactions. The list of parent transactions is taken from transaction Tx child The steps are collected by the pipeline when it tries to validate a transaction Tx childto the usage graph. When one of the transaction inputs unlocks an output that is associated with an unseen transaction that is not included in the orphan pool's usage graph, the function listens for the unseen transaction on the pipeline. Input: transaction Tx child , a list of k missing parent transactions TxID i , i=1,…,k Steps to follow: 1. Transaction Tx child From transaction ID TxID child Calculate. 2. TxID child If exists in the usage graph data structure, the corresponding node N Txchild Get transaction Tx child To optimize the retrieval, we can use a hash map data structure H that associates transaction IDs TxID with their corresponding nodes. For example, for node N TxID If created, H(TxID)=N TxID Set it as follows. 3. Otherwise, create a new node with its indegree value set to k (e.g., transaction TxID4 in Figure 5 has two parents). 4. Missing Transaction TxID i For each: a. Transaction ID is TxID i If the node does not exist in the graph, set the indegree to undefined and TxIDi and add the node to the usage graph (e.g., Fig. 6(i)). Otherwise, TxIDi Get the. bN TxIDchild If it has not been added yet, N TxIDi N in the list of children TxIDchild Add.

[0103] The release_transactions procedure takes as input the transactions seen by the pipeline. It determines which child transactions in the orphan pool can be released and sent to the pipeline. If so, these child transactions are removed from the orphan pool and sent to the handler associated with the transaction ID for validation. In other examples, the TxID may determine which handler processes the transaction. Input: Transaction Tx Steps to follow: 1. Calculate the transaction ID TxID from the transaction Tx. 2. Node N associated with transaction ID TxID TxID Determine. 3. Node N TxID If the indegree value of is 0, then send transaction Tx for validation. 4.N TxID child node N in the list of children of TxIDchild For each, run the following command: aN TxIDchild Decrease the input degree of by 1. b. Input Tx child Attempts to delete the child transactions by calling release_transactions on the 5.N TxID If the in-degree value of is undefined or 0, then the node N TxID Delete.

[0104] The release_transaction function can use the topology reordering algorithm described in Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L.; Stein, Clifford (2001), Introduction to Algorithms (2nd ed.), MIT Press and McGraw-Hill, pp.549-552, ISBN 0-262-03293-7 [Section 22.4].

[0105] The example in Figure 7 is for node N TxID1 The procedure release_transactions indicates the nodes to which undiscovered transactions associated with node N are sent for validation when they enter the pipeline. TxID1 , N TxID2 , and N TxID3 Delete.

[0106] Instead of sending each transaction Tx to the handler for validation (step 4b), the step release_transactions can collect transactions and send them to the handler in one or more batches. When batching transactions for release, an additional option is to send a chain of transactions (e.g., Tx2, Tx3) to the same StepProcessor that is validating Tx1. Since each parent transaction in the chain is validated by the same StepProcessor, the validation speed of transactions Tx2 and Tx3 can be improved by reducing the communication overhead with other StepProcessors. Here, a StepProcessor is an entity in the pipeline 403 tasked with performing a specific function.

[0107] Below, three methods that can be used to integrate an orphan pool with a blockchain node 104 are described in relation to how the procedure release_transactions is called.

[0108] The first option is to add a listener for each unseen transaction: whenever a transaction is added to the orphan pool using the procedure add_transaction, all unseen parent transactions are associated with a listener. When an unseen parent transaction enters the pipeline, the listener is triggered to call the procedure release_transactions with the unseen transaction as input.

[0109] The following method adds a listener: Input: Transaction ID TxID Steps to follow: 1. Determine the handler based on the transaction ID TxID. 2. Add a listener to the StepProcessor associated with the handler.

[0110] An implementation of this strategy must take race conditions into account, for example the parent transaction may be processed in the pipeline before step 4b.

[0111] Instead of overloading the pipeline with a listener, another option is to check the orphan pool at regular intervals (say every second) and if the pipeline detects any transactions that appear to be undetected in the orphan pool, it calls release_transactions.

[0112] The following steps are performed for each time interval: 1. For every undetected transaction Tx in the orphan pool, a. Send a request to the pipeline to see if transaction Tx has been seen. b. If a transaction Tx is seen, call release_transactions with Tx as input.

[0113] To optimize the reclaiming, the heuristic "most objects die young" used in generational garbage collection techniques can be applied. In the context of the present invention, this means that recently added orphaned transactions are more likely to be removed from the orphan pool. Then, to improve the responsiveness of the above steps, the undetected transactions can be sorted in descending order of the time they were added to the orphan pool.

[0114] Finally, a priority queue can be implemented to quickly add and remove undetected transactions from the usage graph while maintaining descending order.

[0115] Another option is to release orphaned children (if any) of transaction Tx after passing through a concrete StepProcessor S in the pipeline.

[0116] The following steps are performed: 1.For every transaction Tx that successfully passes through StepProcessor S, Call release_transactions with a.Tx as input.

[0117] Each node has its own version of the orphan pool 401, as well as the memory pool 402. Orphan transactions are not propagated to other nodes in the network 106, since their validity cannot be determined. If a denial of service attack is attempted by overloading a node 104 with orphan transactions, only the orphan pool 401 of that node 104 increases in size. To prevent the size from exceeding a certain threshold, a time limit can be imposed on each orphan transaction, after which the orphan transaction is removed from the pool.

[0118] 6.Other precautions Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon review of this specification, and the scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0119] For example, some embodiments described above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it is understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain in any way. More generally, references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 above may be replaced with the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104.

[0120] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the above-mentioned functions of generating, publishing, propagating and storing blocks 151 in the blockchain 150. It is not excluded that there are other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks, but may not generate and publish blocks (recall that these entities are not considered as preferred Bitcoin network 106 nodes).

[0121] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, a "node" may be used to represent a network entity that is configured to generate and publish blocks 151 but does not store and / or propagate the blocks 151 to other nodes.

[0122] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such an entity / element may be configured to perform some or all of the roles of generating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0123] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided according to any one or more of the following: (Statement 1) 1. A computer-implemented method executed by a blockchain node, comprising: maintaining a data structure representing orphaned transactions, where an orphaned transaction is a blockchain transaction that has at least one parent transaction that is an unavailable transaction and / or at least one parent transaction that is a different orphaned transaction, where an unavailable transaction is a transaction that is not available to a validation pipeline of a blockchain node; Including, the data structure includes a directed graph of nodes and edges, each node of the graph representing either a respective orphaned transaction or a respective unavailable transaction, and each edge connecting a respective parent node to a respective child node representing a usage of an output of the respective transaction represented by the respective parent node by an input of the respective transaction represented by the respective child node; Each node of the graph is associated with a respective transaction identifier for each of the transactions represented by the node, such as: a) each of the in-degree values, each of the in-degree values ​​being as follows: i) a first value indicating that each of the transactions has an unknown number of parent transactions that are either unavailable transactions or orphaned transactions; or ii) a value of 0, indicating that each of the transactions has no parent transactions that are either unavailable or orphaned; or iii) a value indicating the number of each of said transactions' respective parent transactions that are either unavailable transactions or orphaned transactions; , and b) a list of each reference of each child node, if any, connected to the node by each edge; A method comprising: (Statement 2) The method described in statement 1, wherein the data structure includes some or all of the orphan transaction. (Statement 3) The method according to statement 2, wherein one, a portion or each node of the graph representing each orphan transaction includes the respective orphan transaction. (Statement 4) removing each orphaned transaction from said data structure in response to each orphaned transaction having resided in said data structure for a predetermined time limit; The method according to claim 2 or 3, comprising: (Statement 5) Each node of the graph is c) A method according to any one of statements 1 to 4, including the respective transaction identifiers of the respective transactions represented by the node. (Statement 6) obtaining a list of target orphan transactions and target parent transactions of each of said target transactions that are either unavailable or orphan transactions; invoking an add transaction algorithm using the target orphan transaction as input; Including, The step of invoking the add transaction algorithm comprises: determining whether the graph includes a target child node that represents the target orphaned transaction; updating the graph by creating or updating the target child node based on the determining step; The method according to claim 1, (Statement 7) 7. The method of claim 6, wherein the determining step includes determining whether each node of the graph is associated with a target transaction identifier of the target orphan transaction. (Statement 8) 8. The method of claim 7, wherein the determining step includes a step of generating the target transaction identifier. (Statement 9) The step of invoking the add transaction algorithm comprises: for each target parent transaction in the list of target parent transactions of each of the target isolated nodes, determining whether the graph includes a respective target parent node representing the respective target parent transaction of the target orphan transaction; updating the graph by creating or updating each of the target parent nodes based on the determining step, each of the nodes including a respective reference to the target child node; A method according to statement 6 or any one of the methods dependent on statement 6, comprising: (Statement 10) 10. The method of claim 9, wherein creating each target parent node includes setting the respective indegree value of each target parent node as the first value if the respective parent transaction is an unavailable transaction. (Statement 11) obtaining the first transaction and invoking a release transaction algorithm with the first transaction as input; The step of invoking the release transaction algorithm comprises: identifying a first node in the graph that represents the first transaction; if the pre-degree value of the first node is set to the zero value, sending the first transaction to the validation pipeline and removing the first node from the graph; The method according to any one of statements 1 to 11, comprising: (Statement 12) The step of invoking the release transaction algorithm includes: For each child node referenced by the first node: if the in-degree is a positive number, updating each in-degree value by decreasing the number of each parent transaction that is either unavailable or orphaned; invoking the release transaction algorithm with each of the child nodes as input; 12. The method according to claim 11, further comprising updating the graph according to (Statement 13) 13. The method of claim 12, wherein invoking the release transaction algorithm with each of the child nodes as input results in one or more child transactions being sent to the validation pipeline, the method including sending the first transaction and the one or more child transactions to the validation pipeline as a batch of transactions. (Statement 14) 14. The method of claim 13, further comprising sending the first transaction and the one or more child transactions to the same processor of the validation pipeline. (Statement 15) The first transaction is a respective unavailable transaction, and the method further comprises: associating each listener with one, some, or each unavailable transaction; in response to obtaining each of the unavailable transactions, each of the listeners invoking the release transaction algorithm; A method according to any one of statement 11 or statement dependent thereon, comprising: (Statement 16) searching said data structure at periodic intervals for one or more respective unavailable transactions that become available in said validation pipeline; identifying at least one respective unavailable transaction that has become available in the validation pipeline, the first transaction being each of the identified unavailable transactions, and the step of invoking the release transaction algorithm being responsive to the identifying step; A method according to any one of statement 11 or statement dependent thereon, comprising: (Statement 17) The release transaction algorithm is as follows: the validation pipeline notifying the data structure that the first transaction has entered or exited the validation pipeline; determining that the first transaction is represented in the data structure as an unavailable transaction; 14. A method as claimed in claim 11 or any one of the claims subordinate to statement 11, which is invoked in response to (Statement 18) 1. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to execute on the processing device, the code configured to execute the method described in any of statements 1 to 17 when executed on the processing device. (Statement 19) A computer program embodied on a computer readable storage device and configured to perform the method according to any of statements 1 to 17 when executed on one or more processors. (Statement 20) a data structure representing an orphaned transaction, an orphaned transaction being a blockchain transaction that has at least one parent transaction that is an unavailable transaction and / or at least one parent transaction that is a different orphaned transaction, an unavailable transaction being a transaction that is not available to a validation pipeline of a blockchain node; the data structure includes a directed graph of nodes and edges, each node of the graph representing either a respective orphaned transaction or a respective unavailable transaction, and each edge connecting a respective parent node to a respective child node representing a usage of an output of the respective transaction represented by the respective parent node by an input of the respective transaction represented by the respective child node; Each node of the graph is associated with a respective transaction identifier for each of the transactions represented by the node, such as: a) each of the in-degree values, each of the in-degree values ​​being as follows: i) a first value indicating that each of the transactions has an unknown number of parent transactions that are either unavailable transactions or orphaned transactions; or ii) a value of 0, indicating that each of the transactions has no parent transactions that are either unavailable or orphaned; or iii) a value indicating the number of each of said transactions' respective parent transactions that are either unavailable transactions or orphaned transactions; , and b) a list of each reference of each child node, if any, connected to the node by each edge; A data structure including:

Claims

1. 1. A computer-implemented method executed by a blockchain node, comprising: maintaining a data structure representing orphaned transactions, where an orphaned transaction is a blockchain transaction that has at least one parent transaction that is an unavailable transaction and / or at least one parent transaction that is a different orphaned transaction, where an unavailable transaction is a transaction that is not available to a validation pipeline of the blockchain node; Including, the data structure includes a directed graph of nodes and edges, each node of the graph representing either a respective orphaned transaction or a respective unavailable transaction, and each edge connecting a respective parent node to a respective child node representing a usage of an output of the respective transaction represented by the respective parent node by an input of the respective transaction represented by the respective child node; Each node of the graph is associated with a respective transaction identifier for each of the transactions represented by the node, such as: a) each of the in-degree values, each of which is one of the following: i) a first value indicating that each of the transactions has an unknown number of parent transactions that are either unavailable transactions or orphaned transactions; or ii) a value of 0, indicating that each of the transactions has no parent transactions that are either unavailable or orphaned transactions; or iii) a value indicating the number of each of said transactions' respective parent transactions that are either unavailable transactions or orphaned transactions; , and b) a list of each reference of each child node, if any, connected to the node by each edge; A method comprising:

2. The method of claim 1 , wherein the data structure includes some or all of the orphaned transactions.

3. The method of claim 2 , wherein one, a portion, or each node of the graph representing each orphaned transaction includes the each orphaned transaction.

4. removing each orphaned transaction from said data structure in response to each orphaned transaction having resided in said data structure for a predetermined time limit; 3. The method of claim 2 comprising:

5. Each node of the graph is and c) the respective transaction identifiers for the respective transactions represented by the node.

6. obtaining a list of target orphaned transactions and target parent transactions for each of the target transactions that are either unavailable or orphaned transactions; invoking an add transaction algorithm using the target orphan transaction as input; Including, The step of invoking the add transaction algorithm comprises: determining whether the graph includes a target child node that represents the target orphaned transaction; updating the graph by creating or updating the target child node based on the determining step; The method of claim 1 , comprising:

7. The method of claim 6 , wherein the determining step comprises determining whether each node of the graph is associated with a target transaction identifier of the target orphan transaction.

8. The method of claim 7 , wherein the determining step includes the step of generating the target transaction identifier.

9. The step of invoking the add transaction algorithm comprises: For each target parent transaction in said list of target parent transactions of each target isolated node, determining whether the graph includes a respective target parent node representing the respective target parent transaction of the target orphan transaction; updating the graph by creating or updating each of the target parent nodes based on the determining step, each of the nodes including a respective reference to the target child node; The method of claim 6, comprising:

10. 10. The method of claim 9, wherein creating the each target parent node comprises setting the each in-degree value of the each target parent node as the first value if the each parent transaction is an unavailable transaction.

11. obtaining a first transaction and invoking a release transaction algorithm with the first transaction as input; The step of invoking the release transaction algorithm comprises: identifying a first node in the graph that represents the first transaction; if the pre-degree value of the first node is set to the value of zero, sending the first transaction to the validation pipeline and removing the first node from the graph; The method of claim 1 , comprising:

12. The step of invoking the release transaction algorithm includes: For each child node referenced by the first node: updating each of the in-degree values ​​by decreasing the number of each of the parent transactions that are either unavailable or orphaned, if the in-degree value is a positive number; invoking the release transaction algorithm with each of the child nodes as input; The method of claim 11 , further comprising updating the graph according to:

13. 13. The method of claim 12, wherein invoking the release transaction algorithm with each of the child nodes as input results in one or more child transactions being sent to the validation pipeline, the method including sending the first transaction and the one or more child transactions to the validation pipeline as a batch of transactions.

14. 14. The method of claim 13, comprising sending the first transaction and the one or more child transactions to a same processor of the validation pipeline.

15. The first transaction is a respective unavailable transaction, and the method further comprises: associating each listener with one, some, or each unavailable transaction; in response to obtaining each of the unavailable transactions, each of the listeners invoking the release transaction algorithm; 12. The method of claim 11, comprising:

16. searching said data structure at periodic intervals for one or more respective unavailable transactions that become available in said validation pipeline; identifying at least one respective unavailable transaction that has become available in the validation pipeline, the first transaction being each of the identified unavailable transactions, and the step of invoking the release transaction algorithm being responsive to the identifying step; 12. The method of claim 11, comprising:

17. The release transaction algorithm is as follows: the validation pipeline notifying the data structure that the first transaction has entered or exited the validation pipeline; determining that the first transaction is represented in the data structure as an unavailable transaction; The method of claim 11 , wherein the method is invoked in response to

18. 1. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to execute on the processing device, the code configured to execute the method of claim 1 when executed on the processing device.

19. A computer program embodied on a computer readable storage device and configured to perform the method of claim 1 when executed on one or more processors.

20. a data structure representing an orphaned transaction, an orphaned transaction being a blockchain transaction that has at least one parent transaction that is an unavailable transaction and / or at least one parent transaction that is a different orphaned transaction, an unavailable transaction being a transaction that is not available to a validation pipeline of a blockchain node; the data structure includes a directed graph of nodes and edges, each node of the graph representing either a respective orphaned transaction or a respective unavailable transaction, and each edge connecting a respective parent node to a respective child node representing a usage of an output of the respective transaction represented by the respective parent node by an input of the respective transaction represented by the respective child node; Each node of the graph is associated with a respective transaction identifier for each of the transactions represented by the node, such as: a) each of the in-degree values, each of which is one of the following: i) a first value indicating that each of the transactions has an unknown number of parent transactions that are either unavailable transactions or orphaned transactions; or ii) a value of 0, indicating that each of the transactions has no parent transactions that are either unavailable or orphaned transactions; or iii) a value indicating the number of each of said transactions' respective parent transactions that are either unavailable transactions or orphaned transactions; , and b) a list of each reference of each child node, if any, connected to the node by each edge; A data structure including:

Images