Computer implementation systems and methods for tree-based data validation, communication, and integrity solutions

Abstract

The present invention relates to associating data with blockchain transactions (Tx), wherein the data is represented in a tree structure; processing the path of the tree structure containing the data; processing the digital signatures of the creator and / or approver of the data; and validating that at least one of the data, the digital signature, and the blockchain transaction (Tx) is part of the tree structure. Similarly, the present invention relates to processing such data for recording and subsequent validation. In one example, a web address is represented by a tree structure. At least the data associated with the data of the web page of the web address is represented in a tree structure. At least one of the data, processed data, and / or digital signature is associated with a blockchain transaction (Tx) represented in a tree structure. The data and the associated tree structure are recorded and subsequently processed so that the data can be validated. Through association with blockchain transactions and by processing the tree structure and the digital signature associated with the data, such as a web page or its content, the validity of the data can be determined so that the browser can selectively access only the valid data.

Description

[Technical Field]

[0001] This disclosure generally relates to improved methods and systems for processing and / or managing data records, and / or the format and / or content of such records. This disclosure is particularly well-suited for use in transactions conducted on or using a blockchain network, storage allocation decisions, pre-mining and / or post-mining validity checks of blockchain transactions, SPV checks, etc. Benefits include, but are not limited to, improved security and resilience, increased or reduced speed and resource requirements, a novel approach to validity checks, and load balancing of resources that was not possible with conventional deployment configurations. This enables blockchain implementation deployment configurations that were previously not possible. The improved methods and systems are well-suited for tracking and / or validating items and / or their subcomponents instantaneously, over time, and through changes in applications, at least one of these. In particular, the improved methods and systems are well-suited for validating that at least one of data, digital signatures, and / or blockchain transactions is part of a tree structure. [Background technology]

[0002] While the Bitcoin protocol and network may be referenced herein for illustrative purposes to provide an exemplary context for implementation, this disclosure is not limited to use with the Bitcoin blockchain and also extends to alternative protocols and implementations.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system, which consists of blocks, and each block consists of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. Each block contains the hash of the previous block, and the chaining of blocks creates a permanent, immutable record of all transactions written to the blockchain since its inception.

[0004] In one or more exemplary blockchain protocols, for a transaction (Tx) to be written to the blockchain, it must undergo validation. 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 validation task on unspent transaction outputs (UTXOs) by executing lock scripts and unlock scripts. If the execution results of the lock scripts and unlock scripts evaluate to TRUE, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, the following must be performed on the transaction: i) it must be validated by the first node that receives the transaction—if the transaction is validated, the node relays the transaction to other nodes in the network, i.e., the transaction is propagated—ii) it must be added to a new block constructed by a miner, and iii) it must be mined, i.e., added to the public ledger of past transactions. After a transaction is stored in the blockchain as a UTXO, a user can transfer control of the associated tokens to another address associated with the input of another transaction that will subsequently be written to the blockchain. This is often done using a digital wallet that stores the public and private key pair associated with the user's token. Known token wallets come in various forms, including SPV wallets (Simplified Payment Verification). SPV technology allows users and merchant nodes to perform local verification based on only partial information related to a particular transaction. SPV is discussed in more detail below.

[0005] However, with the increasing volume of transactions, there is a known need for improved ability to quickly determine the validity of unconsumed transaction outputs (UTXOs). Current techniques for validity verification tasks can be significantly resource-intensive and time-consuming due to the need to download and store blocks, maintain large UTXO pools, and perform the necessary processing tasks for validity verification. Many users are unable to meet such requirements, or in some cases, do not wish to do so because they do not need to. Therefore, there is a need for a faster and more efficient verification model that addresses at least these challenges (and others) without compromising security or adapting existing protocols. Furthermore, the means for validity verification must be scalable. Moreover, known validity verification techniques are performed at a macro level. However, such approaches hinder the validity verification of individual components and / or dynamic tracking of changes at the granular level within a set of data.

[0006] Therefore, such an improved solution was devised. [Prior art documents] [Patent Documents]

[0007] [Patent Document 1] International Publication No. WO2017 / 145016 [Patent Document 2] PCT International Application No. PCT / IB2019 / 059793 [Patent Document 3] PCT International Application No. PCT / IB2019 / 059795 [Patent Document 4] PCT International Application No. PCT / IB2019 / 059791 [Patent Document 5] PCT International Application No. PCT / IB2019 / 059803 [Patent Document 6] PCT International Application No. PCT / IB2019 / 060226 [Patent Document 7] PCT International Application No. PCT / IB2019 / 059807 [Patent Document 8] PCT International Application No. PCT / IB2019 / 059808 [Patent Document 9] PCT International Application No. PCT / IB2019 / 059809 [Overview of the project] [Means for solving the problem]

[0008] Embodiments of this disclosure provide improved blockchain-related methods, devices, and systems. In one form of expression, such embodiments provide solutions for identifying and / or assigning the processing and / or storage of data associated with blockchain transactions, such as UTXOs, including and / or enabling validation.

[0009] In some embodiments, a tree structure is processed. The tree structure generally represents the relationship between an item and at least one of its components. This tree structure may enable tracking and / or validation of the item and / or at least one component. For example, the tree structure can be recorded at a specific point in time, thereby simultaneously recording the status of an item, a component, or inventory. The tree structure can change over time, which can reflect updates to the item or information associated with the item, and of course the status and / or configuration of the components of the item. The application of an item or component can be tracked even when updated, and one of the item or its components can be tracked in a first application using a first tree structure and also in a second application using a second tree structure, thereby tracking the history of the item or its components across different usage scenarios. Overall, the tree structure can be used to track an item from creation to final use or disposal, for example, for end-to-end item tracking. Tracking an item using a tree structure enables validation of the content of the tree structure, i.e., the item and / or component as part of the tree structure.

[0010] Item tracking can be achieved by associating an item and / or at least one component of the item with a blockchain transaction (Tx) represented by a tree structure. The blockchain transaction can include data associated with the root of the tree structure, whereby any data within the tree can be validated therefrom. For example, the tree structure may be a hash tree, and the data associated with the root of the tree structure can include the hash of the root of the tree structure. At least one of the nodes and leaves of the tree structure can also be associated with the blockchain transaction.

[0011] In some embodiments, a third party can verify the validity of the data before processing the data. This can include determining its provenance and / or authenticity. For example, verifying the validity can include associating the data with a blockchain transaction (Tx), where the data is represented in a tree structure. The path of the tree structure containing the data can be processed, and / or the digital signature of the creator and / or approver of the data can be processed. By processing the data, it can be verified that at least one of the data, digital signature, and blockchain transaction (Tx) is part of the tree structure. The digital signature is associated with the blockchain transaction. The digital signature can be combined with the data.

[0012] In one example, the techniques herein are used to compose and verify the validity of a web address and its components. In this way, the content of a web page, such as HTML, attached files, can be verified for validity on a machine before being processed, displayed, or executed.

[0013] In another example, the data is processed to generate processed data. Then, the data and / or the processed data is associated with the digital signature of the creator and / or approver of the data. The data and / or the processed data is then represented in a tree structure. Thereafter, at least one of the data, processed data, and / or digital signature is associated with a blockchain transaction (Tx) represented in a tree structure. At least one of the data, processed data, digital signature, blockchain transaction (Tx), and tree structure is recorded on the blockchain. The combination of the tree structure and the digital signature can provide an efficient and scalable mechanism for verifying the validity and authenticating the data through association with the blockchain transaction.

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

[0015] In other embodiments, a portion of the data derived from a blockchain, for example, a transaction, may be used to identify and / or allocate processing and / or storage resources.

[0016] Item tracking and / or validation may involve processing records of the item and / or at least one component of the item. Processing the tracked item as part of a tree structure allows for validating 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 may 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).

[0017] Item validation can be improved using the tree structure and techniques described herein, which can enable structured, dynamic methods and systems for tracking and / or validating the tree structure or parts thereof. Furthermore, validation that an item or component is part of a tree structure can be securely achieved without disclosing sensitive information associated with other items or components of the tree structure.

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

[0019] The validity and / or provisionance of an item, or its components, may 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 may be associated with further, for example, a second blockchain transaction (Tx), which is represented within a further tree structure.

[0020] In the validation process, data may be securely exchanged and validated using the teachings of International Publication WO2017 / 145016, which are incorporated herein by reference.

[0021] Embodiments of this disclosure provide improved blockchain relationship methods, devices, and systems. In one form of expression, 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 of a plurality of distributed resources. In addition to or alternatively, the resources may be accessed to retrieve data that enables (i) verification of the validity of a transaction, e.g., a UTXO, and / or (ii) determination of the validity of an associated transaction.

[0022] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the accompanying drawings are referenced only as examples. [Brief explanation of the drawing]

[0023] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram illustrates some examples of transactions that can be recorded on the blockchain. [Figure 3] This diagram illustrates a typical Merkle tree structure known in this field. [Figure 4] This diagram illustrates how the Merkle root can be derived from a set of blockchain transactions, as is known in this field. [Figure 5] This is an illustrative diagram illustrating how a Merkle tree may be divided into subsets (or "segments") that can subsequently be assigned to each validity verification resource according to one embodiment of the present disclosure. [Figure 6] This figure illustrates an alternative example to Figure 5, showing how a Merkle tree can be divided into logical segments. [Figure 7]This figure illustrates a distributed validity verification node at the system level according to one exemplary embodiment of the present disclosure. [Figure 8] This flowchart provides a high-level illustration of the steps involved in the exemplary method described herein. [Figure 9] This figure shows the exemplary system in Figure 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 unused transaction outputs (UTXOs) and / or transactions (Tx) that contain UTXOs. [Figure 11] (a) to (d) are tables showing examples of values ​​derived from portions of the data used to identify and determine the allocated resources. [Figure 12] This is a schematic diagram of a system including nodes, an intermediate switch, and allocated resources, wherein the resources have optional validators. [Figure 13] This is a schematic diagram of two transactions having a position within the Merkle tree of a blockchain block, wherein each transaction has an allocated resource, and the allocated resource holds a corresponding record. [Figure 14a] This is a schematic diagram of an asymmetric tree structure where the root node represents an item, and the nodes and leaves represent components of the item. [Figure 14b] This diagram shows two subsequent blockchain transactions associated with the node or leaf in Figure 14(a). [Figure 15] For example, Figure 14(a) is a schematic diagram of two tree structures in which blockchain transactions associated with a node or leaf are processed and / or stored in the allocated resource (1104). [Figure 16] This is a flowchart illustrating how to process a tree structure. [Figure 17] This is a schematic diagram of a tree structure that represents at least part of the web page's architecture, with one of the nodes containing data and digital signatures. [Figure 18] This is a schematic diagram of a user's computer configured to access data via the cloud, and optionally, the allocated resources. [Figure 19] This is a flowchart for establishing a tree structure containing data with digital signatures. [Figure 20] This is a flowchart for verifying the validity of data within a tree structure, where the aforementioned data has a digital signature. [Modes for carrying out the invention]

[0024] We will now describe exemplary embodiments of the present disclosure, without limitation, with reference to the accompanying figures.

[0025] Means for processing and / or storing information about transactions, such as unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs, can be implemented using different systems and methods, which may be configured and / or executed independently. Examples of a “transaction database” and a “block validity check” are described below, each assigning a task to a resource, such as a distributed resource, which includes storing and / or validating one or more transactions.

[0026] An example of assigning / identifying resources, such as records, is described below in relation to a "UTXO database." Also described below are examples of verifying the validity of transactions, and the techniques / management of validity verification, such as "block validity verification."

[0027] In addition to or alternative to the examples of “allocation” and / or “validation,” at least one example includes generating, storing, processing, accessing, and / or maintaining records of at least a portion of a transaction (Tx). The information stored with respect to a transaction, i.e., the records, may be used to support at least the validation of the transaction. For example, the records may include transaction data for determining that at least a portion of the transaction is included in the Merkle path of a blockchain block.

[0028] The techniques taught herein are suitable for tracking items and at least one component of said items using a tree structure. The tree structure schematically represents the relationships between an item and at least one component of it. The status of an item and / or its component may be associated with the tree structure through blockchain transactions. Transactions may be used to determine the validity and / or provision of an item and / or component from the point in time when it was first tracked using the tree structure. Tracking may be performed using one or more tree structures. Each tree structure may represent an item and / or component and alternative relationships with different items and / or different components. The tree structures are independent, and multiple tree structures may be used to track an item and / or at least one component of an item by migrating blockchain transactions (Tx). The tree structure may be a Merkle tree, a binary tree, an ancestor tree, an asymmetric tree, or otherwise imbalanced in any way.

[0029] Tree-based data integrity solution In addition, or instead of validating an item, such as a node, as part of a tree structure, the integrity or authenticity of the data associated with the item, such as a node in a tree structure, can be determined. For example, integrity determination through validation can be achieved at a granular level where each node, or any component thereof, can be validated. In contrast, a Certificate Authority (CA) can provide Secure Sockets Layer (SSL), which enables encrypted communication between a web browser and a web server, but its global authorization does not support a granular level of data integrity.

[0030] Figure 17 shows an example of data organized in a tree structure. The data in the tree structure may be associated with, or at least a portion of, data in a blockchain transaction (Tx). Each node in the tree structure, or any node within it, may be authorized and / or approved by a digital signature. The signature serves to prove the origin or authenticity of the data.

[0031] Preferably, each node can be digitally signed. By processing the path of the tree structure containing the data, and the digital signatures of the creator and / or approver of the data, at least one of the data, digital signatures, and blockchain transactions (Tx) can be validated as part of the tree structure. This can be achieved, for example, by establishing a hash tree, by establishing relationships between the nodes of the tree structure. In this way, the validity and integrity of the data or any part thereof at any node can be determined.

[0032] In the example in Figure 17, the tree structure 1700 represents the structure of a web address through which a web page 1702 and its content can be accessed. A web page may have an associated digital signature 1704, which may be combined with the entire web page or with individual content. Multiple digital signatures may be used and may be associated with the entire web page and individual content, so that each component of the web page, such as HTML content, links, files, attachments, etc., may have its own digital signature. Components, such as the data of a web page or a part of it, may be signed by a digital signature 1704. Multiple digital signatures may be provided for the data, for example, one each for content, links, and attachments.

[0033] A web address has data separated into components including a top-level domain 1706, a second-level domain 1708, a subdomain 1710, two subdirectories 1712, and their respective paths 1714. A web page 1702 can contain data that includes at least one of the following: content, links, and attachments. Content can include HTML content, files, and / or executable files.

[0034] Each component, level, domain, directory, subdirectory, and path can be represented in a tree structure and may have associated blockchain transactions (Tx) or parts thereof. As illustrated with respect to Figures 11, 13, 14, and 15, at least one of the data, digital signatures, and blockchain transactions (Tx) that are part of the tree structure may be stored in the allocated resource 1104. Combinations of data, digital signatures, and blockchain transactions (Tx) may be created for storage in the allocated resource 1104. Once processed, the allocated resource may hold records that enable efficient validation of data within the node, such as HTML content, files, and / or executable files.

[0035] Figure 18 shows an example of a system in which the methods described herein are applicable. A first party 103a and their respective computer equipment 102a may be configured to access a web page 1704 created by a second party 103b and their respective computer equipment 102b, which creates a web address, for example, a web domain 1700, for access over a network, for example, a packet-switched network 101, as described herein and shown in Figure 1. Data may be processed on or through an allocated resource 1104 in an allocated resource system 1100, as also described herein.

[0036] Figure 19 shows process S1900 for processing data and placing it into a tree structure that can be validated. Using a non-restrictive example, this process is suitable for representing web addresses and their components in a tree structure, as shown in Figure 17. In S1902, the top-level domain, which corresponds to the root of the tree structure, is established. In S1904, components of the web address are added. In S1906, digital signatures 1704 are added to each component. Components and / or digital signatures can be associated with their respective blockchain transactions.

