Computer implementation for recording data related to multiple components of an item

Abstract

The present invention relates to a computer implementation method for processing a tree structure representing an item and / or at least one component of an item. The item and / or at least one component of an item are associated with a blockchain transaction represented in the tree structure. Processing may include at least one of generating the tree structure, storing the tree structure, accessing the tree structure, and maintaining the tree structure. The tree structure may be a hash tree. The tree structure may be an asymmetric tree structure, such as an ontology tree. Records of an item and / or at least one component of an item can be processed. Items and / or components can be tracked and verified through the tree structure and associated data. Verification may include at least one of verifying that at least one of an item, a component of an item, and at least one part of a blockchain transaction (Tx) is part of the tree structure, storing the item, at least one component of an item, and at least one part of a blockchain transaction (Tx) in an allocated resource (1104), and / or processing in the allocated resource (1104).

Description

[Technical Field]

[0001] This disclosure relates, in general, to improved methods and systems for data recording and / or the format of such recordings and / or the processing and / or management of the content of such recordings. This disclosure is particularly suited to use with respect to transactions performed via or using a blockchain network, storage allocation decisions, pre- and post-mining verification of blockchain transactions, SPV checks, etc. Benefits include improved security and resilience, increased speed and efficiency or reduction of resource requirements, a new approach to verification, and resource balancing that was not possible with conventional technologies, thereby leading to blockchain implementation configurations that were previously impossible. The improved methods and systems are suited to recording and / or verifying items and / or their subcomponents, in instantaneous, temporal, and application-changed conditions, or at least one of these. [Background technology]

[0002] This specification may refer to the Bitcoin protocol and network for illustrative purposes, but disclosures are not limited to use on the Bitcoin blockchain and include alternative protocols and implementations.

[0003] A blockchain is a peer-to-peer electronic ledger, implemented as a computer-based, decentralized system, where blocks consist of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset among participants in the blockchain system, and includes at least one input and at least one output. Each block contains the hash of the previous block, and as blocks are chained together, a persistent and immutable record of all transactions written since the blockchain began is created.

[0004] For a transaction (Tx) to be written to the blockchain, verification is required. Network nodes (miners) perform the task of verifying that each transaction is valid, and invalid transactions are rejected from the network. Software clients installed on the nodes perform this verification by executing lock and unlock scripts on unspent transaction outputs (UTXOs). If the execution result of the lock and unlock scripts evaluates to TRUE, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, i) it must be verified by the first node that receives the transaction, and if the transaction is verified, the node relays it to other nodes in the network, i.e., the transaction is propagated, ii) it must be added to a new block built by miners, and iii) it must be mined, i.e., added to the public ledger of past transactions. Once a transaction is stored on the blockchain as a UTXO, a user can transfer control of the associated cryptocurrency to another address associated with the input of another transaction that will subsequently be written to the blockchain. This is usually done using a digital wallet that stores the public and private key pair associated with the user's cryptocurrency. There are various forms of known cryptocurrency wallets, and SPV wallets (Simplified Payment Verification) are one of them. SPV technology allows users and merchant nodes to perform local verification based on only partial information related to a specific transaction. SPV will be explained in more detail below.

[0005] However, with transaction volumes expected to increase, there is a need for improved capabilities to quickly determine the validity of unspent transaction outputs (UTXOs). Current verification techniques require significant resources and time, as they involve downloading and storing blocks, maintaining large UTXO pools, and executing the necessary processing tasks for verification. Many users may not be able to meet these requirements, or they may not want to, and therefore do not need to. Thus, a faster and more efficient verification model is needed that can address at least these challenges (and other challenges) without compromising security or requiring adaptation of existing protocols. Furthermore, the verification method needs to be scalable. And now, such an improved solution has been devised. [Overview of the project]

[0006] Embodiments of this disclosure provide improved blockchain-related methods, devices, and systems. In one form of expression, such embodiments provide solutions for the identification and / or processing and / or storage allocation 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 component. The tree structure enables recording and / or verification of the item and / or at least one component. Hereinafter, the term “tracking” may be used only as a substitute for “recording” for convenience. For example, a tree structure can be recorded at a point in time to instantaneously record the status of an item, component, or inventory, and the tree structure can change over time to reflect updates to the state and / or configuration of an item, or information associated with that item, and of course, the components of the item. The usage of an item or component can also be tracked, even if it has been updated, in which case the item or one of its components may be tracked using a first tree structure in a first application and tracked using a second tree structure in a second application, thereby enabling tracking of the history of the item or its components across different usage scenarios. Overall, tree structures can be used for end-to-end item tracking, for example, from the creation of an item to its final use or disposal. Tracking items using a tree structure makes it possible to verify the contents of the tree structure, i.e., the items and / or components as part of the tree structure. The status of an item or component is recorded over time, according to its progress in the process.

[0008] Item tracking can be achieved by associating an item and / or at least one component of an item with a blockchain transaction (Tx) represented in a tree structure. The blockchain transaction may contain data associated with the root of the tree structure, from which any data in the tree can be validated. For example, the tree structure might be a hash tree, and the data associated with the root of the tree structure would consist of the hash of the root of the tree structure. At least one node and leaf of the tree structure can also be associated with a blockchain transaction.

[0009] Data associated with an item or component can be held in a record, which is associated with a blockchain transaction. In some embodiments, item tracking can use techniques disclosed herein, such as techniques for determining whether a tree structure contains a record containing transaction data that proves at least part of a transaction (Tx). A record may include a proof. For example, a proof may include a Merkle path that enables verification that a component is part of a tree structure. Furthermore, a Merkle path may enable verification that a tree structure, such as its root hash, is part of a blockchain block (B). A record may include a data catalog, which is a set of transaction data or contains a set of transaction data.

[0010] In other embodiments, some of the data obtained from the blockchain, such as transactions, can be used to identify and / or allocate processing resources and / or storage resources.

[0011] Item tracking and / or verification involves processing records of the item and / or at least one component of the item. By processing the tracked item as part of a tree structure, it is possible to verify that at least one of the item, at least one component of the item, and at least one portion of the blockchain transaction (Tx) is part of the tree structure. Furthermore, allocated resources can be used to process and / or store at least one of the item, at least one component of the item, and at least one portion of the blockchain transaction (Tx).

[0012] The use of tree structures and the techniques described herein improves item verification, enabling structured, dynamic methods and systems for tracking and / or verifying the tree structure or parts thereof. Furthermore, verifying that an item or component is part of a tree structure can be done securely and without disclosing sensitive information related to other items or components in the tree structure.

[0013] By utilizing allocated resources, the scalability of tree-structured applications can be improved by providing secure solutions to control, manage, and / or enhance the efficiency, resource requirements, speed, and / or resilience of known approaches to processing blockchain transactions.

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

[0015] During the verification process, data can be securely exchanged and verified using the teachings in International Publication No. 2017 / 145016, which are incorporated herein by reference in their entirety.

[0016] Embodiments of this disclosure provide improved blockchain-related methods, devices, and systems. In one form of representation, such embodiments provide a solution for tracking items, at least one component of an item, and at least a portion of blockchain transactions associated with an item and / or component. The blockchain transactions may be stored in one or more distributed resources. In addition, or alternatively, these resources may be accessed to obtain data that enables (i) verification of the validity of a transaction (e.g., UTXO), and / or (ii) determination of the validity of the associated transaction.

[0017] Embodiments of this disclosure can be implemented in part or in whole by various devices. These devices may be hardware-based and / or software-based, and may include, but are not limited to, one or more virtual machines, servers, GPU-based computing resources, or multiprocessor systems. In addition, or alternatively, embodiments may include one or more digital wallets. However, importantly, the embodiments provide a mechanism for distributed processing of blockchain-related verification tasks. Coordinating, managing, and controlling distributed processes is known to be inherently technical in nature, as it requires a comprehensive understanding of the interactions between the relevant hardware and software components, and the implementation of such distributed solutions goes beyond the realm of simple technicality.

[0018] Embodiments can include solutions that enable or facilitate efficient identification and / or allocation of resources, where these resources store and verify at least one of the information associated with each UTXO and / or transaction. Embodiments support the scalability of the systems and methods described herein by balancing the distribution of information among resources. This not only balances the distribution of information among resources but also balances utilization, such as access to information by users, thus suppressing the occurrence of bottlenecks.

[0019] Embodiments can include distributing verification tasks among multiple processing resources, which for convenience are referred to herein as "validators". A validator may be composed of a single processing resource or may be composed of multiple related processing resources (which can also be regarded as verification resources together).

[0020] The method used for identification / allocation is based on pseudo-random number data obtained from the blockchain, thus supporting the uniform distribution and / or scalability of information across multiple resources. When information about a blockchain transaction (e.g., UTXO) is required, access is made to the resource to obtain at least one of (i) verification of the validity of the UTXO and / or related transaction, (ii) data for determining the validity of the UTXO and / or related transaction, and (iii) display and / or proof of the verification performed by the resource or validator.

[0021] In one or more embodiments, a validator may comprise or have access to a repository that records data regarding the work it has performed and / or the data it has processed. In one embodiment, this may include a database that includes unspent transaction outputs (UTXOs) assigned to a particular validator for processing. Recall that in the traditional model, all UTXOs on the blockchain are tracked by nodes within a database called the UTXO pool. To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be implemented, reference is made by way of example to the accompanying drawings.

Brief Description of the Drawings

[0022] [Figure 1] It is a schematic block diagram of a system for implementing a blockchain. [Figure 2] It is a diagram schematically showing some examples of transactions that can be recorded on a blockchain. [Figure 3] It is a diagram of a general Merkle tree structure known in the art. [Figure 4] As is known in the art, it is a diagram showing how a Merkle root can be derived from a set of blockchain transactions. [Figure 5] It is a diagram showing an example of a method of dividing a Merkle tree into subsets (or "segments") and allocating them to respective verification resources according to an embodiment of the present disclosure. [Figure 6] As another example from FIG. 5, it is a diagram showing a method of dividing a Merkle tree into logical segments. [Figure 7] It is a diagram showing a distributed verification node at the system level according to an exemplary embodiment of the present disclosure. [Figure 8] It is a flowchart showing at a high level the steps included in an exemplary method of the present disclosure. [Figure 9] It is a diagram showing the system example of FIG. 7 in more detail. [Figure 10] This is a schematic diagram of an example of the present invention, which includes identifying and / or allocating resources to generate, store, or maintain a database of information associated with transactions, such as unspent transaction outputs (UTXOs) and / or transactions containing UTXOs (Tx). [Figure 11] This figure shows a table illustrating examples of values ​​derived from some of the data used to identify and determine allocated resources. [Figure 12] This is a schematic diagram of the system, including nodes, intermediate switches, and allocated resources (resources with optional validators). [Figure 13] This is a schematic diagram of two transactions located within the Merkle tree of a blockchain block. These transactions have assigned resources, and the assigned resources hold corresponding records. [Figure 14] Figure 14(a) is a schematic diagram of an asymmetric tree structure in which the root node represents an item and the nodes and leaves represent components of the item, and Figure 14(b) is a diagram representing two consecutive blockchain transactions associated with a node or leaf in Figure 14(a). [Figure 15] Figure 14(a) is a schematic diagram of a two-tree structure in which blockchain transactions associated with a node or leaf (example) are processed and / or stored in the allocated resource (1104). [Figure 16] This is a flowchart illustrating how to process a tree structure. [Modes for carrying out the invention]

[0023] Hereinafter, illustrative embodiments of this disclosure will be described for illustrative purposes only, without limitation, with reference to the attached figures.

[0024] Means for processing and / or storing transaction information (e.g., unspent transaction outputs (UTXOs) and / or transactions containing UTXOs (Tx)) can be implemented using different systems and methods that can be configured and / or executed independently. Below are examples of a "transaction database" and a "block validation," each assigning tasks to resources such as distributed resources, which include storing and / or validating one or more transactions.

[0025] The following examples illustrate resource allocation / identification, where information such as records is assigned to resources related to the "UTXO database." Examples of transaction validation and validation methods / management (e.g., "block validation") are also described below.

[0026] In addition to, or as an alternative to, the examples of “assignment” and / or “verification,” at least one example includes generating, storing, processing, accessing, and / or maintaining a record of at least a portion of a transaction (Tx). The information stored in relation to a transaction, i.e., the record, can be used to support at least the verification of the transaction. For example, the record may include transaction data to determine whether at least a portion of the transaction is included in the Merkle path of a blockchain block.

[0027] The techniques taught herein are suitable for tracking items and at least one component of those items using a tree structure. The tree structure schematically represents the relationship between an item and at least one component. The state of an item and / or its component can be associated with the tree structure via blockchain transactions. Transactions can be used to verify and / or determine the provenance of an item and / or component from the point in time when it was first tracked using the tree structure. Tracking can be performed using one or more tree structures. Each tree structure can represent an item and / or component and alternative relationships with different items and / or components. The tree structures may be independent, and multiple tree structures can be used to track items and / or at least one component of an item using transitional blockchain transactions (Tx). The tree structure may be a Merkle tree, a binary tree, an ancestor tree, an asymmetric tree, or other asymmetric tree.

[0028] Therefore, a novel aspect of this disclosure can be considered to include, but is not limited to, the use of a tree structure to represent the components of an item (each component being associated with a transaction on the blockchain). The advantage is that the item can be tracked or verified at a detailed level through the tree structure, even if the state of the item or its components changes over time.

[0029] Records associated with an item and / or at least one component of an item can be managed using blockchain transactions (which may also be part of a blockchain token). The records contain information about the item or component, and the data relating to the tree structure associates the item and / or at least one component of an item with the blockchain transaction. Features of embodiments can be combined in light of the teachings herein.

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

[0031] A tree structure can be used to verify and / or determine the origin of items and / or components. This can be achieved through associations between data within nodes and leaves, preferably through the blockchain transactions associated with them.

[0032] The tree structure can be a hash tree (for example, a Merkle tree), which is a tree-like data structure used in cryptography to efficiently summarize large amounts of data and to prove the authenticity of the summarized data. Each leaf node 1404 represents a data block, and each node other than a leaf node (node ​​1402) represents the hash of its child node. The root node 104 is a summary of all the data in the tree and can be calculated as a hash by concatenating the hashes of all the leaf nodes.

[0033] By processing tree structures 1400, it becomes possible to determine the reliability of data within the tree structure using techniques such as root hashing, proof, and simplified payment verification.

[0034] Therefore, the validity of at least one item or component can be determined by associating an item and / or at least one component of an item with a blockchain transaction (Tx) represented in a tree structure, and by processing the tree structure or a portion thereof that represents the item and / or at least one component of an item. Processing includes at least one of generating, storing, accessing, and maintaining the tree structure. Associated data (e.g., records of the item or component) or updates to the entire tree structure can be updated, and the tree structure and associated items can be tracked.

[0035] By creating a tree structure 1400 to track items and / or their components, and associating items and / or at least one component of an item with blockchain transactions, the tree structure can be used to determine the verification and / or origin of items and / or components from the point in time they were first tracked.

[0036] The tree structure can change over time as at least one of the data, status, and properties of the node and leaf items and components is updated. Tracking becomes possible by using associations with blockchain transactions. Figure 14(b) shows how either the root node 104, node 1402, or leaf 1404 is updated, where the initial associated blockchain transaction Tx n TX n+1 These transactions are updated. These transactions are linked, allowing for immutable determination of records from the blockchain. For example, data associated with a node or leaf can be managed using blockchain tokens. In one example, only the root node 104 or its hash is recorded on-chain, but each of the leaves and nodes can also be recorded.

[0037] Records of items and / or components can be associated with blockchain transactions, and blockchain transactions can function as packets of data associated with an item or component. A record is an example of transaction data, and is data held within a blockchain transaction (for example, within the script of a blockchain transaction). A record can hold data about a tree structure that can be generated, stored, accessed, and subsequently maintained. A record can hold data that can be used (i) to validate an item, component, or tree structure, and / or (ii) to determine how to process and store data associated with the tree structure (for example, data associated with an item or component).

[0038] Once processing is complete, the tree structure can be used to verify that at least one of the following—an item, at least one component of an item, and at least one portion of a blockchain transaction (Tx)—is part of the tree structure. Blockchain transactions can be used to enable processing such as verification and storage. See Figures 10-13 for examples of storage and verification methods.

[0039] Tracing and / or verification involves calculating the hash of each node in the tree structure, where the node's hash is the concatenation of the hashes of its child nodes. To ensure the tree structure has not been tampered with, the hashes traversing the entire tree structure upwards can be checked. This can be done by calculating the hash of each node in the tree structure, where each node is assigned a unique hash value calculated based on the data stored in the node and the hashes of its child nodes. Next, starting from the leaf nodes, the hash of the parent node is compared to the hashes of the child nodes, and the hash value of each parent node is compared to the hash of its child node as the tree is traversed upwards. 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, and if all hashes match, the tree structure is considered authentic and tamper-free. Overall, the root hash can be used to determine the authenticity of the root node summarizing the tree structure by comparing the hash value to trusted hash values ​​previously stored or distributed to servers running public or private blockchains, etc.

[0040] In addition, or alternatively, after processing, the tree structure can be used to process and / or store in the allocated resource 1104 at least one of the following: items, at least one component of an item, and at least one portion of a blockchain transaction (Tx). The tree structure itself can be stored in the allocated resource. Each leaf and associated data can be stored, for example, for verification, but the hash of the root node 104 of the tree structure can, in addition, or alternatively, be stored in the blockchain transaction on the blockchain ledger, for example. The ledger (i.e., blockchain) can be generated according to the blockchain protocol implemented by nodes on the blockchain network.

[0041] In an example like Figure 14, the tree structure remains unchanged, meaning items and components maintain the same relationship. In this case, a record of the tree structure can be created by associating each item and / or component with at least one blockchain transaction. In practice, each item and component can be associated with its respective blockchain transaction. The tree structure is a hash tree, and the root hash and / or hashes of at least some of the data associated with an item or component, represented by nodes and leaves, can be recorded on a blockchain, such as a public blockchain. In addition, or alternatively, each blockchain transaction associated with each item and component can be recorded on a blockchain, such as a public blockchain, either in its original form or hashed. Blockchain transactions associated with items and / or components can be updated when the data associated with an item is updated. In this way, the data associated with an item or component can be tracked. Furthermore, this data can be verified.

