Method and system for distributed blockchain functionality

Abstract

The present disclosure provides a method and system for identifying and / or allocating processing and / or storage resources using a portion of data derived from a blockchain. The data from which the portion of data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) including unspent transaction outputs. By allocating resources using the portion of data, a relationship between the data, its associated information, and the resource in which it is stored is maintained. The database may hold at least one of a validity flag of the unspent transaction outputs (UTXOs) and / or transactions (Tx) including unspent transaction outputs, and information that allows the validity of the unspent transaction outputs and / or transactions (Tx) including unspent transaction outputs to be determined, e.g., SPV information. Processing the data includes determining a key, where the key determines the allocated resources. The key may be hashed, where the resulting hash determines the allocated resources. At least one of the data, the key, and the resulting hash includes at least one of alphanumeric and binary numbers, where the number is used to determine the allocated resources. The portion of the number is parsed to determine the allocated resources.

Description

[Technical field]

[0001] The present disclosure generally relates to improved methods and systems for processing and / or managing data records and / or implementing distributed networks. The present disclosure is particularly suited for use with transactions accomplished through or using a blockchain network, such as, but not limited to, determined storage allocation, pre- and / or post-mining validation of blockchain transactions, SPV checks, etc. Benefits include, but are not limited to, improved security and resilience, improved efficiency or reduced speed and resource requirements, novel approaches to resource validation and balancing not possible in prior art configurations, resulting in blockchain implementation configurations not previously possible. [Background technology]

[0002] Although the Bitcoin protocol and network may be referenced herein for purposes of providing an example context for implementation, the present disclosure is not limited to use with the Bitcoin blockchain, and alternative protocols and implementations (including those involving account-based and proof-of-stake consensus) are within its scope. Hereinafter, the term "UTXO" may be used merely for convenience to refer to transaction outputs, and should not be interpreted as meaning that embodiments of the present disclosure are limited to use with UTXO-based blockchain models.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and those blocks are chained together to create a permanent, immutable record of all transactions that have been written to the blockchain since inception.

[0004] In order for a transaction (Tx) to be written to the blockchain, it must be "validated." Network nodes (miners) perform the work of ensuring that each transaction is valid, and invalid transactions are rejected from the network. In some protocols, a software client installed on the node performs this validation work on the unspent transaction output (UTXO) by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, i.e., propagated; ii) be added to a new block constructed by miners; and iii) be mined, i.e., added to the public ledger of past transactions. Once a transaction is stored in the blockchain as a UTXO, the user can transfer control of the associated cryptocurrency to another address associated with an input in another transaction that is later written to the blockchain. This is often done using a digital wallet that stores a public / private key pair associated with a user's cryptocurrency. There are various forms of known cryptocurrency wallets, including Simplified Payment Verification (SPV) wallets. SPV techniques allow users and merchant nodes to perform local verification based on only partial information related to a particular transfer. SPV is described in more detail below.

[0005] However, the volume of transactions is known to be growing, requiring an improved ability to quickly determine the validity of unspent transaction outputs (UTXOs). Current techniques for the validation task can require significant resources and time due to the need to download and store blocks, maintain large UTXO pools, and perform the processing tasks required for validation. Many users are either unable to meet such requirements, or in some cases do not need to and would prefer not to meet them. Thus, a faster and more efficient validation model is needed that addresses at least these challenges (and others) without compromising security or requiring adaptation of existing protocols. Moreover, the means of validation must be scalable. Such an improved solution has now been devised. Summary of the Invention

[0006] Embodiments of the present disclosure provide improved blockchain-related methods, devices, and systems. According to one form of expression, such embodiments provide a solution for identifying and / or allocating processing and / or storage of data associated with UTXOs that include and / or enable validation. The allocation and / or identification is based on a portion of data derived from the blockchain, e.g., the portion of the derived data includes unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs.

[0007] Embodiments of the present disclosure provide improved blockchain-related methods, devices, and systems. According to one form of expression, such embodiments provide a solution for assigning the task of storing information associated with a UTXO that includes and / or enables validation. Following assignment, at least a portion of the information, e.g., the UTXO and / or transaction (Tx), can be stored in one or more of a plurality of distributable resources.

[0008] Additionally or alternatively, resources may be accessed to (i) verify the validity of the UTXO and / or associated transactions and / or (ii) retrieve data that allows the validity of the UTXO and / or associated transactions to be determined.

[0009] In additional or alternative phrases, embodiments provide secure solutions for controlling, managing and / or enhancing the efficiency, resource requirements, speed and / or resilience of known approaches to processing blockchain transactions. Embodiments also enable scalability of blockchain-implemented solutions and provide improved methods and technical architectures for the electronic transfer of digital resources.

[0010] The embodiments of the present disclosure may be implemented in part or in whole by a variety of devices. These may be hardware and / or software-based devices, including (but not limited to) one or more virtual machines, servers, GPU-based computing resources, or multi-processor systems. Additionally or alternatively, the embodiments may include one or more digital wallets. Importantly, however, the embodiments provide a mechanism for distributed processing of blockchain-related validation tasks. Coordination, management, and control of distributed processes are known to be inherently technical in nature, as they require a holistic understanding of the interactions between the hardware and software components involved, and the implementation of such distributed solutions extends beyond the technically trivial.

[0011] Embodiments may have solutions that enable or facilitate efficient identification and / or allocation of resources, which at least one of store and validate information associated with each UTXO and / or transaction. Embodiments support scaling of the systems and methods described herein by balancing the distribution of information across resources. This can balance not only the distribution of information across resources, but also the utilization, e.g., accessibility of information by users, and can mitigate bottlenecks.

[0012] Embodiments may include distribution of validation tasks across multiple processing resources, which for convenience are referred to as "validators." A validator may include a single processing resource, or may include multiple related processing resources that can be collectively considered as a validation resource.

[0013] In one example, when a block of transactions needs to be validated and / or downloaded, its Merkle tree may be decomposed into one or more smaller segments, each segment having its own root and containing a tree structure that represents a subset of the transactions in the block. These segments can then be assigned to different validators. Each validator operates to perform the necessary processing tasks on the subset of transactions assigned to it.

[0014] The assignment of tree segments to validators can be performed in a variety of ways, but according to one advantageous embodiment, a binary indexing system may be used that uses the leading digit of a randomly generated, double-hashed Merkle root to assign a given segment to a validator (or group / cluster of validators) with a matching binary identifier, providing a simple, efficient and fast mechanism for load balancing across multiple validators.

[0015] The allocation for processing and / or storing information associated with a UTXO may be implemented based in part on data derived from the blockchain. Using this data, resources are allocated and / or identified for processing and / or storing the UTXO information. The method used for identification / allocation supports an even distribution and / or scalability of information across multiple resources, since it is based on pseudo-random data obtained from the blockchain. When information about a UTXO is needed, the resource may be accessed to retrieve at least one of: (i) a confirmation of the validity of the UTXO and / or associated transactions, (ii) data that allows the validity of the UTXO and / or associated transactions to be determined, and (iii) an indication and / or proof of the validation performed by the resource or validator.

[0016] In one or more embodiments, a validator may include or have access to a repository that records data about the work it has performed and / or the data it has processed. In one embodiment, this may include a database that contains unspent transaction outputs (UTXOs) that have been assigned to a given validator for processing. Recall that in the traditional model, all UTXOs on a blockchain are tracked by nodes in a database called a UTXO pool.

[0017] Each full node has its own full copy of the UTXO pool for the blockchain. In accordance with the present disclosure, (i) each validator may have its own UTXO pool that tracks the UTXOs of transactions assigned to it for validation, and / or (ii) a system such as a node may allocate resources to process and / or store information based on a portion of data derived from the blockchain, e.g., data derived from the transactions and / or UTXOs, that provides an indication of the validity of the UTXO and / or allows validity to be determined, e.g., using SPV techniques.

[0018] Advantages of such a decentralized UTXO storage method, identification and allocation of resources, e.g., pools, include, but are not limited to, scalability, guaranteed data integrity, increased speed and efficiency, and incorporation and support for various validation techniques such as SPV. [Brief description of the drawings]

[0019] To aid in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] 1 provides an illustration of a typical Merkle tree structure known in the art. [Figure 4] We show how a Merkle root can be derived from a set of blockchain transactions, as known in the art. [Diagram 5] We provide an example, according to one embodiment of the present disclosure, of how a Merkle tree can be divided into subsets (or "segments"), which can then be assigned to respective validation resources. [Figure 6] FIG. 5 shows an alternative example of how a Merkle tree may be divided into logical segments. [Figure 7] 1 illustrates a system level view of a distributed validation node according to an exemplary embodiment of the present disclosure. [Figure 8] 1 is a flow chart outlining the steps involved in an exemplary method of the present disclosure. [Figure 9] FIG. 8 illustrates the example system of FIG. 7 in greater detail. [Figure 10] FIG. 1 is a schematic diagram of one example of the present invention including the identification and / or allocation of resources to generate, store or maintain a database of information associated with unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs. [Figure 11] 11(a) through 11(d) are tables illustrating example values ​​derived from portions of the data used to identify and determine allocated resources. [Figure 12] 1 is a schematic diagram of a system including nodes, intermediate switches, and allocated resources, said resources having optional validators. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] Exemplary embodiments of the present disclosure will now be described, by way of example and not limitation, with reference to the accompanying drawings.

[0021] The means for processing and / or storing information about unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs may be implemented using different systems and methods that may be configured and / or executed separately. Below, examples of a "UTXO database" and a "block validation" are described, each of which assigns a task to a resource, e.g., a distributed resource, where the task includes storing and / or validating one or more transactions. Features of the examples may be combined in light of the teachings herein.

[0022] UTXO Database 10-12 respectively show steps of the method where data is derived from the blockchain, tables used for allocation to resources 1104, and a diagram of a system for implementing the method. Data is obtained from the peer-to-peer (P2P) network 106 and / or the blockchain 150. In s1000, data can be obtained or retrieved, for example, by requesting and retrieving one or more blocks from the blockchain 150. Retrieving can include downloading at least a portion of a blockchain block containing multiple blockchain transactions. Retrieving or otherwise obtaining data, for example, retrieving, copying or reading data from a blockchain block, is required when data is needed to establish, store and / or process transaction data related to unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs, already stored in history, for example in block 151. UTXOs currently in the mempool or future transactions and UTXOs can be received via a connection to the network, for example, by implementing node 104 to receive transactions broadcast on the network.

[0023] Thus, in general, the system 1100 of FIG. 12 uses a portion of data derived from the blockchain to determine a key and allocate a corresponding resource that stores information associated with said data, e.g., information associated with unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs. For clarity, information associated with data derived from the blockchain is stored in a resource for efficient and cost-effective reference. The data may include unspent transaction outputs (e.g., UTXOs according to the Bitcoin protocol) and / or transactions (Tx) that include unspent transaction outputs (for convenience, referred to as UTXOs). The portion of the data is used to determine a key, and the key determines an allocated resource that stores information about said data. The data from which the portion of the data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs. In s1002, the portion of the data is used to identify or allocate a corresponding resource 1104, e.g., an allocated resource. In s1004, resource 1104 operates to at least one of generate, store, and maintain a database of information, the information including data associated with UTXOs and / or transactions. The information may include an indication of the validity of the UTXO and / or enabling the validity to be determined, e.g., using SPV techniques. The information about the data may include, by way of example, details of the block from which it was obtained, e.g., the block ID, the Merkle path of the unspent transaction output (UTXO) and / or the transaction (Tx) that includes the UTXO, the validity status of all UTXOs in the transaction.

[0024] Resources 1104 may operate to validate UTXOs and / or process data to store information that can be used by others to generate indications, such as flags indicating validity. Additionally or alternatively, resources 1104 may delegate the determination of the validity of a transaction or UTXO in s1006 to a validator 1106. Storing and / or processing at least a portion of the UTXOs and / or transactions (Tx) may be performed in the assigned resource (e.g., the resource 1104 actively manages the information and maintains a database associated with each UTXO therein, e.g., the resource may be self-managing), and / or by the assigned resource (e.g., the resource acts as a controller and functions as the system 1100 managing sub-resources that store and / or process the information), and / or in association with the assigned resource (e.g., the resource 1104 operates as part of the system 1100 as shown in FIG. 12, where, as a non-limiting example, the node 104 provides the transaction and UTXO information to a switch 1102, e.g., a router, that operates to determine which of the multiple resources 1104 is assigned the task of generating, holding and / or storing the UTXO information in the database). Collectively, the resources may implement and perform one or more of the operations of FIG. 10. FIG. 12 illustrates a system 1100 having components for individually performing the operations of FIG. 10. In some embodiments, the switch 1102 operates to transmit and / or receive (IPv6) multicast transmissions.

[0025] In one example, the task of maintaining information associated with a UTXO is assigned to one resource from a group of resources in the system 1100. FIG. 12 shows, by way of example, eight resources, each of which shares information from a UTXO among themselves. However, the system can maintain any number of resources and is scalable. For example, the system can have 16, 256, or 1024 resources. Each resource is thus assigned a range of UTXOs to process, store, and / or maintain.