[0037] Components of a tree structure, such as a web address, function as nodes when creating a tree structure S1908 representing a web address. Digital signatures can be associated with data, for example, added to data, or concatenated with data. Data and digital signatures can be hashed before and / or after association, for example, concatenation. If all components of a web address are associated in the tree structure, a hash tree can be determined. The record S1910 of the tree structure can be recorded on the blockchain. Each node and the data associated with it can be given validity verification data that enables the validity verification of the components of the web address, i.e., the nodes in the tree structure. Validity verification can use Simplified Payment Verification (SPV) technology, for example, a technology that validates the relationships in the tree structure between a node and another node, such as a root node.

[0038] A web address may be monitored for changes S1912, and with each update, no matter how small, additions and / or modifications require that the original and / or new digital signatures of the creator and / or authorized administrator be processed on the components of the web address before the updated tree structure is established. Thus, the data and / or content of the components of the web address, such as each page, link, etc., may be digitally signed. Signatures and updates may be applied additionally. In this way, each iteration of a page may be validated before being accessed. This not only allows a machine to validate the data and decide whether to execute or open the content, but also allows the source of any modifications to be traced, for example, when the creator's digital signature was used to digitally sign the data. Through the tree structure and / or digital signatures, the validity and authenticity of the content of the tree structure, i.e., the data within the content of the nodes of the tree structure, such as web page content, can be validated.

[0039] Overall, process S1900 includes processing data to generate processed data, which is associated with the digital signature of the creator and / or approver of the data. While examples herein relate to web addresses and web page content, which may be represented, the teachings herein may apply to data in any tree structure having data or processed data. The data, processed data, and / or digital signature may be associated with a blockchain transaction (Tx), which is represented in the tree structure. Thus, at least one of the data, processed data, digital signature, blockchain transaction (Tx), and tree structure is recorded on the blockchain. At least one of the data, processed data, digital signature, blockchain transaction (Tx), and tree structure may be encrypted, for example, hashed, before being recorded on the blockchain. The tree structure may therefore be configured as a hash tree.

[0040] Updates to data can generate updated, processed data, which can occur when a tree structure, such as a web page, is updated. An update to one node in a tree structure has ripple effects due to its relationship with at least one parent node, resulting in at least one change to the root node. In effect, a second tree structure is created. Each modification to a node in a tree structure can be tracked and validated using, for example, a digital signature applied to the node, such as a web page. At least the root of each version of the tree structure, for example, the root hash, is recorded on-chain, which can allow each version of the tree structure and the nodes within it to be validated. Thus, processed data can be stored within the nodes of the tree structure or the second tree structure. Each node of the tree structure or the second tree structure can contain at least one of the following: data, processed data, and / or a digital signature with a blockchain transaction (Tx) represented in the tree structure.

[0041] In addition to the tree structure, for example, web pages of web addresses being stored on-chain S1910, or alternatively, data or records of data may be stored on private servers and / or assigned resources 1104 which are part of system 1100 in Figure 12. Thus, records of data for validation and / or authentication may be maintained with the data or content and / or stored on supporting resources 1104.

[0042] The process in S1900 is configured to validate data within a tree structure, for example, to validate a webpage at a web address. In one exemplary scenario, machine 102a performs the action of accessing the content of a webpage, which is a node in the tree structure. Before opening the webpage, the machine attempts to validate and / or authenticate the content of the webpage, for example, the data of the webpage. The machine will not open the webpage or otherwise access its data content unless it is valid and / or authentic.

[0043] Figure 20 shows an example of a process S2000 for validating and / or authenticating data in a tree structure, such as the content of a web page, via a web address. In such an example, machine 102a can select a web page 1700 to be accessed via the internet 101 S2002. The data to be accessed is then associated with a blockchain transaction S2004, which enables on-chain verification of the data and its associated tree structure. Records holding such information necessary for verification may be held on-chain, associated with the blockchain transaction. In addition, or alternatively, records holding the information necessary for validation may be held within an allocated resource 1104, which can provide efficient access to the information necessary for validation.

[0044] S2004 associates the data with a blockchain transaction, and S2006 processes a tree structure 1700 representing the data to be accessed. In one example, the tree structure may be a hash tree, and a web page may be verified to be a node of the hash tree and part of the tree. Furthermore, a digital signature associated with the data, such as a web page and its content, may be used to validate and / or authenticate the data. Thus, S2008 validates the path within the tree structure containing the data, and / or S2010 validates the digital signature associated with the data. Such information may be held on-chain and / or within the allocated resource 1104.

[0045] The process determines the validity of the data S2012. If the data is valid and / or authenticated, machine 102a accesses the data S2014. Otherwise, the data is invalid and access is prohibited, and alternative data to be accessed is selected.

[0046] Overall, for example, process S2000 can be implemented by a browser and allow machine 102a to access a webpage or part thereof only if the data is valid and authentic. This can be achieved by processing the path of a tree structure containing the data, processing the digital signatures of the creator and / or approver of the data, and validating that at least one of the data, digital signatures, and blockchain transactions (Tx) is part of the tree structure.

[0047] A digital signature 1704 associated with data, such as web page content, can be the public key of the data's creator and / or authenticator. Alternatively, the digital signature 1704 may be the public key of a blockchain transaction associated with at least one of the data, processed data, and / or a tree structure. The digital signature 1704 can be combined with the data, for example, concatenated before the data is integrated into a tree structure, thereby becoming a unique component in determining the data's validity. Validation may then include determining that the digital signature is also part of the tree structure.

[0048] Any one of the aforementioned data, the processed data, the digital signature, and the blockchain transaction (Tx) may be used to identify and / or assign an assigned resource 1104 in which validation data can be found for the data to be validated and / or authenticated. This data may be used to determine a key containing at least one of alphanumeric characters and binary numbers, the number of which is used to determine the assigned resource. This data, or its hash, can be parsed to determine the assigned resource.

[0049] Records associated with an item and / or at least one component of an item may be managed by using blockchain transactions, which may be part of a blockchain token. The records may 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 a blockchain transaction.

[0050] The features of the examples can be combined in light of the teachings in this specification.

[0051] Tracking using a tree structure Figure 14(a) shows a schematic 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 relationships between items and components. Each of an item and / or at least one component of an item may be associated with a blockchain transaction. An item and / or at least one component of an item may be associated with a blockchain token, and may be tracked, managed, or validated using the associated blockchain transaction.

[0052] A tree structure can be used to verify the validity and / or providence of items and / or components. This can be achieved by associations between data within nodes and leaves, preferably by associated blockchain transactions.

[0053] The tree structure can be a hash tree, such as a Merkle tree, which is a data structure similar to trees 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 non-leaf node, i.e., node 1402, is 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 the hash of all the leaf node hashes concatenated together.

[0054] By processing the tree structure 1400, it becomes possible to determine the authenticity of data within the tree structure using techniques such as root hashing, and / or proof and Simplified Payment Verification.

[0055] 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 representing the item and / or at least one component of an item, or a portion thereof. Processing may include at least one of generating, storing, accessing, and maintaining the tree structure. Updates to associated data, such as records containing the item or component, or to the entire tree structure may be updated, and the tree structure and associated items may be tracked.

[0056] By creating a tree structure 1400 to track items and / or their components, and by associating items and / or at least one component of an item with a blockchain transaction, the validity and / or provisioning of items and / or components from the time they were first tracked using the tree structure can be determined.

[0057] 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 is made possible by using associations with blockchain transactions. Figure 14(b) illustrates a situation where one of the root node 104, node 1402, or leaf 1404 is updated, with the first associated blockchain transaction Tx n TX has been updated n+1 Transactions are linked, and records can be determined to be tamper-proof 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.

[0058] Records of items and / or components can be associated with blockchain transactions, functioning as packets of data associated with an item or component. A record is an example of transaction data, i.e., 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 to (i) validate an item, component, or tree structure, and / or (ii) determine how to process and store data associated with the tree structure, for example, data associated with an item or component.

[0059] Once processed, the tree structure can be used to validate that at least one of the following is part of the tree structure: an item, at least one component of an item, and at least one part of a blockchain transaction (Tx). Blockchain transactions can be used to enable processing, such as verification or storage. Examples of storage and validation techniques are illustrated with respect to Figures 10 to 13.

[0060] Tracking and / or validity checks may involve calculating the hash of each node in the tree structure, where the node's hash is the hash of its concatenated children. To verify that the tree structure has not been tampered with, hashes may be checked by traversing the tree structure upwards. This can be achieved by calculating the hash of each node in the tree, where each node in the tree structure is assigned a unique hash value, which is calculated based on the data stored in the node and the hashes of its children. The hashes of parent nodes may then be compared to the hashes of child nodes, starting from the leaf nodes, and the check traverses the tree upwards, comparing the hash value of each parent node with the hashes of its children. If the hashes match, this indicates that the data stored in the child nodes has not been tampered with. This process may be repeated for all nodes, and if all hashes match, the tree structure is determined to be authentic and untampered with. Overall, the root hash may be used to determine the authenticity of the root node, summarizing the tree structure by comparing its hash value to a trusted hash value previously stored or distributed on a server running, for example, a public or private blockchain.

[0061] In addition, or alternatively, once processed, the tree structure may be used to process and / or store 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) in the allocated resource 1104. The tree structure itself may be stored in the allocated resource. Each leaf and associated data may be stored, for example, for validation, and the hash of the root node 104 of the tree structure may, in addition, or alternatively, be stored, for example, within a blockchain transaction on the blockchain ledger.

[0062] In an example like that shown in Figure 14, the tree structure remains unchanged; that is, items and components maintain the same relationships. In this situation, items and / or components can be associated with at least one blockchain transaction to create a record for the tree structure. In practice, each item and component can be associated with its respective blockchain transaction. The tree structure may be a hash tree, represented by nodes and leaves, and the root hash and / or hashes of at least some of the data associated with the items or components can be recorded on a blockchain, e.g., a public blockchain. In addition, or alternatively, each blockchain transaction associated with each item and component can be recorded on a blockchain, e.g., a public blockchain, either in their original form or hashed. The blockchain transaction associated with an item and / or component, or each blockchain transaction, can be updated when the data associated with the item is updated. In this way, the data associated with an item or component can be tracked. Furthermore, the data can be validated.

[0063] In another example, the tree structure can change over time; for example, the arrangement configuration of nodes and leaves may be updated, which may reflect updates to the status and / or configuration of information associated with an item or component of said item. Similarly, an item and / or component may be associated with at least one blockchain transaction to create a record for the tree structure, for example, each new arrangement configuration being recorded. In practice, each item and component may be associated with its respective blockchain transaction. The tree structure may be a hash tree, represented by nodes and leaves, and the root hash and / or hashes of at least some of the data associated with the item or component may be recorded on a blockchain, for example, a public blockchain. Each time the tree structure changes, the blockchain transaction associated with the item and / or component may be updated. The data associated with an item may be updated and may include updated proof. In this way, the data associated with an item or component can be tracked. Furthermore, the data may be validated.

[0064] Data, such as records, associated with blockchain transactions representing items or components may include proof that allows a third party to determine the validity of the data without knowing the complete tree structure. Proof can be updated whenever a change is made to the tree structure, or when the tree structure is changed. Proof can be used with Simplified Payment Verification technology, for example, to determine the validity of an item or component using blockchain transactions.

[0065] In yet another example, an item or component can be moved from one tree structure to another. Different tree structures may represent different entities, such as physical entities, but the items or components within each structure are essentially the same, even if there is updated data associated with the item or component, such as an association with a blockchain transaction, which is updated or the record of its use or application is modified.

[0066] Figure 15 illustrates a first tree structure 1500 and a second tree structure 1502 having nodes 1402 and leaves 1404. The first and second tree structures represent different entities. A hashed line connects two of their leaves, representing the connection between trees that occurs when a component from a first entity represented by the first tree structure is transferred to a second entity represented by the second tree structure. The tree structure represents a point in time, thereby showing the leaves as part of the history of the tree structure. 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 its components or items in the tree, or each component or item, or the tree structure itself can be tracked and / or validated.

[0067] Figure 15 further illustrates that each tree structure may be recorded in the assigned resource 1104 in accordance with the techniques taught herein with respect to Figures 10 to 13. In addition, or alternatively, data associated with each node 1402 and / or each leaf 1404, such as records, may be stored in the assigned resource.

[0068] For example, X-ray data (components) may be generated from a medical department and held on records of those data within a structured database (items). The structured database may be represented as a tree structure, as taught herein, and may be used to track the database and the items within it. The database and the X-ray data within it may form part of the tree structure, and at least one of the database and the X-ray data may be associated with a blockchain transaction, thereby processing the tree structure 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. Updating a blockchain transaction, such as updating a blockchain token that holds data associated with X-ray data, allows the tree structure representing the patient record to be processed to determine the validity of the X-ray data. Validity may be determined from the transaction history and / or from records holding proof of data validity and / or providence, such as Merkle certificates, within the blockchain transaction representing the X-ray. Validity may be determined for the X-ray that is part of the hospital database from which the data originates, and may also be validated for being part of a patient record. An item or component can be tracked across applications, for example, from end to end. Effectiveness can be determined without compromising privacy, for example, by disclosing complete patient records.

[0069] In another example, the first tree structure represents products manufactured from a production line, and quality control checks, manufacturing date and time, etc., associated with the product, e.g., an airbag in a car, are held in data packets, such as component records, which are part of the production record, i.e., the item, and can be a database of production records. After production, the product may be transferred to a warehouse, and the associated blockchain transaction can be updated to indicate that the product (component) is part of warehouse inventory (item) which has multiple components represented by the second tree structure. Thus, the item and / or at least one component of the item are further associated with a blockchain transaction (Tx) represented in the second tree structure. The blockchain transaction is updated and, in effect, transferred from the first tree structure to the second tree structure. The item and / or at least one component of the item are associated with a blockchain transaction (Tx) represented in both tree structures. The history of the product can therefore be held in records associated with the blockchain transaction. The vehicle's inspection and maintenance history can be represented in a third tree structure, which may include MOT data (government test data), inspection and maintenance data, and details of replacement parts. For example, inventory of replacement parts such as headlights, tires, and airbags may be represented in the tree structure as "items," with each replacement part listed as a "component." When a new airbag is replaced on a vehicle, the third tree structure is updated to include a new node or leaf representing the airbag. As an example, a blockchain transaction holding a data packet for an airbag, i.e., a record of the component, may be included in a blockchain transaction that is updated and associated with the third tree structure as shown in Figure 14(b).A third party wishing to verify the validity of an airbag replacement through the blockchain transaction history and / or records held in the blockchain transaction can process a tree structure representing the vehicle and verify that the airbag is represented in the tree structure and was part of the vehicle. This can be achieved by associating the airbag with a blockchain transaction (Tx) represented in a third tree structure. The record may further hold an index indicating the details of the airbag and / or where the details of the airbag can be found in at least one of the first and second tree structures to which the airbag is associated. Thus, the technology herein enables the tracking of items or components and the subsequent validity verification of those components. This can be achieved from creation to destruction, or from one end of a product's lifecycle to the other.

[0070] Data associated with a blockchain transaction representing an item or component, such as a record, may further include proof, such as a further proof or a second proof, that enables a third party to determine the validity of the data without knowing the complete tree structure or the complete second tree structure, if the item or component is part of another tree structure. A record may include historical data of the item that enables the complete provision to be validated. A record may include proof that a component, such as an airbag, was part of a tree structure for an item, such as a manufacturing facility, warehouse, or vehicle. Proof may include a Merkle proof.

[0071] Figure 16 illustrates step S1600 for processing tree structures 1400, 1500, and 1502. The 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 may be determined from the data associated with it, for example, the relationships between blockchain transactions. In a non-limiting example, the tree structure may be a hash tree, and the items and components within it, and / or their associated blockchain transactions, or parts thereof, may be hashed. At least the hash derived from the hash of the root node of the tree structure may be stored in a blockchain, for example, a public blockchain. Preferably, the hashes derived from each of the nodes and leaves may be stored on the blockchain, for example. The validity of an item or component being part of the tree structure can be verified by proof, for example, a Merkle proof.

