Computer-implemented system and method for tree-based data verification, communication and integrity schemes

Abstract

The invention relates to associating data with a blockchain transaction (Tx), wherein the data is represented in a tree structure; processing a path of the tree structure containing the data; processing digital signatures of creators and / or approvers of the data; and verifying whether at least one of the data, the digital signature, the blockchain transaction (Tx) is part of the tree structure. Similarly, the invention relates to processing such data for recording and subsequent verification. In one example, a website is represented by a tree structure. Data associated with data of at least one web page of the web address is represented in the tree structure, and at least one of the data, the processed data, and / or the digital signature is associated with a blockchain transaction (Tx) (represented in the tree structure). The data and the associated tree structure may be recorded and subsequently processed to verify the data. Through the association with the blockchain transaction, and processing the tree structure and a digital signature associated with the data (e.g., a webpage or content thereof), the validity of the data may be determined, and the browser may selectively access only valid data.

Description

Technical Field

[0001] This disclosure generally relates to improved methods and systems for processing and / or managing the format and / or content of data records and / or such records. This disclosure is particularly suitable, but not limited to, for transactions implemented on or using blockchain networks, such as determining storage allocations, pre-mining and / or post-mining verification of blockchain transactions, SPV checks, etc. Advantages include, but are not limited to, improved security, resilience, and efficiency, or reduced speed and resource requirements, enabling novel resource verification and balancing methods that are impossible with existing technological arrangements, thereby achieving arrangements of blockchain implementations that were previously impossible. The improved methods and systems are suitable for tracking and / or verifying items and / or their sub-components by at least one of the following: temporarily, over time, or by changing the application. Specifically, the improved methods and systems are suitable for verifying whether at least one of the following is part of a tree structure: data, digital signatures, and / or blockchain transactions. Background Technology

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

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

[0004] In one or more exemplary blockchain protocols, a transaction (Tx) must be verified before it can be written to the blockchain. Network nodes (miners) work to ensure that each transaction is valid, while invalid transactions are rejected by the network. Software clients installed on these nodes perform this verification work on unspent transaction outputs (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, the transaction is valid and is written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must: i) be verified by the first node receiving the transaction, and if the transaction passes verification, that node relays it to other nodes in the network, i.e., the transaction is propagated; ii) be added to a new block built by miners; and iii) be mined, i.e., added to the public ledger of past transactions. Once the transaction is stored in the blockchain as a UTXO, the user can transfer control of the associated token to another address associated with the input in another transaction subsequently written to the blockchain. This is typically 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 (Simple Payment Verification). SPV technology allows users and merchant nodes to perform local verification based only on partial information relevant to a specific transfer. SPV will be discussed in more detail below.

[0005] However, the increased volume of known transactions necessitates a greater ability to quickly determine the validity of unspent transaction outputs (UTXOs). Current technologies for verification tasks can be resource-intensive and time-consuming, requiring the downloading and storage of blocks, maintenance of large UTXO pools, and the execution of necessary verification processing. Many users are either unable or unwilling to meet these requirements, as they may not need to. Therefore, a faster and more efficient verification model is needed that can at least address these challenges (and others) without compromising security or requiring adaptation to existing protocols. Furthermore, the verification method must be scalable. Additionally, known verification techniques are performed at the macro level. However, such approaches hinder the verification of individual components and / or the dynamic tracking of changes at a granular level within the dataset.

[0006] Such improvement schemes have now been designed. Summary of the Invention

[0007] Embodiments of this disclosure provide improved blockchain-related methods, apparatus, and systems. According to one form of wording, such embodiments provide schemes for the processing and / or storage of data (e.g., including and / or implementing verification UTXOs) associated with blockchain transactions.

[0008] In some embodiments, a tree structure is processed. The tree structure schematically represents the relationship between an item and at least one component. The tree structure enables the tracking and / or verification of the item and / or the at least one component. For example, the tree structure can be recorded at a point in time to record the immediate state of an item, component, or inventory; the tree structure can change over time, reflecting updates to the state and / or configuration or information associated with the item, as well as updates to the state and / or configuration or information associated with the component of the item; and even during updates, the application of the item or component can be tracked, wherein a first tree structure is used in a first application to track the item or one of its components, and a second tree structure is used in a second application to track the item or one of its components, thereby tracking the history of the item or its component in different use cases. Overall, the tree structure can be used to track the process of an item from creation to final use or disposal, such as end-to-end item tracking. Using the tree structure to track the item allows the contents of the tree structure (i.e., the item and / or component) to be verified as part of the tree structure.

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

[0010] In some embodiments, a third party may verify the data before processing it. This may include determining its origin and / or authenticity. For example, verification may include associating the data with a blockchain transaction (Tx), wherein the data is represented in a tree structure. The path of the tree structure including the data may be processed, and / or the digital signatures of the data's creator and / or approver may be processed. Processing the data may verify whether at least one of the following is part of the tree structure: the data, the digital signature, and the blockchain transaction (Tx). The digital signature is associated with the blockchain transaction. The digital signature may be combined with the data.

[0011] In one example, the technology here is used to configure and verify URLs and their components. In this way, the content of a webpage (e.g., HTML, attachments) can be verified on the machine before it is processed, displayed, or executed.

[0012] In another example, data is processed to generate processed data. The data and / or the processed data are then associated with the digital signatures of the data's creator and / or approver. The data and / or the processed data are then represented in a tree structure. Subsequently, at least one of the data, the processed data, and / or the digital signature is associated with a blockchain transaction (Tx) represented in the tree structure. The data, the processed data, the digital signature, the blockchain transaction (Tx), and at least one of the tree structure are recorded on the blockchain. Through this association with the blockchain transaction, the combination of the tree structure and the digital signature can provide an efficient and scalable mechanism for verifying and authenticating data.

[0013] Data associated with an item or component may be stored in a record 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 includes at least a portion of a proven transaction (Tx) is included in the tree structure. The record may include a proof. For example, the proof may include a Merkel path that enables verification that a component is part of the tree structure. Further, the Merkel path may enable verification that the tree structure (e.g., its root hash) is part of a blockchain block (B). The record may include a data directory that is or includes a set of the transaction data.

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

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

[0016] The tree structure and techniques described herein can be used to improve item verification, enabling structured, dynamic methods and systems for tracking and / or verifying the tree structure or parts thereof. Furthermore, it is possible to securely verify whether an item or component is part of the tree structure without disclosing confidential information associated with other items or components of the tree structure.

[0017] By providing security solutions that address the efficiency, resource requirements, speed, and / or resilience of known processing methods for controlling, managing, and / or improving blockchain transaction processing, the scalability of the tree-structured application can be enhanced using allocated resources.

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

[0019] During the verification process, the teachings of WO2017 / 145016 can be used to securely exchange and verify data, which are incorporated herein by reference.

[0020] Embodiments of this disclosure provide improved blockchain-related methods, apparatus, and systems. According to one form of wording, such embodiments provide schemes for tracking items, at least one component of said item, and at least a portion of blockchain transactions associated with said item and / or component. The blockchain transactions may be stored on one or more of a plurality of resources, which may be distributed. Additionally or alternatively, said resources may be accessed to retrieve (i) confirmation of the validity of a transaction (e.g., a UTXO) and / or (ii) data enabling the determination of the validity of said associated transaction. Attached Figure Description

[0021] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0022] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0023] Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain.

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

[0025] Figure 4 This demonstrates how Merkle roots can be derived from a blockchain transaction set, as is known in the art.

[0026] Figure 5 Examples are provided of how a Merkle tree can be divided into subsets (or “segments”) according to embodiments of this disclosure, and then those subsets (or “segments”) can be assigned to appropriate verification resources.

[0027] Figure 6 This demonstrates how a Merkle tree can be divided into logical segments. Figure 5 Alternative examples.

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

[0029] Figure 8 A simplified flowchart of the steps involved in the illustrative method of this disclosure is shown.

[0030] Figure 9 Showing more details Figure 7 An illustration of an exemplary system.

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

[0032] Figure 11 (a) to Figure 11 (d) is a table showing examples of values ​​derived from the partial data used to identify the allocated resources.

[0033] Figure 12 This is a schematic diagram of a system that includes nodes, intermediate switches, and allocated resources, which have optional verifiers.

[0034] Figure 13 This is a diagram illustrating two transactions located in the Merkle tree of a blockchain block. Each transaction has allocated resources, and the allocated resources hold corresponding records.

[0035] Figure 14 'a' is a schematic diagram of an asymmetric tree structure, where the root node represents an item, and nodes and leaves represent components of that item. Figure 14 b indicates that... Figure 14 (a) The two subsequent blockchain transactions associated with the node or leaf.

[0036] Figure 15It is a schematic diagram of two tree structures in which blockchain transactions are processed in connection with, for example, a node or leaf of 14(a) and / or stored in an allocated resource (1104).

[0037] Figure 16 This is a flowchart illustrating the methods for processing tree structures.

[0038] Figure 17 It is a schematic diagram of a tree structure representing at least a part of the webpage architecture, where one of the nodes includes data and a digital signature.

[0039] Figure 18 This is a schematic diagram of a user's computer, which is configured to access data via the cloud and optionally access allocated resources.

[0040] Figure 19 It is a flowchart for establishing a tree structure that includes data with digital signatures.

[0041] Figure 20 It is a flowchart used to verify data in a tree structure, the data having a digital signature. Detailed Implementation

[0042] Exemplary embodiments of this disclosure are described below for illustrative purposes (and not for limiting purposes) and with reference to the accompanying drawings.

[0043] Different systems and methods can be used to implement a way of processing and / or storing information related to transactions (e.g., unspent transaction output UTXOs) and / or transactions (Tx) containing UTXOs, and these systems and methods can be configured and / or executed individually. Examples of "transaction database" and "block verification" are described below, where each example assigns a task to a resource, such as a distributed resource, which includes storing and / or verifying one or more transactions.

[0044] The following section describes an example of allocating / identifying resources using a "UTXO database," where information (e.g., records) is assigned to resources. Additionally, examples of verifying transactions and the techniques / management of verification, such as "block verification," are described below.

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

[0046] The techniques taught in this paper are suitable for using tree structures to track items and at least one component of said item. The tree structure schematically represents the relationship between an item and at least one of its components. The state of the item and / or its components can be associated with the tree structure via blockchain transactions. These transactions can be used to determine the verification and / or origin of the item and / or component, starting from the point where the tree structure is first used to track the item and / or component. Tracking can be performed using one or more tree structures. Each tree structure can represent the substitution relationship between the item and / or component and different items and / or different components. The tree structures can be independent, and multiple tree structures can be used to track items and / or at least one component of an item with migrated blockchain transactions (Tx). The tree structure can be a Merkle tree, binary tree, ancestor tree, asymmetric tree, or other unbalanced tree.

[0047] Tree-based data integrity schemes

[0048] Additionally or alternatively, to verify that an item (e.g., a node) is part of a tree structure, the integrity or authenticity of the data associated with the item (e.g., a node in the tree structure) can be determined. Integrity determination (e.g., through verification) can be achieved at a granular level, where each node or its components can be verified. Conversely, while Certification Authorities (CAs) can provide Secure Sockets Layer (SSL) for encrypted communication between web browsers and web servers, their global approval does not support granular-level data integrity.

[0049] Figure 17 This is an example of data organized in a tree structure. Data in a tree structure can be associated with data in a blockchain transaction (Tx), or with at least a portion of a blockchain transaction (Tx). Nodes in the tree structure, or each node, can authorize and / or approve data via digital signatures. Signatures are intended to verify the source or authenticity of the data.

[0050] Preferably, each node can be digitally signed. By processing the path of the tree structure including the data and the digital signatures of the creator and / or approver of the data, it is possible to verify whether at least one of the following is part of the tree structure: data; digital signature; and blockchain transaction (Tx). This can be achieved by establishing relationships between the nodes of the tree structure (e.g., by building a hash tree). In this way, the validity and integrity of the data or portions thereof of any node can be determined.

[0051] exist Figure 17In the example, tree structure 1700 represents the structure through which the URLs of webpage 1702 and its content can be accessed. A webpage can have an associated digital signature 1704, which can be combined with the webpage as a whole or with individual pieces of content. Multiple digital signatures can be used and associated with webpages as a whole and as individual pieces of content, allowing each component of the webpage (e.g., HTML content, links, files, attachments, etc.) to have its own digital signature. The data or portions of a component (e.g., the webpage) can be signed by digital signature 1704. Multiple digital signatures can be provided for data; for example, one digital signature for each of the content, links, and attachments.

[0052] The URL has data divided into components, including a top-level domain 1706, a second-level domain 1708, a subdomain 1710, two subdirectories 1712, and a corresponding path 1714. The webpage 1702 may include data, which includes at least one of content, links, and attachments. The content may include HTML content, files, and / or executable files.

