Computer-implemented scheme for recording data relating to plurality of components of item

Abstract

The invention relates to a computer-implemented method for processing a tree structure representing an item and / or at least one component of said item. And associating the item and / or the at least one component of the item with a block chain transaction, wherein the block chain transaction is represented in the tree structure. Processing may include at least one of generating, storing, accessing, and maintaining the tree structure. The tree structure may be a hash tree. The tree structure may be asymmetric, such as an ontology tree. A record of the item and / or the at least one component of the item may be processed. The items and / or components may be tracked and verified through the tree structure and associated data. Verification may include at least one of: verifying whether at least one of the item, the at least one component of the item, and at least a portion of a blockchain transaction (Tx) is part of the tree structure; and processing and / or storing at least one of the item, the at least one component of the item, and at least a portion of the blockchain transaction (Tx) in the allocated resource (1104).

Description

Technical Field

[0001] The present disclosure generally relates to improved methods and systems for processing and / or managing data records and / or the format and / or content of such records. The present disclosure is particularly suitable, but not limited to, for use in transactions implemented on or using blockchain networks, such as determining storage allocations, pre-mining and / or post-mining verification of blockchain transactions, SPV checks, and the like. Advantages include, but are not limited to, improved security, resilience, and efficiency, or reduced speed and resource requirements, enabling novel resource verification and balancing methods not possible with prior art arrangements, thereby enabling previously unattainable blockchain implementation arrangements. The improved methods and systems are suitable for recording and / or verifying items and / or their subcomponents in at least one of the following ways: temporarily, over time, and through application changes. Background Art

[0002] While the Bitcoin protocol and network may be referred to herein for the purpose of providing an illustrative context for implementation, the present disclosure is not limited to use with the Bitcoin blockchain, and alternative protocols and implementations are within the scope of this disclosure.

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

[0004] In order for a transaction (Tx) to be written to the blockchain, it must be verified. Network nodes (miners) work to ensure that each transaction is valid, and invalid transactions are rejected by the network. Software clients installed on these nodes perform this verification on unspent transaction outputs (UTXOs) by executing their locking and unlocking scripts. If the locking and unlocking scripts evaluate to true, the transaction is valid and written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must: i) be verified by the first node that receives it. If verified, the node relays it to other nodes in the network, meaning it is propagated; ii) be included in a new block constructed by miners; and iii) be mined, meaning it is added to the public ledger of past transactions. Once a transaction is stored as a UTXO on the blockchain, the user can transfer control of the associated cryptocurrency to another address associated with an input in another transaction subsequently written to the blockchain. This is typically accomplished using a digital wallet that stores the public and private key pairs associated with the user's cryptocurrency. There are many known forms of cryptocurrency wallets, including SPV wallets (Simplified Payment Verification). SPV technology allows users and merchant nodes to perform local verification based on only partial information related to a specific transfer. SPV is discussed in more detail below.

[0005] However, given the expected increase in transaction volume, the ability to quickly determine the validity of unspent transaction outputs (UTXOs) will be required. Current techniques for verifying this can be resource-intensive and time-consuming due to the need to download and store blocks, maintain a large UTXO pool, and perform the necessary verification processing. Many users are either unable or unwilling to meet these requirements, as they may not need to. Therefore, a faster, more efficient verification model is needed that can at least address these challenges (and others) without compromising security or requiring adaptation to existing protocols. Furthermore, the verification approach must be scalable. Such an improved approach has now been designed. Summary of the Invention

[0006] Embodiments of the present disclosure provide improved blockchain-related methods, devices, and systems. According to one form of wording, such embodiments provide a scheme for identifying and / or allocating processing and / or storage of data related to at least a portion of a blockchain transaction (e.g., outputs, such as UTXOs that include and / or enable verification).

[0007] In some embodiments, a tree structure is processed. The tree structure schematically represents the relationship between an item and at least one of its components. The tree structure can enable recording and / or verification of the item and / or at least one component. Hereinafter, for convenience only, the term "track" can be used as a substitute for "record". For example, a tree structure can be recorded at a certain point in time to record the immediate status of an item, component, or inventory; the tree structure can change over time, which can reflect updates to the status and / or configuration of an item or information related to the item, as well as updates to the status and / or configuration of a component of the item or information related to the component; and even when updated, the application of an item or component can be tracked, wherein a first tree structure is used in a first application to track one of the items or its components, and a second tree structure is used in a second application to track one of the items or its components, thereby tracking the history of the item or its components in different usage scenarios. In general, the tree structure can be used to track the process of an item from creation to final use or disposal, such as end-to-end project tracking. Using the tree structure to track the items enables the contents of the tree structure (i.e., the items and / or components) to be verified as part of the tree structure. The status of the items or components can be recorded based on their progress in a process over time.

[0008] Item tracking can be achieved by associating the item and / or at least one component of the item with a blockchain transaction (Tx), which is represented in the tree structure. The blockchain transaction may include data associated with the root of the tree structure, such that any data in the tree can be verified therefrom. For example, the tree structure may be a hash tree, and the data associated with the root of the tree structure may include a hash of the root of the tree structure. At least one of a node and a leaf of the tree structure may also be associated with a blockchain transaction.

[0009] Data associated with an item or component can be stored in a record associated with a blockchain transaction. In some embodiments, item tracking can utilize the techniques disclosed herein, for example, by determining that a record comprising transaction data proving at least a portion of a transaction (Tx) is included in the tree structure. The record can include a proof. For example, the proof can include a Merkle path that enables verification that a component is part of the tree structure. Further, the Merkle path can enable verification that the tree structure (e.g., its root hash) is part of a blockchain block (B). The record can include a data directory that is or includes a set of the transaction data.

[0010] In other embodiments, a portion of the data derived from the blockchain (e.g., the transactions) may be used to identify and / or allocate processing and / or storage resources.

[0011] Item tracking and / or verification may include processing a record of the item and / or the at least one component of the item. Processing the tracked item as part of a tree structure enables verification of whether at least one of the item, the at least one component of the item, and at least a portion of a blockchain transaction (Tx) is part of the tree structure. Further, allocated resources may be used to process and / or store at least one of the item, the at least one component of the item, and at least a portion of a blockchain transaction (Tx).

[0012] Using the tree structure and techniques herein to improve item verification can achieve a structured, dynamic method and system for tracking and / or verifying the tree structure or a portion thereof. Furthermore, verifying whether an item or component is part of a tree structure can be securely achieved without disclosing confidential information associated with other items or components of the tree structure.

[0013] Using allocated resources can improve the scalability of applications of the tree structure by providing a secure solution for controlling, managing and / or improving the efficiency, resource requirements, speed and / or resilience of known processing methods for blockchain transactions.

[0014] The validity and / or provenance of an item or its components can be tracked across multiple tree structures, each tree structure representing the item and / or the at least one component of the item in a different application or usage scenario. Within a further tree structure (e.g., a second tree structure), the item and / or the at least one component of the item can be associated with a further (e.g., a second) blockchain transaction (Tx), which is represented in the further (e.g., second) tree structure.

[0015] During the verification process, the teachings of WO2017 / 145016 may be used to securely exchange and verify data, the teachings of which are incorporated herein by reference in their entirety.

[0016] Embodiments of the present disclosure provide improved blockchain-related methods, devices, and systems. According to one form of wording, such embodiments provide a scheme for tracking an item, at least one component of the item, and at least a portion of a blockchain transaction associated with the item and / or component. The blockchain transaction may be stored on one or more of a plurality of resources, which may be distributed. Additionally or alternatively, the resource may be accessed to retrieve (i) confirmation of the validity of a transaction (e.g., a UTXO) and / or (ii) data enabling determination of the validity of the associated transaction.

[0017] The various embodiments of the present disclosure may be implemented in part or in whole by various devices. These devices 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, embodiments may include one or more digital wallets. However, importantly, embodiments provide a mechanism for distributed processing of blockchain-related verification tasks. The coordination, management, and control of known distributed processes are inherently technical, as they require a comprehensive understanding of the interactions between the hardware and software components involved, and the implementation of such distributed solutions is beyond the technically trivial.

[0018] Various embodiments may include solutions that implement or facilitate efficient identification and / or allocation of resources that perform at least one of storing and verifying 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 not only balances the distribution of information across resources, but also balances utilization, such as user accessibility to information, which can mitigate bottlenecks.

[0019] Various embodiments may include distributing verification tasks among multiple processing resources, which for convenience are referred to as “verifiers.” A verifier may include a single processing resource or multiple related processing resources that may be collectively considered verification resources.

[0020] The method for identification / allocation supports uniform distribution of information across multiple resources and / or scalability because it is based on pseudorandom data obtained from the blockchain. When information about a blockchain transaction (e.g., a UTXO) is needed, the resource can be accessed to retrieve at least one of the following: (i) confirmation of the validity of the UTXO and / or associated transaction; (ii) data capable of determining the validity of the UTXO and / or associated transaction; and (iii) an indication and / or proof that the resource or verifier has performed verification.

[0021] In one or more embodiments, a verifier may include or have access to a repository that records data related to the work it has performed and / or the data it has processed. In one embodiment, this may include a database that includes the unspent transaction outputs (UTXOs) that have been assigned to a given verifier for processing. It should be remembered that in the traditional model, all UTXOs on the blockchain are tracked by nodes in a database called the UTXO pool. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0023] Figure 1 A schematic block diagram of a system for implementing a blockchain.

[0024] Figure 2 Some examples of transactions that may be recorded in a blockchain are schematically shown.

[0025] Figure 3 A diagram of a general Merkle tree structure known in the art is provided.

[0026] Figure 4 It is shown how a Merkle root can be derived from a set of blockchain transactions as is known in the art.

[0027] Figure 5 An example is provided of how a Merkle tree may be partitioned into subsets (or "segments") according to embodiments of the present disclosure, which may then be assigned to respective verification resources.

[0028] Figure 6 shows how the Merkle tree can be divided into logical segments Figure 5 An alternative example of .

[0029] Figure 7 A system-level distributed verification node is shown according to an illustrative embodiment of the present disclosure.

[0030] Figure 8 A simplified flow chart showing the steps involved in an illustrative method of the present disclosure is shown.

[0031] Figure 9 Shown in more detail Figure 7 Illustration of an exemplary system.

[0032] Figure 10 is a schematic diagram of an example of the present invention, including identification and / or allocation of resources that generate, store, or maintain a database of information associated with transactions, examples of which are unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0033] Figure 11 (a) to Figure 11 (d) is a table showing examples of values ​​derived from partial data for identifying determined allocated resources.

[0034] Figure 12 is a schematic diagram of a system including nodes, intermediate switches, and allocated resources with optional verifiers.

[0035] Figure 13 Schematic diagram of two transactions in a Merkle tree of a blockchain block, the transactions having allocated resources and the allocated resources holding corresponding records.

[0036] Figure 14 a is a diagram of an asymmetric tree structure, where the root node represents an item, the nodes and leaves represent the components of the item, and Figure 14 b means Figure 14 Two subsequent blockchain transactions associated with a node or leaf in (a).

[0037] Figure 15 is a schematic diagram of two tree structures in which blockchain transactions associated with nodes or leaves, such as 14(a), are processed and / or stored in allocated resources (1104).

[0038] Figure 16 is a flowchart showing a method of processing a tree structure. DETAILED DESCRIPTION

[0039] For purposes of illustration and not limitation, and with reference to the accompanying drawings, exemplary embodiments of the present disclosure are described below.

[0040] A manner for processing and / or storing information related to transactions (e.g., unspent transaction outputs (UTXOs)) and / or transactions (Tx) containing UTXOs can be implemented using various systems and methods, which can be configured and / or executed independently. Examples of a "transaction database" and "block verification" are described below, each of which assigns a task to a resource, such as a distributed resource, including storing and / or verifying one or more transactions.

[0041] Below, examples of allocating / identifying resources are described in conjunction with the "UTXO database," where information (e.g., records) are allocated to resources. Furthermore, examples of verifying transactions and the techniques / management of verification, such as "block verification," are also described below.

[0042] Additionally or alternatively to the examples of "assigning" and / or "verifying," at least one example includes generating, storing, processing, accessing, and / or maintaining a record of at least a portion of a transaction (Tx). Information stored in association with the transaction (e.g., the record) may be used to at least support verification of the transaction. For example, the record may include transaction data used to determine that at least a portion of the transaction is included in a Merkle path of a blockchain block.

[0043] The techniques taught herein are suitable for tracking an item and at least one component of the item using a tree structure. The tree structure schematically represents the relationship between an item and at least one component. The state of the item and / or its component can be associated with the tree structure via a blockchain transaction. The transaction can be used to determine the verification and / or provenance of the item and / or component from the point at which the tree structure is first used to track the item and / or component. Tracking can be performed using a single tree structure or multiple tree structures. Each tree structure can represent the replacement relationship between the item and / or component and different items and / or different components. The tree structures can be independent, and multiple tree structures can be used to track an item and / or at least one component of the item with a migrated blockchain transaction (Tx). The tree structure can be a Merkle tree, a binary tree, an ancestor tree, an asymmetric tree, or other unbalanced tree.

[0044] Thus, novel aspects of the present disclosure may be viewed as including, but not limited to, using a tree structure to represent the constituent components of an item, each component being associated with a transaction on a blockchain.

[0045] Advantages include being able to track or verify the item at a granular level through the tree structure even if the state of the item or its components changes over time.

[0046] A record associated with an item and / or at least one component of the item can be managed using a blockchain transaction, which can be part of a blockchain token. The record can include information about the item or component, and data about the tree structure can associate the item and / or at least one component of the item with the blockchain transaction.

[0047] Features of the examples may be combined according to the teachings herein.

[0048] Tracking using a tree structure

[0049] Figure 14 (a) shows a schematic diagram of an asymmetric tree structure 1400 having a root node 104 and multiple nodes 1402 and leaves 1404. For example, the root node represents an item, while the nodes and leaves represent components of the item. The tree structure represents the relationship between the item and the components. Each item and / or at least one component of the item can be associated with a blockchain transaction. The item and / or at least one component of the item can be tracked, managed, or verified using the associated blockchain transaction, which can be associated with a blockchain token.

[0050] The tree structure can be used to determine the verification and / or provenance of items and / or components. This can be achieved through the association between data within the nodes and leaves, and preferably through the blockchain transactions associated therewith.

[0051] The tree structure can be a hash tree (e.g., a Merkle tree), which is a tree-like data structure used in encryption to efficiently aggregate large amounts of data and prove the authenticity of the aggregated data. Each leaf node 1404 represents a block of data, and each non-leaf node (i.e., node 1402) is a hash of its child nodes. The root node 104 is a summary of all the data in the tree and can be calculated as a hash of all the concatenated leaf node hashes.

[0052] Processing the tree structure 1400 enables the authenticity of the data in the tree structure to be determined using techniques such as root hashing and / or proof of use and simple payment verification.

[0053] Thus, by associating an item and / or at least one component of the item with a blockchain transaction (Tx), the blockchain transaction (Tx) being represented in a tree structure, and processing the tree structure, or a portion thereof, representing the item and / or at least one component of the item, at least the validity of the item or component can be determined. Processing can include at least one of generating, storing, accessing, and maintaining the tree structure. Updates to data associated with, for example, a record of the item or component or the entire tree structure can be updated, and the tree structure and associated items can be tracked.

[0054] By creating a tree structure 1400 to track an item and / or its components, and by associating the item and / or at least one component of the item with a blockchain transaction, the verification and / or provenance of the item and / or component can then be determined from the point at which the tree structure was first used to track the item and / or component.

[0055] The tree structure can change over time when at least one of the data, state, and attributes of the items and components of the nodes and leaves is updated. The use of association with blockchain transactions enables tracking. Figure 14 (b) is a representation of one of the root node 104, node 1402, or leaf 1404 being updated, where the first associated blockchain transaction Tx n Updated to TX n+1 Transactions are linked, and records can be immutably determined based on the blockchain. For example, blockchain tokens can be used to manage data associated with nodes or leaves. In one example, only the root node 104 or its hash is recorded on the chain, and each of the leaves and nodes can also be recorded.

[0056] A record of an item and / or component can be associated with a blockchain transaction, which can serve as a data package associated with the item or component. A record is an example of transaction data, i.e., data stored within a blockchain transaction (e.g., within a blockchain transaction script). A record can store data about a tree structure that can be generated, stored, accessed, and subsequently maintained. A record can store data that can be used to (i) verify an item, component, or tree structure and / or (ii) determine the processing and storage of data associated with the tree structure, such as data associated with the item or component.

[0057] Once processed, the tree structure can be used to verify whether at least one of an item, at least one component of the item, and at least a portion of a blockchain transaction (Tx) is part of the tree structure. The blockchain transaction can be used to implement processing, such as verification or storage. Figures 10 to 13 Describe examples of storage and verification techniques.

[0058] Tracking and / or verification can include computing a hash for each node in a tree structure, where the hash of a node is the hash of its concatenated child nodes. All hashes in the tree structure can be checked to ensure that the tree structure has not been tampered with. This can be achieved by computing a hash for each node in the tree, where each node in the tree structure is assigned a unique hash value that is calculated based on the data stored in the node and the hashes of its child nodes. The parent node hash can then be compared with the child node hashes, starting from the leaf nodes and traversing the tree upwards to compare the hash value of each parent node with the hash of its child nodes. If the hashes match, it indicates that the data stored in the child node has not been tampered with. This process can be repeated for all nodes, so that if all hashes are consistent, the tree structure is determined to be authentic and has not been altered. In general, the root hash can be used to determine the authenticity of the root node (which summarizes the tree structure) by comparing the hash value of the root node with a previously stored or distributed trusted hash value (e.g., on a public blockchain or a server running a private blockchain).

[0059] Additionally or alternatively, once processed, the tree structure can be used to process and / or store at least one of an item, at least one component of the item, and at least a portion of a blockchain transaction (Tx) in the allocated resources 1104. The tree structure itself can be stored in the allocated resources. While each leaf and associated data can be stored, for example, for verification purposes, a hash of the root node 104 of the tree structure can additionally or alternatively be stored in the blockchain transaction, for example, on a blockchain ledger. The ledger (i.e., blockchain) can be generated according to a blockchain protocol implemented by nodes in the blockchain network.

[0060] In one example, if Figure 14As shown, the tree structure remains unchanged, meaning the items and components maintain the same relationships. In this case, the items and / or components can be associated with at least one blockchain transaction to create a record for the tree structure. In practice, each item and component can be associated with its corresponding blockchain transaction. The tree structure can be a hash tree, and the root hash and / or hashes of at least a portion of the data associated with the items or components represented by the nodes and leaves can be recorded on a blockchain, such as a public blockchain. Additionally or alternatively, the corresponding blockchain transactions associated with each item and component can be recorded in their original form on a blockchain, such as a public blockchain, or hashed. When data associated with an item is updated, the blockchain transaction associated with the item and / or component, or each of the blockchain transactions therein, can be updated. This allows tracking of data associated with the item or component. Furthermore, such data can be verified.