[0042] In another example, the tree structure changes over time, for example, by updating the arrangement of nodes and leaves to reflect updates to the state or configuration of items, or to information associated with items or components of items. Similarly, items and / or components can be associated with at least one blockchain transaction, creating a record of the tree structure. For example, each new arrangement is recorded. In practice, each item and component can be associated with its own blockchain transaction. The tree structure is a hash tree, and at least some of the root hashes and / or hashes of the data associated with items or components represented by nodes and leaves can be recorded on a blockchain, for example, a public blockchain. Whenever the tree structure changes, the blockchain transaction associated with the item and / or component can be updated. The data associated with the item is updated and can include updated proof. In this way, the data associated with items or components can be tracked. Furthermore, this data can be verified.

[0043] Data representing an item or component (e.g., a record) associated with a blockchain transaction may include a proof that allows a third party to determine the validity of the data without knowing the entire tree structure. This proof can be updated whenever a change is made to the tree structure, or whenever the tree structure is modified. This proof can, for example, use blockchain transactions to determine the validity of an item or component using simplified payment verification techniques.

[0044] As yet another example, an item or component can be moved from one tree structure to another. Different tree structures may represent different entities (for example, physical entities), but the items or components within each structure are essentially the same, although the data associated with the item or component is updated. For example, the association with a blockchain transaction may be updated, or the record of its use or application may be changed.

[0045] Figure 15 shows a first tree structure 1500 and a second tree structure 1502, each having a node 1402 and a leaf 1404. The first and second tree structures each represent different entities. The two leaves are connected by hash lines, which represent the connections between the trees that occur when a component of the first entity represented in the first tree structure is transferred to the second entity represented in the second tree structure. Since the tree structures represent a specific point in time, the leaves are shown as part of the history of the tree structures. At least the hash of the root node 104, for example, is associated with a blockchain transaction and recorded in the blockchain ledger. Preferably, each node and leaf is associated with a blockchain transaction and likewise recorded in 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.

[0046] Figure 15 further shows that each tree structure can be recorded in a resource 1104 allocated according to the techniques taught herein in relation to Figures 10 to 13. In addition, or alternatively, data associated with each node 1402 and / or each leaf 1404, such as records, can be stored in the allocated resource.

[0047] For example, each department of a hospital can create X-ray data (components) and maintain them as records in a structured database (items). The structured database can be represented as a tree structure, as disclosed herein, and can be used to track the database and the items within it. The database and the X-ray data within it form part of the tree structure, and since at least one of the database and the X-ray data is associated with a blockchain transaction, the tree structure can be processed to determine at least the validity of the tree structure. However, the X-ray data may be transferred to another item, such as a patient record, and become part of another tree structure. By updating the blockchain transaction, for example, updating the blockchain token that holds the data associated with the X-ray data, the tree structure representing the patient record can be processed to determine the validity of the X-ray data. Validity can be determined from the transaction history and / or from the records in the blockchain transaction representing the X-ray that hold proof of the validity and / or provenance of the data, such as a Merkle certificate. The authenticity of the X-ray image can be determined because it can also be verified that it is part of the hospital database from which the data originates and part of the patient record. Thus, the item or component can be tracked, for example, end-to-end across the entire application. By making the entire patient record public, it becomes possible to determine legitimacy without infringing on privacy.

[0048] As another example, the first tree structure represents products manufactured on a production line, and data related to products such as automotive airbags, such as quality control inspections and manufacturing dates, is held in data packets, such as component records. These component records are part of the production records, i.e., items, and can serve as a database of production records. After production, the products are transferred to a warehouse, and the associated blockchain transactions are updated to indicate that the product (component) has become part of warehouse inventory (items) represented in a second tree structure, which includes multiple parts. Thus, the item and / or at least one part of the item are further associated with blockchain transactions (Tx) represented in the second tree structure. The blockchain transactions are updated and effectively transferred from the first tree structure to the second tree structure. The item and / or at least one part of the item are associated with blockchain transactions (Tx) represented in both tree structures. Thus, the history of the product is held in records associated with blockchain transactions. The maintenance history of an automobile can be represented in a third tree structure that includes MOT data (government inspection data), maintenance data, and details of replacement parts. The inventory of replacement parts such as headlamps, tires, and airbags can be represented as "items" in a tree structure, with each replacement part listed as a "component." When a new airbag is replaced in a vehicle, the third tree structure is updated to include a new node or leaf representing the airbag. For example, a blockchain transaction holding the airbag's data packet (i.e., a record of the component) may be updated and included in the blockchain transaction associated with the third tree structure, as shown in Figure 14(b). Through the blockchain transaction history and / or records held in the blockchain transaction, a third party wishing to verify the airbag replacement can process the tree structure representing the vehicle and confirm that the airbag is represented in the tree structure and is part of the vehicle.This is achieved by associating airbags with blockchain transactions (Tx) represented in a third tree structure. The record can additionally hold details of the airbag and / or an index indicating where the airbag details are located in at least one of the first and second tree structures to which the airbag is associated. Thus, the technology of the present invention enables the tracking of items or components and subsequent verification of those components. This can be consistently achieved from manufacturing to disposal, or from the beginning to the end of the product lifecycle.

[0049] Data associated with a blockchain transaction representing an item or component (e.g., a record) (if the item or component was part of another tree structure) may include further proof (e.g., further proof or second proof) that allows a third party to determine the validity of the data without knowing the complete tree structure or the complete second tree structure. A record may include historical data that can verify the complete provenance of the item. A record may include proof that a component (e.g., an airbag) was part of the tree structure of an item (e.g., a manufacturing facility, warehouse, or vehicle). Proof may include Merkle proofs.

[0050] Figure 16 shows step S1600 for processing tree structures 1400, 1500, and 1502. A tree structure can represent an item and at least one subcomponent. An item and / or at least one component of an item are associated with a blockchain transaction represented in the tree structure. The relationship between an item and a component can be determined from the relationship between the data associated with them (e.g., blockchain transactions). In one example, the tree structure is a hash tree, and the items and components within it, and / or the blockchain transactions associated with them, or parts thereof, can be hashed. At least one hash derived from the hash of the root node of the tree structure can be stored in a blockchain (e.g., a public blockchain). Preferably, hashes derived from each node and leaf can be stored in a blockchain, for example. Proof (e.g., Merkle proof) can be used to verify that an item or component is part of the tree structure.

[0051] In S1602, the processor may receive or retrieve a tree structure representing an item and / or its components. Furthermore, data associated with the tree structure may be retrieved, which may include information associated with the item and / or its components. This data may be a hash of the aforementioned 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 calculated based on the hashes of the data stored in the node and / or its child nodes.

[0052] In S1604, the processor processes the tree structure through association with blockchain transactions. These transactions can hold data about items or components within the script. Blockchain transactions can become part of blockchain tokens.

[0053] In S1606, an item or component can be validated as part of a tree structure. This can be done following or prior to processing and / or storing in the allocated resource 1104 an item and / or at least one component of an item associated with a blockchain transaction (Tx) represented in a tree structure (S1608). Data such as records of an item or component can be validated before storage and vice versa.

[0054] The verification techniques described herein propose the use of hash trees, in which the nodes and leaves of the tree are hashed to generate a hash of the tree's root. Other techniques can also be implemented in light of the teachings herein.

[0055] To verify that an item or component is part of a "hash" tree structure, the processor is provided with data indicating that it is part of the tree structure, such as the hash of the item or component. For example, someone trying to prove that an airbag was supplied to or replaced in a vehicle could provide the tree structure representing the vehicle, or the part of the structure that proves the airbag is part of the tree structure. For privacy reasons, only the part of the tree structure may be provided. Alternatively, for privacy reasons, only the hash data associated with other parts of the tree structure may be provided. Simple payment verification techniques can be used for verification.

[0056] The processor can use the tree structure, or a part thereof, to calculate the hash of each node 1402 in the tree, where the node's hash is the hash of its child nodes (including leaf 1404), concatenated together. To ensure the tree is valid and untouched, the processor can verify that the hashes are consistent throughout the tree up to the root node. This is achieved by the processor calculating the hash of each node 1402 and leaf 1404 and comparing the parent node's hash with the child node's hash. Starting from leaf node 1404, the processor traverses the tree upwards, comparing the hash value of each parent node with the hash of its child node. If the hashes match, it indicates 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 match, it indicates that the entire tree is authentic and untouched. The root hash can also be verified, which summarizes the entire tree structure.

[0057] Validating a tree structure allows you to verify an item or component by using its items or components to compare the provided data (for example, data associated with a vehicle's replacement airbag, or its hash value) with records in the tree structure that were previously stored or distributed.

[0058] Using two or more tree structures, an item or component can be verified by comparing the provided data, such as data associated with a vehicle's replacement airbag, or its hash value, with records in a first and second tree structure previously stored or distributed (see, for example, Figure 15). Having two or more tree structures enhances the item's history, which is beneficial when the item or component has a history spanning two or more applications and corresponding tree structures. Thus, a processor can process the record of an item or component to verify that at least one of the item, at least one component of the item, and at least one portion of a blockchain transaction (Tx) is part of a tree structure or another tree structure.

[0059] Data associated with an item, at least one component of an item, and at least part of a blockchain transaction (e.g., a record) includes the tree structure from which the associated blockchain transaction originated or the history of each tree structure, the history of the allocated resources in which the blockchain transaction is stored, and at least one proof that can verify that the item, component, or blockchain transaction is part of a tree structure (e.g., a first and / or second tree structure).

[0060] Verification of items, components, or blockchain transactions can be achieved by comparing them with stored data on the blockchain, such as manufacturing facility databases, warehouse inventory, or vehicle maintenance records. Data such as product records can be used to determine whether they are valid and originate from a specific tree structure.

[0061] By limiting verification to the minimum necessary scope for the item or component in question, decisions can be made while maintaining privacy. This protects the privacy of confidential information such as medical records.

[0062] As shown in Figures 13 and 15 above, the tree structure or any part thereof can be stored as data, such as records of allocated resources. Any part of the data associated with an item, component, or blockchain transaction can be used to identify and / or allocate allocated resources. Part of this data may be transactions, such as unconsumed transaction outputs (UTXOs) or transactions containing UTXOs (Tx). Figure 11 and its related explanation illustrate an example of how data can be used to determine allocated resources.

[0063] The teachings herein are suitable for processing secure and / or sensitive data, such as medical records, because they allow for the verification of items or components that are part of a tree structure without compromising the privacy of other items or components. Furthermore, the means for processing the tree structure can be extensible by quasi-randomly allocating storage for at least one of the items, components, or associated blockchain transactions. Thus, the allocation to resources can be load-balanced, which can be achieved by determining a key using at least one portion of the data associated with the item, component, or associated blockchain transaction. The key may include at least one of alphanumeric and binary numbers. The key can be determined by parsing at least one portion of the data associated with the item, component, or associated blockchain transaction. For example, the key and the associated allocated resource 1104 can be determined by hashing and / or parsing the data associated with a component.

[0064] Data associated with at least one of an item, component, or related blockchain transaction (e.g., a record) may include at least one of the following: a Merkle tree of the block in which a transaction (Tx) is recorded; a Merkle root of the block in which a transaction (Tx) is recorded; a Merkle path that allows determining the value of the Merkle root of the block in which a transaction (Tx) is recorded from 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 multiple blockchain transactions within a blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); and a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0065] At least one item, component, or piece of data associated with a related blockchain transaction (e.g., a record) may contain at least one proof that the related blockchain transaction is part of a tree structure (by using the hash of the root of the tree structure and at least one path that allows determining from the hash of the blockchain transaction the hash of the root of the tree structure in which the related blockchain transaction is recorded); and proof.

[0066] record Figure 13 shows two transactions generated from blockchain 150. The methods illustrated herein include at least one method for generating, storing, processing, accessing, and maintaining records of at least a portion of a transaction (Tx) in one of several resources 1104. The allocation and / or identification of the resource corresponding to each transaction is described below in relation to a UTXO database, where hash table technology is used as an example for allocation. Resource 1104 may be one of several resources that make up the database.

[0067] Figure 13 shows two Merkle trees constructed using the set of transactions within a block, which are used to determine the Merkle root included in the block header. Each transaction (Tx n and Tx n+1 These are parts of the respective Merkle trees, as will be discussed later, at least in relation to Figure 4.

[0068] A record is at least part of a transaction (for example, Tx n or Tx n+1 The record includes transaction data for determining whether the transaction is included in the Merkle path of blockchain block (B). The record holds data that enables efficient and cost-effective referencing and / or retrieval of information associated with the transaction, either alone or in combination with the examples taught herein. In particular, the information held in the record allows a third party wishing to verify a transaction to identify the allocated resource where the associated record is held and retrieve transaction data for determining whether 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 indicating that the transaction is part of a Merkle tree that determined the Merkle root of the block in which it is recorded.

[0069] A record can hold a dataset related to a transaction. A record can include, for example, shortened and / or concatenated data for efficient storage. The information within a record can be organized for reference. For example, a record can be organized into a data catalog. A data catalog can be structured, for example, by indexing, so that transaction-related information can be selectively identified and / or retrieved. A data catalog can hold transaction datasets, for example, Merkle certificates that enable simplified payment verification (SPV).

[0070] Records that can contain a data catalog can be managed by the resource and / or validator 1106. A record holds information that can be stored / associated with a transaction (e.g., a UTXO) and performs at least one of the following: validation, status display, signature retention, or transaction state. For example, a record might contain at least a portion of a script defining an "OP_PUSH_TX" to impose conditions on a transaction. Thus, a record can provide a catalog or library of information associated with a transaction.

[0071] The output of a transaction is either an unconsumed transaction output (UTXO) and / or a transaction (Tx) containing the UTXO of a blockchain block. As the UTXO and OP_PUSH_TX records suggest, this record is not limited to the output of a transaction, and at least a portion of a transaction (Tx) may contain the output, input, and / or other parameters of the transaction.

[0072] Records can be stored in a database. A database may contain multiple resources 1104 and / or validators 1106. A record may contain a blockchain transaction (TX0) which contains at least one data item (D). In addition, or alternatively, a record may contain at least one additional blockchain transaction (TX1) which is necessary to ensure that the blockchain transaction (TX1) is included in the Merkle path of a blockchain block (B).

[0073] Records such as data catalogs can be stored in a single database or distributed across multiple databases. The databases themselves can be distributed across multiple resources 1104. The storage of records (e.g., information and / or data) disclosed herein applies to and / or supports the efficient allocation, referencing, and access of records associated with nodes (e.g., metanet nodes) and associated metanet protocols.

[0074] The following applications are incorporated herein by reference in their entirety: PCT / IB2019 / 059793, this concerns node indexing and structuring. PCT / IB2019 / 059795, this supports the mapping from categories to mnemonics, for example, catalog creation. PCT / IB2019 / 059791, this supports resource searching. PCT / IB2019 / 059803 supports wallets, blockchain search systems, block explorers, etc., allowing users to search / access / view / write / retrieve some of the data contained in Metanet nodes (such as transactions), and to identify Metanet nodes based on the Metanet index. PCT / IB2019 / 060226 and PCT / IB2019 / 059807 support data partitioning across multiple nodes. PCT / IB2019 / 059808 supports the splitting of records across multiple transaction inputs and multiple transaction outputs, particularly in node attributes, and PCT / IB2019 / 059809 is used when an atomic swap (e.g., a conditional exchange) is established between two or more parties.

[0075] The use of a database and / or records and / or information may include the creation, maintenance, provision, updating, storage, access, or processing of: i) the database, and / or ii) data / records / information stored in or in relation to the database. A database is stored in or between one or more resources, and data, records, or information stored in the database is processed and / or stored in the allocated resource (1104).

[0076] In addition to, or alternatively to, a record containing transaction data for determining whether at least a portion of a transaction (Tx) is included in the Merkle path of a blockchain block (B), a record may hold a Merkle path from a transaction (TXO) to the root of the Merkle tree of the blockchain block (B). The Merkle path may include at least the minimum blockchain transactions necessary to establish or verify that a blockchain transaction (TXO) is included in the blockchain block (B). The records herein provide an efficient and effective means for verifying transactions. By allocating and identifying the resources on which the records are held, and / or combining them with the verification techniques herein, an improved system for managing and / or using transaction data is obtained. Transactions can be derived from blockchain blocks.

[0077] A blockchain transaction (TXO) can be used alone or in combination with at least one additional blockchain transaction (TX1) to verify that it is included in the Merkle path of a blockchain block (B). A data item (D) may be part of a record or information stored in an allocated resource, and is stored either associated with a script within the transaction or as metadata within the transaction. Overall, a record consists of the verification data necessary to verify the transaction, such as an unconsumed transaction output (UTXO) and / or a transaction (Tx) containing the UTXO.

[0078] Blockchain blocks can be stored on or associated with the blockchain ledger, off-chain storage resources, or in conjunction with them.

[0079] A record may contain the history of at least one preceding transaction, i.e., the transaction data of at least one preceding transaction. The history may include transactions with unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. At least one preceding transaction may be the transaction immediately preceding the last transaction.

[0080] The record may further include a history of the allocated resources that processed and / or stored at least the previous transaction. The record may include a link to the allocated resource that holds the previous transaction. The record may hold a history of multiple preceding transactions for unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0081] In this way, third parties using the history can retrieve the most recent transaction and, if necessary, efficiently identify previous transactions without further searching or investigation. The history can provide a back catalog or shortcut set to important records, data, or information. The history may include at least one of the following: a transaction dataset for determining Merkle proofs of preceding transactions, and links to the respective assigned resources that processed and / or stored those preceding transactions.

[0082] Referring to Figure 13, the first transaction Tx n The second transaction Tx n+1 This continues. In this example, the first and second transactions have related records stored in different allocation resources 1104, although they may also be stored at different addresses within the same allocation resource. The second transaction's record contains at least a link to the address of the first transaction within the allocation resource. The second transaction's record contains at least partially the transaction data record of the first transaction. The second transaction's record contains transaction data records of multiple preceding transactions.

[0083] Records may include flags and / or status indicators for transaction data (for example, each input of an unconsumed transaction output (UTXO) and / or the transaction (Tx) containing the UTXO). For example, these indicators may be "read," "in block," or "double-paid," allowing for an efficient reference to the status of transaction data.

[0084] A record can hold any number of transaction data information and / or supplementary data (e.g., verification data). Using records provides an alternative means of searching, identifying, and processing transaction data on-chain. Records can consolidate key data, thereby minimizing the computational cost of using transactions and performing operations with the blockchain and blockchain blocks. A record may further include at least one of the following: a Merkle tree of the block in which a transaction (Tx) is recorded; a Merkle root of the block in which a transaction (Tx) is recorded; a Merkle path that enables the determination of the value of the Merkle root of the block in which a transaction (Tx) is recorded from a 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 multiple blockchain transactions within a 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); a digital signature; an authentication code; and a signed message for determining the transaction state.