[0053] Each of the components, levels, domains, directories, subdirectories, and paths can be represented in a tree structure and has an associated blockchain transaction (Tx) or a portion thereof. (See also: Regarding...) Figure 11 , Figure 13 , Figure 14 and Figure 15 As described, at least one of the following can be stored as part of the tree structure in the allocated resource 1104: data; digital signatures; blockchain transactions (Tx). Combinations of data, digital signatures, and blockchain transactions (Tx) can be created for storage in the allocated resource 1104. The allocated resource can hold records that enable efficient verification of data within the node (e.g., HTML content, files, and / or executable files, etc.) during processing.

[0054] Figure 18 This section illustrates an example of a system in which the methods described herein can operate. The first party 103a and its corresponding computer device 102a can be configured to access a webpage 1704 created by the second party 103b and its corresponding computer device 102b, which has been created with a URL (e.g., webpage domain name 1700) for access via a network (e.g., packet-switched network 101), as described herein and as... Figure 1 As shown. In the system 1100 with allocated resources, data can be processed on or through the allocated resource 1104, as also described herein.

[0055] Figure 19This is process S1900, used to process data into a verifiable tree structure. As a non-limiting example, this process is suitable for representing URLs and their components in a tree structure, such as... Figure 17 As shown. In S1902, a top-level domain is established, which corresponds to the root of the tree structure. In S1904, the URL component is added. In S1906, digital signature 1704 is added to each of these components. Components and / or digital signatures can be associated with the corresponding blockchain transactions.

[0056] When creating (S1908) a tree structure representing a URL, the components of that tree structure (e.g., the URL) are used as nodes. Digital signatures can be associated with data (e.g., additions, such as concatenation). Data and digital signatures can be hashed before and / or after the association (e.g., concatenation). Using all the components of the URLs associated in the tree structure, a hash tree can be determined. A record of the tree structure can be recorded on the blockchain (S1910). Verification data can be provided to each node and the data associated with that node, enabling the verification of the components of the URL (i.e., the nodes in the tree structure). Verification can use Simple Payment Verification (SPV) technology, for example, verifying the relationship of a path between one node in the tree structure and another node (e.g., the root node).

[0057] URLs can be monitored for changes (S1912), and with each update, no matter how minor, additions and / or modifications require processing of the original digital signature and / or new digital signature of the creator and / or controlling authority using the components of the URL before establishing the updated tree structure. Therefore, the data and / or content of the URL components (e.g., each page, link, etc.) can be digitally signed. Signatures and updates can be applied incrementally. In this way, each iteration of a webpage can be verified before accessing it. This not only enables machines to verify data and decide whether to execute or open content, but also allows tracing the source of any modifications (e.g., when data is digitally signed using the creator's digital signature). 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 (e.g., webpage content)) can be verified through the tree structure and / or digital signatures.

[0058] In general, process S1900 includes processing data to produce processed data associated with the digital signature of the creator and / or approver of the data. The examples herein relate to URLs and webpage content that can be represented, although the teachings herein can be applied to data in any tree structure containing data or processed data. Data, processed data, and / or digital signatures can be associated with a blockchain transaction (Tx) represented in a tree structure. In this way, at least one of the data, processed data, digital signature, blockchain transaction (Tx), and tree structure is recorded on the blockchain. The data, processed data, digital signature, blockchain transaction (Tx), and tree structure can be encrypted (e.g., hashed) before being recorded on the blockchain. Therefore, the tree structure can be configured as a hash tree.

[0059] Updates to data can produce updated, processed data, which may occur when updating a tree structure (e.g., a webpage). Due to its relationship with at least one parent node, an update to a node in the tree structure has a cascading effect, and at least the root node will change. In effect, this creates a second tree structure. Each modification to a node (e.g., a webpage) can be tracked and verified, for example, using a digital signature applied to the node in the tree structure. The root of at least each version of the tree structure (e.g., a hash of the root) can be recorded on-chain, making it possible to verify each version of the tree structure and the nodes within it. Therefore, processed data can be stored in nodes of either the tree structure or the second tree structure. Each node in either the tree structure or the second tree structure can include at least one of data, processed data, and / or a digital signature of a blockchain transaction (Tx) represented in the tree structure.

[0060] As a supplement to or alternative to storing tree structures (e.g., web pages with URLs) on-chain (S1910), data or its records may also be stored on private servers and / or Figure 12 The allocated resource 1104 in the system 1100 shown. Therefore, records of data used for verification and / or authentication can be saved and / or stored in the supporting resource 1104 along with the data or content.

[0061] The process in S1900 enables data in the tree structure to be configured for verification, for example, enabling the verification of web pages with URLs. In an exemplary scenario, machine 102a operates to access the content of a web page, which is a node in the tree structure. Before opening the web page, the machine attempts to verify and / or authenticate the content of the web page (e.g., the data of the web page). Unless it is valid and / or authentic, the machine will not open the web page or otherwise access its data content.

[0062] Figure 20 An example of process S2000 for verifying and / or authenticating data (e.g., the content of a webpage) in a tree structure via a URL is shown. In such an example, machine 102a can select (S2002) a webpage 1700 to be accessed via the Internet 101. The data to be accessed can then be associated with a blockchain transaction (S2004), thereby enabling on-chain verification of the data and its associated tree structure. Records containing such information required for verification can be stored on-chain in association with blockchain transactions. Additionally or alternatively, records containing the information required for verification can be stored in allocated resources 1104, which can provide efficient access to the information required for verification.

[0063] Once data is associated with a blockchain transaction (S2004), processing (S2006) represents the tree structure 1700 of the data to be accessed. In one example, the tree structure is a hash tree, and the webpage is a node in said hash tree and can be verified as part of that tree. Furthermore, a digital signature associated with the data (e.g., the webpage and its content) can be used to verify and / or authenticate the data. Therefore, verification (S2008) includes the path in the data's tree structure, and / or verification (S2010) includes the digital signature associated with the data. Such information can be stored on-chain and / or in allocated resources 1104.

[0064] The process determines (S2012) the verification of the data, and if the data is verified and / or authenticated, machine 102a accesses (S2014) the data; otherwise, access is prohibited due to invalid data, and alternative data to be accessed is selected.

[0065] In general, for example, process S2000 can be implemented by a browser, and only allows machine 102a to access a webpage or parts thereof if the data is valid and authentic. This can be achieved by processing the path of the tree structure including the data, processing the digital signatures of the creator and / or approver of the data, and verifying whether at least one of the following is part of the tree structure: data; digital signature; blockchain transaction (Tx).

[0066] The digital signature 1704 associated with data (e.g., webpage content) can be the public key of the data's creator and / or authenticator. Additionally or alternatively, the digital signature 1704 can be the public key of a blockchain transaction associated with at least one of the data, processed data, and / or the tree structure. The digital signature 1704 can be combined (e.g., cascaded) with the data before being integrated into the tree structure, thus becoming an inherent component in determining the validity of the data. Verification can then include determining that the digital signature is also part of the tree structure.

[0067] Any of the data, the processed data, the digital signature, and the blockchain transaction (Tx) can be used to identify and / or allocate the allocated resources 1104, in which verification data for the data to be verified and / or authenticated can be found. This data can be used to determine a key, which includes at least one of the following: an alphanumeric number; a binary number, and said number is used to determine the allocated resources. The data or its hash can be parsed to determine the allocated resources.

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

[0069] As taught in this article, you can combine the characteristics of the examples.

[0070] Using a tree structure for tracking

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

[0072] Tree structures can be used to determine the verification and / or origin of items and / or components. This can be achieved through associations between data within nodes and leaves, and preferably through blockchain transactions associated with them.

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

[0074] Processing tree structures 1400 enables the use of techniques such as root hashing and / or proof and simple payment verification to determine the authenticity of data in the tree structure.

[0075] Therefore, by associating an item and / or at least one component of that item with a blockchain transaction (Tx), which is represented in a tree structure, and processing that tree structure or a portion thereof, which represents an item and / or at least one component of that item, the validity of at least that item or component can be determined. Processing may include generating, storing, accessing, and maintaining at least one of the tree structure. Updates may be made to, for example, data associated with a record of an item or component or the entire tree structure, and the tree structure and associated items may be tracked.

[0076] By creating a tree structure 1400 to track items and / or their components, and by associating the item and / or at least one component of the item with a blockchain transaction, the verification and / or origin of the item and / or component can then be determined from the point where the tree structure is first used to track the item and / or component.

[0077] The tree structure can change over time when at least one of the data, state, and attributes of the items and components in the nodes and leaves is updated. Linking it to blockchain transactions enables tracking. Figure 14 (b) is a representation of the one being updated in root node 104, node 1402, or leaf node 1404, where the first associated blockchain transaction Tx n Updated to become TX n+1 Chained transactions can be made immutable and records can be determined based on the blockchain. For example, blockchain tokens can be used to manage data associated with nodes or leaves. In one example, only the root node 104 or its hash could be recorded on the chain, but it's also possible to record each of the leaves and nodes.

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

[0079] Once processing is complete, the tree structure can be used to verify whether at least one of the following is part of the item, at least one component of that item, and at least a portion of the blockchain transaction (Tx): The blockchain transaction can be used to implement processing, such as verification or storage. Combined Figures 10 to 13 Examples describing storage and verification technologies.

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

[0081] Alternatively or additionally, once processing is complete, the tree structure can be used to process and / or store at least one of an item, at least one component of that item, and at least a portion of a blockchain transaction (Tx) in the allocated resource 1104. The tree structure itself can be stored in the allocated resource. While each leaf and its associated data can be stored, for example, for verification purposes, the hash of the root node 104 of the tree structure can be additionally or additionally stored in the blockchain transaction, for example, on the blockchain ledger.

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

[0083] In another example, the tree structure can change over time; for example, the arrangement of nodes and leaves can be updated, reflecting updates to the state and / or configuration of items or information associated with said items or components of said items. Similarly, items and / or components can be associated with at least one blockchain transaction to create records for the tree structure, for example, recording each new arrangement. In practice, each item and component can be associated with its corresponding blockchain transaction. The tree structure can be a hash tree, and the root hash and / or hash of at least a portion of the data associated with the items or components represented by nodes and leaves can be recorded on a blockchain such as a public blockchain. Each time the tree structure changes, the blockchain transactions associated with the items and / or components can be updated. The data associated with the items can be updated, including the updated proof. In this way, the data associated with the items or components can be tracked. Furthermore, the data can be verified.

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

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

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

[0087] Figure 15 Further examples are shown in conjunction with this article. Figures 10 to 13The teaching technique allows each tree structure to be recorded in the allocated resource 1104. Additionally or alternatively, data associated with each node 1402 and / or each leaf 1404 (e.g., a record) can be stored in the allocated resource.

[0088] For example, X-ray data (components) may be generated by a hospital department and stored in records within a structured database (items). As taught herein, the structured database can be represented as a tree structure and used to track the database and its items. The database and the X-ray data therein may form part of the tree structure, with at least one of the database and the X-ray data associated with a blockchain transaction, allowing the tree structure to be processed to at least determine its validity. However, the X-ray data may be transferred to another item, such as a patient's record, and become part of another tree structure. Updating the blockchain transaction (e.g., updating the blockchain token storing data associated with the X-ray data) enables processing of the tree structure representing the patient's record to determine the validity of the X-ray data. Validity can be determined based on transaction history and / or based on records within the blockchain transaction representing X-rays that store proof (e.g., the validity of the data and / or a Merkel proof of its source). The validity of the X-ray as part of the hospital database from which the data originates can be determined, and the validity of the X-ray as part of the patient's record can also be verified. Therefore, items or components can be tracked across applications (e.g., end-to-end). Validity can be determined without compromising privacy (e.g., avoiding disclosure of the patient’s full records).

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

[0090] Data (e.g., records) associated with blockchain transactions representing items or components (where the item or component is already part of another tree structure) may further include proofs (e.g., further proofs or second proofs) that enable a third party to determine the validity of the data without knowing the complete tree structure or knowing the complete second tree structure. Records may contain historical data about items, enabling verification of their complete origin. Records may include proofs that a component (e.g., an airbag) is part of the tree structure of an item (e.g., a manufacturing facility, warehouse, or vehicle). This proof may include Merkel proofs.

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

[0092] In S1602, the processor may receive or retrieve a tree structure representing its items and / or components. Further, it acquires data associated with the tree structure, which may include information associated with the items and / or their components. This data may also be a hash of said information, or at least a portion of said information. For example, the processor may calculate a hash for each node 1402 and leaf 1404 and assign it a unique hash value based on the data stored in that node and / or the hashes of its child nodes.

[0093] In S1604, the processor processes the tree structure through association with blockchain transactions. These transactions can store data for items or components within their scripts. A blockchain transaction can be part of a blockchain token.

[0094] In S1606, an item or component can be verified as part of the tree structure. This can be done in allocated resource 1104 after or before the item and / or at least one component of that item associated with the blockchain transaction (Tx) in S1608, which is represented in the tree structure. Data (e.g., records of items or components) can be verified before storage and vice versa.

[0095] The verification technique presented in this paper proposes using a hash tree, where the nodes and leaves of the tree are hashed to produce a hash of the root. Other techniques can be implemented based on the teachings of this paper.

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

[0097] Using a tree structure or a portion thereof, the processor can compute the hash of each node 1402 in the tree, where the hash of a node is the hash of its child nodes (including leaf 1404) and they are concatenated. The processor can determine that the hashes are consistent from the tree to the root node, ensuring that the tree is valid and remains unchanged. This is achieved by the processor computing the hash of each node 1402 and leaf 1404 and comparing the parent node hash with the child node hash. Starting from leaf node 1404, the processor can traverse the tree upwards, comparing the hash of each parent node with the hash of its child nodes. If the hashes match, it means that the data stored in the child node has not been tampered with. This can be repeated for all nodes until the root node is reached. If all hashes are consistent, it means that the entire tree is real and has not been altered. Furthermore, the root hash, which summarizes the entire tree structure, can be verified.

[0098] By verifying the tree structure, items or components within it can be verified by comparing the provided data (e.g., data associated with replacing airbags in a vehicle or its hash value) with records in a previously stored or distributed tree structure.

[0099] Items or components can be verified using two or more tree structures by: combining provided data (e.g., data associated with replacing airbags in a vehicle or its hash value) with (e.g., based on...) tree structures. Figure 15 The records of the first and second tree structures previously stored or distributed are compared. Having two or more tree structures can enhance the source of an item, which can be beneficial if the history of an item or component spans two or more applications and corresponding tree structures. Therefore, the processor can process the records of an item or component to verify whether at least one of the item, at least one component of the item, and at least a portion of a blockchain transaction (Tx) is part of that tree structure or another tree structure.

[0100] Data (e.g., records) associated with an item, at least one component of the item, and at least a portion of a blockchain transaction may include at least one of the following: the history of the tree structure or each tree structure in which the associated blockchain transaction originates; the history of the allocated resources in which the blockchain transaction is stored; and proof that enables verification of whether the item, component, or blockchain transaction is part of a tree structure (e.g., a first tree structure and / or a second tree structure).

[0101] Items, components, or blockchain transactions can be verified by comparing them with stored data (e.g., manufacturing facility databases, warehouse inventory, and vehicle maintenance records), which can be stored on a blockchain. Data (e.g., product records) can be used to determine its validity and origination from a specific tree structure. This determination can be achieved by limiting verification to the minimum necessary for the item or component, thereby maintaining privacy. This can protect the privacy of confidential information (e.g., medical records).

[0102] As mentioned above, combined Figure 13 and Figure 15 The tree structure or a portion thereof can be stored as data (e.g., records) within the allocated resources. Any portion of the data associated with an item, component, or blockchain transaction can be used to identify and / or allocate the allocated resources. A portion of the data can be a transaction, such as an Unspent Transaction Output (UTXO) and / or a transaction (Tx) containing a UTXO. Figure 11 The associated description provides an example of how data can be used to determine the allocated resources.

[0103] The teachings of this paper are applicable to processing secure and / or confidential data (e.g., medical records) because they enable the verification of items or components within a tree structure without compromising the privacy of other items or components. Furthermore, the methods for processing tree structures can be extended by allocating storage for at least one of the items or components of an associated blockchain transaction in a pseudo-random manner. Therefore, the allocation of resources can be load-balanced, which can be achieved by determining a key using at least one of the data associated with an item, component, or associated blockchain transaction. This key can include at least one of the following: a number consisting of letters and numbers; and a binary number. The key can be determined by parsing at least one of the data associated with an item, component, or associated blockchain transaction. For example, the data associated with a component can be hashed and / or parsed to determine the key and the associated allocated resources 1104.

[0104] Data (e.g., records associated with at least one of an item, component, or associated blockchain transaction) may include at least one of the following: a Merkle tree recording the block of the transaction (Tx); a Merkle root for recording the block of the transaction (Tx); a Merkle path that enables the determination of the value of the Merkle root (for recording the transaction (Tx)) based on the hash of the blockchain transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions within a blockchain block; functions 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).