[0061] In another example, the tree structure can change over time. For example, the arrangement of nodes and leaves can be updated to reflect updates to the state and / or configuration of an item or information associated with the item or its components. Similarly, an item and / or component can be associated with at least one blockchain transaction to create a record of the tree structure, e.g., recording each new arrangement. In practice, each item and component can be associated with its corresponding blockchain transaction. The tree structure can be a hash tree, and the root hash and / or a hash of at least a portion of the data associated with the item or component represented by the nodes and leaves can be recorded on a blockchain, such as a public blockchain. Each time the tree structure changes, the blockchain transaction associated with the item and / or component can be updated. The data associated with the item can be updated, including the updated proof. This allows tracking of the data associated with the item or component. Furthermore, the data can be verified.

[0062] Data associated with a blockchain transaction representing an item or component (e.g., a record) may include a proof that enables a third party to determine the validity of the data without knowing the complete tree structure. The proof may be updated each time a change is made to the tree structure or when the tree structure changes. The proof may use simple payment verification techniques, such as using blockchain transactions to determine the validity of the item or component.

[0063] In another example, an item or component can be moved from one tree structure to another. The different tree structures can represent different entities (e.g., physical entities), while the item or component in each structure is substantially the same, although data associated with the item or component is updated, for example, an association with a blockchain transaction is updated, or a record of its use or application is modified.

[0064] Figure 15A first tree structure 1500 and a second tree structure 1502 are shown, each having nodes 1402 and leaves 1404. The first and second tree structures represent different corresponding entities. A hash line connects two of the leaves, representing the connection between the trees created when a component of the first entity represented by the first tree structure is transferred to the second entity represented by the second tree structure. The tree structure represents a point in time, and thus the leaves are shown as part of the history of the tree structure. At least the root node 104 (e.g., a hash of the root node) is associated with a blockchain transaction and recorded on the blockchain ledger. Preferably, each of the nodes and leaves is associated with a blockchain transaction and similarly recorded on the blockchain ledger. Through the history of blockchain transactions, the validity of each component or item of the tree, or the tree structure itself, can be tracked and / or verified.

[0065] Figure 15 It is further shown that according to this article Figures 10 to 13 According to the teachings of the present invention, each tree structure can be recorded in the allocated resources 1104. Additionally or alternatively, data associated with each node 1402 and / or each leaf 1404 (eg, a record) can be stored in the allocated resources.

[0066] For example, x-ray data (component) may be generated by a hospital department and stored in a record within a structured database (item). As taught herein, the structured database can be represented as a tree structure and used to track the database and items therein. The database and the x-ray data therein may form part of a tree structure, wherein at least one of the database and the x-ray data is associated with a blockchain transaction, enabling the tree structure to be processed to at least determine the validity of the tree structure. However, the x-ray data may be transferred to another item, such as a patient's record, and become part of another tree structure. Updating a blockchain transaction (e.g., updating a blockchain token storing data associated with the x-ray data) enables the tree structure representing the patient's record to be processed to determine the validity of the x-ray data. Validity can be determined based on transaction history and / or based on a record within the blockchain transaction, which represents an x-ray that stores proof (e.g., a Merkle proof of data validity and / or origin). The validity of the x-ray as part of the hospital database from which the data originated can be determined, and the validity of the x-ray as part of the patient's record can also be verified. Thus, an item or component can be tracked across applications (e.g., from end to end). Validity can be determined without compromising privacy (eg, without disclosing the patient's complete record).

[0067] As another example, a first tree structure represents a product manufactured on a production line, where quality control checks, manufacturing dates and times, and other information associated with the product (e.g., a vehicle airbag) are stored in data (e.g., a data packet), such as a record of a component, which is part of the production record, i.e., an item, which can be a database of production records. After production, the product can be transferred to a warehouse, and the associated blockchain transaction can be updated to indicate that the product (component) is now part of the warehouse inventory (item), which has multiple components represented by a second tree structure. Therefore, the item and / or at least one component of the item is further associated with a blockchain transaction (Tx), which is now represented in the second tree structure. The blockchain transaction is updated and, in effect, transferred from the first tree structure to the second tree structure. The item and / or at least one component of the item is associated with a blockchain transaction (Tx), which is represented in both tree structures. Thus, the product's history can be stored in the record associated with the blockchain transaction. The vehicle's maintenance history can be represented by a third tree structure, which can include MOT data (government test data), maintenance data, and details of replaced parts. The inventory of replacement parts (e.g., headlights, tires, and airbags) can be represented as "items" in the tree structure, with each replacement part listed as a "component." When a new airbag is installed on a vehicle, the third tree structure is updated to include a new node or leaf representing the airbag. For example, the blockchain transaction that holds the data package (i.e., the record of the component) for the airbag can be updated and included in the blockchain transaction associated with the third tree structure, such as Figure 14 (b) . Through the blockchain transaction history and / or the record stored in the blockchain transaction, a third party wishing to verify the replacement of the airbag can process the tree structure used to represent the vehicle and confirm that the airbag is represented in the tree structure, as well as a part of the vehicle. This can be achieved by associating the airbag with a blockchain transaction (Tx), which is represented in a third tree structure. Additionally, the record can store detailed information about the airbag and / or an index in which to find detailed information about the airbag, with at least one of the first tree structure and the second tree structure associated with the airbag. Thus, the technology herein enables tracking of items or components and subsequent verification of these components. This can be achieved from creation to destruction, or from one end of a product's life cycle to the other.

[0068] Data (e.g., a record) associated with a blockchain transaction representing an item or component (where the item or component is already part of another tree structure) can further include a proof (e.g., a further proof or a second proof) that enables a third party to determine the validity of the data without knowing the complete tree structure or knowing the complete second tree structure. The record can contain historical data for the item that enables verification of its complete provenance. The record can include proof that a component (e.g., an airbag) is part of a tree structure for an item (e.g., a manufacturing facility, a warehouse, or a vehicle). The proof can include a Merkle proof.

[0069] Figure 16 Step S1600 for processing tree structures 1400, 1500, and 1502 is shown. The tree structure may represent an item and at least one subcomponent. The item and / or at least one component of the item is associated with a blockchain transaction, which is represented in the tree structure. The relationship between the item and the component can be determined based on the relationship between the data associated with them (e.g., blockchain transactions). In a non-limiting example, the tree structure may be a hash tree, in which the items and components and / or their associated blockchain transactions or portions thereof can be hashed. A hash derived from at least the hash of the root node of the tree structure can be stored in a blockchain, such as a public blockchain. Preferably, the hash derived from each of the nodes and leaves can be stored, for example, on the blockchain. Using proofs (e.g., Merkle proofs), the item or component can be verified as being part of the tree structure.

[0070] At S1602, the processor may receive or retrieve a tree structure representing its items and / or components. Furthermore, data associated with the tree structure may be obtained, which may include information associated with the items and / or components. The data may also be a hash of the information, or at least a portion of the information. For example, the processor may calculate a hash for each node 1402 and leaf 1404 and assign a unique hash value to each node, the unique hash value being calculated based on the data stored in the node and / or the hashes of its child nodes.

[0071] In S1604, the processor processes the tree structure by associating it with a blockchain transaction. The transaction may store data of an item or component in its script. The blockchain transaction may be part of a blockchain token.

[0072] In S1606, the item or component may be verified as part of the tree structure. This may be after or before processing and / or storing S1608 the item and / or at least one component of the item associated with the blockchain transaction (Tx) in the allocated resources 1104, which is represented in the tree structure. Data (e.g., a record of the item or component) may be verified before storage, and vice versa.

[0073] The verification technique herein proposes the use of a hash tree, wherein the nodes and leaves of the tree are hashed and a hash of the root of the tree is generated. Other techniques may be implemented based on the teachings herein.

[0074] To verify that an item or component is part of a "hash" tree structure, the processor is provided with data (e.g., a hash of the item or component) that indicates it is part of the tree structure. For example, someone seeking to prove that an airbag has been provided or replaced in a vehicle can provide a tree structure representing the vehicle, or a portion of a structure that can prove that the airbag is part of the tree structure. A portion of the tree structure can be provided to maintain privacy. Alternatively, only hash data associated with other portions of the tree structure can be provided to maintain privacy. Verification can use simple payment verification techniques.

[0075] Using the tree structure or a portion thereof, the processor can calculate the hash of each node 1402 in the tree, where the hash of a node is the hash of its child nodes (including leaves 1404) and is concatenated together. The processor can determine that the hashes are consistent from the tree to the root node to ensure that the tree is valid and remains unchanged. This can be achieved by the processor calculating the hash of each node 1402 and leaf 1404 and comparing the parent node hash with the child node hash. Starting from the leaf node 1404, the processor can traverse the tree upwards and compare the hash value of each parent node with the hash of its child nodes. If the hashes match, it means that the data stored in the child node has not been tampered with. This can be repeated for all nodes until the root node is reached. If all hashes are consistent, it means that the entire tree is authentic and has not been changed. In addition, the root hash can also be verified, which summarizes the entire tree structure.

[0076] By verifying the tree structure, items or components therein may be used to verify items or components by comparing provided data (eg, data associated with a replacement airbag in a vehicle or a hash value thereof) with previously stored or distributed records of the tree structure.

[0077] Two or more tree structures may be used to verify an item or component by comparing provided data (e.g., data associated with a replacement airbag in a vehicle or a hash thereof) with (e.g., data associated with a replacement airbag in a vehicle or a hash thereof) Figure 15 ) previously stored or distributed records of a first tree structure and a second tree structure. Having two or more tree structures can enhance the provenance of an item, which can be beneficial if the history of an item or component spans two or more applications and corresponding tree structures. Thus, the processor can process the record of the item or component to verify whether at least one of the item, at least one component of the item, and at least a portion of a blockchain transaction (Tx) is part of the tree structure or another tree structure.

[0078] The data (e.g., a record) associated with an item, at least one component of the item, and at least a portion of a blockchain transaction may include at least one of: a history of the or each tree structure from which the associated blockchain transaction originated; a history of the allocated resources in which the blockchain transaction was stored; and a proof enabling verification that the item, component, or blockchain transaction is part of a tree structure (e.g., the first tree structure and / or the second tree structure).

[0079] Items, components, or blockchain transactions can be verified by comparing against stored data (e.g., manufacturing facility databases, warehouse inventories, and vehicle maintenance records), which can be stored on the blockchain. Data (e.g., product records) can be used to confirm that it is valid and originates from a specific tree structure. This can be achieved by limiting verification to the minimum required for the item or component, thereby maintaining privacy. This can maintain the privacy of confidential information (e.g., medical records).

[0080] As mentioned above, combined Figure 13 and Figure 15 , a tree structure or a portion thereof can be stored as data (e.g., a record) in an allocated resource. Any portion of the data associated with an item, component, or blockchain transaction can be used to identify and / or allocate the allocated resource. A portion of the data can be a transaction, such as an unspent transaction output (UTXO) and / or a transaction (Tx) containing a UTXO. Figure 11 and the associated description describe one example of how the data is used to determine allocated resources.

[0081] The teachings herein are suitable for processing secure and / or confidential data (e.g., medical records) because they enable verification of items or components that are part of a tree structure without compromising the privacy of other items or components. Furthermore, the method for processing a tree structure can be extended by allocating storage for at least one of items or components of an associated blockchain transaction in a pseudo-random manner. Thus, the allocation of resources can be load-balanced, which can be achieved by using at least one of a portion of data associated with the item, component, or associated blockchain transaction to determine a key. The key can include at least one of: an alphanumeric number; and a binary number. The key can be determined by parsing at least one of a portion of data associated with the item, component, or associated blockchain transaction. For example, data associated with the component can be hashed and / or parsed to determine the key and the associated allocated resources 1104.

[0082] The data (e.g., a record associated with at least one of an item, a component, or an associated blockchain transaction) may include at least one of the following: a Merkle tree of a block recording the transaction (Tx); a Merkle root of a block recording the transaction (Tx); a Merkle path enabling determination of a value of a Merkle root of a block recording the transaction (Tx) based on a hash of the blockchain transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in a plurality of blockchain transactions within the blockchain block; a function of a block identifier (block_ID) and a transaction identifier (TxID); a concatenation of a block identifier (block_ID) and a transaction identifier (TxID).

[0083] The data (e.g., a record associated with at least one of an item, a component, or an associated blockchain transaction) may include at least one of: a proof that the associated blockchain transaction is part of a tree structure using at least one of a hash of the root of the tree structure and a path that enables determination of the hash of the root of the tree structure recording the associated blockchain transaction from the hash of the blockchain transaction; and, proof.

[0084] Record

[0085] Figure 13 Two transactions derived from blockchain 150 are shown. Examples of methods described herein include at least one of generating, storing, processing, accessing, and maintaining a record of at least a portion of a transaction (Tx) in one of multiple resources 1104. The allocation and / or identification of resources corresponding to each transaction is described below in conjunction with a UTXO database, which may utilize, for example, hash table techniques for allocation. Resource 1104 may be one of multiple resources comprising the database.

[0086] Figure 13 Two Merkle trees are shown, which are constructed using the set of transactions in a block to determine the Merkle root included in the block header. n and transaction Tx n+1 Each transaction in is part of the corresponding Merkle tree, at least as described below for Figure 4 shown.

[0087] The record includes transaction data that is used to identify the transaction (e.g., Tx n or Tx n+1) is included in the Merkle path of blockchain block (B). Alone or in combination with the examples taught herein, the record holds data that enables efficient and cost-effective reference and / or retrieval of information associated with the transaction. Specifically, the information held in the record enables a third party wishing to verify the transaction to identify the allocated resources holding the associated record and retrieve transaction data to confirm that at least a portion of the transaction is included in the Merkle path of blockchain block (B). For example, the record holds a Merkle proof that the transaction is part of a Merkle tree that identifies the Merkle root of the block in which the transaction is recorded.

[0088] A record can hold a set of data associated with a transaction. For example, a record can be simplified and / or contain concatenated data for efficient storage. The information in a record can be configured for reference. For example, a record can include a data directory. The data directory can be structured, such as by adding an index, to selectively identify and / or retrieve information associated with a transaction. The data directory can hold a set of transaction data, such as a Merkle proof that enables simple payment verification (SPV).

[0089] The record may include a data directory that can be managed by the resource and / or verifier 1106. The record is used to hold information that can be stored / associated with the transaction, such as UTXO for verification, status indication, holding signatures, and at least one of transaction status. For example, the record may include at least a portion of a script that defines "OP_PUSH_TX" to impose conditions on the transaction. Thus, the record can provide a directory or information repository associated with the transaction.

[0090] The output of a transaction can be an unspent transaction output (UTXO) and / or a transaction (Tx) containing a UTXO of a blockchain block. As suggested by the UTXO and OP_PUSH_TX records, the record is not limited to the output of the transaction, and at least a portion of the transaction (Tx) can include the output, input, and / or any other parameters of the transaction.

[0091] The record may be stored in a database. The database may include a plurality of resources 1104 and / or a verifier 1106. The record may include a blockchain transaction (TX0) including at least one data item (D). Additionally or alternatively, the record may include at least one other blockchain transaction (TX1) necessary to confirm that the blockchain transaction (TX1) is included in the Merkle path of the blockchain block (B).

[0092] The record may be a data directory and may be stored in a database or distributed across multiple databases. The database itself may be distributed across multiple resources 1104. The storage of records (e.g., information and / or data as taught herein) may be applied to and / or support efficient distribution, reference, and access of records associated with nodes (e.g., Metanet nodes) and associated Metanet protocols.

[0093] The following applications are incorporated herein by reference in their entirety:

[0094] - PCT / IB2019 / 059793, which relates to indexing and structured nodes

[0095] - PCT / IB2019 / 059795, which supports mapping categories to mnemonics, such as cataloging.

[0096] - PCT / IB2019 / 059791, which supports searching and locating resources.

[0097] - PCT / IB2019 / 059803, which supports wallets, blockchain search systems, block explorers, etc., enabling users to search / access / view / write / retrieve partial data (e.g., transactions) contained in Metanet nodes, and can identify Metanet nodes based on their Metanet index.

[0098] - PCT / IB2019 / 060226, PCT / IB2019 / 059807, which support splitting data across multiple nodes.

[0099] - PCT / IB2019 / 059808, which supports splitting records, particularly node attributes, across multiple transaction inputs and multiple transaction outputs.

[0100] - PCT / IB2019 / 059809, which establishes atomic swaps, such as conditional swaps, between two or more parties.

[0101] Using a database and / or records and / or information may include generating, maintaining, providing, updating, storing, accessing, or processing: i) a database; and / or ii) data / records / information stored in or associated with a database. The database is stored in or across one or more resources, and the data, records, or information stored in the database is processed and / or stored in the allocated resource (1104).

[0102] Additionally or alternatively, the record includes transaction data used to determine that at least a portion of the transaction (Tx) is included in a Merkle path of the blockchain block (B), and the record may hold a Merkle path from the transaction (TX0) to the root of the Merkle tree of the blockchain block (B). The Merkle path may include at least the minimum blockchain transactions required to establish or verify that the blockchain transaction (TX0) is included in the blockchain block (B). The records herein provide an efficient and effective method for verifying transactions. In conjunction with techniques for allocating and identifying resources holding records and / or verifying the records, an improved system for managing and / or using transaction data is provided. Transactions can be derived from blockchain blocks.

[0103] A blockchain transaction (TX0) can be used alone or in conjunction with at least one other blockchain transaction (TX1) to verify that the blockchain transaction (TX0) is included in the Merkle path of a blockchain block (B). A data item (D) can be a portion of a record or information stored in the allocated resource and can be at least one of the following: stored in association with a script in a transaction; or stored as metadata in the transaction. Generally speaking, the record includes verification data necessary to verify the transaction, such as unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0104] Blockchain blocks may be stored on or associated with: a blockchain ledger; and / or off-chain storage resources.

[0105] The record may include a history of at least one previous transaction, i.e., transaction data of at least one previous transaction. The history may include transactions of unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. The at least one previous transaction may be the previous transaction of the last transaction.

[0106] The record may further include a history of allocated resources, the allocated resources being used to process and / or store at least the last transaction. The record may include a link to the allocated resources holding the last transaction. The record may hold a history of multiple previous transactions for unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0107] In this way, the history enables a third party using the record to retrieve the most recent transaction and, if necessary, efficiently identify the previous transaction without having to perform further lookups or searches. The history can provide an old directory or a set of shortcuts to key records, data, or information. The history can include at least one of the following: a set of transaction data used to determine Merkle proofs for multiple previous transactions; and links to corresponding allocated resources that processed and / or stored the multiple previous transactions.

[0108] refer to Figure 13 , the first transaction Tx n Then comes the second transaction Tx n+1 In the example, the first transaction and the second transaction store associated records in different allocated resources 1104, although they may both be stored at different addresses in the same allocated resource. The record of the second transaction may include at least a link to the address of the first transaction in the allocated resource. The record of the second transaction may at least partially include a record of the transaction data of the first transaction. The record of the second transaction may include records of transaction data for multiple previous transactions.

[0109] The record may include flags and / or status indications for transaction data, such as unspent transaction outputs (UTXOs) and / or each input of a transaction (Tx) containing a UTXO. For example, the indication may be one of "seen," "in block," and "double spent," thereby providing an efficient reference to the status of the transaction data.

