Blockchain Transaction Cleanup Service

Abstract

Methods, devices, and data structures for processing a large volume of transactions on blockchain nodes are provided. Solutions for transaction clean-up following the reception of block announcements from other nodes are provided. In one example, transaction identifiers in a list matching a local candidate block are marked if they match transaction identifiers in the announced block, and when the block is authenticated, the block assembly service uses the unmarked transaction identifiers to construct a new candidate block. In other examples, a candidate database of transaction identifiers is built during the mining phase, and TxIDs are marked as array identifiers or node identifiers as arrays are announced by other nodes on the network. This can accelerate clean-up when a block is announced and reduces the memory footprint required to mark post-solution TxIDs as included in the resolved block.

Description

Technology Field

[0001] The present disclosure relates to blockchain networks, and in particular to methods and devices for validating blocks involving large transaction flows. Background Technology

[0002] A blockchain refers to a form of distributed data structure, where replicas of the blockchain are maintained and widely made public by each of multiple nodes within a distributed peer-to-peer (P2P) network (referred to as the "blockchain network" below). A blockchain is formed by a chain of data blocks, each containing one or more transactions. Each transaction, excluding so-called "coinbase transactions," refers inversely to a preceding transaction within a sequence that may span one or more blocks leading up to one or more coinbase transactions. Coinbase transactions are discussed below. Transactions submitted to the blockchain network are included in new blocks. New blocks are often generated by a process referred to as "mining," which involves each of multiple nodes competing to perform a "proof of work"—that is, solving a cryptographic puzzle based on a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that a blockchain can be pruned at nodes, and the publication of blocks can be achieved simply by publishing block headers.

[0003] Transactions within a blockchain are used to perform one or more of the following: transferring digital assets (i.e., multiple digital tokens), ordering sets of journal entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or arranging index pointers in chronological order. Blockchains can also be utilized to layer additional functions on top of the blockchain. Blockchain protocols may allow the storage of additional user data or indexes to data within a transaction. There is no predefined limit on the maximum data capacity that can be stored within a single transaction, and thus increasingly complex data can be integrated. For example, this can be used to store electronic documents, or audio or video data, within the blockchain.

[0004] Nodes in a blockchain network (often referred to as "miners") perform the distributed transaction registration and verification process, which will be described in detail below. In summary, during this process, nodes authenticate transactions, insert them into block templates, and attempt to identify valid proof-of-work solutions for those block templates. If a valid solution is found, the new block is propagated to other nodes in the network, thereby enabling each node to record the new block on the blockchain. To have a transaction recorded on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to be propagated. Nodes receiving the transaction may enter into a competition to find a proof-of-work solution that incorporates the authenticated transaction into a new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions will not be propagated or incorporated into blocks. Assuming that a transaction is authenticated and accepted on the blockchain, the transaction (including arbitrary user data) will therefore be maintained as an immutable public record registered and indexed on each of the nodes within the blockchain network.

[0005] Nodes that successfully solve the proof-of-work puzzle to generate the latest block are rewarded with a new transaction, typically called a "coinbase transaction," which distributes an amount of digital assets—that is, the number of tokens. The detection and rejection of invalid transactions are enforced by the actions of competing nodes, which act as network agents and are incentivized to report and block fraud. Extensive disclosure of information enables users to continuously audit the performance of nodes. The simple disclosure of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any consumable output includes an element specifying the amount of digital assets derivable from the sequence of preceding transactions. Consumable outputs are sometimes referred to as UTXOs ("unspent transaction outputs"). An output may further include a locking script that specifies conditions for the future redemption of the output. A locking script is a predicate that defines the conditions required to authenticate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such outputs in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-out output. Consider that a pair of transactions may be labeled as the first transaction and the second transaction (or "target" transaction). A first transaction includes at least one output having a lock script that specifies an amount of digital assets and defines one or more conditions for unlocking the output. A second target transaction has at least one input including a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In this model, when a second target transaction is transmitted to a blockchain network and propagated and recorded on the blockchain, one of the validity criteria applied at each node will be whether the unlock script satisfies all of one or more conditions defined in the lock script of the first transaction. Another will be whether the output of the first transaction has not already been reclaimed by another preceding valid transaction. Any node that discovers that the target transaction is invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly propagate it to register it as an invalid transaction), nor will it include it in a new block to be recorded on the blockchain.

[0008] An alternative type of transaction model is an account-based model. In this case, rather than defining the amount to be transferred by referencing the UTXO of a preceding transaction within a sequence of past transactions, each transaction defines the amount to be transferred by referencing the absolute account balance. The current state of all accounts is stored by nodes separately from the blockchain and is continuously updated.

[0009] As blockchain technology is applied to an increasing number of transactions, managing the volume of transactions is becoming difficult. For example, general credit card payment networks, such as those of Mastercard or Visa, typically process thousands of transactions per second in batches. It can be advantageous for blockchain networks to have solutions that enable them to manage a similar level of throughput. Brief explanation of the drawing

[0010] Now, we will refer to the accompanying drawings illustrating exemplary embodiments of the present application as an example. Figure 1 illustrates an exemplary system for implementing a blockchain. Figure 2 illustrates an exemplary transaction protocol. FIG. 3a illustrates an exemplary implementation of a client application. Figure 3b illustrates an example of a user interface for a client application. Figure 4 illustrates exemplary node software for a blockchain node. FIG. 5 schematically illustrates a simplified exemplary blockchain node for processing a large volume of blockchain transactions. Figure 6 illustrates an exemplary method of performing transaction clean-up as a result of block announcement in the form of a flowchart. Figure 7 illustrates another exemplary method for performing transaction cleanup in the form of a flowchart. Figure 8 illustrates an additional exemplary method for performing transaction cleanup in the form of a flowchart. In drawings, the same reference numbers are used to represent similar elements and features. Specific details for implementing the invention

[0011] In one aspect, a computer implementation method for processing blockchain transactions by a node may be provided. The method may include the steps of: constructing a candidate datastore containing transaction identifiers for each validated transaction within a candidate block during a mining phase; receiving two or more arrays from another node, each array containing an individual set of transaction identifiers; identifying transaction identifiers within the candidate datastore that match transaction identifiers in one of the two or more arrays, and recording the array identifier of one of the two or more arrays for each matching transaction identifier within the candidate datastore. The method may include the steps of: receiving a block solution identifying multiple arrays from another node during a block validation phase; identifying each transaction identifier within the candidate datastore having a recorded array identifier that matches one of the arrays within the multiple arrays; and marking the transaction identifier as being present in the block solution. After the block solution is authenticated, the method may further include the step of identifying all transaction identifiers within candidate datastores that are not marked as being in the block solution, and making said transaction identifiers available to other services within the node.

[0012] In some embodiments, the step of identifying each transaction identifier in a candidate datastore having a recorded array identifier that matches one of the arrays in a plurality of arrays includes the step of constructing a list of array identifiers from a block solution in memory. In some cases, the step of constructing a list of array identifiers includes the step of constructing a hash table populated by array identifiers from a block solution. In some of these cases, the step of marking a transaction identifier as being in a block solution includes, for each array identifier in the hash table, searching the candidate datastore to identify transaction identifiers marked with the corresponding array identifier, and marking the corresponding transaction identifiers as being in a block solution.

[0013] In some implementations, the step of marking transaction identifiers as being in a block solution includes the step of marking transaction identifiers as being in tip i, where i is an index for a block solution among a plurality of announced block solutions.

[0014] In some embodiments, the step of identifying all transaction identifiers in a candidate datastore that are not marked as being in a block solution includes the step of removing all transaction identifiers marked as being in a block solution from the candidate datastore. In some cases, the step of making the transaction identifiers available includes the step of copying and transferring all remaining transaction identifiers from the candidate datastore to another service.

[0015] In some embodiments, the block solution includes a new array that has not previously been received from another node, and the method further comprises the steps of: obtaining a set of transaction identifiers included in the new array and loading it into memory; and querying a candidate datastore for a match for each transaction identifier in the set, and if a match is found, marking the corresponding transaction identifier in the candidate datastore as being in the block solution. The new array that has not previously been received may be an array that has not been received during the mining phase.

[0016] In some implementations, the method includes the step of constructing a candidate block containing authenticated transactions while constructing a candidate datastore.

[0017] In some implementations, the step of making the transaction identifiers available to other services includes the step of forwarding the transaction identifiers to at least a block assembly service to construct a new candidate block.

[0018] In some embodiments, the step of making these transaction identifiers available may include notifying the other service that the candidate database is available for access by the other service and that the candidate database contains all transaction identifiers that are not marked as being in a block solution.

[0019] In some implementations, other services include a mempool monitoring service or a double-spending detection service.

[0020] In another aspect, the present application describes a method for processing blockchain transactions by a node, comprising: during a mining phase, constructing a candidate datastore containing transaction identifiers for each authenticated transaction within a candidate block; receiving from another node two or more arrays, each array containing an individual set of transaction identifiers; identifying transaction identifiers within the candidate datastore that match transaction identifiers in one of the two or more arrays, and recording the array identifier of one of the two or more arrays for each matching transaction identifier within the candidate datastore. The method may further comprise, during a block authentication phase, receiving from another node a block solution identifying a plurality of arrays, identifying each transaction identifier within the candidate datastore associated with said other node, and marking said transaction identifiers as being within the block solution; and after the block solution is authenticated, identifying all transaction identifiers within the candidate datastore that are not marked as being within the block solution, and making said transaction identifiers available to other services within the node.

[0021] In some embodiments, the recording step includes recording a node identifier for the other node for each matching transaction identifier in the candidate datastore. In some cases, the step of identifying each transaction identifier in the candidate datastore associated with the other node includes identifying each transaction identifier in the candidate datastore marked as a node identifier for the other node. In some such cases, the step of identifying each transaction identifier in the candidate datastore marked as a node identifier includes, as a prerequisite, determining that all arrays received from the other node are included in the block solution.

[0022] In some embodiments, the block solution includes a new array that has not previously been received from another node, and the method further comprises the steps of: obtaining a set of transaction identifiers included in the new array and loading it into memory; and querying a candidate datastore for a match for each transaction identifier in the set, and if a match is found, marking the corresponding transaction identifier in the candidate datastore as being in the block solution. The new array that has not previously been received may be an array that has not been received during the mining phase.

[0023] In some implementations, the step of marking transaction identifiers as being in a block solution includes the step of marking transaction identifiers as being in tip i, where i is an index for a block solution among a plurality of announced block solutions.