[0085] Resources allocated for processing and / or storing records are identified and / or allocated using a portion of the data derived from the blockchain to identify and / or allocate the resources, and that portion of the data includes transactional data such as unconsumed transaction outputs (UTXOs) and / or transactions containing UTXOs (Tx).

[0086] The examples and related systems herein enable the use of a database containing at least one record, the at least one record containing a blockchain transaction (TXO) containing at least one data item (D), and at least one additional blockchain transaction (TX1) necessary to ensure that the blockchain transaction (TX1) is included in the Merkle path of a blockchain block (B).

[0087] Database use includes generating, maintaining, providing, updating, storing, accessing, or processing data stored in or associated with the database and / or within the database. A record may further include a Merkle path from a transaction (TXO) to the root of the Merkle tree of a blockchain block (B). A Merkle path may include the minimum number of blockchain transactions necessary to establish or verify that a blockchain transaction (TXO) is included in a blockchain block (B).

[0088] The method described herein can verify that a blockchain transaction (TXO) is included in the Merkle path of a blockchain block (B) using a blockchain transaction (TXO) and at least one further blockchain transaction (TX1).

[0089] The aforementioned data item (D) can be stored in association with a script within a transaction, and / or as metadata within a transaction.

[0090] A transaction may further include at least one of the following: a transaction ID (TxID), protocol flags, a discretionary public key (DPK), and a discretionary transaction ID (DTxID). The above records, such as information and data related to, derived from, or associated with a transaction, can be stored in the allocated resources using the methods described below.

[0091] UTXO Database Figures 10 to 12 show the stages of a method for retrieving data from the blockchain, the table used for allocation to resource 1104, and the system for performing this method, respectively. The data is retrieved from the peer-to-peer (P2P) network 106 and / or blockchain 150. In 1000, data can be retrieved or extracted by, for example, requesting and retrieving one or more blocks from blockchain 150. Retrieval involves downloading at least a portion of a blockchain block containing multiple blockchain transactions. Retrieval or extraction of data is necessary, such as retrieving, copying, or reading data from blockchain blocks, when data is needed to establish and / or process stored historical data, such as transaction data already recorded in block 151 related to unconsumed transaction outputs (UTXOs) and / or transactions containing UTXOs (Tx). UTXOs currently in the memory pool or future transactions and UTXOs can be received via a connection to the network, for example, by implementing node 104 that receives broadcast transactions on the network.

[0092] Therefore, as a whole, the system 1100 in Figure 12 uses a portion of the data obtained from the blockchain to determine a key and allocate a corresponding resource to store information related to that data, such as unspent transaction outputs (UTXOs) and / or information related to transactions (Tx) containing UTXOs. To be clear, information related to the data obtained from the blockchain is stored in a resource for efficient and cost-effective reference. The data may include unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. A portion of that data is used to determine a key, which determines the allocated resource to store information about that data. The data from which a portion of the data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. In S1002, the portion of that data is used to identify or allocate a corresponding resource 1104, such as the allocated resource. In S1004, resource 1104 performs at least one of generating, storing, and maintaining an information database containing data related to UTXOs and / or transactions. This information includes information indicating the validity of UTXOs and / or information determining validity using, for example, SPV technology. Information about the data includes, for example, details of the block from which the data was retrieved (e.g., block ID), the Merkle path of the transaction (Tx) containing the unconsumed transaction output (UTXO) and / or UTXO, and the validity status of all UTXOs within the transaction.

[0093] Resource 1104 can be configured to store information that others can use to validate the UTXO, and / or information that can be used to process the data and generate indicators such as flags that show validity. In addition, or alternatively, Resource 1104 can delegate the determination of the validity of a transaction or UTXO in S1006 to Validator 1106. Storing and / or processing UTXOs and / or transactions (Tx) is implemented by an assigned resource, for example, by resource 1104 actively managing the information and maintaining a database associated with each UTXO such that the resource is self-manageable, and / or by an assigned resource, for example by the resource acting as a controller and functioning as a system 1100 that manages sub-resources for storing and / or processing information, and / or, in association with an assigned resource, for example by resource 1104 operating as part of system 1100 as shown in Figure 12, in a non-limiting example, by node 104 providing transaction and UTXO information to switch 1102 (e.g., a router), and switch 1102 deciding which of several resources to assign the task of generating, holding, and / or storing UTXO information in a database to. Overall, a resource can implement and perform one or more of the operations shown in Figure 10. Figure 12 shows system 1100 with components for individually performing the operations of Figure 10.

[0094] In one example, a task responsible for holding information associated with a UTXO is assigned to a single resource from a resource group within system 1100. Figure 12 shows eight resources as an example, each sharing information from the UTXOs with the others. However, the system can hold any number of resources and is expandable; for example, the system could have 16, 256, or 1024 resources. Thus, each resource is assigned a certain range of UTXOs to process, store, and / or maintain.

[0095] Unconsumed transaction outputs (UTXOs) and / or a portion of the data from transactions (Tx) containing UTXOs can be retrieved and / or received and parsed. The parsing determines which resource is assigned the task of storing the information. The parsing can be performed by resource 1104 or switch 1102. Node 1104, switch 1102, and at least one of resource 1104 can retrieve a portion of the data from the blockchain. Once parsing is performed by node 1104 or switch 1102, the information is sent to the assigned resource. Identification and / or assignment to processing resources and / or storage resources can be performed by nodes and / or switches acting as intermediaries. These nodes or switches are connected to multiple assigned resources and act as managers for many resources 1104, determining which resource manages which UTXO / Tx. If analysis is performed by resource 1104, resource 1104 will process the data and / or store information derived from the data, or store data associated with the data, or take no action if it is not responsible for the UTXO.

[0096] Once the allocation of resource 1104 is determined, for example, where the information related to UTXOs / Tx will be stored, resource 1104 can perform the processing in S1004 to generate, store, and / or maintain information related to unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. Resource 1104 can process the received data to determine the validity of the UTXOs / Tx (for example, S1006), or it can delegate that task to validator 1106. Resource 1104 and / or validator 1106 can validate at least a portion of the unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0097] The data is retrieved from the peer-to-peer (P2P) network 106 and / or blockchain 150. This data is retrieved by node 104 and / or switch 1102 and assigned to a resource. The data is also retrieved by resource 1104 itself and searched and parsed according to the assigned range of UTXO / Tx. The retrieved data includes at least one of the following: UTXO identifier, UTXO script hash, and transaction ID (TXID).

[0098] The retrieved data is associated with a UTXO or a transaction with UTXO functionality and provides a key that identifies and / or assigns a resource to store, maintain, or generate the corresponding information. The key is determined either directly using a portion of the data, for example, such as determining the resource assigned by the key, or indirectly by hashing a portion of the data and processing it so that the assigned resource is determined by the resulting hash.

[0099] The key is used to determine which resource 1104 holds the corresponding information associated with that key. Therefore, 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 that key is used to determine which resource holds the information associated with the UTXO and / or transaction. The data and key not only enable resource allocation, but also allow retrieval of the stored information by searching and accessing that information using the key.

[0100] At least one of the data, key, and resulting hash consists of at least one alphanumeric character and one binary character. This numerical value is used to determine the allocated resource.

[0101] For example, part of the data consists of unused transaction outputs (UTXOs) and / or transactions (Tx) that contain UTXOs. Input to a transaction includes a transaction ID that references the transaction containing the UTXOs to be used, an output index (e.g., Vout) that identifies which UTXOs in that transaction are being referenced, a scriptSig that satisfies the unlock conditions for the UTXOs, and a sequence number.

[0102] Potential recipients of a UTXO need to validate the UTXO before the transaction using that UTXO is compiled and broadcast. Existing validation methods are slow, resource-intensive, and computationally expensive. By using some of the UTXO's data, or related transaction information, the UTXO can be validated, or information that enables validation can be stored in a resource. By using some of the UTXO's unique data, a key can be determined. This key determines the allocated resource from which the related information can be stored, and from which the information can then be retrieved.

[0103] As a non-restrictive example, a Transaction ID (TxID) is typically represented in hexadecimal, but can also be represented in binary. Figures 11(a) to (d) are tables illustrating how to determine an assigned resource using a portion of the data. A portion of the data (e.g., a TxID) can be parsed directly or processed through hashing or other methods. In Figure 11(a), the TxID is parsed to select the first three digits of the binary number as the key, and the resource assigned according to that binary value (for example, information associated with a TxID whose first three digits are "101") is allocated for storage / processing to the assigned resource "6". Using the first three binary digits allows us to identify one of eight resources, while Figure 11(c) shows how to support allocation among 16 resources by taking the first four digits of the binary form of the TxID. For example, information associated with a TxID whose first four digits start with the binary number '1011' is allocated for storage / processing to the assigned resource '12'. Alternatively, as shown in Figure 11(b), a hexadecimal value of the TxID may be used, in which a single hexadecimal value is mapped to a resource, for example, assigned from 'c' to '13', and as shown in Figure 11(d), a range of hexadecimal values ​​is assigned to a resource, for example, information associated with a TxID starting with '76' is assigned to resource '8'.

[0104] Alternatively, since a portion of the data can be processed (e.g., hashed) to generate a hexadecimal or binary number, the determination of the key for identifying / assigning the portion of the data to the subsequent resource 1104 is not limited to the TxID.

[0105] A portion of the data selected from a transaction or its UTXO, or processed values ​​such as hash values, is pseudo-random. Resource allocation is load-balanced; that is, a portion of the data used to determine the key for resource allocation is pseudo-random, distributing processing and / or storage across multiple resources. This distributes information associated with a transaction / UTXO across multiple resources. Balancing allocations across resources minimizes the risk of performance degradation or failure, as some processing resources may become idle while others become overloaded. This improves the resilience, performance, and / or efficiency of System 1100.

[0106] Therefore, the data and parts of the data can be used to (i) determine the allocated resources, and then (ii) provide references to identify the resources and / or information associated with the data within those resources, for example, in a database.

[0107] As a result, some of the data is derived from the blockchain, and the keys and corresponding resources that store the information associated with that data, namely the unspent transaction outputs (UTXOs) and / or the information associated with the transactions (Tx) that contain the UTXOs, are determined.

[0108] An actor requesting validation of a UTXO's validity can use the UTXO and / or a portion of the transaction holding it to identify a resource that holds information usable to determine the validity of the UTXO and / or the transaction. This information may include flags or markers indicating whether the UTXO is locked or unlocked (e.g., invalid or valid (e.g., suitable for inclusion in subsequent transactions)). This information may additionally or alternatively include records of the UTXO and / or the transaction holding it, enabling the actor to validate the UTXO efficiently and independently.

[0109] A record may include, in at least part, a Merkle tree of the block in which a transaction (Tx) is recorded, a Merkle root of the block in which a transaction (Tx) is recorded, a Merkle path that allows the value of the Merkle root of the block in which a transaction (Tx) is recorded to be determined from 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 one of several transactions (Tx), a blockchain transaction within a blockchain block, a function of the block identifier (block_ID) and the transaction identifier (TxID), and a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0110] The resource may include information and records necessary to determine the validity of the UTXO. In addition, or alternatively, the resource may generate records that support the verification and / or validation of the UTXO, either by itself or through verification S1006 by validator 1106. Resource 1104 and / or validator 1106 may perform at least one of the following: verify and / or validate the UTXO; perform at least part of the simplified payment verification (SPV) process for the UTXO; verify whether a particular blockchain transaction (Tx) is included in a blockchain block; generate a hash of at least one blockchain transaction and use that hash to construct a Merkle path and / or verify whether the hash matches a transaction identifier (TxID) in the header of a blockchain block; and determine the Merkle proof of the UTXO.

[0111] By identifying resource 1104 allocated from a UTXO / transaction and providing a means to store the information necessary for validating the UTXO in that resource, an efficient and scalable alternative to UTXO validation is provided. Since nodes no longer need to maintain a complete copy of the blockchain, and additional information to support transactions such as SPV-based exchanges and wallets is also unnecessary, system 1100 and its resource 1104 provide rapid and scalable support.

[0112] Overall, system 1100 includes resource 1104 which operates to provide a UTXO repository for generating, storing, and / or maintaining information and / or records related to multiple unconsumed transaction outputs (UTXOs), each UTXO being associated with a transaction (Tx) within multiple blockchain transactions (TX) of a blockchain block. The resource can record, retrieve, and / or process information and / or records by identifying and / or assigning resources using a portion of the data derived from the blockchain, where the data from which a portion of the data is derived includes unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0113] System 1100 may include Node 104 and / or Switch 1102 for receiving and / or processing unconsumed transaction outputs (UTXOs) to include them in a transaction. The Node and / or Switch support resources and can determine the allocation to a specific resource from among several resources. The allocated resource holds UTXO information and / or verification data such as records.

[0114] For example, after receiving a UTXO to be included in a transaction as part of a payment or transfer of digital assets, the actor can request or retrieve verification information and records from the assigned resources.

[0115] When an actor accesses information and / or records from an assigned resource, the actor can perform at least one of the following: validate a UTXO and / or a transaction (Tx) containing the UTXO, and / or determine the validity of the UTXO and / or a transaction (Tx) containing the UTXO. Validation by resource 1104, validator 1106, and at least one actor may include: 1) validating and / or verifying at least one blockchain transaction, and / or 2) performing a simplified payment verification (SPV) process, and / or 3) checking whether a given blockchain transaction (Tx) is included in a blockchain block, and / or 4) generating a hash of at least one blockchain transaction, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier (TxID) in the header of a blockchain block.

[0116] Subsequently, following the validation of the UTXO, the actor or a further actor may prepare and / or send a transaction (Tx) with the UTXO as input.

[0117] Node 104 can be configured to generate, store, and maintain UTXO resources for recording, retrieving, and / or processing multiple unconsumed transaction outputs (UTXOs), the node processing a portion of the data derived from the blockchain to identify and / or allocate processing resources and / or storage resources. The data from which a portion of the data is derived includes unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0118] Block Verification Traditionally, nodes within a blockchain network manage a global ledger that records all transactions on the blockchain. The global ledger is a distributed ledger, and each node can store a complete or partial copy of it. Transactions affecting the global ledger by a node are verified by other nodes, thus maintaining the validity and integrity of the global ledger. Details of the implementation and operation of blockchain networks using the Bitcoin protocol, for example, should be easily understood by those skilled in the art.

[0119] 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 may be an address to which control of a value is transferred as a result of the transaction. That value is associated with its output address as an unconsumed transaction output (UTXO). Subsequent transactions can reference that address as input and acquire control or ownership of that value.

[0120] As mentioned earlier, using the Bitcoin network and protocol as an example, mining nodes compete to generate the next block on the blockchain. To assemble a block, miners construct it as a set of transactions from a pool of unconfirmed transactions ("memory pool"). They then attempt to complete a Proof-of-Work (PoW) puzzle with respect to the assembled block. If a miner can complete their PoW before receiving notification that another miner has generated their block and completed their PoW, they propagate the block by sending it to peer nodes on the network. These nodes verify the block and send it to other nodes on the network. If a miner receives notification that another block has been completed before completing their PoW, the miner stops working and begins building the next block.

[0121] Thus, rapid block propagation helps avoid wasted effort (and associated energy) for miners and verification nodes. By providing a solution that accelerates block verification and propagation, the present invention improves network performance. This reduces the required computation time and effort, as well as the amount of energy required for the network. This results in a more resource- and time-efficient network. And ultimately, an improved (blockchain) network is realized.

[0122] In current blockchain implementations such as the Bitcoin network, each node that receives a block first verifies it before sending it to other nodes. The time it takes to verify a block slows down the propagation of the block on the network. While some blockchain implementations, such as evolutions of existing protocols, may provide block verification by only some nodes rather than every node in the network, block verification by most nodes will likely remain an essential feature in all blockchain implementations to prevent invalid blocks from propagating on the network.

[0123] Block verification involves confirming that the block meets the criteria defined by the applicable blockchain protocol. Examples of criteria applicable to the Bitcoin protocol include functions such as CheckBlock and CheckBlockHeader. In addition to confirming that the block itself meets the specified criteria, it may also be necessary to evaluate whether each transaction within the block conforms to transaction-level criteria. For example, transaction-level criteria applicable to the Bitcoin protocol include functions such as AcceptToMemoryPool, CheckTransaction, and Checkinputs.

[0124] Specific examples of block-level criteria based on the Bitcoin protocol include the following: · The block data structure is syntactically valid. · The block header hash is less than the target difficulty (compulsory proof of work). · The block timestamp is within 2 hours (considering time error). · The block size is within the allowable range. · The first transaction (only the first transaction) is a coinbase generation transaction. · All transactions within the block are valid.

[0125] Specific examples of transaction-level criteria based on the Bitcoin protocol include the following. [[ID=十六]]· The syntax and data structure of the transaction must be correct. · Neither the input list nor the output list is empty. · For each output value x and the total of all outputs, 0 < x < 21·10 6の It must be within the range. · None of the inputs have a null hash. · nLockTime is less than or equal to INT_MAX. · The transaction size (in bytes) is greater than or equal to the minimum value and less than the maximum value. · The number of signature operations is less than the signature operation limit. · The unlocking script scriptSig can only push numbers onto the stack, and the locking script scriptPubkey must match the isStandard format. · For each input, if the referenced output exists in other transactions within the pool, that transaction must be rejected. · For each input, if the referenced output transaction is a coinbase output, at least COINBASE_MATURITY (100) confirmations are required. · For each input, the referenced output must exist and must not have been consumed already. • Use the referenced output transaction to retrieve the input values, and determine the range of values ​​x (i.e., 0 < x < 21 · 10) for which each input value and its sum are allowed. 6 Make sure it is inside the parentheses. • A matching transaction must exist within the pool or within a block on the main branch. • The sum of the input values ​​must be greater than or equal to the sum of the output values. • The transaction fee must be sufficient to enter an empty block. Each input unlock script must be validated against the corresponding output lock script.

[0126] These example criteria are illustrative and should not be interpreted as sufficient or necessary for all embodiments, as the defined criteria may differ depending on the protocol, and may also change over time even within a particular protocol if changes are made to the protocol. Generally, transaction-level validation criteria are defined characteristics that a transaction must possess in order to be considered valid within the applicable blockchain protocol. Similarly, block-level validation criteria are defined characteristics that a block must possess in order to be considered valid within the applicable blockchain protocol.

[0127] This application describes a method and device for accelerating block verification in order to speed up block propagation in a network.