[0105] Data (e.g., a record associated with at least one of an item, component, or associated blockchain transaction) may include at least one of the following: proof that the associated blockchain transaction is part of the tree structure by using at least one of the hash of the root of the tree structure and a path (which makes it possible to determine the hash of the root of the tree structure used to record the associated blockchain transaction based on the hash of the blockchain transaction); and proof.

[0106] Record

[0107] Figure 13 Two transactions derived from blockchain 150 are shown. Examples of the methods described herein include at least one of the following: generating, storing, processing, accessing, and maintaining records of at least a portion of a transaction (Tx) in one of a plurality of resources 1104. The allocation and / or identification of the resource corresponding to each transaction is described below in conjunction with a UTXO database, which is used, for example, for allocation using hash table techniques. Resource 1104 may be one of the plurality of resources that make up the database.

[0108] Figure 13 Two Merkle trees are shown, constructed using sets of transactions within a block to determine the Merkle root contained in the block header. Transaction Tx n and transaction Tx n+1 Each transaction in the tree is part of the corresponding Merkle tree, at least as follows: Figure 4 As shown.

[0109] The record includes transaction data used to identify the transaction (e.g., Tx). n or Tx n+1At least a portion of the transaction is contained in the Merkel path of blockchain block (B). Either alone or in conjunction with the examples taught herein, a record holds data that enables efficient and cost-effective referencing and / or retrieval of information associated with the transaction. Specifically, the information held in the record enables a third party wishing to verify the transaction to identify the allocated resources holding the associated record and to retrieve transaction data used to determine that at least a portion of the transaction is contained in the Merkel path of blockchain block (B). For example, the record holds a Merkel proof that the transaction is part of a Merkel tree that determines the Merkel root of the block containing the transaction.

[0110] A record can hold a set of data associated with a transaction. For example, a record can be simplified and / or contain cascaded data for efficient storage. The information in a record can be configured for reference. For example, a record can include a data catalog. The data catalog can be structured, for example, with indexes added, for selectively identifying and / or retrieving information associated with a transaction. The data catalog can hold a set of transaction data, such as a Merkel proof that enables Simple Payment Verification (SPV).

[0111] Records may include a data catalog, which may be managed by the resource and / or verifier 1106. Records are used to hold information that can be stored / associated with transactions, such as UTXOs, for verification, status indication, holding signatures, and transaction status, at least one of these. For example, a record may include at least a portion of a script that defines "OP_PUSH_TX" to impose conditions on a transaction. Therefore, records can provide a catalog or repository associated with transactions.

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

[0113] Records may be stored in a database. The database may include multiple resources 1104 and / or verifiers 1106. Records may include blockchain transactions (TX0) that include at least one data item (D). Additionally or alternatively, records may include at least one other blockchain transaction (TX1) that is necessary to confirm that the blockchain transaction (TX1) is included in the Merkel path of blockchain block (B).

[0114] Records can be data directories, stored in a database, or distributed across multiple databases. The database itself can be distributed across multiple resources. The storage of records (e.g., the information and / or data taught herein) can be applied to and / or support the efficient allocation, referencing, and access of records associated with nodes (e.g., Metanet nodes) and the associated Metanet protocols.

[0115] The entire contents of the following applications are incorporated herein by reference:

[0116] -PCT / IB2019 / 059793, which relates to indexes and structured nodes.

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

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

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

[0120] -PCT / IB2019 / 060226 and PCT / IB2019 / 059807 support splitting data across multiple nodes.

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

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

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

[0124] Additionally or alternatively, the record includes transaction data used to determine that at least a portion of a transaction (Tx) is included in the Merkel path of the blockchain block (B), and the record may hold a Merkel path from the transaction (TX0) to the root of the Merkel tree of the blockchain block (B). The Merkel path may at least include the minimum blockchain transaction required to establish or verify that the blockchain transaction (TX0) is included in the blockchain block (B). The record of this paper provides an efficient and effective method for verifying transactions. This paper, combining the allocation and identification and / or verification techniques of the resources holding the record, provides an improved system for managing and / or using transaction data. Transactions can be derived from blockchain blocks.

[0125] A blockchain transaction (TX0) can be used alone or in combination with at least one other blockchain transaction (TX1) to verify that the blockchain transaction (TX0) is included in the Merkel path of the blockchain block (B). A data item (D) can be a record or part of information stored in allocated resources, and can be at least one of the following: stored in association with a script in the transaction; or stored as metadata in the transaction. Generally, records include verification data required to verify the transaction, such as unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0126] Blockchain blocks can be stored on or associated with the following: blockchain ledger; and / or off-chain storage resources.

[0127] The record may include the history of at least one previous transaction, i.e., the transaction data of at least one previous transaction. The history may include transactions that have not spent transaction outputs (UTXOs) and / or transactions (Tx) that contain UTXOs. The at least one previous transaction may be the transaction preceding the last transaction.

[0128] The record may further include the history of the allocated resources, which at least processed and / or stored the previous transaction. The record may include links to the allocated resources that held the previous transaction. The record may hold the history of multiple previous transactions, including unspent transaction outputs (UTXOs) and / or transactions (Tx) that contain UTXOs.

[0129] In this way, history enables third parties using the records to retrieve the latest transactions and, if necessary, efficiently identify the previous transaction without performing further lookups or searches. History can provide a set of shortcuts to old directories or key records, data, or information. History may include at least one of the following: a set of transaction data used to determine Merkel proofs of multiple previous transactions; links to correspondingly allocated resources that process and / or store multiple previous transactions.

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

[0131] Records may include flags and / or status indicators for transaction data, such as unspent transaction outputs (UTXOs) and / or each input of a transaction (Tx) containing UTXOs. For example, the indicator may be one of “seen,” “in-block,” and “double-spent,” thus providing an efficient reference to the status of transaction data.

[0132] Records can hold any amount of transaction data and / or supplementary data, such as verification data. Using records provides an alternative method for searching, identifying, and processing transaction data on the blockchain. Records can consolidate critical data, thereby minimizing the computational costs of using transactions and performing operations using blockchains and blockchain blocks. The record may further include at least one of the following: a Merkle tree recording the block of the transaction (Tx); a Merkle root recording the block of the transaction (Tx); a Merkle path capable of determining the value of the Merkle root for recording the block of the transaction (Tx) based on the hash of the transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions within a blockchain block; functions 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 signature message for determining the transaction state.

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

[0134] The examples and associated systems in this paper enable the use of a database comprising at least one record, which includes: a blockchain transaction (TX0) comprising at least one data item (D); and at least one other blockchain transaction (TX1) which is necessary to confirm that the blockchain transaction (TX1) is included in the Merkel path of the blockchain block (B).

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

[0136] The method described in this paper can use a blockchain transaction (TX0) and at least one other blockchain transaction (TX1) to verify that the blockchain transaction (TX0) is included in the Merkel path of the blockchain block (B).

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

[0138] A transaction may further include at least one of the following: transaction ID (TxID); protocol identifier; discretionary public key (DPK); discretionary transaction ID (DTxID).

[0139] The aforementioned records (e.g., information and data associated with, derived from, or related to transactions) can be stored in the allocated resources using the following methods.

[0140] UTXO Database

[0141] Figures 10 to 12The various stages of the method for deriving data from the blockchain, the table for allocating resources 1104, and the illustration of the system for implementing the method are shown respectively. Data is obtained from a peer-to-peer (P2P) network 106 and / or a blockchain network 150. At s1000, data can be obtained or retrieved, for example, by requesting and retrieving one or more blocks from blockchain 150. Retrieval may include downloading at least a portion of a blockchain block containing multiple blockchain transactions. Data needs to be retrieved or otherwise obtained, such as by obtaining, copying, or reading data from blockchain blocks, when data is needed to establish stored and / or processed historical (e.g., already recorded in block 151) transaction data related to unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. UTXOs are currently in a mempool or in future transactions. UTXOs can be received by connecting to a network, for example by implementing a node 104 that receives transactions broadcast on the network.

[0142] Therefore, overall, Figure 12 System 1100 uses a portion of data derived from the blockchain to determine a key and allocate corresponding resources, which will store information associated with the data, such as information associated with unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. For clarity, the information associated with the data derived from the blockchain will be stored in the resources for efficient and cost-effective reference. The data may include unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs. A portion of the data is used to determine a key, which in turn determines the allocated resources, which will 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) containing UTXOs. At s1002, a portion of the data is used to identify or allocate corresponding resources 1104, such as the allocated resources. At s1004, resource 1104 operates to perform at least one of a database for generating, storing, and maintaining information, wherein the information includes data associated with UTXOs and / or transactions. Information may include indications of the validity of UTXOs and / or the ability to determine validity, for example, using SPV techniques. Information about the data may include, for example, details of the blocks in which the data was obtained, such as the block ID, the Merkel path of the unspent transaction outputs (UTXOs) and / or the transaction (Tx) containing the UTXOs, and the status of the validity of all UTXOs within the transaction.