[0072] 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. The data may be a hash of the aforementioned information, or at least a part 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 and / or children stored in the node.

[0073] In S1604, the processor processes the tree structure through association with blockchain transactions. These transactions may hold data about items or components in their script. Blockchain transactions may be part of blockchain tokens.

[0074] In S1606, an item or component may be validated as part of a tree structure. This can be done after or before S1608, when processing an item and / or at least one component of an item associated with a blockchain transaction (Tx), and / or storing it within the allocated resource 1104, as represented in the tree structure. Data, such as a record of an item or component, may be validated before being stored, or vice versa.

[0075] The validation technique described herein proposes the use of a hash tree, where the nodes and leaves of the tree are hashed to generate a hash of the tree root. Other techniques may be implemented in accordance with the teachings herein.

[0076] To validate that an item or component is part of a "hash" tree structure, the processor may be provided with data, such as a hash of the item or component, indicating that it is part of a tree structure. For example, someone seeking to prove that an airbag is installed in or replaced in a vehicle may provide a tree structure representing the vehicle, or a part of a structure that can prove the airbag is part of a tree structure. Parts of the tree structure may be provided to maintain privacy. Alternatively, only hashed data associated with other parts of the tree structure may be provided to maintain privacy. Simplified Payment Verification technology can be used for validation.

[0077] Using a tree structure, or a part thereof, the processor can compute the hash of each node 1402 in the tree, and the hash of the node is concatenated with the hashes of its children, including the leaf 1404. The processor can determine that the hashes are consistent as it traverses the tree upwards to the root node to ensure that the tree is valid and immutable. This can be achieved by the processor computeing the hashes of each node 1402 and leaf 1404 and comparing the parent node hashes with the child node hashes. Starting from the leaf node 1404, the processor can traverse the tree upwards and compare the hash value of each parent node with the hashes of its children. If the hashes match, this 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, this indicates that the entire tree is authentic and has not been tampered with. The root hash can also be validated, as it summarizes the entire tree structure.

[0078] Validating a tree structure, and the items or components within it, can be done by comparing the provided data, such as data associated with a replacement airbag in a vehicle, or its hash value, with a previously stored or distributed record in the tree structure.

[0079] Two or more tree structures may be used to validate an item or component by comparing the provided data, for example, data associated with a replacement airbag in a vehicle, or its hash value, with records in first and second tree structures previously stored or distributed, for example, according to Figure 15. Having two or more tree structures can increase the provisionance of an item, which may be beneficial if the item or component has a history spanning two or more applications and corresponding tree structures. The processor can therefore process records of an item or component to validate 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 its tree structure or another tree structure.

[0080] An item, at least one component of an item, and at least a portion of a blockchain transaction, for example, data associated with a record, may include at least one of the following: the tree structure in which the associated blockchain transaction occurred or the history of each tree structure; the history of the allocated resources in which the blockchain transaction was stored; and proof that allows for the validity verification that the item, component, or blockchain transaction is part of a tree structure, for example, a first and / or second tree structure.

[0081] The validity of an item, component, or blockchain transaction can be achieved by comparing it with stored data, such as a manufacturing facility database, warehouse inventory, and vehicle inspection and maintenance records, which can be stored within the blockchain. Data, such as product records, can be used to determine that it is valid and originates from a specific tree structure. The determination can be achieved in a way that limits the validity check to only the minimum necessary for that item or component, thereby preserving privacy. This can preserve the privacy of sensitive information, such as medical records.

[0082] Referring to Figures 13 and 15, as described above, the tree structure or any part thereof can be stored as data, for example, records within 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. This part of the data may be a transaction, for example, an unconsumed transaction output (UTXO) and / or a transaction (Tx) containing a UTXO. Figure 11 and its related description illustrate an example of how data can be used to determine allocated resources.

[0083] The teachings herein are suitable for handling secure and / or confidential data, such as medical records, because they have the ability to validate that an item or component is part of a tree structure without compromising the privacy of other items or components. Furthermore, the means for processing the tree structure is scalable by allocating storage space for at least one of the items or components of the associated blockchain transaction in a pseudo-random manner. Thus, the allocation to resources is load-balanced, which can be implemented by determining a key using at least one of the data associated with the item, component, or associated blockchain transaction. The key may include at least one of alphanumeric and binary numbers. At least one of the data associated with the item, component, or associated blockchain transaction may be parsed to determine the key. For example, the data associated with a component may be hashed and / or parsed to determine the key and the associated allocated resource 1104.

[0084] A record associated with data, such as an item, a component, or at least one associated blockchain transaction, may include at least one of the following: 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 to the block in which the transaction (Tx) is recorded from the hash of the blockchain transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in 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).

[0085] A record associated with data, such as an item, a component, or at least one associated blockchain transaction, may include proof that the associated blockchain transaction is part of a tree structure, by using a path that enables the determination of the hash of the root to the tree structure on which the associated blockchain transaction is recorded, from the hash of the root of the tree structure and the hash of the blockchain transaction.

[0086] record Figure 13 illustrates two transactions derived from blockchain 150. One example of the method described herein is to generate, store, process, access, and maintain 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, for example, with respect to a UTXO database using hash table technology for allocation. Resource 1104 can be one of several resources that make up the database.

[0087] Figure 13 illustrates two Merkle trees constructed using a set of transactions within a block to determine the Merkle root included in the block header. Transactions, Tx n and Tx n+1 Each of these is part of the respective Merkle tree, as will be explained below, at least with respect to Figure 4.

[0088] A record is a transaction, for example, Tx n or Tx n+1 The record includes transaction data for determining that at least a portion of the transaction is included in the Merkle path of blockchain block (B). Either alone or in combination with the examples taught herein, the record holds data that enables efficient and cost-effective referencing and / or retrieval of information associated with a transaction. 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 that at least a portion of the transaction is included in the Merkle path of blockchain block (B). For example, the record holds a Merkle proof that the transaction is part of a Merkle tree that determined the Merkle root of the block in which it is recorded.

[0089] A record can hold a set of data associated with a transaction. A record may include data that is abbreviated and / or concatenated for efficient storage, for example. Information within a record may be structured for reference. For example, a record may include a data catalog. A data catalog may be structured, for example, indexed, to selectively identify and / or retrieve information associated with a transaction. A data catalog may hold a set of transactional data, such as a Merkle certificate that enables Simplified Payment Verification (SPV).

[0090] Records that can include a data catalog may be managed by a resource and / or validator 1106. Records have the ability to hold information that can be stored / associated with a transaction, e.g., a UTXO, for at least one of the following: validity checks, status indicators, retained signatures, and transaction status. For example, a record may include at least a portion of a script that defines an "OP_PUSH_TX" for setting conditions on a transaction. Thus, a record can provide a catalog or library of information associated with a transaction.

[0091] The output of a transaction can be an unconsumed transaction output (UTXO) and / or a transaction (Tx) containing the UTXO of a blockchain block. Records are not limited to the output of a transaction, as suggested by the UTXO and OP_PUSH_TX records, and at least a portion of the transaction (Tx) may include the output, input, and / or any other parameters of the transaction.

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

[0093] Records that can serve as a data catalog may be stored in a database or scattered across multiple databases. The database itself may be distributed across multiple resources 1104. The storage of records, such as information and / or data, as taught herein, can be applied to and / or support the efficient allocation, referencing, and access of records associated with nodes, such as metanet nodes, and associated metanet protocols.

[0094] The following application is incorporated herein by reference in its entirety. - PCT International Application No. PCT / IB2019 / 059793 relating to indexing and structuring nodes. - PCT International Application No. PCT / IB2019 / 059795, which maps categories to mnemonics, for example, to support cataloging. - PCT International Application No. PCT / IB2019 / 059791, which supports the search for placement resources. - Supports wallets, blockchain search systems, block explorers, etc., enabling users to search / access / display / write / retrieve some of the data contained in Metanet nodes, such as transactions, and to identify Metanet nodes based on the Metanet index, PCT International Application No. PCT / IB2019 / 059803. - Supports data partitioning across multiple nodes, as per PCT International Applications PCT / IB2019 / 060226 and PCT International Applications PCT / IB2019 / 059807. - Supports multiple transaction inputs and multiple transaction outputs, particularly the splitting of records across node attributes, as per PCT International Application No. PCT / IB2019 / 059808. - Atomic swap, for example, a conditional exchange established between two or more parties, PCT International Application No. PCT / IB2019 / 059809.

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

[0096] 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 transaction (TX0) to the root of the Merkle tree to blockchain block (B). The Merkle path may include at least the minimum blockchain transactions necessary to prove or verify that blockchain transaction (TX0) is included in blockchain block (B). The records herein provide an efficient and effective means for validating transactions. The allocation and identification of resources on which records are held, and / or combined with the validation techniques herein, provide an improved system for managing and / or using transaction data. Transactions may be derived from blockchain blocks.

[0097] A blockchain transaction (TX0) can be used alone or in combination with at least one further blockchain transaction (TX1) to verify that the blockchain transaction (TX0) is included in the Merkle path of a blockchain block (B). Data items (D) that can be part of a record or information stored within an allocated resource can be at least one of those stored in relation to a script within a transaction and those stored as metadata within a transaction. Together, the record contains validation data necessary to validate a transaction, such as an unconsumed transaction output (UTXO) and / or a transaction (Tx) containing the UTXO.

[0098] Blockchain blocks may be stored on or in connection with the blockchain ledger and / or off-chain storage resources.

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

[0100] 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 resources that hold the previous transaction. The record may hold a history of multiple preceding transactions for unconsumed transaction outputs (UTXOs) and / or transactions (Tx) that contain the UTXOs.

[0101] In this way, the history allows a third party using the records to retrieve the most recent transaction and, if necessary, efficiently identify previous transactions without performing further lookups or searches. The history can provide a back catalog or set of shortcuts to key records, data, or information. The history may include at least one of the following: a set of transaction data for determining Merkle proofs of multiple preceding transactions, or links to the respective assigned resources that processed and / or stored multiple preceding transactions.

[0102] Referring to Figure 13, the first transaction Tx n The second transaction Tx n+1The following is an example. In this example, the first and second transactions have associated records stored in different allocated resources 1104, although they could also be stored at different addresses within the same allocated resource. The record of the second transaction may contain at least a link to the address of the first transaction within the allocated resource. The record of the second transaction may contain at least part of the transaction data record of the first transaction. The record of the second transaction may contain transaction data records for multiple preceding transactions.

[0103] A record can include flags and / or status indicators of transaction data, such as unspent transaction outputs (UTXOs) and / or their inputs or each input of the transaction (Tx) containing the UTXOs. For example, these indicators could be one of "seen," "in-block," and "double-spend," providing an efficient reference to the status of the transaction data.

[0104] A record can hold any number of transaction data information and / or supplementary data, such as validation data. Using a record provides an alternative means of retrieving, identifying, and processing transaction data on-chain. A record can consolidate key data and thus minimize the computational cost when using transactions and performing operations using the blockchain and blockchain blocks. A record may further include at least one of the following: a Merkle tree of the block in which the transaction (Tx) is recorded; a Merkle root of the block in which the transaction (Tx) is recorded; a Merkle path that enables determining the value of the Merkle root to the block in which the transaction (Tx) is recorded from a hash of the transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with the blockchain block; a transaction identifier (TxID) associated with the transaction (Tx) in multiple blockchain transactions within the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); a concatenation of the block identifier (block_ID) and the transaction identifier (TxID); a digital signature; an authentication code; and a signed message for determining the transaction state.

[0105] The allocated resources for processing and / or storing records may be identified and / or allocated using a portion of data derived from the blockchain to identify and / or allocate the resources, the source of which that portion of data is derived, including transaction data, such as unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing the UTXOs.

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

[0107] Using a database involves generating, maintaining, providing, updating, storing, accessing, or processing data in and / or stored within or associated with the database. A record may further include a Merkle path from a transaction (TX0) to the root of the Merkle tree of a blockchain block (B). A Merkle path may include at least the minimum blockchain transactions necessary to prove or verify that a blockchain transaction (TX0) is included in a blockchain block (B).

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

[0109] The aforementioned data item (D) may be stored in relation to a script within a transaction and / or as metadata within a transaction.

[0110] 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).

[0111] The records mentioned above, such as information and data associated with a transaction, derived from or relating to a transaction, may be stored in resources allocated using the methods described below.

[0112] UTXO Database Figures 10 to 12 illustrate, respectively, the stages of how data is derived from the blockchain, the tables used for allocation to resource 1104, and an example of a system for implementing the method. Data is obtained from a peer-to-peer (P2P) network 106 and / or blockchain 150. In s1000, data may be obtained or retrieved, for example, by requesting and obtaining one or more blocks from blockchain 150. Retrieval may include downloading at least a portion of a blockchain block containing multiple blockchain transactions. Retrieving data from a blockchain block, or obtaining it in any other way, for example, by obtaining, copying, or reading data, is necessary if the data relates to unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing the UTXOs, and is historical, e.g., already recorded, transaction data stored and / or processed in block 151. UTXOs currently in the mempool, or future transactions and UTXOs, may be received via a connection to the network, for example, by implementing a node 104 that receives transactions broadcast on the network.

[0113] Therefore, as a whole, the system 1100 in Figure 12 uses a portion of the data derived from the blockchain to determine a key and allocate a corresponding resource to store information associated with the data, such as unspent transaction outputs (UTXOs) and / or information associated with transactions (Tx) that contain the UTXOs. Specifically, the information associated with the data derived 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) that contain the UTXOs. A portion of the data is used to determine a key, which then determines the allocated resource to store information about the data. The data from which a portion of the data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) that contain the UTXOs. In s1002, a portion of the data is used to identify or allocate the corresponding resource 1104, for example, the allocated resource. In s1004, resource 1104 operates to generate, store, and maintain a database of information, which includes data associated with UTXOs and / or transactions. The information may include indications of the validity of UTXOs and / or enable validity to be determined using, for example, SPV technology. Information about the data may include, for example, details of the block from which it was retrieved, such as the block ID, the Merkle path of the unconsumed transaction output (UTXO) and / or the transaction (Tx) containing the UTXO, and the validity status of all UTXOs within the transaction.

[0114] Resource 1104 can store information that may be used by others to validate UTXOs and / or process data to generate instructions, such as flags indicating validity. In addition to or alternatively, resource 1104 can delegate the determination of transaction or UTXO validity in s1006 to validator 1106. A resource may be implemented to store and / or process at least a portion of UTXOs and / or transactions (Tx), and in an allocated resource, for example, resource 1104 actively manages the information and maintains a database associated with each UTXO therein, for example, the resource is self-managed and / or by the allocated resource, for example, the resource acts as a controller and functions as system 1100 which manages sub-resources for storing and / or processing information and / or in relation to the allocated resource, for example, resource 1104 operates as part of system 1100 as shown in Figure 12, and in a non-limiting example, node 104 provides transaction and UTXO information to a switch 1102, for example, a router, which operates to determine which of several resources resource 1104 is assigned the task of generating, holding and / or storing UTXO information in the database. Overall, a resource can implement and perform one or more of the operations of Figure 10. Figure 12 illustrates system 1100 having components that individually perform the operations of Figure 10.

[0115] In one example, the task of holding information associated with a UTXO is assigned to one resource from a group of resources within system 1100. Figure 12 illustrates, for example, eight resources, each of which shares information from UTXOs among itself. However, the system can hold any number of resources and is scalable; for example, the system could have 16, 256, or 1024 resources. Thus, each resource is assigned a range of UTXOs to process, store, and / or maintain.