[0128] In one embodiment, the present application describes a node configured to validate a block by performing at least transaction-level validation of individual transactions in parallel and / or in a distributed manner. However, certain transaction-level criteria may not be evaluateable in parallel. For example, the uniqueness of a UTXO may be evaluated serially. In such cases, the distributed validation node of the present disclosure may be configured or arranged to verify the uniqueness of the transaction's reference input (UTXO) before assigning the set of transactions to a set of two or more parallel processors for validation of the remaining transaction-level criteria.

[0129] In particular, embodiments of the present disclosure provide improved verification 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 known in the art, a tree structure can be broken down into smaller trees (which may be referred to herein as “segments,” “subsets,” or “parts” of the tree), each segment constituting a subset of the data records of the entire tree and having 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.

[0130] In the exemplary embodiment, multiple data records consist of associated blockchain transactions to form nodes in a Merkle tree. The Merkle tree has a root that is included, or may be included, in the block header of the transactions according to the blockchain protocol, and the root provides a path to all leaves (i.e., transaction IDs (TxIDs)) in the tree. The exemplary blockchain protocol is either the Bitcoin protocol or one derived from the Bitcoin protocol, but other protocols are also included in the scope of this disclosure.

[0131] For example, processing multiple transactions involves verifying at least a portion of a blockchain block containing multiple blockchain transactions and the root of the Merkle tree of that block. These examples are not limiting, and the technologies disclosed herein can also be used for data not related to blockchain and / or other processes other than verification. For example, embodiments can be used to store, structure, retrieve, and / or maintain any type of data record that can be represented in a Merkle tree. Instead of, or in addition to, a blockchain ledger, a database or other known storage resource can also be used.

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

[0133] For completeness, we will explain Merkle trees and their use in representing blocks of blockchain transactions, referring to Figures 3 and 4.

[0134] Merkle Tree Referring to Figure 3, a Merkle tree is a hierarchical data structure that enables secure validation of data sets. In a Merkle tree, each node in the tree is assigned an index pair (i,j), represented as N(i,j). Indices i and j are numerical labels associated with a specific location in the tree.

[0135] A key characteristic of Merkle trees is that the construction of each node is governed by the following formula:

number

[0136] An example of a binary Merkle tree constructed according to these formulas is shown in Figure 3. From the figure, when i=j, it corresponds to a leaf node, which simply corresponds to the i-th data packet D. i It can be seen that this is a hash. If i≠j, it corresponds to an internal node or a parent node, which is generated by recursively hashing and concatenating the child nodes until one parent (Merkle root) is found. For example, node N(0,3) is constructed from four data packets D0,...,D3 as follows:

number

[0137] For the Merkle tree of Bitcoin and other blockchains, the hash function is double SHA256. This means applying the standard hash function SHA-256 twice: W(x) = SHA256(SHA256(x)).

[0138] The main function of a Merkle tree is that a given data packet DL is a list or set D ∈ {D0,...,D} of N data packets. N-1 The verification is to verify that it is a member of}. This verification mechanism is called a Merkle proof, and given data packet D i This involves obtaining a hash set called a Merkle path for the Merkle root R. A Merkle proof of a data packet is the minimum hash list necessary to reconstruct the root R by repeatedly hashing and concatenating, and is often called an "authentication proof."

[0139] All packets D0,...,D N-1If the prover knows the order of the elements, the proof of existence can be easily performed. However, this requires a much larger storage overhead than the Merkle proof, and the entire dataset must be available to the prover. A comparison of using the Merkle proof versus using the entire list is shown in the table below. Here, we use a binary Merkle tree and assume that the number of data blocks N is exactly equal to a power of 2.

[0140] 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 (or Merkle proof). [Table 1] In this simplified scenario (where the number of data packets is equal to the number of leaf nodes), we can see that the number of hash values ​​required to compute the Merkle proof increases logarithmically. It is clearly far more efficient and practical to compute a Merkle proof containing log2N hashes than to store N data hashes and compute an explicit proof.

[0141] Given a Merkle root R, data block D o An ordered list D ∈ {D0, ..., D} represented by R. N-1 If you want to prove that something belongs to}, you can perform a Merkle proof as follows: i. Obtain the Merkle root R from a reliable source. ii. Obtain the Merkle proof Γ from the source. In this case, Γ is a set of hashes. Γ = {N(1,1), N(2,3), N(4,7)}. iii. Using D1 and Γ, compute the following Merkle proof. a. Hash the data block to get the following: N(0,0) = H(D0). b. Concatenate N(1,1) and hash it to obtain the following: N(0,1) = H(N(0,0)||N(1,1)). c. When concatenated with N(2,3) and hashed, the result is as follows: N(0,3) = H(N(0,1)||N(2,3)). d. Concatenate N(4,7) with the hash to obtain the root. N(0,7)=H(N(0,3)||(4,7)),R'=N(0,7). e. Compare the calculated square root R' with the square root R obtained in (i). 1. If R'=R, the existence of D0 in the tree and the existence of dataset D are confirmed. 2. If R'≠R, the proof fails, and it is not confirmed that D0 is a member of D.

[0142] This is an efficient mechanism for providing proof of existence for data as 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 exposed as part of the block header, it can be quickly proven that the transaction is included in that block.

[0143] SPV Simple Payment Verification (SPV) leverages these features of the Merkle tree, first described in Section 8 of Satoshi Nakamoto's 2008 white paper, "Bitcoin: A Peer-to-Peer Electronic Cash System." When Alice and Bob exchange SPV-based cryptocurrency, they both use the same type of SPV wallet. The SPV wallet stores the user's private and public keys, unspent transactions, and a block header that uniquely identifies the block and locates its position on the blockchain. As mentioned earlier, the block header consists of a data field that provides a unique summary or fingerprint of the entire block's contents, and a field that provides the Merkle root for that block. The Merkle root is generated by repeatedly hashing pairs of transaction IDs (TxIDs) within the block, ultimately producing a single hash value. The Merkle root provides an efficient and secure mechanism for verifying that a transaction is part of a block, as it allows users, such as wallets and merchant nodes, to verify a specific transaction locally without having to download the entire blockchain. This is advantageous for users who do not need to run a full node, nor do they wish to do so, and only need to locally verify whether a particular transaction is included in a particular block (for example, parties involved in transfers between merchants and customers). In other words, with SPV, such users can search a Merkle tree with a specific root to verify whether a particular transaction is included in a particular blockchain block, without having to download and store the entire blockchain.

[0144] Therefore, SPV wallets offer at least the advantage of being able to operate within the Bitcoin ecosystem on devices such as smartphones and laptops with limited power and storage capacity, because they only need to confirm that a transaction has been verified, rather than performing a full check of the blockchain like other forms of wallets (hence the name "simple payment verification"). SPV wallets download only the block header and no transaction data, significantly reducing the storage capacity, power, and processing resources required for verification. SPV wallets are particularly well-suited for use in the embodiments of this disclosure for the reasons described below. In this document, the term "verification" will be used to include SPV checks.

[0145] Transaction block Figure 4 schematically illustrates an example of a blockchain block. Each block contains a block header and a set of transactions. The block header contains, in particular, the hash of the previous block header, i.e., the hash of the block header of the block on which the current block was constructed. The block header also contains the Merkle root of the Merkle tree constructed using the set of transactions. Each transaction is first hashed (for example, double hashed) to generate a transaction identifier (TxID) for that transaction. These transaction identifiers are used as leaf nodes in the Merkle tree. Next, pairs of transaction identifiers are concatenated and hashed to form the respective internal nodes at the first internal level of the Merkle tree. Next, pairs of internal nodes at the first internal level are concatenated and hashed to form the respective internal nodes at the second internal level of the Merkle tree. The process of concatenating and hashing pairs of internal nodes is repeated until only one hash remains, which is the Merkle root. This Merkle root is sometimes called the block Merkle root.

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

[0147] Identifying segments of a block's Merkle tree Suppose a particular party (e.g., Alice) wants to verify several transactions. According to one embodiment of this disclosure, at least one subset of transactions is identified, and this subset forms a segment of the Merkle tree for the entire block, and / or is represented by the segment. Thus, a block of transactions can be logically divided into multiple segments based on the Merkle tree of the block, each segment containing a subset of transactions in the block, and each segment has its own root node (or “root hash”). This common root hash may hereafter be referred to as the “segment hash” to distinguish it from the root hash for the entire block. Transactions at the same level in a tree segment (i.e., the lowest level, or sometimes called the “leaf level” or “leaf layer”) are siblings. All transactions within a particular segment share a common root node for that segment. The common root node may belong to an adjacent level in the Merkle tree, i.e., the level immediately above the lowest level. Alternatively, the common root node may belong to a higher level. In general, the common root node can belong to any level between the lowest level of the Merkle tree and the Merkle root.

[0148] Dividing blocks into smaller parts based on a Merkle tree offers significant technical advantages, such as the ability to quickly and efficiently assign transactions to multiple validators. For example, the Bitcoin protocol uses a binary tree, making it possible to implement binary assignment across multiple machines. Using small binary markers as a segment indexing system allows for the rapid calculation of each segment's position within the overall Merkle tree, enabling the segment to be restored after validation is complete and the block's complete Merkle tree to be reconstructed. This binary indexing approach is explained in more detail below.

[0149] Various methods can be used to identify segments, but one approach is to determine the number of segments based on the number of validators available in the system. For example, in a system with four validators, the Merkle tree is divided into four segments, and if there are eight validators, the Merkle tree is divided into eight segments. Similarly, the identification of segments in a particular Merkle tree is performed or controlled by the control entity shown in controller 702 in Figure 7.

[0150] The points described above are further explained with reference to Figures 5 and 6, which show an example of how to divide a Merkle tree into separate parts 502 for assignment to validators. In the example in Figure 5, each arrow represents a transaction, which is hashed to form a transaction identifier used by each leaf node of the Merkle tree. The top level of the Merkle tree is the Merkle root of the block. In this example, the transaction block represented by the Merkle tree contains 32 transactions. However, this is merely an illustrative example, and it should be noted that a Merkle tree can generally 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-d, indicated by dashed boxes. Each part 502 is linked by a common internal node (internal hash) 504 of the Merkle tree, indicated by a solid circle. Each part 502 represents eight transactions. In this example, the common internal node 504 belongs to the fourth level of the Merkle tree. In the embodiments described herein, each portion 502 (or the transactions forming and / or representing the portion) is assigned to a corresponding validator, which performs processing, for example, validation of the transactions belonging to each portion 502.

[0151] Figure 6 shows another example of how to divide a Merkle tree into 602 parts. The Merkle tree in Figure 6 is the same as the Merkle tree in Figure 5. In this example, the Merkle tree is divided into eight parts 602a-h, each part 602 representing four transactions. In this example, a common internal node 604 belongs to the third level of the Merkle tree. The Merkle trees in Figures 5 and 6 can also be divided into more parts (e.g., 16) or fewer parts (e.g., 2) 502,602. In general, a Merkle tree formed from a block of transactions can be divided into any number of parts 502,602, each part containing at least two transactions.

[0152] Assignment of segments to each validation resource A subset of identified transactions is distributed among multiple validation resources (also referred to for convenience as "validators"). In Figures 7 and 9, these multiple validators are shown as resources A through D (704a through 704d). This allocation process may, but is not limited to, be directed or controlled by dedicated units such as component 904 shown in Figure 9.

[0153] Each validator (704a-704d) can contain one or more processing resources. Therefore, at least one of the multiple validators (704a-704d) can contain at least one, or at least one, such as 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 multiprocessor systems. Essentially, any multiple validators can consist of any type or any combination of processing resources that can validate one or more transactions associated with each other by segments of a block's Merkle tree. The multiple validators (704a-704d) and other system components form a collective resource or entity 700, which is called a “(distributed) validation node”.

[0154] Preferably, the distribution includes assigning each segment to the respective validator among multiple validators. The validators are arranged as follows: • Operate the one-territory transaction that constitutes the allocated segment. • Verify one or more transactions to ensure compliance with the blockchain protocol, and / or • Verify that the transaction can be identified in existing repositories, such as blockchain ledgers and databases of known, registered, and used transactions.

[0155] The behavior of validators and the assignment of subsets to each validator may be directed by the controller. Figure 7 shows how controller 702 assigns subsets of transactions A-D of each tree segment to validators 704a-704d, respectively. The system-level controller 702 may coordinate the behavior of systems or devices 704a-704d within the distributed validation node and control or control tasks such as identifying tree segments by the block's Merkle tree, assigning the identified segments to each validator, rearranging the validated tree segments into the block's complete Merkle tree, and / or ordering transactions within the reconstructed block.

[0156] One or more validators may include at least one coordinating entity configured to function as a controller at the validator level. Thus, any or all of validators 704a-704d may include at least one of their own controller components. This lower-level controller can influence or direct operations such as assigning tasks or subtasks to one or more processing resources within the validator, rebuilding the Merkle tree for a particular segment, or interacting with other system components (other validators, higher-level controllers, UTXO pools, wallets, etc.). Furthermore, the processing resources themselves may be broken down into even smaller systems, one or more of which may include a controller and one or more processing resources of their own. In this way, the system may include a hierarchical architecture, and segment validation is performed by validation entities that include one or more processing resources for executing validation tasks and one or more controllers for coordinating processor activity and performing inter-component communication.

[0157] In embodiments where the validator has multiple processing resources, the validator can divide its assigned segment into smaller segments. The validator's controller can distribute these subsegments to processors under its control. In this way, the verification process can be implemented in a hierarchical and distributed manner.

[0158] This hierarchical decomposition can be extended down to the transaction level, allowing verification to be further broken down into subprocesses or tasks per transaction, rather than at the tree segment level. In this approach, the verification of individual transactions is divided into subtasks and distributed across multiple machines, or multiple threads running on the same or multiple machines. These processes are queued, and when a thread becomes available, it is assigned to another transaction or task.

[0159] Therefore, this disclosure makes it possible to process a large number of transactions simultaneously, as the only limiting factor is the amount of hardware available to configure the distributed verification nodes, rather than the available processing speed being the bottleneck as in conventional technologies. This makes it possible to horizontally expand the blockchain processing system without changing the underlying protocol of the blockchain network.

[0160] Therefore, this disclosure differs significantly from conventional validation approaches, which will be described in more detail with reference to Figures 1 and 2 in the following section entitled “Exemplary Technical Environment for Implementing Exemplary Embodiments of the Disclosure.” As described, conventional approaches validate a single block as a whole and employ the traditional approach of treating the validation node (see 104 in Figure 1) as a single computing unit. In contrast, embodiments of the disclosure divide the Merkle tree into multiple segments, each passed to a different validator (704a-704d in Figures 7 and 9), and each segment and validator can be further subdivided to increase the degree of distribution.

[0161] Furthermore, by dividing each block into segments based on its Merkle tree, embodiments of the present invention enable validators to access, download, and process smaller portions of a block rather than the entire block. It should be noted that transactions within each segment are hashed up to a single root value (in pairs). This means that segments can be validated using only the relevant transactions needed, rather than downloading, storing, and processing the entire block in bulk. As protocols such as Bitcoin SV enable scaling of block size and inclusion of larger blocks into the ledger, the traditional model of downloading the entire block becomes a bottleneck. Embodiments of the present invention overcome this challenge to blockchain scalability by enabling individual validators to receive and process only the (smaller) portions relevant to them. This reduces overall validation time and improves blockchain networks and applications running on the blockchain.

[0162] Furthermore, the embodiments support and facilitate the use of SPV processes and resources because SPV performs local validation only on the portion of the Merkle tree that is of interest to the specific party. Therefore, the tree-pruning properties of SPV technology are ideal for use in combination with the embodiments of this disclosure. In an SPV context, the validator is provided with only the necessary portion of the block data, namely the block header or segment root node and associated transactions.

[0163] Once each validator performs a check and verifies the validity of the processed segment, the hash mechanism used for tree generation guarantees the validity of the block.

[0164] Load balancing among multiple validators Load balancing techniques and systems are known in the art for their purpose of evenly distributing tasks across multiple resources to improve efficiency. The goal is to minimize the risk of performance degradation and failure caused by some processing resources becoming idle while others become overloaded. Therefore, load balancing is crucial for ensuring the overall resilience, performance, and efficiency of the system. Embodiments of this disclosure may utilize known load balancing techniques, such as static or dynamic load balancing. In addition, or alternatively, the load balancing approaches disclosed herein may be advantageously utilized.

[0165] As described above, an index system can be used when assigning block segments to each validator in embodiments of the present disclosure. Preferably, this is a binary index system. In this preferred system, each validator is assigned a binary label or identifier. Suppose each identifier is four digits long, and the first validator is identified as 0000, the next as 0001, the next as 0010, and so on. Obviously, with four-digit identifiers, 256 validator IDs are possible, and the last validator is identified as 1111 (i.e., the decimal of validator number 255).

[0166] When a tree segment needs to be assigned to a validator, the first four digits of its double hash (i.e., the segment hash of the tree segment) can be used to determine which validator will process that segment. Recall that the Merkle root is generated by hashing pairs of block transaction IDs (TxIDs) to produce each internal node (or internal hash) of the Merkle tree, and then repeatedly hashing adjacent internal hashes to eventually arrive at a single hash. This double-hash Merkle root provides an efficient, fast, and secure verification mechanism. Also, in this context, the double hash has the added benefit of generating a random binary number. Each internal hash containing each segment hash is itself a double hash. Therefore, the x-th digit of the segment hash can be used as an assignment index. A hash with four leading zeros assigns the tree segment to the validator with ID 0000, a hash with 0001 assigns it to the validator with ID 0001, and so on. The random generation of the double hash randomly distributes the tree segments to validators.

[0167] When generating a Merkle tree, a double hash is typically used, but this is not mandatory in all examples; a single hash can be used instead. In fact, any number of hash operations can generate random binary values. Load balancing tasks may be performed by a dedicated system component, as shown in 905 of Figure 9, provided elsewhere within system 700, or communicate in conjunction with system 700.

[0168] Distributed download of blocks According to some embodiments, assigning segments of a block's Merkle tree to different validators may provide a faster and more efficient process for downloading some or all of a block of transactions.

[0169] Each validator is assigned a segment of the Merkle tree, for example, based on the aforementioned allocation index. Any validator then downloads the transaction set that makes up its assigned tree segment. This may involve downloading the transaction set from the blockchain itself (e.g., a blockchain node) or from another resource or entity, such as a third-party service provider. The transaction set is downloaded to the validator's internal memory or to shared storage, such as a shared drive in the cloud.

[0170] A distributed node may need an entire block, that is, the entire set of transactions that make up the block. In that case, each validator assigned a tree segment downloads a subset of the transactions that make up that segment. In other scenarios, a distributed node may only need a specific part of a block. In that case, only some validators need to download a subset of the transactions to obtain the required transactions.