[0024] In some embodiments, the blockchain network comprises a plurality of different nodes, and the node comprises individual candidate datastores for each of the other nodes, and the step of identifying each transaction identifier in the candidate datastore associated with the other node comprises the step of identifying the individual candidate datastore associated with the other node.

[0025] In some embodiments, the method includes the step of constructing a candidate block containing authenticated transactions while constructing a candidate datastore. The step of constructing the candidate block may be performed by a block assembly service using a first memory, and the candidate datastore may be contained in a second memory separated from the first memory.

[0026] In some implementations, the step of making the transaction identifiers available to other services includes the step of forwarding the transaction identifiers to at least a block assembly service to construct a new candidate block.

[0027] In some embodiments, the step of making these transaction identifiers available may include notifying the other service that the candidate database is available for access by the other service and that the candidate database contains all transaction identifiers that are not marked as being in a block solution.

[0028] In some implementations, other services include a mempool monitoring service or a double-spending detection service.

[0029] In another aspect, the present application describes a computer implementation method for processing blockchain transactions by a node. The method may include: building in memory a list of transaction identifiers included in a candidate block mined by the node during a mining phase; receiving a block solution from another node specifying a resolved block; and in response thereto, loading a set of transaction identifiers from the resolved block into memory; querying the set of transaction identifiers for a match for each transaction identifier in the list, and if a match is found, marking the transaction identifier in the list as included in the resolved block; and after the block solution is authenticated, removing all transaction identifiers in the list marked as being in the resolved block and building a new candidate block using any remaining transaction identifiers in the list.

[0030] In another aspect, a computing device implementing a node on a blockchain network may be provided. The computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processors to perform one or more of the methods described herein.

[0031] In another aspect, a computer-readable medium storing processor-executable instructions may be provided, wherein the processor-executable instructions include instructions that, when executed by one or more processors, cause the processors to perform at least one of the methods described herein.

[0032] Other exemplary embodiments of the present disclosure will be apparent to those skilled in the art from a review of the following detailed description together with the drawings.

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

[0034] In this application, the phrase “...at least one of” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements and without necessarily requiring all elements.

[0035] Exemplary System Overview

[0036] FIG. 1 illustrates an exemplary system (100) for implementing a blockchain (150). The system (100) may include a packet-switched network (101), typically a wide-area internetwork such as the Internet. The packet-switched network (101) includes a plurality 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 illustrated, the blockchain nodes (104) may be arranged as a near-complete graph. Thus, each blockchain node (104) is highly connected to other blockchain nodes (104).

[0037] Each blockchain node (104) includes computer equipment of a peer, and different nodes among the nodes (104) belong to different peers. Each blockchain node (104) includes a processing unit implemented by one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also includes memory, that is, computer-readable storage in the form of non-transient computer-readable media or media. The memory may include one or more memory units employing one or more memory media, such as magnetic media such as hard disks; electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs; and / or optical media such as optical disc drives.

[0038] A blockchain (150) comprises a chain (151) of blocks of data, and individual copies of the blockchain (150) are maintained at each of the multiple blockchain nodes (104) within a distributed or blockchain network (160). As mentioned above, maintaining copies of the blockchain (150) does not necessarily mean storing the entire blockchain (150). Instead, the blockchain (150) may be pruned as long as each blockchain node (150) stores the block header (discussed below) of each block (151). Each block (151) in the chain contains one or more transactions (152), and a transaction in this context refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain will use one specific transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction (152) has at least one input and at least one output. Each output specifies an amount representing the quantity of digital assets as property, an example being a user (103) whose output is cryptographically locked (requiring the user's signature or other solution to be unlocked and thereby recovered or consumed). Each input points back to the output of a preceding transaction (152), thereby linking the transactions.

[0039] Each block (151) also includes a block pointer (155) that points back to a previously created block (151) in the chain to define a sequential order for the blocks (151). Each transaction (152) (other than a coinbase transaction) has a pointer that points back to a previous transaction to define an order for a sequence of transactions (Note: sequences of transactions (152) are allowed to branch). The chain of blocks (151) returns to the genesis block (Gb) (153), which was the first block in the chain. One or more original transactions (152) at the beginning of the chain (150) point to the genesis block (153), not the preceding transaction.

[0040] Each blockchain node (104) is configured to forward transactions (152) to other blockchain nodes (104), thereby causing the transactions (152) to propagate across the network (106). Each blockchain node (104) is configured to generate blocks (151) and store individual copies of the same blockchain (150) in their individual memories. Each blockchain node (104) also maintains an ordered set (154) of transactions (152) waiting to be incorporated into the blocks (151). The ordered set (154) is often referred to as a "mempool." In this specification, this term is not intended to be limited to any specific blockchain, protocol, or model. It refers to an ordered set of transactions that the node (104) accepts as valid and is obligated not to accept any other transactions that the node (104) attempts to consume the same output.

[0041] In a given current transaction (152j), the input (or each input) includes a pointer that references the output of a preceding transaction (152i) in a sequence of transactions, specifying that this output will be reclaimed or "consumed" in the current transaction (152j). Generally, the preceding transaction may be any transaction within any block (151) or sorted set (154). For the current transaction (152j) to be valid, the preceding transaction (152i) must exist and be authenticated, but the preceding transaction (152i) does not necessarily have to exist at the time the current transaction (152j) is created or even transmitted to the network (106). Accordingly, in this specification, “predecessor” refers to a predecessor in a logical sequence linked by pointers and does not necessarily refer to a time of creation or transmission in a time sequence, and thus does not necessarily exclude transactions (152i, 152j) being created or transmitted out of order (see discussion below regarding orphan transactions). The preceding transaction (152i) may also be referred to as the antecedent transaction or the predecessor transaction.

[0042] The input of the current transaction (152j) also includes input authorization, for example, the signature of the user (103a) whose output of the preceding transaction (152i) is locked. Eventually, the output of the current transaction (152j) can be cryptographically locked to a new user or entity (103b). Thus, the current transaction (152j) can transfer an amount defined in the input of the preceding transaction (152i) to the new user or entity (103b) as defined in the output of the current transaction (152j). In some cases, the transaction (152) may have multiple outputs for dividing 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, the transaction may also have multiple inputs for collecting amounts from multiple outputs of one or more preceding transactions and redistributing them to one or more outputs of the current transaction.

[0043] According to an output-based transaction protocol such as Bitcoin, when an entity (103), such as a user or machine, wishes to enact a new transaction (152i), the entity transmits the new transaction from its computer terminal (102) to a recipient. The entity or recipient will eventually transmit 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, they may be other user terminals). It is also not excluded that the entity (103) performing the new transaction (152j) may transmit the transaction to one or more of the blockchain nodes (104) and, in some examples, not transmit it to a recipient. The blockchain node (104) receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied to each of the blockchain nodes (104). A blockchain node protocol typically requires a blockchain node (104) to check whether the cryptographic signature in a new transaction (152j) matches the expected description, which depends on the previous transaction (152i) in an ordered sequence of transactions (152). In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of an entity (103) included in the input of the new transaction (152j) matches a condition defined in the output of the preceding transaction (152i) to which the new transaction is assigned, wherein the condition typically includes checking whether the cryptographic signature or other authorization in the input of the new transaction (152j) unlocks the output of the preceding transaction (152i) to which the input of the new transaction is linked. The condition may be at least partially defined by a script included in the output of the preceding transaction (152i). Alternatively, this may be fixed simply by the blockchain node protocol alone, or due to a combination thereof.In either case, if the new transaction (152j) is valid, the blockchain node (104) forwards it to one or more other blockchain nodes (104) within the blockchain network (106). These other blockchain nodes (104) apply the same test according to the same blockchain node protocol and, accordingly, forward the new transaction (152j) to one or more additional nodes (104), etc. In this way, the new transaction is propagated throughout the entire network of blockchain nodes (104).