[0026] A portion of data from an unspent transaction output (UTXO) and / or a transaction (Tx) containing a UTXO may be retrieved and / or received and parsed. The parsing determines which resource is assigned the task of storing the information. The parsing may be performed by the resource 1104 or the switch 1102. At least one of the node 104, the switch 1102, and the resource 1104 may derive the portion of data from the blockchain. When the parsing is performed by the node 104 or the switch 1102, the information is directed to the assigned resource. The identification and / or assignment to processing and / or storage resources may be performed by the node and / or the switch acting as an intermediary. They are connected to multiple assigned resources, and said node or switch acts as a manager of many resources 1104 that determines which resource looks after which UTXO / Tx. Once the parsing is performed by resource 1104, it may process the data and / or store information derived from the data, store data associated with the data, or take no action if it is not responsible for the UTXO.

[0027] When the allocation of resources 1104 is determined, e.g., when it is determined where information associated with a UTXO / Tx is kept, resources 1104 may perform the operations of s1004 to generate, store, and / or maintain information associated with unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs. Resources 1104 may process the received data to determine the validity of the UTXOs / Tx, e.g., s1006, or delegate that task to a validator 1106. Resources 1104 and / or validator 1106 may at least partially validate the unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs.

[0028] The data is obtained from the peer-to-peer (P2P) network 106 and / or the blockchain 150. The data is obtained by the node 104 and / or the switch 1102, which assigns the data to a resource, or the data can be obtained by the resource 1104 itself, which searches and parses the data according to the assigned UTXO / Tx range. The obtained data may include at least one of the following: a UTXO identifier, a hash of the UTXO script, and a transaction identification (TXID).

[0029] The obtained data serves to provide a key that identifies and / or assigns resources associated with a UTXO or a transaction having a UTXO and for which corresponding information is stored, maintained or generated. The key is determined directly by using a portion of the data (e.g., the key determines the assigned resource) or indirectly by processing, e.g., hashing, a portion of the data such that the resulting hash determines the assigned resource.

[0030] The key is used to determine which resource 1104 holds the corresponding information associated with the key. The resource thus holds a data structure, e.g., a database or hash table, that implements the associative array. In other words, data associated with the UTXO and / or transaction is used to determine a key, and said key is used to determine a resource that holds the information associated with the UTXO and / or transaction. Not only do the data and the key allow resources to be assigned, but the stored information can also be retrieved by looking up and accessing said information using the key.

[0031] At least one of the data, the key, and the resulting hash includes at least one of an alphanumeric and a binary number, which is used to determine the allocated resources.

[0032] By way of example, the piece of data may include unspent transaction outputs (UTXOs) and / or transactions (Tx) that contain UTXOs. Inputs to a transaction may include a transaction ID that references the transaction that contains the UTXO being spent, an output index, e.g., Vout, that identifies which UTXO is referenced for that transaction, a scriptSig that satisfies the conditions imposed on the UTXO for unlocking, and a sequence number.

[0033] Potential recipients of a UTXO need to validate the UTXO before a transaction that uses said UTXO can be compiled and broadcast. Known techniques for validation are time-consuming, resource-heavy, and computationally expensive. By using a portion of the data from the UTXO and / or related transactions, the UTXO can be validated or information that enables the validation of the UTXO can be stored in a resource. A portion of the data unique to the UTXO can be used to determine a key, which then determines in which assigned resource the related information can be stored and later retrieved from there.

[0034] Using transaction identification information (TxID) as a non-limiting example, the TxID is commonly referred to in hexadecimal format and can also be represented as a binary number. Figures 11(a)-(d) are tables illustrating how a portion of data can be used to determine the allocated resources. The portion of data, e.g., the TxID, can be directly parsed or processed, e.g., hashed. In Figure 11(a), the TxID is parsed such that the first three digits of the binary form of the TxID are selected as a key, and the resources allocated according to the binary value, e.g., information associated with a TxID having a binary number with the first three digits "101" is assigned for storage / processing in allocated resource "6". Using the first three binary digits can determine one of eight resources, while Figure 11(c) shows how to take the first four digits of the binary form of the TxID to support allocation among 16 resources, e.g., information associated with a TxID beginning with a binary number with the first four digits "1011" is assigned for storage / processing in allocated resource "12". Alternatively, hexadecimal values ​​for the TxID can be used, as shown in FIG. 11(b) where a single hexadecimal value is mapped to a resource, e.g., "c" is mapped to "13", and in FIG. 11(d) where a range of hexadecimal values ​​are assigned to resources, e.g., information associated with a TxID starting with "76" is assigned to resource "8".

[0035] Alternatively, a portion of the data can be processed, e.g., hashed, to generate a hexadecimal or binary number, and thus the subsequent determination of the portion of the data and the key to identify / allocate the resource 1104 is not limited to the TxID.

[0036] The portion of data selected from a transaction or its UTXO, or the processed value, e.g., hash value, is pseudo-random. The allocation to resources is load balanced, i.e., the portion of data used to determine the key for allocating resources is pseudo-random, distributing processing and / or storage among multiple resources. As a result, information associated with a transaction / UTXO is distributed across multiple resources. The balancing of allocation among resources minimizes the risk that some processing resources are idle while others are overloaded, and thus the risk of performance degradation or even failure. The resilience, performance and / or efficiency of the system 1100 is improved.

[0037] Thus, the data, and portions of the data, can be used to (i) determine allocated resources and thereafter (ii) provide references to identify the resources and / or information associated with the data within the resources, e.g., in a database.

[0038] As a result, a portion of the data is derived from the blockchain to determine keys and corresponding resources that store information associated with said data, i.e. unspent transaction outputs (UTXOs) and / or information associated with transactions (Tx) that contain UTXOs.

[0039] An actor seeking to verify the validity of a UTXO may use a portion of the UTXO and / or the transaction holding said UTXO to identify a resource that holds information that can be used to determine the validity of the UTXO and / or transaction. This information may include a flag or marker associated with the UTXO, indicating whether the UTXO is locked or unlocked, e.g., invalid or valid, e.g., suitable for inclusion in a subsequent transaction. The information may additionally or alternatively include a record of the UTXO and / or the transaction holding said UTXO that allows the actor to efficiently and independently validate the UTXO.

[0040] The record may include, at least in part, at least one of a Merkle tree of the block in which the transaction (Tx) is recorded, a Merkle root of the block in which the transaction (Tx) is recorded, a Merkle path that enables determining, from a hash of the transaction (Tx), a value of the Merkle root for the block in which the transaction (Tx) is recorded, a Merkle proof, a block identifier (block_ID) associated with the blockchain block, a transaction identifier (TxID) associated with the transaction (Tx) among a plurality of blockchain transactions in the blockchain block, a function of the block identifier (block_ID) and the transaction identifier (TxID), and a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0041] The resource may include information and records required to determine the validity of the UTXO. Additionally or alternatively, the resource may validate the UTXO and / or generate records supporting the validation of the UTXO, either by itself or via validation s1006 by a validator 1106. The resource 1104 and / or the validator 1106 may at least one of: validate and / or verify the UTXO, perform at least a portion of a simplified payment verification (SPV) process on the UTXO, verify whether a given blockchain transaction (Tx) is included within a blockchain block, generate a hash of at least one of the blockchain transactions and use the hash to construct a Merkle path and / or check whether the hash matches a transaction identifier (TxID) in the header of the blockchain block, and determine a Merkle proof for the UTXO.

[0042] By providing a means to identify allocated resources 1104 from a UTXO / transaction and store the information needed to validate the UTXO in said resources, an efficient and scalable alternative method for validating UTXOs is provided. Nodes no longer need to keep a full copy of the blockchain, and no additional information is required to support transactions, e.g., SPV-based exchanges and wallets, and the system 1100 and resources 1104 therein provide fast and scalable support.

[0043] Generally, the system 1100 includes a resource 1104 that operates to provide a UTXO repository for generating, storing, and / or maintaining information and / or records associated with a plurality of unspent transaction outputs (UTXOs) associated with transactions (Tx) respectively in a plurality of blockchain transactions (TX) of a blockchain block. The resource may record, retrieve, and / or process the information and / or records by identifying and / or allocating said resource using a portion of data derived from the blockchain, said data from which the portion of the data is derived including the unspent transaction outputs (UTXOs) and / or transactions (Tx) including the UTXOs.

[0044] The system 1100 may include nodes 104 and / or switches 1102 for receiving and / or processing unspent transaction outputs (UTXOs) for inclusion in a transaction. The nodes and / or switches may support resources and determine allocation to one of a plurality of resources. The allocated resource then maintains validation data, e.g., information and / or records about the UTXO.

[0045] For example, after receiving a UTXO for inclusion in a transaction as part of a payment or transfer of a digital asset, validation information and / or records may be requested and / or obtained by an actor from its allocated resources.

[0046] Once an actor has access to information and / or records from an assigned resource, the actor may at least one of: validate the UTXO and / or the transaction (Tx) including said UTXO, and / or determine the validity of the UTXO and / or the transaction (Tx) including said UTXO. Validation by at least one of the resource 1104, the validator 1106, and the actor may include: ii) validating and / or verifying at least one blockchain transaction, and / or ii) performing a simplified payment verification (SPV) process, and / or iii) verifying whether a given blockchain transaction (Tx) is included within a blockchain block, and / or iii) generating a hash of at least one of the blockchain transactions, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block.

[0047] Then, following validation of the UTXO, that actor or a further actor may prepare and / or submit a transaction (Tx) having that UTXO as input.

[0048] A node 104 may be configured to at least one of generate, store, and maintain UTXO resources for recording, retrieving, and / or processing a plurality of unspent transaction outputs (UTXOs), and the node processes a portion of data derived from the blockchain to identify and / or allocate processing and / or storage resources. The data from which the portion of data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs.

[0049] Block Validation Traditionally, nodes in a blockchain network maintain a global ledger of all transactions on the blockchain. The global ledger is a distributed ledger, and each node may store a full or partial copy of the global ledger. Transactions by nodes that affect the global ledger are verified by other nodes to ensure that the validity and integrity of the global ledger is maintained. The details of implementing and operating a blockchain network, such as one that uses the Bitcoin protocol, will be understood by those skilled in the art.

[0050] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify who can access the transaction's output and how. A transaction's output may be an address to which control of a value is transferred as a result of the transaction. That value is then associated with that output address as an unspent transaction output (UTXO). Subsequent transactions may then reference that address as an input to gain control or ownership of that value.

[0051] Using the Bitcoin network and protocol as an example, as described above, mining nodes compete to create the next block in the blockchain. To assemble a block, a miner constructs the block as a set of transactions from a pool of unconfirmed transactions ("mempool"). The miner then attempts to complete a Proof-of-Work (PoW) puzzle on the block it assembled. If a miner manages to complete a PoW before receiving notification that other miners have successfully generated their block and completed their PoW, it propagates by sending its block to peer nodes on the network. Those nodes validate the block and then send it further in the network to other nodes. If a miner receives notification that another block has been completed before it has finished its PoW, it abandons its efforts and begins attempting to construct the next block.

[0052] Thus, fast propagation of blocks helps to avoid wasted effort (and associated energy) on behalf of miners and validation nodes. By providing a solution that allows faster validation and therefore propagation of blocks, the present invention provides an enhancement of network performance. This reduces the amount of computation time and effort required, and also reduces the amount of energy required by the network. A more efficient network in terms of resources and time is provided. Finally, an improved (blockchain) network is provided.

[0053] In current implementations of blockchains, such as the Bitcoin network, each node that receives a block first validates the block before sending it to other nodes. If it takes a long time to validate a block, it will propagate the block through the network slower. Note that while some implementations of blockchains, including evolutions of existing protocols, may provide block validation by only a subset of nodes rather than every node in the network, block validation at most nodes is still likely to be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0054] Validating a block includes verifying that the block meets predefined criteria set by the applicable blockchain protocol. Exemplary criteria applicable to the Bitcoin protocol may include functions such as CheckBlock and CheckBlockHeader. In addition to verifying that the block itself meets predefined criteria, each transaction within the block may be evaluated for conformance with transaction-level criteria. As an example, transaction-level criteria applied in the Bitcoin protocol may include the functions AcceptToMemoryPool, CheckTransaction, and CheckInputs.

[0055] Examples of block level standards based on the Bitcoin protocol could include: Block data structures are syntactically valid. The hash of the block header is less than the target difficulty (to enforce the proof of work). The block timestamp is less than 2 hours in the future (allowing for time skew). Block sizes are within acceptable limits. The first transaction (and only the first transaction) is a coinbase generating transaction. All transactions in a block are valid.