[0110] Records can hold any amount of transaction data information and / or supplementary data, such as verification data. Using records provides an alternative method for searching, identifying, and processing transaction data on-chain. Records can consolidate key data, minimizing the computational cost of using transactions and performing operations using blockchains and blockchain blocks. The record may further include at least one of the following: a Merkle tree of the block recording the transaction (Tx); a Merkle root of the block recording the transaction (Tx); a Merkle path capable of determining the value of the Merkle root of the block recording the transaction (Tx) based on the hash of the transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in a plurality of blockchain transactions within the blockchain block; a function of a block identifier (block_ID) and a transaction identifier (TxID); a concatenation of a block identifier (block_ID) and a transaction identifier (TxID); a digital signature; an authentication code; a signed message for determining a transaction status.

[0111] The allocated resources for processing and / or storing records can be identified and / or allocated using partial data derived from the blockchain for identifying and / or allocating resources, wherein the data from which the partial data is derived includes transaction data, such as unspent transaction outputs (UTXO) and / or transactions (Tx) containing UTXO.

[0112] Examples herein and associated systems enable use of a database comprising at least one record including: a blockchain transaction (TX0), the blockchain transaction including at least one data item (D); and at least one other blockchain transaction (TX1), the at least one other blockchain transaction necessary to confirm that the blockchain transaction (TX1) is included in a Merkle path of a blockchain block (B).

[0113] Using a database includes generating, maintaining, providing, updating, storing, accessing, or processing: a database; and / or data stored in or associated with the database. The record may further include: a Merkle path from the transaction (TX0) to the root of the Merkle tree for blockchain block (B). The Merkle path may include at least the minimum blockchain transactions required to establish or verify that blockchain transaction (TX0) is included in blockchain block (B).

[0114] The method herein can use a blockchain transaction (TX0) and at least one other blockchain transaction (TX1) to verify that the blockchain transaction (TX0) is included in a Merkle path of a blockchain block (B).

[0115] The data item (D) may be stored in association with the script in the transaction; and / or may be stored as metadata in the transaction.

[0116] The transaction may further include at least one of the following: a transaction ID (TxID); a protocol flag; a discretionary public key (DPK); and a discretionary transaction ID (DTxID).

[0117] The above-mentioned records (eg, information and data associated with, derived from, or related to a transaction) may be stored in the allocated resources using the following methods.

[0118] UTXO database

[0119] Figures 10 to 12A diagram illustrates various stages of a method for exporting data from a blockchain, a table for allocating resources 1104, and a system for implementing the method. Data is obtained from a peer-to-peer (P2P) network 106 and / or a blockchain network 150. At s1000, data may be obtained or retrieved, for example, by requesting and retrieving one or more blocks from blockchain 150. Retrieval may include downloading at least a portion of a blockchain block, which includes multiple blockchain transactions. When data is needed to establish a stored and / or processing history (e.g., as recorded in block 151) of transaction data related to unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs, data may need to be retrieved or otherwise obtained, such as by retrieving, copying, or reading data from a blockchain block. UTXOs are currently in the memory pool or in future transactions. UTXOs may be received by connecting to the network, such as by implementing a node 104 that receives transactions broadcast on the network.

[0120] Therefore, in general, Figure 12 System 1100 in

[1102] uses partial data derived from a blockchain to determine a key and allocate a corresponding resource. The resource will store information associated with the data, such as information associated with unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. For clarity, information associated with the data derived from the blockchain will be stored in the resource for efficient and cost-effective reference. The data may include unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. A portion of the data is used to determine a key, which in turn determines an allocated resource. The allocated resource will store information related to the data. The data from which the partial data was derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. At s1002, a portion of the data is used to identify or allocate a corresponding resource 1104, such as the allocated resource. At s1004, resource 1104 operates to at least one of generate, store, and maintain a database of information, including data associated with UTXOs and / or transactions. The information may include an indication of the validity of the UTXO and / or may be able to determine validity, for example, using SPV techniques. The information about the data may include, for example, details of the block from which the data was obtained, such as the block ID, the Merkle path of unspent transaction outputs (UTXOs) and / or the transaction (Tx) containing the UTXO, and the status of the validity of all UTXOs within the transaction.

[0121] Resource 1104 may operate to store information that may be used by other resources to verify UTXOs and / or process data to generate an indication, such as a flag indicating validity. Additionally or alternatively, resource 1104 may delegate determination of the validity of a transaction or UTXO to verifier 1106 at s1006. Storing and / or processing at least a portion of a UTXO and / or transaction (Tx) may be accomplished: within an allocated resource, such as resource 1104 actively managing information and maintaining a database associated with each UTXO therein, such as the resource may be managed by itself; and / or by an allocated resource, such as a system 1100 where the resource acts as a controller and functions as a subresource to store and / or process information; and / or associated with an allocated resource, such as resource 1104 operating as part of system 1100, such as Figure 12 As shown, by way of non-limiting example, a node 104 provides transaction and UTXO information to a switch 1102 (e.g., a router), which operates to determine which of a plurality of resources 1104 is assigned the task of generating, holding, and / or storing UTXO information in a database. In general, a resource may implement and perform Figure 10 One or more operations in the operations. Figure 12 A system 1100 is shown having a single execution Figure 10 Components of the operation.

[0122] In one example, the task of holding information associated with the UTXO is assigned to one resource from a set of resources in the system 1100. For example, Figure 12 Eight resources are shown, each sharing information from UTXOs among the others. However, the system can hold any number of resources and is scalable, for example, the system can have 16, 256, or 1024 resources. Therefore, each resource is assigned a UTXO range for processing, storage, and / or maintenance.

[0123] A portion of the data for an unspent transaction output and / or a transaction (Tx) containing a UTXO can be retrieved and / or received and parsed. Parsing can determine which resource is assigned the task of storing the information. Parsing can be performed by resource 1104 or switch 1102. At least one of node 104, switch 1102, and resource 1104 can derive a portion of the data from the blockchain. When parsing is performed by node 104 or switch 1102, the information is directed to the assigned resource. Identifying and / or allocating processing and / or storage resources can be performed by a node and / or switch acting as an intermediary. These nodes and / or switches are connected to multiple assigned resources, and the node or switch acts as a manager for many resources 1104, determining the specific resource that manages the UTXO / Tx. When resource 1104 performs parsing, it processes the data and / or stores information derived from the data, stores data associated with the data, or takes no action if it is not responsible for the UTXO.

[0124] When determining the allocation of resource 1104, for example, determining the location of holding information associated with UTXO / Tx, resource 1104 may perform the operation of s1004 and generate, store and / or maintain information associated with unspent transaction output (UTXO) and / or transaction (Tx) containing UTXO. Resource 1104 may process the received data to determine the validity of UTXO / Tx, for example, s1006, or delegate this task to verifier 1106. Resource 1104 and / or verifier 1106 may at least partially verify the unspent transaction output (UTXO) and / or transaction (Tx) containing UTXO.

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

[0126] The acquired data relates to a UTXO or a transaction with a UTXO and is used to provide a key that identifies and / or allocates a resource that will store, maintain, or generate the corresponding information. The key is determined directly by using a portion of the data, such as the key determining the allocated resource, or indirectly by processing, such as hashing a portion of the data such that the resulting hash determines the allocated resource.

[0127] The key is used to determine which resource 1104 will hold the corresponding information associated with that key. Thus, a resource holds a data structure, such as a database or hash table that implements an associative array. In other words, the data associated with the UTXO and / or transaction is used to determine the key, and the key is used to determine the resource that holds the information associated with the UTXO and / or transaction. The data and key not only enable the allocation of resources, but also allow the retrieval of stored information by using the key to find and access the information.

[0128] At least one of the data, the key, and the resulting hash comprises at least one of: an alphanumeric number; and a binary number. The number is used to determine the allocated resources.

[0129] For example, some data includes unspent transaction outputs (UTXO) and / or transactions (Tx) containing UTXO. The inputs of a transaction include: a transaction ID that references the transaction containing the spent UTXO; an output index, such as Vout, that identifies the UTXO that references the transaction; a scriptSig that satisfies the conditions imposed on the UTXO to unlock it; and a sequence number.

[0130] Potential recipients of a UTXO need to verify the UTXO before compiling and broadcasting a transaction that spends the UTXO. Known verification techniques are slow, resource-intensive, and computationally expensive. By using partial data of the UTXO and / or associated transactions, information used to verify the UTXO or allow verification of the UTXO can be stored in a resource. Using the partial data unique to the UTXO, a key can be determined, which in turn determines the allocated resource where the associated information can be stored and then retrieved.

[0131] Taking a transaction identifier (TxID) as a non-limiting example, the TxID is usually in hexadecimal form, but can also be expressed as a binary number. Figure 11 (a) to Figure 11 (d) is a table showing how a portion of the data is used to determine the allocated resources. Part of the data (e.g., TxID) can be directly parsed or processed, such as by hashing. Figure 11 In (a), the TxID is parsed so that the first three digits of the binary form of the TxID are selected as a key and resources are allocated according to the binary value, for example, information associated with a TxID having a binary number with the first three digits being "101" is allocated for storage / processing in the allocated resource "6". By using the first three digits, the binary number can determine one of the eight resources, and Figure 11(c) shows how the first four digits of the binary TxID can be taken to support allocation among the 16 resources, for example, allocating information associated with a TxID that begins with a binary number with the first four digits being "1011" for storage / processing in the allocated resource "12". Alternatively, the hexadecimal value of the TxID can be used, such as Figure 11 (b), where a single hexadecimal value is mapped to a resource, such as "c" to "13", and Figure 11 In (d), a range of hexadecimal values ​​is assigned to the resources, for example, information associated with TxIDs starting with "76" is assigned to resource "8".

[0132] Alternatively, a portion of the data may be processed, such as hashed, to produce a hexadecimal or binary number, so that the portion of data and the subsequent determination of the key used to identify / allocate the resource 1104 is not limited to the TxID.

[0133] Part of the data selected from the transaction or its UTXO, or the processed value (e.g., hash value) is pseudo-random. The allocation of resources is load-balanced, that is, part of the data used to determine the key for allocating resources is pseudo-random, and processing and / or storage are distributed among multiple resources. It can be seen that the information associated with the transaction / UTXO is distributed among multiple resources. The balanced allocation between resources can minimize the risk of some processing resources being idle while other processing resources are overloaded, resulting in performance degradation or even failure. The resilience, performance and / or efficiency of system 1100 are improved.

[0134] Thus, the data and portions of the data may be used to (i) determine the allocated resources and thereby (ii) provide a reference for identifying the resources and / or information associated with the data in the resources (eg, in a database).

[0135] It can be seen that part of the data is derived from the blockchain, and a key and a corresponding resource are determined, which will store information associated with the data, namely information associated with unspent transaction outputs (UTXO) and / or transactions (Tx) containing UTXO.

[0136] Participants seeking to verify the validity of a UTXO may use a portion of the UTXO and / or the transaction holding the UTXO to identify a resource holding information that can be used to determine the validity of the UTXO and / or the transaction. This information may include a flag or marker associated with and indicating whether the UTXO is locked or unlocked, e.g., invalid or valid, e.g., suitable for inclusion in a subsequent transaction. Additionally or alternatively, this information may include a record of the UTXO and / or the transaction holding the UTXO, enabling participants to efficiently and independently verify the UTXO.

[0137] The record may include, at least in part, at least one of: a Merkle tree of the block recording the transaction (Tx); a Merkle root of the block recording the transaction (Tx); a Merkle path, from a hash of the transaction (Tx), the Merkle path being capable of determining a value of the Merkle root of the block recording the transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in a plurality of blockchain transactions within the blockchain block; a function of a block identifier (block_ID) and a transaction identifier (TxID); and a concatenation of a block identifier (block_ID) and a transaction identifier (TxID).

[0138] The resource may include information and records required to determine the validity of the UTXO. Additionally or alternatively, the resource may generate records verifying and / or supporting the verification of the UTXO, either on its own or through verification s1006 of the verifier 1106. The resource 1104 and / or the verifier 1106 may perform at least one of the following: verifying and / or validating the UTXO; performing at least a portion of a simple payment verification (SPV) process for the UTXO; confirming whether a given blockchain transaction (Tx) is included within a blockchain block; generating a hash of at least one of the blockchain transactions, using the hash to construct a Merkle path and / or checking whether the hash matches a transaction identifier (TxID) in a block header of the blockchain block; and determining a Merkle proof for the UTXO.

[0139] By providing a way to identify the allocated resource 1104 from the UTXO / transaction and storing the information required to verify the UTXO in the resource, an efficient and scalable alternative method for verifying UTXO is provided. Nodes no longer need to hold a full copy of the blockchain, nor do they need additional information to support transactions, such as SPV-based exchanges and wallets. The system 1100 and the resources 1104 therein provide fast and scalable support.

[0140] In general, 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), each UTXO being associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of a blockchain block. The resource can record, search, and / or process the information and / or records using partial data derived from a blockchain to identify and / or assign the resource, wherein the data from which the partial data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) containing the UTXOs.

[0141] System 1100 may include a node 104 and / or a switch 1102 for receiving and / or processing unspent transaction outputs (UTXOs) for inclusion in transactions. The node and / or switch may support resources and determine allocation of resources among a plurality of resources. The allocated resources then hold verification data, such as information and / or records for the UTXOs.

[0142] After receiving a UTXO for inclusion in a transaction (e.g., as part of a payment or transfer of a digital asset), a participant may request and / or obtain verification information and / or records from the allocated resource.

[0143] When a participant accesses information and / or records from an allocated resource, the participant may perform at least one of the following: verifying the UTXO and / or the transaction (Tx) containing the UTXO; and / or determining the validity of the UTXO and / or the transaction (Tx) containing the UTXO. The verification performed by at least one of the resource 1104, the verifier 1106, and the participant may include: verifying and / or validating at least one blockchain transaction; and / or ii) performing a simple payment verification (SPV) process; and / or iii) confirming whether a given blockchain transaction (Tx) is included in a blockchain block; and / or iii) generating a hash of at least one of the blockchain transactions, using the hash to construct a Merkle path, and / or checking whether the hash matches a transaction identifier (TxID) in a block header of a blockchain block.

[0144] Thereafter, after verifying the UTXO, the participant or another participant may prepare and / or transmit a transaction (Tx) having the UTXO as input.

[0145] The node 104 may be configured to perform at least one of generating, storing, and maintaining UTXO resources for recording, searching, and / or processing a plurality of unspent transaction outputs (UTXOs), wherein the node processes partial data derived from the blockchain to identify and / or allocate processing and / or storage resources. The data from which the partial data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) containing the UTXOs.

[0146] Block Verification

[0147] Traditionally, nodes in a blockchain network maintain a global ledger of all transactions on the blockchain. This global ledger is a distributed ledger, and each node may store a full or partial copy of it. Transactions affecting a node's global ledger are verified by other nodes, thereby maintaining the validity and integrity of the global ledger. Those skilled in the art will understand the details of implementing and operating a blockchain network (e.g., one using the Bitcoin protocol).

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

[0149] As described above, using the Bitcoin network and protocol as an example, mining nodes compete to create the next block in the blockchain. To assemble a block, a miner constructs it as a set of transactions from a pool of unconfirmed transactions (the "memory pool"). The miner then attempts to complete the Proof-of-Work (PoW) puzzle for the block they have assembled. If the miner manages to complete the PoW before receiving notification that any other miner has successfully generated their own block and completed their PoW, the miner propagates their block by sending it to peer nodes on the network. These nodes verify the block and then send it further along the network. If the miner receives notification that another block has been completed before completing its own PoW, it abandons its efforts and begins attempting to build the next block.

[0150] Therefore, rapidly propagating blocks helps avoid wasted effort (and associated energy) on behalf of miners and verification nodes. By providing a solution that enables faster verification and, therefore, propagation of blocks, the present invention provides enhanced network performance. This solution reduces the required computational time and workload, thereby reducing the energy required by the network. This solution provides a more efficient network in terms of resources and time. Ultimately, this solution provides an improved (blockchain) network.

[0151] In current implementations of blockchains (e.g., the Bitcoin network), each node that receives a block first verifies it before sending it to other nodes. The time required to verify a block slows down the block's propagation through the network. It should be noted that some implementations of blockchains (including evolutions of existing protocols) may require block verification by only a subset of nodes, rather than by every node in the network; however, block verification by a majority of nodes may still be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0152] Verifying a block involves confirming that it meets the specified standards set by the applicable blockchain protocol. Exemplary standards applicable to the Bitcoin protocol may include functions such as CheckBlock and CheckBlockHeader. In addition to confirming that the block itself meets the specified standards, each transaction within the block may also be evaluated for compliance with transaction-level standards. For example, transaction-level standards applied in the Bitcoin protocol may include the AcceptToMemoryPool, CheckTransaction, and CheckInputs functions.

[0153] Specific examples of blockchain-level standards based on the Bitcoin protocol could include:

[0154] ●Block data structures are syntactically valid.

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

[0156] ●The block timestamp is less than two hours in the future (accounting for time errors).

[0157] ●Block size is within acceptable range.

[0158] • The first transaction (and only the first transaction) is a Coinbase Generate transaction.

[0159] ●All transactions within the block are valid.

[0160] Specific examples of transaction-level standards based on the Bitcoin protocol could include:

[0161] ●The syntax and data structure of the transaction must be correct.

[0162] ●Neither the input list nor the output list is empty.

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

[0164] ●All inputs do not have an empty hash.

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

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

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

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

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

[0170] For each input, if the referenced output transaction is a Coinbase output, then that output transaction must have at least COINBASE_MATURITY(100) confirmations.

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

[0172] Use the referenced output transaction to get the input values, checking that each input value and the sum are within the allowed range for value x, i.e. 0 <x<21·10 6 .

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

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

[0175] ●Transaction fees must be sufficient to obtain an input to an empty block.

[0176] ●Each input’s unlocking script must be verified against the corresponding output locking script.

[0177] These exemplary standards are illustrative and should not be construed as sufficient or necessary for all embodiments, as the specified standards may differ across different protocols and may change over time for a given protocol if changes are made to that protocol. Generally, transaction-level verification standards refer to the specified characteristics that a transaction must meet to be considered valid under the applicable blockchain protocol. Similarly, block-level verification standards refer to the specified characteristics that a block must meet to be considered valid under the applicable blockchain protocol.

[0178] According to the present application, methods and apparatus are described for accelerating block verification in order to facilitate faster propagation of blocks in a network.

[0179] In one aspect, the present application describes a node that is configured to verify blocks by performing at least transaction-level verification of each transaction in parallel and / or in a distributed manner. However, certain transaction-level criteria may not be evaluated in parallel. For example, the uniqueness of UTXOs may be evaluated on a serial basis. In this case, the distributed verification node of the present disclosure may be configured or arranged to confirm the uniqueness of the referenced inputs (UTXOs) of a transaction before distributing multiple transaction sets among a set of two or more parallel processors for verification of the remaining transaction-level criteria.

[0180] Specifically, embodiments of the present disclosure provide improved authentication 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, a tree structure can be decomposed into smaller trees (which may be referred to herein as tree "segments," "subsets," or "portions"), where each segment includes a subset of the data records in the entire tree and has its own root. Advantageously, embodiments of the present disclosure utilize this feature to provide methods and systems for distributing and parallelizing the processing of related data records across multiple processing resources.