[0044] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated is whether the output has already been validly reclaimed by the input of another subsequent (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 the transaction attempts to allocate or reclaim has not already been allocated / reclaimed by another transaction. Again, if invalid, the transaction (152j) will not be propagated or recorded on the blockchain (150) (unless it is flagged as invalid and propagated for warning). This prevents double spending, where a trader attempts to allocate the output of the same transaction more than once. On the other hand, an account-based model takes precautions against double spending by maintaining an account balance. Again, because there is a defined order of transactions, the account balance has a single defined state at any given time.

[0045] In addition to authenticating transactions, blockchain nodes (104) also compete to be the first to generate blocks of transactions in a process commonly referred to as mining supported by “proof of work.” At the blockchain nodes (104), new transactions are added to an ordered set (154) of valid transactions that have not yet appeared in a block (151) recorded on the blockchain (150). Then, the blockchain nodes compete to assemble a new valid block (151) of transactions (152) from the ordered set (154) of transactions by attempting to solve a cryptographic puzzle. Typically, this involves retrieving a “nonce” value, and when the nonce is concatenated with and hashed with a representation of the ordered set (154) of transactions, the output of the hash satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash has a specific predefined number of leading zeros. It should be noted that this is only one specific type of proof-of-work puzzle, and other types are not excluded. The characteristic of a hash function is that it has an unpredictable output for its input. Accordingly, such a search can only be performed by brute force, and thus consumes a significant amount of processing resources at each blockchain node (104) attempting to solve the puzzle.

[0046] The first blockchain node (104) for solving the puzzle announces this to the network (106) and then provides a proof of the solution that can be easily checked by other blockchain nodes (104) in the network (it is simple to check whether the output of the hash satisfies the conditions once a solution for the hash is given). The first blockchain node (104) accepts the block and propagates the block to a critical consensus point of other nodes that enforce the protocol rules accordingly. Subsequently, an ordered set of transactions (154) is recorded by each of the blockchain nodes (104) as a new block (151) in the blockchain (150). A block pointer (155) that points back to a previously created block (151n-1) in the chain is also assigned to the new block (151n). The significant amount of effort required to generate a proof-of-work solution, such as a hash, signals the first node (104)'s intention to follow the rules of the blockchain protocol. These rules include not accepting a transaction as valid if it assigns the same output as a previously authenticated transaction, also known as double spending. Once created, the block (151) cannot be modified because it is recognized and maintained at each of the blockchain nodes (104) within the blockchain network (106). The block pointer (155) also imposes a sequential order on the blocks (151). Since the transactions (152) are written in ordered blocks at each of the blockchain nodes (104) within the network (106), this provides an immutable public ledger of transactions.

[0047] Different blockchain nodes (104) competing to solve the puzzle at any given point in time may perform operations based on different snapshots of an ordered set (154) of transactions that have not yet been published at any given point in time, depending on when they started searching for a solution or the order in which the transactions were received. Whoever solves their individual puzzle first defines which transactions (152) are included in the next new block (151n) and in what order, and the current set (154) of unpublished transactions is updated. Then, the blockchain nodes (104) continue to compete to create a block from the newly defined unprocessed ordered set (154) of unpublished transactions, and this continues to repeat. There is also a protocol for solving any "fork" that may occur, which is a situation where two blockchain nodes (104) solve their puzzles within a very short time from each other so that a conflicting view of the blockchain between the nodes (104) is propagated. In short, whichever prong of the fork grows the longest becomes the final blockchain (150). Note that since the same transaction will appear in both forks, this should not affect the users or agents of the network.

[0048] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block (104) is granted the ability to allocate an accepted amount of digital assets in a new special type of transaction that distributes a defined amount of digital assets (in contrast to inter-agent or inter-user transactions that transfer an amount of digital assets from one agent or user to another). This special type of transaction is generally referred to as a "coinbase transaction," but may also be referred to as an "initiation transaction." This typically forms the first transaction of the new block (151n). Proof of work signals the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be recovered later. Blockchain protocol rules may require a maturity period, such as 100 blocks, before this special transaction can be recovered. Often, a regular (non-generated) transaction (152) will also specify an additional transaction fee in one of its outputs to further reward the blockchain node (104) that generated the block (151n) in which the transaction was issued. This fee is generally referred to as a "transaction fee" and is discussed below.

[0049] Due to the resources involved in transaction authentication and publication, typically at least each blockchain node (104) takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node (104) may take the form of a group of user terminals networked together or a user terminal.

[0050] The memory of each blockchain node (104) stores software configured to be executed on the processing unit of the blockchain node (104) to perform their respective roles or roles and handle transactions (152) in accordance with the blockchain node protocol. It will be understood that any action attributed to the blockchain node (104) herein may be performed by software executed on the processing unit of the individual computer equipment. The node software may be implemented as one or more applications in the application layer, or in lower layers such as the operating system layer or the protocol layer, or any combination thereof.

[0051] Additionally, the network (101) is connected to the computer equipment (102) of each of the multiple parties (103) acting as consuming users. These users can interact with the blockchain network but do not participate in authenticating, creating, or propagating transactions and blocks. Some of these users or agents (103) 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 copies of the blockchain (150) (e.g., obtaining a copy of the blockchain from a blockchain node (104)).

[0052] Some or all of the parties (103) may be connected as part of a different network, such as a network overlaid on top of a blockchain network (106). Users of the blockchain network (often referred to as "clients") may be said to be part of a system containing the blockchain network, but these users are not blockchain nodes (104) because they do not perform the roles required of blockchain nodes. Instead, each party (103) may interact with the blockchain network (106) by connecting (i.e., communicating) to the blockchain node (106) and thereby utilize the blockchain (150). Two parties (103) and their respective equipment (102) are illustrated for exemplary purposes: a first party (103a) and its individual computer equipment (102a), and a second party (103b) and its individual computer equipment (102b). It will be understood that more such parties (103) and their individual computer equipment (102) may exist and participate in the system (100), but for convenience, they are not exemplified. Each party (103) may be an individual or an organization. Purely by example, the first party (103a) is referred to herein as Alice and the second party (103b) as Bob, but this is not limiting, and it will be understood that any reference to Alice or Bob in the present invention may be replaced with "first party" and "second party," respectively.

[0053] The computer equipment (102) of each party (103) comprises individual processing units comprising one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer equipment (102) of each party (103) further comprises memory, i.e., computer-readable storage in the form of non-transient computer-readable media or media. This memory may comprise one or more memory units employing one or more memory media, such as magnetic media such as a hard disk; electronic media such as an SSD, flash memory, or EEPROM; and / or optical media such as an optical disc drive. The memory on the computer equipment (102) of each party (103) stores software, such as individual instances of at least one client application (105), arranged to be executed on the processing unit. It will be understood that any action attributable to a given party (103) herein may be performed using software executed on the processing unit of the individual computer equipment (102). The computer equipment (102) of each party (103) includes at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment (102) of a given party (103) may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

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

[0055] The client application (105) includes at least a “wallet” function. It has two main functions. One of these is to enable an individual party (103) to create, authorize (e.g., sign) transactions (152) and send them to one or more Bitcoin nodes (104), so that they are subsequently propagated across the entire network of blockchain nodes (104) and thereby included in the blockchain (150). The other is to report back to the individual party the amount of digital assets currently owned. In an output-based system, this second function includes collating defined amounts from the outputs of various transactions (152) distributed across the entire blockchain (150) belonging to the party.

[0056] While various client functions may be described as being integrated into a given client application (105), this is not necessarily limiting; instead, it will be understood that any client function described herein may be implemented as a suite of two or more distinct applications, such as being interfaced via an API or one plugging into another. More generally, client functions may be implemented in the application layer or a lower layer, such as an operating system, or any combination thereof. The following will be described in terms of the client application (105), but it will be understood that this is not limiting.

[0057] An instance of a client application or software (105) on each computer equipment (102) is operably coupled to at least one of the blockchain nodes (104) of the network (106). This enables the wallet function of the client (105) to transmit transactions (152) to the network (106). The client (105) may also contact the blockchain nodes (104) to query the blockchain (150) for any transactions to which the individual parties (103) are recipients (or, in the embodiments, to actually examine the transactions of other parties in the blockchain (150), since the blockchain (150) is a public facility that provides trust in the transactions in part through its public visibility). The wallet function on each computer equipment (102) is configured to formulate and transmit transactions (152) according to the transaction protocol. As described above, each blockchain node (104) executes software configured to authenticate transactions (152) according to the blockchain node protocol and to forward the transactions (152) to propagate the transactions across the entire blockchain network (106). The transaction protocol and the node protocol correspond to each other, and a given transaction protocol proceeds together with a given node protocol to implement a given transaction model together. The same transaction protocol is used for all transactions (152) within the blockchain (150). The same node protocol is used by all nodes (104) within the network (106).

[0058] When a given party (103), such as Alice, wishes to send a new transaction (152j) to be included in the blockchain (150), Alice formulates the new transaction according to the relevant transaction protocol (using the wallet function in her client application (105)). Then, she sends the transaction (152) from the client application (105) to one or more blockchain nodes (104) to which she is connected. For example, this may be a blockchain node (104) best connected to Alice's computer (102). When any given blockchain node (104) receives the new transaction (152j), it handles the transaction according to the blockchain node protocol and its respective role. This may include first checking whether the newly received transaction (152j) satisfies certain conditions to be "valid," examples of which will be discussed in more detail shortly. In some transaction protocols, conditions for authentication may be configured per transaction by scripts included in the transactions (152). Alternatively, the condition can be simply an embedded feature of the node protocol, or it can be defined by a combination of the script and the node protocol.

[0059] Under the condition that the newly received transaction (152j) passes a test in which it is considered valid (i.e., under the "authenticated" condition), any blockchain node (104) receiving the transaction (152j) will add the new authenticated transaction (152) to the ordered set (154) of transactions maintained at that blockchain node (104). Additionally, any blockchain node (104) receiving the transaction (152j) will propagate the authenticated transaction (152) onward to one or more other blockchain nodes (104) within the network (106). Since each blockchain node (104) applies the same protocol, assuming the transaction (152j) is valid, this means that the transaction (152j) will soon be propagated across the entire network (106).

[0060] When an ordered set (154) of transactions maintained by a given blockchain node (104) is approved, the blockchain node (104) will begin to compete to solve a proof-of-work puzzle for the latest version of the ordered set (154) of their individual transactions, including a new transaction (152) (remind that other blockchain nodes (104) may attempt to solve the puzzle based on different ordered sets (154) of transactions, but whichever node solves the puzzle first will define the ordered set of transactions included in the latest block (151), and eventually the blockchain node (104) will solve the puzzle for a part of the ordered set (154) including Alice's transaction (152j)). When a proof-of-work is performed for the ordered set (154) including the new transaction (152j), it invariably becomes part of one of the blocks (151) within the blockchain (150). Each transaction (152) includes a pointer that points back to the previous transaction, and the order of the transactions is also recorded so as not to be altered.

[0061] Different blockchain nodes (104) may receive different instances of a given transaction first, and thus may have conflicting views on which instance is 'valid' before one instance is issued in a new block (151), at which point all blockchain nodes (104) agree that the issued instance is the only 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), the blockchain node (104) must accept it and discard the instance that was initially accepted (i.e., the instance not issued in the block (151)) (i.e., treat it as invalid).

[0062] An alternative type of transaction protocol operated by some blockchain networks can be referred to as an "account-based" protocol as part of an account-based transaction model. In the case of account-based transactions, each transaction defines the amount to be transferred by referencing the absolute account balance rather than by referencing the UTXO of a preceding transaction within a sequence of past transactions. The current state of all accounts is stored separately from the blockchain by the nodes of the corresponding network and is continuously updated. In such a system, transactions are sorted using the account's execution transaction aggregation (also referred to as "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may also be signed by the transaction. This data field can point back to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0063] UTXO-based model

[0064] FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction (152) (abbreviated as "Tx") is a basic data structure of a blockchain (150) (each block (151) contains one or more transactions (152)). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that while an exemplary UTXO-based protocol is described with reference to Bitcoin, it can be implemented in the same way on other exemplary blockchain networks.

[0065] In a UTXO-based model, each transaction ("Tx") (152) is a data structure having one or more inputs (202) and one or more outputs (203). Each output (203) may contain a UTXO that can be used as a source for the input (202) of another new transaction (if the unspent transaction output (UTXO) has not already been recovered). The UTXO contains a value specifying the amount of digital assets. This represents the number of sets of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header (201) that may contain an indicator of the size of the input field(s) (202) and the output field(s) (203). The header (201) may also include the transaction ID. In some embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header (201) of the original transaction (152) submitted to the nodes (104).

[0066] Alice (103a) says she wants to create a transaction (152j) that transfers the amount of the digital asset to Bob (103b). In FIG. 2, Alice's new transaction (152j) is labeled "Tx1". This takes the amount of the digital asset locked in Alice from 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 merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain (151) or that Tx1 is the very next transaction in the pool (154). Tx1 can refer back to any preceding (i.e., earlier) transaction that still has the unused output (203) locked in Alice.

[0067] The preceding transaction (Tx0) may already be authenticated and included in a block (151) of the blockchain (150) by the time Alice creates her new transaction Tx1, or at least by the time she transmits 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 a sorted set (154), in which case it will soon be included in a new block (151). Alternatively, Tx0 and Tx1 may be created and transmitted together to the network (106), or if the node protocol allows buffering of "orphan" transactions, Tx0 may even be transmitted after Tx1. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by the transaction pointers specified in the transactions (such as which transaction points to another transaction). These may be equally replaced with "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. This does not necessarily imply the order in which they are generated, transmitted to the network (106), or arrive at any given blockchain node (104). Nevertheless, a subsequent transaction (descendant transaction or "child") pointing to a preceding transaction (predecessor transaction or "parent") will not be authenticated until the parent transaction is authenticated, and unless it is authenticated. A child that arrives at the blockchain node (104) before its parent is considered an orphan. Depending on the node protocol and / or node behavior, this may be discarded or buffered for a certain period of time to wait for the parent.

[0068] One or more outputs (203) of a preceding transaction (Tx0) is a specific UTXO labeled here as UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO, and a lock script defining conditions that must be satisfied by an unlock script in the input (202) of the subsequent transaction for the subsequent transaction to be authenticated and the UTXO to be successfully recovered. Typically, the lock script locks the amount to a specific party (the beneficiary of the transaction containing the amount). That is, the lock script defines unlock conditions, and generally includes a condition that the unlock script in the input of the subsequent transaction contains the cryptographic signature of the party to whom the preceding transaction was locked.

[0069] A lock script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of this language is called a "script" (uppercase S) used by the blockchain network. The lock script specifies what information is required to consume the transaction output (203), for example, the requirement for Alice's signature. Unlock scripts appear in the outputs of the transactions. An unlock script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the lock script criteria. For example, this may include Bob's signature. Unlock scripts appear in the inputs (202) of the transactions.

[0070] Therefore, in the example illustrated, UTXO0 in the output (203) of Tx0 is Alice's signature Sig P for UTXO0 to be redeemed (strictly, for a subsequent transaction attempting to redeem UTXO0 to be valid). A Lock script requiring [Checksig P A Includes ]. [Checksig P A] is the public key P from Alice's public-private key pair A It includes a representation (i.e., a hash). The input (202) of Tx1 includes a pointer that points back to Tx0 (e.g., by its transaction ID (TxID0), which is the hash of the entire transaction Tx0 in some embodiments). The input (202) of Tx1 includes an index that identifies UTXO0 within Tx0 to identify it among any other possible outputs of Tx0. The input (202) of Tx1 is an unlock script having Alice's cryptographic description generated by Alice applying her private key from the key pair to a predefined part of the data (sometimes referred to as a "message" in cryptography). <Sig P A Includes > further. Data (or "messages") that need to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or by a combination thereof.

[0071] When a new transaction (Tx1) arrives at a blockchain node (104), the node applies a node protocol. This may include executing a lock script and an unlock script together to check whether the unlock script satisfies a condition defined in the lock script (wherein this condition may include one or more criteria). In some embodiments, this may involve concatenating the two scripts:

[0072] <Sig P A > <P A > || [Checksig P A ]

[0073] Here, "||" represents concatenation, "<...>" signifies placing data onto a stack, and "[...]" is a function executed by a locking script (a stack-based language in this example). Equivalently, scripts can be executed one by one on a common stack rather than concatenating scripts. In either case, when executed together, the scripts use Alice's public key (PA), as included in the locking script at the output of Tx0, to authenticate that the unlocking script at the input of Tx1 contains Alice's signature signing the expected portion of the data. The expected portion of the data itself ("message") also needs to be included to perform this authentication. In the embodiments, the signed data includes the entire Tx1 (therefore, there is no need to include a separate element explicitly specifying the signed portion of the data, as the signed portion already exists by nature).

[0074] The details of authentication by public-private encryption will be familiar to those skilled in the art. Basically, if Alice has signed a message using her private key, given Alice's public key and the message, other entities such as Node (104) can authenticate that the message was signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging the message as a signature, thereby allowing any holder of the public key to authenticate the signature. Accordingly, it should be noted that any reference in this specification to signing a specific part of data or part of a transaction, etc., may mean signing the hash of said part of data or part of a transaction in the embodiments.

[0075] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, if Alice's signature is provided and authenticated in Tx1), the blockchain node (104) considers Tx1 to be valid. This means that the blockchain node (104) will add Tx1 to an ordered set of transactions (154). The blockchain node (104) will also forward transaction Tx1 to one or more other blockchain nodes (104) within the network (106) so that the transaction will be propagated throughout the network (106). Once Tx1 is authenticated and included in the blockchain (150), this defines the UTXO0 from Tx0 as consumed. Note that Tx1 can only be valid if it consumes an unconsumed transaction output (203). If it attempts to consume an output that has already been consumed by another transaction (152), Tx1 will be invalid, even if all other conditions are satisfied. Therefore, the blockchain node (104) also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been consumed (i.e., whether it has already formed a valid input for another valid transaction). This is one important reason why the blockchain (150) imposes a defined order on the transactions (152). In practice, a given blockchain node (104) may maintain a separate database indicating which UTXOs (203) of which transactions (152) have been consumed, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input for another valid transaction within the blockchain (150).

[0076] If the total amount specified in all outputs (203) of a given transaction (152) is greater than the total amount indicated by all its inputs (202), this is another ground for invalidation in most transaction models. Therefore, such transactions will not only not be propagated but will also not be included in a block (151).

[0077] In UTXO-based transaction models, it is important to note that a given UTXO must be consumed in its entirety. It is impossible to "leave" a portion of the amount defined in a UTXO unused while consuming only a portion of the others. However, the amount from a UTXO can be split among multiple outputs of the following transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Therefore, if Alice does not wish to give the entire amount defined in UTXO0 to Bob, she can use the remainder to give herself change or pay another party from the second output of Tx1.

[0078] In practice, Alice will also generally need to include a fee for the Bitcoin node (104) issuing her transaction. If Alice does not include such a fee, Tx0 may be rejected by the blockchain nodes (104) and thus, although technically valid, may not be propagated and may not be included in the blockchain (150) (the node protocol does not force the blockchain nodes (104) to accept transactions (152) if they do not want to). In some protocols, transaction fees do not require their own separate outputs (203) (i.e., do not require separate UTXOs). Instead, any difference between the total amount pointed to by the input(s) (202) of a given transaction (152) and the total amount specified in the output(s) (203) is automatically paid to the blockchain node (104) issuing the transaction. For example, assume that a pointer to UTXO0 is the only input to Tx1, and that Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node (104) that issues the block containing UTXO1. However, alternatively or additionally, it is not necessarily excluded that the transaction fee may be explicitly specified in the UTXO itself among the UTXOs (203) of the transaction (152).

[0079] Alice and Bob's digital assets consist of UTXOs locked to them in random transactions (152) across the blockchain (150). Thus, typically, the assets of a given party (103) are distributed across UTXOs of various transactions (152) across the blockchain (150). Nowhere within the blockchain (150) is a single number stored that defines the total balance of a given party (103). The role of the wallet function in the client application (105) is to compare together the values ​​of all the various UTXOs that are locked to individual parties and have not yet been spent in other subsequent transactions. This can be done by querying a copy of the blockchain (150) stored in any of the Bitcoin nodes (104).

[0080] Note that script code is often expressed in a general way (i.e., not using precise language). For example, opcodes may be used to represent specific functions. "OP_..." refers to specific opcodes in the script language. For example, OP_RETURN is an opcode in the script language that, when preceded by OP_FALSE at the start of a lock script, generates an unspendable output of a transaction that can store data within the transaction and, accordingly, immutably record the data on the blockchain (150). For example, the data may include documents that are to be stored on the blockchain.

[0081] Typically, the input to a transaction is the public key (P AIt includes a digital signature corresponding to ). In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature will sign parts of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs that this signs depend on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature to select which outputs are signed (and thus fixed at the time of signing).

[0082] Lock scripts are sometimes referred to as "scriptPubKey," referring to the fact that they generally contain the public key of the party whose transaction is being locked. Unlock scripts are sometimes referred to as "scriptSig," referring to the fact that they generally provide a corresponding signature. However, more generally, it is not mandatory for all applications of the blockchain (150) for the conditions for a UTXO to be recovered to include the authentication of a signature. More generally, scripting languages ​​may be used to define any one or more conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0083] As illustrated in FIG. 1, client applications on the respective computer equipment (102a, 120b) of Alice and Bob may include additional communication functions. This additional function allows Alice (103a) to establish a separate side channel (301) with Bob (103b) (at the suggestion of either party or a third party). The side channel (301) enables the exchange of data separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, it may be used to exchange a transaction (152) between Alice and Bob without the transaction being registered on the blockchain network (106) or entering the chain (150) until one of the parties chooses to broadcast it to the network (106). Sharing a transaction in this manner is sometimes referred to as sharing a "transaction template." A transaction template may not contain one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel (301) may be used to exchange any other transaction-related data, such as keys, negotiated amounts or conditions, data content, etc.