[0056] Examples of transaction level standards based on the Bitcoin protocol could include: · The transaction syntax and data structures must be correct. Neither the input list nor the output list may be empty. Each output value x and the sum of all outputs is 0 <x<21·10 6 must be within the range. No input has a null hash. nLockTime is less than or equal to INT_MAX. The transaction size in bytes is greater than or equal to the minimum and less than the maximum. The number of signing actions is less than the signing action limit. The unlock script scriptSig can only push numbers onto the stack, and the lock script scriptPubkey must match the isStandard format. For each input, if the referenced output is present in any other transaction in the pool, the transaction must be rejected. For each input, if the referenced output transaction is a coinbase output, then at least COINBASE_MATURITY(100) confirmations are required. For each input, the referenced output must exist and not be in use. Use the referenced output transaction to get the input values, and ensure that each input value and the sum are within the tolerance range of value x, i.e. 0 <x<21·10 6 Check that it's inside. · There must be a matching transaction in the pool or in a block on the main branch. The sum of the input values ​​must be greater than or equal to the sum of the output values. The transaction fee must be sufficient to gain entry to a free block. · The unlock script for each input must be validated against the corresponding output lock script.

[0057] These exemplary criteria are exemplary and should not be construed as sufficient or necessary for all embodiments, as the predetermined criteria may vary by protocol and may change over time for a given protocol as changes are made to the protocol. In general, transaction-level validation criteria are predetermined characteristics that a transaction must have in order to be considered valid under the applicable blockchain protocol. Similarly, block-level validation criteria are predetermined characteristics that a block must have in order to be considered valid under the applicable blockchain protocol.

[0058] In accordance with the present application, methods and devices are described that speed up block validation to facilitate faster propagation of blocks in the network. Faster and more efficient validation and propagation helps address the technical challenge of how to scale blockchain networks, thus providing improved applications and systems built on such blockchain platforms.

[0059] In one aspect, the present application describes a node structured to validate a block by performing at least transaction-level validation of individual transactions in a parallel and / or distributed manner. However, certain transaction-level criteria may not be evaluated in parallel. For example, the uniqueness of a UTXO may be evaluated on a serial basis. In such cases, a distributed validation node of the present disclosure may be structured or configured to verify the uniqueness of a transaction's referenced input (UTXO) before allocating the set of transactions among a set of two or more parallel processors for validation of the remaining transaction-level criteria.

[0060] In particular, embodiments of the present disclosure provide improved validation and security solutions for processing related or associated data records stored in a tree structure. The tree can be a binary tree or a mesh structure. As is known in the art, the tree structure can be decomposed into smaller trees (sometimes referred to herein as tree "segments," "subsets," or "parts"), each segment containing a subset of the data records in the overall tree and having its own root. Advantageously, embodiments of the present disclosure take advantage of this feature to provide a method and system for distribution and parallelization of processing of related data records across multiple processing resources.

[0061] In an exemplary embodiment of the present application, a plurality of data records comprise related blockchain transactions as they form nodes in a Merkle tree. A Merkle tree has a root that is or can be included in the header of a block of transactions according to a blockchain protocol, such that the root provides a path that can be traced to all leaves (i.e., transaction IDs (TxIDs)) in the tree. In the present example, the blockchain protocol is or is derived from the Bitcoin protocol, although other protocols are within the scope of the present disclosure.

[0062] In one example, processing the plurality of transactions includes validating at least a portion of a blockchain block that includes the plurality of blockchain transactions and the root of a Merkle tree for the block. These examples are non-limiting, and the techniques disclosed herein may be utilized with respect to non-blockchain related data and / or with respect to other processes other than validation. For example, embodiments may be used to store, structure, search, and / or maintain any type of data record that can be represented by a Merkle tree. Databases and other known storage resources may be utilized instead of or in addition to a blockchain ledger.

[0063] In another exemplary embodiment, processing the plurality of transactions includes downloading at least a portion of a blockchain block that includes the plurality of blockchain transactions and the root of a Merkle tree for the block.

[0064] For completeness, a discussion of Merkle trees and their use in representing blocks of blockchain transactions is provided with reference to Figures 3 and 4.

[0065] Merkle Tree Referring to Figure 3, a Merkle tree is a hierarchical data structure that allows for secure verification of a collection of data. In a Merkle tree, each node in the tree is given an index pair (i,j), denoted as N(i,j), where the indices i,j are simply numerical labels associated with a particular position in the tree.

[0066] A characteristic of a Merkle tree is that the composition of each of its nodes is governed by the following formula:

number

[0067] An example of a binary Merkle tree constructed according to these formulas is shown in Figure 3. As shown, for i=j, we simply denote the corresponding i-th data packet D i If i ≠ j, then it corresponds to an internal or parent node generated by hashing recursively until a single parent (the Merkle root) is found, and concatenating the child nodes.

[0068] For example, node N(0,3) is constructed from four data packets D0,...,D3 as follows:

number

[0069] The tree depth M is defined as the lowest level of a node in the tree, and the depth m of a node is the level at which the node resides. For example, root =0 and m leaf =M, and in Figure 3 M=3.

[0070] For Merkle trees in Bitcoin and some other blockchains, the hash function is double SHA256, which is the two applications of the standard hash function SHA-256: H(x) = SHA256(SHA256(x)).