[0116] Unconsumed transaction outputs (UTXOs) and / or data from transactions (Tx) containing UTXOs can be retrieved and / or received and parsed. Parsing determines which resource is assigned the task of storing the information. Parsing may be performed by resource 1104 or switch 1102. At least one of node 104, switch 1102, and resource 1104 can derive its portion of the data from the blockchain. When parsing is performed by node 104 or switch 1102, the information is directed to the assigned resource. Identification and / or assignment to processing resources and / or storage resources may be performed by nodes and / or switches acting as intermediaries. These are connected to multiple assigned resources, and the node or switch acts as a manager 1104 of multiple resources, determining which resource is responsible for which UTXO / Tx. When parsing is performed by resource 1104, it processes the data and / or stores information derived from the data, or stores data associated with the data, or takes no action if it is not responsible for the UTXO.

[0117] When the allocation of resource 1104 is determined, for example, when it is determined where the information associated with UTXOs / Tx will be stored, resource 1104 can perform the operation of s1004 to generate, store, and / or maintain information associated with unconsumed transaction outputs (UTXOs) and / or transactions (Tx) that contain the UTXOs. Resource 1104 can process the received data to determine the validity of the UTXOs / Tx in s1006, for example, or delegate that task to validator 1106. Resource 1104 and / or validator 1106 can validate at least some of the unconsumed transaction outputs (UTXOs) and / or transactions (Tx) that contain the UTXOs.

[0118] Data retrieved from a peer-to-peer (P2P) network 106 and / or blockchain 150. The data may be retrieved by node 104 and / or switch 1102, which then allocates the data to a resource, or the data may be retrieved by resource 1104 itself, which searches and parses the data according to the allocated range of UTXO / Tx. The retrieved data may include at least one of the following: UTXO identifier, UTXO script hash, or transaction identifier (TXID).

[0119] The retrieved data relates to a UTXO or a transaction containing a UTXO and serves the function of providing a key that identifies and / or assigns to a resource where the corresponding information is stored, maintained, or generated. The key is determined either directly by using a portion of the data, for example, to determine the resource to which the key is assigned, or indirectly by processing a portion of the data, for example, by hashing, so that the resulting hash determines the resource to which it is assigned.

[0120] The key is used to determine which resource 1104 holds the corresponding information associated with the key. Thus, the resource holds a data structure, such as a database or hash table implementing an associative array. In other words, the data associated with the UTXO and / or transaction is used to determine the key, and the key is used to determine the resource that holds the information associated with the UTXO and / or transaction. The data and key not only enable the resource to be allocated, but the stored information can also be retrieved by looking up and accessing the information using the key.

[0121] At least one of the data, key, and resulting hash must contain at least one of the following: alphanumeric characters and binary numbers. This number is used to determine the allocated resource.

[0122] For example, a portion of the data may include unconsumed transaction outputs (UTXOs) and / or transactions (Tx) that contain the UTXOs. Input to a transaction includes a transaction ID that refers to the transaction containing the UTXOs to be consumed, an output index, e.g., Vout, that identifies which UTXOs are referenced for that transaction, a scriptSig that satisfies the conditions imposed on the UTXO to unlock it, and a sequence number.

[0123] Potential recipients of a UTXO must validate the UTXO before the transaction consuming the UTXO is compiled and broadcast. Known techniques for validation are slow, resource-intensive, and computationally expensive. Some of the data from the UTXO and / or associated transaction information that validates the UTXO can be stored in a resource. A key is often determined by using some of the data specific to the UTXO, which then determines which allocated resource the associated information is stored in and from which it can be retrieved.

[0124] As a non-restrictive example, using a Transaction ID (TxID), which is typically referenced in hexadecimal form but can also be represented as a binary number, Figures 11(a) through 11(d) are tables illustrating how parts of the data can be used to determine the allocated resource. Parts of the data, such as a TxID, can be directly parsed or processed, for example, by hashing. In Figure 11(a), the TxID is parsed so that the first three digits of the TxID in binary form are selected as the key, and the resource allocated according to the information associated with the TxID having a binary value, for example, a binary value with "101" as the first three digits, is allocated for storage / processing at the allocated resource "6". While using the first three digits of a binary value allows determining one of eight resources, Figure 11(c) shows how taking the first four digits of a TxID in binary form supports assignments between 16 resources. For example, information associated with a TxID starting with a binary value of "1011" as the first four digits is assigned for storage / processing of the assigned resource "12". Alternatively, the hexadecimal value of a TxID can be used as shown in Figure 11(b), where a single hexadecimal value maps to a resource, e.g., from "c" to "13". In Figure 11(d), a range of hexadecimal values ​​is assigned to resources, e.g., information associated with a TxID starting with "76" is assigned to resource "8".

[0125] Alternatively, since some of the data may be processed to generate hexadecimal or binary numbers, and thus hashed, for example, the subsequent determination of the key for identifying / assigning some of the data and resource 1104 is not limited to TxID.

[0126] A portion of the data selected from a transaction or its UTXO, or a processed value such as a hash value, is pseudo-random. Allocation to resources is load-balanced; that is, a portion of the data used to determine the key for allocating resources is pseudo-random, distributing processing and / or storage across multiple resources. Information associated with a transaction / UTXO will be distributed across multiple resources. Balancing allocation across resources minimizes the risk of some processing resources being idle while others become overloaded, and therefore the risk of performance degradation or even failure. The resilience, performance, and / or efficiency of system 1100 are improved.

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

[0128] A portion of the data is derived from the blockchain to determine the keys and the corresponding resources that store the information associated with the data, namely the unspent transaction output (UTXO) and / or the information associated with the transaction (Tx) that contains the UTXO.

[0129] An actor seeking validation of a UTXO's validity may identify a resource holding information that can be used to determine the validity of the UTXO and / or the transaction holding the UTXO, using a portion of the UTXO and / or the transaction holding the UTXO. This information may include flags or associated markers indicating whether the UTXO is locked or unlocked, for example, invalid or valid, or suitable for inclusion in a subsequent transaction. In addition to or alternatively, the information may include records of the UTXO and / or the transaction holding the UTXO, enabling the actor to efficiently and independently validate the UTXO.

[0130] The record includes, at least in part, a Merkle tree of the block in which the transaction (Tx) is recorded, a Merkle root of the block in which the transaction (Tx) is recorded, a Merkle path that enables determining the value of the Merkle root to the block in which the transaction (Tx) is recorded from the hash of the transaction (Tx), a Merkle proof, a block identifier (block_ID) associated with the blockchain block, a transaction identifier (TxID) associated with the 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).

[0131] The resource may include information and records necessary to determine the validity of the UTXO. Additionally or alternatively, the resource may generate records that validate the UTXO and / or support the validation of the UTXO, either by itself or via validation s1006 by validator 1106. Resource 1104 and / or validator 1106 may perform at least one of the following: validate and / or verify the UTXO; perform at least part of the Simplified Payment Verification (SPV) process on the UTXO; determine whether a given blockchain transaction (Tx) is contained within a blockchain block; generate at least one hash of the blockchain transaction, use that hash to construct a Merkle path, and / or check whether that hash matches a transaction identifier (TxID) in the header of a blockchain block; or determine a Merkle proof for the UTXO.

[0132] An efficient and scalable alternative method for validating UTXOs is provided by providing a means to identify resource 1104 allocated from a UTXO / transaction and by storing the information necessary to validate the UTXO in said resource. Nodes no longer need to hold a complete copy of the blockchain, and additional information is no longer required to support transactions, such as SPV-based exchanges and wallets, and system 1100 and its resource 1104 provide fast and scalable support.

[0133] Overall, the system 1100 includes a resource 1104 that operates to provide a UTXO repository for generating, storing, and / or maintaining information and / or records associated with multiple unspent transaction outputs (UTXOs) associated with each transaction (Tx) in multiple blockchain transactions (TX) of a blockchain block. The resource can record, retrieve, and / or process information and / or records by using a portion of data derived from the blockchain to identify and / or assign the resource, the data from which a portion of the data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) that contain the UTXOs.

[0134] System 1100 may include a node 104 and / or switch 1102 for receiving and / or processing unconsumed transaction outputs (UTXOs) to be included in a transaction. The node and / or switch can support resources and determine the allocation to one of several resources. The allocated resource then holds validity confirmation data for the UTXO, such as information and / or records.

[0135] For example, after receiving a UTXO to be included in a transaction as part of a payment or transfer of digital assets, validity confirmation information and / or records may be requested and / or retrieved by the actor from the assigned resources.

[0136] When an actor accesses information and / or records from an assigned resource, the actor may perform at least one of the following: validate the UTXO and / or the transaction (Tx) containing the UTXO, and / or determine the validity of the UTXO and / or the transaction (Tx) containing the UTXO. Validation by at least one of resource 1104, validator 1106, and actor may include validating and / or verifying at least one blockchain transaction, and / or ii) performing a Simplified Payment Verification (SPV) process, and / or iii) determining whether a given blockchain transaction (Tx) is contained within a blockchain block, and / or iii) generating at least one hash of the blockchain transaction, using the hash to construct a Merkle path, and / or checking whether the hash matches a transaction identifier (TxID) in the header of a blockchain block.

[0137] Subsequently, following the validity check of the UTXO, the actor or any further actor may prepare and / or transmit a transaction (Tx) having the UTXO as input.

[0138] Node 104 may 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 and / or storage resources. The data from which a portion of the data is derived includes unconsumed transaction outputs (UTXOs) and / or transactions (Tx) that contain the UTXOs.

[0139] Block effectiveness verification Traditionally, nodes within a blockchain network maintain a global ledger of all transactions on the blockchain. The global ledger is a distributed ledger, and each node may store a full or partial copy of it. Transactions made by nodes that affect the global ledger are verified by other nodes, thereby maintaining the validity and integrity of the global ledger. The details of blockchain network implementation and operation will be understood by those skilled in the art.

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

[0141] As described above, in one or more exemplary blockchain networks and protocols, mining nodes participate in a competition to create the next block in the blockchain. To assemble a block, miners construct it as a set of transactions from a pool of unconfirmed transactions ("mempool"). Miners then attempt to complete a Proof of Work (PoW) puzzle with respect to the assembled block. If a miner manages to complete a PoW before receiving notification that another miner has successfully generated its own block and completed its PoW, the miner propagates by sending its block to peer nodes on the network. Those nodes validate the block and then send it to other nodes on the network. If a miner receives notification that another block is completed before it has finished its PoW, the miner abandons its work and begins attempting to construct the next block.

[0142] Therefore, faster block propagation helps avoid wasted effort (and associated energy) on behalf of miners and validation nodes. By providing a solution that enables faster block validation and thus propagation, the present invention provides enhanced network performance. It reduces the amount of computation time and effort required, and therefore the amount of energy required for the network. This provides a more resource and time-efficient network. This ultimately provides an improved (blockchain) network.

[0143] In several exemplary blockchain implementations, each node receiving a block first validates it before sending it to other nodes. If the validation process takes time, the propagation of blocks across the network will be slow. While some blockchain implementations, including evolutions of existing protocols, provide block validation by only a subset of nodes rather than every node in the network, it should be noted that block validation by most nodes is still likely a characteristic feature of blockchain implementations that prevents invalid blocks from propagating across the network.

[0144] Validating a block involves verifying that the block meets the specified criteria set by the applicable blockchain protocol. Exemplary criteria applicable to one or more protocols may include functions such as CheckBlock and CheckBlockHeader. In addition to verifying that the block itself conforms to the specified criteria, each transaction within the block may be evaluated for conforming to transaction-level criteria. For example, transaction-level criteria applicable to one or more exemplary protocols may include the functions AcceptToMemoryPool, CheckTransaction, and CheckInputs.

[0145] Specific examples of block-level criteria based on one or more known protocols may include the following: • Block data structures are syntactically valid. • The block header hash is less than the target difficulty (enforcing proof of work). • The block's timestamp is within two hours of the future (allowing for a time margin of error). The block size is within the acceptable range. • The first transaction (and only the first transaction) is a Coinbase-generated transaction. · All transactions within a block are valid.

[0146] Specific examples of transaction-level criteria based on one or more known blockchain protocols may include the following. · The syntax and data structure of a transaction must be correct. · The list of inputs or outputs must not be empty. · For each output value x, and indeed the total of all outputs, it must be within the range of 0 < x < 21·10 6 . · None of the inputs have a NULL hash. · nLockTime is less than or equal to INT_MAX. · The transaction size in bytes is above the minimum value and below the maximum value. 1]· The number of signature operations is less than the signature operation upper 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 within any other transaction in the pool, that transaction must be rejected. · For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY (100) confirmations. · For each input, the referenced output must exist and must not already have been consumed. · Use the referenced output transaction to obtain the input value, and check that each input value, and indeed the total, is within the acceptable range of value x, i.e., 0 < x < 6 6 . · There must be no matching transactions within the pool or within the blocks on the main branch. · The total of the input values must be greater than or equal to the total of the output values. • The transaction fee must be sufficient to enter an empty block. • The unlock script for each input must be verified for validity by comparing it with the corresponding output lock script.

[0147] These exemplary criteria are illustrative, and the prescribed criteria may differ in different protocols and may change over time for a given protocol if changes are made to the protocol; therefore, they should not be interpreted as sufficient or necessary for all embodiments. In general, transaction-level validity criteria are prescribed characteristics that a transaction must possess in order to be considered valid under the applicable blockchain protocol. Similarly, block-level validity criteria are prescribed characteristics that a block must possess in order to be considered valid under the applicable blockchain protocol.

[0148] This application describes a method and device for speeding up block validity verification to facilitate faster propagation of blocks in a network.

[0149] In one embodiment, the application describes a node structured 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 cannot be evaluated in parallel. For example, the uniqueness of a UTXO may be evaluated on a serial basis. In such cases, the distributed validation node of the Disclosure may be structured or configured to validate the uniqueness of the reference input (UTXO) of a transaction prior to allocating a set of transactions among two or more sets of parallel processors for validating the remaining transaction-level criteria.

[0150] 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 is known in the art, a tree structure can be decomposed into smaller trees (which may be referred to herein as “segments,” “subsets,” or “parts” of the tree), each segment containing 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 the distributed and parallel processing of related data records across multiple processing resources.

[0151] In our exemplary embodiment, multiple data records include blockchain transactions that are relevant, as they form nodes in a Merkle tree. The Merkle tree has a root that is included in, or may be included in, the block header of the transactions according to the blockchain protocol, and the root provides a path that can be traversed to all leaves (i.e., transaction IDs (TxIDs)) in the tree. In our example, the blockchain protocol is the Bitcoin protocol or a derivative thereof, but other protocols are also included in the scope of this disclosure.

[0152] For example, processing multiple transactions involves validating at least a portion of a blockchain block containing multiple blockchain transactions, and the Merkle tree root to that block. These examples are non-limiting, and the technologies disclosed herein may be used with respect to non-blockchain-related data and / or other processes other than validation. For example, embodiments may be used to store, structure, retrieve, and / or maintain any type of data record that can be represented in a Merkle tree. Databases and other known storage resources may be used instead of, or even in conjunction with, a blockchain ledger.

[0153] 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 to that block.

[0154] For completeness, with reference to Figures 3 and 4, we present a detailed explanation of Merkle trees and their use in representing blocks of blockchain transactions.

[0155] Merkle Tree Referring to Figure 3, a Merkle tree is a hierarchical data structure that allows for the secure validation of a collection of data. In a Merkle tree, each node in the tree is given an index pair (i,j) and is represented as N(i,j). The indices i and j are simply numerical labels relating to a particular location in the tree.

[0156] A characteristic of Merkle trees is that the structure of each node is expressed as an equation.

[0157]

number

[0158] It is something that will be decided by Here, H is a cryptographic hash function.

[0159] An example of a binary Merkle tree formed according to these formulas is shown in Figure 3. As illustrated, when i=j, it corresponds to a leaf node, which is simply the i-th data packet D i It can be seen that this is a hash. If i ≠ j, it corresponds to an internal or parent node, which is generated by recursively hashing and concatenating the child nodes until one parent (Merkle root) is found.

[0160] For example, node N(0,3) is constructed from four data packets D0, ..., D3 as follows: N(0,3) = H(N(0,1)∥N(2,3)) =[H(N(0,0)∥N(1,1))∥H(N(2,2)∥N(3,3))] =[H(H(D0)∥H(D1))∥H(H(D2)∥H(D3))]

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