[0181] In an exemplary embodiment of the present disclosure, a plurality of data records include blockchain transactions that are related by forming nodes within a Merkle tree. The Merkle tree has a root that is or may be included in a block header of a block of transactions according to a blockchain protocol, such that the root provides a path that can be followed to each leaf (i.e., a transaction ID (TxID)) within the tree. Although in some examples of the present disclosure, the blockchain protocol is the Bitcoin protocol or is derived from the Bitcoin protocol, other protocols are also within the scope of the present disclosure.

[0182] In one example, processing the plurality of transactions includes verifying 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 can be used for non-blockchain related data and / or processes other than verification. For example, embodiments can be used to store, construct, search, and / or maintain any type of data record that can be represented in a Merkle tree. Databases and other known storage resources can be utilized in place of or in addition to a blockchain ledger.

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

[0184] For the sake of completeness, and with reference to Figure 3 and Figure 4 , below we discuss Merkle trees and their use in representing blocks of blockchain transactions.

[0185] Merkle Tree

[0186] See Figure 3 Merkle trees are hierarchical data structures that enable secure verification of data sets. In a Merkle tree, each node in the tree is given an index pair (i, j), denoted as N(i, j). The indices i and j are simply numeric labels associated with a specific position in the tree.

[0187] A characteristic of a Merkle tree is that the construction of each of its nodes is governed by the following equation:

[0188]

[0189] Where H is a cryptographic hash function.

[0190] Figure 3 An example of a binary Merkle tree constructed according to these equations is shown in FIG. As can be seen from the figure, the case i=j corresponds to a leaf node, which is simply the data D i The hash of the corresponding i-th group. The case i≠j corresponds to an internal node or parent node, which is generated by recursively hashing and concatenating child nodes until a parent node (Merkle root) is found.

[0191] For example, the node N(0,3) is constructed from four data packets D0,…,D3 as

[0192] N(0,3)=H(N(0,1)||N(2,3))

[0193] =[H(N(0,0)||N(1,1))||H(N(2,2)||N(3,3))]

[0194] =[H(H(D0)||H(D1))||H(H(D2)||H(D3))].

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

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

[0197] The main function of the Merkle tree is to verify a data packet D i There are N data packets The verification mechanism is called a Merkle proof and involves i The Merkle root R is used to obtain a set of hashes called a Merkle path. The Merkle proof of a packet is simply the minimal list of hashes required to reconstruct the root R by repeated hashing and concatenation, often called an "authentication proof".

[0198] If the prover knows all the groups D0,…,D N-1and its order, a proof of existence can be trivially performed. However, this does require significantly greater storage overhead than a Merkle proof and requires the entire dataset to be available to the prover.

[0199] The comparison between using a Merkle proof and using the entire list is shown in the table below, using a binary Merkle tree and assuming that the number of data blocks N is exactly equal to an integer power of 2.

[0200] The following table shows the relationship between the number of leaf nodes in a Merkle tree and the number of hashes required for a Merkle proof (Merkle proof).

[0201]

[0202] In this simplified scenario (where the number of data packets is equal to the number of leaf nodes), it has been found that the number of hashes required to compute a Merkle proof scales logarithmically. Clearly, computing a Merkle proof involving log2N hashes is much more efficient and practical than storing N data hashes and computing a proof of existence.

[0203] If we are given a Merkle root R, we want to prove that the data block D0 belongs to the ordered list represented by R A Merkle proof can be performed as follows:

[0204] i. Get the Merkle root R from a trusted source.

[0205] ii. Get the Merkle proof Γ from the source. In this case, Γ is the set of hashes:

[0206] Γ={N(1,1),N(2,3),N(4,7)}.

[0207] iii. Compute the Merkle proof using D1 and Γ as follows:

[0208] a. Hash the data block to get:

[0209] N(0,0)=H(D0).

[0210] b. Concatenate with N(1,1) and hash to get:

[0211] N(0,1)=H(N(0,0)||N(1,1)).

[0212] c. Concatenate with N(2,3) and hash to get:

[0213] N(0,3)=H(N(0,1)||N(2,3)).

[0214] d. Concatenate with N(4,7) and hash to get the root:

[0215] N(0,7)=H(N(0,3)||N(4,7)),

[0216] R′=N(0,7).

[0217] e. Compare the calculated root R′ with the root R obtained in (i):

[0218] 1. If R′=R, then confirm that D0 exists in the tree, thus confirming the data set

[0219] 2. If R′≠R, the proof fails and it cannot be confirmed that D0 is members.

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

[0221] SPV

[0222] Simplified Payment Verification (SPV), first proposed in Section 8 of Satoshi Nakamoto's 2008 white paper, "Bitcoin: A Peer-to-Peer Electronic Cash System," leverages these characteristics 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 block headers, which uniquely identify blocks so they can be located on the blockchain. As explained, the block header includes a data field that provides a unique digest, or fingerprint, of the entire block's contents, as well as a field that provides the Merkle root for the block. The Merkle root is generated by repeatedly hashing pairs of transaction IDs (TxIDs) in the block until a single hash is produced. The Merkle root provides an efficient and secure mechanism for verifying that a transaction is part of a block, allowing users and merchant nodes, such as wallets, to locally verify a specific transaction without downloading the entire blockchain. This is advantageous for users who do not need or wish to run a full node but only need to perform a localized check to determine whether a particular transaction is in a particular block (e.g., parties such as merchants and customers wishing to perform a transfer between them). In summary, SPV enables 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.

[0223] Thus, an SPV wallet has at least one advantage: power- and storage-constrained devices such as mobile phones and laptops can operate within the Bitcoin ecosystem because it only needs to confirm whether a transaction has been verified (hence the term "Simplified Payment Verification"), rather than performing a full check of the blockchain as other wallets do. Since an SPV wallet only downloads block headers and not any transactions, this significantly reduces the storage space, energy, and processing resources required for verification. For the reasons explained below, SPV wallets are particularly well-suited for use with embodiments of the present disclosure, and the term "verification" is used herein to include SPV checks.

[0224] Transaction blocks

[0225] Figure 4 An example of a blockchain block is schematically shown. Each block contains a block header and a set of transactions. The block header includes a hash of the previous block header, i.e., the hash of the block header of the block on which the current block is built. The block header also includes the Merkle root of a Merkle tree constructed using the transaction set. 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 corresponding internal nodes of the first internal level of the Merkle tree. Pairs of internal nodes of the first internal level are then concatenated and hashed to form corresponding internal nodes of the second internal level of the Merkle tree. This process of concatenating and hashing paired internal nodes is repeated until only a single hash remains: the Merkle root. This Merkle root is sometimes called the block Merkle root.

[0226] Turning now to the embodiments of the present disclosure, specific reference is made to Figure 5 、 Figure 6 and Figure 7 .

[0227] A segment of the Merkle tree that identifies the block

[0228] Assume that a particular party (e.g., Alice) wishes to verify some transactions. According to an embodiment of the present disclosure, at least one subset of transactions is identified, wherein the subset forms a segment of the entire Merkle tree for the block and / or is represented by a segment of the entire Merkle tree for the block. Thus, a transaction block can be logically divided into multiple segments based on the Merkle tree of the block, each segment including a subset of the transactions of the block, and each segment having its own root node (or "root hash"). This common root hash is sometimes referred to as a "segment hash" below to distinguish it from the root hash of the entire block. Transactions on the same level within a tree segment (i.e., the lowest level, sometimes referred to as the "leaf level" or "leaf layer") are siblings. All transactions in a given segment share the common root node of the segment. The common root node can belong to an adjacent level of the Merkle tree, i.e., a level immediately above the lowest level. Alternatively, the common root node can belong to a higher level. In general, the common root node can belong to any level between the lowest level of the Merkle tree and the Merkle root.

[0229] Breaking blocks into smaller parts based on a block-based Merkle tree offers significant technical advantages, including the ability to quickly and efficiently distribute transactions across multiple verifiers. For example, because the Bitcoin protocol uses a binary tree, binary distribution can be achieved across multiple machines. By using small binary tags as an indexing system for segments, the position of each segment in the entire Merkle tree can be quickly calculated, allowing the segments to be reassembled after verification has been completed to reconstruct the complete Merkle tree for the block. This binary indexing method will be discussed in more detail below.

[0230] Various techniques can be used to identify the segments, but according to one approach, the number of segments can be determined by the number of validators available in the system. For example, in a system with four validators, the Merkle tree can be split into four segments; if there are eight validators, the Merkle tree can be split into eight segments, and so on. Figure 7 As shown in controller 702 , the identification of segments of a given Merkle tree may be performed or influenced by a control entity.

[0231] refer to Figure 5 and Figure 6 The points explained above are further illustrated, where Figure 5 An example of how a Merkle tree may be partitioned into separate parts 502 to be assigned to verifiers is shown. Figure 5In the example of , each arrow represents a corresponding transaction, which is hashed to form a corresponding transaction identifier, which is used at the corresponding leaf node of the Merkle tree. The top of the Merkle tree is the block Merkle root. In this example, the transaction block represented by the Merkle tree contains 32 transactions. However, it should be understood that this is merely an illustrative example, and generally, the Merkle tree can contain any number of transactions depending on the number of transactions in the block. As shown in the figure, the Merkle tree is divided into four parts 502a to 502d indicated by dotted boxes. Each part 502 is linked by a corresponding public internal node (inner hash) 504 of the Merkle tree, which is represented by a solid circle. Each part 502 represents eight transactions. In this example, the public internal node 504 belongs to the fourth level of the Merkle tree. According to embodiments described herein, each respective portion 502 (or more precisely, transactions forming and / or representing a portion) is assigned to a respective verifier for processing, eg, for verifying transactions belonging to the respective portion 502 .

[0232] Figure 6 Another example of how a Merkle tree may be partitioned into parts 602 is shown. Figure 6 The Merkle tree in Figure 5 Now, in this example, the Merkle tree is divided into eight parts 602a to 602h, each part 602 represents four transactions. In this example, the public internal node 604 belongs to the third level of the Merkle tree. Figure 5 and Figure 6 The Merkle tree of is divided into more (e.g., 16) or fewer (e.g., 2) parts 502, 602. In general, the Merkle tree formed by the transaction set of the block can be divided into any number of parts 502, 602, where each part includes at least two transactions.

[0233] Assign segments to appropriate verification resources

[0234] After identification, the transaction subset is distributed across multiple verification resources, which for ease of reference may also be referred to as "verifiers". Figure 7 and Figure 9 In FIG, multiple verifiers are shown as resources A to D (704a to 704d). The allocation process can be performed by Figure 9 Component 904 and other dedicated units are shown to guide or influence, but are not limited to such.

[0235] Each verifier (704a-704d) can include one or more processing resources. Thus, at least one of the plurality of verifiers (704a-704d) can be or include at least one of the following: 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, among others. In essence, any of the plurality of verifiers can be comprised of any one or more types of processing resources or combinations of processing resources, each capable of verifying one or more transactions that are interconnected by segments of a block's Merkle tree. The plurality of verifiers (704a-704d) and other system components form a collective resource or entity 700, which will be referred to as a "(distributed) verification node."

[0236] Preferably, the distribution comprises assigning each segment to a respective verifier of a plurality of verifiers. The verifier may be arranged to at least:

[0237] ● operating on one or more transactions that constitute one or more segments that have been allocated to the one or more transactions;

[0238] ● verifying one or more transactions to verify that the one or more transactions comply with the blockchain protocol; and / or,

[0239] ● Verify that they can be identified in an existing repository such as a blockchain ledger or a database of known, registered, or spent transactions.

[0240] The activities of the verifiers and the assignment of subsets to different verifiers may be directed by the controller. Figure 7 Controller 702 is shown assigning subsets of transactions A through D of corresponding tree segments to verifiers 704a through 704d, respectively. System-level controller 702 coordinates the activities of systems or devices 704a through 704d within the distributed verification nodes and can control or influence tasks such as identifying tree segments using the Merkle tree of a block, assigning the identified segments to corresponding verifiers, reordering the verified tree segments into a complete Merkle tree for the block, and / or ordering transactions within a reconstructed block.

[0241] One or more of these verifiers may include at least one coordination entity that is configured to act as a verifier-level controller. Thus, any or all of verifiers 704a to 704d may include at least one controller component of its own. The lower-level controller can influence or direct operations, such as assigning tasks or subtasks to one or more processing resources within the verifier, rebuilding a Merkle tree for a given segment, or interacting with other system components (e.g., other verifiers or higher-level controllers, UTXO pools, wallets, etc.). In turn, the processing resources themselves can be further decomposed into smaller systems, one or more of which may include a controller and one or more processing resources of its own. In this way, the system can include a hierarchical architecture in which segment verification is performed by verification entities that include one or more processing resources for performing verification tasks, and one or more controllers for coordinating processor activity and performing communication between components.

[0242] In embodiments where the verifier includes multiple processing resources, the verifier can split its assigned segment into smaller segments. The verifier's controller can then distribute the sub-segments among the processors under its control. In this way, the verification process can be implemented in a hierarchical and distributed manner.

[0243] This hierarchical decomposition can also be extended to the transaction level, so that verification can be further decomposed into sub-processes or tasks for each transaction, rather than at the tree segment level. In this way, the verification of one or more individual transactions is decomposed into sub-tasks 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 is assigned to it.

[0244] Therefore, the present disclosure enables the simultaneous processing of many transactions, with the only limitation being the amount of hardware available to form distributed verification nodes, rather than the amount of available processing speed that becomes the bottleneck as in conventional technologies. This enables the blockchain processing system to be horizontally scalable without requiring changes to the underlying protocol of the blockchain network.

[0245] Therefore, the present disclosure deviates significantly from conventional verification methods, which are described below in the section entitled "Exemplary Technical Environment for Implementing Illustrative Embodiments of the Present Disclosure" and with reference to Figure 1 and Figure 2 As explained, the traditional approach involves verifying a block as a whole entity, while the verification node (see Figure 1 104) as a single computational unit. In contrast, embodiments of the present disclosure decompose the Merkle tree into multiple segments that are provided to different verifiers ( Figure 7 and Figure 9 704a to 704d), each segment and verifier can be further decomposed to increase the degree of distribution involved.

[0246] Furthermore, by breaking each block into segments based on its Merkle tree, embodiments of the present disclosure enable verifiers to access, download, and process small portions of a block, rather than the entire block. It should be remembered that the transactions in each segment hash (pairwise) to a single root value. This means that only the necessary, relevant transactions can be used to verify the segment, rather than downloading, storing, and processing the entire block as a whole. As protocols such as Bitcoin SV allow for expanded block sizes and the inclusion of larger blocks 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 enabling each verifier to receive and process only the (smaller) portion that is relevant to it. This results in faster overall verification times, improved blockchain networks, and improved applications running on the blockchain.

[0247] Furthermore, embodiments support and facilitate the use of SPV processes and resources, as such SPV only involves local verification of the portion of the Merkle tree that a given party is interested in. Thus, the tree-pruning nature of SPV technology is well-suited for use in conjunction with embodiments of the present disclosure. In an SPV context, a verifier can be provided with only the portion of the block data it requires, i.e., the block header or segment root and associated transactions.

[0248] When each validator has performed its checks and confirmed the validity of the segments it has processed, the block is guaranteed to be valid thanks to the hashing mechanism used to generate the tree.

[0249] Load balancing across multiple authenticators

[0250] Load balancing techniques and systems are known in the art, and their purpose is to evenly distribute tasks across multiple resources to improve efficiency. This is done to minimize the risk of some processing resources being idle while others are overloaded, leading to performance degradation or even failure. Therefore, load balancing becomes crucial in ensuring the resilience of the entire system, as well as its performance and efficiency. Embodiments of the present disclosure may utilize any known load balancing technique, such as static or dynamic load balancing. Additionally or alternatively, the load balancing method disclosed herein may be advantageously employed.

[0251] As described above, embodiments of the present disclosure may use an indexing system when assigning block segments to corresponding verifiers. Preferably, the indexing system is a binary indexing system. In this preferred system, each verifier is designated as a binary label or identifier. Assuming that each identifier is 4 bits in length, the first verifier is identified as 0000, the next verifier is identified as 0001, the next verifier is identified as 0010, and so on. Obviously, a 4-bit identifier allows for 256 verifier IDs, with the last verifier being identified as 1111 (i.e., verifier number 255 in decimal).

[0252] When a tree segment needs to be assigned to a verifier, the first 4 bits of its double hash (i.e., the segment hash of the tree segment) can be used to determine which verifier will process the segment. It should be remembered that the Merkle root is generated by hashing pairs of transaction IDs (TxIDs) in the block together to generate corresponding internal nodes (or internal hashes) of the Merkle tree, and then repeatedly hashing adjacent internal hashes until a single hash is finally produced. This double-hashed Merkle root provides an efficient, fast, and secure verification mechanism. In the context of the present disclosure, this also has the advantage of double hashing to generate random binary numbers. Each internal hash (including each segment hash) is itself double-hashed. Therefore, the first x leading digits of the segment hash can be used as an assignment index. A hash with four leading zeros will result in the tree segment being assigned to a verifier with ID 0000, while a hash with leading digits 0001 will result in assignment to a verifier with ID 0001, and so on. Randomly generating double hashes ensures that the tree segments are randomly distributed to the verifiers.

[0253] Although double hashing is often used when generating Merkle trees, it is not necessary to use double hashing in all examples; instead, single hashing can be used. In fact, any number of hashing operations will produce a random binary number. Load balancing tasks can be performed by dedicated system components, such as Figure 9 905, or may be provided elsewhere within the system 700, or associated with and in communication with the system 700.

[0254] Distributed download blocks

[0255] According to some embodiments, distributing segments of a block Merkle tree to different validators may be used to provide a faster, more efficient process for downloading portions or all of a transaction block.

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

[0257] A distributed node may require a full block—that is, the entire set of transactions that form the block. In this case, each validator assigned a tree segment downloads a subset of the transactions that form that segment. In other cases, a distributed node may only require certain portions of a block. In this case, only some validators may need to download their corresponding subset of transactions to obtain the required transactions.

[0258] Downloading blocks (or parts of blocks) in this way increases overall download speed because each validator processes only a subset of the transactions that make up the block. This contrasts with traditional block downloads, in which a given entity (e.g., a full node) must download the entire block, for example, by downloading each transaction in the order in which they appear in the block. Now, the block is downloaded in parallel by multiple validators. Blocks can contain tens of thousands of transactions, perhaps orders of magnitude more. Downloading that number of transactions by a single entity would consume significant resources and take a significant amount of time. Now, the computational burden is distributed across the validators, allowing each individual validator to consume a small fraction of the processing resources. Similarly, this reduces the overall time to download a block.

[0259] As discussed, each verifier can download a subset of transactions. These subsets can then be combined to reconstruct a block in a single storage location. (A "single storage location" refers to a storage resource as an independent entity or multiple associated storage resources forming a collective entity). To this end, each verifier can transmit its corresponding subset to a central controller of distributed nodes, which is configured to arrange the transactions in the correct order. Segment hashes (i.e., hashes of linked tree segments) can be used for this purpose. For example, a mapping of segment hashes to their positions in the Merkle tree can be maintained, such as from left to right (when the segment hashes appear in the Merkle tree). The transaction subsets can then be placed in order (e.g., from first to last) based on the corresponding segment hashes.