[0071] The main function of a Merkle tree is to find a data packet D i Let D be a set of N data packets D∈{D0,...,D N-1 The goal of verification is to verify that a packet of data D is a member of a list or set of . i and obtaining a set of hashes, known as a Merkle path, for the Merkle root R. A Merkle proof for a data packet is simply the minimal list of hashes needed to reconstruct the root R by repeated hashing and concatenation, and is often called an "authentication proof."

[0072] A proof of existence is the proof of existence for all packets D0,...,D N-1 and their order are known to the prover, this can be done trivially. However, this requires a much larger storage overhead than Merkle proofs, and requires the entire data set to be available to the prover.

[0073] A comparison of using Merkle proofs and using the entire list is shown in the table below, where we use binary Merkle trees and assume that the number of data blocks, N, is exactly equal to an integer power of 2.

[0074] The table below shows the relationship between the number of leaf nodes in a Merkle tree and the number of hashes required for a Merkle proof (or a Merkle proof). [Table 1] In this simplified scenario, where the number of data packets is equal to the number of leaf nodes, we can see that the number of hash values ​​required to compute a Merkle proof scales logarithmically. It is clear that it is much more efficient and practical to compute a Merkle proof that contains log2N hashes than it is to store N data hashes and compute an explicit proof.

[0075] Given a Merkle root R, let D∈{D0,...,D N-1}, you can perform a Merkle proof as follows: i. Obtain the Merkle root R from a trusted source. ii. Obtain a Merkle proof Γ from a source, where Γ is a set of hashes: Γ={N(1,1),N(2,3),N(4,7)}. iii. Compute the Merkle proof using D1 and Γ as follows: a. Hash the data block to get: N(0,0)=H(D0). Concatenating with bN(1,1) and hashing, we get: N(0,1)=H(N(0,0)||N(1,1)). Concatenating with cN(2,3) and hashing, we get: N(0,3)=H(N(0,1)||N(2,3)). Concatenate this with dN(4,7) and hash it to get the root: N(0,7)=H(N(0,3)||N(4,7)), R´=N(0,7). e. Compare the calculated root R' with the root R obtained in (i): 1. If R′=R, then the presence of D0 in the tree and therefore the data set D is confirmed. 2. If R' ≠ R, the proof fails and D 0が D membership is not verified.

[0076] This is an efficient mechanism for providing proof of existence of some data as part of the dataset represented by the Merkle tree and its root. For example, if the data D0 corresponds to a blockchain transaction and the root R is publicly available as part of the block header, then it can be quickly proven that the transaction was included in that block.

[0077] SPV Simple Payment Verification (SPV), first described in section 8 of Satoshi Nakamoto's 2008 whitepaper "Bitcoin: A Peer-to-Peer Electronic Cash System", exploits these properties of Merkle trees. In an SPV-based cryptocurrency exchange between Alice and Bob, both parties use the same type of SPV wallet. The SPV wallet stores the user's private and public keys, unspent transactions, and a block header that uniquely identifies the block so that it can be located on the blockchain. As explained, the block header contains a field of data that provides a unique summary or fingerprint of the entire block's contents, and a field that provides the Merkle root of that block. The Merkle root is generated by repeatedly hashing pairs of transaction IDs (TxIDs) from the block together until a single hash is eventually arrived at. The Merkle root provides an efficient and secure mechanism for verifying that a transaction is part of a block, as it allows users such as wallets and merchant nodes to verify a particular transaction locally without having to download the entire blockchain. This is advantageous for users who do not need or want to run a full node, but simply need to perform a local check that a particular transaction is in a particular block, e.g., parties such as merchants and customers who want to perform transfers between each other. In summary, SPV allows such users to search a Merkle tree with a given root to check (i.e., verify) whether a particular transaction is included in a particular blockchain block, without having to download and store the entire blockchain.

[0078] Thus, SPV wallets provide at least the advantage that power and storage constrained devices, such as phones and laptops, can operate within the Bitcoin ecosystem because they only need to verify that a transaction has been verified (hence the name "simple payment verification"), rather than performing a full check of the blockchain as other forms of wallets do. SPV wallets download only the block headers without including any of the transactions, greatly reducing the storage space, energy, and processing resources required for verification. SPV wallets are particularly well suited for use in embodiments of the present disclosure for reasons explained below, and the term "verification" is used herein to include SPV checks.

[0079] Blocking Transactions FIG. 4 illustrates an example of a blockchain block. Each block includes a block header and a set of transactions. The block header includes, among other things, a hash of the previous block header, i.e., the hash of the block header of the block from which the current block was built. The block header also includes the Merkle root of a Merkle tree built using the set of transactions. Each transaction is first hashed (e.g., double hashed) to generate a transaction identifier (TxID) for that transaction. The transaction identifier is then used as a leaf node of the Merkle tree. Pairs of transaction identifiers are then concatenated and hashed to form respective internal nodes of a first internal level of the Merkle tree. Pairs of internal nodes of the first internal level are then concatenated and hashed to form respective internal nodes of a second internal level of the Merkle tree. The process of concatenating and hashing pairs of internal nodes is repeated until only a single hash remains, i.e., the Merkle root. This Merkle root is sometimes referred to as the block Merkle root.

[0080] Next, with particular reference to Figures 5, 6 and 7, an embodiment of the present disclosure will be described.

[0081] Identifying the segments of a block’s Merkle tree Suppose a particular party, say Alice, wishes to validate some transactions. According to one embodiment of the present disclosure, at least one subset of the transactions is identified, the subset forming a segment of the entire Merkle tree of blocks and / or represented by a segment of the entire Merkle tree of blocks. Thus, the block of transactions can be logically segmented into multiple segments based on the Merkle tree of blocks, with each segment containing a subset of the transactions of the block, and each segment having its own root node (or "root hash"). This common root hash may be referred to as the "segment hash" below to distinguish it from the root hash of the entire block. Transactions on the same level in a tree segment (i.e., the lowest level, sometimes referred to as the "leaf level" or "leaf tier") are siblings. All transactions in a given segment share a common root node for that segment. The common root node may belong to an adjacent level of the Merkle tree, i.e., the level immediately above the lowest level. Alternatively, the common root node may belong to a higher level. In general, the common root node may belong to any level of the Merkle tree between the lowest level and the Merkle root.

[0082] Splitting a block into smaller parts based on a Merkle tree offers significant technical advantages, including the ability to quickly and efficiently allocate transactions across multiple validators. For example, because the Bitcoin protocol uses a binary tree, it is possible to implement binary allocation across multiple machines. By using small binary markers as an indexing system for segments, the position of each segment in the overall Merkle tree can be quickly calculated, and the segments can be returned to their original state after validation is complete, reconstructing the full Merkle tree for the block. This binary indexing approach is described in more detail below.

[0083] Although various techniques can be used to identify the segments, according to one approach, the number of segments may be determined by the number of available validators in the system. For example, in a system with four validators, the Merkle tree may be divided into four segments, if there are eight validators, the Merkle tree may be divided into eight segments, and so on. The identification of the segments of a given Merkle tree may be performed or influenced by a control entity, represented by controller 702 in FIG. 7.

[0084] The above-described points are further illustrated with reference to FIG. 5 and FIG. 6, where FIG. 5 shows an example of how a Merkle tree can be divided into separate portions 502 that are assigned to validators. In the example of FIG. 5, each arrow represents a respective transaction that is hashed to form a respective transaction identifier, which is used in a respective leaf node of the Merkle tree. The top of the Merkle tree is a block Merkle root. In this example, the block of transactions represented by the Merkle tree contains 32 transactions. However, it will be understood that this is only an illustrative example, and that in general, a Merkle tree can contain any number of transactions, depending on the number of transactions in the block. As shown, the Merkle tree is divided into four portions 502a-d, indicated by dashed boxes. Each portion 502 is linked by a respective common internal node (inner hash) 504 of the Merkle tree, indicated by a solid circle. Each portion 502 represents eight transactions. In this example, the common internal node 504 belongs to the fourth level of the Merkle tree. According to embodiments described herein, each respective portion 502 (or rather, the transactions forming and / or representing a part of it) is assigned to a respective validator for processing, e.g., for validation of the transactions belonging to the respective portion 502.

[0085] FIG. 6 shows another example of how a Merkle tree can be split into parts 602. The Merkle tree of FIG. 6 is the same as the Merkle tree of FIG. 5. However, in this example, the Merkle tree is split into eight parts 602a-h, each part 602 representing four transactions. In this example, the common internal node 604 belongs to the third level of the Merkle tree. The Merkle trees of FIG. 5 and FIG. 6 may alternatively be split into more (e.g., 16) or fewer (e.g., two) parts 502, 602. In general, a Merkle tree formed from a set of transactions of a block may be split into any number of parts 502, 602, each part containing a minimum of two transactions.

[0086] Assigning segments to each validation resource Following their identification, a subset of transactions are distributed across multiple validation resources, sometimes also referred to as "validators" for ease of reference. In Figures 7 and 9, the multiple validators are shown as Resources A-D (704a-704d). The allocation process may be directed or influenced by a dedicated unit, such as, but not limited to, component 904 as shown in Figure 9.

[0087] Each validator (704a-704d) can include one or more processing resources. Thus, at least one of the validators in the plurality of validators (704a-704d) can be or include at least one of one or more virtual machines, one or more servers, one or more GPU-based computing resources, one or more threads, and / or one or more multi-processor systems, etc. In essence, any of the plurality of validators can be comprised of any type(s) or combination of processing resources, each capable of validating one or more transactions related to each other by a segment of a Merkle tree of blocks. The plurality of validators (704a-704d) and other system components form a collective resource or entity 700, which we refer to as a "(distributed) validation node."

[0088] Preferably, the distribution includes allocating each of the segments to a respective validator in the plurality of validators. The validators may be configured to do at least the following: · Operate on one or more transactions that make up the assigned segment(s); Validating one or more transactions to verify that they comply with the blockchain protocol; and / or Validate that they are identifiable within an existing repository, such as a blockchain ledger or a database of known, registered or used transactions.

[0089] The activity of the validators and the allocation of subsets to different validators may be directed by a controller. Figure 7 shows the controller 702 assigning subsets of transactions A-D for each tree segment to validators 704a-d, respectively. The system-level controller 702 coordinates the activity of the systems or devices 704a-d in the distributed validation node and may control or influence tasks such as identifying tree segments according to the Merkle tree of blocks, assigning the identified segments to respective validators, reordering the validated tree segments into the complete Merkle tree of blocks, and / or ordering of transactions in the reconstructed blocks.

[0090] One or more of the validators may include at least one coordinating entity configured to act as a controller at the validator level. Thus, any or all of the validators 704a-704d may include at least one controller component of their own. This lower-level controller may influence or direct operations such as the allocation of tasks or subtasks to one or more processing resources within the validator, the reconstruction of the Merkle tree for a given segment, or interaction with other system components, e.g., other validators or higher-level controllers, UTXO pools, wallets, etc. The processing resources themselves may then be further decomposed into smaller systems, one or more of which may include a controller and one or more processing resources of their own. In this way, the system may include a hierarchical architecture in which segment validation is performed by a validation entity that includes one or more processing resources for performing validation tasks and one or more controllers for coordination of execution of processor activities and inter-component communication.

[0091] In embodiments where the validator includes multiple processing resources, the validator may divide its assigned segment into smaller segments. The validator's controller can then distribute the sub-segments across the processors under its control. In this manner, the validation process can be performed in a hierarchical and distributed manner.

[0092] This hierarchical decomposition can also be extended to the transaction level, so that validation can be further decomposed into sub-processes or tasks per transaction, rather than at the tree segment level. In this approach, validation of an individual transaction or transactions is decomposed into sub-tasks that are distributed across different machines, or different threads running on the same or different machines. These processes can be queued so that when a thread becomes available, another transaction or task can be assigned to it.

[0093] Thus, the present disclosure allows many transactions to be processed simultaneously, with the only limitation being the amount of hardware available to form the distributed validation nodes, rather than the bottleneck being the amount of processing speed available as in conventional techniques. This allows blockchain processing systems to scale horizontally without the need to change the underlying protocol of the blockchain network.

[0094] Thus, the present disclosure represents a significant departure from conventional approaches to validation, which are described in more detail below in the section entitled "Exemplary Technical Environment for Implementing Exemplary Embodiments of the Present Disclosure" with reference to Figures 1 and 2. As explained, conventional approaches include a block being validated as an entire entity and the conventional view of a validation node (see 104 in Figure 1) as a single computing unit. In contrast, embodiments of the present disclosure divide the Merkle tree into multiple segments that are fed to different validators (704a-704d in Figures 7 and 9), each of which can be further decomposed to increase the degree of distribution involved.

[0095] Furthermore, by splitting each block into segments based on its Merkle tree, embodiments of the present disclosure allow validators to access, download, and process smaller portions of a block rather than the entire block. Recall that transactions in each segment hash up (in pairs) to a single root value. This means that segments can be validated using only the relevant transactions required, rather than the entire block being downloaded, stored, and processed in its entirety. As protocols such as Bitcoin SV allow for scaling block sizes and for larger blocks to be included in the ledger, the traditional model of downloading the entire block becomes a bottleneck. Embodiments of the present disclosure overcome this challenge to blockchain scalability by allowing individual validators to receive and process only the (smaller) portions relevant to them. This results in faster overall validation times, improved blockchain networks, and improved applications running on the blockchain.

[0096] Additionally, embodiments support and facilitate the use of SPV processes and resources because such SPV involves local validation of only the portion of the Merkle tree that is of interest to a given party. Thus, the tree-pruning nature of SPV techniques is ideally suited for use with embodiments of the present disclosure. In the context of SPV, validators may be provided with only the portion of the block data they need, i.e., the block header or segment root node and associated transactions.

[0097] If each validator performs its checks and confirms the validity of the segments it has processed, the hashing mechanism used to generate the tree ensures that the block is valid.

[0098] Load Balancing Across Multiple Validators Load balancing techniques and systems are known in the art that are designed to distribute tasks evenly across multiple resources to improve efficiency. The objective is to minimize the risk of some processing resources being overloaded while others are idle, and thus the risk of performance degradation and even failure. Load balancing is therefore important in ensuring the resilience of the overall system as well as its performance and efficiency. The embodiments of the present disclosure may utilize any known load balancing technique, such as, for example, static or dynamic load balancing. Additionally or alternatively, the load balancing techniques disclosed herein may be advantageously used.

[0099] As mentioned above, embodiments of the present disclosure may use an indexing system in assigning block segments to each validator. Preferably, this is a binary indexing system. In this preferred system, each validator is assigned a binary label or identifier. Assume that each identifier is four digits long, with the first validator identified as 0000, the next as 0001, the next as validator 0010, and so on. It is clear that a four-digit identifier allows for 256 validator IDs, with the last validator being identified as 1111 (i.e., validator number 255 in decimal).

[0100] When a tree segment needs to be assigned to a validator, the first four digits of the double hash (i.e., the segment hash of the tree segment) can be used to determine which validator will process the segment. Recall that the Merkle root is generated by hashing together pairs of transaction IDs (TxIDs) from blocks to generate each internal node (or internal hash) of the Merkle tree, and then repeatedly hashing adjacent internal hashes until a single hash is finally reached. This double-hashed Merkle root provides an efficient, fast, and secure validation mechanism. It also provides the advantage, in this context, that the double hash generates random binary numbers. Each internal hash, including each segment hash, is itself a double hash. Thus, the first x leading digits of the segment hash can be taken as the assignment index. A hash with four leading zeros would result in the assignment of the tree segment to the validator with ID 0000, a hash with leading digits 0001 would result in the assignment to the validator with ID 0001, and so on. The random generation of the double hash ensures a random distribution of tree segments to validators.

[0101] Although a double hash is typically used in generating a Merkle tree, this is not required in all instances and instead, only a single hash may be used. In fact, any number of hash operations will result in a random binary number. Load balancing tasks may be performed by a dedicated system component shown as 905 in Figure 9, or may be provided elsewhere in system 700 or in association with and communication with system 700.

[0102] Distributed download or reception of blocks According to some embodiments, the allocation of segments of a block Merkle tree to different validators may be used to provide a faster, more efficient process for receiving, e.g., downloading, some or all of a block of transactions. Although the term "downloading" may be used herein for convenience, the disclosure is not so limited and one or more of the validators may obtain the data through other means, for example, by receiving a transmission from a transmission resource on a network such as the Internet or a VLAN.

[0103] Each validator is assigned a segment of the Merkle tree, for example, based on the assignment index described above. Any given validator then operates to download the set of transactions that form its assigned tree segment. This may include downloading the set of transactions from the blockchain itself (e.g., from a blockchain node) or from a different resource or entity, such as a third-party service provider. The set of transactions may be downloaded to the validator's internal memory or to a shared storage location, such as a shared drive in the cloud.

[0104] In some embodiments, the validator(s) may receive the data in the form of one or more data packets sent to a multicast address to which the validator subscribes. This may be an IPv6 multicast address known in the art. One, some, or all of the validators may subscribe to the multicast address. In some embodiments, subsets of the validators may subscribe to different respective multicast addresses so that transactions for different segments can be assigned to groups of validators that share a common multicast address.

[0105] A distributed node may need a complete block, i.e., the entire set of transactions that form a block. In that case, each validator that has been assigned a tree segment downloads a subset of the transactions that form that segment. In other scenarios, a distributed node may only need a specific portion of a block. In that case, only a subset of validators may need to download their respective subsets of transactions to obtain the desired transactions.

[0106] Downloading a block (or a portion of a block) in this manner results in a faster overall download, since each validator processes only a subset of the transactions of the entire set of transactions that form the block. This is in contrast to traditional block downloads, where a given entity (e.g., a full node) must download the entire block, e.g., by downloading each transaction in the order in which it appears in the block. Here, a block is downloaded in parallel by multiple validators. A block may contain tens of thousands of transactions, if not more than a few orders of magnitude more. A single entity downloading this number of transactions would consume significant resources and take a significant amount of time. The computational load is distributed among the validators, such that each individual validator consumes a portion of the processing resources. Similarly, the overall time to download a block is reduced.

[0107] As described above, each validator may download a subset of the transactions. The subsets may then be combined to reconstruct a block in a single storage location. (By "single storage location" we mean either a storage resource that is a self-contained entity, or multiple related storage resources that form a collective entity). To do so, the individual validators may send their respective subsets to a central controller of distributed nodes configured to place the transactions in the correct order. Segment hashes (i.e., hashes that link tree segments) may be utilized for this purpose. For example, a mapping of segment hashes to their positions in the Merkle tree may be maintained, e.g., from left to right as the segment hashes appear in the Merkle tree. The subsets of transactions may then be placed in order (e.g., from first to last) based on their corresponding segment hashes.

[0108] In some embodiments, individual validators (or the distributed nodes as a whole) may verify that the correct transactions have been downloaded (or that the transactions have been downloaded correctly) by reconstructing the Merkle tree. After downloading a subset of transactions, the validators may generate candidate segment hashes based on these transactions. The candidate segment hashes are constructed by hashing pairs of TxIDs to generate their respective internal hashes, and repeatedly hashing the pairs of internal hashes until a candidate segment hash is generated. The level of the Merkle tree to which the candidate segment hash belongs depends on the number of tree segments the Merkle tree is divided into. The validators may verify that the candidate segment hash is a hash of the Merkle tree. If the hashes do not match, an error occurred during download. In some examples, each validator may generate a candidate segment hash and send it to the controller to perform validation. As another example, a candidate block Merkle root may be generated based on the entire set of downloaded transactions. Again, the candidate Merkle root should match the actual block's Merkle root (i.e., the Merkle root stored in the block) if the block was downloaded correctly.

[0109] In some cases, validators may validate the downloaded transactions using the techniques described above; that is, each validator is assigned a tree segment, downloads a corresponding subset of transactions, and validates those transactions. In other cases, validators may not necessarily validate the transactions, but simply download them for later use, e.g., sending to a third party.

[0110] Decentralized UTXO Pool Preferably, each validator 704 forming part of the distributed validation node has its own repository (pool) for generating, storing and / or maintaining unspent transaction outputs (UTXOs). It serves as a UTXO pool providing a record of unspent, i.e. unspent outputs associated with blockchain transactions. Thus, each validator's UTXO pool is built based on and from transactions that are assigned to it by the controller in terms of Merkle tree segments. In one embodiment, this may be a (graph) database containing data on unspent UTXOs of transactions assigned to a given validator for processing. A record in the database is created for each UTXO that the validator becomes aware of when a new Merkle tree segment is assigned to it. Thus, from the perspective of the distributed validation node, the UTXO pool is not a single pool but rather consists of several different UTXO pools, each UTXO pool provided to or on a different validator and containing a different set of UTXOs. Thus, the UTXO pool for a node is distributed both in terms of data and the resources to store and / or process it.

[0111] This is a significant departure from the traditional UTXO model, where each full node in the network has a copy of a UTXO pool that tracks all UTXOs on the blockchain. In contrast, the present disclosure distributes UTXO pools across multiple validating resources, each of which has a UTXO pool that is a subset of the blockchain's entire UTXO set. Each validator's UTXO pool contains the UTXOs of transactions that make up a subportion of the Merkle tree that it is tasked with validating.

[0112] Such an approach can be implemented in a manner similar to SQL transaction logs in that all commands, events, and items related to the database are logged each time a new block needs to be validated. The term "database log" is used herein to avoid confusion arising from the use of the term "transaction" as known in the context of blockchain, but the term "database log" is used to include terms such as "transaction journal", "transaction log", etc. In essence, a database log can be interpreted as a history of actions performed by a database management system, providing a record of all changes that have occurred with respect to the state of the database, as known in the field of computer-based databases (see https: / / en.wikipedia.org / wiki / Transaction_log).

[0113] The use of an ordered history database log means that the entire UTXO pool can be constructed by running the log's history in its original order. Advantageously, this ensures that a copy of the database can always be (re)generated when needed, and no separate copies of the data need to be stored. Data integrity is ensured and fewer storage resources are required. Each UTXO pool can be stored, maintained and processed separately. Advantageously, the SPV technique also facilitates the creation of a separate UTXO database for each validator, assuming that the SPV technique operates on a pruned portion of the Merkle tree.

[0114] Transactions (TX) in the database can be structured in a variety of ways, but a particularly advantageous approach is to structure transactions according to an identifier that comprises the concatenation of a block ID and a transaction ID (block_ID||TxID). Both block ID and transaction ID are 256-bit hashes, resulting in a secure, collision-free 512-bit concatenated field structure.

[0115] Structuring transactions in this way provides a fast and efficient lookup mechanism. Transactions can be sorted by block_ID such that all transactions with the same block_ID are located together in the database. Thus, when a validator needs a transaction (e.g., to check if the transaction's UTXO has been spent), the validator can locate the transaction in the database by first looking up the corresponding block_ID and then the corresponding TxID. This has the effect that the search is limited to the relevant section of the database. This efficiency reduces the time, processing resources and energy required for the search operation, providing a significant improvement over the prior art.

[0116] A flag or marker is associated with each UTXO in a validator's pool to indicate whether the UTXO is locked or unlocked. For convenience, we sometimes refer to this flag or marker as the "lock flag." When a UTXO is marked as "locked," it serves as an indicator to validators in the group (i.e., elsewhere in the decentralized validation nodes) that this UTXO is not available for spending. Conversely, when a UTXO is marked as "unlocked," it serves as an indicator to validators that the UTXO is available for spending. It thus serves as a way for a validator assigned to verify a transaction that uses the UTXO to signal to its peers that it has been redeemed and is therefore no longer available for spending, assuming that the transaction proves valid. The "locked" state means that spending is permitted, and the "unlocked" state means that spending is prohibited.

[0117] This lock / unlock flag can be a simple small binary marker, such as 0 for "locked" and "1" for unlocked. The marker mechanism is used internally by validators in the distributed node system, and the marker is removed from transactions before interacting with the blockchain to ensure that the transactions comply with the protocol rules.

[0118] In use, a validator checks the outputs in each new transaction assigned to it by the controller. Any unspent outputs (UTXOs) are added to the validator's UTXO pool, i.e., recorded as an entry in the UTXO database. In the associated database record for each new UTXO, the lock flag is set to "unlocked".

[0119] Once a validator sees that a UTXO has been spent by a newly allocated transaction, it sends a message to all other validators in the pool informing them that this UTXO should also be locked in their respective pools. Essentially, the validator sends a communication to its peers indicating that it has seen a spend involving a transaction with a particular hash ID at a particular time. Other validators do not need to receive the full data for the entire transaction, since the transaction hash and the list of UTXOs it uses are enough to identify the transaction and mark it as locked in its own database. Upon receiving the message, each receiving validator checks if the UTXO is in their UTXO pool. If so, the state of the lock flag is changed to "locked". Thus, the lock prevents the validator from allowing the same UTXO to be spent in a subsequent transaction. If a new transaction attempts to spend the same UTXO, the lock flag check indicates that the second spend attempt should be ignored. If the validator that sent the message determines that the validation has failed and therefore the UTXO has not been spent, a further message to this effect may be sent to the validator peers indicating that the UTXO's lock flag should be changed to an "unlocked" state. Once valid usage has been completed, a message to this effect can be sent and the locked UTXO can be removed from the associated UTXO pool.

[0120] In the embodiment described above, each validator has a single UTXO pool that contains the UTXOs of all transactions in all of the tree segments assigned to it. However, in an alternative approach, the UTXO pool maintained by each validator may be divided / split / compartmentalized / formed into multiple subpools, one for each block. In this way, the single UTXO pool may be organized into a logical hierarchy. In yet another approach, one or more validators may be configured in association with respective multiple UTXO pools, each multiple UTXO pool relating to UTXOs for a set of one or more tree segments. Thus, in some embodiments, the validator(s) may organize UTXOs into separate UTXO pools for different individual tree segments, or according to some predefined criteria, such as the type of tree segment or tree segments that fall within a given range. In such an embodiment, the identifier may include a block ID that can be used to narrow the search to the relevant UTXO pool, and then the search can proceed within that pool to (attempt to) identify the relevant transaction by its TxID. Those skilled in the art will understand that in some embodiments, a mixture of these approaches may be used, i.e., one or more validators within a distributed node may employ a single UTXO pool approach, while other(s) are configured to use multiple separate UTXO pools, and / or a UTXO pool organized into sub-pools, or any combination thereof.

[0121] This provides protection against "double spend" situations where a party attempts to spend the same UTXO twice. It provides a simple and secure locking mechanism that works efficiently and quickly regardless of the number or location of validators in the system, and preserves the security and integrity of transfers implemented via the blockchain.

[0122] Exemplary Systems of Possible Embodiments Figures 7 and 9 show an example system 700 for implementing at least some of the described embodiments. Figure 8 shows a flow chart of example steps that may be taken in a (high-level view of) the method of the present disclosure.

[0123] System 700 may be a closed system in the sense that it is associated with an organization and forms part of a larger proprietary system. In such a case, its data, e.g., transactions, may be received from other components within the organization's wider system, and the results and outputs may be sent to internal destinations. Additionally or alternatively, system 700 may be configured to interface with various entities, some or all of which may be located outside the organization. In such a case, system 700 may be configured to provide validation functionality as a service. For example, system 700 may be configured to interact with a blockchain network to obtain data it needs. Additionally or alternatively, it may interact with entities that wish to use its validation services. Thus, the activities of system 700 may be merely internal with respect to a particular organization or entity, or open to interaction with external entities to provide validation services to other parties, or a combination of the two. Communications between other internal or external entities may be coordinated by one or more interfaces or communication components, shown as 902 in FIG. 9.

[0124] As shown in Fig. 7 and Fig. 9, the system 700 includes a control entity 702 (or simply "controller") and a number of validation resources 704, also referred to herein simply as "validators". Although only four validators 701a-d are shown in Fig. 7, in general the system 700 may include any number of validators. Furthermore, although the controller 702 is shown in Fig. 7 and Fig. 9 as distinct from the validators 704, this does not exclude that the controller 702 may include or be included in one of the validators 704. As explained above, each validator may include one or more processing resources and may include its own controller for the coordination of its own internal activities. There are no technical or logical limitations to the hierarchical levels that may be implemented in this manner. However, Fig. 7 shows only one level (the top) of such a hierarchy for the sake of brevity and ease of understanding.

[0125] As shown in FIG. 7, the controller 702 obtains a set of transactions. The transactions may be received over an electronic channel or network from a sending resource. The sender may be any entity that wishes to perform some type of validation check, internal or external to the organization of the system, as described above. For example, this may be a full node on the blockchain network, such as node 104 in FIG. 1, or a digital wallet, or a merchant / SPV node that wishes to perform local checks on blockchain-implemented transfers made between parties. The interface(s) 902 may facilitate the transmission of data between the system 700 and sources external to the system.

[0126] The transactions form or may form a block of transactions. The transactions may be obtained from a single resource (e.g., from a block of the blockchain) or from different resources (e.g., one or more users, one or more blockchain nodes, etc.). The transactions may be obtained before they are published on the blockchain, i.e., before they are recorded in a block. Alternatively, the transactions may be obtained after they are recorded in the blockchain.

[0127] The controller 702 assigns a respective subset of the transactions to each validator 704 as described herein. Each subset of the transactions forms at least a portion of a respective portion of a Merkle tree generated based on the full set of transactions and is linked by a respective common internal node of the Merkle tree. In the example of FIG. 7 , transaction subset A is assigned to validator A, transaction subset B is assigned to validator B, transaction subset C is assigned to validator C, and transaction subset D is assigned to validator D. Once the subsets of transactions have been assigned, the validators 704 process the respective subsets. In some embodiments, this includes each validator 704 validating its respective subset of the transactions. To do so, the controller 702 may send the relevant transactions to the respective validators 704. The validators 704 may reply to the controller 704 to indicate that each of the respective subsets of the transactions is valid or that at least one transaction is not valid.

[0128] At least one, and preferably some or all, of the validators 704a-704d have access to their own UTXO pool, shown as 901a-901d in Figure 9. This pool may include a storage facility such as the database described above, potentially with an advantageous indexing structure including a concatenation of block IDs and transaction IDs. While the pool is shown in Figure 9 as being contained within the respective validator, those skilled in the art will readily appreciate that the pool may also / alternatively be provided as being external to and in communication with the validator.

[0129] In one or more embodiments, the disclosed process may include a block-level validation phase, during which incoming new blocks are tested against block-level criteria. Exemplary block-level criteria are described above and generally relate to predefined formatting requirements and characteristics or restrictions applicable to the blocks themselves, as opposed to transactions within the blocks. Examples include block size, block header structure or contents, and similar criteria. Such operations may be performed by the controller, or a component of the controller, or another system component.

[0130] In some embodiments, the method may further include a UTXO uniqueness checking module that operates to evaluate whether each of the inputs to a transaction in the new block, i.e., each UTXO, is unique. If the same UTXO appears more than once as an input in the new block, it indicates a potential double-spend problem and violates the UTXO uniqueness criteria. If the UTXO uniqueness checking module identifies a UTXO that is referenced more than once among transaction inputs in the new block, it may output an error signal or other interrupt to indicate that the block should be rejected.

[0131] Assuming that the new block is not rejected, i.e., all UTXO entries are unique, Merkle tree segments may be identified and their associated transactions may be allocated among the set of validators. The identification process may be performed by a component such as the segment identification unit 903 shown in FIG. 9. The allocation process may be performed by a segment allocation unit, shown as 904 in FIG. 9. The allocation unit 904 may employ any one of several possible allocation schemes for distributing block segments among the individual validators, but in an advantageous approach, the allocation scheme may be for the purpose of load balancing, as explained above. The allocation unit 904 may include (or be in communication with) a load balancing unit 905. Although this is shown in FIG. 9 as a separate and related component of the system, in other embodiments, the load balancing unit may be part of the allocation unit 904 or may be separate to the controller 702. Any combination of components may be readily employed.

[0132] Individual validators validate transactions associated with the segment(s) they receive against transaction-level validation criteria. Validators operate independently in verifying that their assigned transactions are valid, so no synchronization paradigm between validators is required. Each validator outputs a result that confirms the validity of its assigned transactions. The results are added or accumulated to confirm that all transactions in the segment are valid. If one of the validators identifies a non-compliant, i.e., invalid, transaction, the validator may issue an output, such as an interrupt or other signal, to indicate that an invalid transaction is present. That interrupt or signal may be sent to other validators, or to a controller or another system component, which can immediately stop testing their respective transactions and not waste any more resources validating transactions in the block to be rejected.

[0133] In some examples, the system may be configured to check block-level criteria. This may be performed prior to the allocation of segments to validators, although it will be understood that the block-level validation stage may occur after transaction-level validation tests by the validators, and in some cases may occur in parallel with transaction-level validation tests.

[0134] Reference is now made to Figure 8, which illustrates in flow chart form one example of a method for validating a block. A block includes multiple transactions, each transaction references one or more inputs, each input being a UXTO (except in the case of a coinbase generating transaction). The method is implemented using suitable hardware and processor executable instructions in a node on the blockchain network.

[0135] In operation, the distributed validation node 700 receives new block data in step S801. This may be an entire block, or in the case of SPV-related validation, may include only partial data necessary to perform an SPV check. For convenience, this data is referred to as a "block." The new block to be validated may be received from a mining node on the blockchain network that has generated the new block and completed a proof of work, from a merchant node that wishes to perform an (SPV) check, or from a wallet, such as an SPV wallet. The new block may be received from another (non-mining) node in the network. In some examples, the distributed validation node 700 validates the block before forwarding it to any other nodes in the network. As discussed above, validating the new block may include verifying that the block meets certain protocol-based criteria and / or other criteria that may be specified and required within a given implementation.

[0136] In step S802, the system 700 identifies chunks of the Merkle tree of a block. In S803, the segments are distributed to multiple validators, which process their respective subsets of transactions substantially in parallel and independently of each other in S804. In S805, the validators signal to the controller whether the validation was successful or unsuccessful.

[0137] It should be noted that the term "processor," as used herein in connection with the description of a parallel processor, does not necessarily mean a physically separate microprocessor, but may include any hardware or software implementation that allows for parallel processing resources that can perform processor functions independently and in parallel. A parallel processor may include one processor with multiple cores. In some cases, a parallel processor may include multiple separate processing units. Parallel processors may or may not share physical memory. Each parallel processor, however implemented, has a software or hardware mechanism for signaling, such as outputting a signal in response to identifying an invalid transaction. A parallel processor implementation also includes providing, in software and / or hardware, the necessary data transfer mechanisms to route assigned transaction data to the respective processors for local processing.

[0138] Clause enumeration Embodiments of the present disclosure are provided by way of example, and not by way of limitation, in the following enumerated appendices.

[0139] Features mentioned below with respect to one set of enumerated appendices or aspects of the disclosure are not intended to be limiting in such respects, and any feature(s) mentioned with respect to one set of appendices may be incorporated in one or more of the other sets of appendices.

[0140] Appendix Set 1: <Supplementary Note 1.1> A computer-implemented method for processing (e.g., validating) at least a portion of a blockchain block that includes a plurality of blockchain transactions and the root of a Merkle tree for the block. The method comprises: assigning respective subsets of the blockchain transactions to a plurality of processing (e.g., validation) resources, each respective subset providing a respective portion of a Merkle tree and represented by a respective interior node of the Merkle tree; and / or Processing (e.g., validating) respective subsets of the blockchain transactions using a plurality of processing (e.g., validation) resources. may include.

[0141] Additionally or alternatively, the method may include: Transmitting or receiving at least a portion of a blockchain block including a plurality of blockchain transactions and a root of a Merkle tree for the block. The portion of the blockchain block may be transmitted from a transmitting resource to a receiving resource. It may be transmitted over a network, e.g., the Internet. The method may include processing the portion of the blockchain block at the receiving resource. The receiving resource may be referred to as a processing or validation resource. The portion of the blockchain block may be transmitted using IPv6 multicast transmission. At least one, some, or all of the plurality of processing resources may be members of an IPv6 multicast group. The transmitting resource may include a network device. The network device may be operative to transmit IPv6 multicast communications to a multicast address. MLD snooping may be enabled in the network device. This provides efficiency with respect to traffic on the network, since the transmitting resource may selectively transmit the portion of the blockchain block to a particular receiving resource (e.g., a resource within the plurality of processing resources). Network traffic is reduced and no waste of energy and processing resources is caused by transmitting data packets to all resources on the network, including those that do not need or want to receive the data. It also improves security as it avoids possible Denial of Service (DOS) attacks, while lower levels of network congestion allow for faster throughput of transactions, promoting the scalability of blockchain networks.

[0142] The term "validator" may be used interchangeably with "validation resource." "Validator / validating" may be used herein instead of "processor / processing" for convenience. A plurality of validation resources may form a distributed validation node. At least one of the plurality of validation resources may include one or more processing resources. Additionally or alternatively, one or more of the plurality of validation resources may include a validator controller component substantially as described herein. At least one or some of the validation resources in a distributed validation node may share, i.e., subscribe to, a common IPv6 multicast address.

[0143] Each internal node may be a segment root. In other words, an "internal node" is a node in a Merkle tree that is neither the root node nor a leaf node of the entire tree. Transactions in each subset may share their common internal nodes.

[0144] Stated another way, each subset may include at least two transactions associated with a common node in the Merkle tree such that the subset provides and / or is represented by a (sub)portion of the Merkle tree. The common (internal) node may be a segment node or root substantially as described herein. A portion of a Merkle tree may be a "segment" substantially as described herein.

[0145] <Supplementary Note 1.2> The step of validating a subset of blockchain blocks and / or blockchain transactions includes: i) validating and / or verifying at least one blockchain transaction; and / or ii) performing a Simplified Payment Verification (SPV) process; and / or iii) checking whether a given blockchain transaction (Tx) is contained within a blockchain block; and / or iii) generating a hash of at least one of the blockchain transactions, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block. The method of claim 1.1, comprising:

[0146] <Supplementary Note 1.3> At least one of the subsets of blockchain transactions includes an identifier that is associated with, identifies, and / or represents the subset; The method according to claim 1.1 or 1.2.

[0147] <Appendix 1.4> The identifier facilitates the computation of the position of at least one subset in the Merkle tree. The method described in Appendix 1.3.

[0148] <Supplementary Note 1.5> The identifier includes a portion of a hash of a blockchain transaction in at least a subset of the blockchain transactions. The method according to claim 1.3 or 1.4.

[0149] <Supplementary Note 1.6> The step of assigning each subset of the blockchain transactions to a plurality of validation resources includes matching each subset to a respective validation resource based on a respective identifier associated with the subset of transactions; 2. The method according to any preceding claim.

[0150] <Supplementary Note 1.7> i) downloading at least a subset of the blockchain transactions to at least one of a plurality of validation resources; and / or ii) sending at least a subset of the blockchain transactions to at least one of the plurality of validation resources; The method of any preceding claim, further comprising:

[0151] <Appendix 1.8> A Merkle tree is a binary tree or mesh of hashes of multiple blockchain transactions. 2. The method according to any preceding claim.

[0152] <Appendix 1.9> Identifying and / or determining a subset of blockchain transactions within a plurality of blockchain transactions The method of any preceding claim, further comprising:

[0153] <Supplementary Note 1.10> At least one of the multiple validation resources is Virtual machines, servers, GPU-based computing resources, processing threads, and / or multi-processor systems is or includes one or more of: 2. The method according to any preceding claim.

[0154] i) at least two transactions are siblings in the Merkle tree, and / or ii) A common node is a parent or ancestor of at least two transactions; 2. The method according to any preceding claim.

[0155] <Supplementary Note 1.12> A blockchain validation system that operates to validate at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block. The system includes a plurality of validation resources, each of which: A processor; A memory containing executable instructions; the executable instructions, when executed by the processor, cause the system to perform a computer-implemented method as set forth in any preceding clause. Blockchain validation system.

[0156] <Appendix 1.13> A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause the computer system to perform a computer-implemented method described in any one of Appendices 1.1 to 1.11.

[0157] According to another aspect of the present disclosure, there is provided a computer-implemented system configured to perform any method step or combination of method steps described or claimed herein.

[0158] Also provided is a blockchain system (network) including a plurality of computer-implemented nodes, each node in the blockchain network being: A processor; A memory containing executable instructions; The executable instructions, when executed by the processor, cause the system to perform any variation of the computer-implemented methods claimed or described herein.

[0159] The network may be configured to operate using the described blockchain protocol as described herein.

[0160] Additionally or alternatively, the present disclosure may include a computer-implemented method for downloading at least a portion of a blockchain block. The block may include a plurality of blockchain transactions and the root of a Merkle tree for the block. The method may include the steps as described in one or more of the following clauses.

[0161] Appendix Set 2: <Supplementary Note 2.1> A computer-implemented method for receiving, e.g., downloading, at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, comprising: allocating respective subsets of the blockchain transactions to a plurality of processing resources, each respective subset providing a respective portion of a Merkle tree and represented by a respective interior node of the Merkle tree; receiving, e.g., downloading, a respective subset of the blockchain transactions using one, some, or all of a plurality of processing resources; The method includes: According to one or more embodiments, one, some, or all of the processing resources may receive a respective subset of the blockchain transactions from the providing (transmitting) resource. The respective subsets of the blockchain transactions may be transmitted over a network, e.g., the Internet. The respective subsets of the blockchain transactions may be transmitted using IPv6 multicast transmission. At least one, some, or all of the multiple processing resources may be members of an IPv6 multicast group. The transmitting resource may include a network device. The network device may be operative to transmit IPv6 multicast communications to a multicast address. MLD snooping may be enabled in the network device. This provides efficiency with respect to traffic on the network, since the transmitting resource may selectively transmit a subset(s) of the blockchain transactions to a particular receiving resource (e.g., a resource within the multiple processing resources). Network traffic is reduced, eliminating the waste of energy and processing resources by transmitting data packets to all resources on the network, including those that do not need or want to receive the data. It also improves security as it avoids the possibility of denial of service (DOS) attacks, while lower levels of network congestion allow for faster throughput of transactions, promoting scalability of the blockchain network.

[0162] Each respective subset may be represented by a respective internal node in the sense that each respective internal node may encode the respective subset. That is, each respective internal node may be generated based on (i.e., as a function of) the respective subset. Each transaction in each respective subset may be linked to the respective internal node by one or more hash operations.

[0163] <Appendix 2.2> One, some, or all of the multiple processing resources sending respective subsets of the blockchain transactions to a central storage location. The method of claim 2.1, comprising:

[0164] <Appendix 2.3> Each internal node of the Merkle tree has a respective position in the Merkle tree, and the method further comprises: placing each subset of the blockchain transactions based on their respective positions in each internal node of the Merkle tree; The method of claim 2.2, comprising:

[0165] <Appendix 2.4> A step in which one, some, or all of the processing resources generate respective candidate internal nodes of the Merkle tree based on the respective downloaded subsets of the blockchain transactions. Including, verifying that each candidate internal node matches a respective internal node of the Merkle tree; and / or verifying that each candidate internal node is a node of the Merkle tree by performing a Merkle proof based on the root of the Merkle tree; and / or sending each candidate internal node of the Merkle tree to one or more other processing resources; The method of any preceding claim, further comprising at least one of:

[0166] <Appendix 2.5> Validating each subset of blockchain transactions using one, some, or all of a plurality of processing resources. The method of any preceding claim, comprising:

[0167] <Supplementary Note 2.6> The step of validating each subset of blockchain transactions includes: i) validating and / or verifying at least one blockchain transaction; and / or ii) performing a simplified payment verification process; and / or iii) checking whether the given blockchain transaction is contained within a blockchain block; and / or iii) generating a hash of at least one of the blockchain transactions, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier in a header of the blockchain block. The method described in Appendix 2.1.

[0168] <Supplementary Note 2.7> At least one of the respective subsets of blockchain transactions includes a respective identifier associated with, identifying, and / or representing the respective subset; 2. The method according to any preceding claim.

[0169] <Appendix 2.8> Each identifier facilitates the computation of the position of each of at least one respective subset in the Merkle tree. The method described in Appendix 2.7.

[0170] <Appendix 2.9> Each identifier is based on each internal node of the Merkle tree, The method according to claim 2.7 or 2.8.

[0171] <Appendix 2.10> Each identifier contains a portion of each internal node of the Merkle tree, The method of claim 9.

[0172] <Supplementary Note 2.11> The step of allocating each subset of the blockchain transactions to a plurality of respective processing resources includes a step of matching each subset to a respective processing resource based on a respective identifier associated with each subset of the transactions; 2. The method according to any preceding claim.

[0173] <Appendix 2.12> A Merkle tree is a binary tree or mesh structure of hashes of multiple blockchain transactions. 2. The method according to any preceding claim.

[0174] <Appendix 2.13> Identifying and / or determining a subset of blockchain transactions within a plurality of blockchain transactions The method of any preceding claim, comprising:

[0175] <Supplementary Note 2.14> At least one of the multiple processing resources is or includes a virtual machine, a server, a GPU-based computing resource, or a multiprocessor system; 2. The method according to any preceding claim.

[0176] <Supplementary Note 2.15> A blockchain processing system that operates to download at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, the system including a plurality of processing resources, each of the plurality of processing resources: A processor; A memory containing executable instructions; the executable instructions, when executed by a processor, cause or enable a system to perform a computer-implemented method as set forth in any preceding clause. Blockchain processing system.

[0177] <Appendix 2.16> A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause or enable a computer system to perform or execute a computer-implemented method according to any one of Appendices 2.1 to 2.14.

[0178] According to another aspect, a non-transitory computer-readable storage medium is provided having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to perform any version of the computer-implemented methods claimed or described herein.

[0179] Appendix Set 3: <Supplementary Note 3.1> A computer-implemented method, comprising: generating, storing, and / or maintaining a first output repository for recording, retrieving, and / or processing a plurality of unspent transaction outputs respectively associated with transactions (Tx) in a plurality of blockchain transactions (TX) of a blockchain block; Including, The plurality of blockchain transactions provide and / or are represented by a portion of a Merkle tree for a blockchain block; method. In some embodiments, the first output repository may be referred to as the first UTXO output repository. An unspent transaction output may be referred to as a UTXO.

[0180] <Appendix 3.2> Generating, storing and / or maintaining at least one further output repository The method of claim 3.1, comprising:

[0181] <Appendix 3.3> Creating and / or maintaining a database log containing a history of actions, changes, and events related to the output repository The method of claim 3.1 or 3.2, further comprising:

[0182] <Appendix 3.4> The first output repository and / or the further output repository, i) Unspent Transaction Outputs, and / or ii) a) unspent transaction outputs and / or b) an identifier associated with a transaction (Tx) among multiple blockchain transactions. The method of any preceding claim, comprising at least one record associated with

[0183] <Appendix 3.5> At least one record, i) the block identifier (block_ID) associated with the blockchain block, and / or ii) A transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions. The method of claim 3.4, including a record identifier having the following:

[0184] <Appendix 3.6> i) The record identifier includes a function of a block identifier (block_ID) and a transaction identifier (TxID), and / or ii) the concatenation of a block identifier (block_ID) and a transaction identifier (TxID), and / or iii) transactions of multiple blockchain transactions are associated with unspent transaction outputs; The method described in Appendix 3.5.

[0185] <Appendix 3.7> Using the record identifier to locate, identify, access, or insert at least one record in the output repository. The method of claim 3.5 or 3.6, further comprising:

[0186] <Supplementary Note 3.8> At least one unspent transaction output in the multiple unspent transaction outputs is associated with a lock flag in the UTXO repository, and the lock flag is: i) Indicate whether unspent transaction outputs are available or unavailable; and / or ii) being configurable between a first state indicating that use of unspent transaction outputs is permitted and a second state indicating that use of unspent transaction outputs is prohibited; The method according to any preceding claim.

[0187] <Appendix 3.9> The method is i) associating unspent transaction outputs with a lock flag; and / or ii) changing the state of the lock flag from a first state to a second state or from the second state to the first state. The method of claim 3.8, comprising:

[0188] <Supplementary Note 3.10> Sending a communication from the first processing resource to the at least one further processing resource to cause the at least one further processing resource to change a state of a lock flag associated with the unspent transaction output from the first state to the second state or from the second state to the first state. The method of claim 3.8 or 3.9, further comprising: The communication may be sent to an IPv6 address associated with the at least one further processing resource using multicast transmission.

[0189] <Appendix 3.11> Communications are i) the transaction (TX), the transaction identifier (TxID), and / or the hash of the transaction (Tx), and ii) A list of one or more unspent transaction outputs The method of claim 3.10, comprising:

[0190] <Supplementary Note 3.12> Receiving a communication in at least one further processing resource; changing the state of the lock flag from a first state to a second state or from the second state to the first state; The method of claim 3.10 or 3.11, comprising:

[0191] <Appendix 3.13> i) a portion of a Merkle tree is a sub-portion or segment of a Merkle tree for a blockchain block; and / or ii) Multiple blockchain transactions are represented by interior nodes of the Merkle tree; 2. The method according to any preceding claim.

[0192] <Supplementary Note 3.14> A blockchain implementation system including a plurality of processing resources, each of which is A processor; A memory containing executable instructions; the executable instructions, when executed by a processor, cause or enable a system to perform a computer-implemented method as set forth in any preceding clause. Blockchain processing system.

[0193] <Appendix 3.15> A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause or enable a computer system to perform any of the computer-implemented methods described in Appendices 3.1 to 3.13.

[0194] Note Set 4 Any embodiment defined in any addendum or combination of addendums in addendum set 4 may be configured to implement or combine with any addendum(s) in addendum sets 1 to 3.

[0195] <Supplementary Note 4.1> A system operative to validate at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, comprising: Multiple Validation Resources each of the plurality of validation resources At least one processor associated with at least a portion of the memory that stores executable instructions. the executable instructions, upon execution by the at least one processor, cause a validation resource to: Validating at least a subset of a plurality of blockchain transactions, the at least one subset providing a portion of a Merkle tree and represented by an interior node of the Merkle tree. A system that causes or enables the execution of

[0196] <Supplementary Note 4.2> i) a load balancing component configured to facilitate balancing the distribution of a plurality of subsets of a plurality of blockchain transactions among a plurality of validation resources; and / or ii) a segment identification component configured to facilitate identification of at least a subset of the plurality of blockchain transactions; and / or iii) Allocation Units; and / or iv) One or more interfaces for sending or receiving communications between the system and one or more data sources or destinations. The system of claim 4.1, further comprising:

[0197] <Supplementary Note 4.3> The system includes at least one controller component, the at least one controller component being At least one validation resource, at least one processor of at least one validation resource; One or more interfaces, one or more load balancing components, and / or One or more segment identification components configured to facilitate identification of at least a subset of the plurality of blockchain transactions. 3. The system of claim 4.1 or 4.2, configured to affect and / or control the operation of at least one of the following:

[0198] <Supplementary Note 4.4> i) At least two of the multiple blockchain transactions are siblings in the Merkle tree, and / or ii) an internal node is a parent or ancestor of a subset of blockchain transactions; 2. The system of any preceding claim.

[0199] <Appendix 4.5> A plurality of output repositories, each of which is associated with a respective validation resource and configured to facilitate recording, retrieval, and / or processing of a plurality of unspent transaction outputs. Further equipped with Preferably, each of the plurality of unspent transaction outputs is associated with at least one transaction (Tx) in the plurality of blockchain transactions; 2. The system of any preceding claim.

[0200] <Appendix 4.6> Create and / or maintain a database log containing a history of actions, changes, and events with respect to at least one of the multiple output repositories. 4.5. The system of claim 4.5,

[0201] <Appendix 4.7> At least one of the multiple output repositories is i) Unspent Transaction Outputs, and / or ii) a) unspent transaction outputs and / or b) an identifier associated with a transaction (Tx) among multiple blockchain transactions. Contains at least one record associated with 2. The system of any preceding claim.

[0202] <Appendix 4.8> At least one record, i) the block identifier (block_ID) associated with the blockchain block, and / or ii) A transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions. The system of claim 4.7, further comprising a record identifier having:

[0203] <Appendix 4.9> The record identifier is i) a function of the block identifier (block_ID) and the transaction identifier (TxID), and / or ii) A concatenation of the block identifier (block_ID) and the transaction identifier (TxID) 9. The system of claim 4.7 or 4.8,

[0204] <Appendix 4.10> The system is Using the record identifier to locate, identify, access, or insert at least one record in at least one output repository among the plurality of output repositories. 10. The system according to claim 8 or 9, which operates as follows:

[0205] <Supplementary Note 4.11> At least one unspent transaction output (UTXO) among the multiple unspent transaction outputs (UTXOs) is associated with a lock flag, and the lock flag is i) Indicate whether unspent transaction outputs are available or unavailable; and / or ii) being configurable between a first state indicating that use of unspent transaction outputs is permitted and a second state indicating that use of unspent transaction outputs is prohibited; 11. The system of any of Clauses 4.5 to 4.10.

[0206] <Appendix 4.12> The system is Change the state of a lock flag from a first state to a second state or from a second state to the first state The system of claim 4.11,

[0207] <Appendix 4.13> i) Allocating each subset of blockchain transactions to multiple validation resources; and ii) using one, some, or all of the multiple validation resources to download and / or receive respective subsets of the blockchain transactions; 2. The system of any preceding claim, operative to:

[0208] <Appendix 4.14> Using one, some, or all of the validation resources to generate candidate internal nodes for each of the Merkle trees based on each downloaded subset of blockchain transactions. It operates to do Verifying that each candidate internal node matches a respective internal node of the Merkle tree; and / or verifying that each candidate internal node is a node of the Merkle tree by performing a Merkle proof based on the root of the Merkle tree; and / or sending each candidate internal node of the Merkle tree to one or more other processing resources; The system of any preceding claim, further operative to perform at least one of the following:

[0209] <Appendix 4.15>i) validating and / or verifying at least one blockchain transaction; and / or ii) carrying out a simplified payment verification process; and / or iii) verifying whether a given blockchain transaction is contained within a blockchain block; and / or iii) generating a hash of at least one of the blockchain transactions, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier in a header of the blockchain block. 2. The system of any preceding claim, operative to:

[0210] <Supplementary Note 4.16> At least one of the multiple validation resources is or includes at least one of a virtual machine, a server, a GPU-based computing resource, a thread, and / or a multiprocessor system; 2. The system of any preceding claim.

[0211] Note Set 5 Any embodiment defined in any addendum or combination of addendums in addendum set 4 may be configured to implement or combine with any addendum(s) in addendum sets 1 to 4.

[0212] <Supplementary Note 5.1> A computer-implemented method comprising: identifying and / or allocating processing and / or storage resources using a portion of data derived from a blockchain, the data from which the portion of the data is derived comprising unspent transaction outputs and / or transactions (Tx) comprising unspent outputs.

[0213] Information associated with the data derived from the blockchain is stored in a resource for efficient and cost-effective reference. By allocating resources using a portion of the data, a relationship between the data, its associated information, and the resource on which it is stored is maintained. The data may include unspent transaction outputs (e.g., UTXOs) and / or transactions (Tx) that include unspent outputs. The portion of the data is used to determine a key, which determines the allocated resource that will store information about the data.

[0214] A database of UTXOs and / or transactions having UTXOs can be established. The database can be distributed to obtain a distributed pool. The database can hold at least one of a validity flag of the unspent transaction output (UTXO) and / or the transaction (Tx) including the UTXO, and information that allows the validity of the unspent transaction output (UTXO) and / or the transaction (Tx) including the UTXO to be determined, e.g., SPV information such as at least a portion of a Merkle proof that can be used for SPV validation or SPV related operations.

[0215] Prior to the allocation enabling subsequent identification of the resource, the method may include retrieving a portion of the derived data and / or associated data from the blockchain. Following the allocation, the method may include storing and / or validating the unspent transaction output (UTXO) and / or the transaction (Tx) including the UTXO.

[0216] This allocation makes it possible to support load balancing among multiple resources.

[0217] <Supplementary Note 5.2> The method described in Supplementary Note 1 further comprising a step of storing and / or processing at least a portion of the UTXO and / or transaction (Tx) in and / or by and / or in association with the allocated resources.

[0218] The processing step may include at least one of validating the UTXO and / or the transaction (Tx) and managing information associated with the data in an accessible structure, such as a database.

[0219] <Supplementary Note 5.3> The method of Supplementary Note 5.1 or 5.2, further comprising the steps of receiving the data from which a portion of the data is derived in allocated resources, and parsing the data to process the data and / or store information derived from the data or to decide whether to take no action.

[0220] One or more resources may receive a portion of the data and / or information associated with said data and determine whether it is responsible for storing information related to said UTXO.

[0221] <Appendix 5.4> A method as described in any preceding appendix, further comprising deriving a portion of the data from the blockchain.

[0222] <Appendix 5.5> A method as claimed in any preceding appendix, wherein the identification and / or allocation of processing and / or storage resources is performed by an intermediate means connected to a plurality of allocated resources.

[0223] <Supplementary Note 5.6> A method as in any preceding supplementary note, wherein the allocated resources at least partially validate unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs, and generate, store, and / or maintain records of validation data required to validate unspent transaction outputs (UTXOs) and / or transactions (Tx) that include UTXOs.

[0224] <Appendix 5.7> The method of appendix 5.1, wherein the data includes at least one of a UTXO identifier, a hash of the UTXO script, and a transaction identification (TXID).

[0225] <Appendix 5.8> The method of any preceding appendix, wherein processing the data includes determining a key, the key determining the allocated resources.

[0226] <Addendum 5.9> The method of Addendum 5.8, in which the key is hashed and the resulting hash determines the allocated resource.

[0227] <Addendum 5.10> The method of any preceding addendum, wherein at least one of the data, the key, and the resulting hash includes at least one of alphanumeric and binary numbers, said numbers being used to determine allocated resources.

[0228] <Appendix 5.11> The method of appendix 5.10, in which a portion of the number is parsed to determine allocated resources.

[0229] <Appendix 5.12> The method of any preceding appendix, wherein a hash table determines the allocated resources in which at least a portion of a UTXO and / or transaction (Tx) is stored.

[0230] <Supplementary Note 5.13> A method according to any of Supplements 5.6 to 5.12, wherein at least some of the records include at least one of a Merkle tree of a block in which the transaction (Tx) is recorded, a Merkle root of the block in which the transaction (Tx) is recorded, a Merkle path that enables determining the value of the Merkle root for the block in which the transaction (Tx) is recorded from a hash of the transaction (Tx), a Merkle proof, a block identifier (block_ID) associated with the blockchain block, a transaction identifier (TxID) associated with a transaction (Tx) in a plurality of blockchain transactions in the blockchain block, a function of the block identifier (block_ID) and the transaction identifier (TxID), and a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0231] <Appendix 5.14> The method of any preceding appendix, further comprising at least one of the following steps for at least a portion of a transaction (Tx) and / or the UTXO: validating and / or verifying the UTXO; performing at least a portion of a Simplified Payment Verification (SPV) process on the UTXO; verifying whether a given blockchain transaction (Tx) is included within a blockchain block; generating a hash of at least one of the blockchain transactions and constructing a Merkle path using the hash and / or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block; and determining a Merkle proof for the UTXO.