[0084] The side channel (301) may be established through the same packet switching network (101) as the blockchain network (106). Alternatively or additionally, the side channel (301) may be established through a different network, such as a mobile cellular network, a local area network such as a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices (102a, 102b). Generally, the side channel (301) referred to anywhere in this invention may include any one or more links through one or more networking technologies or communication media to exchange data "off-chain," that is, separately from the blockchain network (106). If more than one link is used, the entire bundle or set of off-chain links may be referred to as the side channel (301). Thus, it should be noted that if Alice and Bob exchange specific information or data, etc., through the side channel (301), this does not necessarily mean that all such pieces of data must be transmitted through exactly the same link or even the same type of network.

[0085] Client software

[0086] FIG. 3a illustrates an exemplary implementation of a client application (105) for implementing embodiments of the method currently disclosed. The client application (105) may include a transaction engine (401) and a user interface (UI) layer (402). The transaction engine (401) is configured to implement underlying transaction-related functions of the client (105), such as formulating transactions (152) according to the processes discussed above, receiving and / or transmitting transactions and / or other data through a side channel (301), and / or transmitting transactions to one or more nodes (104) to be propagated through a blockchain network (106).

[0087] The UI layer (402) is configured to render a user interface through the user input / output (I / O) means of the computer equipment (102) of each user, including outputting information to each user (103) through the user output means of the equipment (102) and receiving input from each user (103) through the user input means of the equipment (102). For example, the user output means may include one or more display screens (touch or non-touch screens) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing tactile output. The user input means may include, for example, an input array of one or more touch screens (which may be the same or different as used in the output means); one or more cursor-based devices such as a mouse, trackpad, or trackball; one or more microphones and voice or voice recognition algorithms for receiving voice or verbal input; one or more gesture-based input devices for receiving input in the form of hands or physical gestures; or one or more mechanical buttons, switches, or joysticks.