[0143] Resource 1104 can operate to store information that can be used by other resources to verify UTXOs and / or process data to generate indications, such as flags indicating validity. Additionally or alternatively, resource 1104 can delegate the determination of the validity of a transaction or UTXO to verifier 1106 at s1006. At least a portion of storing and / or processing UTXOs and / or transactions (Tx) can be implemented in the following situations: in an allocated resource, for example, resource 1104 actively manages the information and maintains a database associated with each UTXO therein, e.g., the resource can manage itself; and / or is performed by an allocated resource, for example, the resource acts as a controller and is used as a system 1100 to manage sub-resources for storing and / or processing information; and / or is associated with an allocated resource, for example, resource 1104 operates as part of system 1100, such as... Figure 12 As shown, in a non-limiting example, node 104 provides transaction and UTXO information to switch 1102 (e.g., a router), which operates to determine which of a plurality of resources 1104 is assigned a task to generate, hold, and / or store UTXO information in a database. Overall, resources can be implemented and executed. Figure 10 One or more operations within the operations. Figure 12 System 1100 is shown, which has a separate execution capability. Figure 10 Components for operation.

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

[0145] It is possible to retrieve and / or receive and parse a portion of the data from unspent transaction outputs and / or transactions (Tx) containing UTXOs. Parsing can determine which resource is assigned the task of storing information. Parsing can be performed by resource 1104 or switch 1102. At least one of node 104, switch 1102, and resource 1104 can derive partial data from the blockchain. When parsing is performed by node 104 or switch 1102, the information is directed to the allocated resource. Identifying and / or allocating processing and / or storage resources can be performed by nodes and / or switches acting as intermediaries. They are connected to multiple allocated resources, and the nodes or switches operate as managers of many resources 1104, determining the specific resource managing the UTXOs / Tx. When resource 1104 performs parsing, 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.

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

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

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

[0149] A key is used to determine which resource 1104 will hold the corresponding information associated with that key. Therefore, the resource holds a data structure, such as a database or hash table implementing an associative array. In other words, data associated with UTXOs and / or transactions is used to determine the key, and the key is used to determine the resource holding the information associated with the UTXOs and / or transactions. The data and key not only enable resource allocation but also allow the retrieval of stored information by using the key to look up and access the information.

[0150] The data, the key, and the resulting hash include at least one of the following: a number containing letters and numbers; and a binary number. This number is used to determine the allocated resources.

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

[0152] Potential recipients of a UTXO need to verify the UTXO before compiling and broadcasting transactions that consume it. Known verification techniques are slow, resource-intensive, and computationally expensive. By using partial data of the UTXO and / or associated transactions, information used to verify the UTXO, or to allow verification of the UTXO, can be stored in resources. A key can be determined using the UTXO-specific partial data, which then determines the allocated resources from which the associated information can be stored and retrieved.

[0153] Using a transaction identifier (TxID) as a non-restrictive example, TxID is usually in hexadecimal form, but can also be represented as a binary number. Figure 11 (a) to Figure 11 (d) is a table illustrating how a portion of the data is used to determine the allocated resources. Some data (e.g., TxID) may be directly parsed or processed, such as through hashing. Figure 11 In (a), the TxID is parsed such that the first three digits of the TxID's binary form are selected as the key, and resources are allocated based on the binary value. For example, information associated with the TxID, which has a binary number whose first three digits are "101", is allocated for storage / processing in the allocated resource "6". By using the first three digits, the binary number can identify one of eight resources. Figure 11(c) illustrates how to extract the first four digits of a TxID in binary form to support allocation among 16 resources, such as allocating information associated with a TxID that begins with the first four digits of a binary number "1011" for storage / processing in the allocated resource "12". Alternatively, the hexadecimal value of the TxID can be used, such as... Figure 11 As shown in (b), where a single hexadecimal value is mapped to a resource, such as "c" to "13", and... Figure 11 In (d), a range of hexadecimal values ​​is assigned to the resource, for example, the information associated with a TxID that begins with "76" is assigned to resource "8".

[0154] Alternatively, a portion of the data can be processed, for example, by hashing it to produce a hexadecimal or binary number, so that portion of the data, and subsequently the key used to identify / allocate resource 1104, is not limited to TxID.

[0155] The portion of data selected from a transaction or its UTXO, or the value processed (e.g., a hash value), is pseudo-random. Resource allocation is load-balanced, meaning that a portion of the data used to determine the key for resource allocation is pseudo-random and distributed across multiple resources for processing and / or storage. Thus, the information associated with a transaction / UTXO is distributed across multiple resources. This resource-balanced allocation minimizes the risk of some processing resources being idle while others are overloaded, leading to performance degradation or even failure. The resilience, performance, and / or efficiency of System 1100 are improved.

[0156] Therefore, the data and portions of the data can be used to (i) determine the allocated resources, and thus (ii) provide reference for identifying resources and / or information associated with data in the resources (e.g., in a database).

[0157] Thus, some data is derived from the blockchain, and keys and corresponding resources are determined. These resources will store information associated with the data, namely, information associated with unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

[0158] Participants seeking to verify the validity of a UTXO may use the UTXO and / or a portion of the transaction holding the UTXO to identify resources holding information that can be used to determine the validity of the UTXO and / or the transaction. This information may include flags or tags associated with and indicating whether the UTXO is locked or unlocked, such as invalid or valid, and suitable for inclusion in subsequent transactions. Additionally or alternatively, this information may include records of the UTXO and / or the transactions holding the UTXO, enabling participants to efficiently and independently verify the UTXO.

[0159] A record may include at least in part one of the following: a Merkle tree recording the block of the transaction (Tx); a Merkle root for recording the block of the transaction (Tx); a Merkle path, from the hash of the transaction (Tx), which is capable of determining the value of the Merkle root for recording the block of the transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions within a blockchain block; functions 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).

[0160] Resources may include the information and records necessary to determine the validity of a UTXO. Additionally or alternatively, resources may generate, on their own or through the verification s1006 of verifier 1106, records verifying and / or supporting the verification of the UTXO. Resources 1104 and / or verifier 1106 may perform at least one of the following: verifying and / or validating the UTXO; performing at least a portion of a Simple Payment Verification (SPV) process for the UTXO; confirming whether a given blockchain transaction (Tx) is included in a blockchain block; generating a hash of at least one blockchain transaction in the blockchain transaction, using the hash to construct a Merkel path and / or checking whether the hash matches a transaction identifier (TxID) in the block header of the blockchain block; and determining a Merkel proof for the UTXO.

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

[0162] Overall, system 1100 includes resource 1104, which operates to provide a UTXO repository for generating, storing, and / or maintaining information and / or records associated with multiple unspent transaction outputs (UTXOs), each UTXO being associated with a transaction (Tx) in multiple blockchain transactions (TXs) of a blockchain block. The resource can use partial data derived from the blockchain to record, search, and / or process information and / or records to identify and / or allocate the resource, wherein the data from which partial data is derived includes unspent transaction outputs (UTXOs) and / or transactions (Tx) containing UTXOs.

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

[0164] After receiving a UTXO to be included in a transaction (e.g., as part of a payment or transfer of digital assets), participants can request and / or obtain verification information and / or records from the allocated resources.

[0165] When a participant accesses information and / or records from the allocated resources, the participant may perform at least one of the following: verify a UTXO and / or a transaction (Tx) containing the UTXO; and / or determine the validity of the UTXO and / or the transaction (Tx) containing the UTXO. Verification performed by at least one of the resources 1104, the verifier 1106, and the participant may include: verifying and / or validating at least one blockchain transaction; and / or ii) performing a Simple Payment Verification (SPV) process; and / or iii) confirming whether a given blockchain transaction (Tx) is included in a blockchain block; and / or iii) generating a hash of at least one blockchain transaction in the blockchain transactions, using the hash to construct a Merkel path, and / or checking whether the hash matches a transaction identifier (TxID) in the block header of the blockchain block.

[0166] After verifying the UTXO, the participant or another participant may prepare and / or transmit a transaction (Tx) that takes the UTXO as input.

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

[0168] Block verification

[0169] Traditionally, nodes in a blockchain network maintain a global ledger of all transactions on the blockchain. This global ledger is a distributed ledger, and each node can store a complete or partial copy of it. Transactions affecting a node's global ledger are verified by other nodes, thus maintaining the validity and integrity of the global ledger. Those skilled in the art should understand the details of implementing and operating a blockchain network.

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

[0171] As described above, according to one or more exemplary blockchain networks and protocols, mining nodes compete to create the next block in the blockchain. To assemble a block, a miner constructs it as a set of transactions from an unconfirmed transaction pool (“mempool”). The miner then attempts to complete a Proof-of-Work (PoW) puzzle regarding the block it has assembled. If the miner manages to complete its PoW before receiving notification that any other miner has successfully generated its own block and completed its PoW, the miner propagates the block by sending it to peer nodes on the network. These nodes verify the block and then further forward it to other nodes in the network. If the miner receives notification that another block has been completed before completing its own PoW, the miner abandons its efforts and begins attempting to build the next block.

[0172] Therefore, faster block propagation helps avoid wasting effort (and associated energy) on behalf of miners and verifying nodes. By providing a solution that enables faster block verification and thus propagation, this invention offers enhanced network performance. This solution reduces the required computation time and workload, thereby reducing the energy required by the network. This solution provides a more efficient network in terms of resources and time. Ultimately, this solution provides an improved (blockchain) network.

[0173] In some exemplary implementations of blockchain, each node that receives a block first verifies the block before sending it to other nodes. The time required to verify a block slows down its propagation through the network. It should be noted that some blockchain implementations (including evolutions of existing protocols) may perform block verification only at a subset of nodes rather than at every node in the network; however, block verification at a majority of nodes is likely to remain a feature of any blockchain implementation to prevent invalid blocks from spreading through the network.

[0174] Verifying a block involves confirming that the block conforms to the prescribed standards set by the applicable blockchain protocol. Exemplary standards applicable to one or more protocols may include functions such as CheckBlock and CheckBlockHeader. In addition to confirming that the block itself conforms to the prescribed standards, it is also possible to evaluate whether each transaction within the block conforms to transaction-level standards. For example, transaction-level standards applied in one or more exemplary protocols may include the AcceptToMemoryPool, CheckTransaction, and CheckInputs functions.

[0175] Specific examples of block-level standards (based on one or more known protocols) may include:

[0176] ● The block data structure is syntactically valid.

[0177] ● The block header hash is less than the target difficulty (forces proof-of-work).

[0178] ● The block timestamp is less than two hours from now (taking into account time errors).

[0179] ● The block size is within an acceptable range.

[0180] ●The first transaction (and only the first transaction) is the Coinbase-generated transaction.

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

[0182] Specific examples of transaction-level standards (based on one or more known blockchain protocols) may include:

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

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

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

[0186] ●None of the inputs have an empty hash.

[0187] ●nLockTime is less than or equal to INT_MAX.

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

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

[0190] ● The unlock script scriptSig can only push numbers onto the stack, while the lock script scriptPubkey must match the isStandard form.

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

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

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

[0194] ● Use the referenced output transaction to obtain the input values, and check whether each input value and the sum are within the allowed range of value x, i.e., 0. <x<21·10 6 .

[0195] ●A matching transaction must exist in the block in the pool or the main branch.

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

[0197] ● The transaction cost must be sufficient to obtain input for an empty block.

[0198] ● Each input unlock script must be verified against the corresponding output lock script.

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

[0200] According to this application, methods and apparatus for accelerating block verification to facilitate faster block propagation in a network are described.

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

[0202] Specifically, embodiments of this disclosure provide improved verification and security solutions for processing related or associated data records stored in a tree structure. The tree can be a binary tree or a mesh structure. As known in the art, a tree structure can be decomposed into smaller trees (which may be referred to herein as tree “segments,” “subsets,” or “parts”), where each segment comprises a subset of data records in the entire tree and has its own root. Advantageously, embodiments of this disclosure utilize this feature to provide methods and systems for distributing and parallelizing the processing of related data records across multiple processing resources.

[0203] In exemplary embodiments of this disclosure, multiple data records include blockchain transactions that are related by forming nodes within a Merkle tree. This Merkle tree has a root that is already present in or may be included in the block header of blocks representing transactions according to the blockchain protocol, such that the root provides a path that can be followed to each leaf within the tree (i.e., the transaction ID (TxID)). While the blockchain protocol in some examples of this disclosure is the Bitcoin protocol or derived from it, other protocols are also within the scope of this disclosure.

[0204] In one example, processing multiple transactions includes verifying at least a portion of a blockchain block, which comprises multiple blockchain transactions and the root of a Merkle tree for that block. These examples are non-limiting, and the techniques disclosed herein can be used for non-blockchain-related data and / or processes other than verification. For example, embodiments can be used to store, construct, search, and / or maintain any type of data records that can be represented in a Merkle tree. Databases and other known storage resources can be used instead of a blockchain ledger, or a blockchain ledger can be utilized.

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

[0206] For completeness, and for reference Figure 3 and Figure 4The Merkle tree and its use in representing blockchain transactions will be discussed below.

[0207] Merkel tree

[0208] See Figure 3 Merkle trees are hierarchical data structures that enable secure verification of datasets. In a Merkle tree, each node provides an index pair (i,j), denoted as N(i,j). The indices i and j are simply numeric labels associated with specific positions within the tree.

[0209] A characteristic of Merkle trees is that the construction of each node is governed by the following equation:

[0210]