[0162] For Merkle trees in some known blockchain implementations, the hash function is double SHA256, which is the standard hash function SHA-256 applied twice. H(x) = SHA256(SHA256(x))

[0163] The main function of a Merkle tree is to handle a data packet D i N data packets D∈{D0,...,D N-1The task is to verify that something is a member of a list or set. The mechanism for verification is known as a Merkle proof, and given a data packet D i This involves obtaining a set of hashes known as the Merkle route to the Merkle route R. A Merkle proof for a data packet is simply the minimum list of hashes needed to reconstruct the route R by repeatedly hashing and concatenating, and is often referred to as the "certificate of authenticity".

[0164] Proof of existence is that all packets D0,...,D N-1 This can be performed trivially if the order is known to the prover. However, this requires a much larger storage overhead than the Merkle proof, and further requires that the entire dataset be available to the prover. A comparison of using the Merkle proof versus using the entire list is shown in the table below, where we use a binary Merkle tree and assume that the number of data blocks N is exactly equal to an integer power of 2.

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

[0166] [Table 1]

[0167] In this simplified scenario—where the number of data packets is equal to the number of leaf nodes—we found 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 involving log2N hashes than to store N data hashes and compute an explicit proof.

[0168] Given a Merkle root R, the ordered list D ∈ {D0,...,D} represented by the data block D0 in R is D N-1 If you want to prove that something belongs to}, you can perform a Merkle proof as follows: i. Obtain 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 Γ, we compute the Merkle proof as follows: a. Hash the data block N(0,0)=H(D0) To obtain. b. Concatenate with N(1,1) and hash it. N(0,1)=H(N(0,0)∥N(1,1)) To obtain. c. Concatenate with N(2,3) and hash it. N(0,3) = H(N(0,1)∥N(2,3)) To obtain. d. Concatenate with N(4,7) and hash it to form a root. N(0,7)=H(N(0,3)∥N(4,7)), R'=N(0,7) To obtain. e. Compare the calculated square root R' with the square root R obtained in (i). 1. If R'=R, then the existence of D0 in the tree, and therefore the dataset D, is confirmed. 2. If R'≠R, the proof fails and it is not confirmed that D0 is a member of D.

[0169] 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 publicly available as part of the block header, it can be quickly proven that the transaction was included in that block.

[0170] SPV Simplified Payment Verification (SPV) cleverly utilizes these features of the Merkle tree, as first demonstrated in Section 8 of Satoshi Nakamoto's 2008 white paper, "Bitcoin: A Peer-to-Peer Electronic Cash System." In the SPV-based token exchange between Alice and Bob, both use the same type of SPV wallet. An SPV wallet stores the user's private and public keys, unspent transactions, and a block header that uniquely identifies the block, thereby allowing it to be placed on the blockchain. As described, the block header includes data fields that provide a unique summary or fingerprint of the entire block's contents, as well as fields that provide the Merkle root to that block. The Merkle root is generated by repeatedly hashing pairs of transaction IDs (TxIDs) from the block until a single hash is eventually reached. The Merkle root provides an efficient and secure mechanism for verifying that a transaction is part of a block, because it allows users such as wallets and merchant nodes to verify specific transactions locally without downloading the entire blockchain. This is advantageous for users who do not need or do not want to run a full node but simply need to perform a local check to see if a particular transaction is in a particular block, such as merchants and customers who want to execute a transfer between them. In summary, SPV allows such users to search a Merkle tree with a given root and check (i.e., verify) whether a particular transaction is contained within a particular blockchain block without having to download and store the entire blockchain.

[0171] Therefore, SPV wallets only need to verify that a transaction is validated, rather than performing a full check of the blockchain like other forms of wallets (hence the name "simplified payment verification"), thus offering the advantage that power and storage-constrained devices such as mobile phones and laptops can operate within the blockchain ecosystem. Since SPV wallets download only the block header without including any of the transactions, this significantly reduces the storage, energy, and processing resources required for verification. SPV wallets are particularly well suited for use with embodiments of this disclosure for the reasons described below, and the term "verification" is used herein to include SPV checks.

[0172] Transaction block Figure 4 illustrates an example of a blockchain block. Each block contains a block header and a set of transactions. The block header includes, among other things, a hash of the previous block header, i.e., a hash of the block header based on when the current block was constructed. The block header also includes the Merkle root of the Merkle tree constructed using the set of transactions. Each transaction is first hashed (e.g., double hashed) to generate a transaction identifier (TxID) for that transaction. The transaction identifier is then used as a leaf node 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 a single hash remains, the Merkle root. This Merkle root is sometimes referred to as the block Merkle root.

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

[0174] Segment identification of a block Merkle tree Suppose a specific party, for example Alice, wants to validate several transactions. According to one embodiment of this disclosure, at least one subset of transactions is identified, and the subset forms and / or is represented by a segment of the entire Merkle tree for its block. Thus, a block of transactions may be logically segmented into multiple segments based on the Merkle tree of the block, each segment containing a subset of transactions in the block, and each segment having its own root node (or “root hash”). This common root hash is sometimes referred to below as the “segment hash” to distinguish it from the root hash of the entire block. Transactions at the same level within a tree segment (i.e., the lowest level, sometimes also referred to as the “leaf level” or “leaf layer”) are siblings. All transactions within a given 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, a common root node can belong to any level of the Merkle tree between the lowest level and the Merkle root.

[0175] Dividing a block into smaller parts based on its Merkle tree offers significant technical advantages, including the ability to quickly and efficiently allocate transactions among multiple validators. For example, certain exemplary blockchain protocols use binary trees, making it possible to implement binary allocation across multiple machines. By using small binary markers as an indexing system for segments, the position of each segment within the overall Merkle tree can be quickly calculated, allowing segments to be put back together after validation is complete, thus reconstructing the complete Merkle tree for the block. This binary indexing approach will be discussed in more detail later.

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

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

[0178] Figure 6 illustrates another example showing how a Merkle tree can be divided into 602 parts. The Merkle tree in Figure 6 is the same as that 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, the common internal node 604 belongs to the third level of the Merkle tree. The Merkle trees in Figures 5 and 6 could also be divided into more (e.g., 16) or fewer (e.g., 2) parts 502,602. In general, a Merkle tree formed from a set of transactions in a block may be divided into any number of parts 502,602, each part containing at least two transactions.

[0179] Assignment of segments to each effectiveness verification resource A subset of transactions, following their identification, is distributed across multiple validation resources, which may also be referred to as “validators” for easy reference. These multiple validators are shown in Figures 7 and 9 as resources A through D (704a through 704d). The allocation process may be directed or influenced by, but is not limited to, dedicated units such as component 904, as shown in Figure 9.

[0180] Each validator (704a to 704d) may contain one or more processing resources. Therefore, at least one of the validators (704a to 704d) is or may contain at least one of the following: one or more virtual machines, one or more servers, one or more GPU-based computing resources, one or more threads, and / or one or more multiprocessor systems. Essentially, any of the validators consists of any type or combination of processing resources and can validate one or more transactions that are related to each other by segments of the Merkle tree in each block. The validators (704a to 704d) and other system components form a collective resource or entity 700, which is referred to as a “(distributed) validation node”.

[0181] Preferably, distribution includes assigning each of the segments to each validator in a plurality of validators. The validators are at least, • Operate the one-territory transaction that constitutes the allocated segment. • Validate one or more transactions to verify that they conform to the blockchain protocol, and / or • Verify the validity of the transaction, such as verifying that it can be identified in an existing repository, such as a blockchain ledger or a database of known, registered, or consumed transactions. It can be arranged and configured in this way.

[0182] The activities of validators, and the assignment of subsets to different validators, can be directed by a controller. Figure 7 shows how controller 702 assigns subsets of transactions A through D to each tree segment to validators 704a through 704d, respectively. The system-level controller 702 can coordinate the activities of systems or devices 704a through 704d within the distributed validation node and control or influence tasks such as identifying tree segments by the Merkle tree of a block, assigning identified segments to each validator, reordering validated tree segments into a complete Merkle tree for the block, and / or ordering transactions within the reconfigured block.

[0183] One or more of these 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 through 704d may include at least one controller component of their own. This lower-level controller may influence or direct operations such as assigning tasks or subtasks to one or more processing resources within the validator, reconstructing a Merkle tree for a given segment, or interacting with other system components, such as other validators or higher-level controllers, UTXO pools, wallets, etc. Subsequently, the processing resources themselves may be further broken down into smaller systems, one or more of which may include a controller and one or more processing resources of their own. In this way, the system may include a hierarchical architecture in which segment validation is performed by validation entities, one or more processing resources for performing validation tasks, and one or more controllers for coordinating processor activity and performing inter-component communication.

[0184] In embodiments where the validator includes multiple processing resources, the validator may divide its allocated segment into smaller segments. The validator's controller can then distribute these subsegments across the processors under its control. In this way, the validation process can be implemented in both hierarchical and distributed manner.

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

[0186] Therefore, this disclosure enables many transactions to be processed simultaneously, with the only limitation being the number of hardware units available to form distributed validation nodes, rather than the available processing speed which becomes a bottleneck as in conventional technologies. This allows the blockchain processing system to scale horizontally without requiring any modification of the underlying protocol of the blockchain network.

[0187] Accordingly, this disclosure presents a significant departure from conventional approaches to validation, 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 involve the conventional view that one block is validated as an entire entity, and that the validation node (see 104 in Figure 1) is a single computing unit. In contrast, embodiments of the disclosure divide the Merkle tree into multiple segments given to different validators (704a to 704d in Figures 7 and 9), and each segment and validator can be further divided to increase the degree of distribution involved.

[0188] Furthermore, by dividing each block into segments based on its Merkle tree, embodiments of this disclosure enable validators to access, download, and process smaller portions of a block rather than the entire block. Recall that transactions within each segment (in pairs) are hashed up to a single root value. This means that segments can be validated using only the relevant transactions required, rather than the entire block being downloaded, stored, and processed as a whole. As some blockchain protocols allow for scaling of block size and inclusion of larger blocks in the ledger, the traditional model of downloading the entire block becomes a bottleneck. Embodiments of this disclosure resolve this challenge to blockchain scalability by enabling individual validators to receive and process only the (smaller) portions relevant to them. This results in reduced overall validation time, improved blockchain networks, and improved applications running on the blockchain.

[0189] Furthermore, the embodiments support and facilitate the use of SPV processes and resources because such SPVs involve local validation of only the portion of the Merkle tree of interest to a given party. Therefore, the pruning nature of SPV technology makes it ideal for use in combination with embodiments of the present disclosure. In an SPV context, validators may be given only the portion of the block data they require, namely the block header or segment root node and associated transactions.

[0190] When each validator performs a check and verifies the validity of the segment it has processed, the validity of the block can be guaranteed due to the hash mechanism used to generate the tree.

[0191] Load balancing across multiple validators Load balancing techniques and systems are known in the art and are configured to evenly distribute tasks among multiple resources to improve efficiency. The goal is to minimize the risk of some processing resources becoming idle while others become overloaded, thereby reducing performance and potentially leading to failure. Therefore, load balancing is crucial for ensuring the overall resilience, performance, and efficiency of the system. Embodiments of this disclosure may utilize any known load balancing technique, such as static or dynamic load balancing. Alternatively, the load balancing approaches disclosed herein may be advantageously used.

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

[0193] 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. A Merkle root is generated by hashing pairs of transaction IDs (TxIDs) from a block together to produce each internal node (or internal hash) of the Merkle tree, and then repeatedly hashing adjacent internal hashes until a single hash is reached. This double-hash Merkle root provides an efficient, fast, and secure verification mechanism. This also brings the advantage that, in the current context, double hashes generate random binary numbers. Each internal hash containing each segment hash is itself a double hash. Therefore, we can use the first x leading digits of a segment hash as an assignment index. A hash with four leading zeros would, as a result, assign the tree segment to the validator with ID 0000, a hash with leading digit 0001 would, as a result, assign it to the validator with ID 0001, and so on. The random generation of double hashes ensures the random distribution of tree segments to validators.

[0194] Double hashing is typically used when generating a Merkle tree, but it is not required in all examples; instead, single hashing alone may be used. In practice, no matter how many times the hash operation is performed, a random binary number is generated. The load balancing task may be performed by a dedicated system component, shown as 905 in Figure 9, or it may be provided elsewhere within system 700, or it may be provided in relation to and communicating with system 700.

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

[0196] Each validator is assigned a segment of the Merkle tree based, for example, on the allocation index described above. Any given validator then operates to download a set of transactions that make up its allocated tree segment. This may involve downloading the transaction set from the blockchain itself (e.g., from blockchain nodes) or from different resources or entities, such as third-party service providers. The transaction set may be downloaded to the validator's internal memory or to a shared storage location, such as a shared drive in the cloud.

[0197] A distributed node may require a complete block, i.e., the entire set of transactions that make up the block. In this case, each validator assigned a tree segment downloads a subset of the transactions that make up the segment. In other scenarios, a distributed node may only require a specific part of a block. In this case, only some of the validators may need to download each subset of transactions to obtain the desired transactions.

[0198] Downloading blocks (or parts of blocks) in this manner speeds up the overall download because each validator only needs to process a subset of the transactions that make up the block. This is in contrast to traditional block downloads, where a given entity (e.g., a full node) must download the entire block by, for example, downloading each transaction in the order in which they appear within the block. Therefore, blocks are downloaded in parallel by multiple validators. A single block can contain tens of thousands, if not several orders of magnitude, of transactions. For a single entity to download this many transactions consumes significant resources and takes considerable time. The computational load is distributed among validators, so that each individual validator consumes only a small fraction of the processing resources. Similarly, the overall time it takes to download a block is also reduced.

[0199] As described, each validator may download a subset of transactions. These subsets can then be combined to reconstruct blocks within a single storage location. ("Single storage location" means either a self-contained storage resource or multiple associated storage resources forming a collective entity.) To do this, individual validators may transmit their respective subsets to a central controller of distributed nodes configured to arrange and configure transactions in the correct order. For this purpose, segment hashes (i.e., hashes linking tree segments) may be used. For example, a mapping of segment hashes to their positions within a Merkle tree, e.g., from left to right as the segment hashes appear in the Merkle tree, may be maintained. The subsets of transactions can then be arranged in order (e.g., from first to last) based on their corresponding segment hashes.

[0200] In some embodiments, individual validators (or the entire distributed node) may verify that the correct transactions have been downloaded (or that the transactions have been downloaded correctly) by reconstructing the Merkle tree. After downloading a subset of transactions, validators may 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 may verify that the candidate segment hash is a hash of the Merkle tree. If the hashes do not match, an error occurred during the download. In some examples, each validator may generate a candidate segment hash and send it to a controller for verification. In another example, a candidate block Merkle root may be generated based on the entire set of downloaded transactions. Again, the candidate Merkle root should match the actual block Merkle root (i.e., the Merkle root stored in the block) if the block was downloaded correctly.

[0201] In some cases, validators may validate downloaded transactions using the techniques described above. That is, each validator is assigned a tree segment, downloads a corresponding subset of transactions, and validates those transactions. In other cases, validators do not necessarily need to validate transactions; they may simply download them for later use, for example, to send to a third party.

[0202] Distributed UTXO pool Preferably, each validator 704 constituting part of the 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, or unconsumed, outputs associated with blockchain transactions. Thus, each validator's UTXO pool is based on and constructed from transactions assigned by the controller with respect to Merkle tree segments. In one embodiment, this may be a (graph) database containing data relating to unconsumed UTXOs of transactions assigned to a given validator for processing. For each UTXO, a record is created in the database that the validator will become aware of when a new Merkle tree segment is assigned. Thus, from the perspective of the distributed validation node, the UTXO pool consists of multiple different UTXO pools, each containing a different set of UTXOs, provided at or on different validators. Thus, the UTXO pool for the nodes is distributed in both the data and the resources that store and / or process it.