[0232] <Supplementary Note 5.15> A computer-implemented method comprising: generating, storing and / or maintaining a first UTXO resource for recording, retrieving and / or processing a plurality of unspent transaction outputs (UTXOs) associated with transactions (Tx) in a plurality of blockchain transactions (TX) of a blockchain block; and identifying and / or allocating said resource using a portion of data derived from the blockchain, wherein the data from which the portion of the data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) including UTXOs.

[0233] <Supplementary Note 5.16> A computer-implemented method comprising: receiving and / or processing an unspent transaction output (UTXO) for inclusion in a transaction; and / or using a portion of data derived from the UTXO to identify an allocated resource, the allocated resource maintaining validation data for the UTXO; and / or requesting validation data from the allocated resource.

[0234] <Appendix 5.17> From the allocated resources, (i) the validation of the UTXO and / or the transaction (Tx) that contains said UTXO; and / or (ii) A record to determine the validity of the UTXO and / or the transaction (Tx) that contains the UTXO. The method of claim 5.16, further comprising the step of obtaining at least one of:

[0235] <Addendum 5.18> A method as described in any preceding addendum, further comprising preparing and / or sending a transaction (Tx) having the UTXO as input.

[0236] <Supplementary Note 5.19> A blockchain node configured to at least one of generate, store, and maintain UTXO resources for recording, retrieving, and / or processing a plurality of unspent transaction outputs (UTXOs), the node processing a portion of data derived from a blockchain to identify and / or allocate processing and / or storage resources, the data from which the portion of the data is derived including unspent transaction outputs (UTXOs) and / or transactions (Tx) including UTXOs.

[0237] <Appendix 5.20> A computing device comprising a memory having one or more memory units and a processing device having one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured, when on the processing device, to perform a method according to any one of Appendices 5.1 to 5.18.

[0238] <Appendix 5.21> A computer program embodied in a computer-readable storage device and configured, when executed on one or more processors, to perform the method according to any of Appendices 5.1 to 5.18.

[0239] Exemplary Technology Environment for Implementing Exemplary Embodiments of the Present Disclosure We now provide an overview of a computing environment in which one or more embodiments of the present disclosure may be implemented. However, as noted above, this context is not intended to be limiting, and embodiments may be implemented for processing data records and structures that are not implemented via blockchain. Non-blockchain embodiments may be devised, for example, using databases rather than distributed ledgers.

[0240] FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may be comprised of a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0242] The blockchain 150 includes a chain of data blocks 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a decentralized or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing an amount of digital assets as a property, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or used). Each input points to the output of a preceding transaction 152, thereby linking the transactions.

[0243] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain to define an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer back to a previous transaction to define an order for the sequence of transactions (Note: a sequence of transactions 152 can branch). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0244] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. This refers to an ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0245] For a given current transaction 152j, its input (or each input) contains a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. Although a preceding transaction 152i must exist and be validated for the current transaction to be valid, a preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or transmitted to the network 106. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by a pointer, and not necessarily to the time of creation or transmission in the time sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i is also referred to as an antecedent transaction or a predecessor transaction.

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

[0247] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (manually or by an automated process adopted by the party), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which is currently typically a server or a data center, but in principle could be other user terminals). It is not excluded that the party 103 enacting the new transaction 152j sends the transaction directly to one or more of the blockchain nodes 104 and in some examples does not send it to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of them. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction uses (or "assigns"), which condition typically includes at least checking that 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 defined at least in part by a script included in the output of the preceding transaction 152i. Alternatively, it may be fixed solely by the blockchain node protocol or by a combination of these.In any event, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

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

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

[0250] The first blockchain node 104 to solve the puzzle publishes this to the network 106 and provides its solution as a proof that can be easily checked later by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the output of the hash satisfies the conditions). This first blockchain node 104 propagates the block to threshold consensus of other nodes that accept this block and enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution indicates the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it uses or assigns the same output as a previously validated transaction (also known as double-spending). Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0251] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n, and in what order, the current pool of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined, ordered pool of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may occur if two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate between the nodes 104. In essence, whichever prong of the fork grows the longest will be the deterministic blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both forks.

[0252] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate the additional amount of accepted digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but may also be referred to as an "initiation transaction" or "generation transaction." This typically forms the first transaction of a new block 151n. The proof of work indicates the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturity period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generative) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and is explained below.

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

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

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

[0256] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but are not blockchain nodes 104 because they do not fulfill the role required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting (i.e., communicating) with the blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes, namely, a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that there may be many more such parties 103 and their respective computer devices 102 and they may participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, although it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

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

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

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

[0260] It should be noted that various client functions may be described as being integrated into a given client application 105, but are not necessarily limited thereto; instead, any client functionality described herein may be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer or a lower layer, such as an operating system, or any combination thereof. The following description is given with respect to client application 105, but will be understood to be non-limiting.

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

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

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

[0264] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but whichever node solves it first defines the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it universally becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 contains a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

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

[0266] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of the preceding transaction in the sequence of past transactions. The current state of every account is stored and constantly updated by the nodes of the network separately from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field in the transaction may also be signed. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0267] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. It is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). In the following, it is 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 the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0268] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include a transaction ID of the underlying transaction, among other information. The transaction data structure may also include a header 201 that may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 that is submitted to the node 104.

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

[0270] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 106 together, or even Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of the transactions in a sequence defined by transaction pointers (e.g., which transactions point to which other transactions) specified in the transactions. They may similarly be replaced with "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. This does not necessarily imply the order of their creation, transmission to the network 106, or arrival at any given blockchain node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for the parent or discarded, depending on the node protocol and / or node behavior.

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

[0272] A lock script (commonly called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies what information is needed to use the transaction output 203, e.g. the need for Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0273] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P A Requires lock script [Checksig P A ]. [Checksig P A ] is the public key P of Alice's public-private key pair.A Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key of her key pair to a given portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0274] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that are composed in the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create Alice's public key P as contained in the lock script in the output of Tx0. A, to authenticate that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. In order to perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the data to be signed includes the entirety of Tx1 (i.e., a separate element specifying the signed portion of the plaintext data does not need to be included, as that is already inherently present).

[0275] The details of public-private cryptographic authentication are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular portion of data or part of a transaction, etc., may, in embodiments, mean signing a hash of that portion of data or part of a transaction.

[0276] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, 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 the ordered pool 154 of pending transactions. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that the transaction Tx1 is propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it uses unspent transaction outputs 203. If it attempts to use an output that has already been used by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it already formed a valid input to another valid transaction in the blockchain 150.

[0277] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another ground of invalidity in most transaction models, so such a transaction will not be propagated or included in block 151.

[0278] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined as spent in the UTXO cannot be "left" while another part is spent. However, it is possible to split the amount from the UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use a reminder to give the remainder to herself in the second output of Tx1 or to pay another party.

[0279] In practice, Alice would also typically need to include a fee for any Bitcoin node 104 that successfully includes Alice's transaction 104 in a block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus may not be propagated and included in the blockchain 150, even if it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). 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 given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or used) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0280] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. No number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to collate together all the values ​​of the various UTXOs that are locked to the respective parties and that have not yet been used in another subsequent transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0281] Note that scripting code is often represented generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in the scripting language. As an example, OP_RETURN is an opcode in the scripting language that creates an unusable output of a transaction that can store data in the transaction when preceded by OP_FALSE at the beginning of the lock script, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

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

[0283] A lock script may typically be referred to as a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script may typically be referred to as a "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, any condition or conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0284] Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a (at the instigation of either party or a third party) to establish a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data apart from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction (yet) being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0285] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, anywhere in this specification, the side channel 107 referred to may include any link or links over one or more networking technologies or communication media for exchanging data "off-chain", i.e., apart from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange information or particular pieces of data, etc., over the side channel 107, this does not necessarily mean that all of these pieces of data must be transmitted over the exact same link or the same type of network.

[0286] conclusion Other variations or use cases of the disclosed techniques may become apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims. For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

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

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

[0289] Even more generally, any reference above to the term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element”, where such entity / element is configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0290] The term "user" may be used herein to include human and machine-based entities.

[0291] The above-described embodiments are illustrative rather than limiting of the disclosure, and those skilled in the art could design many alternative embodiments without departing from the scope of the disclosure, which is defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the scope of the claims. Terms such as "comprising" and "comprises" do not exclude the presence of elements or steps other than those listed in the claim or the specification as a whole. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consisting of". It will be understood that throughout this specification, the word "comprise", or variations such as "includes", "comprises" or "comprising" are meant to include the stated elements, integers or steps, or groups of elements, integers or steps, and are not meant to exclude any other elements, integers or steps, or groups of elements, integers or steps. The singular reference of an element does not exclude the plural reference of such element, and vice versa. The disclosure can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. 1. A computer-implemented method comprising: identifying and / or allocating processing and / or storage resources using a portion of data derived from the blockchain, the data from which the portion of data is derived including unspent transaction outputs and / or transactions (Tx) including unspent transaction outputs; A method comprising:

2. storing and / or processing said unspent transaction outputs and / or at least a portion of said transactions (Tx) in and / or by and / or in association with said allocated resources; The method of claim 1 further comprising:

3. receiving the data from which a portion of the data is derived in the allocated resources; Parsing the data (i) processing said data and / or storing information derived from said data; (ii) Take no action determining The method of claim 1 further comprising:

4. The method of claim 1 , further comprising deriving a portion of the data from the blockchain.

5. said identifying and / or allocating processing and / or storage resources is performed by an intermediate means connected to a plurality of allocated resources; The method of claim 1.

6. The allocated resources are: at least partially validating said unspent transaction output and / or a transaction (Tx) including said unspent transaction output; and generating, storing, and / or maintaining records of validation data required to validate said unspent transaction outputs and / or transactions (Tx) including unspent transaction outputs; The method of claim 1 , further comprising:

7. The data is Unspent transaction output identifiers, hash of unspent transaction output script, Transaction Identification Information (TXID) The method of claim 1 , comprising at least one of:

8. The method of claim 1 , wherein processing the data includes determining a key, the key determining the allocated resources.

9. The method of claim 8 , wherein the key is hashed and the resulting hash determines the allocated resources.

10. At least one of the data, the key, and the resulting hash is Alphanumeric and binary numbers and the number is used to determine the allocated resources. The method of claim 1.

11. The method of claim 10 , wherein a portion of the number is parsed to determine the allocated resources.

12. The method of claim 1 , wherein a hash table determines the allocated resources in which the unspent transaction outputs and / or at least a portion of the transaction (Tx) are stored.

13. At least some of the records are: A Merkle tree of the block in which the transaction (Tx) is recorded; The Merkle root for the block in which the transaction (Tx) is recorded; a Merkle path that allows determining, from the hash of the transaction (Tx), the value of the Merkle root for the block in which the transaction (Tx) is recorded; Merkle proof, The block identifier (block_ID) associated with the blockchain block, a transaction identifier (TxID) associated with a transaction (Tx) among the plurality of blockchain transactions in the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); and a concatenation of the block identifier (block_ID) and the transaction identifier (TxID); The method of claim 6 , comprising at least one of:

14. For at least a portion of the transactions (Tx) and / or unspent transaction outputs, validating and / or verifying said unspent transaction outputs; performing at least a portion of a simplified payment verification (SPV) process on said unspent transaction output; Checking whether a given blockchain transaction (Tx) is included in a blockchain block; generating a hash of at least one of the blockchain transactions, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block; and determining a Merkle proof of said unspent transaction output. The method of claim 1 , further comprising at least one of:

15. 1. A computer-implemented method comprising: generating, storing, and / or maintaining a first unspent transaction output resource for recording, retrieving, and / or processing a plurality of unspent transaction outputs respectively associated with transactions (Tx) among a plurality of blockchain transactions (TX) of a blockchain block; identifying and / or allocating the first unspent transaction output resource using a portion of data derived from a blockchain, the data from which the portion of data is derived including unspent transaction outputs and / or transactions (Tx) including unspent transaction outputs; A method comprising:

16. 1. A computer-implemented method comprising: receiving and / or processing unspent transaction outputs for inclusion in a transaction; and / or using a portion of the data derived from the unspent transaction output to identify an allocated resource, the allocated resource holding validation data for the unspent transaction output; and / or requesting the validation data from the allocated resource. A method comprising:

17. From the allocated resources, (iii) validating the unspent transaction output and / or the transaction (Tx) including the unspent transaction output; and / or (iv) a record for determining the validity of the unspent transaction output and / or the transaction (Tx) including the unspent transaction output; obtaining at least one of 17. The method of claim 16, further comprising:

18. 1. A blockchain node configured to at least one of generate, store, and maintain an unspent transaction output resource for recording, retrieving, and / or processing a plurality of unspent transaction outputs, the blockchain nodes process a portion of the data derived from the blockchain to identify and / or allocate processing and / or storage resources; the data from which the portion of the data is derived includes unspent transaction outputs and / or transactions (Tx) including unspent transaction outputs; Blockchain node.

19. A computer device comprising: a memory comprising one or more memory units; A processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code configured to execute the method of any one of claims 1 to 17 when present on the processing device; 1. A computer device comprising:

20. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 17 when executed on one or more processors.

Images