[0260] In some embodiments, each verifier (or the distributed nodes as a whole) can confirm that the correct transactions have been downloaded (or that the transactions have been downloaded correctly) by rebuilding the Merkle tree. After downloading a subset of transactions, the verifier can generate candidate segment hashes based on these transactions. Candidate segment hashes are constructed by hashing pairs of TxIDs to generate corresponding internal hashes, and repeatedly hashing the paired internal hashes until a candidate segment hash is generated. The level of the Merkle tree to which the candidate segment hash belongs will depend on the number of tree segments into which the Merkle tree is divided. The verifier can verify that the candidate segment hash is a hash of the Merkle tree. If the hashes do not match, it indicates that an error occurred during the download process. In some examples, each verifier can generate a candidate segment hash and send it to the controller for verification. For example, a candidate block Merkle root can be generated based on the entire set of downloaded transactions. Similarly, if the block has been downloaded correctly, the candidate Merkle root should match the actual block Merkle root (i.e., the Merkle root stored in the block).

[0261] In some cases, verifiers can verify downloaded transactions using the techniques described above. That is, each verifier is assigned a tree segment, downloads a corresponding subset of transactions, and verifies those transactions. In other cases, verifiers may not necessarily verify transactions and may simply download transactions for later use, for example, to send to a third party.

[0262] Distributed UTXO pool

[0263] Preferably, each verifier 704 forming part of a distributed verification node has its own repository (pool) for generating, storing, and / or maintaining unspent transaction outputs (UTXOs). This repository (pool) acts as a UTXO pool, which provides a record of unspent (i.e., unspent) outputs associated with blockchain transactions. Thus, each verifier's UTXO pool is based on the transactions assigned to it by the controller relative to the Merkle tree segments, and is constructed based on these transactions. In one embodiment, this can be a (graph) database that includes data related to the unspent UTXOs of transactions that have been assigned to a given verifier for processing. When a new Merkle tree segment is assigned to a verifier, a record is created in the database for each UTXO of which the verifier is aware. Therefore, from the perspective of a distributed verification node, the UTXO pool is not a single pool, but rather consists of multiple different UTXO pools, each of which is provided at or on a different verifier and includes a different set of UTXOs. Therefore, the UTXO pool for that node is distributed, both in terms of data and the resources for storing and / or processing that data.

[0264] This is significantly different from the traditional UTXO model, where each full node in the network has a copy of the UTXO pool, which tracks all UTXOs on the blockchain. In contrast, the present disclosure distributes the UTXO pool across multiple verification resources, each with a UTXO pool that is a subset of the blockchain's entire UTXO set. Each verifier's UTXO pool includes the UTXOs of the transactions that make up the sub-part of the Merkle tree that it is responsible for verifying.

[0265] According to this approach, each time a new block needs to be verified, it can be implemented in a manner similar to an SQL transaction log, as every command, event, and entry related to the database is recorded in this log. This article will use the term "database log" to avoid confusion caused by the use of the term "transaction," as is known with respect to blockchains, but will use the term "database log" to encompass terms such as "transaction processing log," "transaction log," and so on. Essentially, 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 to the database state, as is known in the field of computer-based databases (see https: / / en.wikipedia.org / wiki / Transaction_log).

[0266] Using an ordered historical database log means that the entire UTXO pool can be constructed by executing the history of the log in its original order. Advantageously, this ensures that a copy of the database can always be (re)generated when needed, and there is no need to store separate copies of the data. This ensures data integrity and requires fewer storage resources. Each UTXO pool can be stored, maintained, and processed separately. Also advantageously, if SPV technology operates on a pruned portion of the Merkle tree, then SPV technology can facilitate the creation of a separate UTXO database for each validator.

[0267] Transactions (TX) within the database can be structured in various ways, although a particularly advantageous approach is to structure transactions based on an identifier that includes the concatenation of a block ID and a transaction ID (block_ID ll TxID). Both the block ID and the transaction ID are 256-bit hashes, resulting in a secure and collision-free 512-bit concatenated field structure.

[0268] Structuring transactions in this way provides a fast, efficient lookup mechanism. Transactions can be sorted by block_ID so that all transactions with the same block_ID are located together in the database. Therefore, when a verifier needs a transaction (for example, to check whether the transaction's UTXO has been spent), the verifier can locate the transaction in the database by first searching for the corresponding block_ID and then searching for the corresponding TxID. The effect of this is that the search is limited to the relevant part of the database. This efficiency reduces the time, processing resources, and energy required for search operations, resulting in a significant improvement over the existing technology.

[0269] A flag or marker is associated with each UTXO in the verifier pool and indicates whether the UTXO is locked or unlocked. For convenience, this flag or marker may be referred to as the "lock flag". When a UTXO is marked as "locked", this indicates to the verifiers in the group (i.e., elsewhere in the distributed verification nodes) that the UTXO is not available for spending. Conversely, when a UTXO is marked as "unlocked", this indicates to the verifiers that the UTXO can be spent. Its effect is therefore to enable a verifier that has been assigned to verify a transaction spending a UTXO to signal to its peer that the transaction spent the UTXO, assuming that the transaction is proven to be valid, that the transaction has been redeemed and is therefore no longer spendable. The "locked" state means that spending is allowed, while the "unlocked" state means that spending is prohibited.

[0270] This lock / unlock flag can be a simple binary flag, such as 0 for "locked" and 1 for unlocked. The flagging mechanism is used internally by validators in the distributed node system to remove the flag from the transaction before interacting with the blockchain, ensuring that the transaction complies with the protocol rules.

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

[0272] When a validator discovers a newly allocated transaction spending a UTXO, it sends a message to each of the multiple validators, notifying them that the UTXO should also be locked in their respective pools. Essentially, the validator sends a communication to its peers indicating that it has discovered a spend involving a transaction with a specific hash ID at a specific time. Other validators do not need to receive the full transaction data; the transaction hash and the list of UTXOs it spent are sufficient for them to identify the relevant transaction and mark it as locked in their own databases. Upon receiving the message, each receiving validator checks whether the relevant UTXO is in its UTXO pool. If so, the lock flag is changed to "locked." This lock prevents the validator from allowing subsequent transactions to spend the same UTXO. If a new transaction does attempt to spend the same UTXO, checking the lock flag will indicate that the second spend attempt should be ignored. If the validator that sent the message determines that the verification failed and therefore the UTXO has not been spent, it can send another message to the validator peers to this effect, indicating that the UTXO's lock flag should be changed to "unlocked." Once a valid spend has been completed, a message can be sent to this effect, and the locked UTXO can be removed from the relevant UTXO pool.

[0273] In the above embodiment, each verifier has a single UTXO pool that includes the UTXOs of all transactions in all tree segments that have been assigned to it. However, by an alternative approach, the UTXO pool maintained by each verifier can be divided / split / separated into / composed of multiple sub-pools, one sub-pool for each block. In this way, a single UTXO pool can be organized into a logical hierarchy. By another approach, one or more verifiers can be set in association with corresponding multiple UTXO pools, each of which is associated with the UTXO for a set of one or more tree segments. Thus, in some embodiments, one or more verifiers can organize UTXO into separate UTXO pools for different single tree segments or according to certain predefined criteria such as tree segment type or tree segments within a given range. In such embodiments, the identifier can include a block ID that can be used to narrow the search to the relevant UTXO pool, and the search can then be performed within the pool to (attempt to) identify the relevant transaction by its TxID. It will be appreciated by those skilled in the art that in some embodiments, a hybrid of these approaches may be used, i.e., one or more verifiers within a distributed node may use a single UTXO pool approach, while other one or more verifiers are configured to use multiple separate UTXO pools and / or UTXO pools organized into sub-pools, or any combination thereof.

[0274] This prevents "double-spending," where a party attempts to spend the same UTXO twice. This provides a simple and secure locking mechanism that operates efficiently and quickly, regardless of the number or location of validators in the system, and maintains the security and integrity of transfers made on the blockchain.

[0275] Illustrative Systems of Possible Embodiments

[0276] Figure 7 and Figure 9 An exemplary system 700 is shown for implementing at least some of the described embodiments. Figure 8 A flowchart showing exemplary steps that may be taken in (a simplified view of) the method of the present disclosure is shown.

[0277] The system 700 may be a closed system in that the system may be associated with an organization and form part of a larger proprietary system. In this case, its data (e.g., transactions) may be received from other components within the organization's wider system and its results and outputs may be sent to internal destinations. Additionally or alternatively, the system 700 may be arranged to interface with various entities, some or all of which may be external to the organization. In this case, the system 700 may be arranged to provide verification functionality as a service. For example, the system 700 may be arranged to interact with a blockchain network to obtain the data it requires. Additionally or alternatively, the system may interact with entities that wish to use its verification services. Thus, the activities of the system 700 may be solely internal activities with respect to a particular organization or entity, or it may be open to interaction with external entities to provide verification services to other parties, or a combination of both. Communications between other internal or external entities may be coordinated by one or more interfaces or communication components, such as Figure 9 As shown in 902.

[0278] like Figure 7 and Figure 9 As shown, the system 700 includes a control entity 702 (or simply "controller") and a plurality of verification resources 704 (also simply "verifiers" herein). Figure 7 Only four verifiers 701a to 701d are shown, but the system 700 may generally include any number of verifiers. Figure 7 and Figure 9Controller 702 is shown as distinct from verifier 704, but it is not excluded that controller 702 may include or consist of one of verifiers 704. As described above, each verifier may include one or more processing resources and may include its own controller for coordinating its own internal activities. There is no technical or logical limitation to the hierarchical levels that can be implemented in this manner. However, for simplicity and ease of understanding, Figure 7 Only one (top) level of this hierarchy is shown.

[0279] like Figure 7 As shown, the controller 702 obtains a transaction set. The transaction can be received from a sending resource via an electronic channel or network. The sender can be any entity that wishes to perform some kind of verification check inside or outside the system organization as described above. For example, this can be a full node on a blockchain network, such as Figure 1 Node 104 in, or a digital wallet, or a merchant / SPV node that wishes to perform local checks related to blockchain-enabled transfers between parties. One or more interfaces 902 can facilitate data transfer between system 700 and sources external to the system.

[0280] Transactions form or can form blocks of transactions. Transactions can be obtained from a single source (e.g., from a block of a blockchain) or from different sources (e.g., one or more users, one or more blockchain nodes, etc.). Transactions can be obtained before they are published on the blockchain (i.e., before they are recorded in a block). Alternatively, transactions can be obtained after they have been recorded on the blockchain.

[0281] The controller 702 assigns a corresponding transaction subset to each verifier 704, as described herein. Each transaction subset forms at least a portion of a corresponding portion of a Merkle tree generated based on the entire transaction set and is linked by corresponding common internal nodes of the Merkle tree. Figure 7 In the example of , transaction subset A is assigned to verifier A, transaction subset B is assigned to verifier B, transaction subset C is assigned to verifier C, and transaction subset D is assigned to verifier D. After the transaction subsets have been assigned, the verifiers 704 then process their respective subsets. In some embodiments, this involves each verifier 704 verifying its respective transaction subset. To this end, the controller 702 can transmit the relevant transactions to the respective verifiers 704. The verifiers 704 can communicate back to the controller 704 to indicate that each transaction in its respective transaction subset is valid, or that at least one transaction is invalid.

[0282] At least one, but preferably some or all, of the validators 704a to 704d may have access to their own UTXO pools, which are Figure 9The pool includes storage facilities such as the above-mentioned database and may have an advantageous index structure including a concatenation of block IDs and transaction IDs. Figure 9 In the examples, these pools are shown as being included within the respective verifiers, but a person skilled in the art will readily appreciate that these pools may also / alternatively be provided in a manner that is external to the verifier but in communication with the verifier.

[0283] In one or more embodiments, the disclosed process may include a block-level verification phase during which incoming new blocks are tested against block-level standards. Exemplary block-level standards are described above and generally involve prescribed format requirements and features or restrictions that apply to the blocks themselves (rather than the transactions within the blocks). Examples include block size, block header structure or content, and similar standards. Such operations may be performed by the controller or a component of the controller, or by another system component.

[0284] In some embodiments, the method may further include a UTXO uniqueness confirmation module for evaluating whether each input to a transaction in a new block (i.e., each UTXO) is unique. If the same UTXO appears multiple times as an input in a new block, this indicates a potential double-spending problem and violates the UTXO uniqueness standard. If the UTXO uniqueness confirmation module identifies a UTXO that is referenced multiple times in a transaction input in a new block, it may output an error signal or other interrupt to indicate that the block will be rejected.

[0285] Assuming the new block is not rejected, i.e. all UTXO inputs are unique, the Merkle tree segments can be identified and their associated transactions distributed across the validator set. The identification process can be done as follows: Figure 9 The segment identification unit 903 and other components shown in FIG. The allocation process can be performed by the segment allocation unit (in Figure 9 The allocation unit 904 may distribute the block segments among the various verifiers using any of a variety of possible allocation schemes, but in an advantageous approach, the allocation scheme may be targeted at load balancing as described above. The allocation unit 904 may include (or communicate with) a load balancing unit 905. Although this Figure 9 7. The load balancing unit 904 is shown as a separate associated component of the system, but in other embodiments, the load balancing unit may be part of the distribution unit 904, or may be separate from the controller 702. Any combination of components may be readily employed.

[0286] Each verifier verifies the transactions associated with one or more segments they receive against the transaction-level verification standard. No synchronization paradigm is required between verifiers because they each independently verify whether the transactions assigned to them are valid. Each verifier outputs a result confirming the validity of the transactions assigned to it. The results are added or accumulated to confirm that all transactions in the segment are valid. If one of the verifiers identifies a non-compliant transaction (i.e., an invalid transaction), the verifier can issue an output, such as an interrupt or other signal, to indicate the presence of an invalid transaction. The interrupt or signal can be sent to other verifiers or a controller or another system component so that they can immediately stop testing their corresponding transactions and not waste more resources in verifying transactions that are to be rejected within the block.

[0287] In some examples, the system can be configured to check block-level criteria. This can be performed before assigning segments to verifiers, although it should be understood that the block-level verification phase can occur after, or in some cases in parallel with, the verifier's transaction-level verification testing.

[0288] Now refer to Figure 8 The accompanying figure illustrates, in flowchart form, an example method for verifying a block. The block contains multiple transactions, each transaction references one or more inputs, and each input is a UXTO (except in the case of Coinbase-generated transactions). The method is implemented using appropriate hardware and processor-executable instructions within a node on a blockchain network.

[0289] In operation, the distributed verification node 700 receives new block data in step S801. This can be an entire block, or, in the case of SPV-related verification, it can include only the portion of data required to perform the SPV check. For convenience, this data is referred to as a "block." The new block to be verified can be received from a mining node on the blockchain network that generated the new block and completed the 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 can be received from another (non-mining) node in the network. In some examples, the distributed verification node 700 verifies the block before forwarding it to any other node in the network. As described above, verifying the new block can include confirming that the block meets certain protocol-based criteria and / or other criteria that may be specified and required within a given implementation.

[0290] In step S802, the system 700 identifies a block of the Merkle tree of blocks. In S803, the segments are distributed to multiple validators; and in S804, the validators process their respective transaction subsets substantially in parallel and independently of each other. In S805, the validators signal the controller whether the verification succeeded or failed.

[0291] It should be noted that when used in conjunction with the description of parallel processors herein, the term "processor" does not necessarily refer to physically distinct microprocessors and may include any hardware or software implementation that enables parallel processing resources to independently and in parallel perform processor functions. A parallel processor may include a processor having multiple cores. In some cases, a parallel processor may include multiple separate processing units. Parallel processors may or may not share physical memory. Regardless of the implementation, each parallel processor has a software or hardware mechanism for signaling so as to output a signal in response to identifying an invalid transaction. The implementation of the parallel processor also includes providing the necessary data transfer mechanisms in software and / or hardware to route the allocated transaction data to the individual processors for local processing.

[0292] List the terms

[0293]

[00106] For purposes of illustration and not limitation, embodiments of the present disclosure are provided in the following enumerated clauses.

[0294] Features mentioned below in relation to a group of enumerated clauses or aspects of the disclosure are not intended to be limited in this respect, and any one or more features mentioned in relation to a group of clauses may be incorporated into one or more groups of clauses in the other group of clauses.

[0295] Clause Set 1:

[0296] Clause 1.1. A computer-implemented method for processing (e.g., verifying) at least a portion of a blockchain block, the blockchain block comprising a plurality of blockchain transactions and a root of a Merkle tree for the block;

[0297] The method comprises:

[0298] assigning respective subsets of the blockchain transactions to a plurality of processing (e.g., verification) resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective internal node of the Merkle tree; and,

[0299] Using the plurality of processing (e.g., verification) resources to process (e.g., verify) their respective subsets of blockchain transactions.

[0300] The term "verifier" may be used interchangeably with "verification resource." A plurality of verification resources may form a distributed verification node. At least one of the plurality of verification resources may include one or more processing resources. Additionally or alternatively, one or more of the plurality of verification resources may include a verifier controller assembly substantially as described herein.

[0301] The corresponding internal node can be a segment root. In other words, an "internal node" is a node in the Merkle tree that is neither the root node nor a leaf node of the entire tree. Transactions in each subset can share a corresponding common internal node.

[0302] In an alternative wording, 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. The portion of the Merkle tree may be a "segment" substantially as described herein.

[0303] Clause 1.2. The method of clause 1.1, wherein verifying the blockchain block and / or blockchain transaction subset comprises:

[0304] i) verifying and / or validating at least one blockchain transaction; and / or

[0305] ii) perform a Simple Payment Verification (SPV) process; and / or

[0306] iii) confirming whether a given blockchain transaction (Tx) is included in the blockchain block; and / or

[0307] 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.

[0308] Clause 1.3. A method according to clause 1.1 or 1.2, wherein:

[0309] At least one of the blockchain transaction subsets includes an identifier associated with, identifying, and / or representing the subset.

[0310] Clause 1.4. The method according to clause 1.3, wherein:

[0311] The identifier facilitates computing a position of the at least one subset within the Merkle tree.

[0312] Clause 1.5. A method according to clause 1.3 or 1.4, wherein:

[0313] The identifier comprises a portion of a hash of a blockchain transaction within the at least one subset of blockchain transactions.

[0314] Clause 1.6. A method according to any of the preceding clauses, wherein:

[0315] Assigning the respective subsets of blockchain transactions to the plurality of verification resources includes matching the respective subsets with respective verification resources based on respective identifiers associated with the subsets of transactions.

[0316] Clause 1.7. The method according to any of the preceding clauses, further comprising the following steps:

[0317] i) downloading at least one subset of blockchain transactions to at least one verification resource of the plurality of verification resources; and / or

[0318] ii) sending at least a subset of blockchain transactions to at least one verifying resource of the plurality of verifying resources.

[0319] Clause 1.8. A method according to any of the preceding clauses, wherein:

[0320] The Merkle tree comprises a binary tree or mesh of hashes of the plurality of blockchain transactions. Clause 1.9. A method according to any of the preceding clauses, further comprising the following steps:

[0321] Identifying and / or determining the subset of blockchain transactions within the plurality of blockchain transactions.

[0322] Clause 1.10. A method according to any of the preceding clauses, wherein:

[0323] At least one verification resource of the plurality of verification resources is or includes one or more of the following:

[0324] Virtual machines, servers, GPU-based computing resources, processing threads, and / or multi-processor systems.

[0325] Clause 1.11. A method according to any of the preceding clauses, wherein:

[0326] i) the at least two transactions are siblings in the Merkle tree; and / or

[0327] ii) The common node is a parent or ancestor of the at least two transactions.

[0328] Clause 1.12. A blockchain verification system for verifying at least a portion of a blockchain block, the blockchain block comprising a plurality of blockchain transactions and a root of a Merkle tree for the block;

[0329] The system includes a plurality of verification resources, each verification resource including:

[0330] processor; and

[0331] A memory comprising executable instructions, wherein when the processor executes the executable instructions, the system is caused to perform the computer-implemented method according to any of the preceding clauses.

[0332] Clause 1.13. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any one of Clauses 1.1 to 1.11.

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

[0334] In addition, a blockchain system (network) is provided, wherein the blockchain system (network) includes a plurality of computer-implemented nodes, wherein each node in the blockchain network includes:

[0335] processor; and

[0336] A memory comprising executable instructions that, when executed by the processor, cause the system to perform any variant of the computer-implemented method claimed or described herein.

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

[0338] 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 described in one or more of the following clauses:

[0339] Clause Set 2:

[0340] Clause 2.1. A computer-implemented method for downloading at least a portion of a blockchain block, the blockchain block comprising a plurality of blockchain transactions and a root of a Merkle tree for the block; the method comprising:

[0341] allocating respective subsets of the blockchain transactions to a plurality of processing resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective internal node of the Merkle tree; and

[0342] Using one, some, or all of the plurality of processing resources to download their respective subsets of blockchain transactions.

[0343] Each corresponding subset can be represented by the corresponding internal node, in the sense that the corresponding internal node can encode the corresponding subset. That is, the corresponding internal node can be generated based on (i.e., according to) the corresponding subset. Each transaction in the corresponding subset can be linked to the corresponding internal node through one or more hash operations.

[0344] Clause 2.2. The method according to clause 2.1, comprising:

[0345] One, some, or all of the plurality of processing resources send their respective blockchain transaction subsets to a central store.

[0346] Clause 2.3. The method according to clause 2.2, wherein:

[0347] The respective internal nodes of the Merkle tree have respective positions in the Merkle tree, and wherein the method comprises:

[0348] The respective blockchain transaction subsets are arranged based on the respective positions of the respective internal nodes of the Merkle tree.

[0349] Clause 2.4. A method according to any preceding clause, comprising:

[0350] One, some or all of the processing resources generate corresponding candidate internal nodes of the Merkle tree based on the downloaded corresponding subset of blockchain transactions; and the method further includes at least one of the following:

[0351] Verifying that the corresponding candidate internal node matches the corresponding internal node of the Merkle tree; and / or

[0352] Verifying that the corresponding 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

[0353] The corresponding candidate internal node of the Merkle tree is sent to one or more other processing resources.

[0354] Clause 2.5. A method according to any preceding clause, comprising:

[0355] Using one, some, or all of the plurality of processing resources to verify their respective subset of blockchain transactions.

[0356] Clause 2.6. A method according to Clause 2.1, wherein:

[0357] Verifying the corresponding blockchain transaction subset includes:

[0358] i) verifying and / or validating at least one blockchain transaction; and / or

[0359] ii) perform a simple payment verification process; and / or

[0360] iii) confirming whether a given blockchain transaction is included in the blockchain block; and / or

[0361] 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 block header of the blockchain block.

[0362] Clause 2.7. A method according to any of the preceding clauses, wherein:

[0363] At least one respective subset of the respective blockchain transaction subsets includes a respective identifier associated with, identifying, and / or representing the respective subset.

[0364] Clause 2.8. The method according to Clause 2.7, wherein:

[0365] The respective identifier facilitates calculation of the respective position of the at least one respective subset within the Merkle tree.

[0366] Clause 2.9. A method according to clause 2.7 or 2.8, wherein:

[0367] The respective identifiers are based on the respective internal nodes of the Merkle tree.

[0368] 10. The method according to clause 9, wherein:

[0369] The corresponding identifier comprises a portion of the corresponding internal node of the Merkle tree.

[0370] Clause 2.11. A method according to any of the preceding clauses, wherein:

[0371] Allocating the respective subset of blockchain transactions to the plurality of respective processing resources includes matching the respective subset with respective processing resources based on respective identifiers associated with the respective subset of transactions.

[0372] Clause 2.12. A method according to any of the preceding clauses, wherein:

[0373] The Merkle tree includes a binary tree or a mesh structure of hashes of the multiple blockchain transactions.

[0374] Clause 2.13. A method according to any preceding clause, comprising:

[0375] Identifying and / or determining the subset of blockchain transactions within the plurality of blockchain transactions.

[0376] Clause 2.14. A method according to any of the preceding clauses, wherein:

[0377] At least one of the plurality of processing resources is or includes: a virtual machine, a server, a GPU-based computing resource, or a multi-processor system.

[0378] Clause 2.15. A blockchain processing system for downloading at least a portion of a blockchain block, the blockchain block comprising a plurality of blockchain transactions and a root of a Merkle tree for the block; wherein the system comprises a plurality of processing resources, each processing resource comprising:

[0379] processor; and

[0380] A memory comprising executable instructions, which, when executed by the processor, cause the system to perform, or enable the system to perform, a computer-implemented method according to any one of the preceding clauses.

[0381] Clause 2.16. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor of a computer system, causes the computer system to perform, or enables the computer system to perform, a computer-implemented method according to any one of Clauses 2.1 to 2.14.

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

[0383] Clause Set 3:

[0384] Clause 3.1. A computer-implemented method comprising the steps of:

[0385] Generate, store and / or maintain a first UTXO repository for recording, searching and / or processing a plurality of unspent transaction outputs (UTXOs), each unspent transaction output being associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of a blockchain block;

[0386] in:

[0387] The plurality of blockchain transactions provide a portion of a Merkle tree for the blockchain block and / or are represented by a portion of a Merkle tree for the blockchain block.

[0388] Clause 3.2. The method according to clause 3.1, comprising:

[0389] Generate, store, and / or maintain at least one other UTXO repository.

[0390] Clause 3.3. The method according to clause 3.1 or 3.2, further comprising:

[0391] Creating and / or maintaining a database log comprising a history of actions, changes, and events related to the UTXO repository.

[0392] Clause 3.4. A method according to any of the preceding clauses, wherein:

[0393] The first UTXO repository and / or the at least one other UTXO repository includes at least one record associated with:

[0394] i) Unspent Transaction Outputs (UTXO); and / or

[0395] ii) an identifier associated with a) an unspent transaction output and / or b) a transaction (Tx) in the plurality of blockchain transactions.

[0396] Clause 3.5. The method according to clause 3.4, wherein:

[0397] The at least one record includes a record identifier having:

[0398] i) a block identifier (block_ID), which is associated with a blockchain block; and / or

[0399] ii) a transaction identifier (TxID), the transaction identifier being associated with a transaction (Tx) in the plurality of blockchain transactions.

[0400] Clause 3.6. The method according to clause 3.5, wherein:

[0401] i) the record identifier comprises a function of the block identifier (block_ID) and the transaction identifier (TxID); and / or

[0402] ii) the concatenation of the block identifier (block_ID) and the transaction identifier (TxID); and / or

[0403] iii) the transaction in the plurality of blockchain transactions is associated with an unspent transaction output (UTXO).

[0404] Clause 3.7. The method according to clause 3.5 or 3.6, further comprising the following steps:

[0405] At least one record in the UTXO repository is searched for, identified, accessed, or inserted using the record identifier.

[0406] Clause 3.8. A method according to any of the preceding clauses, wherein:

[0407] At least one unspent transaction output (UTXO) of the plurality (UTXOs) is associated with a lock flag in the UTXO repository, the lock flag:

[0408] i) indicating whether the unspent transaction output (UTXO) is available for spending; and / or

[0409] ii) configurable between a first state indicating that spending of the unspent transaction output is permitted and a second state indicating that spending of the unspent transaction output is prohibited.

[0410] Clause 3.9. The method according to clause 3.8, comprising the steps of:

[0411] i) associating the unspent transaction output (UTXO) with the lock flag; and / or

[0412] ii) changing the state of the lock flag from the first state to the second state, or from the second state to the first state.

[0413] Clause 3.10. The method according to clause 3.8 or 3.9, comprising the following steps:

[0414] Sending a communication from the first processing resource to at least one other processing resource to cause the at least one other processing resource to change the state of the 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.

[0415] Clause 3.11. The method of clause 3.10, wherein the communicating comprises:

[0416] i) the transaction (TX), the transaction identifier (TxID), and / or the hash of the transaction (Tx); and

[0417] ii) A list of one or more unspent transaction outputs (UTXOs).

[0418] Clause 3.12. The method according to clause 3.10 or 3.11, comprising the following steps:

[0419] receiving the communication at the at least one other processing resource;

[0420] The state of the lock flag is changed from the first state to the second state, or from the second state to the first state.

[0421] Clause 3.13. A method according to any of the preceding clauses, wherein:

[0422] i) the portion of the Merkle tree is a sub-portion or segment of the Merkle tree for the blockchain block; and / or

[0423] ii) The plurality of blockchain transactions are represented by internal nodes of the Merkle tree.

[0424] Clause 3.14. A blockchain-implemented system comprising a plurality of processing resources, each processing resource comprising:

[0425] processor; and

[0426] A memory comprising executable instructions, which, when executed by the processor, cause the system to perform, or enable the system to perform, a computer-implemented method according to any one of the preceding clauses.

[0427] 15. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor of a computer system, cause the system to perform, or enable the system to perform, the computer-implemented method according to any one of clauses 3.1 to 3.13.

[0428] Clause Set 4:

[0429] Any embodiment defined in any clause or combination of clauses in clause set 4 may be used to implement, or combined with, any one or more clauses in clause sets 1 to 3.

[0430] Clause 4.1. A system for verifying at least a portion of a blockchain block, the blockchain block comprising a plurality of blockchain transactions and a root of a Merkle tree for the block, the system comprising:

[0431] Multiple verification resources, each verification resource includes:

[0432] at least one processor associated with at least a portion of a memory storing executable instructions, the at least one processor, when executing the executable instructions, causing or enabling the verification resource to:

[0433] Verifying at least a subset of the plurality of blockchain transactions, wherein the at least a subset provides a portion of the Merkle tree and is represented by an internal node of the Merkle tree.

[0434] Clause 4.2. The system of clause 4.1, wherein the system further comprises:

[0435] i) a load balancing component for facilitating balanced distribution of subsets of the plurality of blockchain transactions across the plurality of verification resources; and / or

[0436] ii) a segment identification component for facilitating identification of the at least a subset of the plurality of blockchain transactions; and / or

[0437] iii) allocation units; and / or

[0438] iv) one or more interfaces for sending or receiving communications between the system and one or more data sources or destinations.

[0439] Clause 4.3. A system according to clause 4.1 or 4.2, wherein:

[0440] The system includes at least one controller component for influencing and / or controlling the operation of at least one of:

[0441] at least one verification resource;

[0442] at least one processor of the at least one verification resource;

[0443] One or more interfaces;

[0444] One or more load balancing components; and / or

[0445] One or more segment identification components for facilitating identifying the at least a subset of the plurality of blockchain transactions.

[0446] Clause 4.4. A system according to any of the preceding clauses, wherein:

[0447] i) at least two of the plurality of blockchain transactions are siblings in the Merkle tree; and / or

[0448] ii) The internal node is the parent or ancestor of the subset of blockchain transactions.

[0449] Clause 4.5. The system according to any of the preceding clauses, further comprising:

[0450] a plurality of UTXO repositories, each repository of the plurality of repositories being associated with a respective verification resource and configured to facilitate recording, searching, and / or processing a plurality of unspent transaction outputs (UTXOs);

[0451] Preferably, each of the plurality of unspent transaction outputs is associated with at least one transaction (Tx) among the plurality of blockchain transactions.

[0452] Clause 4.6. The system of clause 4.5, wherein the system is used to:

[0453] Creating and / or maintaining a database log comprising a history of actions, changes, and events related to at least one UTXO repository of the plurality of UTXO repositories.

[0454] Clause 4.7. A system according to any of the preceding clauses, wherein:

[0455] At least one UTXO repository of the plurality of UTXO repositories includes at least one record associated with:

[0456] i) Unspent Transaction Outputs (UTXO); and / or

[0457] ii) an identifier associated with a) an unspent transaction output and / or b) a transaction (Tx) in the plurality of blockchain transactions.

[0458] Clause 4.8. The system of Clause 4.7, wherein:

[0459] The at least one record includes a record identifier having:

[0460] i) a block identifier (block_ID), the block identifier being associated with the blockchain block; and / or

[0461] ii) a transaction identifier (TxID), the transaction identifier being associated with a transaction (Tx) in the plurality of blockchain transactions.

[0462] Clause 4.9. A system according to clause 4.7 or 4.8, wherein the record identifier comprises:

[0463] i) a function of the block identifier (block_ID) and the transaction identifier (TxID); and / or

[0464] ii) The concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0465] Clause 4.10. A system according to clause 8 or 9, wherein the system is used to:

[0466] The record identifier is used to search for, identify, access, or insert the at least one record in at least one UTXO store of the plurality of UTXO stores.

[0467] Clause 4.11. A system according to any of clauses 4.5 to 4.10, wherein:

[0468] At least one unspent transaction output (UTXO) of the plurality (UTXOs) is associated with a lock flag, the lock flag:

[0469] i) indicating whether the unspent transaction output (UTXO) is available for spending; and / or

[0470] ii) configurable between a first state indicating that spending of the unspent transaction output is permitted and a second state indicating that spending of the unspent transaction output is prohibited.

[0471] Clause 4.12. A system according to Clause 4.11, wherein the system is used to:

[0472] The state of the lock flag is changed from the first state to the second state, or from the second state to the first state.

[0473] Clause 4.13. A system according to any preceding clause, wherein the system is used to:

[0474] i) assigning respective subsets of the blockchain transactions to the plurality of verification resources; and

[0475] ii) downloading and / or receiving the corresponding blockchain transaction subset using one, some, or all of the plurality of verification resources.

[0476] Clause 4.14. A system according to any of the preceding clauses, wherein the system is used to:

[0477] generating, using one, some, or all of the verification resources, corresponding candidate internal nodes of the Merkle tree based on the downloaded corresponding subset of blockchain transactions; and the system is further configured to perform at least one of the following:

[0478] Verifying that the corresponding candidate internal node matches the corresponding internal node of the Merkle tree; and / or

[0479] Verifying that the corresponding 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

[0480] The corresponding candidate internal node of the Merkle tree is sent to one or more other processing resources.

[0481] Clause 4.15. A system according to any preceding clause, wherein the system is used to:

[0482] i) verifying and / or validating at least one blockchain transaction; and / or

[0483] ii) perform a simple payment verification process; and / or

[0484] iii) confirming whether a given blockchain transaction is included in the blockchain block; and / or

[0485] 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 block header of the blockchain block.

[0486] Clause 4.16. A system according to any of the preceding clauses, wherein:

[0487] At least one verification resource of the plurality of verification resources is or includes at least one of the following: a virtual machine, a server, a GPU-based computing resource, a thread, and / or a multi-processor system.

[0488] Article Set 5

[0489] Any embodiment defined in any clause or combination of clauses in clause set 5 may be used to implement any clause in any one or more of clause sets 1 to 4, or in combination with any clause in any one or more of clause sets 1 to 4.

[0490] Clause 5.1 A computer-implemented method comprising: using partial data derived from a blockchain to identify and / or allocate processing and / or storage resources, wherein the data from which the partial data is derived comprises: unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0491] Additionally or alternatively, the data may include transaction data used to determine that at least a portion of a transaction (Tx) is included in a Merkle path of a blockchain block (B).

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

[0493] A database of UTXOs and / or a database of transactions containing UTXOs may be established. The database may be a distributed database, thereby forming a distributed pool. The database may hold at least one of the following: an indication of the validity of the unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs; and information capable of determining the validity of the unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs, such as SPV information.

[0494] Prior to making an allocation to enable subsequent identification of the resource, the method may include retrieving partial data and / or associated data derived from the blockchain. After making an allocation, the method may include storing and / or verifying unspent transaction outputs (UTXOs) and / or transactions (Tx) containing the UTXOs.

[0495] The allocation may support load balancing among the multiple resources.

[0496] Clause 5.2. The method according to clause 1, further comprising: storing and / or processing at least a portion of the UTXO and / or the transaction (Tx) in the allocated resources; and / or storing and / or processing at least a portion of the UTXO and / or the transaction (Tx) by the allocated resources; and / or storing and / or processing at least a portion of the UTXO and / or the transaction (Tx) in association with the allocated resources.

[0497] The processing may include at least one of: verifying the UTXO and / or the transaction (Tx); managing information associated with the data into an accessible structure such as a database.

[0498] Clause 5.3. The method according to clause 5.1 or 5.2 further comprises: receiving, at the allocated resources, the data from which the portion of data is derived; parsing the data to determine whether to: process the data and / or store information derived from the data, or take no action.

[0499] Multiple resources can receive partial data and / or information associated with the data and determine whether they are responsible for storing information related to the UTXO.

[0500] Clause 5.4. A method according to any preceding clause, further comprising: exporting the portion of data from the blockchain.

[0501] Clause 5.5. A method as recited in any preceding clause, wherein identifying and / or allocating the processing and / or storage resources is performed by an intermediary connected to a plurality of allocated resources.

[0502] Clause 5.6. A method according to any of the preceding clauses, wherein the allocated resources perform at least one of the following: at least partially verifying the unspent transaction output (UTXO) and / or the transaction (Tx) containing the UTXO; generating, storing and / or maintaining records of verification data required to verify the unspent transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0503] Clause 5.7. The method of clause 5.1, wherein the data comprises at least one of: a UTXO identifier; a hash of the UTXO script; a transaction identifier (TXID).

[0504] Clause 5.8. A method as defined in any preceding clause, wherein processing the data comprises determining a key, wherein the key determines the allocated resources.

[0505] Clause 5.9. The method of clause 5.8, wherein the key is hashed and the resulting hash determines the allocated resources.

[0506] Clause 5.10. A method according to any preceding clause, wherein at least one of the data, the key, and the resulting hash comprises at least one of: an alphanumeric number, a binary number; and wherein the number is used to determine the allocated resources.

[0507] Clause 5.11. The method of clause 5.10, wherein a portion of the number is parsed to determine the allocated resources.

[0508] Clause 5.12. A method according to any preceding clause, wherein the allocated resources are determined by a hash table in which the UTXO and / or at least a portion of the transaction (Tx) are stored.