[0171] Downloading blocks (or parts of blocks) in this way speeds up the overall download because each validator processes only a subset of the entire set of transactions that make up the block. This is in contrast to traditional block downloads, where a specific entity (such as a full node) needs to download the entire block (downloading each transaction in the order they appear in the block). Currently, blocks are downloaded in parallel by multiple validators. A block can contain tens of thousands, or even more, of transactions. If a single entity were to download this many transactions, it would consume enormous resources and take a considerable amount of time. Because the computational load is distributed among validators, the processing resources consumed by each validator are very small. Similarly, the overall time it takes to download a block is also reduced.

[0172] As mentioned earlier, each validator can download a subset of transactions. These subsets can then be combined to reconstruct a block in a single storage location (where "single storage location" means either a self-contained storage resource or multiple related storage resources forming a collective entity). To this end, each validator can send its respective subset to a central controller of distributed nodes configured to order the transactions correctly. Segment hashes (i.e., hashes linking tree segments) can be used for this purpose. For example, a mapping can be maintained between segment hashes and their positions in the Merkle tree, for instance, mapping from left to right in the order in which the segment hashes appear in the Merkle tree. The subsets of transactions are then ordered based on their corresponding segment hashes (for example, from beginning to end).

[0173] In some embodiments, individual validators (or the entire distributed node) can verify that the correct transactions were downloaded (or that the transactions were downloaded correctly) by reconstructing the Merkle tree. After downloading a subset of transactions, validators can generate candidate segment hashes based on those transactions. Candidate segment hashes are constructed by hashing pairs of TxIDs to generate their respective internal hashes, and repeatedly hashing pairs of internal hashes until a candidate segment hash is generated. The level of the Merkle tree to which the candidate segment hash belongs depends on the number of tree segments into which the Merkle tree is divided. Validators can verify that the candidate segment hash is a hash of the Merkle tree. If the hashes do not match, it means that an error occurred during the download. In some examples, each validator can generate a candidate segment hash and send it to a controller for verification. In another example, a candidate block Merkle root can be generated based on the entire set of downloaded transactions. Again, if the block was downloaded correctly, the candidate Merkle root should match the actual block Merkle root (i.e., the Merkle root stored in the block).

[0174] In some cases, validators may validate downloaded transactions using the methods described above. That is, each validator is assigned a tree segment, downloads a subset of the corresponding transactions, and validates those transactions. Alternatively, validators may not necessarily validate transactions, but simply download them for later use (for example, to send to a third party).

[0175] Distributed UTXO pool Preferably, each validator 704 constituting a distributed validation node has its own repository (pool) for generating, storing, and / or maintaining unconsumed transaction outputs (UTXOS). This functions as a UTXO pool that provides a record of unconsumed, i.e., unconsumed outputs related to blockchain transactions. Thus, each validator's UTXO pool is built on transactions assigned by the controller with respect to Merkle tree segments. In one embodiment, this may be a (graph) database containing data about unconsumed UTXOs of transactions assigned to a particular validator for processing. When a validator is assigned a new Merkle tree segment, a record is created in the database for each UTXO that the validator is aware of. Thus, from the perspective of the distributed validation node, the UTXO pool is not a single pool, but consists of multiple different UTXO pools, each served by a different validator and consisting of a different set of UTXOs. Thus, the node's UTXO pool is distributed in terms of both the data and the resources that store and / or process it.

[0176] This differs significantly from the traditional UTXO model, where each full node in the network holds a copy of the UTXO pool that tracks all UTXOs on the blockchain. In contrast, this disclosure distributes the UTXO pool across multiple validation resources, with each validation resource holding a UTXO pool that is a subset of the blockchain-wide UTXO set. Each validator's UTXO pool consists of UTXOs of transactions that make up a subset of the Merkle tree entrusted with validation.

[0177] This approach allows for the implementation of a SQL transaction log whenever a new block needs to be validated, logging all commands, events, and items related to the database. To avoid confusion caused by the use of the term "transaction" as it is known in blockchain contexts, we will use the term "database log" here, including terms such as "transaction journal" and "transaction log." 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 regarding the state of the database, as is known in the field of computer-based databases (see https: / / en.wikipedia.org / wiki / Transaction_log).

[0178] By using an ordered historical database log, the entire UTXO pool can be built by executing the log history in its original order. This allows for (re)regeneration of database copies at any time as needed, eliminating the need to store individual copies of the data. Data integrity is ensured, and the required storage resources are reduced. Each UTXO pool can be stored, maintained, and processed independently. Furthermore, because SPV technology operates on pruned portions of the Merkle tree, it is easy to create separate UTXO databases for each validator.

[0179] Transactions (TX) in a database can be structured in various ways, but a particularly advantageous approach is to structure them based on an identifier that concatenates the block ID and the transaction ID (block_ID||TxID). Both the block ID and the transaction ID are 256-bit hashes, resulting in a 512-bit concatenated field structure that is secure and collision-free.

[0180] Structuring transactions in this way enables a fast and efficient search mechanism. Since transactions can be sorted by block_ID, all transactions with the same block_ID are grouped together in the database. Therefore, when a validator needs a transaction (for example, to check if a transaction's UTXO is being used), the validator can find the transaction in the database by first searching for the corresponding block_ID and then the corresponding TxID. This limits the search to the relevant section of the database. This efficiency reduces the time, processing resources, and energy required for search operations, resulting in a significant improvement over conventional techniques.

[0181] Each UTXO in the validator pool has an associated flag or marker that indicates whether the UTXO is locked or unlocked. For convenience, this flag or marker is sometimes referred to as the "lock flag." When a UTXO is marked "locked," it indicates to validators in the group (i.e., other locations within the distributed validation nodes) that this UTXO is unavailable. Conversely, when a UTXO is marked "unlocked," it indicates to validators that this UTXO is available. Thus, it serves as a way for validators assigned to validate a transaction using a UTXO to notify their peers that the UTXO has been redeemed and is therefore no longer available once the transaction is proven valid. The "locked" state means that use is permitted, and the "unlocked" state means that use is prohibited.

[0182] This lock / unlock flag can be represented by a simple, small binary marker, such as 0 for "locked" and 1 for "unlocked." This marker mechanism is used internally by validators in the distributed node system, and the marker is removed from the transaction before it interacts with the blockchain, so that the transaction conforms to the protocol rules.

[0183] During use, the validator inspects the output of each new transaction assigned by the controller. Unconsumed outputs (UTXOs) are added to the validator's UTXO pool and recorded as entries in the UTXO database. In the associated database record for each new UTXO, the lock flag is set to "unlocked".

[0184] When a validator confirms that a UTXO has been consumed by a newly allocated transaction, it sends a message to all other validators informing them that this UTXO also needs to be locked in their respective pools. Essentially, a validator sends a communication to its peers indicating that a transaction with a specific hash ID consumed the UTXO at a specific time. Other validators do not need to receive the complete transaction data; they can identify the transaction and mark it as locked in their own database with just the transaction hash and a list of the UTXOs used. Upon receiving the message, each receiving validator checks whether the UTXO in question is in its UTXO pool. If it is, the lock flag status is changed to "locked". In this way, the lock prevents the validator from allowing subsequent transactions to consume the same UTXO. If a new transaction attempts to consume the same UTXO, the lock flag check ensures that the second attempt is ignored. If the validator that sent the message determines that the verification failed and therefore the UTXO was not consumed, it can send a message to its validator peers instructing them to change the UTXO's lock flag to the "unlocked" state. Once effective consumption is complete, a message to that effect can be sent, and the locked UTXO can be removed from the associated UTXO pool.

[0185] In the embodiments described above, each validator has a single UTXO pool containing the UTXOs of all transactions within all assigned tree segments. However, in another approach, the UTXO pool managed by each validator can be divided / partitioned / formed into multiple subpools, one per block. In this way, a single UTXO pool can be organized into a logical hierarchy. In yet another approach, one or more validators are each associated with multiple UTXO pools, and each UTXO pool is associated with UTXOs corresponding to one or more sets of tree segments. Thus, in some embodiments, validators can organize UTXOs into separate UTXO pools for each different individual tree segment, or according to predefined criteria such as the type of tree segment or tree segments included within a given range. In such embodiments, identifiers may include a block ID that can be used to narrow the search to the relevant UTXO pool, and then the search can proceed within that pool to identify (attempt to identify) the relevant transaction by its TxID. Those skilled in the art will understand that in some embodiments these approaches can be used in combination. In other words, one or more validators within a distributed node adopt a single UTXO pool approach, while other validators are configured to use multiple separate UTXO pools and / or UTXO pools organized into subpools, or any combination thereof.

[0186] This protects against "double spending," that is, situations where the same UTXO is used 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, maintaining the security and integrity of transactions implemented on the blockchain.

[0187] Exemplary System of Possible Embodiments Figures 7 and 9 show an exemplary system 700 for carrying out at least a portion of the embodiments described. Figure 8 shows a flowchart of exemplary steps (high-level view) that may be performed in the method of the present disclosure.

[0188] System 700 may be a closed system in the sense that it is associated with an organization and forms part of a larger, proprietary system. In such a case, data from System 700 (e.g., transactions) may be received from other components within the organization's broader system, and the results and outputs may be sent to internal destinations. In addition, or alternatively, System 700 may be configured to interface with various entities that may be located some or all outside the organization. In such a case, System 700 may be configured to provide verification functionality as a service. For example, System 700 may be configured to interact with a blockchain network to retrieve the necessary data. In addition, or alternatively, System 700 may interact with entities that wish to use its verification services. Thus, the activities of System 700 may be entirely internal 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 both. Communication between other internal or external entities may be coordinated by one or more interfaces or communication components, as shown in 902 of Figure 9.

[0189] As shown in Figures 7 and 9, system 700 includes a control entity 702 (or simply "controller") and multiple validation resources 704 (also referred to herein simply as "validators"). Although only four validators 701a-d are shown in Figure 7, system 700 can generally contain any number of validators. Furthermore, although controller 702 is shown separately from validators 704 in Figures 7 and 9, this does not preclude the possibility that controller 702 contains or is contained within any of validators 704. As mentioned above, each validator can contain one or more processing resources and can also contain its own controller to coordinate its internal activities. There are no technical or logical limitations on the level of hierarchy that can be implemented in this way. However, for the sake of brevity and ease of understanding, Figure 7 shows only one level of such hierarchy (the top level).

[0190] As shown in Figure 7, the controller 702 acquires a set of transactions. These transactions can be received from source resources via electronic channels or networks. As mentioned earlier, a source is any entity that wants to perform some kind of verification check, either inside or outside the system. For example, this could be a full node on a blockchain network, like node 104 in Figure 1, a digital wallet, or a merchant / SPV node that wants to perform local checks on a blockchain implementation transfer made between parties. Interface 902 facilitates data transfer between system 700 and sources outside the system.

[0191] A transaction may or may form a block of transactions. A transaction may be retrieved from a single resource (e.g., a block on the blockchain) or from multiple resources (e.g., one or more users, one or more blockchain nodes, etc.). A transaction may be retrieved before it is published on the blockchain, i.e., before it is recorded in a block. Alternatively, a transaction may be retrieved after it has been recorded on the blockchain.

[0192] The controller 702 assigns each validator 704 a subset of the transactions, as described herein. Each subset of transactions forms at least a portion of each part of the Merkle tree generated from the complete set of transactions, and is linked by each common internal node of the Merkle tree. In the example in Figure 7, subset A of transactions is assigned to validator A, subset B of transactions to validator B, subset C of transactions to validator C, and subset D of transactions to validator D. The validator 704 to which a subset of transactions is assigned processes each subset. In some embodiments, this involves each validator 704 validating each subset of transactions. To this end, the controller 702 can send the relevant transactions to each validator 704. The validator 704 can return a communication to the controller 704 indicating whether each subset of transactions is valid or whether at least one transaction is invalid.

[0193] At least one, preferably some or all, of the validators 704a to 704d can access their own UTXO pools shown in 901a to 901d of Figure 9. These pools may have storage capabilities such as the aforementioned database and may have advantageous index structures including the concatenation of block IDs and transaction IDs. Although Figure 9 shows the pools contained within each validator, it will be readily apparent to those skilled in the art that they may also be located outside the validators and communicate with them.

[0194] In one or more embodiments, the disclosed process may include a block-level validation stage in which a new incoming block is tested against block-level criteria. Examples of block-level criteria have been described above, but generally relate to prescribed formatting requirements and characteristics or limitations that apply to the block itself, rather than to the transactions within the block. Examples include block size, the structure or content of the block header, and similar criteria. Such operations may be performed by a controller, a component of the controller, or other system components.

[0195] In some embodiments, the method may further include a UTXO uniqueness check module that operates to evaluate 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 to a new block, it indicates a potential double-spending problem and violates the UTXO uniqueness criterion. If the UTXO uniqueness check module identifies a UTXO that is referenced multiple times in the transaction inputs in a new block, it may output an error signal or other interrupt indicating that it will reject the block.

[0196] Assuming that new blocks are not rejected, i.e., all UTXO inputs are unique, Merkle tree segments can be identified and their associated transactions assigned to a group of validators. The identification process can be performed by a component such as the segment identification unit 903 shown in Figure 9. The assignment process can be performed by the segment assignment unit 904 shown in Figure 9. The assignment unit 904 can employ one of several possible assignment schemes for distributing block segments to individual validators, but in a favorable approach, the assignment scheme can be load-balancing as described above. The assignment unit 904 may include (or communicate with) a load balancing unit 905. In Figure 9, this is shown as a separate related component of the system, but in other embodiments, the load balancing unit may be part of the assignment unit 904 and separate from the controller 702. Any combination of components can be readily adopted.

[0197] Each validator validates the transactions associated with the received segment against transaction-level validation criteria. Each validator operates independently and validates the validity of its assigned transactions; therefore, no synchronization paradigm is required between validators. Each validator outputs results confirming the validity of its assigned transactions. These results are added or accumulated to ensure that all transactions within the segment are valid. If one validator identifies a non-compliant, or invalid, transaction, it may issue an output such as an interrupt or other signal indicating the presence of an invalid transaction. This interrupt or signal is sent to other validators, controllers, or other system components, allowing each validator to immediately stop testing its respective transaction and avoid wasting further resources validating transactions within the rejected block.

[0198] In some cases, the system may be configured to check block-level criteria. This may be performed before assigning segments to validators, but the block-level validation phase may also be performed after the transaction-level validation tests by the validators, or in some cases, concurrently with the transaction-level validation tests.

[0199] Figure 8 shows an example of how to validate a block in flowchart format. A block contains multiple transactions, each transaction referencing one or more inputs, and each input is a UXTO (except for the coinbase generation transaction). This method is implemented within a node on the blockchain network using appropriate hardware and processor execution instructions.

[0200] During operation, distributed verification node 700 receives new block data in step S801. This may be the entire block, or, in the case of SPV-related verification, it may consist only of the partial data necessary to perform the SPV check. For convenience, this data is referred to as the “block”. The new block to be verified may be received from a mining node on the blockchain network that generated the new block and completed proof-of-work, from a merchant node that wishes to perform the (SPV) check, or from a wallet such as an SPV wallet. The new block may also be received from another node (not a mining node) in the network. In some examples, distributed verification node 700 verifies the block before forwarding it to other nodes in the network. As mentioned above, verifying a new block may involve confirming that the block meets certain protocol-based criteria and / or other criteria that may be defined and required within a particular implementation.

[0201] In step S802, system 700 identifies the chunk of the block's Merkle tree. In S803, the segment is distributed to multiple validators, and in S804, the validators process a subset of the transaction in substantially parallel and independently of each other. In S805, the validators notify the controller of the success or failure of the validation.

[0202] It should be noted that the term “processor” as used herein in relation to the description of parallel processors does not necessarily mean physically independent microprocessors, but rather includes any hardware or software implementation that enables parallel processing resources capable of independently executing processor functions in parallel. A parallel processor may include a single processor with multiple cores. In some cases, a parallel processor may include multiple independent processing units. Parallel processors may or may not share physical memory. Each parallel processor, regardless of its implementation, has software or hardware mechanisms for signaling, such as outputting a signal when it identifies an invalid transaction. Implementations of parallel processors also include providing necessary software and / or hardware data transfer mechanisms for routing allocated transaction data to each processor for local processing.

[0203] Listed clauses Embodiments of this disclosure are provided, without limitation, for illustrative purposes only, in the following clauses. Features described in relation to any set of clauses or aspects of the disclosure listed below are not intended to be limiting in that respect, and features described in relation to any set of clauses may be incorporated into any other set of clauses.

[0204] Clause Set 1: Clause 1.1: A computer implementation method for processing (e.g., verifying) at least a portion of a blockchain block, including multiple blockchain transactions and the root of the block's Merkle tree, This delicious, Assigning each subset of blockchain transactions to multiple processes (e.g., verification resources) (where each subset provides a part of the Merkle tree, represented by each internal node of the Merkle tree), and, This involves using multiple processing (e.g., verification) resources to process (e.g., verify) each subset of blockchain transactions.

[0205] The term “validator” may be used interchangeably with “validation resource.” Multiple validation resources may form a distributed validation node. At least one of the multiple validation resources may include one or more processing resources. In addition, or alternatively, one or more of the multiple validation resources may include validator controller components substantially described herein.

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

[0207] In other words, each subset consists of at least two transactions associated with a common node in the Merkle tree, and the subset provides a (sub)part of the Merkle tree and / or is represented by a part of the Merkle tree. A common (internal) node may be a segment node or root as substantially described herein. A part of the Merkle tree may be a “segment” as substantially described herein.

[0208] Clause 1.2. The method described in Clause 1.1, which validates a subset of blockchain blocks and / or blockchain transactions, i) Verify and / or validate at least one blockchain transaction, and / or ii) Performing the Simple Payment Verification (SPV) process, and / or iii) Check whether a particular blockchain transaction (Tx) is included in a blockchain block, and / or iii) including generating a hash of at least one blockchain transaction, using that hash to construct a Merkle path, and / or verifying whether the hash matches a transaction identifier (TxID) in the header of a blockchain block.

[0209] Clause 1.3. A method described in Clause 1.1 or 1.2, wherein at least one subset of blockchain transactions includes an identifier associated with and identifying and / or representing such subset.

[0210] Clause 1.4. The method described in Clause 1.3, wherein the identifier facilitates the calculation of the location of at least one subset within the Merkle tree.

[0211] Clause 1.5. The method described in Clause 1.3 or 1.4, wherein the identifier includes a portion of the hash of blockchain transactions within a subset of at least one blockchain transaction.