[0088] Although the various functions of this specification may be described as being integrated into the same client application (105), this is not necessarily limiting; instead, they may be implemented as a suite of two or more separate applications, for example, one may be a plugin to another or interface through an application programming interface (API). For example, the functions of the transaction engine (401) may be implemented as an application separate from the UI layer (402), or the functions of a given module, such as the transaction engine (401), may be divided into more than one application. It is also not excluded that some or all of the described functions may be implemented, for example, at the operating system layer. Wherever a single or given application (105) or similar is referred to in this specification, it will be understood that this is merely an example and, more generally, the described functions may be implemented in any form of software.

[0089] FIG. 3b provides an example mock-up of a user interface (UI) (500) that can be rendered by the UI layer (402) of a client application (105a) on Alice's device (102a). It will be known that a similar UI can be rendered by a client (105b) on Bob's device (102b), or that a UI of any other party can be rendered.

[0090] As an example, FIG. 3b illustrates a UI (500) from Alice's perspective. The UI (500) may include one or more UI elements (501, 502, 502) rendered as separate UI elements through a user output means.

[0091] For example, UI elements may include one or more user-selectable elements (501), such as different on-screen buttons or different options within a menu. User input means are arranged to allow the user (103) (in this case Alice (103a)) to select or otherwise operate one of the options by clicking or touching a UI element on the screen or by saying the name of the desired option (Note: The term “manual” as used herein is used merely to contrast with automatic and is not necessarily limited to the use of a hand or hands).

[0092] Alternatively or additionally, UI elements may include one or more data input fields (502). These data input fields (502) are rendered via a user output means, such as on-screen, and data may be entered into the fields via a user input means, such as a keyboard or touchscreen. Alternatively, data may be received verbally, for example, based on speech recognition.

[0093] Alternatively or additionally, UI elements may include one or more information elements (503) that are displayed to display information to the user. For example, the information may be rendered on the screen or audibly.

[0094] It will be understood that specific means of rendering various UI elements, selecting options, and entering data are not important. The functions of these UI elements will be discussed in more detail shortly. It will also be understood that the UI (500) illustrated in FIG. 3b is merely a mock-up, and in reality, it may include one or more additional UI elements not illustrated for the sake of brevity.

[0095] Node Software

[0096] FIG. 4 illustrates an example of node software (450) running on each blockchain node (104) of a network (106) in an example of a UTXO or output-based model. It should be noted that other entities may run node software (450) without being classified as nodes (104) on the network (106), that is, without performing the actions required of nodes (104). 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 (455) of one or more blockchain-related function modules. Each node (104) may run node software that includes (but is not limited to) all three of a consensus module (455C) (e.g., proof of work), a propagation module (455P), and a storage module (455S) (e.g., database). The protocol engine (401) is typically configured to recognize different fields of a transaction (152) and process them according to the node protocol. Another preceding transaction (152i) (Tx m-1 A transaction (152j) (Tx) having an input pointing to the output (e.g., UTXO) of ) j When ) is received, the protocol engine (451) Tx j It identifies the unlock script within and passes it to the script engine (452). The protocol engine (451) also Tx j Tx based on the pointer in the input i Identify and retrieve. Tx i It can be issued on the blockchain (150), in which case the protocol engine Tx from a copy of the block (151) of the blockchain (150) stored in the node (104). i It can retrieve. Alternatively, Tx iIt may not yet be issued on the blockchain (150). In this case, the protocol engine (451) obtains Tx from an ordered set (154) of unissued transactions maintained by the node (104). i It can retrieve. In either case, the protocol engine (451) Tx i Identify the lock script from the referenced output and pass it to the script engine (452).

[0097] Therefore, the script engine (452) Tx i lock script and Tx j It has an unlock script from the corresponding input. For example, transactions labeled Tx0 and Tx1 are exemplified in FIG. 2, but the same can be applied to any pair of transactions. The script engine (452) executes the two scripts together as previously discussed, which will include placing data on the stack (453) and retrieving data from the stack (453) according to the stack-based scripting language used (e.g., Script).

[0098] By executing the script together, the script engine (452) determines whether the unlock script satisfies one or more criteria defined in the lock script, that is, whether the output containing the lock script is "unlocked." 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 satisfies one or more criteria specified in the corresponding lock script, it returns the result "True." Otherwise, it returns the result "False."

[0099] 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 is also one or more additional protocol-level conditions evaluated by the protocol engine (451) that must also be satisfied: e.g., Tx j The total amount of digital assets specified in the output(s) of does not exceed the total amount indicated by its inputs, and the indicated output of Txi has not already been consumed by another valid transaction. The protocol engine (451) evaluates the result from the script engine (452) along with one or more protocol-level conditions, and only if all of them are true, transaction Tx j Validates. The protocol engine (451) outputs an indication of whether the transaction is valid to the application-level determination engine (454). Tx j Only under conditions where it is actually authenticated, the decision engine (454) controls both the consensus module (455C) and the propagation module (455P) to Tx j In relation to this, they may choose to perform individual blockchain-related functions. This involves the consensus module (455C) Tx to an individual ordered set (154) of node transactions to be integrated into a block (151). j Adding, and the propagation module (455P) Tx to other blockchain nodes (104) within the network (106) j It may include forwarding. Optionally, in the embodiments, the application-level decision engine (454) may apply one or more additional conditions before triggering any one or both of these functions. For example, the decision engine may choose to issue a transaction only under the condition that the transaction is valid and leaves a sufficient amount of transaction fees.

[0100] Additionally, the terms “True” and “False” herein are not necessarily limited to returning a result expressed solely in the form of a single binary number (bit), but this is certainly one possible implementation. More generally, “True” may refer to any state indicating a successful or positive result, and “False” may refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model, a result of “True” may be indicated by a combination of implicit protocol-level authentication of a signature and an additional positive output of a smart contract (if both individual results are True, the total result is considered signaled True).

[0101] Other variations or uses of the disclosed techniques may become apparent to those skilled in the art when the disclosures in this specification are given. The scope of the disclosures is not limited by the described embodiments, but only by the appended claims.

[0102] For example, some of the above embodiments have been described in terms of a Bitcoin network (106), a Bitcoin blockchain (150), and Bitcoin nodes (104). However, it will be understood that the Bitcoin blockchain is one specific example of a blockchain (150), and the above description can generally be applied to any blockchain. That is, the invention is not limited to a Bitcoin blockchain. More generally, any of the above references to a Bitcoin network (106), a Bitcoin blockchain (150), and Bitcoin nodes (104) may be replaced by references to a blockchain network (106), a blockchain (150), and a blockchain node (104), respectively. A blockchain, a blockchain network, and / or a blockchain node may share some or all of the described characteristics of a Bitcoin blockchain (150), a Bitcoin network (106), and Bitcoin nodes (104) as described above.

[0103] In some embodiments of the present invention, the blockchain network (106) is a Bitcoin network, and Bitcoin nodes (104) perform at least all of the described functions of creating, publishing, propagating, and storing blocks (151) of the blockchain (150). It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (recall that these entities are not considered to be nodes of the preferred Bitcoin network (106)).

[0104] In some other embodiments of the present invention, the blockchain network (106) may not be a 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 creating, publishing, propagating, and storing blocks (151) of the blockchain (150). For example, on these other blockchain networks, the term "node" may be used to refer to a network entity configured to create and publish blocks (151) but not to store and / or propagate these blocks (151) to other nodes.

[0105] More generally, any reference to the term "Bitcoin node" (104) above may be replaced with the term "network entity" or "network element," wherein such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functions of such network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node (104).

[0106] Bulk transaction handling

[0107] As network capacity grows to accommodate a larger number of transactions, nodes will need to adapt to handling significant flows of transactions. In some possible scenarios, the flow of new transactions can grow to tens of thousands, hundreds of thousands, or even millions of transactions per minute.

[0108] One of the mechanisms for handling the challenges of large volumes and large blocks is for nodes to pre-propagate their candidate blocks before finding a solution. In this way, once a block solution is found, the successful node needs to transmit only the solution details, such as the coinbase transaction, Merkle root, and nonce, instead of transmitting the entire sorted list of TxIDs. Subsequently, other nodes can authenticate the solution based on the already received sorted list of TxIDs.

[0109] To address the problem of a large and constant influx of new transactions, nodes can engage in dynamic transaction authentication and block assembly, where a node constructs a succession of sorted transactions, and the candidate blocks mined by that node consist of these arrays. As new arrays are completed, they are added to the candidate blocks. Meanwhile, the node propagates its completed arrays to other nodes. When a block solution is found, the node transmits a sorted list of array identifiers specifying the solution details and the order of the arrays in the solved block. In this way, other nodes can quickly assemble the solved block from the arrays previously received from that node and subsequently participate in authenticating the block solution.

[0110] In the array-based solution described above, nodes will know that they will receive multiple arrays from other nodes that reflect the arrays built by these nodes and on which they are performing mining operations. Therefore, nodes will maintain a record of arrays from each node. To accelerate block authentication, nodes may be configured to perform some authentication tasks before the announcement of the block solution. Block assembly and authentication are potential bottlenecks to be handled in the case of a high volume of transaction flows. There are several matters involved in block authentication, which include verifying the following: (1) that transaction inputs are valid (e.g., that they reference existing outputs and their unlock scripts are valid); (2) that transactions are not double-spending outputs from previous blocks; (3) that transactions are not double-spending outputs from the current block; and (4) that transactions are topologically aligned. Topological alignment dictates that transactions within a block that consume outputs from other transactions within the same block must appear later in order; that is, child transactions must appear after their parents in an aligned set of transactions within the block. The block authentication service may perform some operations during the mining phase using a set of transaction graph datastores or array transaction databases to prepare for rapid verification of topological order when a block solution is discovered by another node. In some cases, pre-processing of the arrays can be delegated to individual processors, enabling horizontal scaling.