[0203] This represents a significant departure from the traditional UTXO model, where each full node in the network has 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, each having its own UTXO pool, which is a subset of the entire UTXO set on the blockchain. Each validator's UTXO pool contains the UTXOs of transactions that constitute the sub-part of the Merkle tree to which validation is performed.

[0204] Following such an approach, it can be implemented in a manner similar to an SQL transaction log, in that every time a new block needs to be validated, all commands, events, and items related to the database are logged. The term “database log” is used herein to avoid confusion arising from the use of the term “transaction,” as is known in relation to blockchain, but we use the term “database log” to include 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).

[0205] The use of ordered, historical database logs means that the entire UTXO pool can be constructed by executing the log history in its original order. Advantageously, this ensures that a copy of the database can always be (re)generated when needed, and that separate copies of the data do not need to be stored. Data integrity is ensured, and fewer storage resources are required. Each UTXO pool can be stored, maintained, and processed independently. Also advantageously, if you are working with pruned portions of the Merkle tree using SPV technology, SPV technology facilitates the creation of separate UTXO databases for each validator.

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

[0207] Structuring transactions in this way provides a fast and efficient lookup mechanism. Transactions can be sorted by block_ID so that 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 the transaction's UTXO has been consumed), the validator can locate the transaction in the database by first looking up the corresponding block_ID and then the corresponding TxID. This has the effect of limiting the search to the relevant section of the database. This efficiency reduces the time, processing resources, and energy required for the search operation, resulting in a significant improvement over prior art.

[0208] A flag or marker is associated with each UTXO in the validator pool and indicates whether the UTXO is locked or unlocked. For convenience, we sometimes refer to this flag or marker as the “lock flag”. When a UTXO is marked “locked”, this acts as an indicator to validators within the group (i.e., elsewhere in the distributed validity verification nodes) that this UTXO is not available for consumption. Conversely, when a UTXO is marked “unlocked”, this acts as an indicator to validators that the UTXO can be consumed. This therefore allows validators assigned to verifying a transaction that consumes a UTXO to signal to their peers that the UTXO has been redeemed, and therefore is no longer available, assuming the transaction has been proven valid. The “locked” state means that consumption is permitted, while the “unlocked” state means that consumption is prohibited.

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

[0210] During use, the validator inspects the output of each new transaction assigned by the controller. Any unconsumed output (UTXO) is added to the validator's UTXO pool, i.e., recorded as an entry in the UTXO database. In the associated database record for each new UTXO, the lock flag is set to "unlocked".

[0211] When a validator sees that a UTXO is being consumed by a newly allocated transaction, it sends a message to all other validators in a group of validators informing them that this UTXO should also be locked in their respective pools. Essentially, a validator sends a message to its peer indicating that it has seen consumption by a transaction with a specific hash ID at a specific time. Other validators do not need to receive the complete data for the entire transaction, as the transaction hash and the list of UTXOs it consumes are sufficient for them to identify the transaction they are interested in and mark it as locked in their own database. Upon receiving the message, each receiving validator checks whether the UTXO they are interested in is in their UTXO pool. If so, the state of the lock flag is changed to "locked". Thus, the lock prevents the validator from allowing the same UTXO to be consumed by a subsequent transaction. If a new transaction attempts to consume the same UTXO, the lock flag check indicates that the second attempt should be ignored. If the validator that sent the message determines that the validity check failed and therefore the UTXO has not been consumed, it may send a further message to its peers indicating that the lock flag for the UTXO should be changed to the "unclocked" state. After valid consumption is complete, a message to that effect is sent, and the locked UTXO may be removed from the associated UTXO pool.

[0212] In the embodiments described above, each validator has a single UTXO pool, which contains the UTXOs of all transactions in all the tree segments to which it is assigned. However, in an alternative approach, the UTXO pool maintained by each validator may be divided / partitioned / compartmentalized / formed into multiple subpools, one per block. In this way, a single UTXO pool may be organized into a logical hierarchy. In yet another approach, one or more validators may be arranged and configured in relation to each of multiple UTXO pools, each of which is related to UTXOs for one or more sets of tree segments. Thus, in some embodiments, validators may organize UTXOs into separate UTXO pools for different individual tree segments, or according to predefined criteria such as the type of tree segment, or tree segments within a given range. In such embodiments, the identifier may include a block ID that can be used to narrow down a search against the relevant UTXO pool, and the search can then proceed within that pool to identify (attempt to identify) the relevant transaction by its TxID. Those involved will understand that in some embodiments, a mixture of these approaches can be used, namely, one or more validators within a distributed node may employ a single UTXO pool approach, while others may be arranged and configured to use multiple, separate UTXO pools, and / or UTXO pools organized into subpools, or any combination thereof.

[0213] This provides protection against "double-spending" situations where parties attempt to use the same UTXO twice. It offers a simple and secure locking mechanism that operates efficiently and quickly, regardless of the number or location of validators in the system, and maintains the security and integrity of transactions implemented on the blockchain.

[0214] Exemplary System of Possible Embodiments Figures 7 and 9 illustrate exemplary systems 700 for implementing at least some of the embodiments described. Figure 8 illustrates a flowchart of exemplary steps that may be taken in a high-level view of the method of this disclosure.

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

[0216] As shown in Figures 7 and 9, the system 700 includes a control entity 702 (or simply "controller") and a number of validation resources 704, also referred to herein simply as "validators." Although only four validators 701a-d are shown in Figure 7, the system 700 can generally include any number of validators. Furthermore, although the controller 702 is shown separately from the validators 704 in Figures 7 and 9, this does not preclude the controller 702 from including or being composed of one of the validators 704. As described above, each validator may include one or more processing resources and its own controller for coordinating its own internal activities. There are no technical or logical limitations on the level of hierarchy that can be implemented in this way. However, Figure 7 shows only one (topmost) level of such hierarchy for simplicity and ease of understanding.

[0217] As shown in Figure 7, the controller 702 receives a set of transactions. Transactions can be received from sending resources across electronic channels or networks. The sender can be any entity, internal or external to the system organization, that wishes to perform some kind of validation check, as described above. For example, this could be a full node on the blockchain network, such as node 104 in Figure 1, or a digital wallet, or a merchant / SPV node that wishes to perform local checks related to blockchain implementation transfers made between parties. Interface 902 can facilitate the transmission of data between system 700 and sources outside the system.

[0218] Transactions can form or may form blocks of transactions. Transactions may be retrieved from a single resource (e.g., from a block on the blockchain) or from different resources (e.g., from one or more users, one or more blockchain nodes, etc.). Transactions may be retrieved before they are made public on the blockchain, i.e., before they are recorded in a block. Alternatively, transactions may be retrieved after they have been recorded on the blockchain.

[0219] The controller 702 assigns each subset of a transaction to each validator 704, as described herein. Each subset of a transaction forms at least part of each part of the Merkle tree generated from the full 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 is assigned to validator B, subset C of transactions is assigned to validator C, and subset D of transactions is assigned to validator D. Once the subsets of transactions are assigned, the validators 704 process each of those subsets. In some embodiments, this involves each validator 704 validating each of the subsets of transactions. To do this, the controller 702 may transmit the relevant transactions to each validator 704. The validators 704 may send back communications to the controller 704 indicating that each of those subsets of transactions is valid, or that at least one transaction is invalid.

[0220] At least one, preferably some or all, of the validators 704a to 704d have access to their own UTXO pool, shown as 901a to 901d in Figure 9. This pool includes a storage facility such as the database described above, and potentially, a favorable indexing structure includes the concatenation of block IDs and transaction IDs. In Figure 9, the pools are shown as being contained within each validator, but those skilled in the art will readily understand that they may also be provided as being outside the validators but communicating with them.

[0221] In one or more embodiments, the disclosed process may include a block-level validity verification step, in which incoming new blocks are examined against block-level criteria. Exemplary block-level criteria are described above and generally relate to characteristics or limitations applicable to the block itself, as opposed to prescribed formal requirements and transactions within the block. Examples include block size, block header structure, or content, and similar criteria. Such operations may be performed by a controller, or a component of a controller, or another system component.

[0222] In some embodiments, the method may further include a UTXO uniqueness check module capable of evaluating whether each input to a transaction in a new block, i.e., each UTXO, is unique. If the same UTXO appears multiple times as an input in a new block, 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 among the transaction inputs in a new block, it may output an error signal or other interrupt indicating that the block should be rejected.

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

[0224] Individual validators verify the validity of transactions associated with the segments they receive against transaction-level validity criteria. Validators do not require a synchronization paradigm between validators when they work independently to verify the validity of their assigned transactions. Each validator outputs a result validating its assigned transactions. These results are added or accumulated to ensure that all transactions within a segment are valid. If one of these validators identifies a non-compliant, i.e., invalid transaction, it may output an interrupt or other signal to indicate the presence of an invalid transaction. This interrupt or signal may be sent to other validators, or to the controller or another system component, allowing them to immediately stop checking their respective transactions and avoid wasting further resources validating transactions in blocks that should be rejected.

[0225] In some cases, the system may be configured to check block-level criteria. This may be performed prior to assigning segments to validators, but it will be understood that the block-level validity check phase may occur after the transaction-level validity check by the validator, or in some cases, in parallel with the transaction-level validity check.

[0226] Next, refer to Figure 8, which shows an example of how to verify the validity of a block in the form of a flowchart. A block contains multiple transactions, each transaction referencing one or more inputs, and each input is a UXTO (except in the case of coinbase-generated transactions). The method is implemented within a node on the blockchain network using suitable hardware and processor-executable instructions.

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

[0228] In step S802, system 700 identifies chunks of the block's Merkle tree. In S803, the segments are distributed to multiple validators, and in S804, the validators process their respective subsets of the transaction virtually in parallel but independently of each other. In S805, the validators signal to the controller whether the validation was successful or failed.

[0229] It should be noted that, when used in relation to the description of parallel processors in this specification, the term “processor” does not necessarily mean physically distinct microprocessors, but may include 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 having multiple cores. In some cases, a parallel processor may comprise multiple separate processing units. Parallel processors may or may not share physical memory. Each parallel processor, however implemented, has software or hardware mechanisms for signaling, such as outputting a signal in response to identifying an invalid transaction. Implementations of parallel processors also include providing, in software and / or hardware, the necessary data transfer mechanisms for routing allocated transaction data to each processor for local processing.

[0230] Clause Set 1: Any embodiment defined by any clause or combination of clauses within Clause Set 1 may be arranged and configured to implement or combine any other clause or example herein.

[0231] Clause 1.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.

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

[0233] At least a portion of the tree structure can be processed. This allows for validating that an item or component is part of the tree structure. At least a portion may include paths between the root and the nodes representing the items or components.

[0234] Clause 1.2. A method of Clause 1.1, the method further comprising processing a record of an item and / or at least one component of an item; validating 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 at least one of the item, at least one component of an item, and at least one portion of a blockchain transaction (Tx) in an allocated resource (1104).

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

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

[0237] Data associated with an item or component, such as a data item (D), can be stored in association with a script within a transaction. In addition or alternatively, and / or the data item (D) can be stored as metadata within a transaction.

[0238] A record can include validity verification data necessary to verify the validity of a blockchain transaction. For example, unspent transaction outputs (UTXOs) are associated with a tree structure. A record can further include the history of a plurality of preceding blockchain transactions.

[0239] Clause 1.3. A method as described in Clause 1.1 or 1.2, wherein each item and component of the item is represented by nodes and leaves within a tree structure and is hashed to create a hash tree.

[0240] Clause 1.4. A method as described in Clause 1.3, wherein the hash of the root node of the tree structure is stored in a blockchain transaction (Tx) on a blockchain ledger.

[0241] Clause 1.5. A method as described in at least one of Clauses 1.1 to 1.4, wherein at least a part of the tree structure is stored on a blockchain ledger.

[0242] The 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.

[0243] Clause 1.6. A method of any one of Clauses 1.1 to 1.5, 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.

[0244] The second tree structure may be an iteration of the first tree structure, for example, the nodes of the first tree structure may be updated. In addition, or alternatively, the second tree structure may be independent of the first tree structure, for example, the nodes of the first tree structure may be updated and the updated nodes may be represented in the second tree structure.

[0245] Clause 1.7. A method relating to Clause 1.6, further comprising processing a record to validate that at least one of an item, 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.

[0246] Clause 1.8. A method of any one of Clauses 1.1 to 1.7, wherein a blockchain transaction includes at least one of the following: the tree structure in which the blockchain transaction originated or the history of each tree structure; the history of the allocated resources in which the blockchain transaction is stored, the history which enables validation that at least one of an item, 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.

[0247] Clause 1.9. A method of any one of Clauses 1.1 to 1.8, wherein a blockchain transaction (Tx) is used to identify and / or allocate a resource.

[0248] Data associated with at least one of items, components, and tree structures, or associated blockchain transactions, and parts thereof, may be used to identify and / or allocate processing and / or storage resources. The data may include, at least in part, unconsumed transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0249] Clause 1.10. A method relating to Clause 1.9, further comprising storing and / or processing at least a portion of a blockchain transaction (Tx) in and / or by and / or in relation to an assigned resource.

[0250] Clause 1.11. A method relating to any one of Clauses 1.2 to 1.10, wherein a blockchain transaction or its hash is used to determine a key, and the key determines the allocated resource.

[0251] Clause 1.12. A method according to Clause 1.11, wherein the key comprises at least one of alphanumeric characters and binary numbers, and the number is used to determine the allocated resource.

[0252] Clause 1.13. A method according to Clause 1.11 or 1.12, wherein a blockchain transaction, or its hash, or key is parsed to determine the allocated resource.

[0253] Clause 1.14. A method of any one of Clauses 1.1 to 1.13, wherein a blockchain transaction comprises at least one of the following: a Merkle tree of the block in which the transaction (Tx) is recorded; a Merkle root of the block in which the transaction (Tx) is recorded; a Merkle path that enables determining the value of the Merkle root to the block in which the transaction (Tx) is recorded from the hash of the blockchain transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) in 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).

[0254] Clause 1.15. A method of any one of Clauses 1.1 to 1.14, further comprising, for at least a portion of a blockchain transaction (Tx), validating and / or verifying the blockchain transaction (Tx); performing at least a portion of a Simplified Payment Verification (SPV) process on the blockchain transaction; determining whether the blockchain transaction (Tx) is contained within a blockchain block; determining a Merkle proof for the blockchain transaction (Tx); and using a path that enables the determination of the hash of the root to the tree structure on which the associated blockchain transaction is recorded, from the hash of the root of the tree structure and the hash of the blockchain transaction, that the associated blockchain transaction is part of a tree structure.

[0255] Clause 1.16. Computer equipment comprising memory including one or more memory units and processing units including one or more processing units, wherein the memory stores code configured to be placed and run on the processing unit, and the code is configured to run as described in any one of Clauses 1 to 16 when it is on the processing unit.

[0256] Clause 1.17. A computer program that is embodied on a computer-readable storage medium and is configured to perform any method described in any one of Clauses 1.1 to 1.16 when executed on one or more processors.

[0257] Clause Set 2 Any embodiment defined by any clause or combination of clauses within Clause Set 2 may be arranged and configured to implement or combine any other clause or example herein.

[0258] Clause 2.1. A computer implementation method for associating data with a blockchain transaction (Tx), wherein the data is represented in a tree structure, and the method includes processing the path of the tree structure containing the data; processing the digital signature of the creator and / or approver of the data; and validating that at least one of the data, the digital signature, and the blockchain transaction (Tx) is part of the tree structure.

[0259] This method can be performed by a machine, for example, a computer running a browser to access a webpage via a web address. Through association with blockchain transactions and processing the tree structure and digital signatures associated with the data, such as a webpage or its content, the validity of the data can be determined, and the browser can selectively access only valid data.

[0260] The tree structure may be a hash tree. The Simplified Payment Verification technology can be used to determine that data is part of the tree structure. At least one of data, digital signatures, and blockchain transactions (Tx) can be hashed when associated with the tree structure.