[0211] Where H is the cryptographic hash function.

[0212] Figure 3 The diagram shows an example of a binary Merkle tree constructed based on these equations. As can be seen from the diagram, the case i = j corresponds to a leaf node, which is simply the data D. i The hash corresponding to the i-th group. The case i≠j corresponds to an internal node or parent node, which is generated by recursively hashing and cascading child nodes until a parent node (Merkelgen) is found.

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

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

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

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

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

[0218] For Merkle trees in some known blockchains, the hash function is double SHA256, that is, the standard hash function SHA-256 is applied twice: H(x) = SHA256(SHA256(x)).

[0219] The main function of a Merkle tree is to verify a specific data packet D. iThere are N data packets. The member of a list or set. This verification mechanism, known as Merkel proof, involves verifying the identity of a given data packet D. i The Merkel root R is obtained by taking a set of hashes called Merkel paths. The Merkel proof of a packet is simply the minimum list of hashes needed to reconstruct the root R through repeated hashing and concatenation, often referred to as an "authentication proof".

[0220] If the prover knows all groups D0,…,D N-1 If the order of these conditions is determined, an existence proof can be performed simply. However, this does require significantly more storage overhead than a Merkel proof, and the entire dataset must be available to the prover.

[0221] The comparison between using Merkle proofs and using the entire list is shown in the table below, where a binary Merkle tree is used and it is assumed that the number of data blocks N is exactly a power of 2.

[0222] The following diagram illustrates the relationship between the number of leaf nodes in a Merkle tree and the number of hashes required for a Merkle proof (the Merkle proof itself).

[0223]

[0224] In this simplified scenario (where the number of packets equals the number of leaf nodes), it has been found that the number of hashes required to compute the Merkel proof scales logarithmically. Clearly, computing a Merkel proof involving log₂N hashes is far more efficient and practical than storing N data hashes and computing the explicit proof.

[0225] Given a Merklein symbol R, the goal is to prove that data block D0 belongs to an ordered list represented by R. Merkel's proof can be performed as follows:

[0226] i. Obtain Merklegen R from a trusted source.

[0227] ii. Obtain the Merkel proof Γ from the source. In this case, Γ is a set of hashes:

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

[0229] iii. Calculate Merkel's proof using D1 and Γ as follows:

[0230] a. Hash the data block to obtain:

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

[0232] b. Concatenate with N(1,1) and perform hashing to obtain:

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

[0234] c. Concatenate with N(2,3) and perform hashing to obtain:

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

[0236] d. Concatenate with N(4,7) and perform hashing to obtain the root:

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

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

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

[0240] 1. If R′=R, then it confirms the existence of D0 in the tree, thus confirming the dataset.

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

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

[0243] SPV

[0244] Simple Payment Verification (SPV) leverages these characteristics of Merkle trees, as first proposed 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 parties use the same type of SPV wallet. An SPV wallet stores the user's private and public keys, unspent transactions, and block headers that uniquely identify blocks so they can be located on the blockchain. As explained, the block header includes a data field providing a unique summary or fingerprint of the entire block's content, as well as a field providing the Merkle root used for that block. The Merkle root is generated by repeatedly hashing pairs of transaction IDs (TxIDs) within the block until a single hash is produced. The Merkle root provides an efficient and secure mechanism for verifying whether a transaction is part of a block, as it allows user and merchant nodes, such as wallets, to verify specific transactions locally without downloading the entire blockchain. This is advantageous for users who do not need or wish to run a full node but only need to perform localized checks to determine whether a specific transaction is in a specific block (e.g., parties such as merchants and customers who want to perform transfers between them). In short, SPV enables such users to search a Merkle tree with a given root to check (i.e., verify) whether a specific transaction is included in a specific blockchain block without having to download and store the entire blockchain.

[0245] Therefore, SPV wallets offer at least the advantage that power- and storage-constrained devices such as mobile phones and laptops can operate within the blockchain ecosystem because they only require verification of whether a transaction has been validated (hence the term "simple payment verification"), rather than performing a full check of the blockchain as with other forms of wallets. Since SPV wallets only download block headers and do not include any transactions, this significantly reduces the storage space, energy, and processing resources required for verification. For reasons explained below, SPV wallets are particularly well-suited for use with embodiments of this disclosure, and the term "verification" is used herein to encompass SPV checks.

[0246] Transaction blocks

[0247] Figure 4An example of a blockchain block is illustrated. Each block contains a block header and a set of transactions. The block header includes a hash of the previous block header, i.e., the hash of the block header of the block upon which the current block is built. The block header also includes the Merkle root of a Merkle tree constructed using that set of transactions. Each transaction is first hashed (e.g., double-hashed) to generate a transaction identifier (TxID). The transaction identifier is then used as a leaf node in the Merkle tree. Pairs of transaction identifiers are then concatenated and hashed to form corresponding internal nodes in the first inner level of the Merkle tree. Pairs of internal nodes in the first inner level are then concatenated and hashed to form corresponding internal nodes in the second inner level of the Merkle tree. This 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.

[0248] The following describes embodiments of this disclosure, which are referred to in detail below. Figure 5 , Figure 6 and Figure 7 .

[0249] Merkle tree segments that identify blocks

[0250] Suppose a specific party (e.g., Alice) wishes to verify some transactions. According to embodiments of this disclosure, at least one subset of transactions is identified, where this subset forms a segment of the entire Merkle tree used for the block, and / or is represented by a segment of the entire Merkle tree used for the block. Therefore, a transaction block can be logically divided into multiple segments based on the Merkle tree of the block, each segment comprising a subset of the transactions of the block, and each segment having its own root node (or “root hash”). This common root hash is sometimes referred to hereinafter as a “segment hash” to distinguish it from the root hash of the entire block. Transactions at the same level within a segment (i.e., the lowest level, sometimes referred to as a “leaf level” or “leaf layer”) are siblings. All transactions in a given segment share the common root node of that segment. This common root node can belong to an adjacent level in the Merkle tree, i.e., the level immediately above the lowest level. Alternatively, the common root node can belong to a higher level. Typically, the common root node can belong to any level between the lowest level of the Merkle tree and the Merkle root.

[0251] Block-based Merkle trees offer significant technical advantages by breaking down blocks into smaller parts, including the ability to quickly and efficiently distribute transactions across multiple verifiers. For example, since certain exemplary blockchain protocols use binary trees, binary distribution can be implemented across multiple machines. By using small binary tokens as an indexing system for segments, the position of each segment within the entire Merkle tree can be quickly calculated, allowing the segments to be reassembled after verification has been completed, thereby reconstructing the complete Merkle tree for the block. This binary indexing method will be discussed in more detail below.

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

[0253] refer to Figure 5 and Figure 6 This further illustrates the key points explained above, where Figure 5 An example is shown of how a Merkle tree can be divided into separate parts 502 to be assigned to the verifiers. Figure 5 In the example, each arrow represents a corresponding transaction, which is hashed to form a corresponding transaction identifier, used at the corresponding leaf node of the Merkle tree. The top of the Merkle tree is the block Merkle root. In this example, the transaction block represented by the Merkle tree contains 32 transactions. However, it should be understood that this is merely an illustrative example, and typically, 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 sections 502a to 502d, indicated by dashed boxes. Each section 502 is linked by a corresponding public internal node (internal hash) 504 of the Merkle tree, indicated by a solid circle. Each section 502 represents eight transactions. In this example, the public internal node 504 belongs to the fourth level of the Merkle tree. According to the embodiments described herein, each corresponding portion 502 (or more precisely, a transaction that forms and / or represents a portion) is assigned to a corresponding verifier for processing, for example, for verifying transactions belonging to the corresponding portion 502.

[0254] Figure 6 Another example of how a Merkle tree can be divided into parts 602 is shown. Figure 6 Merkel tree in Figure 5The Merkle tree in this example is the same as the one in the example. Now, in this example, the Merkle tree is divided into eight parts 602a to 602h, with each part 602 representing four transactions. In this example, the common internal node 604 belongs to the third level of the Merkle tree. Conversely, it can be... Figure 5 and Figure 6 The Merkle tree is divided into more (e.g., 16) or fewer (e.g., 2) parts 502, 602. Typically, the Merkle tree formed by the transaction set of a block can be divided into any number of parts 502, 602, where each part includes at least two transactions.

[0255] Assign segments to the corresponding verification resources

[0256] Following the identifier, a subset of transactions is distributed across multiple verification resources; for ease of reference, these multiple verification resources can also be referred to as "verifiers." Figure 7 and Figure 9 In the diagram, multiple verifiers are shown as resources A through D (704a through 704d). The allocation process can be performed by... Figure 9 The components shown, such as component 904, are dedicated units used to guide or influence, but are not limited to this.

[0257] Each verifier (704a to 704d) may include one or more processing resources. Therefore, at least one of the multiple verifiers (704a to 704d) may be or include at least one of the following: one or more virtual machines, one or more servers, one or more GPU-based computing resources, one or more threads, and / or one or more multiprocessor systems, etc. Essentially, any one of the multiple verifiers may consist of any one or more types of processing resources or combinations of processing resources, and each verifier is capable of verifying one or more transactions that are related to each other through segments of the Merkle tree of blocks. The multiple verifiers (704a to 704d) and other system components form a collective resource or entity 700, which will be referred to as a "(distributed) verifier node".

[0258] Preferably, the distribution includes assigning each segment to a corresponding verifier among multiple verifiers. The verifiers can be configured at least as follows:

[0259] ● Perform operations on one or more transactions, which constitute one or more segments that have been allocated to the transactions;

[0260] ● Verify one or more transactions to confirm whether those transactions conform to the blockchain protocol; and / or,

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

[0262] The activities of the verifiers and the assignment of subsets to different verifiers can be guided by the controller. Figure 7 The diagram illustrates how controller 702 assigns subsets of transactions A through D from the corresponding tree segments to verifiers 704a through 704d, respectively. The system-level controller 702 coordinates the activities of systems or devices 704a through 704d within the distributed verifier nodes and can control or influence tasks, such as identifying tree segments using the Merkle tree of the block, assigning the identified segments to the corresponding verifiers, reordering the verified tree segments into a complete Merkle tree for the block, and / or ordering transactions within the reconstructed block.

[0263] One or more of these validators may include at least one coordinating entity configured to act as a validator-level controller. Therefore, any or all of validators 704a to 704d may include at least one controller component of itself. 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 the Merkle tree for a given segment, or interacting with other system components (e.g., other validators or higher-level controllers, UTXO pools, wallets, etc.). In turn, the processing resources themselves may be further decomposed into smaller systems, one or more of which may include a controller and one or more of its own processing resources. In this way, the system may include a hierarchical architecture where segment verification is performed through validator entities, which include one or more processing resources for performing validator tasks, and one or more controllers for coordinating processor activity and executing inter-component communication.

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

[0265] This hierarchical decomposition can also be extended to the transaction level, allowing verification to be further broken down into sub-processes or tasks for each transaction, rather than at the segment level. In this way, the verification of one or more individual transactions is decomposed into sub-tasks distributed across different machines, or different threads running on the same or different machines. These processes can be queued so that when a thread becomes available, another transaction or task is assigned to that thread.

[0266] Therefore, this disclosure enables the simultaneous processing of many transactions, with the only limitation being the number of hardware available to form distributed verification nodes, rather than the available processing speed, which would be a bottleneck as in traditional technologies. This allows blockchain processing systems to scale horizontally without requiring changes to the underlying protocol of the blockchain network.

[0267] Therefore, this disclosure deviates significantly from conventional verification methods, which are described in the section titled "Exemplary Technical Environment for Implementing Illustrative Embodiments of this Disclosure" and referenced below. Figure 1 and Figure 2 A more detailed description is needed. As explained, the traditional method involves verifying a block as a whole entity, while verifying nodes (see [link to documentation]). Figure 1 The traditional view of the Merkle tree (104) is treated as a single computational unit. Instead, embodiments of this disclosure decompose the Merkle tree into multiple segments, which are provided to different verifiers ( Figure 7 and Figure 9 In sections 704a to 704d), each segment and verifier can be further decomposed to improve the extent of the distribution involved.

[0268] Furthermore, by breaking down each block into segments based on a Merkle tree, embodiments of this disclosure enable verifiers to access, download, and process small portions of a block, rather than the entire block. It should be remembered that transactions within each segment are hashed (in pairs) to a single root value. This means that only the necessary relevant transactions can be verified for that segment, rather than downloading, storing, and processing the entire block as a whole. Because some blockchain protocols allow for extended block sizes and the inclusion of larger blocks in the ledger, the traditional model of downloading the entire block becomes a bottleneck. Embodiments of this disclosure overcome this challenge to blockchain scalability by enabling individual verifiers to receive and process only the (smaller) portions relevant to them. This results in faster overall verification times, improved blockchain networks, and improved applications running on the blockchain.

[0269] Furthermore, the embodiments support and facilitate the use of SPV processes and resources because such SPVs only involve local verification of the portion of the Merkle tree that is of interest to a given party. Therefore, the tree-pruning nature of SPV technology is well-suited for use in conjunction with embodiments of this disclosure. In an SPV context, the verifier may be provided only with the portion of block data it requires, namely the block header or segment root node and the associated transaction.