[0212] Clause 1.6. The method described in any one of the above clauses, which involves assigning each subset of blockchain transactions to multiple verification resources, includes matching each subset to each verification resource based on each identifier associated with the subset of transactions.

[0213] Clause 1.7. The method described in any one of the above clauses: i) A step of downloading at least one subset of blockchain transactions to at least one of multiple verification resources; and / or ii) further includes the step of sending a subset of at least one blockchain transaction to at least one of several verification resources.

[0214] Clause 1.8. The method described in any one of the above clauses, wherein a Merkle tree includes a binary tree or mesh of hashes of multiple blockchain transactions.

[0215] Clause 1.9. A method described in any one of the above clauses, further comprising the step of identifying and / or determining a subset of blockchain transactions within a plurality of blockchain transactions.

[0216] Clause 1.10. The method described in any one of the above clauses, wherein at least one of the multiple verification resources is or includes one or more of the following: virtual machines, servers, GPU-based computing resources, processing threads, and / or multiprocessor systems.

[0217] Clause 1.11. The method described in any one of the above clauses, i) At least two transactions are siblings in the Merkle tree, and / or ii) A common node is the parent or ancestor of at least two transactions.

[0218] Clause 1.12. A blockchain verification system that operates to verify multiple blockchain transactions and at least a portion of a blockchain block, including the root of the Merkle tree of the block in question. The system has multiple verification resources, and each verification resource is: Processor and The system includes memory containing executable instructions that, as a result of execution by the processor, cause the system to perform any of the computer implementations described in the preceding clauses.

[0219] Clause 1.13. A non-temporary computer-readable storage medium storing executable instructions that, when executed by the processor of a computer system, cause the computer system to perform any of the computer implementation methods described in any one of Clauses 1.1 to 1.11.

[0220] According to another aspect of this disclosure, a computer implementation system is provided which is configured to perform any method step or combination of method steps described or claimed herein.

[0221] Furthermore, a blockchain system (network) including multiple computer implementation nodes is provided, each node in the blockchain network comprising a processor and memory containing executable instructions that, as a result of execution by the processor, cause the system to execute any variation of the computer implementation method claimed or described herein. The network can be configured to operate using the blockchain protocol described herein.

[0222] In addition, or alternatively, this disclosure may include a computer implementation method for downloading at least a portion of a blockchain block. A block may include multiple blockchain transactions and the root of the Merkle tree for that block. This method may include steps set out in one or more of the following clauses.

[0223] Clause Set 2: Clause 2.1. A computer implementation method for downloading at least a portion of a blockchain block, including multiple blockchain transactions and the root of the block's Merkle tree. This involves allocating each subset of blockchain transactions to multiple processing resources, where each subset provides a respective part of the Merkle tree and is represented by each internal node of the Merkle tree. Download each subset of blockchain transactions using one, some, or all of multiple processing resources.

[0224] Each subset can be represented by each internal node, meaning that each internal node can encode each subset. In other words, each internal node can be generated based on (i.e., as a function of) each subset. Each transaction within each subset can be linked to each internal node by one or more hash operations.

[0225] Clause 2.2. The method described in Clause 2.1, which involves one, some, or all of multiple processing resources sending a subset of their respective blockchain transactions to a central storage location.

[0226] Clause 2.3. The method described in Clause 2.2, Each internal node in a Merkle tree has its own position within the Merkle tree, and the method is: This involves locating each subset of blockchain transactions based on the respective positions of each internal node in the Merkle tree.

[0227] Clause 2.4. The method described in any one of the above clauses, One, some, or all of the processing resources include generating each candidate internal node of the Merkle tree based on each subset of downloaded blockchain transactions, and further, Verify that each candidate internal node matches each internal node in the Merkle tree, and / or By performing a Merkle proof based on the root of the Merkle tree, we can verify that each candidate internal node is a node in the Merkle tree, and / or, Sending each candidate internal node of the Merkle tree to one or more other processing resources. It includes at least one of the following.

[0228] Clause 2.5. The method described in any of the preceding clauses, which includes verifying a subset of each blockchain transaction using one, some, or all of a plurality of processing resources.

[0229] Clause 2.6. The method described in Clause 2.1, Verifying each subset of blockchain transactions is i) Verify and / or validate at least one blockchain transaction, and / or ii) Perform a simplified payment verification process, and / or iii) Check whether a particular blockchain transaction is included in a blockchain block, and / or iii) including generating a hash of at least one blockchain transaction, using that hash to construct a Merkle path, and / or verifying whether the hash matches a transaction identifier in the header of a blockchain block.

[0230] Clause 2.7. A method described in any one of the above clauses, wherein at least one of each subset of blockchain transactions includes each identifier associated with, identifying, and / or representing each subset.

[0231] Clause 2.8. The method described in Clause 2.7, wherein each identifier facilitates the calculation of the respective position of each subset in at least one of them within the Merkle tree.

[0232] Clause 2.9. The method described in Clause 2.7 or 2.8, where each identifier is based on the respective internal node of the Merkle tree.

[0233] Clause 2.10. The method described in Clause 2.9, where each identifier includes a portion of each internal node of the Merkle tree.

[0234] Clause 2.11. The method described in any one of the above clauses, which involves assigning each subset of blockchain transactions to each of several processing resources, includes matching each subset to each processing resource based on each identifier associated with each subset of transactions.

[0235] Clause 2.12. The method described in any one of the above clauses, the Merkle tree, includes a binary tree or mesh structure of hashes of multiple blockchain transactions.

[0236] Clause 2.13. The method described in any one of the above clauses, which includes identifying and / or determining a subset of blockchain transactions within a set of blockchain transactions.

[0237] Clause 2.14. The method described in any one of the above clauses, wherein at least one of the processing resources is a virtual machine, server, GPU-based computing resource, or multiprocessor system, or includes them.

[0238] Clause 2.15. A blockchain processing system that operates to download at least a portion of a blockchain block containing multiple blockchain transactions and the root of the Merkle tree of said block, the system comprising multiple processing resources, each processing resource having, Processor and As a result of execution by a processor, the system comprises a memory including executable instructions that cause or enable the system to execute any of the computer-implemented methods of the foregoing clauses.

[0239] Clause 2.16. A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, enable the computer system to execute a computer-implemented method described in any one of Clauses 2.1 to 2.14.

[0240] According to another aspect, there is provided a non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause the computer system to execute any version of the computer-implemented methods described or claimed herein.

[0241] Clause set 3: A computer-implemented method including the steps of generating, storing, and / or maintaining a first UTXO repository for recording, searching, and / or processing a plurality of unspent transaction outputs (UTXOs) respectively associated with transactions (Tx) within a plurality of blockchain transactions (TX) of a blockchain block, where the plurality of blockchain transactions provide a part of a Merkle tree of the blockchain block and / or are represented by a part of the Merkle tree.

[0242] The method according to Clause 3.1, further including generating, storing, and / or maintaining at least one additional UTXO repository.

[0243] The method according to Clause 3.1 or 3.2, further including creating and / or maintaining a database log including a history of actions, changes, and events related to the UTXO repository.

[0244] Clause 3.4. The method described in any one of the above clauses, wherein the first UTXO repository and / or at least one additional UTXO repository i) Unconsumed transaction output (UTXO), and / or ii) a) Unconsumed transaction output and / or b) at least one record associated with an identifier associated with a transaction (Tx) within multiple blockchain transactions.

[0245] Clause 3.5. The method described in Clause 3.4, wherein at least one record is i) The block identifier (block_ID) associated with the blockchain block, and / or ii) Includes a record identifier that includes a transaction identifier (TxID) associated with a transaction (Tx) within multiple blockchain transactions.

[0246] Clause 3.6. The method described in Clause 3.5, i) The record identifier includes a function of the block identifier (block_ID) and the transaction identifier (TxID); and / or ii) including the concatenation of a block identifier (block_ID) and a transaction identifier (TxID); and / or iii) Transactions in multiple blockchain transactions are associated with an Unspent Transaction Output (UTXO).

[0247] Clause 3.7. The method described in Clause 3.5 or 3.6, further comprising the step of searching, identifying, accessing, or inserting at least one record in the UTXO repository using a record identifier.

[0248] Clause 3.8. The method described in any one of the above clauses, wherein at least one of multiple unconsumed transaction outputs (UTXOs) is in the UTXO repository. i) The unspent transaction output (UTXO) is associated with a lock flag indicating whether it is available or unavailable, and / or ii) A method that can be set between a first state indicating that the use of unconsumed transaction output is permitted and a second state indicating that the use of unconsumed transaction output is prohibited.

[0249] Clause 3.9. A method as described in Clause 3.8, comprising the following steps: i) The step of associating the unconsumed transaction output (UTXO) with the lock flag; and / or ii) A step of changing the state of the lock flag from the first state to the second state, or from the second state to the first state.

[0250] Clause 3.10. The method described in Clause 3.8 or 3.9, comprising the steps of: sending a communication from a first processing resource to at least one further processing resource to cause at least one further processing resource to change the state of the lock flag associated with the unconsumed transaction output from a first state to a second state, or from a second state to a first state.

[0251] Clause 3.11. The method described in Clause 3.10, and the communications, i) Transaction (TX), transaction identifier (TxID), and / or hash of transaction (Tx), ii) A list of one or more unconsumed transaction outputs (UTXOs).

[0252] Clause 3.12. The method described in Clause 3.10 or 3.11, The steps include receiving the communication on at least one additional processing resource, The procedure includes the step of changing the state of the lock flag from a first state to a second state, or from a second state to a first state.

[0253] Clause 3.13. A method as described in any one of the above clauses, i) The Merkle tree part is a sub-part or segment of the Merkle tree of the blockchain block, and / or ii) Multiple blockchain transactions are represented by the internal nodes of the Merkle tree.

[0254] Clause 3.14. A blockchain implementation system comprising a plurality of processing resources, each processing resource comprises a processor, and a memory containing executable instructions that enable the system to execute a computer-implemented method as described in any one of the above clauses as a result of execution by the processor.

[0255] 15. A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, enable the computer system to execute a computer-implemented method as described in any one of Clauses 3.1 to 3.13.

[0256] Clause Set 4: Any embodiment defined by any clause or combination of clauses in Clause Set 4 can be configured to implement or combine with any clause in Clause Sets 1 to 3.

[0257] Clause 4.1. A system that operates to verify at least a part of a blockchain block including multiple blockchain transactions and the root of the Merkle tree of the block, the system comprising a plurality of verification resources, each verification resource The system comprises at least one processor associated with a portion of memory containing executable instructions that, as a result of execution by at least one processor, cause a verification resource to verify at least one subset of multiple blockchain transactions, or enable verification, where the at least one subset provides a portion of a Merkle tree, represented by internal nodes of the Merkle tree.

[0258] Clause 4.2. The system described in Clause 4.1, further comprising: i) Load balancing components arranged to facilitate the balancing of the distribution of multiple subsets of multiple blockchain transactions across multiple validation resources; and / or ii) Segment identification components arranged to facilitate the identification of at least one subset of multiple blockchain transactions; and / or iii) Assigned units; and / or iv) One or more interfaces for sending and receiving communications between the system and one or more data sources or destinations.

[0259] Clause 4.3. The system is as described in Clause 4.1 or 4.2, and the system is: At least one verification resource, At least one processor of at least one verification resource, One or more interfaces, One or more load balancing components, and / or One or more segment identification components arranged to facilitate the identification of at least one subset of multiple blockchain transactions. It comprises at least one controller component positioned to influence and / or control at least one of the operations.

[0260] Clause 4.4. A system as described in any one of the above clauses, i) At least two of the multiple blockchain transactions are Merkle Tree, and / or ii) An internal node is the parent or ancestor of a subset of blockchain transactions.

[0261] Clause 4.5. A system as described in any one of the above clauses, further comprising multiple UTXO repositories, each of which is associated with its respective validation resource and configured to facilitate the recording, retrieval, and / or processing of multiple unconsumed transaction outputs (UTXOs), Preferably, each of the multiple unspent transaction outputs is associated with at least one transaction (Tx) within multiple blockchain transactions.

[0262] Clause 4.6. A system described in Clause 4.5 that operates to create and / or maintain a database log containing a history of actions, changes, and events related to at least one of multiple UTXO repositories.

[0263] Clause 4.7. A system described in any one of the above clauses, wherein at least one of the multiple UTXO repositories is i) Unconsumed transaction output (UTXO), and / or ii) a) Unconsumed transaction output and / or b) at least one record associated with an identifier associated with a transaction (Tx) within multiple blockchain transactions.

[0264] Clause 4.8. The system is as described in Clause 4.7, and at least one record is: i) The block identifier (blockID) associated with the blockchain block, and / or ii) Includes a record identifier that includes a transaction identifier (TxID) associated with a transaction (Tx) within multiple blockchain transactions.

[0265] Clause 4.9. The system is as described in Clause 4.7 or 4.8, and the record identifier is: i) Functions for block identifier (block_ID) and transaction identifier (TxID), and / or ii) Includes concatenation of block identifier (block_ID) and transaction identifier (TxID).

[0266] Clause 4.10. A system described in Clause 8 or 9, which operates to retrieve, identify, access, or insert at least one record in at least one UTXO repository in multiple UTXO repositories using a record identifier.

[0267] Clause 4.11. A system described in any one of Clauses 4.5 through 4.10, wherein at least one of multiple unspent transaction outputs (UTXOs) is associated with a lock flag, and this lock flag is i) Indicates whether the unconsumed transaction output (UTXO) is available or unavailable, and / or ii) It is configurable between a first state indicating that the use of unconsumed transaction output is permitted and a second state indicating that the use of unconsumed transaction output is prohibited.

[0268] Clause 4.12. A system as described in Clause 4.11, which operates to change the state of a lock flag from the first state to the second state, or from the second state to the first state.

[0269] Clause 4.13. A system described in any one of the above clauses, said system i) Assigning each subset of blockchain transactions to multiple validation resources, and ii) Use one, some, or all of multiple verification resources to download and / or receive each subset of blockchain transactions.

[0270] Clause 4.14. A system described in any of the above clauses, which operates to generate each candidate internal node of a Merkle tree using one, some, or all of the verification resources based on each subset of downloaded blockchain transactions, and further operates to perform at least one of the following: Verify that each candidate internal node matches each internal node in the Merkle tree, and / or By performing a Merkle proof based on the root of the Merkle tree, we verify that each candidate internal node is a node in the Merkle tree, and / or, Send each candidate internal node of the Merkle tree to one or more other processing resources.

[0271] Clause 4.15. A system as described in any one of the above clauses, i) Verify and / or validate at least one blockchain transaction, and / or ii) Perform a simplified payment verification process, and / or iii) To act to check whether a given blockchain transaction is included in a blockchain block, and / or iii) Generate a hash of at least one blockchain transaction, use that hash to construct a Merkle path, and / or check if the hash matches the transaction identifier in the blockchain block header.

[0272] Clause 4.16. A system as described in any one of the above clauses, wherein at least one of the multiple verification resources is or includes at least one of a virtual machine, a server, a GPU-based computing resource, a thread, and / or a multiprocessor system.

[0273] Clause Set 5: Any embodiment defined by any clause or combination of clauses in Clause Set 5 may be arranged to implement or combine with any clause in Clause Sets 1 through 4.

[0274] Clause 5.1. A computer implementation method that includes using 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 derived includes unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0275] The aforementioned data may additionally or alternatively include transaction data for determining whether at least a portion of a transaction (Tx) is included in the Merkle path of a blockchain block (B).

[0276] Information related to data obtained from the blockchain is stored in resources for efficient and cost-effective referencing. By allocating resources using a portion of the data, the relationships between the data, its associated information, and the resources in which it is stored are 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 stores information about that data.

[0277] A database of transactions containing UTXOs and / or UTXOs can be constructed. The database can be distributed and form a distributed pool. The database can hold at least one of the following: a flag indicating the validity of unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs, and information for determining the validity of unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs (e.g., SPV information).

[0278] Prior to allocation, which enables subsequent identification of the resource, this method may include retrieving some of the data obtained from the blockchain and / or related data. After allocation, this method may include storing and / or validating the unconsumed transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0279] Allocation can support load balancing across multiple resources. Clause 5.2. A method relating to Clause 5.1, further comprising storing and / or processing at least a portion of a UTXO and / or transaction (Tx) in an allocated resource, storing and / or processing by an allocated resource, or storing and / or processing in relation to an allocated resource.

[0280] The process includes at least one of the following: validating UTXOs and / or transactions (Tx), and managing information associated with the data in an accessible structure such as a database.

[0281] Clause 5.3. The method described in Clause 5.1 or 5.2, further comprising, in an allocated resource, receiving the data from which a portion of the data originates, parsing the data, and deciding whether to process the data and / or store information obtained from the data, or do nothing.

[0282] One of several resources can determine whether it is responsible for receiving a portion of the data and / or information associated with said data, and for storing information related to the UTXO.

[0283] Clause 5.4. The method described in any one of the above clauses, further including obtaining a portion of the data from the blockchain.

[0284] Clause 5.5. The method described in any one of the above clauses, wherein the identification and / or allocation to processing resources and / or storage resources is performed by an intermediary connected to multiple allocated resources.

[0285] Clause 5.6. The method described in any one of the above clauses, wherein the allocated resource performs at least one of the following: verifying unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs, and generating, storing, and / or maintaining records of verification data necessary to verify unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0286] Clause 5.7. The method described in Clause 5.1, wherein the data includes at least one of the following: a UTXO identifier, a UTXO script hash, or a transaction identifier (TXID).

[0287] Clause 5.8. The method described in any one of the above clauses, wherein the processing of the data includes determining a key, and the key determines the allocated resource.

[0288] Clause 5.9. The method described in Clause 5.8, wherein the key is hashed, and the allocated resource is determined by the resulting hash.

[0289] Clause 5.10. A method as described in any one of the above clauses, wherein at least one of the data, key, and resulting hash includes at least one alphanumeric character and at least one binary character, the numeric character being used to determine the allocated resource.

[0290] Clause 5.11. The method described in Clause 5.10, which involves analyzing a portion of a numerical value to determine the allocated resources.

[0291] Clause 5.12. The method described in any one of the above clauses, wherein the hash table determines the allocated resource in which at least a portion of the UTXO and / or transaction (Tx) will be stored.