[0111] In the context of high-volume transaction processing, one of the technical challenges for blockchain nodes is that when a valid block is discovered, the node must flush out or remove the transactions in the currently verified block so that they do not remain in the node's current candidate block. At a higher level, a clean-up service can be configured to identify transactions within candidate blocks included in blocks announced by other nodes and then remove these identified transactions from the candidate blocks. However, because this process is likely to be performed in parallel with the block authentication process and because competing block announcements may be received, the clean-up operation is ideally performed in a reversible manner so that it can be canceled as necessary. In some cases, it may be advantageous to perform operations to prepare for the clean-up prior to the announcement of the block solution so that the clean-up operation can be performed as quickly as possible once the newly announced block is authenticated.

[0112] Now, referring to FIG. 5, FIG. 7 schematically illustrates a simplified exemplary blockchain node (550) for processing a large volume of blockchain transactions. In this example, the node (550) is illustrated as a single device, but it will be understood that the node (550) can be implemented using one or more computing devices. The computing devices include, among other systems, one or more processors, memory, an internal communication bus, and an external network communication subsystem.

[0113] A blockchain node (550) is configured for communication through one or more computer networks (552). The computer networks (552) may include peer-to-peer computer networks, such as a blockchain network that interconnects blockchain nodes such as other blockchain nodes (504). The computer networks (552) may include public and / or private computing networks, such as the Internet. In some cases, the computer networks (552) may support multicast communications. The computer networks (552) may enable communications from user devices (506), such as end-user computing or edge devices, capable of generating and transmitting blockchain transactions or queries. User devices may include mobile devices, point-of-sale (POS) devices, merchant computing systems, e-commerce platforms, financial services platforms, payment processing systems, and other such systems or devices.

[0114] A blockchain node (550) can implement a number of services including a propagation service (510), a transaction authentication service (512), a block assembly service (514), a blockchain service (516), and a block authentication service (518). Some or all of these services may be horizontally scalable.

[0115] Additionally, the blockchain node (550) may maintain or access specific stored data. Depending on the implementation, the data may be stored in a database format or in other data structures. The stored data may include, for example, transaction storage (520), UTXO storage (522), one or more array databases (524), and blockchain storage (526).

[0116] The propagation service (510) manages network communications for the blockchain node (550). For example, it can listen for incoming transactions through an IPv6 multicast network. It can perform some basic validation checks on incoming transactions, such as gating, for example, ensuring that the transaction is correctly formatted, has non-zero inputs and outputs, and other such basic validation checks.

[0117] The transaction authentication service (512) can authenticate transactions according to the rules of an applicable blockchain protocol. For example, it can verify that the inputs consumed in the transaction are valid unused outputs of a confirmed or unconfirmed transaction, such as a UTXO. The transaction authentication service (512) can partially verify that a block is valid by referring to the UTXO storage (522) to verify that the inputs are not consumed. The authenticated transactions are passed to the block assembly service (514).

[0118] The transaction authentication service (512) or sub-service may mark any inputs for transactions as consumed in the UTXO storage (522). The authenticated transaction may be stored in the transaction storage (520).

[0119] The block assembly service (514) is responsible for generating new candidate blocks for miners associated with the blockchain node (550). The block assembly service (514) receives a stream or flow of authenticated transactions and assembles them into an array of sorted transaction identifiers. As the array is completed, its Merkle root is calculated, which is added to the current candidate block, the Merkle root of the candidate block is updated, and the candidate block header is pushed to the miners. The newly completed array is announced to other blockchain nodes via computer networks (552).

[0120] The blockchain service (516) manages block headers and arrays in a block and records block data in blockchain storage (526). In some cases, blockchain storage (526) may be a complete copy of the current blockchain. In some cases, blockchain storage (526) may be metadata such as array data containing block headers and TxIDs, but excluding full transaction data.

[0121] In some cases, the array discussed above may be referred to as a subtree, because the transaction identifiers form part of a whole integrated, ordered list of transaction identifiers that may be in a candidate block, and transaction identifiers from the array can be used to discover part of the Merkle tree for the candidate block, i.e., the "subtree." Each array has a unique array identifier or "subtree identifier" that is transmitted along with the array when propagated to other blockchain nodes (504) through the blockchain network. Other nodes that have determined that they have verified and authenticated all transactions within the array may then store the array identifier in memory in association with the array data. Likewise, when a blockchain node (550) receives arrays from other blockchain nodes (504), it determines whether it has received and authenticated all transactions listed in the array by the transaction identifier, and then authenticates the Merkle root of the array and stores the array identifier in memory in association with the array data within the array database (524). Arrays are stored in association with the identifier of the node that transmitted the arrays. That is, the array database (524) may include a set of arrays associated with a specific node identifier unique to the node that created and propagated these arrays.

[0122] In the examples below, the block authentication service (518) serves to verify the validity of a block announced by one of the other blockchain nodes (504). It listens to arrays communicated by the other blockchain nodes (504) and, if a solution is found, performs functions of compactly storing array data in a manner that enables fast and efficient authentication of the block. A block announcement from one of the other nodes (504) includes block header data and an ordered list of array identifiers that allow the node to determine the block content, if the node has already received arrays corresponding to the array identifiers. A block solution may be referred to herein as a newly resolved block.

[0123] To enable high-volume transaction processing, the node (550) must be able to process incoming array data from other nodes quickly and efficiently, verify its validity, and quickly and accurately authenticate the block when the block solution is announced. To meet these challenges, the block authentication service (518) stores array data in a structure and manner that is ideally horizontally scalable and allows the node (550) to quickly authenticate the block when the solution is announced. In one such solution, the node (550) utilizes a transaction graph datastore (528) to map transaction data and interrelationships to enable verification of topological alignment when the solution is discovered. In another such solution, the node (550) utilizes a set of array transaction databases (530) that, for each array, tracks inputs for the array's transactions from previous blocks or other arrays and outputs from the array's transactions that are not consumed within the array.

[0124] In this example, the blockchain node (550) further includes a cleanup service (530). The cleanup service (530) may be implemented as a standalone service, or in some cases, may be part of the block authentication service (518) or part of the block assembly service (514). The cleanup service (530) is configured to identify which of the authenticated transactions in the current candidate block generated by the block assembly service (514) are included in a block solution received from another node, and, if the block solution is authenticated, to remove these identified transactions so that the block assembly service (514) can build a new block from the remaining authenticated transactions that were not included in the block solution, i.e., unidentified transactions. In some cases, a cleanup list of the remaining unidentified transaction identifiers may be forwarded to the block assembly service (514). In some cases, a database or other memory structure containing a cleanup list of the remaining unidentified transaction identifiers may be made available to the block assembly service (514). In some other cases, the cleanup list of the remaining unidentified transaction identifiers may be forwarded to or made available to other services within the node other than the block assembly service. Examples of other services include a mempool monitoring service or a double-spending detection service.

[0125] In the example below, the cleanup service (530) may rely on performing a comparison between the transaction identifiers within the node's own candidate block and the transaction identifiers within the announced block after the block solution has been announced. In one implementation, this may be performed by using the same RAM used to load the TxIDs of the candidate block and the announced block, so that the comparison can be performed within the same RAM. To improve speed and scalability, in another exemplary solution, the cleanup service (530) may build a candidate datastore separate from the RAM containing the TxIDs of all transactions within the node's own candidate block. During the mining phase, the cleanup service (530) may use the candidate datastore (532) to prepare for a rapid cleanup once the block is authenticated.

[0126] In the first exemplary solution, the cleanup service (530) can identify transactions listed in an array received from another node and can mark corresponding transaction identifiers within the candidate datastore (532) as array identifiers, so that the candidate datastore (532) has a record of which transaction identifiers are included in which arrays. In the second exemplary solution, the cleanup service (530) can alternatively or additionally mark transaction identifiers within the candidate datastore (532) as node identifiers indicating that the transaction identifier is in an array received from that specific node. In both examples, when an announced block is received, while the block authentication service (518) performs authentication of the block, the cleanup service (530) can quickly identify which transactions within the candidate datastore (532) are included in the announced block based on array identifiers and / or node identifiers. This allows the cleanup service (530) to quickly remove or delete the included transactions, leaving only unidentified transaction identifiers in the candidate datastore (532). Alternatively, it can extract unidentified transaction identifiers from the candidate datastore (532). In either case, the cleanup service (530) is configured to provide a list or set of unidentified transaction identifiers to the block assembly service (514) thereby, so that the block assembly service (514) can quickly construct a new candidate block to enable the blockchain node (550) to begin mining the newly added block as soon as possible.

[0127] Cleanup Service

[0128] FIG. 6 illustrates, in the form of a flowchart, an exemplary method (600) for performing transaction cleanup as a result of block announcement. The method (700) can be implemented by a blockchain node. A blockchain node can be implemented using one or more computing devices. In this example, the cleanup service and the block assembly service share the same RAM. Thus, the cleanup service has access to a list of transactions within a candidate block.

[0129] The block assembly service constructs an ordered list (L) of transaction identifiers that constitute the body of a candidate block as part of constructing arrays of transaction identifiers to form a candidate block. The ordered list (L) is stored in RAM. During the mining phase, the block assembly service continues to construct arrays using newly verified transactions because the blockchain node continues to receive a large volume of new transaction flows, potentially one million transactions per second in some examples. Therefore, during the mining phase, the candidate block, e.g., the ordered list (L) of transactions, grows rapidly as new arrays of transaction identifiers are completed and added to the candidate block.

[0130] In operation (602), a node may receive a block solution announcement from another node. In many implementations, the block solution announcement may include some additional information, such as block header data such as a nonce, a Merkle root, and a sorted list of array identifiers specifying the coinbase transaction and the arrays included in the resolved block.

[0131] In operation (604), the cleanup service fetches all transaction identifiers contained in the announced block. In some cases, this can be done by querying the array database for stored arrays that match the array identifiers. The array database contains arrays previously received from other nodes and stores them associated with their unique array identifiers; in particular, it stores an ordered set of TxIDs forming the array along with its own unique array identifier. Based on the received block solution, the cleanup service retrieves the arrays contained in the resolved block and loads them into RAM. In some cases, it can construct a hash table, such as HashMap H, containing transaction identifiers from all retrieved arrays.