[0270] Once each verifier has performed its checks and confirmed the validity of the segments it has processed, the block is guaranteed to be valid due to the hashing mechanism used to span the tree.

[0271] Load balancing across multiple verifiers

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

[0273] As described above, embodiments of this disclosure can use an indexing system when assigning block segments to corresponding validators. Preferably, the indexing system is a binary indexing system. In this preferred system, each validator is assigned a binary tag or identifier. Assuming each identifier is 4 bits long, the first validator is identified as 0000, the next validator as 0001, the following validator as 0010, and so on. Obviously, a 4-bit identifier allows for 256 validator IDs, with the last validator identified as 1111 (i.e., validator number 255 in decimal representation).

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

[0275] While double hashing is commonly used when generating Merkle trees, it is not necessary in all examples; a single hash can be used instead. In fact, any number of hash operations will produce random binary numbers. Load balancing tasks can be performed by dedicated system components, such as... Figure 9 As shown in 905, it may be provided elsewhere within system 700, or associated with and communicate with system 700.

[0276] Distributed download blocks

[0277] According to some embodiments, assigning segments of the block Merkle tree to different verifiers can be used to provide a faster, more efficient process for downloading part or all of a transaction block.

[0278] A segment of the Merkle tree is allocated to each validator, for example, based on the allocation index described above. Then, any given validator downloads a set of transactions that forms the allocated tree segment. This may involve downloading the transaction set from the blockchain itself (e.g., from a blockchain node) or from a different resource or entity (e.g., a third-party service provider). The transaction set can be downloaded to the validator's internal storage or to a shared storage location, such as a shared drive in the cloud.

[0279] Distributed nodes may require the complete block, i.e., the entire set of transactions that make up the block. In this case, each validator allocated a segment downloads the subset of transactions that make up that segment. In other cases, distributed nodes may only need certain parts of the block. In this case, only some validators may need to download their respective subsets of transactions to obtain the required transactions.

[0280] Downloading blocks (or portions of blocks) in this way improves overall download speed because each validator only processes a subset of the transactions that make up the entire set of transactions forming the block. This contrasts with traditional block downloads, where a given entity (e.g., a full node) must download the entire block, for example, by downloading each transaction in the order it appears in the block. Now, the block is downloaded in parallel by multiple validators. A block can contain tens of thousands, perhaps orders of magnitude more, of transactions. Downloading that many transactions for a single entity would consume significant resources and take a considerable amount of time. Now, the computational burden is distributed among the validators, causing each individual validator to consume a small fraction of the processing resources. Similarly, this reduces the total time to download the block.

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

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

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

[0284] Distributed UTXO pool

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

[0286] This differs significantly from the traditional UTXO model, where each full node in the network has a copy of a UTXO pool that tracks all UTXOs on the blockchain. In contrast, this disclosure distributes UTXO pools across multiple verification resources, each verification resource having a UTXO pool that is a subset of the entire UTXO set of the blockchain. Each verifier's UTXO pool comprises the UTXOs of transactions that constitute the Merkle tree sub-part responsible for verification.

[0287] Following this approach, each time a new block needs to be verified, it can be implemented in a manner similar to an SQL transaction log, since every command, event, and item related to the database is recorded in this log. This article will use the term "database log" to avoid confusion caused by using the term "transaction," as is known in blockchain, but to encompass terms such as "transaction processing log," "transaction log," etc. Essentially, a database log can be interpreted as a history of actions performed by the database management system, providing a record of all changes that have occurred to the database state, as is known in the field of computer-based databases (see https: / / en.wikipedia.org / wiki / Transaction_log).

[0288] Using an ordered historical database log means that the entire UTXO pool can be built 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 there is no need to store separate copies of the data. This ensures data integrity and requires fewer storage resources. Each UTXO pool can be stored, maintained, and processed independently. Also advantageously, if SPV technology operates on the pruned portion of the Merkle tree, it can facilitate the creation of a separate UTXO database for each validator.

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

[0290] Constructing transactions in this way provides a fast and efficient lookup mechanism. Transactions can be sorted by block_ID, ensuring that all transactions with the same block_ID reside together in the database. Therefore, when a validator needs a transaction (e.g., to check if the transaction's UTXO has been spent), it can first locate the transaction in the database by searching for the corresponding block_ID, and then the corresponding TxID. This effectively limits the search to the relevant parts of the database. This efficiency reduces the time, processing resources, and energy required for search operations, resulting in a significant improvement over existing technologies.

[0291] A flag or marker is associated with each UTXO in the validator pool and indicates whether the UTXO is locked or unlocked. For convenience, this flag or marker can be called the "lock flag." When a UTXO is marked "locked," this indicates to the validators in the group (i.e., elsewhere in the distributed validator nodes) that the UTXO is not available for spending. Conversely, when a UTXO is marked "unlocked," this indicates to the validators that the UTXO is available for spending. Therefore, its purpose is to enable a validator assigned to validate a transaction spending UTXO to signal to its peers that the transaction has spent the UTXO, assuming the transaction has been proven valid, redeemed, and is therefore no longer spendable. A "locked" state means spending is allowed, while an "unlocked" state means spending is prohibited.

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

[0293] During operation, the validator examines the output of each new transaction assigned to it by the controller. Any unspent outputs (UTXOs) are added to the validator's UTXO pool, i.e., recorded as entries in the UTXO database. In the associated database record for each new UTXO, the lock flag is set to "unlocked".

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

[0295] In the above embodiments, each validator has a single UTXO pool that includes UTXOs for all transactions across all tree segments allocated to it. However, an alternative approach is that the UTXO pool maintained by each validator can be partitioned / splittered / divided into / composed of multiple sub-pools, one sub-pool per block. In this way, a single UTXO pool can be organized into a logical hierarchical structure. Alternatively, one or more validators can be associated with corresponding multiple UTXO pools, each UTXO pool being associated with a set of UTXOs for one or more tree segments. Therefore, in some embodiments, one or more validators can organize UTXOs into separate UTXO pools for different individual tree segments or according to certain predefined criteria such as tree segment type or tree segments within a given range. In such embodiments, identifiers can include block IDs that can be used to narrow down a search to a relevant UTXO pool, which can then be searched within that pool to (attempt) identify the relevant transaction by its TxID. Those skilled in the art will understand that in some embodiments, a combination of these methods may be used, i.e., one or more verifiers within a distributed node may use a single UTXO pool method, while one or more other verifiers are configured to use multiple separate UTXO pools and / or UTXO pools organized into sub-pools, or any combination thereof.

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

[0297] Illustrative system of possible embodiments

[0298] Figure 7 and Figure 9 An exemplary system 700 for implementing at least some of the embodiments described is shown. Figure 8 A flowchart illustrating exemplary steps that can be taken in the methods of this disclosure (in a brief view) is shown.

[0299] System 700 can be a closed system, as it can be associated with an organization and form part of a larger proprietary system. In this case, it can receive data (e.g., transactions) from other components within the organization's broader system and send its results and outputs to internal destinations. Additionally or alternatively, System 700 can be configured to interface with various entities, some or all of which may be located outside the organization. In this case, System 700 can be configured to provide verification functionality as a service. For example, System 700 can be configured to interact with a blockchain network to obtain the data it needs. Additionally or alternatively, the system can interact with entities that wish to use its verification services. Therefore, the activities of System 700 can be purely internal activities concerning a specific organization or entity, or they can be open to interaction with external entities to provide verification services to other parties, or a combination of both. Communication between other internal or external entities can be coordinated by one or more interfaces or communication components, such as... Figure 9 As shown in 902.

[0300] like Figure 7 and Figure 9 As shown, system 700 includes control entity 702 (or simply "controller") and multiple verification resources 704 (also simply "verifiers" herein). Figure 7 Only four verifiers 701a to 701d are shown, but system 700 can typically include any number of verifiers. Furthermore, controller 702... Figure 7 and Figure 9The controller 702 is shown as different from the verifier 704, but it is not excluded that the controller 702 may include one of the verifiers in the verifier 704, or may be composed of one of the verifiers in the verifier 704. As mentioned above, each verifier may include one or more processing resources, and may include its own controller for coordinating its own internal activities. There are no technical or logical limitations to the hierarchical structure that can be implemented in this way. However, for simplicity and ease of understanding, Figure 7 Only one (top) level of this hierarchical structure is shown.

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

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

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

[0304] At least one of the verifiers 704a to 704d, but preferably some or all of the verifiers, can access their own UTXO pools, which are in Figure 9These are shown as 901a to 901d. This pool includes the aforementioned databases and other storage facilities, and may have a favorable index structure that includes cascading block IDs and transaction IDs. Figure 9 In this paper, these pools are shown as being included within the respective verifiers, but those skilled in the art will readily understand that these pools may also / alternatively be provided outside the verifiers but in communication with them.

[0305] In one or more embodiments, the disclosed process may include a block-level verification phase during which incoming new blocks are tested against block-level standards. Exemplary block-level standards are as described above and generally relate to predefined format requirements and characteristics or limitations applicable to the block itself (rather than transactions within the block). Examples include block size, block header structure or content, and similar standards. Such operations may be performed by a controller or a component of a controller, or by another system component.

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

[0307] Assuming the new block is not rejected, meaning all UTXO inputs are unique, Merkle tree segments can be identified, and associated transactions for these Merkle tree segments can be allocated in the verifier set. The identification process can be performed by, for example... Figure 9 The segment identification unit 903 and other components shown are used for execution. The allocation process can be performed by the segment allocation unit (in... Figure 9 (Shown as 904) This is executed. Allocation unit 904 can employ any of a variety of possible allocation schemes to distribute block segments among the verifiers; however, in an advantageous approach, the allocation scheme can aim at load balancing as described above. Allocation unit 904 may include load balancing unit 905 (or communicate with load balancing unit). Although this is in... Figure 9 The load balancing unit is shown as a separate associated component of the system, but in other embodiments, it may be part of the distribution unit 904 or may be separate from the controller 702. Any combination of components may be readily employed.

[0308] Each validator verifies the transactions associated with one or more segments it receives against transaction-level verification criteria. No synchronization paradigm is required between validators, as they independently verify the validity of the transactions assigned to them. Each validator outputs a result confirming the validity of the transactions it assigned. The results are summed or accumulated to confirm that all transactions in the segment are valid. If one of these validators identifies a non-compliant transaction (i.e., an invalid transaction), that validator can issue output, such as an interrupt or other signal, indicating the presence of an invalid transaction. This interrupt or signal can be sent to other validators, the controller, or another system component, allowing them to immediately stop testing their corresponding transactions and avoid wasting resources verifying transactions to be rejected within the block.

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

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

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

[0312] In step S802, system 700 identifies the block of the Merkle tree of the block. In S803, the segment is distributed to multiple verifiers; and in S804, the verifiers process their respective subsets of transactions substantially in parallel and independently of each other. In S805, the verifier signals to the controller whether the verification was successful or failed.

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

[0314] Clause Set 1

[0315] Any embodiment defined in any or a combination of clauses in Clause Set 1 may be used to implement any other clause or example herein, or in combination with any other clause or example herein.

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

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

[0318] It is possible to process at least a portion of the tree structure. This verifies that an item or component is part of the tree structure. The at least a portion may include the path between the root and the node representing the item or component.

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

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

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

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

[0323] The record may include verification data required for the blockchain transaction, such as unspent transaction outputs (UTXOs), associated with the tree structure. The record may also include the history of multiple previous blockchain transactions.

[0324] Clause 1.3. The method according to Clause 1.1 or 1.2, wherein each item and its components are represented by nodes and leaves in the tree structure and are hashed to create a hash tree.

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

[0326] Clause 1.5. The method described in any of the preceding clauses, wherein at least a portion of the tree structure is stored in a blockchain ledger.

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

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

[0329] The second tree structure can be an iteration of the first tree structure, for example, in which nodes of the first tree structure are updated. Additionally or alternatively, the second tree structure can be independent of the first tree structure, for example, in which nodes of the first tree structure are updated and the updated nodes are represented in the second tree structure.

[0330] Clause 1.7. The method according to Clause 1.6 further comprises: processing the record to verify that at least one of the item, the at least one component of the item, and at least a portion of the blockchain transaction (Tx) is part of the tree structure or the second tree structure.

[0331] Clause 1.8. The method according to any of the preceding clauses, wherein the blockchain transaction includes at least one of the following: the history of the tree structure or each tree structure, the blockchain transaction originating from the tree structure or each tree structure; the history of the allocated resources, the blockchain transaction being stored in the allocated resources,

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

[0333] Clause 1.9. The method described in accordance with any of the preceding clauses, wherein the blockchain transaction (Tx) is used to identify and / or allocate the allocated resources.

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

[0335] Clause 1.10. The method according to Clause 1.9 further includes: storing and / or processing at least a portion of the blockchain transaction (Tx) in the allocated resources; and / or storing and / or processing at least a portion of the blockchain transaction (Tx) by the allocated resources; and / or storing and / or processing at least a portion of the blockchain transaction (Tx) in association with the allocated resources.

[0336] Clause 1.11. The method according to any one of Clauses 1.2 to 1.10, wherein the blockchain transaction or its hash is used to determine a key, wherein the key determines the allocated resources.

[0337] Clause 1.12. The method according to Clause 1.11, wherein the key comprises at least one of: an alphanumeric number; a binary number, and the number is used to determine the allocated resource.

[0338] Clause 1.13. The method according to Clause 1.11 or 1.12, wherein the blockchain transaction, or its hash, or key is parsed to determine the allocated resources.

[0339] Clause 1.14. The method according to any of the preceding clauses, wherein the blockchain transaction further comprises at least one of the following: a Merkle tree for recording blocks of the transaction (Tx); a Merkle root for recording the block of the transaction (Tx); a Merkle path, the Merkle path enabling the determination of the value of the Merkle root for recording the block of the transaction (Tx) based on the hash of the blockchain transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) among a plurality of blockchain transactions within the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0340] Clause 1.15. The method according to any of the preceding clauses, for at least a portion of the blockchain transaction (Tx), the method further comprises at least one of the following steps: validating and / or verifying the blockchain transaction (Tx); performing at least a portion of a Simple Payment Verification (SPV) process for the blockchain transaction; confirming whether the blockchain transaction (Tx) is included in the blockchain block; determining a Merkel proof of the blockchain transaction (Tx); and providing proof that the associated blockchain transaction is part of the tree structure by using at least one of the hash of the root of the tree structure and a path, wherein the path enables the hash of the root of the tree structure used to record the associated blockchain transaction to be determined based on the hash of the blockchain transaction.