[0292] Clause 5.13. A method described in any one of Clauses 5.6 to 5.12, wherein the records of at least some UTXOs and / or transactions (Tx) include at least one of: a Merkle tree of the block in which the transaction (Tx) is recorded; a Merkle root of the block in which the transaction (Tx) is recorded; a Merkle path that enables the determination of the value of the Merkle root of the block in which the transaction (Tx) is recorded from a hash of the transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in multiple blockchain transactions within the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); and a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0293] Clause 5.14. A method of any one of the preceding Clauses, further comprising, for at least a portion of a transaction (Tx) and / or UTXO, at least one of the following: verifying and / or confirming a UTXO; performing at least a portion of the simplified payment verification (SPV) process for a UTXO; determining whether a particular blockchain transaction (Tx) is included in a blockchain block; generating a hash of at least one blockchain transaction and using that hash to construct a Merkle path and / or determining whether the hash matches a transaction identifier (TxID) in the header of a blockchain block; and determining a Merkle proof for a UTXO.

[0294] Clause 5.15. A computer implementation method comprising the steps of generating, storing, and / or maintaining a first UTXO resource for recording, retrieving, and / or processing a plurality of unspent transaction outputs (UTXOs) associated with each transaction (Tx) within a plurality of blockchain transactions (TX) of a blockchain block; identifying and / or allocating the resource using a portion of data derived from the blockchain; and the data from which the portion of the data derived includes an unspent transaction output (UTXO) and / or a transaction (Tx) containing the UTXO.

[0295] Clause 5.16. A computer implementation method that includes receiving and / or processing an unconsumed transaction output (UTXO) and including it in a transaction, and / or using a portion of the data obtained from the UTXO to identify an allocated resource (where the allocated resource holds the validation data of the UTXO), and / or requesting validation data from the allocated resource.

[0296] Clause 5.17. The method described in Clause 5.16, further comprising obtaining at least one of the following from the allocated resources: (i) Verification of the UTXO and / or the transaction (Tx) containing the UTXO, and / or (ii) A record for determining the validity of a UTXO and / or a transaction (Tx) that contains such UTXO.

[0297] Clause 5.18. The method described in any one of the above clauses, further comprising preparing and / or sending a transaction (Tx) that includes a UTXO as input.

[0298] Clause 5.19. A blockchain node configured to generate, store, and maintain UTXO resources for recording, retrieving, and / or processing multiple unconsumed transaction outputs (UTXOs), and to process a portion of the data derived from the blockchain, to identify and / or allocate processing and / or storage resources, the data from which this portion of the data derived includes unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0299] Clause 5.20. A computer device comprising memory including one or more memory units and a processing unit including one or more processing units, wherein the memory stores code arranged to be executed on the processing unit, and the code is configured to perform any one of Clauses 5.1 to 5.18 when executed on the processing unit.

[0300] Clause 5.21. A computer program recorded in a computer-readable storage device and configured to perform, when executed on one or more processors, the method described in any one of Clauses 5.1 through 5.18.

[0301] Clause Set 6: Any embodiment defined by any clause or combination of clauses in Clause Set 6 may be arranged to implement or combine with any clause in Clause Sets 1 through 5.

[0302] Clause 6.1. A computer implementation method that includes generating, storing, processing, accessing, and / or maintaining records of at least a portion of a transaction (Tx), The record contains transaction data to determine that at least a portion of a transaction (Tx) is included in the Merkle path of a blockchain block (B).

[0303] Overall, a record has the function of holding information such as data items. As mentioned above, records can be stored in allocated resources (e.g., databases), and these resources can be part of blockchain-connected resources (e.g., nodes) or other resources connected to the blockchain network. The present invention is not limited to this, and the verification, allocation / identification, and formatting of records can be used to implement node functions, which may be off-chain.

[0304] A record consists of at least transaction data and may also include status flags / state, validation information, validation data, detailed information about the location of the UTXO, a reference to at least one previous record (e.g., location), signature, and approval data. This record allows for the storage of transaction-related data in a catalog format.

[0305] In other words, a record is part of a pruned version of a blockchain block. A record is part of a collection of records, preferably stored in an allocated resource, and holds data items retrieved directly from a blockchain block, or data derived from the blockchain (for example, a collection of verification data or transaction-related information).

[0306] The system 1100, which manages the database and / or allocated resource 1104 that holds the transaction records, can be said to behave like a node. Since the records contain transaction data that includes at least some of the transactions included in the Merkle path, a Merkle-linked, pruned node can be implemented.

[0307] For example, a system such as a Merkle-linked pruning node could be built and made available to its owner. For instance, blockchain data associated with tokens issued by the Bank of England could be held as records within allocated resources. These records could be pruned or enhanced versions of the corresponding transaction data held on the blockchain.

[0308] The configuration of records, as disclosed herein, complements transaction validation and / or the allocation and / or identification of processing resources and / or storage resources. The contents of records enable improved security and resilience, increased efficiency, or reduced speed and resource requirements when used, and their use includes validation of the transactions to which the records relate.

[0309] Assignment and / or identification are based on some of the data obtained from the entire blockchain transaction or at least a portion of it, for example, some of the data obtained consists of transaction data such as unconsumed transaction outputs (UTXOs) and / or transactions containing UTXOs (Tx). The data may also include, additionally or alternatively, transaction data to determine whether at least a portion of the transaction is included in the Merkle path of a blockchain block.

[0310] Clause 6.2. The method described in Clause 6.1, wherein the record includes a data catalog, and the data catalog is a set of transactional data or includes a set of transactional data.

[0311] Clause 6.3. The method described in Clause 6.1 or 6.2, wherein the record is processed and / or stored in the allocated resource (1104).

[0312] Clause 6.4. The method described in any one of the above clauses, wherein at least a portion of the transaction (Tx) is the output of the transaction.

[0313] Clause 6.5. The method described in Clause 6.4, wherein the output of a transaction is a transaction (Tx) containing the unconsumed transaction output (UTXO) and / or the UTXO of the blockchain block.

[0314] Clause 6.6. A method described in any one of the above clauses, wherein a record is stored in a database, and said record is i) A blockchain transaction (TXO) containing at least one data item (D), ii) including at least one further blockchain transaction (TX1) necessary to confirm that the blockchain transaction (TX1) is included in the Merkle path of the blockchain block (B).

[0315] Clause 6.7. The use of the database as described in any one of the above clauses includes i) generating, maintaining, providing, updating, storing, accessing, or processing data stored in or related to the database and / or ii) the database.

[0316] Clause 6.8. The method described in any one of the preceding Clauses, wherein the record further includes a Merkle path from the transaction (TXO) to the root of the Merkle tree of the blockchain block (B).

[0317] Clause 6.9. A method as described in any of the preceding Clauses, wherein the Merkle pass includes at least the minimum number of blockchain transactions necessary to establish or verify that the blockchain transaction (TXO) is included in the blockchain block (B).

[0318] Clause 6.10. The method described in any one of the above clauses, and the blockchain block is i) Blockchain ledger, and / or ii) Stored on or associated with off-chain storage resources.

[0319] Clause 6.11. The method described in any one of Clauses 6.6 to 6.10, further comprising verifying that a blockchain transaction (TXO) is included in the Merkle path of a blockchain block (B) using a blockchain transaction (TXO) and at least one further blockchain transaction (TX1).

[0320] Clause 6.12. The method described in any one of Clauses 6.6 through 6.11, wherein the data item (D) is stored in association with a script within a transaction and / or stored as metadata within a transaction.

[0321] Clause 6.13. The method described in any one of the above clauses, wherein the record further includes verification data necessary to verify the unconsumed transaction output (UTXO) and / or the transaction (Tx) containing the UTXO.

[0322] Clause 6.14. The method described in any one of the above clauses, wherein the record further includes the history of multiple preceding transactions of the unconsumed transaction output (UTXO) and / or transaction (Tx) containing the UTXO.

[0323] Clause 6.15. The method described in any one of the above clauses, wherein the record further includes a history of allocated resources that processed and / or stored data of at least one preceding transaction, preferably an unconsumed transaction output (UTXO), and / or a transaction (Tx) containing a UTXO.

[0324] Clause 6.16. The method described in Clause 6.14 or 6.15, and the said history includes: A set of transaction data for determining Merkle proofs of multiple preceding transactions. Links to the respective allocated resources that processed and / or stored multiple preceding transactions. It includes at least one of the following.

[0325] Clause 6.17. The method described in any one of the above clauses, wherein the record further includes flags and / or status indicators for each input of an unconsumed transaction output (UTXO) and / or a transaction (Tx) containing a UTXO.

[0326] Clause 6.18. The method described in any one of the above clauses, the record further includes at least one of the following: A Merkle tree of the block in which transactions (Tx) are recorded; The Merkle root of the block in which the transaction (Tx) is recorded; A Merkle path allows you to determine the value of the Merkle root of the block in which a transaction (Tx) is recorded, from the hash of the transaction (Tx); Merkle proof; Block identifier (block_ID) associated with a blockchain block; Transaction identifier (TxID) associated with a transaction (Tx) in multiple blockchain transactions within a blockchain block; Functions for block identifiers (block_ID) and transaction identifiers (TxID); Concatenation of block identifier (block_ID) and transaction identifier (TXID); Digital signature; Authentication code; A signature message used to determine the transaction state; Protocol flags; Public Key (DPK) as appropriate; and Transaction ID (DTxID) as appropriate.

[0327] Clause 6.19. The method described in any one of Clauses 6.3 through 6.18, wherein the resources allocated for processing and / or storing records are identified and / or allocated using a portion of the data derived from the blockchain to identify and / or allocate the resources, and the data from which a portion of the data is derived includes unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0328] Clause 6.20. A computer implementation method that uses a database containing at least one record, where at least one record is i) A blockchain transaction (TXO) containing at least one data item (D), ii) including at least one further blockchain transaction (TX1) necessary to confirm that the blockchain transaction (TX1) is included in the Merkle path of the blockchain block (B).

[0329] Clause 6.21. The method described in Clause 6.20, and the use of the database, i) databases, and / or ii) Including generating, maintaining, providing, updating, storing, accessing, or processing data stored in or in relation to a database.

[0330] Clause 6.22. The method described in Clause 6.20 or 6.21, wherein the record further includes a Merkle path from the transaction (TXO) to the root of the Merkle tree of the blockchain block (B).

[0331] Clause 6.23. The method described in Clause 6.22, wherein the Merkle pass includes at least the minimum blockchain transactions necessary to establish or verify that a blockchain transaction (TXO) is included in a blockchain block (B).

[0332] Clause 6.24. The method described in any one of Clauses 6.20 to 6.23, and the block is: i) Blockchain ledger, and / or ii) Stored on or associated with off-chain storage resources.

[0333] Clause 6.25. The method described in any one of Clauses 6.20 to 6.24, further comprising verifying that a blockchain transaction (TXO) is included in the Merkle path of a blockchain block (B) using a blockchain transaction (TXO) and at least one additional blockchain transaction (TX1).

[0334] Clause 6.26. The method described in any one of Clauses 6.20 through 6.25, wherein data item (D) is Stored in association with the script within the transaction, and / or It is stored as metadata within the transaction.

[0335] Clause 6.27. A method described in any one of Clauses 6.20 through 6.26, wherein the transaction is: Transaction ID (TxID), It further includes protocol flags, public key (DPK) as appropriate, and transaction ID (DTxID) as appropriate.

[0336] Clause 6.28. Computer equipment, Memory including one or more memory units, The system comprises a processing unit including one or more processing units, the memory storing code arranged to run on the processing unit, and the code configured to perform the method described in any one of the clauses 6.1 to 6.27 on the processing unit.

[0337] Clause 6.29. A computer program that is implemented in a computer-readable storage device and, when executed on one or more processors, is configured to perform a method described in any one of Clauses 6.1 through 6.27.

[0338] Article 7: Any embodiment defined by any clause or combination of clauses in Clause Set 7 can be configured to implement or combine any clause in Clause Sets 1 through 6, and this disclosure includes a technique for representing items consisting of multiple components using a tree structure. Data associated with each component is stored in the respective blockchain transactions that may be included in the tree structure.

[0339] Furthermore, or alternatively, the disclosure aspect involves the use of a tree structure to represent the components of an item, with each component associated with a (potentially separate, respective) transaction on the blockchain.

[0340] One advantage is that even if the state of an item or its components changes over time, the item can be tracked or verified at a detailed level through the tree structure. A component can be the physical part of a physical item, or a part or function of a virtual or digital item. The term "attribute" can also be used instead of "component."

[0341] In non-exclusive use cases, an item could be a vehicle such as an aircraft. Data related to each component of an aircraft can be included in the output of a transaction on the blockchain (e.g., manufacturer, manufacturing date, last service date, serial number, etc.). Data related to various transactions can be recorded in a tree structure such as a hash tree. Over time, the output is used by new transactions, and the tree is updated accordingly. Thus, the history and current status of an aircraft can be verified through the tree. Therefore, this method can provide a technical mechanism to guarantee the integrity of the data related to an item and / or the history of that item.

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

[0343] The process may include at least one of the following: creation, storage, access, and maintenance of a tree structure. The tree structure may be a hash tree, or it may be an asymmetric tree structure, such as an ontology tree.

[0344] Clause 7.2. The method described in Clause 7.1, which further includes processing a record of an item and / or at least one component of an item, verifying that at least one of the item, at least one component of an item, and at least one portion of a blockchain transaction (Tx) is part of a tree structure, and processing and / or storing the item, at least one component of an item, and at least one portion of a blockchain transaction (Tx) in an allocated resource (1104).

[0345] A record can be data associated with a blockchain transaction. A record may include proof that at least one of an item, component, or blockchain transaction is part of a tree structure.

[0346] At least a portion of a blockchain transaction can be a transaction output. A transaction output can be an unconsumed transaction output (UTXO) and / or a transaction (Tx) containing a blockchain block UTXO. A record is stored in a database, for example, an allocated resource, and includes i) a blockchain transaction containing at least one data item (D), and ii) at least one additional blockchain transaction (TX1) necessary to ensure that the blockchain transaction (TX1) is included in the tree structure.

[0347] Data associated with an item or component (for example, a data item (D)) can be stored in association with a script within a transaction. Alternatively, data items (D) can also be stored as metadata within a transaction.

[0348] Records may contain verification data necessary for validating blockchain transactions (for example, unspent transaction outputs (UTXOs) associated with a tree structure). Records may also contain the history of several preceding blockchain transactions.

[0349] Clause 7.3. The method described in Clause 7.1 or 7.2, wherein each item and component of an item is represented by nodes and leaves in a tree structure, which are hashed to create a hash tree.

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

[0351] Clause 7.5. A method described in any one of the above clauses, wherein at least a portion of the tree structure is stored in the blockchain ledger.

[0352] A blockchain ledger can be a private ledger stored on a server. At least the hash of the root node can be stored on a public blockchain.

[0353] Clause 7.6. A method described in any of the preceding Clauses, further comprising processing a second tree structure representing an item and / or at least one component of an item, associating an item and / or at least one component of an item with a second blockchain transaction (Tx) represented in the second tree structure, and associating a blockchain transaction in the tree structure with the second tree structure.

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

[0355] Clause 7.8. The method described in any one of the preceding Clauses, wherein a blockchain transaction includes at least one of the tree structure from which the blockchain transaction originated or the history of each tree structure, and the history of the allocated resource in which the blockchain transaction is stored, and the history can be used to verify that at least one of the items, at least one component of an item, and at least one part of a blockchain transaction (Tx) is part of the tree structure or a second tree structure.

[0356] Clause 7.9. The method described in any one of the above clauses, wherein a blockchain transaction (Tx) is used to identify and / or allocate the allocated resources.

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

[0358] Clause 7.10. The method described in Clause 7.9, further comprising storing and / or processing at least a portion of a blockchain transaction (Tx) in an allocated resource, by an allocated resource, or in relation to an allocated resource.

[0359] Clause 7.11. The method described in any one of Clauses 7.2 through 7.10, wherein a key is determined using a blockchain transaction or its hash, and the resources allocated by that key are determined.

[0360] Clause 7.12. The method described in Clause 7.11, wherein the key includes at least one alphanumeric and binary number, and the numerical value is used to determine the allocated resource.

[0361] Clause 7.13. The method described in Clause 7.11 or 7.12, which involves analyzing a blockchain transaction, its hash, or key to determine the allocated resources.

[0362] Clause 7.14. A blockchain transaction as described in any of the preceding Clauses, comprising at least one of: a Merkle tree of the block in which a transaction (Tx) is recorded; a Merkle root of the block in which a transaction (Tx) is recorded; a Merkle path that enables the determination of the value of the Merkle root of the block in which a transaction (Tx) is recorded from 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 multiple blockchain transactions within a 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).

[0363] Clause 7.15. A method of any one of the preceding Clauses, further comprising, for at least a portion of a blockchain transaction (Tx), at least one of the following: verifying and / or confirming a blockchain transaction (Tx); performing at least a portion of a simplified payment verification (SPV) process on a blockchain transaction; determining whether a blockchain transaction (Tx) is contained within a blockchain block; determining a Merkle proof of a blockchain transaction (Tx); and proving that the associated blockchain transaction is part of a tree structure (by using the hash of the root of the tree structure and at least one path that enables determining from the hash of the blockchain transaction the hash of the root of the tree structure on which the associated blockchain transaction is recorded).

[0364] Clause 7.16. A computer device comprising memory including one or more memory units and a processing unit including one or more processing units, wherein the memory stores code arranged to be executed on the processing unit, and the code is configured to perform the method described in any one of Clauses 7.1 to 7.16 when executed on the processing unit.

[0365] Clause 7.17. A computer program recorded in a computer-readable storage device and configured to perform, when executed on one or more processors, the method described in any one of Clauses 7.1 through 7.16.

[0366] Exemplary technical environment for implementing exemplary embodiments of the disclosure The following outlines a computing environment in which one or more embodiments of this disclosure can be implemented. However, as stated above, this context is not limiting, and the embodiments can also be applied to the processing of data records and structures not implemented via blockchain. Non-blockchain embodiments include, for example, those that use a database instead of a distributed ledger.

[0367] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0368] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0369] Blockchain 150 comprises a chain of data blocks 151, and each copy of Blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of Blockchain 150 does not necessarily mean remembering Blockchain 150 completely. Instead, Blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 remembers the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount as a property representing the quantity of a digital asset, an example being user 103, the target of the cryptographically locked output (requiring the user's signature or other solution to be unlocked and thereby redeemed or consumed). Each input points to the output of the preceding transaction 152, thereby linking the transactions.

[0370] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define the sequential order of blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer to a previous transaction to define the order of the transaction sequence (note that the sequence of transactions 152 is allowed to fork). The chain of block 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. One or more initial original transactions 152 in chain 150 pointed to the genesis block 153, rather than a preceding transaction.

[0371] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool.” In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0372] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Thus, in this specification, "preceding" refers to something that precedes in a logical sequence linked by pointers, and not necessarily the time of creation or transmission in chronological order, and does not necessarily preclude transactions 152i and 152j from being created or sent in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0373] The input to the current transaction 152j also includes authorization of the input, for example, the signature of user 103a, which locks the output of the preceding transaction 152i. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input to the preceding transaction 152i to a new user or entity 103b as defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs for dividing the input amount among multiple users or entities (one of which may be the original user or entity 103a to make the change). In some cases, the transaction may also have multiple inputs for aggregating amounts from multiple outputs of one or more preceding transactions and redistributing them to one or more outputs of the current transaction.