[0509] Clause 5.13. A method according to any one of clauses 5.6 to 5.12, wherein the record of at least a portion of the UTXO and / or the transaction (Tx) includes at least one of the following: a Merkle tree of a block for recording the transaction (Tx); a Merkle root of the block for recording the transaction (Tx); a Merkle path, wherein the Merkle path is capable of determining the value of the Merkle root of the block for recording the transaction (Tx) based on the hash of the transaction (Tx); a Merkle proof; a block identifier (block_ID), wherein the block identifier is associated with a blockchain block; a transaction identifier (TxID), wherein the transaction identifier is associated with a transaction (Tx) in a plurality of blockchain transactions within the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0510] Clause 5.14. A method according to any of the preceding clauses, wherein, for at least a portion of the transaction (Tx) and / or the UTXO, the method further comprises at least one of the following: verifying and / or validating the UTXO; performing at least a portion of a simple payment verification (SPV) process for the UTXO; confirming whether a given blockchain transaction (Tx) is included in the blockchain block; generating a hash of at least one of the blockchain transactions, using the hash to construct a Merkle path and / or checking whether the hash matches a transaction identifier (TxID) in a block header of the blockchain block; and determining a Merkle proof for the UTXO.

[0511] Clause 5.15. A computer-implemented method comprising the steps of: generating, storing, and / or maintaining a first UTXO resource for recording, searching, and / or processing a plurality of unspent transaction outputs (UTXOs), each of which is associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of a blockchain block; and using partial data derived from a blockchain to identify and / or allocate the resource, wherein the data from which the partial data is derived comprises: unspent transaction outputs (UTXOs) and / or transactions (Tx) containing the UTXOs.

[0512] Clause 5.16. A computer-implemented method comprising: receiving and / or processing an unspent transaction output (UTXO) for inclusion in a transaction; and / or, using partial data derived from the UTXO to identify an allocated resource, wherein the allocated resource holds verification data for the UTXO; and / or, requesting the verification data from the allocated resource.

[0513] Clause 5.17. The method of clause 5.16, further comprising obtaining from the allocated resources at least one of the following:

[0514] (i) verification of the UTXO and / or the transaction (Tx) containing the UTXO; and / or,

[0515] (ii) a record for determining the validity of the UTXO and / or the transaction (Tx) containing the UTXO.

[0516] Clause 5.18. A method according to any preceding clause, further comprising: preparing and / or transmitting a transaction (Tx), the transaction (Tx) having the UTXO as input.

[0517] Clause 5.19. A blockchain node configured to generate, store, and maintain at least one of a UTXO resource for recording, searching, and / or processing a plurality of unspent transaction outputs (UTXOs), wherein the node processes a portion of data derived from a blockchain to identify and / or allocate processing and / or storage resources, wherein the data from which the portion of data is derived includes: unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0518] Clause 5.20. A computer device comprising: a memory comprising one or more memory units; and a processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to, when executed on the processing device, perform a method according to any one of clauses 5.1 to 5.18.

[0519] Clause 5.21. A computer program embodied on a computer-readable memory and configured to, when executed on one or more processors, perform the method of any one of clauses 5.1 to 5.18.

[0520] Article Set 6

[0521] Any embodiment defined in any clause or combination of clauses in clause set 6 may be used to implement any one or more clauses in clause sets 1 to 5, or in combination with any one or more clauses in clause sets 1 to 3.

[0522] Clause 6.1 A computer-implemented method, the method comprising:

[0523] Generate, store, process, access and / or maintain a record of at least a portion of a transaction (Tx),

[0524] wherein the record comprises transaction data, the transaction data being used to determine that at least a portion of the transaction (Tx) is included in a Merkle path of a blockchain block (B).

[0525] Generally speaking, the records are used to hold information such as data items. As described elsewhere, the records can be stored in an allocated resource, such as a database, which can be part of a resource connected to the blockchain, such as a node or other resource connected to the blockchain network. The present invention is not limited in this regard, and the verification, allocation / identification, and formatting of the records can be used to implement the functionality of a node, which can be off-chain.

[0526] The record may include at least the transaction data and may also include status flags / status, verification information, validation data, detailed information about the location of the UTXO, and a reference to at least one previous record, such as location, signature, and authorization data. The record enables data related to the transaction to be stored and stored in a cataloged manner.

[0527] In other words, the record is part of a pruned version of a blockchain block. The record will be part of a collection of records, preferably stored in allocated resources, and holding data items taken directly from a block of the blockchain and / or data derived from the blockchain, such as verification data or a collection of information associated with a transaction.

[0528] The system 1100 manages the database and / or allocated resources 1104, which hold a record of transactions. The system can be thought of as operating like a node—the record holds transaction data, the transaction data has at least a portion of the transaction, and the at least a portion of the transaction is included in the Merkle path, thereby enabling the pruning of Merkle links.

[0529] For example, the system (e.g., a Merkle-linked pruned node) can be established and used by an owner. For example, blockchain data associated with a token issued by the Bank of England can be held as a record in the allocated resource. The record can be a pruned and / or enhanced version of the corresponding transaction data held on the blockchain.

[0530] As taught herein, configuring the record supplements at least one of verification of the transaction, allocation of processing and / or storage resources, and / or identification. The record content can improve security, resilience, and efficiency, or reduce speed and resource requirements, when used, including verifying the transaction to which the record relates.

[0531] The allocation and / or identification is based on partial data derived from all or at least a portion of a blockchain transaction, for example, the derived partial data includes transaction data, which may be unspent transaction outputs (UTXOs) and transactions (Tx) containing the UTXOs. Additionally or alternatively, the data may include transaction data used to determine that at least a portion of the transaction is included in a Merkle path of a blockchain block.

[0532] Clause 6.2. The method of Clause 1, wherein the record comprises a data catalogue, the data catalog being or comprising a collection of the transaction data.

[0533] Clause 6.3. The method of clause 1 or 2, wherein the record is processed and / or stored in the allocated resource (1104).

[0534] Clause 6.4. A method as described in any preceding clause, wherein the at least part of the transaction (Tx) is an output of the transaction.

[0535] Clause 6.5. The method of clause 4, wherein the output of the transaction is

[0536] Unspent Transaction Outputs (UTXO) and / or

[0537] A transaction (Tx), which contains the UTXO of a blockchain block.

[0538] Clause 6.6. A method according to any preceding clause, wherein the record is stored in a database, the record comprising:

[0539] i) a blockchain transaction (TX0), the blockchain transaction (TX0) comprising at least one data item (D); and

[0540] ii) at least one other blockchain transaction (TX1), said at least one other blockchain transaction (TX1) being necessary to confirm that said blockchain transaction (TX1) is included in said Merkle path of blockchain block (B).

[0541] Clause 6.7. A method according to any preceding clause, wherein using the database comprises generating, maintaining, providing, updating, storing, accessing or processing:

[0542] i) the database; and / or

[0543] ii) data, said data being stored in or associated with said database.

[0544] Clause 6.8. A method according to any preceding clause, wherein the record further comprises: a Merkle path from the transaction (TX0) to the root of the Merkle tree for the blockchain block (B).

[0545] Clause 6.9. A method according to any of the preceding clauses, wherein: the Merkle path includes at least: establishing or verifying the minimum blockchain transaction required for the blockchain transaction (TX0) to be included in the blockchain block (B).

[0546] Clause 6.10. A method according to any preceding clause, wherein the blockchain block is stored on or in association with:

[0547] i) blockchain ledger; and / or

[0548] ii) Off-chain storage resources.

[0549] Clause 6.11. A method according to any one of clauses 6 to 10, further comprising: using the blockchain transaction (TX0) and the at least one other blockchain transaction (TX1) to verify that: the blockchain transaction (TX0) is included in the Merkle path of the blockchain block (B).

[0550] Clause 6.12. A method according to any one of clauses 6 to 11, wherein the data item (D):

[0551] stored in association with the script in the transaction; and / or

[0552] Stored as metadata in the transaction.

[0553] Clause 6.13. A method as described in any preceding clause, wherein the record further includes: verification data required to verify the unspent transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0554] Clause 6.14. A method according to any preceding clause, wherein the recording further comprises:

[0555] A history of multiple previous transactions of the unspent transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0556] Clause 6.15. A method according to any preceding clause, wherein the recording further comprises:

[0557] History of the resources allocated, their processing and / or storage

[0558] The data of at least one previous transaction, preferably at least one transaction of the unspent transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0559] Clause 6.16. The method of clause 14 or 15, wherein the history comprises at least one of the following:

[0560] a set of transaction data, the set of transaction data being used to determine a Merkle proof of the previous transaction or transactions;

[0561] A link to the respective allocated resources that processed and / or stored the plurality of previous transactions.

[0562] Clause 6.17. A method according to any preceding clause, wherein the recording further comprises:

[0563] A flag and / or status indication of the or each input of the unspent transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0564] Clause 6.18. A method according to any preceding clause, wherein the record further comprises at least one of the following:

[0565] A Merkle tree of blocks recording the transaction (Tx);

[0566] a Merkle root of the block recording the transaction (Tx);

[0567] a Merkle path, wherein, based on the hash of the transaction (Tx), the Merkle path is capable of determining a value of the Merkle root of the block recording the transaction (Tx);

[0568] Merkel proved;

[0569] a block identifier (block_ID), the block identifier being associated with the blockchain block;

[0570] a transaction identifier (TxID), the transaction identifier being associated with a transaction (Tx) among a plurality of blockchain transactions within the blockchain block;

[0571] A function of the block identifier (block_ID) and the transaction identifier (TxID);

[0572] The concatenation of the block identifier (block_ID) and the transaction identifier (TxID);

[0573] Digital signatures;

[0574] Authentication code;

[0575] A signed message, wherein the signed message is used to determine the transaction status;

[0576] Protocol logo;

[0577] Autonomous Public Key (DPK);

[0578] Autonomous transaction ID (DTxID).

[0579] Clause 6.19. A method according to any of clauses 3 to 18, wherein the allocated resources for processing and / or storing the record are identified and / or allocated using partial data derived from a blockchain for identifying and / or allocating resources, wherein the data from which the partial data is derived includes the unspent transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0580] Clause 6.20. A computer-implemented method comprising:

[0581] Using a database, the database comprising at least one record, the at least one record comprising:

[0582] i) a blockchain transaction (TX0), the blockchain transaction (TX0) comprising at least one data item (D); and

[0583] ii) at least one other blockchain transaction (TX1), said at least one other blockchain transaction (TX1) being necessary to confirm that said blockchain transaction (TX1) is included in said Merkle path of blockchain block (B).

[0584] Clause 6.21. The method of Clause 20, wherein using the database comprises generating, maintaining, providing, updating, storing, accessing, or processing:

[0585] i) the database; and / or

[0586] ii) data, said data being stored in or associated with said database.

[0587] Clause 6.22. A method according to clause 20 or 21, wherein the record further comprises: a Merkle path from the transaction (TX0) to the root of the Merkle tree for the blockchain block (B).

[0588] Clause 6.23. A method according to clause 22, wherein the Merkle path includes at least: establishing or verifying the minimum blockchain transaction required for the blockchain transaction (TX0) to be included in the blockchain block (B).

[0589] Clause 6.24. A method according to any of clauses 20 to 23, wherein the block is stored on or in association with: a blockchain ledger; and / or an off-chain storage resource.

[0590] Clause 6.25. The method according to any one of clauses 20 to 24, further comprising:

[0591] The blockchain transaction (TX0) and the at least one other blockchain transaction (TX1) are used to verify that the blockchain transaction (TX0) is included in the Merkle path of the blockchain block (B).

[0592] Clause 6.26. A method according to any of clauses 20 to 25, wherein the data item (D) is: stored in association with a script in the transaction; and / or stored as metadata in the transaction.

[0593] Clause 6.27. A method according to any of clauses 20 to 26, wherein the transaction further comprises: a transaction ID (TxID); a protocol flag; a autonomous public key (DPK); and an autonomous transaction ID (DTxID).

[0594] Clause 6.28. A computer device comprising:

[0595] a memory comprising one or more memory cells; and

[0596] A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to, when executed on the processing device, perform the method according to any one of clauses 1 to 27.

[0597] Clause 6.29. A computer program embodied on a computer-readable memory and configured to, when executed on one or more processors, perform the method of any one of clauses 1 to 27.

[0598] Article Set 7

[0599] Any embodiment defined in any clause or combination of clauses in clause set 7 may be used to implement, or combined with, any one or more clauses in clause sets 1 to 6.

[0600] The present disclosure may include techniques for representing an item composed of multiple components using a tree structure. Data related to the components may be stored in corresponding blockchain transactions, which may be included in the tree structure.

[0601] Additionally or alternatively, aspects of the present disclosure may include using a tree structure to represent the constituent components of an item, each component being associated with a (possibly separate, corresponding) transaction on the blockchain.

[0602] Advantages include being able to track or verify the item at a granular level through the tree structure, even if the state of the item or its components changes over time. The components can be physical parts of a physical item or parts or features of a virtual or digital item. The term "attribute" can be used instead of "component."

[0603] In a non-limiting example use case, the item can be a vehicle such as an airplane. Data related to each component of the airplane can be included in the output of a transaction on the blockchain (e.g., manufacturer, manufacturing date, last service date, serial number, etc.). The data associated with various transactions can be recorded in a tree structure such as a hash tree. Over time, the outputs can be spent by new transactions, and the tree can be updated accordingly. Thus, the history of the airplane and its current status can be verified through the tree.

[0604] Thus, the method may provide a technical mechanism to ensure the integrity of data associated with an item and / or the history of the item.

[0605] Clause 7.1. A computer-implemented method comprising: processing a tree structure, the tree structure representing an item and / or at least one component of the item; and associating the item and / or the at least one component of the item with a blockchain transaction (Tx), the blockchain transaction (Tx) being represented in the tree structure.

[0606] Processing may include generating, storing, accessing, and maintaining at least one of the tree structure. The tree structure may be a hash tree. The tree structure may be asymmetric, such as an ontology tree.

[0607] Clause 7.2. A method according to clause 7.1, wherein the method further comprises: processing a record of the item and / or at least one component of the item; and at least one of the following steps: verifying that at least one of the item, at least one component of the item, and at least a portion of a blockchain transaction (Tx) is part of the tree structure; processing and / or storing at least one of the item, at least one component of the item, and at least a portion of a blockchain transaction (Tx) in allocated resources (1104).

[0608] The record may be data associated with the blockchain transaction. The record may include proof that at least one of the item, the component, and the blockchain transaction is part of the tree structure.

[0609] At least a portion of the blockchain transaction may be an output of the transaction. The output of the transaction may be an unspent transaction output (UTXO) and / or a transaction (Tx) containing a UTXO of a blockchain block. The record may be stored in a database (e.g., an allocated resource), the record comprising: i) a blockchain transaction, the blockchain transaction comprising at least one data item (D); and ii) at least one further blockchain transaction (TX1), the at least one further blockchain transaction being used to confirm that the blockchain transaction (TX1) is included in the tree structure.

[0610] Data associated with the item or component (e.g., the data item (D)) may be stored in association with the script in the transaction. Additionally or alternatively; and / or the data item (D) may be stored as metadata in the transaction.

[0611] The record may include verification data required to verify the blockchain transaction, such as unspent transaction output (UTXO), associated with the tree structure. The record may also include a history of multiple previous blockchain transactions.

[0612] Clause 7.3. The method of clause 7.1 or 7.2, wherein each term and component of the term is represented by a node and a leaf in the tree structure and is hashed to create a hash tree.

[0613] Clause 7.4. The method of clause 7.3, wherein a hash of the root node of the tree structure is stored in the blockchain transaction (Tx) on the blockchain ledger.

[0614] Clause 7.5. A method according to any preceding clause, wherein at least a portion of the tree structure is stored in a blockchain ledger.

[0615] The blockchain ledger may be a private ledger stored on a server. At least the hash of the root node may be stored on a public blockchain.

[0616] Clause 7.6. A method according to any preceding clause, further comprising: processing a second tree structure, the second tree structure representing the item and / or the at least one component of the item; associating the item and / or the at least one component of the item with a second blockchain transaction (Tx), the second blockchain transaction (Tx) being represented in the second tree structure; and associating the blockchain transaction in the tree structure with the second tree structure.

[0617] Clause 7.7. The method of clause 7.6, further comprising: processing the record to verify that at least one of the item, at least one component of the item, or at least a portion of a blockchain transaction (Tx) is part of the tree structure or the second tree structure.

[0618] Clause 7.8. A method according to any preceding clause, wherein the blockchain transaction comprises at least one of: a history of the or each tree structure from which the blockchain transaction originated; a history of the allocated resources in which the blockchain transaction is stored;

[0619] wherein the history enables verification that at least one of the item, the at least one component of the item, or at least a portion of a blockchain transaction (Tx) is part of the tree structure or the second tree structure.

[0620] Clause 7.9. A method according to any preceding clause, wherein the blockchain transaction (Tx) is used to identify and / or allocate the allocated resources.

[0621] Data associated with at least one of the item, the component, and the tree structure, or the associated blockchain transaction or a portion thereof may be used to identify and / or allocate processing and / or storage resources. The data may include, at least in part, unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0622] Clause 7.10. The method according to clause 7.9, further comprising: storing and / or processing at least a portion of the blockchain transaction (Tx) in the allocated resources; and / or storing and / or processing at least a portion of the blockchain transaction (Tx) by the allocated resources; and / or storing and / or processing at least a portion of the blockchain transaction (Tx) in association with the allocated resources.

[0623] Clause 7.11. A method according to any of clauses 7.2 to 7.10, wherein the blockchain transaction or a hash thereof is used to determine a key, wherein the key determines the allocated resource.

[0624] Clause 7.12. The method of clause 7.11, wherein the key comprises at least one of: an alphanumeric number; a binary number, and the number is used to determine the allocated resources.

[0625] Clause 7.13. A method according to clause 7.11 or 7.12, wherein the blockchain transaction, or a hash thereof, or a key is parsed to determine the allocated resources.

[0626] Clause 7.14. A method according to any of the preceding clauses, wherein the blockchain transaction further comprises at least one of the following: a Merkle tree of a block recording the transaction (Tx); a Merkle root of the block recording the transaction (Tx); a Merkle path that enables the value of the Merkle root of the block recording the transaction (Tx) to be determined based on the hash of the blockchain transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in a plurality of blockchain transactions within the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0627] Clause 7.15. A method according to any of the preceding clauses, wherein, for at least a portion of the blockchain transaction (Tx), the method further comprises at least one of the following steps: validating and / or verifying the blockchain transaction (Tx); performing at least a portion of a simple payment verification (SPV) process for the blockchain transaction; confirming whether the blockchain transaction (Tx) is included in the blockchain block; determining a Merkle proof of the blockchain transaction (Tx); proof that the associated blockchain transaction is part of the tree structure by using at least one of a hash of the root of the tree structure and a path, the path enabling determination of the hash of the root of the tree structure used to record the associated blockchain transaction based on the hash of the blockchain transaction.

[0628] Clause 7.16. A computer device comprising: a memory comprising one or more memory units; and a processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to perform a method according to any one of clauses 7.1 to 7.16 when executed on the processing device.

[0629] Clause 7.17. A computer program embodied on a computer-readable memory and configured to, when executed on one or more processors, perform the method of any one of clauses 7.1 to 7.16.

[0630] Exemplary technical environment for implementing illustrative embodiments of the present disclosure

[0631] An overview of a computing environment in which one or more embodiments of the present disclosure may be practiced will now be described. However, as noted above, this context is not intended to be limiting, and embodiments may be used to process data records and structures that are not implemented via a blockchain. For example, non-blockchain embodiments may be designed using a database rather than a distributed ledger.

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

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