[0341] Clause 1.16. A computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to perform a method according to any one of Clauses 1 to 16 when executed on the processing means.

[0342] Clause 1.17. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of Clauses 1.1 to 1.16 when run on one or more processors.

[0343] Clause Set 2

[0344] Any embodiment defined in any or a combination of clauses in Clause Set 2 may be used to implement any other clause or example herein, or in combination with any other clause or example herein.

[0345] Clause 2.1. A computer-implemented method, the method comprising: associating data with a blockchain transaction (Tx), wherein the data is represented in a tree structure; processing a path of the tree structure containing the data; processing a digital signature of the author and / or approver of the data; and verifying whether at least one of the following is part of the tree structure: the data, the digital signature, and the blockchain transaction (Tx).

[0346] The method can be performed by a machine (e.g., a computer that operates a browser to access web pages via URLs). By associating the data with the blockchain transaction and processing the tree structure and the digital signature associated with the data (e.g., a web page or its content), the validity of the data can be determined, and the browser can selectively access only valid data.

[0347] The tree structure can be a hash tree. Simple payment verification techniques can be used to determine if data is part of the tree structure. When associated with the tree structure, at least one of the data, the digital signature, and the blockchain transaction (Tx) can be hashed.

[0348] Therefore, verification considers not only whether the data is included in the tree structure, but also the signature associated with the data. This allows verification of the data or any part thereof (e.g., a webpage and its content), but also the provenance of the data's creator or authority. Verification may include the digital signatures of at least one of the creator, the authority, and the associated blockchain transaction. A URL is merely one example of a dataset, which can be represented as a tree structure.

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

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

[0351] The data and the digital signature can be concatenated. The hashes of the data and the digital signature can also be concatenated. Overall, the digital signal is associated with the data to be verified.

[0352] Clause 2.4. The method according to any of the preceding clauses, wherein the verification includes: determining that the digital signature is part of the tree structure.

[0353] Clause 2.5. The method according to any of the preceding clauses, wherein the method further comprises: processing and / or storing at least one of the following in the allocated resources (1104): the data, the digital signature, the tree structure item, the blockchain transaction (Tx).

[0354] Clause 2.6. A computer-implemented method, the method comprising: processing data to generate processed data, and associating the data and / or the processed data with digital signatures of a 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 the 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.

[0355] The processed data can be data associated with or otherwise combined with a digital signature. For example, data to be verified can be cascaded with a digital signature. Prior to association, the data and / or the digital signature can be processed (e.g., hashed).

[0356] The method processes data to be subsequently verified. This can be performed by a machine to retrieve and / or receive data and digital signatures used to create the tree structure. In one example, the digital signatures of the creator and / or authority are used to process the URL. Digital signatures of components of the data (e.g., components of a webpage) can also be retrieved and / or received as part of the URL. A hash tree can be constructed.

[0357] Clause 2.7. The method according to Clause 2.6, wherein the method further comprises: processing the update of the data to produce updated processed data, and representing the updated processed data in a second tree structure.

[0358] The second tree structure can be an iterative update of the first tree structure. The second tree structure, and subsequently created tree structures, can be used to track data. The tree structure schematically represents different versions of the relationship between data and the rest of the tree structure. The second tree structure can be used to determine the verification and / or origin of the item and / or component, starting from the point where the tree structure is first used to track the item and / or component. Tracking can be performed using one or more tree structures. Each tree structure can represent the substitution relationship between the item and / or component and different items and / or different components. The tree structures can be independent, and multiple tree structures can be used to track items and / or at least one component of a blockchain transaction (Tx) with migrations. The tree structure can be a Merkle tree, binary tree, ancestor tree, asymmetric tree, or other unbalanced tree.

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

[0360] Clause 2.9. The method according to any one of Clauses 2.6 to 2.8, the method further comprising: processing at least one of the data, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure to generate its hash, and storing the hash on the blockchain.

[0361] Clause 2.10. The method according to any one of Clauses 2.6 to 2.9, the method further comprising: processing and / or storing at least one of the following in the allocated resources (1104): the data, the processed data, the digital signature, the tree structure, the blockchain transaction (Tx).

[0362] Clause 2.11. The method according to any of the preceding clauses, wherein the data is represented by nodes or leaves in the tree structure and hashed to create a hash tree.

[0363] Clause 2.12. The method described in 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.

[0364] Clause 2.13. The method according to any of the preceding clauses, wherein the tree structure represents a URL (web address), and the data is content on a webpage (web page) of the URL and accessible via a path provided by the URL, the path providing a link to the content; wherein the tree structure includes at least one of the following: a top-level domain, a second-level domain, a subdomain, and a subdirectory.

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

[0366] Clause 2.14. The method described in Clause 2.13, wherein the content of each webpage is signed with a digital signature by the creator and / or approver of the data.

[0367] Clause 2.15. The method according to any of the preceding clauses, wherein the blockchain transaction includes at least one of the following: the history of the tree structure or each tree structure from which the blockchain transaction originates; the history of the allocated resources stored in the blockchain transaction; wherein the history enables verification on the blockchain of at least one of the following: the data, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure.

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

[0369] The key may include at least one of the following: a number consisting of letters and numbers; and a binary number used to determine the allocated resources. At least one of the following may be parsed to determine the key and / or the allocated resources: the data; the digital signature; the blockchain transaction (Tx); the URL; the webpage or its hash.

[0370] Clause 2.17. The method according to any of the preceding clauses, wherein the blockchain transaction further comprises at least one of the following: a Merkle tree for recording blocks of the transaction (Tx); a Merkle root for recording the block of the transaction (Tx); a Merkle path, the Merkle path enabling the determination of the value of the Merkle root for recording the block of the transaction (Tx) based on the hash of the blockchain transaction (Tx); a Merkle proof; a block identifier (block_ID) associated with a blockchain block; a transaction identifier (TxID) associated with a transaction (Tx) among a plurality of blockchain transactions within the blockchain block; a function of the block identifier (block_ID) and the transaction identifier (TxID); a concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

[0371] Clause 2.18. The method according to any of the preceding clauses, for at least a portion of the blockchain transaction (Tx), the method further comprises at least one of the following steps: validating and / or verifying the blockchain transaction (Tx); performing at least a portion of a Simple Payment Verification (SPV) process for the blockchain transaction; confirming whether the blockchain transaction (Tx) is included in the blockchain block; determining a Merkel proof of the blockchain transaction (Tx); and providing proof that the associated blockchain transaction is part of the tree structure by using at least one of the hash of the root of the tree structure and a path, wherein the path enables the hash of the root of the tree structure used to record the associated blockchain transaction to be determined based on the hash of the blockchain transaction.

[0372] Clause 2.19. A computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to perform a method according to any one of Clauses 2.1 to 2.18 when executed on the processing means.

[0373] Clause 2.20. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of Clauses 2.1 to 2.18 when run on one or more processors.

[0374] Exemplary technical environment for implementing the illustrative embodiments of this disclosure

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

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

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

[0378] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean fully storing blockchain 150. Rather, blockchain 150 can be pruned as long as each blockchain node 150 stores the block header of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies the quantity of digital assets represented as a property amount; an example is an output that is password-locked to a user 103 (requiring the user's signature or other solution to unlock, thus allowing redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

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

[0380] 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 a corresponding copy of the same blockchain 150 in its corresponding 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 a “mempool.” In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of transactions that node 104 has accepted as valid, and for that set of transactions, node 104 is forced not to accept any other transactions attempting to spend the same output.

[0381] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when creating the current transaction 152j or even sending the current transaction 152j to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0382] The inputs of the current transaction 152j also include input authorization, such as the signature of user 103a to which the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Therefore, the current transaction 152j can transfer the amount defined in the inputs of the previous transaction 152i to a new user or entity 103b defined in the output of the current transaction 152j. In some cases, transaction 152j may have multiple outputs to split the input amount among multiple users or entities (one of which can be the original user or entity 103a for modification). In some cases, a transaction may also have multiple inputs, aggregating the amounts from multiple outputs of one or more previous transactions and redistributing them to one or more outputs of the current transaction.

[0383] According to the output-based transaction protocol, when a party 103, such as an individual user or organization, wishes to issue a new transaction 152j (either automatically or manually), the issuing party sends the new transaction from its computer terminal 102 to the recipient. The issuing party or recipient will eventually send the transaction to one or more blockchain nodes 104 on network 106 (currently typically servers or data centers, but in principle, other user terminals are also possible). It is also not excluded that the party 103 issuing the new transaction 152j may send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks the validity of the transaction according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In this output-based transaction protocol, this may include checking whether 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 previous transaction 152i to which the new transaction is assigned. This condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined, at least in part, by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or by a combination thereof. Regardless of the approach, if the new transaction 152j is valid, blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and thus forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

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

[0385] In addition to verifying the validity of transactions, blockchain nodes 104 compete to be the first node to create a transaction block in a process commonly known as mining, which is backed by "proof-of-work". At blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded on blockchain 150. Blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 from the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "random number" value such that when the random number is juxtaposed with and hashed from the representation of the ordered pool 154 of pending transactions, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof-of-work puzzle, and other types are not excluded. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs. Therefore, this search can only be performed by brute force, consuming significant processing resources at each blockchain node 104 attempting to solve the puzzle.

[0386] The first blockchain node 104 that solves the problem announces its solution on network 106, providing the solution as proof. Other blockchain nodes 104 in the network can then easily check the solution (once a hash value solution is provided, it can be directly checked whether the solution makes the hash value output satisfy the condition). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. Then, an ordered set of transactions 154 is recorded by each blockchain node 104 as a new block 151 in blockchain 150. A block pointer 155 is also assigned to a new block 151n pointing to a previously created block 151n-1 in the blockchain. The significant amount of work required to create the proof-of-work solution (e.g., in the form of a hash) signals the first node 104's intention to follow the blockchain protocol. These rules include that a transaction is not accepted as valid if it assigns the same output as a previously verified valid transaction; otherwise, it is called double-spending. Once created, block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in blockchain network 106. Block pointer 155 also imposes order on block 151. Since transaction 152 is recorded in ordered blocks at each blockchain node 104 in network 106, an immutable public ledger of transactions is provided.

[0387] It should be noted that different blockchain nodes 104 vying to solve a puzzle at any given time can do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they begin searching for solutions or the order in which they receive transactions. Those solving the corresponding puzzle first define the transactions 152 included in the new block 151n and their order, and update the current pool of unpublished transactions 154. Then, blockchain nodes 104 continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. Furthermore, there are protocols for resolving any potential “forks,” where two blockchain nodes 104 solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain between nodes 104. In short, the fork with the longest fork direction becomes the final blockchain 150. It should be noted that this does not affect users or agents on the network, as the same transaction will appear in both forks.

[0388] According to some exemplary blockchain protocols, a node that successfully constructs a new block 104 is granted the ability to allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional, limited amount of digital assets (as opposed to inter-agent or inter-user transactions, which transfer a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction," but can also be referred to as a "starting transaction" or a "generating transaction." It is typically the first transaction to form a new block 151n. Proof-of-work signals the intention of the node constructing the new block to comply with the protocol rules, thereby allowing the redemption of that particular transaction later. The blockchain protocol rules may require a maturity period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is typically called a "transaction fee" and is discussed below.

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

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

[0391] The computer devices 102 of each of the multiple parties 103, acting as consumer users, are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities storing copies of the blockchain 150 (e.g., having already obtained a copy of the blockchain from blockchain node 104).

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

[0393] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0395] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the respondent 103 to create, authorize (e.g., sign) transactions 152 and send them to one or more nodes 104, which then propagate through the network of blockchain nodes 104, thus being included in blockchain 150. The other function is to report to the respondent the amount of digital assets they currently possess. In an output-based system, this second function includes organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across blockchain 150.