[0132] If the network generates approximately 1 million transactions per second, the hash table for resolved blocks can be expected to contain about 600 million transaction identifiers, occupying over 19 GB of memory. In the case of the hash table, that number is likely to be three times higher due to the data structure.

[0133] In operation (606), subsequently, one or more processors can pass through a sorted list (L), that is, the transactions in the node's own candidate blocks, and see if each transaction identifier in the candidate block is in the resolved block. The cleanup service can query a hash table containing transaction identifiers from the resolved block using each of the transaction identifiers in the candidate block. As indicated by operation (608), if a match exists, that is, if the transaction identifier in the candidate block is also in the resolved block (e.g., the TxID from L is in H), in operation (610), the transaction identifier is marked in the sorted list (L) as an identifier for the block. For example, this may be marked as "in_tip_{i}", where i is an index for the announced block (e.g., 0, 1, 2, …). The need for an index is to account for a situation where there may be more than one announced block being evaluated and authenticated by the node. In this case, at some point, the blockchain service will decide which one to accept and which one to attempt to build additional blocks for. Typically, the choice may be based on the first announced block received, but other factors may be considered, for example, when another additional block is added to one of the announced blocks. Additionally, the authentication of one of the announced blocks may fail if, at some point, it is found to violate a validity check.

[0134] Operation (612) reflects an evaluation of whether the block is authenticated and accepted. If it is not yet so, the node continues to evaluate transactions that are in or added to the candidate block, as transactions will continue to arrive during the authentication of the announced block and may be added to new arrays and inserted into the candidate block. In this way, newly integrated transaction identifiers may be added to the sorted list (L), and the hash table needs to be searched to ensure that they are not already in the announced block. In such cases, they are marked as shown above.

[0135] When a block is authenticated and accepted, in operation (614), the node removes all transaction identifiers marked as included in the resolved block from the sorted list (L). The new accepted block may be referred to as tip (j) in the discussion herein. The cleanup service deletes or removes all transaction identifiers from the sorted list (L) marked as "in_tip_{j}", and then instructs the block assembly service to construct new arrays and new candidate blocks using the remaining transaction identifiers in the list (L) as indicated by operation (616).

[0136] The method (600) described above simplifies passing the remaining transaction identifiers by relying on a single RAM that is advantageously shared between the block assembly service and the cleanup service. Although elegantly simple, this technique results in high main memory usage and has limited scalability. It is also primarily performed only after a block solution has been discovered. Therefore, it may be advantageous to adopt other techniques that involve preparing the cleanup before the block solution is announced.

[0137] Now, refer to FIG. 7, which illustrates another exemplary method (700) for performing transaction cleanup as a result of block announcement. In this example, the method (700) utilizes the fact that array data is shared by other nodes prior to block announcement. That is, the nodes have already seen all transaction identifiers listed in their respective arrays and have records of them in the array database. Thus, candidate datastores can be prepared in advance so that the cleanup service can perform cleanup operations quickly without requiring a large main memory footprint after the block solution is announced.

[0138] In this exemplary method (700), the cleanup service manages a candidate datastore that stores the transaction identifiers of all transactions in a candidate block. Whenever new transactions are added to the candidate block, the transaction identifiers are also added to the candidate datastore. For example, operation (702) indicates that one or more transaction identifiers, such as an array of TxIDs, are added to the candidate block constructed by the block assembly service. In operation (704), the cleanup service adds these same transaction identifiers to the candidate datastore. In the examples described herein, the candidate datastore is a separate data structure from the candidate block; however, in some implementations, the candidate datastore and the candidate block are one and identical. That is, the marking of transactions described below may be applied within a database or data structure containing the candidate block without creating a separate candidate datastore. The reference herein to the candidate datastore is to be understood to include both possibilities.

[0139] Operation (706) evaluates whether a new array has been received from another node on the network. As indicated by operation (708), if no block solution has been announced, the node continues to build candidate blocks and build candidate datastores.

[0140] When a new array is received from another node in operation (706), the cleanup service queries the candidate datastore for all transaction identifiers in the array to find a matching transaction identifier in the candidate datastore. Matching transaction identifiers in the candidate datastore are marked as associated with the array. For example, as illustrated in operation (710), transaction identifiers in the candidate datastore may be marked as "in_{array_ID}", where array_ID is the array identifier for the array just received.

[0141] Assuming that each array contains approximately 1 million transaction identifiers and the array is received from each node approximately once per second (based on a volume of approximately 1 million transactions per second), if there are approximately 30 nodes in the network, the cleanup service will perform approximately 30 million read and write accesses per second on the candidate datastore.

[0142] When an array containing transaction identifiers that are not yet in the candidate block and candidate datastore arrives, it is highly likely that the node has not previously received these transactions. The node requests copies of these transactions from other nodes, authenticates them, and adds them to a new array to include them in the node's own candidate block. Transactions can be stored in the candidate datastore along with array identifiers for the array containing the transactions.

[0143] Since all nodes generally operate from a common pool of transactions, you will understand that many identical transactions will be included in arrays different from those of other nodes within the network. Therefore, in many cases, transaction identifiers within a candidate datastore can be marked multiple times as "in_{array_ID}" with different array identifiers. If there are 30 different nodes in the network, transaction identifiers can be marked with up to 30 different array identifiers.

[0144] In operation (708), the node may receive a block announcement from one of the other nodes. As previously mentioned, the block announcement may include a list of array identifiers along with block header data. The array identifiers inform the other nodes which arrays of transaction identifiers constitute the contents of the block. In operation (712), the cleanup service constructs a list of array identifiers from the block. The list may be a hash table, such as a HashMap, or other such data structure. The hash table may be stored in the cleanup service's RAM.

[0145] If one of the arrays in the block solution has not yet been received by a node, in one implementation, the array is requested from another node. When the array is provided, other services within the node may perform functions related to storing the array, but the cleanup service may be configured to simply add the transaction identifiers of the new array directly to the hash table.

[0146] In operation (714), when a hash table is constructed, the cleanup service queries the candidate datastore using array identifiers within the hash table. For each transaction identifier within the candidate datastore marked by the corresponding array identifier, e.g., "in_{array_ID}", the cleanup service also marks the corresponding transaction identifier as "in_tip_{I}", where i is an index indicating a published block. As described above, the index is used to distinguish blocks when there are multiple possible resolved blocks at the same level / height of the blockchain being evaluated and authenticated. If individual transaction identifiers are present in the hash table, the cleanup service searches for a matching identifier in the candidate datastore and marks it as "in_tip_{i}".

[0147] When a block is accepted by the block verification service, operation (716) is performed. That is, it is determined to be valid and added to the blockchain. As mentioned above, such a block may be referred to as tip (j) in the discussion herein. In this case, the cleanup service then identifies all transaction identifiers not marked as "in_tip_{j}" in the candidate datastore and transmits them to the block assembly service so that the block assembly service can begin constructing new arrays and new candidate blocks. Any transactions labeled as "in_tip_{j}" are deleted or removed from the candidate datastore. In some cases, all transactions are removed from the candidate datastore, and the transactions transmitted to the block assembly service are added back to the candidate datastore when they are placed in the candidate block. In some other cases, the remaining transactions are left in the candidate datastore according to the understanding that the block assembly service will immediately add them to the new candidate block being constructed. In this situation, the marking of these transactions as being in specific arrays may be removed.

[0148] In some examples, the cleanup service may expose or provide access to a candidate datastore containing the remaining transactions so that the block assembly service can read them from the candidate datastore. In some cases, the remaining transactions may be transmitted to or provided in other ways to other services within the node, such as a mempool monitoring service and / or a double-spending detection service.

[0149] Advantageously, this solution entails much smaller RAM usage requirements because, instead of loading millions of transaction identifiers into an in-memory hash table for each array, a single array identifier is loaded into the hash table. When all arrays are received, this may contain only about 600 array identifiers that can be stored in a few kilobytes.

[0150] A potential drawback of this solution is that, in order for the block assembly service to begin constructing a new candidate block, the remaining transaction identifiers not marked with “in_tip_{j}” need to be communicated by the cleanup service from the candidate datastore to the block assembly service. If this involves a large number of transactions, this can represent significant communication overhead; however, since all nodes on the network operate with a mostly common set of transactions, it is expected that the block solution will tend to include most of the currently unconfirmed transactions, and consequently, the number of transactions remaining in the candidate database that were not included in the block solution will be relatively small.

[0151] The process described above involves marking transaction identifiers as array identifiers so that the cleanup service can quickly identify transactions confirmed in a resolved block based on the array identifiers constituting the block. In this way, rather than loading all transaction identifiers from the resolved block into a hash table and searching for matches within the candidate datastore, the cleanup service only needs to load the array identifiers into the hash table and search for transaction identifiers within the candidate datastore that are already marked as being associated with or included in these array identifiers.

[0152] For the most likely cases, it may be possible to further improve speed and reduce the RAM footprint. In many situations, the resolved block contains a set of all array identifiers previously advertised to the network by a successful node. All other nodes would have seen and stored these previously advertised arrays. As long as a node can identify the node transmitting specific arrays, the node can also tag or mark the transaction identifiers included in those arrays as being within the array "from that node." In other words, if an array from a specific node contains transaction identifiers, the matching transaction identifiers within the candidate datastore are marked as "in _{array_ID}" using the array identifier and additionally marked as "received_from_{node_ID}" using the node identifier. The node identifier can be a unique identifier for that node, such as a registered miner identifier, domain name, IP address, etc.

[0153] Now, refer to FIG. 8, which illustrates an additional exemplary method (800) for cleaning up transactions after the block solution has been announced, in the form of a flowchart.

[0154] The cleanup service constructs a candidate datastore that stores the transaction identifiers of all transactions in the candidate block. As indicated in operations (802 and 804), whenever new transactions are added to the candidate block, the transaction identifiers are also added to the candidate datastore. Specifically, operation (802) indicates that one or more transaction identifiers, such as an array of TxIDs, are added to the candidate block constructed by the block assembly service. In operation (804), the cleanup service adds these same transaction identifiers to the candidate database. Operation (806) indicates an evaluation of whether a new array has been received from another node on the network. As indicated by operation (808), if the block solution is not announced, the node continues to construct the candidate block and the candidate datastore in operations (802 and 804). Even if the block solution is announced, the node will know that it can continue to construct the candidate block and the candidate datastore in parallel while evaluating the solution, while performing block authentication operations and cleanup preparations.