[0261] Therefore, in validity verification, not only can it be considered whether the data is included in the tree structure, but also the signature associated with the data can be verified for validity. This may enable verifying the validity of data, or any part thereof, such as a web page, and the content of that web page, but the provenance of the creator or approver of the data can be verified for validity. Validity verification can include the digital signature of at least one of the creator, certification authority, and associated blockchain transaction. A web address is just an example of a set of data that can be represented as a tree structure.

[0262] Clause 2.2. The method described in Clause 2.1, wherein the digital signature is associated with a blockchain transaction.

[0263] Clause 2.3. The method described in Clause 2.1 or 2.2, wherein the data and the digital signature are combined.

[0264] The data and the digital signature can be concatenated. The hash of the data and the digital signature can be concatenated. Overall, the digital signature is associated with the data to be verified for validity.

[0265] Clause 2.4. The method described in any one of Clauses 2.1 to 2.3, wherein verifying validity includes determining that the digital signature is part of the tree structure.

[0266] Clause 2.5. A method of any one of Clauses 2.1 to 2.4, further comprising processing and / or storing in an allocated resource (1104) at least one of data, digital signatures, tree structure items, and blockchain transactions (Tx).

[0267] Clause 2.6. A computer implementation method comprising processing data to generate processed data, associating the data and / or the processed data with the digital signatures of the creator and / or approver, representing the data and / or the processed data in a tree structure, associating at least one of the data, the processed data, and / or the digital signature with a blockchain transaction (Tx) represented in a tree structure, and recording at least one of the data, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure on a blockchain.

[0268] The processed data may be data associated with a digital signature or combined with it in some other way. For example, data to be validated may be linked with a digital signature. Prior to association, the data and / or digital signature may be processed, for example, hashed.

[0269] This method processes data that subsequently needs to be validated. This can be done by a machine to extract and / or receive data and digital signatures to create a tree structure. In one example, a web address is processed along with the digital signatures of its creator and / or certification authority. Digital signatures can also extract and / or receive components of data, such as components of a web page as part of a web address. A hash tree can then be established.

[0270] Clause 2.7. A method relating to Clause 2.6, further comprising processing updates to data to generate updated processed data, and representing the updated processed data in a second tree structure.

[0271] The second tree structure may be an iterative update of the first tree structure. The second tree structure, and any tree structures created thereafter, may be used to track data. The tree structure outlines different versions of the relationship between the data and the rest of the tree structure. The second tree structure may be used to determine the validity and / or provision of items and / or components from the point in time when the tree structure was first tracked. Tracking may be performed using one or more tree structures. Each tree structure may represent its items and / or components and alternative relationships with different items and / or different components. Tree structures may be independent, and multiple tree structures may be used to track items and / or at least one component of an item by migrating blockchain transactions (Tx). The tree structure may be a Merkle tree, a binary tree, an ancestor tree, an asymmetric tree, or any other form of unbalanced structure.

[0272] Clause 2.8. A method according to Clause 2.6 or 2.7, wherein the processed data is stored in a node of a tree structure or a second tree structure, and each node of the tree structure or the second tree structure includes at least one of data, processed data, and / or a digital signature with a blockchain transaction (Tx) represented in the tree structure.

[0273] Clause 2.9. A method of any one of Clauses 2.6 to 2.8, further comprising processing at least one of data, processed data, digital signatures, blockchain transactions (Tx), and tree structures to generate a hash thereof, and storing the hash thereof on a blockchain.

[0274] Clause 2.10. A method of any one of Clauses 2.6 to 2.9, further comprising processing and / or storing in an allocated resource (1104) at least one of data, processed data, digital signatures, tree structures, and blockchain transactions (Tx).

[0275] Clause 2.11. A method relating to any one of Clauses 2.6 to 2.10, wherein data is represented by nodes or leaves in a tree structure and hashed to form a hash tree.

[0276] Clause 2.12. A method of Clause 2.11 wherein the hash of the root node of the tree structure is stored in a blockchain transaction (Tx) on the blockchain ledger.

[0277] Clause 2.13. A method of any one of Clauses 2.6 to 2.12, wherein the tree structure represents a web address, the data is content on a web page of the web address, accessible through a path of the web address, the path provides links to the content, and the tree structure includes at least one of a top-level domain, a second-level domain, a subdomain, and a subdirectory.

[0278] The content may include at least one of the following: HTML data, links, executable files, certificates, documents, multimedia data, and machine-readable data.

[0279] Clause 2.14. A method relating to Clause 2.13, wherein the content of each web page is signed by the digital signature of the creator and / or approver of the said data.

[0280] Clause 2.15. A method of any one of Clauses 2.6 to 2.14, wherein a blockchain transaction includes at least one of the tree structure on which the blockchain transaction originated or the history of each tree structure, and the history of the allocated resources on which the blockchain transaction is stored, wherein the history enables the validity verification of at least one of the data on the blockchain, processed data, digital signatures, blockchain transactions (Tx), and tree structures.

[0281] Clause 2.16. A method according to any one of Clauses 2.6 to 2.15, wherein a blockchain transaction (Tx) is used to identify and / or allocate a resource, preferably a hash of the blockchain transaction is used to determine a key, and the key determines the allocated resource.

[0282] The key may contain at least one of alphanumeric characters and binary numbers, the number of which is used to determine the assigned resource. At least one of data, digital signatures, blockchain transactions (Tx), web addresses, web pages, or their hashes may be parsed to determine the key and / or the assigned resource.

[0283] Clause 2.17. A method of any one of Clauses 2.6 to 2.16, wherein a blockchain transaction includes at least one of a Merkle path, a Merkle proof, a blockchain block associated with a transaction (Tx) in a blockchain transaction in a blockchain block, a block identifier (block_ID) associated with a transaction identifier (TxID), 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), which enables determining the value of the Merkle root to the block in which the transaction (Tx) is recorded from 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 hash of the blockchain transaction (Tx).

[0284] Clause 2.18. A method of any one of Clauses 2.6 to 2.17, further comprising, for at least a portion of a blockchain transaction (Tx), validating and / or verifying the blockchain transaction (Tx); performing at least a portion of a Simplified Payment Verification (SPV) process on the blockchain transaction; determining whether the blockchain transaction (Tx) is contained within a blockchain block; determining a Merkle proof for the blockchain transaction (Tx); and proving that the associated blockchain transaction is part of a tree structure by using a path that enables the determination of the hash of the root to the tree structure on which the associated blockchain transaction is recorded, from the hash of the root of the tree structure and the hash of the blockchain transaction.

[0285] Clause 2.19. Computer equipment comprising memory including one or more memory units and processing units including one or more processing units, wherein the memory stores code configured to be arranged to run on the processing units, and the code is configured to perform any one of Clauses 2.1 to 2.18 when it is on the processing units.

[0286] Clause 2.20. A computer program that is embodied on computer-readable storage and is configured to perform any of the methods described in any one of Clauses 2.1 through 2.18 when executed on one or more processors.

[0287] Exemplary technical environment for implementing exemplary embodiments of this disclosure We will now outline a computing environment in which one or more embodiments of this disclosure may be put into practice. However, as stated above, this context is not intended to be limiting, and embodiments may be put into practice for processing data records and structures that are not implemented via blockchain. Non-blockchain embodiments may be devised, for example, using a database instead of a distributed ledger.

[0288] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, a wide-area internet, typically such as the Internet. The packet-switched network 101 may include a plurality of blockchain nodes 104 that can be arranged and configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be arranged and configured as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0290] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within a decentralized or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean completely memorizing blockchain 150. Instead, blockchain 150 can be pruned insofar as each blockchain node 150 remembers the block header (described below) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction refers to a 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 contains at least one input and at least one output. Each output specifies an amount representing the quantity of digital assets as property, one example being user 103, whose output is cryptographically locked (requiring the user's signature or other solution to unlock and thereby redeem or consume it). Each input points to the output of the preceding transaction 152, thereby linking the transactions.

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

[0292] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 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”. This term as used herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as valid, to which the node 104 is obligated not to accept any other transactions attempting to consume the same output.

[0293] 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. A preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or even sent to network 106, but for the current transaction to be valid, a preceding transaction 152i must exist and be validated. Thus, "preceding" as used herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily the time of creation or transmission in a temporal sequence, and therefore does not necessarily exclude transactions 152i, 152j being created or sent out of order (see the following explanation of orphan transactions). A preceding transaction 152i can also be equally called a previous transaction or preceding transaction.

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

[0295] According to an output-based transaction protocol, when a party 103, such as an individual user or organization, wishes to formulate a new transaction 152j (either manually or through an automated process adopted by the party), the implementing party sends the new transaction from its computer terminal 102 to the recipient. The implementing party or recipient then sends this transaction to one or more blockchain nodes 104 on the network 106 (currently typically a server or data center, but in principle, it could be another user terminal). It is also not excluded that the party 103 formulating the new transaction 152j directly sends this transaction to one or more blockchain nodes 104, and in some examples does not send it to the recipient. The blockchain node 104 that receives the transaction checks 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 check 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 checking 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 to which the new transaction assigns, the condition typically includes checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i. Alternatively, it may be modified simply by the blockchain node protocol alone, or by a combination of these.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 then apply the same test according to the same blockchain node protocol, and so on, forwarding the new transaction 152j to one or more further nodes 104. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0296] In the output-based model, the definition of whether a given output (e.g., UTXO) has been allocated (e.g., consumed) is, according to the blockchain node protocol, whether it has still been validly redeemed by the input of another, preceding transaction 152j. Another condition for a transaction to be valid is that the output of the preceding transaction 152i, which attempts to redeem it, has not yet been redeemed by another transaction. Again, if it is not valid, transaction 152j is not propagated (unless it is flagged as invalid for a warning and propagated) or recorded on blockchain 150. This protects against double spending, where a transaction executor attempts to allocate the output of the same transaction multiple times. The account-based model, on the other hand, prevents double spending by maintaining an account balance. Again, there is a defined order of transactions, so the account balance has a single, predefined state at any given time.

[0297] In addition to validating transactions, blockchain node 104 competes to be the first to create a block of the transaction in a process commonly referred to as mining, supported by "proof of work." At blockchain node 104, the new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded on blockchain 150. 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 the output of the hash, when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, satisfies a predetermined condition. For example, the predetermined condition might be that the output of the hash has a specific predefined number of leading zeros. This is just one particular type of proof-of-work puzzle, and other types are not excluded. A characteristic of hash functions is that they have an unpredictable output for a given input. Therefore, this search can only be performed by brute force, which means that a considerable amount of processing resources will be consumed at each blockchain node 104 attempting to solve the puzzle.

[0298] The first blockchain node 104 to solve the puzzle publishes it to the network 106, providing the solution as proof that other blockchain nodes 104 in the network can easily check (given a hash solution, it is easy to check that it satisfies the condition for the hash output). The first blockchain node 104 propagates the block to the threshold consensus of other nodes that accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 then become recorded as a new block 151 in blockchain 150 by each of the blockchain nodes 104. 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 significant amount of effort required to create a proof of work solution, for example in the form of a hash, signals the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, which is otherwise known as double-spending. Once created, block 151 is recognized and maintained at each of the blockchain nodes 104 within the blockchain network 106, and therefore cannot be modified. The block pointer 155 also imposes an order on block 151. Since transaction 152 is recorded in an ordered block at each blockchain node 104 within the network 106, this thus provides an immutable public ledger of transactions.

[0299] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that are not yet public at any given time, depending on when they began 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 unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to create a block from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any possible "forks" that may occur, such as when two blockchain nodes 104 solve the puzzle within a very short time between them such that conflicting views of the blockchain propagate between the nodes 104. In short, whichever branch of the fork grows the longest will become the definitive blockchain 150. It should be noted that this should not affect users or agents of the network when the same transaction appears in both forks.

[0300] According to several exemplary blockchain protocols, the node that successfully constructs a new block 104 is granted the ability to newly allocate an additional accepted amount of digital assets in a new special type of transaction that distributes an additional predetermined amount of digital assets (as opposed to agent-to-agent or user-to-user transactions that transfer digital assets from one agent or user to another). This special type of transaction is usually referred to as a "coinbase transaction," but is sometimes called an "initiating transaction" or "generating transaction." It typically forms the first transaction of a new block 151n. Proof of work signals the node constructing the new block's intention to follow protocol rules that will allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, for example, 100 blocks, before this special transaction can be redeemed. Often, a regular (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 was published. This fee is usually referred to as a "transaction fee" and is described below.

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

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

[0303] Furthermore, connected to the network 101 are the computer devices 102 of multiple parties 103, each acting as a consumer user. These users can interact with the blockchain network 106, but they 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 copies of the blockchain 150 (e.g., obtaining a copy of the blockchain from a blockchain node 104).

[0304] Some or all of the parties 103 may be connected as part of a different network, for example, a network superimposed on top of the blockchain network 106. Users of the blockchain network (often referred to as “clients”) may be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 as they do not perform the necessary roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 by connecting to (i.e., communicating with) the blockchain nodes 106, thereby utilizing the blockchain 150. 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 many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. By purely illustrative means, the first party 103a is referred to herein as Alice, and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference to Alice or Bob herein may be replaced with “the first party” and “the second party,” respectively.

[0305] Each computer device 102 of Party 103 comprises one or more processors, each processing unit including, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further includes memory, i.e., computer-readable storage device in the form of a non-temporary computer-readable medium. This memory may include one or more memory units employing 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 on each computer device 102 of Party 103 stores software, each including at least one instance of a client application 105, which is arranged and configured to run on the processing unit. It will be understood that any activity attributed to a given Party 103 in this specification may be performed using software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 includes 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.

[0306] The client application 105 may first be provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, for example, downloaded from a server, or it may be 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.

[0307] The client application 105 has at least a “wallet” function, which has two main functions. One of these is that each party 103 can create, authorize (e.g., sign) a transaction 152, send it to one or more nodes 104, and then propagate it throughout the network of blockchain nodes 104, thereby enabling it to be included in blockchain 150. The other is to report to each party the amount of digital assets they currently own. In an output-based system, this second function includes matching the amounts belonging to the party of interest, as defined in the outputs of various transactions 152 scattered throughout blockchain 150.

[0308] Note: While it may be described that various client functions are integrated into a given client application 105, this is not necessarily limited. Instead, any client function described herein may instead be implemented in two or more different applications, for example, interfaced via an API or one plugging into the other. More generally, client functions may also be implemented in the application layer, or in a lower layer such as the operating system, or any combination thereof. The client application 105 will now be described, but it should be understood that this is not an exhaustive description.

[0309] Each computer device 102 instance 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 blockchain node 104 to query blockchain 150 for any transaction in which each party 103 is the recipient (or, in embodiments, actually inspect the transactions of other parties within blockchain 150, as blockchain 150 is a public facility that in part provides trust to transactions through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and forward transaction 152 for propagation throughout the blockchain network 106. The transaction protocol and node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements a given transaction model together. The same transaction protocol is used for all 152 transactions within blockchain 150. The same node protocol is used by all 104 nodes within network 106.

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

[0311] Subject to passing a test that the newly received transaction 152j is considered valid (i.e., it is "validated"), any blockchain node 104 receiving transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained on that blockchain node 104. Furthermore, any blockchain node 104 receiving transaction 152j forward propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, then, assuming transaction 152j is valid, this means it will immediately propagate throughout the network 106.

[0312] After being allowed to enter the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 begins a competition to solve a proof-of-work puzzle on the latest version of each pool 154 containing the new transaction 152 (it should be noted that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transaction 154, but whoever gets there first defines the set of transactions included in the latest block 151. Ultimately, blockchain node 104 will solve the puzzle on the portion of the ordered pool 154 containing Alice's transaction 152j). After proof-of-work is performed on the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. Each transaction 152 contains a pointer to a previous transaction, and therefore the order of transactions is also immutably recorded.

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

[0314] An alternative type of transaction protocol operated by several blockchain networks may be referred to as an “account-based” protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the transfer amount not by referencing the UTXO of a preceding transaction within a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account’s running transaction aggregate (also called the “position”). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may refer to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0315] UTXO-based model Figure 2 illustrates an example of a transaction protocol. This 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 output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments.

[0316] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure including one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO) which can be used as the source for the input 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value that specifies 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 originated. The transaction data structure may also comprise a header 201 which may include an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also 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.