[0634] Blockchain 150 comprises a series of data blocks 151, with a respective copy of blockchain 150 maintained at each of the plurality of blockchain nodes 104 in a distributed or blockchain network 106. As discussed above, maintaining a copy of blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, as long as each blockchain node 150 stores the block header (discussed below) for each block 151, blockchain 150 can be pruned. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain utilizes a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies a quantity of digital assets represented as a property amount, an example of which is an output cryptographically locked to a user 103 (requiring the user's signature or other solution to unlock and thus redeem or spend). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0635] Each block 151 also includes a block pointer 155, which points to the previously created block 151 in the blockchain, defining the order of blocks 151. Each transaction 152 (except for the coinbase transaction) includes a pointer to the previous transaction, defining the order of the transaction sequence (Note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transactions.

[0636] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 awaiting incorporation into blocks 151. The ordered pool 154 is often referred to as a "memory pool." As used herein, this term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid and for which it is mandatory that the node 104 not accept any other transaction attempting to spend the same output.

[0637] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the previous transaction 152i needs to exist and be verified as valid in order for the current transaction to be valid, the previous transaction 152i does not need to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by the pointer, and not necessarily the creation time or sending time in the time sequence, and therefore does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of orphan transactions below). The previous transaction 152i can also be referred to as a predecessor or predecessor transaction.

[0638] The inputs of the current transaction 152j also include input authorizations, such as the signature of user 103a to whom the outputs of the previous transaction 152i were locked. Conversely, the outputs of the current transaction 152j can be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152j can have multiple outputs to split the input amounts among multiple users or entities (one of which can be the original user or entity 103a for changes). In some cases, a transaction can also have multiple inputs to aggregate amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0639] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or organization, wishes to issue a new transaction 152j (either through an automated process employed by that party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient ultimately sends the transaction to one or more blockchain nodes 104 of the network 106 (typically servers or data centers, but in principle, other user terminals). It is also possible that the party 103 issuing the new transaction 152j may send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to a recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which is determined by the preceding transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of party 103 included in the inputs of new transaction 152j matches a condition defined in the outputs of the previous transaction 152i to which the new transaction assigns the condition, where the condition typically includes at least checking whether the cryptographic signature or other authorization in the inputs of new transaction 152j unlocks the outputs of the previous transaction 152i to which the inputs of the new transaction are linked. The condition may be defined, at least in part, by a script included in the outputs of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or by a combination thereof. In either case, if the new transaction 152j is valid, blockchain node 104 forwards it to one or more other blockchain nodes 104 in blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and, accordingly, forward the new transaction 152j to one or more other nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0640] In an output-based model, whether a given output (e.g., UTXO) is allocated (e.g., spent) is defined by whether, according to the blockchain node protocol, it is validly redeemed by the input of another subsequent transaction 152j. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Similarly, if invalid, transaction 152j will not be propagated (unless marked as invalid and propagated as a reminder) or recorded in the blockchain 150. This prevents double spending, where a transaction processor allocates the same transaction output more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, account balances have a single, defined state at all times.

[0641] In addition to verifying that transactions are valid, 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 blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that do not yet appear in block 151 recorded on blockchain 150. Blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that, when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition could be that the hash output has a certain predefined number of leading zeros. Note that this is only one specific type of proof-of-work puzzle and does not exclude other types. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs. Therefore, this search can only be performed by brute force, consuming significant processing resources at each blockchain node 104 attempting to solve the puzzle.

[0642] The first blockchain node 104 that solves the puzzle announces its solution to the network 106, providing the solution as proof. Other blockchain nodes 104 in the network can then easily verify the solution (given a hash value solution, it's straightforward to check whether the hash value output satisfies the conditions). The first blockchain node 104 propagates a block to other nodes, who accept it until a threshold consensus is reached, thereby enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, pointing to the previously created block 151n-1 in the blockchain. The significant amount of work required to create the proof-of-work solution (e.g., in the form of a hash) signals the first node 104's intention to follow the blockchain protocol. These rules include rejecting a transaction as valid if it allocates the same output as a previously validated transaction, otherwise known as a double spend. Once created, block 151 cannot be modified, as it is identified and maintained at every blockchain node 104 in the blockchain network 106. The block pointers 155 also impose an order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0643] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at that given time, depending on when they began their search for a solution or the order in which they received transactions. The person solving the corresponding puzzle first defines the transactions 152 to be included in a new block 151n and their order, and updates the current pool of unpublished transactions 154. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. Furthermore, there is a protocol for resolving any "forks" that may occur, in which two blockchain nodes 104 solve a puzzle within a short time of each other, thereby propagating conflicting views of the blockchain between nodes 104. In short, the fork with the longest fork direction becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0644] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional, accepted amount of digital assets in a new, special type of transaction that allocates an additional, limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often referred to as a "coinbase transaction," but may also be referred to as a "start transaction" or "production transaction." It typically forms the first transaction in a new block 151n. The proof of work signals the node that constructed the new block's intention to follow the protocol rules, thereby allowing this particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before this special transaction can be redeemed. Typically, a regular (non-production) transaction 152 will also specify 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 often referred to as the "transaction fee" and is discussed below.

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

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

[0647] Each of the multiple parties 103 acting as consuming users also has its computer device 102 connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without 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 the blockchain node 104).

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

[0649] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 also includes memory, i.e., computer-readable memory in the form of non-transitory computer-readable media. The memory may include one or more memory units, which use one or more storage media, such as magnetic media such as a hard drive, electronic media such as an SSD, flash memory, or EEPROM, and / or optical media such as an optical drive. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 configured to run on the processing device. It should be understood that any action attributed to a given party 103 herein may be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0651] Client application 105 includes at least a "wallet" function. This has two primary functions. One is to enable counterparty 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated across the network of blockchain nodes 104 and included in blockchain 150. The other function is to report to the counterparty the amount of digital assets they currently hold. In an output-based system, this second function involves collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties, which are dispersed across blockchain 150.

[0652] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client function described herein may be implemented in a suite consisting of two or more distinct applications, for example, interfacing via an API or one application as a plug-in to another. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or at any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0653] An instance of a client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality 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 to which the corresponding party 103 is a recipient (or indeed, to examine other parties' transactions in the blockchain 150, since, in embodiments, the blockchain 150 is a public utility that provides trust in transactions, in part, through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation within the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0654] When a given party 103 (say, Alice) wishes to send a new transaction 152j to be included in blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends the transaction 152j from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this might be the blockchain node 104 with which Alice's computer 102 is best connected. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its corresponding role. This involves first checking whether the newly received transaction 152j satisfies certain conditions for becoming "valid," specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or defined through a combination of script and node protocol.

[0655] If the newly received transaction 152j passes the validity test (i.e., is "valid"), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, the transaction 152j is assumed to be valid, which means that the transaction will soon propagate throughout the network 106.

[0656] Once accessed to the ordered pool of pending transactions 154 maintained at a given blockchain node 104, that blockchain node 104 will begin competing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (remember, other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, the first to solve the puzzle will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j. Once the pool 154 containing the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0657] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is "valid" before 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 a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

[0658] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In the account-based scenario, each transaction defines the amount transferred not by reference to the UTXO of a previous transaction in the past sequence of transactions, but rather by reference to absolute account balances. The current state of all accounts is stored independently in the blockchain by the network's nodes and continuously updated. In this type of system, transactions are ordered using an account's running transaction record (also known as its "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Optional data fields can also be signed in transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to the previous transaction.

[0659] UTXO-based model

[0660] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx") is the fundamental data structure of a blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to an output-based or "UTXO-based" protocol. However, this is not intended to limit all possible implementations. It should be noted that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other exemplary blockchain networks.

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

[0662] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In , Alice's new transaction 152j is labeled "Tx1". This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least part of such amount to Bob. Figure 2In the example, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels that do not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can point to any previous (i.e., predecessor) transaction that still has unspent outputs 203 locked to Alice.

[0663] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 may already be valid and included in block 151 of the blockchain 150. This transaction may already be included in one of the blocks within block 151, or it may still be waiting in ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together; or, if the node protocol allows for buffering of "orphaned" transactions, Tx0 may even be sent after Tx1. As used herein in the context of transaction sequences, the terms "previous" and "successor" refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, and so on). These terms could equally well be replaced with "predecessor" and "successor," "ancestor" and "descendant," or "parent" and "child." This does not necessarily refer to the order in which they were created, sent to the network 106, or arrived at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") pointing to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. Children that arrive at the blockchain node 104 before the parent are considered orphaned. Depending on the node protocol and / or node behavior, they may be discarded or buffered for a period of time to wait for the parent.

[0664] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must meet in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following conditions: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to whom the previous transaction was locked.

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

[0666] Thus in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , in order to redeem UTXO0 (strictly speaking, to make subsequent transactions that attempt to redeem UTXO0 valid). [Checksig P A ] contains Alice's public key P from her public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (e.g., through its transaction ID (TxID0), which in this embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0667] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing the two scripts:

[0668] <Sig PA> <pa>||[Checksig PA]

[0669] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating them. In either case, when run together, the scripts use Alice's public key P A (included in the locking script of Tx0's output) to verify that the unlocking script in Tx1's input contains Alice's signature when signing the expected partial data. The expected partial data itself (the "message") also needs to be included in order to perform this verification. In an embodiment, the signed data includes the entire Tx1 (so there is no need to include a separate element to plaintextally specify the signed partial data, as it is already present).

[0670] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has cryptographically signed a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can verify that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and appending this hash to the message as a signature, thereby enabling any holder of the public key to verify the signature. Therefore, it should be noted that, in embodiments, any reference herein to signing a particular data segment, transaction portion, or the like may also mean signing the hash of that data segment or transaction portion.

[0671] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (thus, in the example shown, if Alice's signature is provided and authenticated in Tx1), then the blockchain node 104 deems Tx1 valid. This means that the blockchain node 104 will add Tx1 to the ordered pool of pending transactions 154. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that it will be propagated throughout the network 106. Once Tx1 is valid and included in the blockchain 150, this defines UTXO0 from Tx0 as spent. It should be noted that Tx1 is only valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid, even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has already been spent (i.e., whether it has already formed a valid input of another valid transaction). This is one reason 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 marking the UTXO 203 of a transaction 152 as having been spent, but ultimately defining whether a UTXO is spent depends on whether it forms a valid input to another valid transaction in the blockchain 150.

[0672] 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 for failure in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0673] Note that in the UTXO-based transaction model, a given UTXO must be spent as a whole. You cannot "leave" a portion of the amount defined in a UTXO as spent while simultaneously spending another portion. However, the amount of a UTXO can be split across multiple outputs in subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split across multiple UTXOs in Tx1. Therefore, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to make change for herself in the second output of Tx1, or to pay another party.

[0674] In practice, Alice is typically also required to include a fee for Bitcoin node 104, which successfully includes Alice's transaction 104 in block 151. If Alice fails to include such a fee, Tx0 may be rejected by blockchain node 104 and, while technically valid, may not be propagated and included in blockchain 150 (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept it). In some protocols, transaction fees do not require their own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 is automatically provided to the blockchain node 104 that issued the transaction. For example, assume that 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 can be distributed among the node 104 that wins the proof-of-work competition to create the block containing UTXO1. Alternatively or additionally, this does not necessarily preclude that a transaction fee may be explicitly specified in one of the UTXOs 203 of the transaction 152 itself.

[0675] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Therefore, typically, a given party's 103 assets are scattered across the UTXOs of various transactions 152 throughout blockchain 150. No single number defining a given party's 103 total balance is stored anywhere in blockchain 150. The wallet functionality of client application 105 is responsible for collating the various UTXO values ​​locked to the respective parties and not yet spent in other subsequent transactions. To do this, it can query a copy of blockchain 150 stored at any Bitcoin node 104.

[0676] It should be noted that script code is typically represented schematically (i.e., using a non-precise language). For example, an opcode (opcode) may be used to represent a specific function. "OP_..." refers to a specific opcode in the scripting language. For example, OP_RETURN is a scripting language opcode. When preceded by OP_FALSE at the beginning of a locking script, the opcode creates an unspendable output of the transaction. This output can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may include a file to be stored on the blockchain.

[0677] Typically, transaction inputs contain a digital signature corresponding to the public key PA. In one embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In one embodiment, for a given transaction, the signature will sign some transaction inputs and some or all transaction outputs. The specific portion of the output that is signed depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at the time of signing).

[0678] The locking script is sometimes referred to as "scriptPubKey," meaning it typically includes the public key of the party to whom the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig," meaning it typically provides the corresponding signature. However, more generally, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily require signature verification. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferred.

[0679] Side Channel

[0680] like Figure 1 As shown, the client applications on each of Alice's and Bob's computer devices 102a and 102b can include additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). Side channel 107 enables data exchange outside of the blockchain network. This type of communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange transactions 152 between Alice and Bob without (yet) registering the transaction on blockchain network 106 or publishing it to chain 150 until one of the parties chooses to broadcast it to network 106. Sharing transactions in this manner is sometimes 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, side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, and so on.

[0681] Side channel 107 may be established via the same packet-switched network 101 as blockchain network 106. Alternatively or additionally, side channel 301 may be established via a different network, such as a mobile cellular network, or a local area network, such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a and 102b. Generally, any reference herein to side channel 107 may include any one or more links, via one or more networking technologies or communication media, used to exchange data "off-chain," i.e., apart from blockchain network 106. Where multiple links are used, the bundle or collection of off-chain links as a whole may be referred to as side channel 107. Therefore, it should be noted that if Alice and Bob are said to exchange certain information, data, etc., via side channel 107, this does not necessarily mean that all of this data must be sent over the exact same link or even the same type of network.

[0682] in conclusion

[0683] Other variations or use cases of the disclosed technology may become apparent to those skilled in the art once 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 of the embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of a blockchain 150, and the above description can generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 can be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the characteristics described above for the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104.

[0684] In a preferred embodiment of the present disclosure, blockchain network 106 is a Bitcoin network, and Bitcoin nodes 104 perform at least some or all of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150. It is not excluded that other network entities (or network elements) may exist that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing blocks (keeping in mind that these entities are not considered nodes of the preferred Bitcoin network 106).

[0685] In other embodiments of the present disclosure, 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, publishing, propagating, and storing blocks 151 of blockchain 150. For example, on these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0686] 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, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with respect to blockchain node 104.

[0687] The term "user" as used herein may include both human and machine-based entities.

[0688] The above embodiments illustrate rather than limit the present disclosure, and those skilled in the art will be able to devise numerous alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any reference signs in parentheses should not be construed as limiting the claims. The word "comprise" or "comprising" does not exclude the presence of elements or steps other than those listed in any claim or in the specification as a whole. In this specification, "comprise" means "include" or "consist of." The word "comprise" or variations such as "comprises" or "comprising" used throughout this specification will be understood to mean the inclusion of the specified elements, integers, steps, or groups of elements, integers, or steps, but not the exclusion of any other elements, integers, steps, or groups of elements, integers, or steps. The singular form of an element does not exclude the plural form of such element, and vice versa. The present disclosure may be implemented by hardware comprising several distinct elements and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by the same hardware. The fact that certain measures are recited in different dependent claims does not mean that a combination of these measures cannot be used to advantage.< / pa>

Claims

1. A computer-implemented method, comprising: processing a tree structure representing an item and / or at least one component of the item; as well as Associating the item and / or the at least one component of the item with a blockchain transaction (Tx), the blockchain transaction (Tx) being represented in the tree structure.

2. The method according to claim 1, further comprising: processing a record of said item and / or said at least one component of said item; as well as At least one of the following steps: verifying whether at least one of the item, the at least one component of the item, and at least a portion of a blockchain transaction (Tx) is part of the tree structure; At least one of the item, the at least one component of the item, at least a portion of a blockchain transaction (Tx) is processed and / or stored in the allocated resources (1104).

3. The method according to claim 1 or 2, wherein Each item and component of the item is represented by a node and a leaf in the tree structure and is hashed to create a hash tree.

4. The method of claim 3, wherein a hash of the root node of the tree structure is stored in the blockchain transaction (Tx) on a blockchain ledger.

5. A method according to any preceding claim, wherein at least a portion of the tree structure is stored in a blockchain ledger.

6. The method according to any one of the preceding claims, further comprising: processing a second tree structure representing the item and / or the at least one component of the item; Associating the item and / or the at least one component of the item with a second blockchain transaction (Tx), the second blockchain transaction (Tx) being represented in the second tree structure; as well as Associating the blockchain transaction in the tree structure with the second tree structure.

7. The method according to claim 6, further comprising: The record is processed to verify whether at least one of the item, the at least one component of the item, or at least a portion of a blockchain transaction (Tx) is part of the tree structure or the second tree structure.

8. The method according to any preceding claim, wherein the blockchain transaction comprises at least one of: the history of the or each tree structure from which the blockchain transaction originated; The history of the allocated resources stored in the blockchain transaction, wherein the history enables verification of whether at least one of the item, the at least one component of the item, or at least a portion of a blockchain transaction (Tx) is part of the tree structure or the second tree structure.

9. The method according to any of the preceding claims, wherein the blockchain transaction (Tx) is used to identify and / or allocate the allocated resources.

10. The method according to claim 9, further comprising: storing and / or processing at least a portion of the blockchain transaction (Tx) in the allocated resources; and / or storing and / or processing at least a portion of the blockchain transaction (Tx) by the allocated resources; and / or storing and / or processing at least a portion of the blockchain transaction (Tx) in association with the allocated resources.

11. The method according to any one of claims 2 to 10, wherein: The blockchain transaction or a hash thereof is used to determine a key, wherein the key determines the allocated resource.

12. The method of claim 11, wherein the key comprises at least one of: a number containing letters and numbers; a binary number, and the number is used to determine the allocated resources.

13. The method according to claim 11 or 12, wherein: The blockchain transaction, or a hash thereof, or a key is parsed to determine the allocated resources.

14. The method according to any preceding claim, wherein the blockchain transaction further comprises at least one of the following: A Merkle tree of blocks recording the transaction (Tx); a Merkle root of the block recording the transaction (Tx); a Merkle path that enables determination of a value of the Merkle root of the block recording the transaction (Tx) based on a hash of the blockchain transaction (Tx); Merkel proved; A block identifier (block_ID), which is associated with a blockchain block; a transaction identifier (TxID), the transaction identifier being associated with a transaction (Tx) among a plurality of blockchain transactions within the blockchain block; A function of the block identifier (block_ID) and the transaction identifier (TxID); The concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

15. The method according to any of the preceding claims, further comprising, for at least a portion of the blockchain transaction (Tx), at least one of the following steps: Verifying and / or validating the blockchain transaction (Tx); performing at least a portion of a Simple Payment Verification (SPV) process on the blockchain transaction; Confirm whether the blockchain transaction (Tx) is included in the blockchain block; Determine a Merkle proof of the blockchain transaction (Tx); Proof that the associated blockchain transaction is part of the tree structure by using at least one of a hash of the root of the tree structure and a path that enables determination of the hash of the root of the tree structure used to record the associated blockchain transaction from the hash of the blockchain transaction.

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

17. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 16.

Images