[0374] According to output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to compose a new transaction 152j (either manually or through an automated process used by the party), the composing party sends the new transaction from its computer terminal 102 to the recipient. The composing party or recipient then sends this transaction to one or more blockchain nodes 104 on the network 106 (which are usually servers or data centers today, but may in principle be other user terminals). The party 103 composing the new transaction 152j may also send the transaction directly to one or more blockchain nodes 104, and in some cases, it is not ruled out that it does not have to send it to the recipient. The blockchain node 104 receiving the transaction verifies whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to verify that the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include verifying that the cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction consumes (i.e., "assigns"), which typically includes verifying that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, this could be determined solely by the blockchain node protocol, or by a combination of both. In any case, if the new transaction 152j is valid, blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0375] In an output-based model, the definition of whether a given output (e.g., a UTXO) is allocated (or "consumed") is whether it has not yet been legitimately redeemed by the input of another preceding transaction 152j according to the blockchain node protocol. Another condition for a transaction to be legitimate is that the output of the preceding transaction 152i that it seeks to redeem has not yet been redeemed by another transaction. Again, if it is not legitimate, transaction 152j is not propagated on blockchain 150 (unless flagged as fraudulent and propagated for warning) or recorded. This protects against double consumption, such as when a trader attempts to allocate the output of the same transaction more than once. Account-based models, on the other hand, protect against double consumption by maintaining account balances. Again, since there is no defined order for transactions, account balances have a single defined state at any given time.

[0376] In addition to verifying the validity of transactions, blockchain node 104 also competes to be the first to create a block of transactions in a process commonly called mining, which is aided by "proof of work". At blockchain node 104, new transactions that have not yet appeared in block 151 recorded in blockchain 150 are added to an ordered pool 154 of valid transactions. The blockchain nodes then compete to assemble a new valid block 151 of transaction 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 unprocessed transactions 154 and hashed, the output of the hash satisfies a given condition. For example, a given condition might be that the output of the hash has leading zeros of a defined number. Note that this is just one particular type of proof of work puzzle, and other types are not excluded. The property of a hash function is that it has an output that is unpredictable with respect to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources on each blockchain node 104 attempting to solve the puzzle.

[0377] The first blockchain node 104, which solves the puzzle, announces this to the network 106 and provides the solution as proof, which can then be easily verified by other blockchain nodes 104 in the network (if a solution to a hash is given, it is easy to verify that the output of the hash satisfies the conditions). The first blockchain node 104 spreads the block to a agreed threshold number of other nodes that accept the block and enforce the protocol rules. Then, the ordered set of transactions 154 is recorded by each of the blockchain nodes 104 as a new block 151 in blockchain 150. The block pointer 155 is also assigned to a new block 151n that points to a previously created block 151n-1 in the chain. The large amount of effort required to produce the proof-of-work solution, for example in the form of a hash, demonstrates the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as legitimate if it consumes or assigns the same output as a previously validated transaction (this is also known as double consumption). Once created, block 151 cannot be altered because it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. The block pointer 155 also imposes a sequential order on block 151. Since transaction 152 is recorded in an ordered block at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0378] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time can do so based on different snapshots of the pool of transactions 154 that have not yet been made public at any given time, depending on when they started searching for the solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of public transactions 154 is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of public transactions 154, and so on. There also exists a protocol for solving any possible "forks," which is a situation where two blockchain nodes 104 solve the puzzle to each other in a very short time, and conflicting views of the blockchain spread between the nodes 104. In other words, the branch of the fork that becomes the final blockchain 150. It should be noted that this should not affect the network's users or agents, as the same transactions will appear in both forks.

[0379] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to newly allocate an additional acceptable amount of digital assets in a new special type of transaction (not an inter-agent or inter-user transaction that transfers a certain amount of digital assets from one agent or user to another) that distributes an additional predetermined amount of digital assets. This special type of transaction is usually called a "coinbase transaction," but may also be named an "initial transaction" or "generating transaction." It usually forms the first transaction of a new block 151n. Proof of work indicates the node constructing the new block's intention to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, for example, 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created block 151n in which the transaction is published. This fee is usually called a "transaction fee" and will be discussed below.

[0380] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0381] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0382] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., they have obtained a copy of the blockchain from a blockchain node 104).

[0383] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. 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 as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0384] Each computer device 102 of party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as an SSD, flash memory, or EEPROM, and / or an optical medium such as an optical disc drive. The memory of each computer device 102 of party 103 stores software comprising each entity of at least one client application 105 which is made to run on the processing unit. It will be understood that any action attributed herein to a given party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

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

[0386] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0387] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it will be understood that this is not limited.

[0388] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0389] When a given party 103, for example Alice, wishes to send a new transaction 152j so that it can be included in blockchain 150, Alice organizes the new transaction according to the relevant transaction protocol (using the wallet function of Alice's client application 105). Alice then sends transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this could be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, the blockchain node 104 handles transaction 152j according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j satisfies certain conditions for being "valid," an example of which will be discussed in detail shortly. In some transaction protocols, the conditions for validity checks may be configurable on a per-transaction basis by a script included in transaction 152. Alternatively, the conditions may simply be built-in functions of the node protocol, or may be defined by a combination of the script and the node protocol.

[0390] Subject to the newly received transaction 152j passing the test for being considered legitimate (i.e., for the conditions under which it is "validated"), any blockchain node 104 receiving transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Furthermore, any blockchain node 104 receiving transaction 152j propagates the validated transaction 152 forward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, assuming transaction 152j is legitimate, this means that transaction 152j will soon be propagated throughout the entire network 106.

[0391] Once allowed to enter the ordered pool of pending transactions 154 maintained on a given blockchain node 104, that blockchain node 104 begins to compete in solving the proof-of-work puzzle for the latest version of each pool 154 containing the new transaction 152 (remember that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but the first to solve it defines the set of transactions included in the latest block 151. Ultimately, blockchain node 104 solves the puzzle for the portion of the ordered pool 154 containing Alice's transaction 152j). Once proof-of-work is performed on the pool 154 containing the new transaction 152j, it becomes immutably part of one of the blocks 151 in blockchain 150. The order of the transactions is also immutably recorded, as each transaction 152 has a pointer to an earlier transaction.

[0392] Since different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views on which instance is "legitimate" before it is published in a new block 151, and at the time of publication, all blockchain nodes 104 agree that the published instance is the only legitimate instance. If a blockchain node 104 accepts an instance as legitimate and discovers that a second instance is recorded in blockchain 150, that blockchain node 104 must accept this and discard (i.e., treat as fraudulent) the instance it initially accepted (i.e., the one not published in block 151).

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

[0394] 2. UTXO base model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0395] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0396] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0397] When Alice creates a new transaction Tx1, or at least before Alice sends it to network 106, the preceding transaction Tx0 may already be validated and included in block 151 of blockchain 150. It may already be included in one of the blocks 151 at that point, or it may still be waiting in an 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 together to network 106, or, if the node protocol allows buffering of “orphan” transactions, Tx0 may even be sent after Tx1. The terms “preceding” and “successor,” as used herein in the context of a sequence of transactions, refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They may be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction, or "child") pointing to a preceding transaction (ancestor transaction, or "parent") will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0398] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO labeled here as UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a lock script that defines the conditions that must be met by the unlock script in the input 202 of the subsequent transaction for the subsequent transaction to be validated and therefore for the redemption of the UTXO to be successful. Typically, the lock script locks its amount to a specific party (the recipient of the transaction containing the lock script). That is, the lock script defines the unlock condition, which typically includes the condition that the unlock script in the input of the subsequent transaction contains the cryptographic signature of the party to whom the preceding transaction is locked.

[0399] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it might include Bob's signature. The unlock script appears in transaction input 202.

[0400] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A] is the public key P from Alice's public key-private key pair. A The input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A It includes Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by a lock script, by a node protocol, or a combination of these.

[0401] When a new transaction Tx1 reaches blockchain node 104, the node applies the node protocol. This involves executing both the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria). In embodiments, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A Here, "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is the functionality included in the lock script (in this example, a stack-based language). Equivalently, the scripts may be executed one after another using a common stack, rather than concatenating them. In any case, when executed together, these scripts contain Alice's public key P, which is included in the lock script in the output of Tx0. AThis is used to authenticate that the unlock script in the input of Tx1 contains Alice's signature to sign the expected portion of the data. The expected portion of the data itself ("message") must also be included in order to perform this authentication. In this embodiment, the signed data comprises the entirety of Tx1 (and therefore a separate element specifying the signed portion of the data in plaintext does not need to be included, as it essentially already exists).

[0402] The details of public-private cryptography for authentication are familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. A signature typically involves hashing the message, signing the hash, and tagging the message with this signature, thereby allowing any holder of the public key to authenticate the signature. Therefore, it should be noted that any reference herein to signing a particular piece of data or transaction may, in embodiments, mean signing the hash of that piece of data or transaction.

[0403] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), blockchain node 104 considers Tx1 to be legitimate. This means that blockchain node 104 adds Tx1 to the ordered pool of pending transactions 154. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106, so that transaction Tx1 is spread throughout network 106. Once Tx1 is validated and included in blockchain 150, this is defined as having consumed UTXO0 from Tx0. Note that Tx1 can only be legitimate if it consumes an unconsumed transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 is invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been consumed (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a predetermined order on transaction 152. In practice, a given blockchain node 104 could maintain a separate database marking which UTXO 203 transaction 152 consumed, but what ultimately defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction in blockchain 150.

[0404] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this constitutes another ground for invalidity in most transaction models. Therefore, such a transaction will neither be propagated nor included in block 151.

[0405] In a UTXO-based transaction model, it should be noted that a given UTXO must be consumed as a whole. While some of the amount defined in the UTXO may be "left behind" as unconsumed, other parts may not be consumed. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Therefore, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself change or pay another party in the second output of Tx1.

[0406] In practice, Alice would also typically need to include a fee for the Bitcoin node 104 to successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and therefore may not be propagated or included in blockchain 150, even if technically valid (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not want to). In some protocols, the transaction fee does not require a unique separate output 203 (i.e., a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 of a given transaction 152 and the total amount specified in the output 203 is automatically given to the blockchain node 104 issuing the transaction. For example, suppose a pointer to UTXO0 is the sole input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104, which wins the proof-of-work competition to create the block containing UTXO1. However, as an alternative or addition, it is not necessarily ruled out that the transaction fee may be explicitly specified in one of the unique UTXO203 of transaction 152.

[0407] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 at any location within blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout blockchain 150. There is no single number that defines the total balance of a given party 103 stored anywhere in blockchain 150. It is the role of the wallet function of the client application 105 to match together the values ​​of all the various UTXOs locked to each party that have not yet been consumed in another previous transaction. The wallet function can do this by querying a copy of blockchain 150, such as one stored in one of the Bitcoin nodes 104.

[0408] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0409] Typically, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0410] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all blockchain applications that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0411] 3. Side Channel As shown in Figure 1, the respective client applications of Alice's computer device 102a and Bob's computer device 102b may have additional communication capabilities. This additional capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either the parties or a third party). The side channel 107 allows for the exchange of data independently of the blockchain network. Such communication is sometimes called “off-chain” communication. For example, this could be used to exchange transaction 152 without transaction 152 being registered in the blockchain network 106 or entering chain 150 until either Alice or Bob chooses to broadcast transaction 152 between Alice and Bob to the network 106. Sharing a transaction in this manner is sometimes called 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 may be used to exchange any other transaction-related data, such as keys, amounts or terms to be negotiated, and data content.

[0412] Side channel 107 may be established via the same packet-switched network 101 as the 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 local wireless network, or even via a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, any side channel 107 referred to anywhere in this specification may be “off-chain,” i.e., comprise any one or more links via one or more networking technologies or communication media for exchanging data separately from the blockchain network 106. If more than one link is 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 when it is said that Alice and Bob exchange some information or data etc. via side channel 107, this does not necessarily imply that all such data must be transmitted via the exact same link, or even the same type of network.

[0413] conclusion Other variations or uses of the disclosed technology will be apparent to those skilled in the art by reading the disclosure herein. The scope of this disclosure is not limited by the embodiments described herein, but only by the appended claims. For example, some of the embodiments described above describe a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, the Bitcoin blockchain is a specific example of blockchain 150, and it will be understood that the above description is generally applicable to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 above can be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104 described above.

[0414] In a preferred embodiment of this disclosure, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least some or all of the aforementioned functions of creating, publishing, propagating, and storing block 151 of blockchain 150. The possibility of other network entities (or network elements) performing only some or some of these functions, rather than all of them, is not ruled out. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (note that these entities would not be considered nodes of the preferred Bitcoin network 106).

[0415] In other embodiments of this disclosure, blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node performs at least one or some (but not all) of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, in other blockchain networks, “node” may be used to refer to a network entity that is configured to create and publish blocks 151, but is not configured to store and / or propagate those blocks 151 to other nodes.

[0416] More generally, the above reference to the term "Bitcoin node" 104 could be replaced with the term "network entity" or "network element," such entities / elements configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements can be implemented in hardware in the same way as described above with respect to blockchain nodes 104.

[0417] In this book, the term "user" may include both human and machine-based entities.

[0418] The embodiments described above are illustrative and not limiting to the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. In the claims, reference numerals in parentheses should not be construed as limiting the claims. Terms such as “comprising” and “comprises” do not preclude the existence of elements or steps other than those described in the claims or the entire specification. In this specification, “comprises” means “including or consist of,” and “comprising” means “including or consist of.” Throughout this specification, the terms “comprise,” “includes,” “comprises,” or “comprising” are understood to mean including, but not excluding, other elements, integers, or steps, or groups of elements, integers, or steps. A singular reference to an element does not preclude a plural reference to that element, and vice versa. This disclosure can be implemented by hardware comprising multiple different elements and by a appropriately programmed computer. In device claims listing multiple means, some of these means may be embodied by the same hardware. The mere fact that certain means are described in different dependent claims does not suggest that combinations of these means cannot be advantageously utilized. [Explanation of Symbols]

[0419] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output

Claims

1. A computer implementation method, A step of processing a tree structure representing an item and / or at least one component of the item, The steps include associating the item and / or at least one component of the item with a blockchain transaction (Tx) represented in the tree structure. A method that includes [a certain feature].

2. The step further comprises processing records of the item and / or at least one component of the item, A step of verifying that at least one of the item, at least one component of the item, and at least one portion of a blockchain transaction (Tx) is part of the tree structure, The step of processing and / or storing in an allocated resource at least one of the item, at least one component of the item, and at least one portion of a blockchain transaction (Tx). The method according to claim 1, comprising at least one of the following.

3. The method according to claim 1 or 2, wherein each item and each component of the item are represented by nodes and leaves of the tree structure and are hashed to create a hash tree.

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

5. The method according to any one of claims 1 to 4, wherein at least a portion of the tree structure is stored in a blockchain ledger.

6. The steps include processing a second tree structure representing the item and / or at least one component of the item, The steps of associating the item and / or at least one component of the item, as represented in the second tree structure, with a second blockchain transaction (Tx), The steps include associating the blockchain transactions of the tree structure with the second tree structure. The method according to any one of claims 1 to 5, further comprising:

7. The method according to claim 6, further comprising the step of processing a record to verify that 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 or the second tree structure.

8. The aforementioned blockchain transaction The tree structure or the history of each tree structure from which the blockchain transaction originated, The history of the allocated resources in which the aforementioned blockchain transactions are stored and The method according to any one of claims 1 to 7, comprising at least one of the following, wherein the history enables verification that at least one of the item, the at least one component of the item, and at least one portion of a blockchain transaction (Tx) is part of the tree structure or a second tree structure.

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

10. The method according to claim 9, further comprising the steps of storing and / or processing at least a portion of the blockchain transaction (Tx) in the allocated resource, and / or storing and / or processing by the allocated resource, and / or storing and / or processing in relation to the allocated resource.

11. The method according to any one of claims 2 to 10, wherein the blockchain transaction or the hash of the blockchain transaction is used to determine a key, and the key determines the resource to which it is assigned.

12. The method according to claim 11, wherein the key comprises at least one alphanumeric and a binary number used to determine the assigned resource.

13. The method according to claim 11 or 12, wherein the blockchain transaction, the hash of the blockchain transaction, or the key is parsed to determine the allocated resource.

14. The aforementioned blockchain transaction The Merkle tree of the block in which the aforementioned blockchain transaction (Tx) is recorded, The Merkle root of the block in which the aforementioned blockchain transaction (Tx) is recorded, From the hash of the blockchain transaction (Tx), a Merkle path is obtained that enables the determination of a value for the Merkle root of the block in which the transaction (Tx) is recorded. Merkle proof, Block identifier (block_ID) associated with a blockchain block, Transaction identifiers (TxID) associated with transactions (Tx) of multiple blockchain transactions within the aforementioned blockchain block, The functions of the block identifier (block_ID) and the transaction identifier (TxID), and The concatenation of the block identifier (block_ID) and the transaction identifier (TxID) The method according to any one of claims 1 to 13, comprising at least one of the following.

15. For at least a portion of the aforementioned blockchain transactions (Tx), The steps include validating and / or verifying the aforementioned blockchain transaction (Tx), The steps include performing at least a portion of the simplified payment verification (SPV) process for the aforementioned blockchain transaction, The steps include: checking whether the aforementioned blockchain transaction (Tx) is included in a blockchain block; The step of determining the Merkle proof for the aforementioned blockchain transaction (Tx) It further includes at least one of the following: The method according to any one of claims 1 to 14, further comprising proof that the associated blockchain transaction is part of the tree structure by using the hash of the root of the tree structure and by at least one of the hash of the blockchain transaction and a path that enables the determination of the hash of the root of the tree structure on which the associated blockchain transaction is recorded.

16. Memory including one or more memory units, A computer device comprising a processing unit including one or more processing units, A computer device wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to any one of claims 1 to 15 when executed on the processing device.

17. A computer program, which is implemented on computer-readable storage, and which, when executed on one or more processors, is configured to perform the method described in any one of claims 1 to 15.

Images