[0317] For example, Alice 103a wants to create transaction 152j that transfers the amount of a digital asset of interest to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". This takes 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 it 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 on blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could also refer to any preceding (i.e., previous) transaction that still has the unspent output 203 locked in Alice.

[0318] The preceding transaction Tx0 may already be validated and included in block 151 of blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time she sends it to network 106. It may already be included in one of the blocks 151 at that point, or still waiting in an ordered set 154, in which case it will immediately be included in the new block 151. Alternatively, Tx0 and Tx1 may be created together and sent together to network 106, or Tx0 may even be sent after Tx1 if the node protocol allows buffering of “orphan” transactions. The terms “preceding” and “following” as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence as defined by transaction pointers specified in the transactions (which transaction points to which other transactions, etc.). These may also be equivalently replaced with “preceding element” and “following element,” or “preceding element” and “descendant,” “parent” and “child,” or such. This does not necessarily imply the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (previous transaction or "parent") will not be validated until the parent transaction has been validated, and unless validated, it will not be validated. A child that arrives at blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or the node's behavior, it may be discarded to wait for its parent or buffered for a certain period of time.

[0319] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, which is here labeled UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining the conditions that must be met by the unlock script of the subsequent transaction's input 202 for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the lock script locks the amount to a specific party (the beneficiary of the transaction in which it is contained). That is, the lock script typically defines unlock conditions that include 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.

[0320] A lock script (also called scriptPubKey) is a snippet of 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 in blockchain networks. The lock script specifies the information necessary to consume transaction output 203, such as the requirement for Alice's signature. The unlock script appears within the transaction output. The unlock script (also called scriptSig) is a snippet of code written in a domain-specific language that provides the information necessary to satisfy the criteria of the lock script. For example, this could include Bob's signature. The unlock script appears within transaction input 202.

[0321] Therefore, in the example given, the UTXO0 of output 203 of Tx0 is redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be valid) by Alice's signature Sig P A Lock script that requires [Checksig P A It has [Checksig P A ] is the public key P from Alice's public key-private key pair.A The input 202 of Tx1 includes a pointer to Tx1 (for example, using its transaction ID, TxID0, which in this embodiment is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an identifier UTXO0 in Tx0 to distinguish it from any other possible outputs of Tx0. The input 202 of Tx1 includes an unlock script containing Alice's cryptographic signature, which is created by Alice applying a secret key from a key pair to a predefined portion of the data (sometimes called a "message" in cryptography). <Sig P A >Furthermore, the data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, by the node protocol, or a combination thereof.

[0322] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves executing the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where these conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is a function composed of a lock script (a stack-based language in this example). Equivalently, scripts can be executed one after the other via a common stack, rather than concatenating them. In any case, when executed together, the scripts contain Alice's public key P, such that the lock script is located in the output of Tx0. AThe unlock script within the input of Tx1 authenticates that it contains Alice's signature, which signs the expected portion of the data. For this authentication to be performed, the expected portion of the data itself ("the message") must also be included. In this embodiment, the signed data includes the entirety of Tx1 (and therefore does not require another element specifying the signed portion of the data in plaintext, as it already exists in its entirety).

[0323] The details of authentication using public-secret cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, another entity, such as node 104, given Alice's public key and the plaintext message, can authenticate that the message must have been signed by Alice. Signature typically involves hashing the message, signing the hash, and tagging the message with this signature, so that anyone holding the public key can authenticate the signature. Therefore, it should be noted that references herein to signing a particular data portion or part of a transaction, etc., may in embodiments mean signing the hash of that data portion or part of a transaction.

[0324] If the unlock script for Tx1 satisfies one or more conditions specified in the lock script for Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), blockchain node 104 considers Tx1 valid. 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, thereby propagating it throughout network 106. After Tx1 has been validated and placed in blockchain 150, this defines UTXO0 from Tx0 as consumed. Note that Tx1 can only be valid if it consumes an unconsumed transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes 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 defined order on transaction 152. In fact, a given blockchain node 104 may maintain a separate database marking which UTXO 203 was consumed in which transaction 152, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction within blockchain 150.

[0325] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all inputs 202, this is another criterion for invalidity in most transaction models. Therefore, such a transaction will not propagate and will not be included in block 151.

[0326] In the UTXO-based transaction model, it should be noted that a given UTXO must be consumed as a whole. A portion of the amount defined in a UTXO cannot be "left behind" as consumed while another portion is being 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 the remainder in the second output of Tx1 to give herself change or to pay another party.

[0327] In practice, Alice would also typically need to include a fee for node 104 to successfully place her transaction 104 into block 151. If Alice does not include such a fee, Tx0 will be rejected by blockchain node 104 and, although technically valid, will not be propagated and cannot be included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not wish to do so). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by input 202 and the total amount specified in output 203 of a given transaction 152 is automatically given to blockchain node 104 publishing the transaction. For example, a pointer to UTXO0 is only an 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 won the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily ruled out that, alternatively or in addition, a transaction fee may be explicitly specified in one of the UTXO203 of transaction 152.

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

[0329] It should be noted that script code is often expressed in general terms (i.e., without using the exact language). For example, operation codes (opcodes) may be used to express 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 a non-consumable output of a transaction that can store data within the transaction, thereby immutably recording the data within blockchain 150. For example, the data may include documents that are desired to be stored on the blockchain.

[0330] 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. A digital signature is a signature of 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 parts of the output that it signs depend on the SIGHASH flag. The SIGHASH flag is a 4-byte code typically included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0331] A lock script is sometimes called a "scriptPubKey," referring to the fact that it typically contains the public keys of the parties whose transactions are locked. An unlock script is sometimes called a "scriptSig," referring to the fact that it typically provides the corresponding signature. However, more generally, in all applications of Blockchain 150, it is not essential 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.

[0332] Side channel As shown in Figure 1, the client applications on Alice and Bob's computer devices 102a and 120b, respectively, may each 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 party or a third party). The side channel 107 allows for the exchange of data away from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, this could be used to exchange transaction 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing on chain 150 until one of the parties chooses to broadcast it to network 106. Sharing a transaction in this manner is sometimes referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively, or in addition to the above, the side channel 107 may be used to exchange any other transaction relation data, such as keys, negotiated amounts or terms, or data content.

[0333] Side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, 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. Generally, side channel 107 as referred to anywhere in this specification may include any one or more links via one or more network technologies or communication media for exchanging data "off-chain," i.e., apart from the blockchain network 106. If multiple links are used, a bundle or collection of off-chain links as a whole may be referred to as side channel 107. Therefore, when it is said that Alice and Bob exchange some information or data or similar over side channel 107, this does not necessarily imply that all parts of this data must be transmitted over the exact same link or network of the same type.

[0334] conclusion Other variations or use cases of the disclosed technology will become apparent to those skilled in the art after the disclosure herein. The scope of this disclosure is not limited by the embodiments described and is limited only by the accompanying claims. For example, some of the embodiments described above have been described in relation to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is a specific example of blockchain 150, and the above description may be applied in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any above references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by 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.

[0335] In one or more possible embodiments of this disclosure, the blockchain network 106 may be a Bitcoin network, and a Bitcoin node 104 may perform at least some or all of the described functions of creating, publishing, propagating, and storing a block 151 of the blockchain 150. However, there may be other network entities (or network elements) that perform only one or some of these functions and not all of them. That is, a network entity may perform the function of propagating and / or storing a block without creating or publishing it.

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

[0337] More generally, any reference to the term “Bitcoin node” 104 above may 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 using the same methods described above with reference to blockchain nodes 104.

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

[0339] The embodiments described above are illustrative of the invention rather than limiting the disclosure, and it should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the disclosure as defined by the supplementary claims. Reference numerals in parentheses in the claims shall not be construed as limiting the claims. Furthermore, “equipment,” “inclusion,” and similar phrases shall not preclude the existence of elements or steps other than those described in any claim or throughout this specification. In this specification, “inclusion,” “equipment,” and “containment,” respectively, mean “to include or consist of,” and “to include,” “to consist of or consist of.” Throughout this specification, the conjugations of “inclusion,” “equipment,” and “containment,” etc., are understood to imply the inclusion of the element, integer, or step, or group of elements, integers, or steps, being described, and not to imply the exclusion of any other element, integer, or step, or group of elements, integers, or steps. A singular reference to an element shall not preclude a plural reference to such element, and vice versa. This disclosure may be implemented using hardware comprising several different elements and a appropriately programmed computer. In device claims that list several means, some of these means may be embodied by one of the hardware and the same item. The mere fact that certain means are referenced in different dependent claims does not imply that combinations of these means cannot be used advantageously.

[0340] References to “Bitcoin,” “cryptocurrency,” or specific cryptocurrency protocols in this specification and accompanying figures may be replaced with the terms “blockchain” or “blockchain network.” “Token,” “digital asset,” or “blockchain protocol” are appropriate in the specific context in which these terms are used.

[0341] Disclaimer The incorporation of the above-mentioned documents by reference is limited so as not to include any subject matter that contradicts the express disclosure herein. The incorporation of the above-mentioned documents by reference is further limited so as not to include any claims contained in the documents by reference herein. The incorporation of the above-mentioned documents by reference is further limited so as not to include any definitions presented in the documents by reference herein unless they are expressly included herein. [Explanation of symbols]

[0342] 100 Systems 101 Packet-switched network, Internet 102 Computer equipment 102a Computer equipment, machines 102b Computer equipment 103 Users, Parties 103a User 103a First party 103b New user or entity 103b The second party 104 Blockchain Nodes, Root Nodes, Bitcoin Nodes 105 Client Applications 106 Peer-to-peer (P2P) networks, decentralized or blockchain networks 107 Side Channel 120b Computer equipment 150 Blockchains 151 data blocks 151n block 151n-1 block 152 transactions 152i Transaction 152j transaction 153 Genesis Block (Gb) 154. Ordered sets (or "pools") 155 Block pointers 201 Header 202 inputs 203 Output 301 Side Channel 502 parts 504 Common Internal Node (Internal Hash) 602 parts 602a~h part 604 Common Internal Node 700 systems, distributed validity verification nodes 702 System Level Controller 704 Validator 704a to 704d Validation Verification Resources 902 Interface 903 Segment Identification Unit 904 Component 904 allocated units 905 Load Balancing Unit 1100 Resource allocation component, system 1102 Switch 1104 Resources 1106 Validator 1400 tree structure 1402 nodes 1404 Leaf, Leaf Node 1500 First tree structure 1502 Second tree structure 1700 tree structure, web domain, web page 1704 Digital signatures, web pages 1706 Top-level domain 1708 Second-level domain 1710 subdomain 1712 subdirectory Route 1714

Claims

1. A step of associating data with a blockchain transaction (Tx), wherein the data is represented in a tree structure, The steps include processing the path of a tree structure containing the aforementioned data, The steps include processing the digital signature of the creator and / or approver of the aforementioned data, A step of validating that at least one of the aforementioned data, the aforementioned digital signature, and the aforementioned blockchain transaction (Tx) is part of the tree structure. Computer implementation methods, including those mentioned above.

2. The method according to claim 1, wherein the digital signature is associated with the blockchain transaction.

3. The method according to claim 1 or 2, wherein the aforementioned data and the aforementioned digital signature are combined.

4. The method according to any one of claims 1 to 3, wherein the step of validating the digital signature includes the step of determining that the digital signature is part of the tree structure.

5. The method according to any one of claims 1 to 4, further comprising the steps of processing and / or storing in an allocated resource (1104) at least one of the data, the digital signature, the tree structure item, and the blockchain transaction (Tx).

6. The steps include processing data to generate processed data and associating the data and / or the processed data with the digital signatures of the creator and / or approver, A step of representing the aforementioned data and / or the processed data in a tree structure, The steps include associating at least one of the aforementioned data, the processed data, and / or the digital signature with a blockchain transaction (Tx) represented in the tree structure, A step of recording at least one of the aforementioned data, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure on the blockchain. Computer implementation methods, including those mentioned above.

7. The method according to claim 6, further comprising the steps of processing updates to the aforementioned data to generate updated processed data, and representing the updated processed data in a second tree structure.

8. The method according to claim 6 or 7, wherein the processed data is stored in a node of the tree structure or the second tree structure, and each node of the tree structure or the second tree structure includes at least one of data, processed data, and / or the digital signature with a blockchain transaction (Tx) represented in the tree structure.

9. The method according to any one of claims 6 to 8, further comprising the steps of processing at least one of the aforementioned data, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure to generate a hash thereof, and storing the hash on the blockchain.

10. The method according to any one of claims 6 to 9, further comprising the steps of processing and / or storing in an allocated resource (1104) at least one of the data, the processed data, the digital signature, the tree structure, and the blockchain transaction (Tx).

11. The method according to any one of claims 6 to 10, wherein the data is represented by nodes or leaves in the tree structure and hashed to form a hash tree.

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

13. The tree structure represents a web address, the data is the content on the web page of the web address, is accessible via the path of the web address, and the path provides links to the content. The method according to any one of claims 6 to 12, wherein the tree structure includes at least one of a top-level domain, a second-level domain, a subdomain, and a subdirectory.

14. The method according to claim 13, wherein the content of each web page is signed by the digital signature of the creator and / or approver of the data.

15. The aforementioned blockchain transaction is The blockchain transaction includes at least one of the tree structure or the history of each tree structure in which the blockchain transaction occurred, and the history of the allocated resource in which the blockchain transaction was stored. The method according to any one of claims 6 to 14, wherein the history enables verification of the validity of at least one of the data on the blockchain, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure. +

16. The method according to any one of claims 6 to 15, wherein the blockchain transaction (Tx) is used to identify and / or allocate the allocated resource, and preferably the hash of the blockchain transaction is used to determine a key, and the key determines the allocated resource.

17. The aforementioned blockchain transaction is The Merkle tree of the block in which the aforementioned transaction (Tx) is recorded, The Merkle root of the block in which the transaction (Tx) is recorded, From the hash of the blockchain transaction (Tx), a Merkle path is provided that enables the determination of a value for the Merkle root to the block in which the transaction (Tx) is recorded. Merkle proof, The block identifier (block_ID) associated with the aforementioned blockchain block, A transaction identifier (TxID) associated with a transaction (Tx) in multiple blockchain transactions within the aforementioned blockchain block, The functions of the aforementioned block identifier (block_ID) and transaction identifier (TxID), The concatenation of the block identifier (block_ID) and the transaction identifier (TxID) The method according to any one of claims 6 to 16, comprising at least one of the following:

18. For at least a portion of the aforementioned blockchain transactions (Tx), Steps to verify the validity and / or validation of the aforementioned blockchain transaction (Tx), A step of performing at least a part of the Simplified Payment Verification (SPV) process on the aforementioned blockchain transaction. A step of checking whether the blockchain transaction (Tx) is contained within the blockchain block, The steps include determining a Merkle proof for the aforementioned blockchain transaction (Tx), and Proof that the associated blockchain transaction is part of the tree structure is made by using at least one of the paths that enables the determination of the hash of the root to the tree structure on which the associated blockchain transaction is recorded, from the hash of the root of the tree structure and the hash of the blockchain transaction. The method according to any one of claims 6 to 17, further comprising at least one of the following:

19. Memory including one or more memory units, A processing apparatus comprising one or more processing units, wherein the memory stores code configured to be executed on the processing apparatus, and the code is configured to perform the method described in any one of claims 1 to 18 when it is on the processing apparatus, and Computer equipment, including...

20. A computer program that is embodied in computer-readable memory and configured to perform the method described in any one of claims 1 to 18 when executed on one or more processors.

Images