[0155] When a new array is received from another node in operation (806), the cleanup service queries the candidate datastore for all transaction identifiers in the array to find a matching transaction identifier in the candidate datastore. Subsequently, in operation (810), the matching transaction identifiers in the candidate datastore are marked as associated with the array and as associated with the node. For example, a transaction identifier in the candidate datastore may be marked as "in_{array_ID}", where array_ID is the array identifier for the array just received, and may also be marked as "received_from_{node_ID}", where node_ID is the unique node identifier for the node that propagated its array over the network.

[0156] In operation (808), the node may determine that a block announcement has been received from one of the other nodes. As previously mentioned, the block announcement may include a list of array identifiers along with block header data. The array identifiers inform all nodes which arrays of transaction identifiers constitute the contents of the block. In this case, the node knows that the block solution was received from a specific other node having a unique node identifier. A message conveying block solution details may include a node identifier.

[0157] A common and possible scenario is that a block solution from a specific node is based on all arrays that the specific node has already communicated. This can enable a rapid cleanup operation. Thus, in operation (812), the node determines whether a block solution listing array identifiers included in the block includes all arrays transmitted by the specific node. If none of the announced arrays are missing from the solution, in operation (814), the cleanup service may query the candidate datastore for transaction identifiers marked as "received_from_node_ID" using the node identifier, i.e., the node_ID of the specific node, and then mark all of these transaction identifiers in the candidate datastore as "in_tip_{i}" to indicate that they are in the resolved block designated as index i.

[0158] The node can evaluate whether there are any additional arrays in the solution in addition to all arrays already visible from a specific node, as indicated by operation (816) from the block solution. If not, the cleanup service does not need to take additional action to mark transaction identifiers, because all included transaction identifiers will now be marked as "in_tip_{i}" in the candidate datastore.

[0159] If additional arrays that have not previously been received by the node are included, the node may request and receive details of the array contents, namely, an ordered list of transaction identifiers included in the array. Then, in operation (818), the node may perform the operation of creating a hash table in RAM, loading transaction identifiers from the new array, and querying the candidate datastore for matching transaction identifiers. As in the methods (600) and (700) described above, any matching identifiers are marked as "in_tip_{i}".

[0160] The aforementioned operations are based on a resolved block from another node containing all arrays previously advertised by the other node on the network. However, in operation (812), if the node decides that the block solution will omit one of the previously advertised arrays from the resolved block, the node cannot simply mark all transaction identifiers from that other node as included in the block. In this situation where one or more of the arrays are excluded from the block solution, method (800) returns to the process described in relation to FIG. 7. That is, in operation (820), it constructs a list of array identifiers from the resolved block. The list may be a hash table, such as a HashMap, or other such data structure. The hash table may be stored in the RAM of the cleanup service.

[0161] In operation (822), when a hash table is constructed, the cleanup service queries the candidate datastores using array identifiers within the hash table. For each transaction identifier within the candidate datastore marked with the corresponding array identifier, e.g., "in_{array_ID}", the cleanup service also marks the corresponding transaction identifier as "in_tip_{I}", where i is an index indicating an announced block. As indicated by operations (816 and 818), the cleanup service can also determine whether a new array that has not previously been received is included in the block, and if so, the cleanup service can add these transaction identifiers to the hash table and mark the corresponding transaction identifiers within the candidate datastores as "in_tip_{i}".

[0162] Regardless of whether the cleanup service could rely on the node identifier, if the block is accepted by the blockchain service, operation (824) is performed, which means that the block is determined to be valid and added to the blockchain. As mentioned above, such a block may be referenced as a tip (j). In this case, the cleanup service then identifies all transaction identifiers not marked as "in_tip_{j}" in the candidate datastore and sends them to the block assembly service so that the block assembly service can begin constructing new arrays and new candidate blocks. Any transactions labeled as "in_tip_{j}" are deleted or removed from the candidate datastore. In some cases, all transactions are removed from the candidate datastore, and the transactions sent to the block assembly service are added back to the candidate datastore when they are placed in the candidate block. In some other cases, the remaining transactions are left in the candidate datastore based on the understanding that the block assembly service will immediately add them to the new candidate block being constructed. In this situation, the marking of these transactions as being in specific arrays may be removed.

[0163] In one alternative implementation, to reduce the load on candidate datastores, the cleanup service can set up candidate datastores for each other node in the network. That is, the candidate datastores are replicated as many times as there are nodes in the network. It should be noted that this entails greater data storage consumption because the same datastore is replicated for each of the other nodes. Whenever new transaction identifiers are added to a candidate block, all candidate datastores need to be updated to add these identical transaction identifiers; however, when an array is received from a specific node, only the candidate datastore for that node is updated to mark the transaction identifiers that match the array identifier. Furthermore, since all marked transaction identifiers within that datastore are associated with a specific node, there is no need to mark these transaction identifiers as associated with that specific node.

[0164] Many of the methods described above may be implemented using one or more computing devices, each having one or more processing units, memory, and communication subsystems. Suitable software stored in memory and executable by one or more processing units may configure the processing units to perform the described functions or operations. In some cases, a microservices architecture may be used to implement some or all of the methods. While the operations described below are set in a linear format, it will be noted that some implementations may at least partially parallelize some of the operations and / or perform them in a different order without substantially affecting the operation of the methods.

[0165] The various embodiments presented above are merely examples and are by no means intended to limit the scope of this application. Variations of the innovations described herein will be apparent to those skilled in the art and are within the intended scope of this application. In particular, features from one or more of the exemplary embodiments described above may be selected to produce alternative exemplary embodiments comprising subcombinations of features that may not be explicitly described above. Additionally, features from one or more of the exemplary embodiments described above may be selected and combined to produce alternative exemplary embodiments comprising combinations of features that may not be explicitly described above. Features suitable for such combinations and subcombinations will be readily apparent to those skilled in the art upon reviewing the entire application. The invention described herein and in the claims cited is intended to cover and encompass all appropriate modifications in the art.

Claims

Claim 1 In a computer implementation method for processing blockchain transactions by nodes, during the mining phase, A step of constructing a candidate datastore containing transaction identifiers for each validated transaction within a candidate block; A step of receiving two or more arrays from another node, each array containing an individual set of transaction identifiers; Identifying transaction identifiers in the candidate datastore that match transaction identifiers in one of the two or more arrays, and recording the array identifier of one of the two or more arrays for each matching transaction identifier in the candidate datastore; during the block authentication phase, after receiving a block solution identifying a plurality of arrays from the other node, A step of identifying each transaction identifier in the candidate datastore having a recorded array identifier that matches one of the arrays in the plurality of arrays, and marking the transaction identifier as being in the block solution; and A computer implementation method for processing blockchain transactions by a node, comprising the step of, after the block solution is authenticated, identifying all transaction identifiers in the candidate datastore that are not marked as being in the block solution, and making the transaction identifiers available to other services within the node. Claim 2 A computer implementation method for processing blockchain transactions by a node, wherein, in claim 1, the step of identifying each transaction identifier in the candidate datastore having a recorded array identifier that matches one of the arrays in the plurality of arrays comprises the step of constructing a list of array identifiers from the block solution in memory. Claim 3 A computer implementation method for processing blockchain transactions by a node, wherein, in paragraph 2, the step of constructing a list of array identifiers includes the step of constructing a hash table filled with array identifiers from the block solution. Claim 4 A computer implementation method for processing blockchain transactions by a node, wherein, in paragraph 3, the step of marking the transaction identifier as being in the block solution comprises, for each array identifier in the hash table, the step of searching the candidate datastore to identify transaction identifiers marked by the corresponding array identifier, and the step of marking the transaction identifiers as being in the block solution. Claim 5 A computer implementation method for processing blockchain transactions by a node, wherein, in any one of claims 1 to 4, the step of marking transaction identifiers as being in the block solution comprises the step of marking the transaction identifiers as being in tip i, wherein i is an index for the block solution among a plurality of announced block solutions. Claim 6 A computer implementation method for processing blockchain transactions by a node, wherein, in any one of claims 1 to 5, the step of identifying all transaction identifiers in the candidate datastore that are not marked as being in the block solution includes the step of deleting all transaction identifiers marked as being in the block solution from the candidate datastore. Claim 7 A computer implementation method for processing blockchain transactions by a node, wherein, in claim 6, the step of making the transaction identifiers available includes the step of copying and transmitting all remaining transaction identifiers from the candidate datastore to the other service. Claim 8 A computer implementation method for processing blockchain transactions by a node, wherein, in any one of claims 1 to 7, the block solution comprises a new array that has not previously been received from the other node, and the method further comprises: a step of obtaining a set of transaction identifiers included in the new array and loading the obtained set of transaction identifiers into memory; and a step of querying the candidate datastore for a match for each transaction identifier in the set, and if the match is found, marking the corresponding transaction identifier in the candidate datastore as being in the block solution. Claim 9 A computer implementation method for processing blockchain transactions by a node, wherein, in paragraph 8, the new array that was not previously received is the array that was not received during the mining phase. Claim 10 A computer implementation method for processing blockchain transactions by a node, wherein, in any one of claims 1 to 9, the step of constructing the candidate datastore and constructing the candidate block containing the authenticated transactions. Claim 11 A computer implementation method for processing blockchain transactions by a node, wherein, in any one of claims 1 to 10, the step of making the transaction identifiers available to another service includes the step of forwarding the transaction identifiers to at least a block assembly service to construct a new candidate block. Claim 12 A computer implementation method for processing blockchain transactions by a node, wherein, in any one of claims 1 to 10, the step of making the transaction identifiers available includes the step of notifying the other service that the candidate database is available for access and that the candidate database includes all transaction identifiers that are not marked as being in the block solution. Claim 13 A computer implementation method for processing blockchain transactions by a node, wherein, in any one of claims 1 to 10, the other service includes a mempool monitoring service or a double-spending detection service. Claim 14 A computing device comprising: one or more processors; memory; and computer-executable instructions stored in the memory, which, when executed by the one or more processors, cause the processor to perform a method described in any one of claims 1 to 13. Claim 15 A computer-readable medium storing processor-executable instructions, wherein the processor-executable instructions include instructions that, when executed by one or more processors, cause the processor to perform the method described in any one of claims 1 to 14.

Images