[0396] Note: While various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented in a suite of two or more different applications, such as through an API interface or as a plugin for one application. More colloquially, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

[0397] An instance of client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also liaise with blockchain node 104 to query blockchain 150 for any transaction in which the corresponding party 103 is the recipient (or actually to check other parties' transactions in blockchain 150, since, in this embodiment, blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify transaction 152 according to a blockchain node protocol and forward transaction 152 for propagation in blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. All nodes 104 in network 106 use the same node protocol.

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

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

[0400] Once a given blockchain node 104 enters the ordered pool 154 of pending transactions maintained at that node, it will begin competing to solve a proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152. (Note that other blockchain nodes 104 may attempt to solve the puzzle based on different transaction pools 154. However, the first to solve the puzzle will define the set of transactions to be included in the latest block 151. Eventually, blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j.) Once the pool 154 containing the new transaction 152j has completed its proof-of-work, it will immutably become part of a block in block 151 of blockchain 150. Each transaction 152 includes pointers to earlier transactions, so the order of transactions is also immutably recorded.

[0401] Different blockchain nodes 104 can initially receive different instances of a given transaction and thus have conflicting views about which instance is "valid" before an instance is published to a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and then finds that a second instance has been recorded in blockchain 150, then blockchain node 104 must accept this and discard (i.e., consider it invalid) its initially accepted instance (i.e., the instance that has not yet been published in block 151).

[0402] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the network's nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to a previous transaction.

[0403] UTXO-based model

[0404] Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments.

[0405] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 committed to node 104.

[0406] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is marked "Tx1". This new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2In this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to a subsequent transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has an unspent output 203 locked to Alice.

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

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

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

[0410] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P). A This is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A [Contains the public key P in Alice's public-private key pair] A The representation (i.e., hash) of Tx1. Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash value of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0411] When a new transaction Tx1 arrives at blockchain node 104, that node applies the node protocol. This includes running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In this embodiment, this involves concatenating two scripts:

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

[0413] Here, "||" indicates concatenation, "<...>" indicates placing data on the stack, and "[...]" indicates a function consisting of locked scripts (in this example, a stack-based language). Alternatively, scripts can be run one after another using a shared stack, rather than concatenating them. Regardless of the method used, when running together, the scripts use Alice's public key P. A (Included in the locking script at the output of Tx0) to authenticate whether the unlocking script at the input of Tx1 contains the signature when Alice's signature is expected. The expected portion of the data itself ("message") also needs to be included in order to perform this authentication. In this embodiment, the signed data includes the entire Tx1 (therefore, it is not necessary to include a separate element to plaintext specify the portion of the signed data, as it already exists on its own).

[0414] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext, other entities such as Node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this as a signature on the message, thereby enabling any holder of the public key to verify the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a specific data segment or transaction portion, etc., can mean signing the hash value of that data segment or transaction portion.

[0415] If the unlock script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (therefore, in the example shown, if Alice's signature is provided and authenticated in Tx1), then blockchain node 104 considers Tx1 valid. This means that blockchain node 104 will add Tx1 to the pending transaction ordered pool 154. Blockchain node 104 will also forward transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that it will propagate throughout network 106. Once Tx1 is valid and included in blockchain 150, this defines UTXO0 as spent from Tx0. It should be noted that Tx1 is only valid if it spends the output of an unspent transaction 203. If it attempts to spend the output of another transaction 152 that has already been spent, Tx1 will be invalid even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (i.e., whether it has become a valid input for another valid transaction). This is one of the reasons why the order in which blockchain 150 imposes definitions on transaction 152 is important. In practice, given a blockchain node 104, it can maintain a separate database that marks the UTXOs 203 of the spent transaction 152, but the final definition of whether a UTXO has been spent depends on whether a valid input of another valid transaction is formed in the blockchain 150.

[0416] This is another failure criterion in most transaction models if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202. Therefore, such a transaction will not be propagated or included in block 151.

[0417] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined in a UTXO as spent while simultaneously spending another portion. However, the amount in a UTXO can be divided among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be divided among multiple UTXOs in Tx1. Therefore, if Alice doesn't want to give Bob all the amount defined in UTXO0, she can use the remainder to make change herself in the second output of Tx1, or pay the other party.

[0418] In practice, Alice typically also needs to include the fee for node 104, which successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and therefore, although technically valid, may not propagate and be included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not wish to). In some protocols, transaction fees do not require their own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by the output 203 of a given transaction 152 is automatically provided to the blockchain node 104 that published the transaction. For example, suppose the pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, that difference can be allocated by node 104, which won the proof-of-work competition to create the block containing UTXO1. Alternatively or additionally, this does not necessarily preclude the possibility of explicitly specifying transaction costs in one of the UTXOs 203 of its own transaction 152.

[0419] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 at any location in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the UTXOs of various transactions 152 throughout blockchain 150. No location in blockchain 150 stores a single number defining the total balance of the given party 103. The wallet function of client application 105 serves to consolidate the various UTXO values ​​locked to the respective parties that have not yet been spent in other subsequent transactions. To achieve this, it can query a copy of blockchain 150 stored at any node 104.

[0420] It should be noted that script code is typically represented graphically (i.e., using a non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For instance, OP_RETURN is a scripting language opcode. When OP_FALSE is added before the opcode at the beginning of the locking script, the opcode creates a non-spendable output for the transaction. This output can store data within the transaction, thus immutably recording the data in the blockchain. For example, the data may include files that need to be stored in the blockchain.

[0421] Typically, the input to a transaction contains a digital signature corresponding to the public key PA. In this embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature to select the output to be signed (and is therefore fixed at the time of signing).

[0422] Locking scripts are sometimes called "scriptPubKey," referring to the fact that they typically include the public keys of the parties to whom the corresponding transaction is locked. Unlocking scripts are sometimes called "scriptSig," referring to the fact that they typically provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0423] side channel

[0424] like Figure 1 As shown, the client applications on each of Alice and Bob's computer devices 102a and 120b can include 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). Side channel 107 enables the exchange of data off-chain. This type of communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange transaction 152 between Alice and Bob without registering the transaction (not yet) on blockchain network 106 or publishing it on chain 150 until one of them chooses to broadcast it on network 106. Sharing transactions in this way is sometimes referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0425] Side channel 107 can be established via the same packet-switching network 101 as blockchain network 106. Alternatively or additionally, side channel 101 can be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, side channel 107 as referred to anywhere herein can include any one or more links via one or more networking technologies or communication media used for "off-chain" data exchange, i.e., data exchanged outside of blockchain network 106. In the case of using multiple links, the bundle or set of off-chain links as a whole can be referred to as side channel 107. Therefore, it should be noted that if Alice and Bob exchange certain information or data via side channel 107, it does not necessarily mean that all of this data must be sent through the exact same link or even the same type of network.

[0426] in conclusion

[0427] Other variations or use cases of the disclosed technology will become apparent to those skilled in the art once the disclosure of this document has been given. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims. For example, some embodiments above have been described with reference to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of blockchain 150, and the above description can generally be applied to any blockchain. That is, the invention is by no means limited to the Bitcoin blockchain. More generally, any references above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 can be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the features described above for Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104.

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

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

[0430] To put it even more colloquially, any reference above to the term "Bitcoin node" 104 can be replaced by the terms "network entity" or "network element," where such an entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element can be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0431] The term "user" as used in this article can include both human and machine-based entities.

[0432] The above embodiments are illustrative and not limiting of this disclosure. Those skilled in the art can devise numerous alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. Any reference numerals in parentheses in the claims should not be construed as limiting the claims. The word "comprising," etc., does not exclude the presence of elements or steps other than those listed in the entirety in any claim or specification. In this specification, "comprising" means "including" or "consisting of." The word "comprising" or variations thereof (such as "comprising" or "including") used throughout this specification will be understood to mean including the specified elements, integers, steps, or groups of elements, integers, or steps, but does not exclude any other elements, integers, steps, or groups of elements, integers, or steps. The singular form of an element does not exclude the plural form of such elements, and vice versa. This disclosure can be implemented by hardware comprising several different elements and by a suitably programmed computer. In device claims enumerating several means, several of these means may be embodied by the same hardware. The fact that certain measures are referenced in mutually different dependent claims does not mean that combinations of these measures cannot be advantageously used.

[0433] Any references to "Bitcoin," "cryptocurrency," or a particular cryptocurrency protocol in this specification and accompanying drawings may be replaced with the terms "blockchain" or "blockchain network," "token," "digital asset," or "blockchain protocol" appropriate for the specific context in which these terms are used.

[0434] statement

[0435] The inclusion of the aforementioned documents by way of introduction is limited to the following: the incorporated subject matter must not contradict the express disclosure herein. The inclusion of the aforementioned documents by way of introduction is further limited to the following: any claims contained in the documents are not incorporated by way of introduction. The inclusion of the aforementioned documents by way of introduction is again limited to the following: any definitions provided in the documents are not incorporated by way of introduction unless expressly included herein.< / pa>

Claims

1. A computer-implemented method, the method comprising: Associate data with blockchain transactions (Tx), wherein the data is represented in a tree structure; Process the path of the tree structure containing the data; Digital signatures of the creators and / or approvers of the data; as well as Verify that at least one of the following is part of the tree structure: the data, the digital signature, and the blockchain transaction (Tx).

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

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

4. The method according to any one of the preceding claims, wherein the verification comprises: It is determined that the digital signature is part of the tree structure.

5. The method according to any one of the preceding claims, wherein the method further comprises: Process and / or store at least one of the following in the allocated resources (1104): the data, the digital signature, the tree structure item, and the blockchain transaction (Tx).

6. A computer-implemented method, the method comprising: Process the data to produce processed data, and associate the data and / or the processed data with the digital signatures of the creator and / or approver; The data and / or the processed data are represented in a tree structure; Associate at least one of the data, the processed data, and / or the digital signature with a blockchain transaction (Tx) represented in the tree structure; as well as Record at least one of the following on the blockchain: the data, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure.

7. The method according to claim 6, wherein, The method further includes: processing the update of the 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 the nodes 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 the digital signature of the blockchain transaction (Tx) represented in the tree structure, the data, and / or the processed data.

9. The method according to any one of claims 6 to 8, further comprising: The data, the processed data, the digital signature, the blockchain transaction (Tx), and at least one of the tree structure are processed to generate their hashes, and the hashes are stored on the blockchain.

10. The method according to any one of claims 6 to 9, further comprising: Process and / or store at least one of the following in the allocated resources (1104): the data, the processed data, the digital signature, the tree structure, and the blockchain transaction (Tx).

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

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

13. The method according to any one of the preceding claims, The tree structure represents a URL, and the data is content on a webpage at that URL and is accessible via a path provided by the URL, which offers links to that content; and The tree structure mentioned therein includes at least one of the following: top-level domain, second-level domain, subdomain, and subdirectory.

14. The method according to claim 13, wherein, The content of each webpage is digitally signed by the creator and / or approver of the data.

15. The method according to any one of the preceding claims, wherein the blockchain transaction includes at least one of the following: The blockchain transaction originates from the tree structure or the history of each tree structure; The blockchain transaction store the history of the allocated resources. in, The history enables verification on the blockchain of at least one of the following: the data, the processed data, the digital signature, the blockchain transaction (Tx), and the tree structure.

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

17. The method according to any one of the preceding claims, wherein the blockchain transaction further comprises at least one of the following: A Merkle tree used to record the blocks of the transaction (Tx); The Merkle root used to record the block of the transaction (Tx); Merkel path, which enables the determination of the value of the Merkel root of the block used to record the transaction (Tx) based on the hash of the blockchain transaction (Tx); Merkel proved; Block identifier (block_ID), which is associated with a blockchain block; A transaction identifier (TxID) is associated with a transaction (Tx) among multiple blockchain transactions within the blockchain block; The functions of the block identifier (block_ID) and the transaction identifier (TxID); The concatenation of the block identifier (block_ID) and the transaction identifier (TxID).

18. The method according to any one of the preceding claims, wherein for at least a portion of the blockchain transaction (Tx), the method further comprises at least one of the following steps: Verify and / or validate the blockchain transaction (Tx); Perform at least a portion of the Simple Payment Verification (SPV) process for the blockchain transaction; Confirm whether the blockchain transaction (Tx) is included in the blockchain block; Determine the Merkel proof of the blockchain transaction (Tx); The associated blockchain transaction is proof that it is part of the tree structure by using at least one of the hash of the root of the tree structure and the path, wherein the path enables the hash of the root of the tree structure used to record the associated blockchain transaction to be determined based on the hash of the blockchain transaction.

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

20. A computer program, the computer program being contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 18 when executed on one or more processors.

Images