CN118202613A - Methods and systems for distributed blockchain functionality - Google Patents

Abstract

The present disclosure provides methods and systems for generating, storing, processing, accessing and/or maintaining a record of at least a portion of a transaction (Tx). The record includes transaction data, and the transaction data is used to determine that the at least a portion of the transaction (Tx) is included in the Merkle path of the blockchain block (B). The record is used to hold information such as data items. The record can be stored in an allocated resource such as a database, and the allocated resource can be part of a node connected to the blockchain network. The record can include at least the transaction data, and can also include a status flag/status, verification information, verification data, detailed information about the location of unspent transaction outputs, and a reference to at least one previous record, such as location, signature, and authorization data. The record enables data related to the transaction to be stored and stored in a cataloged manner.

Description

Method and system for distributed blockchain functionality

Technical Field

The present disclosure relates generally to improved methods and systems for processing and/or managing data records and/or the format and/or content of such records. The present disclosure is particularly suited, but not limited, to transactions implemented on or using a blockchain network, such as determining storage allocation, pre-and/or post-mining verification of blockchain transactions, SPV checking, and the like. Advantages include, but are not limited to, increased security, resilience and efficiency, or reduced speed and resource requirements, implementing novel resource verification and balancing methods that prior art arrangements are not capable of achieving, thereby enabling arrangements of blockchain implementations that were not previously possible.

Background

While bitcoin protocols and networks may be mentioned herein for the purpose of providing an illustrative context for implementation, the present disclosure is not limited to use with bitcoin blockchains, and alternative protocols and implementations (including account-based protocols and implementations and those including proof of rights consensus) are also within the scope of the present disclosure. Hereinafter, purely for convenience, the term "UTXO" may be used to refer to transaction output and should not be construed to mean that embodiments of the present disclosure are limited to use with UTXO-based blockchain models only.

Blockchains are point-to-point electronic ledgers that are implemented as computer-based decentralized distributed systems consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes transfer of digital asset control rights between blockchain system participants and includes at least one input and at least one output. Each chunk contains a hash of the last chunk, so the chunks are linked together to create a permanent and unchangeable record of all transactions written to it since the blockchain was created.

To write a transaction (Tx) to the blockchain, the transaction must be verified. The network node (mineworker) works to ensure that every transaction is valid, while invalid transactions are rejected by the network. In some protocols, software clients installed on these nodes perform this validation work on the unexpired transaction output (UTXO) by executing their lock script and unlock script. If execution of the lock script and the unlock script evaluates to true, the transaction is valid and the transaction is written to the blockchain. Thus, in order to write a transaction to the blockchain, the transaction must: i) Verifying by the first node receiving the transaction, if the transaction passes verification, the node relaying it to other nodes in the network, i.e. the transaction is propagated; ii) to new blocks built by miners; iii) Is mined, i.e., added to the public ledger of past transactions. Once the transaction is stored in the blockchain as a UTXO, the user may transfer control of the associated cryptocurrency to another address associated with an input in another transaction that is subsequently written to the blockchain. This is typically done using a digital wallet that stores public and private key pairs associated with the user's cryptocurrency. Known cryptocurrency wallets come in a variety of forms including SPV wallets (simple payment verification). SPV techniques allow users and merchant nodes to perform local authentication based only on portions of information related to a particular transfer. The SPV will be discussed in more detail below.

However, the known transaction amount will increase, and the ability to quickly determine the validity of the unexpired transaction output (UTXO) needs to be improved. Current techniques for verifying the task may require a significant amount of resources and time due to the need to download and store blocks, maintain a large pool of UTXOs, and perform the necessary verification processing tasks. Many users either fail to meet such requirements or are reluctant to meet such requirements because they may not need to meet such requirements. Thus, there is a need for a faster, more efficient verification model that can at least address these challenges (and others) without compromising security or requiring adaptation to existing protocols. Furthermore, the authentication means must be scalable. Such improved solutions have now been devised.

Disclosure of Invention

Embodiments of the present disclosure provide improved blockchain correlation methods, devices, and systems. According to one form of the wording, the embodiments provide a solution for identifying and/or distributing the processing and/or storage of data associated with a UTXO, including and/or enabling verification.

The allocation and/or identification is based on partial data derived from all or at least a portion of the blockchain transaction, e.g., the partial data derived includes transaction data, which may be an unexpired transaction output (UTXO) and a UTXO-containing transaction (Tx). Additionally or alternatively, the data may include transaction data for determining that at least a portion of a transaction is contained in the merck path of a blockchain chunk.

Further, a record of at least a portion of the transaction may be held in the allocated and/or identified resources, which may include at least one of: transaction data, status flags, authentication information, references to at least one previous record, such as location, signature, and authorization data.

Configuring the record may improve the method herein, the method comprising: verifying the transaction; allocating and/or identifying processing and/or storage resources. The recorded content can increase security, resilience, and efficiency, or reduce speed and resource requirements, when used, including validating the transaction involved with the record.

Embodiments of the present disclosure provide improved blockchain correlation methods, devices, and systems. According to one form of wording, the embodiments provide a solution for assigning tasks to store information associated with a UTXO, including and/or enabling verification. After allocation, information (e.g., at least a portion of the UTXO and/or the transaction (Tx)) may be stored on one or more of a plurality of resources, which may be distributed.

Additionally or alternatively, the resource may be accessed to retrieve (i) a confirmation of the validity of the UTXO and/or associated transaction and/or (ii) data capable of determining the validity of the UTXO and/or associated transaction.

According to additional or alternative forms of wording, embodiments provide security solutions for controlling, managing and/or improving the efficiency, resource requirements, speed and/or resilience of known processing methods of blockchain transactions. Embodiments also enable scalability of blockchain implemented solutions, providing improved methods and technical architecture for electronically transmitting digital resources.

Embodiments of the present disclosure may be implemented in part or in whole by various means. These devices may be hardware and/or software based devices including, but not limited to, one or more virtual machines, servers, GPU-based computing resources, or multiprocessor systems. Additionally or alternatively, embodiments may include one or more digital wallets. Importantly, however, the embodiments provide mechanisms for distributed processing of blockchain-related verification tasks. Coordination, management and control of known distributed processes is technical in nature, as this requires a comprehensive understanding of the interactions between the hardware and software components involved, and the implementation of such distributed solutions is beyond the trivial scope of technology.

Embodiments may include a solution that enables or facilitates efficient identification and/or allocation of resources that performs at least one of storing and verifying information associated with each UTXO and/or transaction. Embodiments support extensions of the systems and methods described herein by balancing the distribution of the information among the resources. This may not only balance the distribution of information in the resource, but may also balance the utilization, e.g. the accessibility of the information by the user, which may suppress bottleneck problems.

Embodiments may include distributing verification tasks among multiple processing resources, which are referred to as "verifiers" for convenience. The verifier may comprise a single processing resource or may comprise a plurality of related processing resources, which may be collectively considered as verification resources.

In one example, when a transaction chunk needs to be verified and/or downloaded, the merck tree of the chunk may be broken down into one or more smaller segments, each segment comprising a tree structure having its own root and representing a subset of the transactions in the chunk. These segments may then be assigned to different verifiers. Each verifier is adapted to perform the necessary processing tasks on the subset of transactions that has been allocated to it.

The tree segments may be assigned to verifiers in various ways, but according to one advantageous embodiment, a binary indexing system may be used in which randomly generated leading digits of the double hashed merck root are used to assign a given segment to a verifier (or group/cluster of verifiers) having a matching binary identifier. This provides a simple, efficient and fast mechanism for load balancing across multiple verifiers.

The allocation of processing and/or storing information associated with the UTXOs may also be implemented based on partial data derived from the blockchain. Using this data, resources may be allocated and/or identified for processing and/or storing UTXO information. The method for identifying/allocating supports uniform distribution and/or scalability of information among multiple resources because it is based on pseudo-random data acquired from the blockchain. When information about the UTXO is needed, the resource may be accessed to retrieve at least one of: (i) Validation of validity of UTXOs and/or associated transactions; (ii) Data capable of determining the validity of the UTXO and/or associated transaction; and (iii) an indication and/or proof that the resource or verifier has performed verification.

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

Each full node has its own full copy of the UTXO pool for the blockchain. In accordance with the present disclosure, (i) each verifier may have its own pool of UTXOs that keep track of the UTXOs that have been assigned to transactions for verification, and/or (ii) a system of nodes or the like may assign processing and/or storage of information to resources based on part of the data derived from the blockchain, such as the data derived from the transactions and/or UTXOs, provide an indication of the validity of the UTXOs, and/or be able to determine the information of the validity, such as using SPV techniques.

Thus, information associated with a (blockchain) transaction (e.g., UTXO) is stored as a record. The record may be stored in the allocated resource. The record may include at least some or all of the blockchain transactions in a blockchain block. The record may be used at least to provide information for determining the validity of the transaction. The record may include data that can determine merck proof and/or Simple Payment Verification (SPV), for example, the record may be used to verify that one or more given transactions are in a given chunk.

Advantages of such distributed storage methods (e.g., transactional or UTXO storage), resource (e.g., pool) identification and allocation include, but are not limited to, scalability, data integrity assurance, speed and efficiency enhancement, and incorporation and support of various verification techniques such as SPV.

Drawings

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

FIG. 1 is a schematic block diagram of a system for implementing a blockchain.

Fig. 2 schematically illustrates some examples of transactions that may be recorded in a blockchain.

Fig. 3 provides an illustration of a general merck tree structure known in the art.

Fig. 4 shows how the merck root can be derived from the blockchain transaction set as is known in the art.

Fig. 5 provides an example of how a merck tree may be divided into subsets (or "segments") that may then be assigned to respective verification resources according to embodiments of the present disclosure.

Fig. 6 shows an alternative example of fig. 5 of how the merck tree may be divided into logical segments.

Fig. 7 shows a system level distributed verification node in accordance with an illustrative embodiment of the present disclosure.

Fig. 8 shows a brief flow chart of steps involved in an illustrative method of the present disclosure.

Fig. 9 shows a diagram of the exemplary system of fig. 7 in more detail.

Fig. 10 is a schematic diagram of an example of the present invention, including identification and/or allocation of resources that generate, store, or maintain a database of information associated with transactions, examples of which are unexpired transaction output (UTXO) and/or transactions (Tx) that contain a UTXO.

Fig. 11 (a) to 11 (d) are tables showing examples of values derived from partial data for identifying the determination of the allocated resources.

FIG. 12 is a schematic diagram of a system including nodes, intermediate switches (switches), and allocated resources with optional verifiers.

FIG. 13 is a schematic diagram of two transactions in the Merker tree of a blockchain chunk, the transactions having allocated resources and the allocated resources holding corresponding records.

Detailed Description

For purposes of illustration (and not limitation) and with reference to the figures, exemplary embodiments of the present disclosure are described below.

A manner for processing and/or storing information related to the spent transaction output (which may be referred to as a UTXO in some embodiments) and/or the UTXO-containing transaction (Tx) may be implemented using different systems and methods, which may be separately configured and/or executed. Examples of "UTXO databases" and "block verification" are described below, wherein each example assigns tasks to resources, such as distributed resources, including storing and/or verifying one or more transactions.

Examples of allocation/identification of resources are described below in connection with a "UTXO database," where information (e.g., records) is allocated to resources. In addition, examples of verification transactions and verification techniques/management, such as "block verification", are described below.

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

Features of examples may be combined in accordance with the teachings herein.

Recording

FIG. 13 illustrates two transactions derived from blockchain 150. Examples of the methods described herein include at least one of: a record of at least a portion of a transaction (Tx) is generated, stored, processed, accessed, and/or maintained in one of the plurality of resources 1104. The allocation and/or identification of resources corresponding to each transaction is described below in connection with a UTXO database that is allocated, for example, using hash table techniques. Resource 1104 may be one of a plurality of resources that make up a database.

Fig. 13 shows two merck trees that are built using the transaction sets in a chunk to determine the merck root contained in the chunk header. Each of the transactions Tx _n and Tx _n+1 is part of a respective merck tree, at least as shown below with respect to fig. 4.

The record includes transaction data that is used to determine that at least a portion of a transaction (e.g., tx _n or Tx _n+1) is contained in the merck path of the blockchain block (B). Alone or in combination with the examples taught herein, record holding data that enables referencing and/or retrieving information associated with transactions to be efficient and cost effective. In particular, the information held in the record makes it desirable for a third party to validate the transaction to identify the allocated resource holding the associated record and retrieve transaction data for use in determining that at least a portion of the transaction is contained in the merck path of the blockchain chunk (B). For example, the record holds a merck proof that the transaction is part of a merck tree that determines the merck root of the block in which the transaction was recorded.

A record may hold a set of data associated with a transaction. For example, the records may be simplified and/or contain concatenated data for efficient storage. The information in the record may be configured for reference. For example, the record may include a data directory. The data directory may be structured, e.g., with an index added, for selectively identifying and/or retrieving information associated with the transaction. The data directory may hold a set of transaction data, such as merck certificates that enable Simple Payment Verification (SPV).

The records may include a data catalog that may be managed by the resource and/or verifier 1106. The record is for holding information that may be stored/associated with the transaction, such as UTXOs, for at least one of verification, status indication, holding signature, and transaction status. For example, the record may include at least a portion of a script defining "op_push_tx" to condition the transaction. Thus, the record may provide a directory or information repository associated with the transaction.

The output of the transaction may be an unexpired transaction output (UTXO) and/or a transaction (Tx) containing a UTXO of the blockchain block. As suggested by UTXO and op_push_tx records, the records are not limited to the output of the transaction, and at least a portion of the Transaction (TX) may include the output, input, and/or any other parameters of the transaction.

The record may be stored in a database. The database may include a plurality of resources 1104 and/or verifiers 1106. The record may include a blockchain transaction (TX 0) that includes at least one data item (D). Additionally or alternatively, the record may include at least one other blockchain transaction (TX 1) necessary to confirm that the blockchain transaction (TX 1) is contained in the merck path of the blockchain block (B).

The records may be data directories, may be stored in a database, or may be distributed among multiple databases. The database itself may be distributed among multiple resources 1104. The storage of records (e.g., information and/or data as taught herein) may be applied to and/or support efficient allocation, referencing, and access of records associated with nodes (e.g., metanet nodes) and associated Metanet protocols.

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

PCT/IB2019/059793, which involves indexing and structuring nodes

PCT/IB2019/059795, which supports mapping categories to mnemonics, such as catalogs.

PCT/IB2019/059791, which supports search for positioning resources.

PCT/IB2019/059803, which supports wallets, blockchain search systems, blockbrowsers, etc., enables users to search/access/view/write/retrieve part of the data (e.g., transactions) contained in the Metanet node, and can identify the Metanet node based on its Metanet index.

PCT/IB2019/060226, PCT/IB2019/059807, which supports splitting data across multiple nodes.

PCT/IB2019/059808, which supports splitting records, in particular node attributes, across multiple transaction inputs and multiple transaction outputs.

PCT/IB2019/059809, wherein an atomic exchange, e.g. a conditional exchange, is established between two or more parties.

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

Additionally or alternatively, the record includes transaction data for determining

At least a portion of the transaction (Tx) is contained in the merck path of the blockchain block (B), and the record may hold the merck path from transaction (Tx 0) to the root of the merck tree of blockchain block (B). The merck path may include at least the minimum blockchain transaction required to establish or verify that the blockchain transaction (TX 0) is contained in blockchain block (B). The records herein provide an efficient and effective way to verify transactions. An improved system for managing and/or using transactional data is provided herein in connection with allocation and identification and/or verification techniques of resources holding records. Transactions may be derived from blockchain blocks.

The blockchain transaction (TX 0) may be used alone or in combination with at least one other blockchain transaction (TX 1) to verify that the blockchain transaction (TX 0) is contained in the merck path of the blockchain block (B). The data item (D) may be part of a record or information stored in the allocated resource, and may be at least one of: storing in association with the script in the transaction; stored as metadata in the transaction. In general, the record includes verification data required to verify the transaction, such as an unexpired transaction output (UTXO) and/or a transaction (Tx) containing the UTXO.

The blockchain blocks may be stored on or associated with: blockchain ledger; and/or an off-chain (chain) storage resource.

The record may comprise a history (history) of at least one previous transaction, i.e. transaction data of at least one previous transaction. The history may include transactions that do not spend transaction output (UTXO) and/or transactions (Tx) that contain UTXOs. The at least one previous transaction may be the last transaction of the last transaction.

The record may further include a history of the allocated resources that at least processed and/or stored the last transaction. The record may include a link to the allocated resource holding the last transaction. The record may hold a history of a number of previous transactions that did not spend transaction output (UTXO) and/or transactions (Tx) that contained the UTXO.

In this way, the history enables a third party using the record to retrieve the latest transaction and, if necessary, efficiently identify the last transaction without performing further searches or searches. The history may provide a set of shortcuts to old directories or critical records, data or information. The history may include at least one of: a set of transaction data for determining a merck proof of a plurality of previous transactions; a link to a respective allocated resource that handles and/or stores a plurality of previous transactions.

Referring to fig. 13, the first transaction Tx _n is followed by a second transaction Tx _n+1. In an example, the first transaction and the second transaction store the associated records in different allocated resources 1104, although they may all be stored at different addresses in the same allocated resources. The record of the second transaction may include at least a link to the address of the first transaction in the allocated resource. The record of the second transaction may include, at least in part, a record of transaction data of the first transaction. The record of the second transaction may include a record of transaction data for a plurality of previous transactions.

The record may include a flag and/or status indication of transaction data, such as each input of a spent transaction output (UTXO) and/or a transaction (Tx) containing a UTXO. For example, the indication may be one of "see", "intra-block", and "double spending", providing an efficient reference to the status of the transaction data.

The record may hold any number of transaction data information and/or supplemental data, such as verification data. The use of records provides an alternative method for searching, identifying, and processing transaction data on a chain. The records may integrate critical data, thereby minimizing the computational cost of performing operations using transactions and using blockchains and blockchain blocks. The record may further include at least one of: recording the merck tree of blocks of the transaction (Tx); recording the merck root of the block of the transaction (Tx); a merck path capable of determining, from a hash of the transaction (Tx), a value of a merck root for recording a block of the transaction (Tx); merck proof; a block identifier (block_id), the block identifier being associated with a block chain block; a transaction identifier (TxID) associated with a transaction (Tx) of a plurality of blockchain transactions within a blockchain block; a function of a block identifier (block_id) and a transaction identifier (TxID); concatenation of block identifier (block_id) and transaction identifier (TxID); a digital signature; an authentication code; signed messages for determining transaction status.

The allocated resources for processing and/or storing the record may be identified and/or allocated using partial data derived from the blockchain for identifying and/or allocating resources, wherein the data from which the partial data is derived includes transaction data, such as an unexpired transaction output (UTXO) and/or a transaction (Tx) containing a UTXO.

Examples herein and associated systems enable use of a database comprising at least one record comprising: a blockchain transaction (TX 0), the blockchain transaction comprising at least one data item (D); and at least one other blockchain transaction (TX 1) necessary to confirm that the blockchain transaction (TX 1) is contained in the merck path of the blockchain block (B).

Using the database includes generating, maintaining, providing, updating, storing, accessing, or processing: a database; and/or data stored within or associated with the database. The recording may further comprise: the merck path from transaction (TX 0) to the root of the merck tree for blockchain chunk (B). The merck path may include at least the minimum blockchain transaction required to establish or verify that the blockchain transaction (TX 0) is contained in blockchain block (B).

The methods herein may use the blockchain transaction (TX 0) and at least one other blockchain transaction (TX 1) to verify that the blockchain transaction (TX 0) is contained in the merck path of the blockchain block (B).

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

The transaction may further include at least one of: transaction ID (TxID); a protocol flag; an autonomous public key (discretionary public key, DPK); autonomous transaction ID (DTxID).

The above-described records (e.g., information and data associated with, derived from, or related to the transaction) may be stored in the allocated resources using the following methods.

UTXO database

Fig. 10-12 show diagrams of stages of a method of exporting data from a blockchain, tables for allocation to resources 1104, and a system for implementing the method, respectively. Data is obtained from peer-to-peer (P2P) network 106 and/or blockchain network 150. At s1000, data may be retrieved or retrieved, for example, by requesting and retrieving one or more blocks from blockchain 150. Retrieving may include downloading at least a portion of a blockchain block that includes a plurality of blockchain transactions. When data is needed to establish transaction data related to an unexpired transaction output (UTXO) and/or related to a transaction (Tx) containing a UTXO that is stored and/or processed history (e.g., has been recorded in block 151), the data needs to be retrieved or otherwise retrieved, e.g., retrieved, copied, or read from a blockchain block. UTXOs are currently in memory pools or future transactions. The UTXO may receive by connecting to the network, for example, by implementing a node 104 that receives transactions broadcast over the network.

Thus, in general, the system 1100 in fig. 12 uses portions of data derived from a blockchain and determines keys and allocates corresponding resources that will store information associated with the data, such as information associated with an unused transaction output (UTXO) and/or a transaction (Tx) that contains the UTXO. For clarity, information associated with data derived from the blockchain will be stored in the resource for efficient and cost-effective reference. The data may include an unexpired transaction output (e.g., UTXO according to the bitcoin protocol) and/or a transaction (Tx) containing the unexpired transaction output (which is referred to as UTXO for convenience). A portion of the data is used to determine a key, which in turn determines an allocated resource that will store information about the data. The data from which the partial data is derived includes the spent transaction output (UTXO) and/or the transaction (Tx) containing the UTXO. At s1002, a portion of the data is used to identify or allocate a corresponding resource 1104, such as an allocated resource. At s1004, the resource 1104 operates to perform at least one of generating, storing, and maintaining a database of information, wherein the information includes data associated with UTXOs and/or transactions. The information may include an indication of the validity of the UTXO and/or may be able to determine the validity, for example using SPV techniques. The information about the data may include, for example, details of the block from which the data was obtained, such as the block ID, the merck path of the unused transaction output (UTXO), and/or the status of the transaction (Tx) containing the UTXO, the validity of all UTXOs within the transaction.

The resource 1104 may operate to store information that may be used by other resources to verify the UTXO and/or process data to generate an indication, such as a flag indicating validity. Additionally or alternatively, the resource 1104 may delegate the determination of the validity of the transaction or UTXO to the verifier 1106 at s 1006. Storing and/or processing at least a portion of the UTXO and/or transaction (Tx) may be implemented in the following cases: among the allocated resources, for example, resource 1104 actively manages information and maintains a database associated with each UTXO therein, for example, the resource may be self-managed; and/or by an allocated resource, such as the system 1100 where the resource acts as a controller and is used to manage sub-resources to store and/or process information; and/or associated with an allocated resource, e.g., resource 1104, as part of system 1100, as shown in fig. 12, wherein by way of non-limiting example, node 104 provides transaction and UTXO information to switch 1102 (e.g., a router) that operates to determine which resource 1104 of the plurality of resources to allocate tasks to generate, hold, and/or store the UTXO information in the database. In general, the resource may implement and perform one or more of the operations in FIG. 10. Fig. 12 illustrates a system 1100 having components that individually perform the operations of fig. 10. In some embodiments, switch 1102 is configured to send and/or receive (IPv 6) multicast transmissions.

In one example, a task holding information associated with the UTXO is assigned to one of a set of resources from the system 1100. For example, fig. 12 shows 8 resources, where each resource shares information from the UTXO among each other. However, the system may hold any number of resources and be scalable, e.g., the system may have 16, 256, or 1024 resources. Thus, a UTXO range is allocated for each resource for processing, storage, and/or maintenance.

A portion of the data of the transaction output and/or the transaction (Tx) containing the UTXO may be retrieved and/or received and parsed (burst). Parsing may determine which resource is assigned a task to store information. Parsing may be performed by resource 1104 or switch 1102. At least one of the node 104, switch 1102, and resource 1104 may derive a portion of the data from the blockchain. When parsing is performed by node 104 or switch 1102, the information is directed to the allocated resources. The identifying and/or allocating process and/or storage resources may be performed by nodes and/or switches that act as intermediaries. They are connected to a plurality of allocated resources and the node or switch operates as a manager of a number of resources 1104, determining the specific resources to manage the UTXO/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 a UTXO.

When determining the allocation of the resource 1104, e.g., determining the location to hold information associated with the UTXO/Tx, the resource 1104 may perform the operation of s1004 and generate, store, and/or maintain information associated with the unused transaction output (UTXO) and/or the UTXO-containing transaction (Tx). The resource 1104 may process the received data to determine the validity of the UTXO/Tx, e.g., s1006, or delegate the task to the verifier 1106. The resource 1104 and/or verifier 1106 may verify, at least in part, the unexpired transaction output (UTXO) and/or the transaction (Tx) containing the UTXO.

Data is obtained from peer-to-peer (P2P) network 106 and/or blockchain 150. The data may be acquired by the node 104 and/or switch 1102 which then allocates the data to the resource or the data may be acquired by the resource 1104 itself which searches for and parses the data based on its allocated UTXO/Tx range. The acquired data may include at least one of: a UTXO identifier; hashing of UTXO script; transaction identification (TXID).

The acquired data relates to a UTXO or a transaction with a UTXO for providing a key that identifies and/or allocates resources to store, maintain, or generate corresponding information. The key is determined directly by using a portion of the data, e.g. the key determines the allocated resources, or indirectly by processing, e.g. hashing a portion of the data, such that the resulting hash determines the allocated resources.

The key is used to determine which resource 1104 will hold the corresponding information associated with the key. Thus, the resource holds a data structure, such as a database or hash table, that implements an associated array. In other words, data associated with the UTXO and/or transaction is used to determine a key, and the key is used to determine a resource holding information associated with the UTXO and/or transaction. The data and keys are not only able to allocate resources, but also can retrieve stored information by looking up and accessing the information using the keys.

At least one of the data, the key, and the resulting hash includes at least one of: a number (alphanumeric number) containing letters and numbers; and binary numbers. This number is used to determine the allocated resources.

For example, the partial data includes an unexpired transaction output (UTXO) and/or a transaction (Tx) containing the UTXO. The input of the transaction includes: a transaction ID referencing a transaction containing the spent UTXO; an output index, e.g., vout, identifying the UTXO that references the transaction; SCRIPTSIG, the SCRIPTSIG meets the conditions imposed on the UTXO for unlocking it; a serial number.

Potential recipients of a UTXO need to verify the UTXO before compiling and broadcasting transactions that spend the UTXO. The known verification techniques are slow, resource intensive and computationally expensive. Information for verifying or allowing verification of the UTXO may be stored in the resource using part of the data and/or associated transactions of the UTXO. A key may be determined using the portion of data unique to the UTXO, which may then determine the allocated resources from which the associated information may be stored and then retrieved.

Taking transaction identification (TxID), which is commonly referred to as hexadecimal form, as a non-limiting example, may also be represented as a binary number. Fig. 11 (a) to 11 (d) are tables showing how to determine allocated resources using a part of data. The partial data (e.g., txID) may be parsed or processed directly, such as by hashing. In fig. 11 (a), the TxID is parsed such that the first three digits of the binary form of the TxID are selected as keys and resources are allocated according to binary values, e.g., information associated with the TxID having a binary number of the first three digits "101" for storage/processing in the allocated resources "6". By using the first three digits, the binary system is able to determine one of the eight resources, while FIG. 11 (c) shows how the first four digits are obtained from the binary form of the TxID to support allocation among the 16 resources, e.g., to allocate information associated with the TxID beginning with the binary number with the first four digits of "1011" for storage/processing in the allocated resource "12". Alternatively, hexadecimal values of TxID may be used, as shown in FIG. 11 (b), where a single hexadecimal value maps to a resource, e.g., "c" through "13", and in FIG. 11 (d), a range of hexadecimal values is allocated to the resource, e.g., information associated with TxID beginning with "76" is allocated to resource "8".

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

The portion of data selected from the transaction or its UTXO, or the processed value (e.g., hash value), is pseudo-random. The allocation of resources is load balanced, i.e. the part of the data used to determine the keys used to allocate the resources is pseudo-random and the processing and/or storage is distributed among the plurality of resources. It follows that the information associated with the transaction/UTXOs is distributed across multiple resources. The balance of allocation among the resources may minimize the risk of some processing resources being in an idle state while other processing resources are overloaded, resulting in reduced performance and even failure. The elasticity, performance, and/or efficiency of system 1100 are improved.

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

It follows that part of the data is derived from the blockchain and that a key and corresponding resources are determined that will store information associated with the data, i.e. information associated with the spent transaction output (UTXO) and/or the transaction (Tx) containing the UTXO.

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

The record may include, at least in part, at least one of: recording the merck tree of blocks of the transaction (Tx); a merck root for recording blocks of the transaction (Tx); a merck path, from the hash of the transaction (Tx), capable of determining the value of the merck root used to record the block of the transaction (Tx); merck proof; a block identifier (block_id), the block identifier being associated with a block chain block; a transaction identifier (TxID) associated with a transaction (Tx) of a plurality of blockchain transactions within a blockchain block; a function of a block identifier (block_id) and a transaction identifier (TxID); and a concatenation of a block identifier (block_id) and a transaction identifier (TxID).

The resources may include information and records necessary to determine the validity of the UTXO. Additionally or alternatively, the resource may generate a record of the verification and/or the verification supporting UTXO at its own or through the verification s1006 of the verifier 1106. The resource 1104 and/or verifier 1106 may perform at least one of: verifying and/or validating the UTXO; performing at least a portion of a Simple Payment Verification (SPV) process for the UTXO; determining whether a given blockchain transaction (Tx) is contained within a blockchain block; generating a hash of at least one of the blockchain transactions, constructing a merck path using the hash and/or checking whether the hash matches a transaction identifier (TxID) in a block header of the blockchain block; and determining a merck proof for the UTXO.

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

In general, the system 1100 includes a resource 1104 that operates to provide a repository of UTXOs for generating, storing, and/or maintaining information and/or records associated with a plurality of unexpired transaction outputs (UTXOs), each UTXO associated with a transaction (Tx) of a plurality of blockchain Transactions (TXs) of a blockchain block. The resource may record, search and/or process information and/or records using partial data derived from the blockchain to identify and/or allocate the resource, wherein the data from which the partial data is derived includes an unexpired transaction output (UTXO) and/or a transaction (Tx) containing the UTXO.

System 1100 may include node 104 and/or switch 1102 to receive and/or process an unexpired transaction output (UTXO) for inclusion in a transaction. Nodes and/or switches may support resources and determine allocation of resources among a plurality of resources. The allocated resource then holds verification data, such as information and/or records for the UTXO.

After receiving the UTXO for inclusion in the transaction (e.g., as part of paying or transferring the digital asset), the participant may request and/or obtain verification information and/or records from the allocated resources.

When a participant accesses information and/or records from an allocated resource, the participant may perform at least one of: verifying the UTXO and/or a transaction (Tx) containing said UTXO; and/or determining the validity of a UTXO and/or a transaction (Tx) containing the UTXO. Verification performed by at least one of the resource 1104, the verifier 1106, and the participant may include: validating and/or validating at least one blockchain transaction; and/or ii) performing a Simple Payment Verification (SPV) process; and/or iii) confirm whether a given blockchain transaction (Tx) is contained within a blockchain block; and/or iii) generating a hash of at least one of the blockchain transactions, constructing a merck path using the hash, and/or checking whether the hash matches a transaction identifier (TxID) in a block header of the blockchain block.

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

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

Block verification

Traditionally, nodes in a blockchain network maintain a global ledger for all transactions on the blockchain. The global ledger is a distributed ledger and each node may store a complete or partial copy of the global ledger. Transactions of nodes affecting the global ledger are validated by other nodes, maintaining the validity and integrity of the global ledger. Those of ordinary skill in the art will understand the details of implementing and operating a blockchain network (e.g., a network using a bitcoin protocol).

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 output of a transaction can be accessed. The output of a transaction may be the address to which control of the value is transferred due to the transaction. This value is then associated with the output address as an unexpired transaction output (UTXO). Subsequent transactions may then reference the address as input to gain control or ownership of the value.

As described above, taking the bitcoin network and protocol as an example, the mining node race creates the next chunk in the blockchain. To assemble a block, miners construct the block as a set of transactions from an unacknowledged transaction pool ("memory pool"). The mineworker then attempts to complete a proof of work (PoW) puzzle with respect to the blocks that they have assembled. If the mineworker tries to complete a PoW before receiving notification that any other mineworker has successfully generated its own tile and completed its PoW, the mineworker propagates its tile by sending it to peer nodes on the network. The nodes verify the block and then send it further to other nodes in the network. If the mineworker receives notification that another block has been completed before completing his own PoW, the mineworker gives up effort and begins trying to build the next block.

Thus, the fast propagation block helps avoid wasting effort (and associated energy) on behalf of miners and verification nodes. By providing a solution that enables faster verification and thus propagation of blocks, the present invention provides enhanced network performance. This solution reduces the computational time and effort required, thereby reducing the energy required by the network. The solution provides a more resource and time efficient network. The solution ultimately provides an improved (blockchain) network.

In the current implementation of a blockchain (e.g., a bitcoin network), each node that receives a block first verifies the block and then sends the block to other nodes. The time required to verify a block slows down the propagation speed of the block in the network. It should be noted that some implementations of blockchains (including evolution of existing protocols) may perform blockcheck only with a subset of nodes, not with each node in the network; however, block verification at most nodes may still be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

Verifying a block involves verifying that the block meets the specified criteria set by the applicable blockchain protocol. Exemplary criteria applicable to the bitcoin protocol may include functions CheckBlock and CheckBlockHeader, among others. In addition to confirming that the block itself meets the specified criteria, it may be evaluated whether each transaction within the block meets the transaction level criteria. For example, transaction level criteria applied in the bitcoin protocol may include AcceptToMemoryPool, checkTransaction and CheckInputs functions.

Specific examples of tile level criteria based on the bitcoin protocol may include:

● The tile data structure is syntactically valid.

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

● The block timestamp is less than two hours in the future (taking into account the time error).

● The block size is within an acceptable range.

● The first transaction (and only the first transaction) is Coinbase a generate transaction.

● All transactions within a block are valid.

Specific examples of transaction level criteria based on bitcoin protocol may include:

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

● Neither the input list nor the output list is empty.

● Each output value x and the sum of all outputs must be in the range 0< x <21·10 ⁶.

● All inputs do not have a null hash.

● NLockTime is less than or equal to INT_MAX.

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

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

● The unlock script SCRIPTSIG can only push numbers onto the stack, while the lock script scriptPubkey must be form-matched to ISSTANDARD.

● For each input, if the referenced output is present in any other transaction in the pool, the transaction must be rejected.

● For each input, if the referenced output transaction is Coinbase outputs, then the output transaction must have at least COINBASE _ MATURITY (100) acknowledgements.

● For each input, the referenced output must exist and cannot already be spent.

● The referenced output transactions are used to obtain the input values, and it is checked whether each input value and the sum are within the allowed range of the value x, i.e. 0< x < 21.10 ⁶.

● There must be matching transactions in the pool or in the blocks in the main branch.

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

● The transaction cost must be sufficient to obtain input for the empty block.

● Each entered unlock script must be verified against the corresponding output lock script.

These exemplary criteria are illustrative and should not be construed as sufficient or necessary for all embodiments, as the prescribed criteria may differ among different protocols and, if a change is made to a given protocol, may change over time for that protocol. In general, transaction level verification criteria refer to prescribed features that a transaction must be considered valid in accordance with the applicable blockchain protocol. Similarly, the block level verification criteria refers to specified features that a block must be considered valid according to the applicable blockchain protocol.

In accordance with the present application, methods and apparatus are described that accelerate block verification in order to facilitate faster propagation of blocks in a network. Faster, more efficient verification and propagation helps address technical challenges regarding how to extend blockchain networks, and thus provides improved applications and systems built based on such blockchain platforms.

In one aspect, the present application describes a node configured to verify a chunk by performing at least transaction-level verification of individual transactions in parallel and/or in a distributed manner. However, certain transaction level criteria may not be evaluated in parallel. For example, the uniqueness of the UTXO may be assessed on a serial basis. In this case, the distributed verification node of the present disclosure may be structured or arranged to confirm the uniqueness of the referenced input (UTXO) of the transaction before distributing the plurality of transaction sets among the set of two or more parallel processors for verifying the remaining transaction level criteria.

In particular, embodiments of the present disclosure provide improved verification and security solutions for processing related or associated data records stored in a tree structure. The tree may be a binary tree or a mesh (mesh) structure. As is known in the art, a tree structure may be broken down into smaller trees (which may be referred to herein as tree "segments," "subsets," or "portions"), where each segment includes a subset of the data records in the entire tree and has its own root. Advantageously, embodiments of the present disclosure take advantage of this feature to provide methods and systems for distributing and parallelizing the processing of related data records across multiple processing resources.

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

In one example, processing the plurality of transactions includes verifying at least a portion of a blockchain chunk that includes the plurality of blockchain transactions and a root of a merck tree for the chunk. These examples are non-limiting and the techniques disclosed herein may be used for non-blockchain related data and/or other processes other than verification. For example, embodiments may be used to store, construct, search, and/or maintain any type of data record that may be represented in a merck tree. Databases and other known storage resources may be utilized in place of or in addition to blockchain ledgers.

In another exemplary embodiment, processing the plurality of transactions includes downloading at least a portion of a blockchain chunk including the plurality of blockchain transactions and a root of a merck tree for the chunk.

For completeness, and with reference to fig. 3 and 4, the merck tree and its use in blocks representing blockchain transactions is discussed below.

Merck tree

Referring to fig. 3, the merck tree is a hierarchical data structure that enables security verification of a data set. In the merck tree, each node in the tree is provided with an index pair (i, j), and is denoted as N (i, j). The indices i, j are simply the number labels associated with a particular location in the tree.

One feature of the merck tree is that the construction of each of its nodes is controlled by the following equation:

Where H is a cryptographic hash function.

An example of a binary merck tree constructed from these equations is shown in fig. 3. As can be seen from the figure, the i=j case corresponds to a leaf node, which is simply a hash of the corresponding i-th packet of data D _i. The i+.j case corresponds to an internal node or parent node, which is generated by recursively hashing and concatenating child nodes until one parent node (merck root) is found.

For example, node N (0, 3) is constructed from four data packets D ₀,...,D₃

N(0，3)＝H(N(0，1)||N(2，3))

＝[H(N(0，0)||N(1，1))||H(N(2，2)||N(3，3))]

＝[H(H(D₀)||H(D₁))||H(H(D₂)||H(D₃))]。

The depth M of the tree is defined as the lowest level of nodes in the tree, the depth M of a node being the level at which the node is located. For example, M _root =0 and M _leaf =m, where m=3 in fig. 3.

For the merck tree in bitcoin and some other blockchain, the hash function is a double SHA256, i.e., the standard hash function SHA-256 is applied twice: h (x) =sha256 (sha256 (x)).

The main function of the merck tree is to verify that a certain data packet D _i is N data packetsMembers of a list or collection. This verification mechanism, known as merck proof, involves obtaining a set of hashes, known as merck paths, for a given data packet D _i and merck root R. The merck proof of a data packet is simply the minimum hash list required to reconstruct the root R by way of repeated hashing and concatenation, commonly referred to as "authentication proof".

If the prover knows all packets D ₀,...,D_N-1 and their order, presence proving can be performed simply. However, this does require a much greater memory overhead than merck proving, and requires the entire data set to be available to the prover.

A comparison using merck proof and using the entire list is shown in the following table, where a binary merck tree is used and the number of data blocks N is assumed to be exactly equal to an integer power of 2.

The following table shows the relationship between the number of leaf nodes in the merck tree and the number of hashes required for merck certification (merck certification).

In this simplified scenario (where the number of data packets is equal to the number of leaf nodes), it has been found that the number of hash values required to calculate the merck proof scales logarithmically. Obviously, computing the merck proof involving log ₂ N hashes is much more efficient and practical than storing N data hashes and computing the display proof.

Given the merck root R, it is desirable to prove that data block D ₀ belongs to the ordered list represented by RMerck proving can be performed as follows:

i. the merck root R is obtained from a trusted source.

Obtaining a merck proof Γ from the source. In this case Γ is the set of hashes:

Γ＝{N(1，1)，N(2，3)，N(4，7)}。

merck proof was calculated as follows using D ₁ and Γ:

a. hashing the data block to obtain:

N(0，0)＝H(D₀)。

b. concatenating with N (1, 1) and hashing to obtain:

N(0，1)＝H(N(0，0)||N(1，1))。

c. Concatenating with N (2, 3) and hashing to obtain:

N(0，3)＝H(N(0，1)||N(2，3))。

d. concatenates with N (4, 7) and hashes to obtain the root:

N(0，7)＝H(N(0，3)||N(4，7))，

R′＝N(0，7)。

e. comparing the calculated root R' with the root R obtained in (i):

1. If R' =r, then D ₀ is present in the validation tree, thereby validating the dataset

2. If R' +.R, the proof fails, and D ₀ cannot be confirmed asAnd members. /(I)

This is an efficient mechanism that can provide proof of existence for certain data that is part of the dataset represented by the merck tree and its root. For example, if data D ₀ corresponds to a blockchain transaction and root R is publicly available as part of the block header, then the transaction can be quickly proven to be contained in the block.

SPV

Simple Pay Verification (SPV) exploits these features of the merck tree, such as white book "bitcoin" in the middle book, 2008: the first time in section 8 of a point-to-point electronic cash system ". In the SPV-based cryptocurrency exchange between alice and bob, both parties use the same type of SPV wallet. The SPV wallet stores the user's private and public keys, unexpired transactions, and chunk headers that uniquely identify the chunks so that they can be located on the blockchain. As explained, the chunk header includes a data field that provides a unique digest or fingerprint of the content of the entire chunk, and a field that provides the merck root for the chunk. The merck root is generated by repeatedly hashing pairs of transaction IDs (txids) in a block together until a single hash is ultimately generated. The merck root provides an efficient and secure mechanism to verify whether a transaction is part of a chunk, as it allows users such as wallets and merchant nodes to verify a particular transaction locally without downloading the entire blockchain. This is advantageous for users (e.g., merchants and customers who wish to perform transfers between them) who do not need or wish to run a full node, but need only perform a localization check to determine whether a particular transaction is in a particular block. In summary, SPV enables such users to search the merck tree with a given root to check (i.e., verify) whether a particular transaction is included in a particular blockchain chunk without having to download and store the entire blockchain.

Thus, the SPV wallet has at least the advantage that power and storage limited devices such as cell phones and notebook computers can operate in the bitcoin ecosystem because it only needs to confirm whether the transaction has been authenticated (hence the term "simple payment authentication") rather than fully checking the blockchain in accordance with other forms of wallets. This significantly reduces the storage space, power and processing resources required for authentication, since the SPV wallet only downloads the block header and does not include any transactions. For reasons explained below, SPV wallets are particularly suitable for use with embodiments of the present disclosure, and the term "authentication" is used herein to include SPV checking.

Blocks of transactions

Fig. 4 schematically illustrates an example of a blockchain block. Each block contains a block header and a transaction set. The block header includes the hash of the previous block header, i.e., the hash of the block header of the block on which the current block is constructed. The tile header also includes the merck root of the merck tree constructed using the transaction set. Each transaction is first hashed (e.g., double hashed) to generate a transaction identifier (TxID) for the transaction. The transaction identifier is then used as a leaf node of the merck tree. The paired transaction identifiers are then concatenated and hashed to form respective internal nodes of the first internal hierarchy of the merck tree. The pairs of internal nodes of the first internal hierarchy are then concatenated and hashed to form corresponding internal nodes of the second internal hierarchy of the merck tree. The process of concatenating and hashing pairs of internal nodes is repeated until only a single hash is retained: merck root. This merck root is sometimes referred to as the block merck root.

Turning now to embodiments of the present disclosure, specific reference is made to fig. 5, 6 and 7.

Segment of merck tree identifying blocks

Suppose a particular party (e.g., alice) wishes to verify some transactions. According to an embodiment of the present disclosure, at least one subset of transactions is identified, wherein the subset forms a segment of an entire merck tree for a chunk and/or is represented by a segment of an entire merck tree for a chunk. Thus, a transaction block may be logically partitioned into multiple segments based on the merck 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 public root hash is sometimes referred to hereinafter as "Duan Haxi" to distinguish it from the root hash of the entire block. Transactions on the same level (i.e., the lowest level, sometimes referred to as the "leaf level" or "leaf level") within the tree segment are peers (siblings). All transactions in a given segment share a common root node for that segment. The common root node may belong to an adjacent level of the merck tree, i.e. a level immediately above the lowest level. Or the common root node may belong to a higher hierarchy. In general, the common root node may belong to any hierarchy between the lowest hierarchy of the merck tree and the merck root.

Decomposing a chunk into smaller parts based on the merck tree provides significant technical advantages, including being able to quickly and efficiently distribute transactions among multiple verifiers. For example, because the bitcoin protocol uses a binary tree, binary assignments can be implemented across multiple machines. By using a small binary marker as an indexing system for segments, the position of each segment in the entire merck tree can be quickly calculated so that the segments can be reassembled after verification has been completed, thereby reconstructing the complete merck tree for the block. This binary indexing method will be discussed in more detail below.

The segments may be identified using various techniques, but according to one approach, the number of segments may be determined by the number of verifiers available in the system. For example, in a system with four verifiers, the merck tree may be partitioned into four segments; if there are eight verifiers, the merck tree can be broken down into eight segments, and so on. As shown by the controller 702 of fig. 7, the identification of segments of a given merck tree may be performed or affected by a control entity.

The gist explained above is further illustrated with reference to fig. 5 and 6, wherein fig. 5 shows an example of how the merck tree may be divided into separate parts 502 to be assigned to the verifier. In the example of fig. 5, each arrow represents a respective transaction hashed to form a respective transaction identifier, which is used at a respective leaf node of the merck tree. At the top of the merck tree is the block merck root. In this example, the transaction block represented by the merck tree contains 32 transactions. However, it should be understood that this is merely an illustrative example, and that the merck tree may contain any number of transactions, generally depending on the number of transactions in a block. As shown, the merck tree is divided into four portions 502a through 502d indicated by dashed boxes. Each portion 502 is linked by a respective common internal node (internal hash) 504 of the merck tree, which is represented by a solid circle. Each section 502 represents eight transactions. In this example, the common internal node 504 belongs to the fourth level of the merck tree. According to embodiments described herein, each respective portion 502 (or, more precisely, transactions forming and/or representing a portion) is assigned to a respective verifier for processing, e.g., for verifying transactions belonging to the respective portion 502.

Fig. 6 shows another example of how the merck tree may be divided into portions 602. The merck tree in fig. 6 is the same as the merck tree in fig. 5. Now, in this example, the merck tree is divided into eight parts 602a through 602h, each part 602 representing four transactions. In this example, the common internal node 604 belongs to the third level of the merck tree. Instead, the merck tree of fig. 5 and 6 may be divided into more (e.g., 16) or fewer (e.g., 2) portions 502, 602. In general, the merck tree formed by the transaction set of a chunk can be divided into any number of portions 502, 602, where each portion includes at least two transactions.

Assigning segments to corresponding verification resources

After identification, the transaction subset is distributed across multiple validation resources, which may also be referred to as a "validator" for ease of reference. In fig. 7 and 9, multiple verifiers are shown as resources a through D (704 a through 704D). The allocation process may be directed or effected by a dedicated element such as the component 904 shown in fig. 9, but is not limited thereto.

Each verifier (704 a-704 d) may include one or more processing resources. Thus, at least one of the plurality of verifiers (704 a-704 d) may be or include at least one of: one or more virtual machines, one or more servers, one or more GPU-based computing resources, one or more threads, and/or one or more multiprocessor systems, etc. Essentially, any one of a plurality of verifiers may be comprised of any one or more types or combinations of processing resources, each capable of verifying one or more transactions associated with each other through segments of the merck tree of blocks. The plurality of verifiers (704 a-704 d) and other system components form a collective resource or entity 700, which will be referred to as a "(distributed) verification node.

Preferably, the distributing includes assigning each segment to a respective verifier of the plurality of verifiers. The verifier may be set at least to:

● Operating on one or more transactions that constitute one or more segments that have been allocated to the one or more transactions;

● Verifying one or more transactions to verify whether the one or more transactions conform to a blockchain protocol; and/or

● Verify that they can be identified in existing stores such as blockchain ledgers or databases of known, registered or spent transactions.

The activity of the verifiers and the assignment of subsets to different verifiers may be directed by the controller. Fig. 7 shows that controller 702 assigns subsets of transactions a through D of corresponding tree segments to verifiers 704a through 704D, respectively. The system level controller 702 coordinates the activities of the systems or devices 704 a-704 d within the distributed verification nodes and may control or affect tasks such as identifying tree segments using the merck tree of the block, assigning the identified segments to respective verifiers, reordering the verified tree segments into a complete merck tree for the block, and/or ordering transactions within the reconstructed block.

One or more of the verifiers may include at least one coordinating entity configured to act as a verifier-level controller. Thus, any or all of verifiers 704a through 704d may include at least one controller component of their own. The lower level controller may affect or direct operations such as assigning tasks or sub-tasks to one or more processing resources within the verifier, reconstructing the merck tree for a given segment, or interacting with other system components (e.g., other verifiers or higher level controllers, UTXO pools, wallets, etc.). In turn, the processing resources themselves may be further broken down into smaller systems, where one or more of the smaller systems may include the controller and its own processing resource or resources. In this manner, the system may include a hierarchical architecture in which segment verification is performed by verification entities that include one or more processing resources for performing verification tasks, and one or more controllers for coordinating processor activities and performing inter-component communications.

In embodiments where the verifier includes multiple processing resources, the verifier may divide its allocated segments into smaller segments. The controller of the verifier may then distribute the subsections among the processors under its control. In this way, the verification process may be implemented in a hierarchical and distributed manner.

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

Thus, the present disclosure enables many transactions to be processed simultaneously, the only limitation being the amount of hardware available to form the distributed verification node, rather than the amount of processing speed available that becomes a bottleneck as in conventional techniques. This enables the blockchain processing system to be horizontally extended without requiring changes to the underlying protocol of the blockchain network.

Accordingly, the present disclosure has significant deviation from the conventional verification method, which is described in more detail below in the section entitled "exemplary technical environment for implementing the illustrative embodiments of the present disclosure" and with reference to fig. 1 and 2. As explained, the conventional approach involves verifying one tile as an entire entity, while the conventional view of the verification node (see 104 of fig. 1) is taken as a single computing unit. Instead, embodiments of the present disclosure decompose the merck tree into a plurality of segments that are provided to different verifiers (704 a through 704d in fig. 7 and 9), each segment and verifier being able to be further decomposed to increase the degree of distribution involved.

Further, by decomposing each chunk into segments based on its merck tree, embodiments of the present disclosure enable verifiers to access, download, and process small portions of chunks instead of entire chunks. It should be remembered that the transactions in each segment are hashed (in pairs) to a single root value. This means that only the necessary related transactions can be used to verify the segment, not the entire block that is downloaded, stored and processed in its entirety. Since protocols such as bitcoin SV allow for expanding the block size and including larger blocks in the ledger, the traditional model of downloading the entire block becomes a bottleneck. Embodiments of the present disclosure overcome this challenge of blockchain scalability by enabling individual verifiers to receive and process only the (smaller) portions associated therewith. This results in faster overall verification times, improved blockchain networks, and improved applications running on the blockchain.

Furthermore, embodiments support and facilitate the use of SPV processes and resources, as such SPVs involve only local verification of the portion of the merck tree that is of interest to a given party. Thus, the tree pruning nature of SPV techniques is well suited for use in connection with embodiments of the present disclosure. In the SPV context, only the portion of the chunk data that it needs, i.e., the chunk header or segment root node and related transactions, may be provided to the verifier.

When each verifier has performed its check and confirmed the validity of the segment it has processed, it can be guaranteed that the block is valid due to the hash mechanism used for the spanning tree.

Load balancing across multiple verifiers

Load balancing techniques and systems are known in the art, the purpose of which is to distribute tasks evenly across multiple resources in order to increase efficiency. The purpose of this is to minimize the risk that some processing resources are in idle state while others are overloaded, resulting in reduced performance and even failure. Load balancing therefore becomes critical in ensuring the flexibility of the overall system, as well as its performance and efficiency. Embodiments of the present disclosure may utilize any known load balancing technique, such as static or dynamic load balancing. Additionally or alternatively, the load balancing methods disclosed herein may be advantageously used.

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

When a tree segment needs to be assigned to a verifier, the first 4 bits of its double hash (i.e., duan Haxi of the tree segment) can be used to determine which verifier will process the segment. It should be remembered that the merck root is generated by hashing pairs of transaction IDs (txids) together in a chunk to generate corresponding internal nodes (or internal hashes) of the merck tree, and then hashing adjacent internal hashes repeatedly until a single hash is ultimately generated. The merck root subjected to double hash processing provides an efficient, quick and safe verification mechanism. In the context of the present disclosure, this also has the advantage of double hashing to generate random binary numbers. Each internal hash (including each segment hash) is itself a double hash. Thus, the first x leading bits of Duan Haxi may be used as the allocation index. A hash with four leading zeros will result in a tree segment being assigned to a verifier with ID 0000, while a hash with leading bits 0001 will result in a verifier with ID 0001, and so on. The random generation of the double hash ensures that the tree segments are randomly distributed to the verifier.

Although double hashing is typically used when generating the merck tree, double hashing is not necessarily used in all examples, but only a single hash may be used. In fact, any number of hash operations will produce random binary numbers. The load balancing tasks may be performed by dedicated system components, as shown at 905 in fig. 9, or may be provided elsewhere within the system 700, or associated with and in communication with the system 700.

Distributed download or receive block

According to some embodiments, assigning segments of a block merck tree to different verifiers may be used to provide a faster, more efficient process for receiving (e.g., downloading) part or all of a transaction block. The term "download" may be used herein for convenience, but the disclosure is not so limited, and one or more of these verifiers may obtain data in other ways, such as by receiving a transmission from a sending resource over a network such as the internet or a VLAN.

Each verifier is assigned a segment of the merck tree, e.g., based on the assignment index described above. Any given verifier is then used to download the transaction set that forms the assigned 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 may be downloaded to the internal memory of the verifier or to a shared storage location, such as a shared driver in the cloud.

In some embodiments, the one or more verifiers may receive data in the form of one or more data packets sent to the multicast address to which the verifiers subscribe. The multicast address may be an IPv6 multicast address as known in the art. One, some, or all of these verifiers may subscribe to the multicast address. In some embodiments, subsets of verifiers may subscribe to different respective multicast addresses, such that transactions for different segments may be assigned to groups of verifiers sharing a common multicast address.

A distributed node may need a complete block, i.e., an entire transaction set forming a block. In this case, each verifier assigned a tree segment downloads a subset of transactions forming the segment. In other cases, the distributed node may only need some portion of the block. In this case, only some verifiers may need to download their respective transaction subsets in order to obtain the desired transaction.

Downloading a chunk (or a portion of a chunk) in this manner increases the overall download speed, as each verifier only processes a subset of the transactions that form the entire transaction set for that chunk. This is in contrast to conventional block downloads in which a given entity (e.g., a full node) must download an entire block, for example, by downloading each transaction in the order in which it occurs in the block. The block is now downloaded in parallel by multiple verifiers. A block may contain thousands of transactions, perhaps orders of magnitude more. Downloading this number of transactions by a single entity would consume a significant amount of resources and take a significant amount of time. The computational burden is now distributed among the verifiers such that each individual verifier consumes a small portion of the processing resources. Similarly, this reduces the total time to download the block.

As discussed, each verifier may download a subset of transactions. These subsets may then be combined to reconstruct the block in a single storage location. ("single storage location" refers to a storage resource that is an independent entity or a plurality of associated storage resources that form a collective entity). To this end, each verifier may transmit its respective subset to a central controller of the distributed node, which is configured to arrange the transactions in the correct order. Duan Haxi (i.e., a hash of the linked tree segment) may be used for this purpose. For example, a mapping of the segment hash to its location in the merck tree may be maintained, e.g., from left to right (when Duan Haxi appears in the merck tree). The subsets of transactions may then be placed in order (e.g., from first to last) based on the corresponding segment hashes.

In some embodiments, each verifier (or distributed node as a whole) can confirm that the correct transaction has been downloaded (or that the transaction has been downloaded correctly) by reconstructing the merck tree. After downloading the subset of transactions, the verifier may generate a candidate segment hash based on the transactions. The candidate segment hash is constructed by hashing the pair of txids to generate a corresponding internal hash, and repeating the hashing of the pair of internal hashes until a candidate segment hash is generated. The level of the merck tree to which the candidate segment hash belongs will depend on the number of tree segments into which the merck tree is divided. The verifier may verify that the candidate segment hash is a hash of the merck tree. If the hashes do not match, an error occurs during the download process. In some examples, each verifier may generate a candidate segment hash and send it to the controller to perform the verification. As another example, candidate block merck roots may be generated based on the entire transaction set downloaded. Likewise, if a chunk has been downloaded correctly, the candidate merck root should match the actual chunk merck root (i.e., the merck root stored in the chunk).

In some cases, the verifier may verify the downloaded transaction using the techniques described above. That is, each verifier is assigned a tree segment, downloads a corresponding subset of transactions, and verifies the transactions. In other cases, the verifier may not necessarily verify the transaction, and may simply download the transaction for later use, e.g., for transmission to a third party.

Distributed UTXO pool

Preferably, each verifier 704 forming part of a distributed verification node has its own repository (pool) for generating, storing and/or maintaining unexpired transaction output (UTXO). The repository (pool) acts as a UTXO pool that provides a record of the unconsumed (i.e., unconsumed) output associated with the blockchain transaction. Thus, the UTXO pool of each verifier is based on the transactions that the controller assigns to it with respect to the merck tree segment, and is built from these transactions. In one embodiment, this may be a (graph) database that includes data related to the unused UTXOs that have been assigned to transactions for processing by a given verifier. When a new merck tree segment is assigned to the verifier, a record is created in the database for each UTXO that the verifier is aware of. Thus, from the perspective of a distributed verification node, the UTXO pool is not a single pool, but is made up of a plurality of different UTXO pools, each provided at or on a different verifier and comprising a different set of UTXOs. Thus, the UTXO pool for that node is distributed in terms of both data and the resources that store and/or process the data.

This is in contrast to the traditional UTXO model, where each complete node in the network has a copy of the UTXO pool that tracks all UTXOs on the blockchain. In contrast, the present disclosure distributes UTXO pools across multiple validation resources, each validation resource having a UTXO pool that is a subset of the entire set of UTXOs of the blockchain. The UTXO pool of each verifier includes UTXOs of transactions that make up the merck tree sub-part responsible for verification.

According to this approach, each time a new chunk needs to be verified, the new chunk can be implemented in a manner similar to an SQL transaction log, in that every command, event, and item associated with the database is recorded in the log. The term "database log" will be used herein to avoid confusion due to the use of the term "transaction", as is known with respect to blockchains, but is used to include terms such as "transaction log", and the like. Essentially, a database log can be interpreted as a history of actions performed by a database management system, providing a record of all changes that have occurred to the database state, as is known in the art of computer-based databases (see https:// en. Wikipedia. Org/wiki/transaction_log).

Using an ordered history database log means that the entire UTXO pool can be built by executing the history of the log in its original order. Advantageously, this ensures that copies of the database can always be (re) generated when needed, and that no separate copy of the data need be stored. This ensures data integrity and requires less memory resources. Each UTXO pool may be stored, maintained, and processed separately. Also advantageously, if the SPV technique operates on a pruned portion of the merck tree, the SPV technique may facilitate creating a separate UTXO database for each verifier.

Transactions (TX) within a database may be structured in various ways, although a particularly advantageous approach is to construct transactions from identifiers comprising a concatenation of a block ID and a transaction ID (block_id ll TxID). Both the block ID and the transaction ID are 256-bit hashes, resulting in a secure and collision-free 512-bit concatenated field structure.

Constructing transactions in this manner provides a fast, efficient lookup mechanism. Transactions may be ordered by block_id such that all transactions with the same block_id are located together in the database. Thus, when a verifier needs a transaction (e.g., to check if the UTXO for the transaction has already spent), the verifier may locate the transaction in the database by first searching for the corresponding block_id and then searching for the corresponding TxID. The effect of this is that the search is limited to relevant parts of the database. Such efficiency reduces the time, processing resources, and energy required for the search operation, thereby achieving significant improvements over the prior art.

A flag or marker is associated with each UTXO in the pool of verifiers and indicates whether the UTXO is locked or unlocked. For convenience, this flag or marker may be referred to as a "lock flag". When a UTXO is marked as "locked," this indicates to the verifiers in the group (i.e., elsewhere in the distributed verification node) that the UTXO is not available for spending. Conversely, when the UTXO is marked as "unlocked," this indicates to the verifier that the UTXO may cost. Thus, its role is to enable a verifier that has been assigned to validate the transaction spending UTXO to signal to its peer that the transaction spending UTXO, assuming that the transaction has proven valid, has been redeemed and is therefore no longer expendable. The "locked" state means the allowable costs, and the "unlocked" state means the forbidden costs.

The lock/unlock flag may be a simple small binary flag, e.g., 0 indicates "lock" and "1" indicates unlock. The tagging mechanism is used internally by a verifier in the distributed node system to remove tags from transactions prior to interacting with the blockchain so that the transactions conform to protocol rules.

In use, the verifier examines the output of each new transaction that the controller assigns to it. Any unexpired output (UTXO) is added to the UTXO pool of the verifier, i.e. recorded as an entry in the UTXO database. In the associated database record for each new UTXO, the lock flag is set to "unlock".

When a verifier finds that a newly allocated transaction is spending a UTXO, the verifier sends a message to each other of the plurality of verifiers informing them that the UTXO should also be locked in its respective pool. Essentially, the verifier sends a communication to its peer indicating that the verifier has found a cost related to a transaction with a particular hash ID at a particular time. Other verifiers need not receive complete data for the entire transaction because the transaction hash and its list of spent UTXOs are sufficient for them to identify the relevant transaction and mark it as locked in their own database. Upon receipt of the message, each receive verifier checks whether the associated UTXO is in its UTXO pool. If so, the state of the lock flag is changed to "locked". Thus, the lock prevention verifier allows the same UTXO to be spent in subsequent transactions. In the event that the new transaction does attempt to spend the same UTXO, checking the lock flag will indicate that the second spending attempt is ignored. If the verifier sending the message determines that verification failed and therefore the UTXO has not yet spent, another message may be sent to the verifier peer to this effect indicating that the lock flag of the UTXO should be changed to the "unlocked" state. Once the cost of validity has been completed, a message may be sent to this effect and the locked UTXOs may be deleted from the associated UTXO pool.

In the above embodiment, each verifier has a single UTXO pool that includes UTXOs that have been assigned to all transactions in all of its tree segments. However, by alternative methods, the UTXO pool maintained by each verifier may be divided/partitioned/divided into/made up of multiple sub-pools, one for each block. In this way, a single UTXO pool may be organized into a logical hierarchy. By another approach, one or more verifiers may be provided in association with a respective plurality of UTXO pools, each of the plurality of UTXO pools being associated with a UTXO for a set of one or more tree segments. Thus, in some embodiments, one or more verifiers may organize the UTXOs into separate UTXO pools for different individual tree segments or according to some predefined criteria, such as tree segment type or tree segments within a given range. In such embodiments, the identifier may include a tile ID that may be used to narrow the search to a pool of related UTXOs, and the search may then be conducted within the pool to (attempt) identify related transactions by their txids. It will be appreciated by those skilled in the art that in some embodiments a mix of these methods may be used, i.e., one or more verifiers within a distributed node may use a single UTXO pool method, while the other one or more verifiers are configured to use multiple separate UTXO pools and/or UTXO pools organized into sub-pools, or any combination thereof.

This may prevent a "double spending" situation, i.e., one party tries to spend the same UTXO twice. This provides a simple and secure locking mechanism that can operate efficiently, quickly, and maintain the security and integrity of transmissions implemented on the blockchain, regardless of the number or location of verifiers in the system.

Illustrative System of possible embodiments

Fig. 7 and 9 illustrate an exemplary system 700 for implementing at least some of the described embodiments. Fig. 8 shows a flowchart of exemplary steps that may be taken in (a brief view of) the methods of the present disclosure.

The system 700 may be a closed system in that it may be associated with an organization and form part of a larger proprietary system. In this case, its data (e.g., transactions) may be received from other components within the organization's broader system and its results and output sent to an internal destination. Additionally or alternatively, the system 700 may be configured to interface with various entities, some or all of which may be located outside of an organization. In this case, the system 700 may be configured to provide verification functionality as a service. For example, system 700 may be configured to interact with a blockchain network to obtain the data it needs. Additionally or alternatively, the system may interact with an entity desiring to use its verification services. Thus, the activities of system 700 may be internal activities only with respect to a particular organization or entity, or may open interactions with external entities to provide verification services to other parties, or a combination of both. Communications between other internal or external entities may be coordinated by one or more interfaces or communication components, as shown at 902 in fig. 9.

As shown in fig. 7 and 9, the system 700 includes a control entity 702 (or simply "controller") and a plurality of verification resources 704 (also referred to herein simply as "verifiers"). Fig. 7 shows only four verifiers 701a through 701d, but system 700 may generally include any number of verifiers. Further, the controller 702 is shown in fig. 7 and 9 as being different from the verifiers 704, but it is not excluded that the controller 702 may include or consist of one of the verifiers 704. As described above, each verifier may include one or more processing resources and may include its own controller for coordinating its own internal activities. The hierarchical level that can be implemented in this way has no technical or logical limitations. However, for simplicity, while for ease of understanding, fig. 7 shows only one (top-level) level of such a hierarchy.

As shown in fig. 7, the controller 702 obtains a transaction set. The transaction may be received from a sending resource over an electronic channel or network. The sender may be any entity that wishes to perform some sort of verification check, either inside or outside the system organization as described above. This may be, for example, a complete node on a blockchain network, such as node 104 in FIG. 1, or a digital wallet, or a merchant/SPV node that wishes to perform local checks related to blockchain-implemented transfers between parties. One or more interfaces 902 may facilitate data transfer between the system 700 and sources external to the system.

Transaction formation or may form a transaction block. Transactions may be obtained from a single resource (e.g., from a block of a blockchain), or from different resources (e.g., one or more users, one or more blockchain nodes, etc.). Transactions may be obtained before they have been published on the blockchain (i.e., before being recorded in the block). Or the transaction may be obtained after it has been recorded on the blockchain.

The controller 702 assigns each verifier 704 a respective subset of transactions, as described herein. Each subset of transactions forms at least a portion of a respective portion of a merck tree generated based on the entire set of transactions and is linked by a respective common internal node of the merck tree. In the example of fig. 7, transaction subset a is assigned to verifier a, transaction subset B is assigned to verifier B, transaction subset C is assigned to verifier C, and transaction subset D is assigned to verifier D. After the transaction subsets have been allocated, verifier 704 then processes its respective subset. In some embodiments, this involves each verifier 704 verifying its respective subset of transactions. To this end, the controller 702 may transmit the relevant transaction to the respective verifier 704. The verifier 704 may communicate back to the controller 704 to indicate that each transaction in its respective subset of transactions is valid, or that at least one transaction is invalid.

At least one of verifiers 704a through 704d, but preferably some or all of the verifiers may have access to their own UTXO pools, shown as 901a through 901d in fig. 9. The pool includes the storage facilities such as the database described above and may have an advantageous indexing structure comprising a concatenation of a block ID and a transaction ID. In fig. 9, 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 by being external to, but in communication with, the verifiers.

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

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

Assuming that the new blocks are not rejected, i.e., all UTXO inputs are unique, the merck tree segments may be identified and the associated transactions for these merck tree segments are centrally allocated in the verifier. The identification process may be performed by a component such as the segment identification unit 903 shown in fig. 9. The allocation process may be performed by a segment allocation unit (shown as 904 in fig. 9). The allocation unit 904 may employ any of a number of possible allocation schemes to distribute the block segments among the verifiers, but in an advantageous approach the allocation scheme may be targeted for load balancing as described above. The distribution unit 904 may include (or be in communication with) a load balancing unit 905. Although this is shown in fig. 9 as a separate associated component of the system, in other embodiments the load balancing unit may be part of the distribution unit 904 or separate with respect to the controller 702. Any combination of components may be readily employed.

Each verifier verifies transactions associated with one or more segments they receive against transaction-level verification criteria. The synchronous paradigm is not required between verifiers because they each independently verify whether the transactions assigned to them are valid. Each verifier outputs a result that confirms the validity of its assigned transaction. The results are added or accumulated to confirm that all transactions in the segment are valid. If one of the verifiers identifies an invalid transaction, the verifier may issue an output, such as an interrupt or other signal, to indicate that an invalid transaction exists. The interrupt or signal may be sent to other verifiers or controllers or another system component so that they may immediately stop testing their respective transactions and not waste more resources when verifying transactions within a block that are to be rejected.

In some examples, the system may be set to check block level criteria. This may be performed prior to assigning the segments to the verifier, although it should be appreciated that the block-level verification phase may occur after, or in some cases in parallel with, the transaction-level verification test of the verifier.

Reference will now be made to fig. 8, which illustrates in flow chart form one example of a method of verifying a block. The block contains a plurality of transactions, each referencing one or more inputs, and each input is UXTO (except where Coinbase generated the transaction). The method is implemented using appropriate hardware and processor-executable instructions within nodes on a blockchain network.

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

In step S802, the system 700 identifies a block of the merck tree of blocks. In S803, the segments are distributed to a plurality of verifiers; and in S804 the verifiers process their respective transaction subsets substantially in parallel and independently of each other. In S805, the verifier signals the controller whether verification succeeded or failed.

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

Enumerating clauses

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

The features mentioned below in relation to a set of enumerated clauses or aspects of the present disclosure are not intended to be limited in this regard, and any one or more features mentioned in relation to a set of clauses may be incorporated into one or more of the other sets of clauses.

Clause set 1:

embodiments of the present disclosure may provide one or more systems for implementing any of the methods described in the following clauses. The one or more systems may be used to perform any of the following methods.

Clause 1.1. A computer-implemented method for processing (e.g., verifying) at least a portion of a blockchain chunk, the blockchain chunk including a plurality of blockchain transactions and a root of a merck tree for the chunk.

The method may comprise one or more of the following steps:

Allocating respective subsets of the blockchain transactions to a plurality of processing (e.g., verifying) resources, wherein each respective subset provides a respective portion of the merck tree and is represented by a respective internal node of the merck tree; and/or

The plurality of processing (e.g., validation) resources are used to process (e.g., validate) their respective subsets of blockchain transactions.

Additionally or alternatively, the method may comprise:

At least a portion of a blockchain block is sent or received, the blockchain block including a plurality of blockchain transactions and a root of a merck tree for the block. The portion of the blockchain block may be transmitted from a transmit resource to a receive resource. The portion of the blockchain block may be transmitted over a network (e.g., the internet). The method may comprise the steps of: the portion of the blockchain block is processed at the receive resource. The receiving resource may be referred to as a processing or verification resource. The portion of the blockchain block may be transmitted using IPv6 multicast transmissions. At least one, some or all of the plurality of processing resources may be members of an IPv6 multicast group. The transmission resources may include network devices. The network device may be configured to send IPv6 multicast communications to a multicast address. MLD snooping may be enabled at the network device. This provides efficiency in terms of traffic on the network, as the transmit resources can selectively transmit portions of the blockchain blocks to particular receive resources (e.g., resources within the plurality of processing resources). By sending data packets to all resources on the network, including those resources that do not need or desire to receive data, network traffic can be reduced and energy and processing resources are not wasted. This also improves security, as it avoids the possibility of denial of service (DOS) attacks, and it also facilitates scalability of the blockchain network by allowing faster transaction throughput due to lower network congestion levels.

The term "verifier" may be used interchangeably with "verifying resources". For convenience, a "verifier/validation" may be used herein in place of a "processor/process". The plurality of verification resources may form a distributed verification node. At least one verification resource of the plurality of verification resources may include one or more processing resources. Additionally or alternatively, one or more of the plurality of verification resources may comprise a verifier controller component substantially as described herein. At least one or some of the verification resources within the distributed verification node may share (i.e., subscribe to) a public IPv6 multicast address.

The respective internal node may be a segment root. In other words, an "internal node" is a node in the merck tree that is neither the root nor leaf node of the entire tree. The transactions in each subset may share a respective common internal node.

In an alternative wording, each subset may comprise at least two transactions associated with a common node in the merck tree, such that the subset provides and/or is represented by a (sub) portion of the merck tree. The common (internal) node may be a segment node or root substantially as described herein. The portion of the merck tree may be a "segment" substantially as described herein.

Clause 1.2 the method of clause 1.1, wherein verifying the blockchain blocks and/or the subset of blockchain transactions comprises:

i) Validating and/or validating at least one blockchain transaction; and/or

Ii) performing a Simple Payment Verification (SPV) procedure; and/or

Iii) Determining whether a given blockchain transaction (Tx) is contained within the blockchain block; and/or

Iii) Generating a hash of at least one of the blockchain transactions, constructing a merck path using the hash, and/or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block.

Clause 1.3 the method of clause 1.1 or 1.2, wherein:

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

Clause 1.4 the method of clause 1.3, wherein:

the identifier facilitates computing a location of the at least one subset within the merck tree.

Clause 1.5 the method of clause 1.3 or 1.4, wherein:

The identifier includes a portion of a hash of a blockchain transaction within the at least one subset of blockchain transactions.

Clause 1.6. The method of any of the preceding clauses, wherein:

the step of assigning the respective subset of blockchain transactions to the plurality of verified resources includes: the respective subset is matched with respective verification resources based on respective identifiers associated with the subset of transactions.

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

i) Downloading at least one subset of blockchain transactions to at least one validation resource of the plurality of validation resources; and/or

Ii) sending at least one subset of blockchain transactions to at least one validation resource of the plurality of validation resources.

Clause 1.8. The method of any of the preceding clauses, wherein:

The merck tree includes a binary tree or mesh (mesh) of hashes of the plurality of blockchain transactions.

Clause 1.9. The method according to any of the preceding clauses, the method further comprising the steps of:

the subset of blockchain transactions within the plurality of blockchain transactions is identified and/or determined.

Clause 1.10. The method of any of the preceding clauses, wherein:

At least one of the plurality of verified resources verifies that the resource is or includes one or more of:

virtual machines, servers, GPU-based computing resources, processing threads, and/or multiprocessor systems.

Clause 1.11. The method of any of the preceding clauses, wherein:

i) The at least two transactions are peers in the merck tree; and/or

Ii) the common node is a parent or ancestor of the at least two transactions.

Clause 1.12. A blockchain verification system for verifying at least a portion of a blockchain block, the blockchain block including a plurality of blockchain transactions and a root of a merck tree for the block;

Wherein the system comprises a plurality of verification resources, each verification resource comprising:

A processor; and

A memory comprising executable instructions that, when executed by the processor, cause the system to perform the computer-implemented method according to any of the preceding clauses.

Clause 1.13 is a non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any of clauses 1.1 to 1.11.

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

Further, there is provided a blockchain system (network) comprising a plurality of computer-implemented nodes, wherein each node in the blockchain network comprises:

A processor; and

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

The network may be used to operate using a blockchain protocol as described herein.

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

Clause set 2:

embodiments of the present disclosure may provide one or more systems for implementing any of the methods described in the following clauses. The one or more systems may be used to perform any of the following methods.

Clause 2.1. A computer-implemented method for receiving (e.g., downloading) at least a portion of a blockchain chunk, the blockchain chunk including a plurality of blockchain transactions and a root of a merck tree for the chunk; the method comprises the following steps:

Allocating respective subsets of the blockchain transactions to a plurality of processing resources, wherein each respective subset provides a respective portion of the merck tree and is represented by a respective internal node of the merck tree; and

One, some, or all of the plurality of processing resources are used to receive (e.g., download) their respective subsets of blockchain transactions.

In accordance with one or more embodiments, the one, some, or all of the processing resources may receive their respective subsets of blockchain transactions from a providing (sending) resource. The portion of the blockchain block may be transmitted over a network (e.g., the internet). The respective subset of blockchain transactions may be sent using IPv6 multicast transmissions. At least one, some or all of the plurality of processing resources may be members of an IPv6 multicast group. The transmission resources may include network devices. The network device may be configured to send IPv6 multicast communications to a multicast address. MLD snooping may be enabled at the network device. This provides efficiency in terms of traffic on the network, as the transmit resources may selectively transmit one or more subsets of blockchain transactions to particular receive resources (e.g., resources within the plurality of processing resources). By sending data packets to all resources on the network, including those resources that do not need or desire to receive data, network traffic can be reduced and energy and processing resources are not wasted. This also improves security, as it avoids the possibility of denial of service (DOS) attacks, and it also facilitates scalability of the blockchain network by allowing faster transaction throughput due to lower network congestion levels.

Each respective subset may be represented by the respective internal node, in the sense that the respective internal node may encode the respective subset. That is, the respective internal nodes may be generated based on (i.e., according to) the respective subsets. Each transaction in the respective subset may be linked to the respective internal node by one or more hash operations.

Clause 2.2 the method of clause 2.1, the method comprising:

one, some, or all of the plurality of processing resources send their respective subsets of blockchain transactions to the central storage.

Clause 2.3 the method of clause 2.2, wherein:

the respective internal nodes of the merck tree have respective locations in the merck tree, and wherein the method comprises:

The respective subset of blockchain transactions is arranged based on the respective location of the respective internal node of the merck tree.

Clause 2.4. The method according to any of the preceding clauses, the method comprising:

One, some, or all of the processing resources generate respective candidate internal nodes of the merck tree based on the downloaded respective subset of blockchain transactions; and the method further comprises at least one of:

Verifying that the respective candidate internal node matches the respective internal node of the merck tree; and/or

Verifying that the respective candidate internal node is a node of the merck tree by performing merck certification based on the root of the merck tree; and/or

The respective candidate internal nodes of the merck tree are sent to one or more other processing resources.

Clause 2.5 the method of any of the preceding clauses, the method comprising:

One, some, or all of the plurality of processing resources are used to validate their respective subsets of blockchain transactions.

Clause 2.6 the method of clause 2.1, wherein:

verifying the respective blockchain transaction subset includes:

i) Validating and/or validating at least one blockchain transaction; and/or

Ii) performing a simple payment verification process; and/or

Iii) Determining whether a given blockchain transaction is contained within the blockchain block; and/or

Iii) Generating a hash of at least one of the blockchain transactions, constructing a merck path using the hash, and/or checking whether the hash matches a transaction identifier in a blockhead of the blockchain block.

Clause 2.7. The method of any of the preceding clauses, wherein:

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

Clause 2.8 the method of clause 2.7, wherein:

the respective identifiers facilitate computing respective locations of the at least one respective subset within the merck tree.

Clause 2.9. The method of clause 2.7 or 2.8, wherein:

the respective identifiers are based on the respective internal nodes of the merck tree.

10. The method of clause 9, wherein:

The respective identifiers include a portion of the respective internal nodes of the merck tree.

Clause 2.11. The method of any of the preceding clauses, wherein:

The step of allocating the respective blockchain transaction subset to the plurality of respective processing resources includes: the respective subset of transactions is matched with respective processing resources based on respective identifiers associated with the respective subset of transactions.

Clause 2.12. The method of any of the preceding clauses, wherein:

the merck tree includes a binary tree or mesh structure of hashes of the plurality of blockchain transactions.

Clause 2.13 the method of any of the preceding clauses, the method comprising:

the subset of blockchain transactions within the plurality of blockchain transactions is identified and/or determined.

Clause 2.14. The method of any of the preceding clauses, wherein:

at least one of the plurality of processing resources is or includes: virtual machines, servers, GPU-based computing resources, or multiprocessor systems.

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

A processor; and

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

Clause 2.16 is a non-transitory computer readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer system, cause the computer system to perform, or enable the computer system to perform, the computer-implemented method according to any of clauses 2.1 to 2.14.

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

Clause set 3:

embodiments of the present disclosure may provide one or more systems for implementing any of the methods described in the following clauses. The one or more systems may be used to perform any of the following methods.

Clause 3.1. A computer-implemented method, the method comprising the steps of:

Generating, storing, and/or maintaining a first output store for recording, searching, and/or processing a plurality of unexpired transaction outputs (e.g., UTXOs), each unexpired transaction output associated with a transaction (Tx) of a plurality of blockchain Transactions (TXs) of a blockchain block;

Wherein:

The plurality of blockchain transactions provides and/or is represented by a portion of a merck tree for the blockchain block.

In some embodiments, the first output repository may be referred to as a first UTXO output repository. The unexpired transaction output may be referred to as UTXO.

Clause 3.2 the method of clause 3.1, the method comprising:

at least one other output repository is generated, stored, and/or maintained.

Clause 3.3 the method of clause 3.1 or 3.2, further comprising:

A database log is created and/or maintained that includes a history of actions, changes, and events associated with the output repository.

Clause 3.4. The method of any of the preceding clauses, wherein:

the first output repository and/or the at least one other output repository includes at least one record associated with:

i) Non-spent transaction output; and/or

Ii) an identifier associated with a) an unexpired transaction output and/or b) a transaction (Tx) of the plurality of blockchain transactions.

Clause 3.5 the method of clause 3.4, wherein:

The at least one record includes a record identifier having:

i) A block identifier (block_id), the block identifier being associated with a block chain block; and/or

Ii) a transaction identifier (TxID) associated with a transaction (Tx) of the plurality of blockchain transactions.

Clause 3.6 the method of clause 3.5, wherein:

i) The record identifier comprises a function of the block identifier (block_id) and the transaction identifier (TxID); and/or

Ii) concatenation of the block identifier (block_id) and the transaction identifier (TxID); and/or

Iii) The transaction of the plurality of blockchain transactions is associated with an unexpired transaction output.

Clause 3.7 the method of clause 3.5 or 3.6, further comprising the steps of:

at least one record in the output repository is searched, identified, accessed, or inserted using the record identifier.

Clause 3.8. The method of any of the preceding clauses, wherein:

at least one of the plurality of unexpired transaction outputs is associated in the output store with a lock flag that:

i) Indicating whether the unexpired transaction output is available for spending; and/or

Ii) configurable between a first state indicating that the unexpired transaction output is allowed to be spent and a second state indicating that the unexpired transaction output is prohibited from being spent.

Clause 3.9 the method of clause 3.8, comprising the steps of:

i) Associating the unexpired transaction output with the lock flag; and/or

Ii) changing the state of the lock flag from the first state to the second state or from the second state to the first state.

Clause 3.10 the method of clause 3.8 or 3.9, comprising the steps of:

A communication is sent from a first processing resource to at least one other processing resource to cause the at least one other processing resource to change the state of the lock flag associated with the unexpired transaction output from the first state to the second state or from the second state to the first state.

The communication may be sent to an IPv6 address associated with the at least one other processing resource using multicast transmission.

Clause 3.11 the method of clause 3.10, wherein the communicating comprises:

i) Transaction (TX), transaction identifier (TxID), and/or hash of Transaction (TX); and

Ii) a list of one or more unexpired transaction outputs.

Clause 3.12 the method of clause 3.10 or 3.11, comprising the steps of:

receiving the communication at the at least one other processing resource;

The state of the lock flag is changed from the first state to the second state or from the second state to the first state.

Clause 3.13. The method of any of the preceding clauses, wherein:

i) The portion of the merck tree is a sub-portion or segment of the merck tree for the blockchain chunk; and/or

Ii) the plurality of blockchain transactions are represented by internal nodes of the merck tree.

Clause 3.14. A system of blockchain implementation, the system comprising a plurality of processing resources, each processing resource comprising:

A processor; and

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

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

Clause set 4:

Any of the embodiments defined in any term or combination of terms in clause set 4 may be used to implement any one or more of clauses set 1-4, or in combination with any one or more of clauses set 1-4. Embodiments of the present disclosure may provide a system for implementing any of the methods described according to the enumerated clause set.

Clause 4.1. A system for verifying at least a portion of a blockchain block, the blockchain block including a plurality of blockchain transactions and a root of a merck tree for the block, the system comprising:

a plurality of processing (e.g., verifying) resources, each processing (e.g., verifying) resource comprising:

at least one processor associated with at least a portion of a memory storing executable instructions that, when executed by the at least one processor, cause or enable the verification resource to:

At least a subset of the plurality of blockchain transactions is processed (e.g., verified), wherein the at least a subset provides a portion of the merck tree and is represented by internal nodes of the merck tree.

Clause 4.2 the system of clause 4.1, wherein the system further comprises:

i) A load balancing component for facilitating balancing distribution of a plurality of subsets of the plurality of blockchain transactions among the plurality of verified resources; and/or

Ii) a segment identification component for facilitating identification of the at least a subset of the plurality of blockchain transactions; and/or

Iii) A distribution unit; and/or

Iv) one or more interfaces for sending or receiving communications between the system and one or more data sources or destinations.

Clause 4.3 the system of clause 4.1 or 4.2, wherein:

The system includes at least one controller component for affecting and/or controlling operation of at least one of:

at least one verification resource;

at least one processor of the at least one verified resource;

One or more interfaces;

One or more load balancing components; and/or

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

Clause 4.4. The system of any of the preceding clauses, wherein:

i) At least two transactions of the plurality of blockchain transactions are peers in the merck tree; and/or

Ii) the internal node is a parent or ancestor of the subset of blockchain transactions.

Clause 4.5 the system of any of the preceding clauses, further comprising:

A plurality of output repositories, each of the plurality of repositories being associated with a respective verification resource and being operable to facilitate recording, searching and/or processing a plurality of unexpired transaction outputs; preferably, wherein each of the plurality of unexpired transaction outputs is associated with at least one transaction (Tx) of the plurality of blockchain transactions.

Clause 4.6 the system of clause 4.5, wherein the system is used to:

creating and/or maintaining a database log including a history of actions, changes, and events associated with at least one of the plurality of output repositories.

Clause 4.7 the system of any of the preceding clauses, wherein:

At least one output repository of the plurality of output repositories includes at least one record associated with:

i) Non-spent transaction output; and/or

Ii) an identifier associated with a) an unexpired transaction output and/or b) a transaction (Tx) of the plurality of blockchain transactions.

Clause 4.8 the system of clause 4.7, wherein:

The at least one record includes a record identifier having:

i) A block identifier (block_id), the block identifier being associated with the blockchain block; and/or

Ii) a transaction identifier (TxID) associated with a transaction (Tx) of the plurality of blockchain transactions.

Clause 4.9 the system of clause 4.7 or 4.8, wherein the record identifier comprises:

i) A function of the block identifier (block_id) and the transaction identifier (TxID); and/or

Ii) concatenation of the block identifier (block_id) and the transaction identifier (TxID).

The system of clause 4.10, wherein the system is for:

the record identifier is used to search, identify, access, or insert the at least one record in at least one of the plurality of output repositories.

The system of any of clauses 4.11-4.5 to 4.10, wherein:

At least one of the plurality of unexpired transaction outputs (e.g., UTXOs) is associated with a lock flag that:

i) Indicating whether the unexpired transaction output is available for spending; and/or

Ii) configurable between a first state indicating that the unexpired transaction output is allowed to be spent and a second state indicating that the unexpired transaction output is prohibited from being spent.

Clause 4.12 the system of clause 4.11, the system being used to:

the state of the lock flag is changed from the first state to the second state or from the second state to the first state.

Clause 4.13 the system of any of the preceding clauses, wherein the system is used to:

i) Assigning respective subsets of the blockchain transactions to the plurality of verified resources; and

Ii) using one, some or all of the plurality of validation resources to download and/or receive a respective subset of blockchain transactions.

Clause 4.14 the system of any of the preceding clauses, the system being for:

generating respective candidate internal nodes of the merck tree based on the downloaded respective subset of blockchain transactions using one, some, or all of the validation resources; and the system is further configured to perform at least one of:

verifying that the respective candidate internal node matches the respective internal node of the merck tree; and/or

Verifying that the respective candidate internal node is a node of the merck tree by performing a merck proof based on the root of the merck tree; and/or

The respective candidate internal nodes of the merck tree are sent to one or more other processing resources.

Clause 4.15 the system of any of the preceding clauses, wherein the system is used to:

i) Validating and/or validating at least one blockchain transaction; and/or

Ii) performing a simple payment verification process; and/or

Iii) Determining whether a given blockchain transaction is contained within the blockchain block; and/or

Iii) Generating a hash of at least one of the blockchain transactions, constructing a merck path using the hash, and/or checking whether the hash matches a transaction identifier in a blockhead of the blockchain block.

Clause 4.16 the system of any of the preceding clauses, wherein:

At least one of the plurality of verified resources is or includes at least one of: virtual machines, servers, GPU-based computing resources, threads, and/or multiprocessor systems.

Clause set 5

Any of the embodiments defined in any term or combination of terms in the set of terms 5 may be used to implement or combine with any term in any one or more of the set of terms herein.

Embodiments of the present disclosure may provide one or more systems for implementing any of the methods described in the following clauses. The one or more systems may be used to perform any of the following methods.

Clause 5.1 a computer-implemented method, the method comprising: using partial data derived from the blockchain to identify and/or allocate processing and/or storage resources (processing and/or or storage resource), wherein the data from which the partial data is derived includes: unexpired transaction output (UTXO) and/or a transaction (Tx) containing unexpired output.

Additionally or alternatively, the data may include transaction data for determining that at least a portion of a transaction (Tx) is contained in the merck path of the blockchain chunk (B).

Information associated with the data derived from the blockchain will be stored in resources for efficient and cost-effective referencing. By using part of the data to allocate the resources, a relationship between the data, its associated information and the resources storing the data may be maintained. The data may include an unexpired transaction output (UTXO) and/or a transaction (Tx) containing an unexpired output (e.g., UTXO). A portion of the data is used to determine a key, which in turn determines an allocated resource that will store information about the data.

A database of (unexpired) transaction outputs and/or a database of transactions with unexpired transaction outputs may be established. The database may be a distributed database, forming a distributed pool. The database may hold at least one of the following: a flag of the validity of the unexpired transaction output (UTXO) and/or of the transaction (Tx) containing unexpired transaction output; and information capable of determining the validity of the unused transaction output and/or of the UTXO-containing transaction (Tx), such as SPV information that may be used for SPV verification or at least a portion of the merck proof of SPV-related operations.

The method may include retrieving partial data and/or associated data derived from the blockchain prior to allocation to enable subsequent identification of the resource. After the allocation is made, the method may include storing and/or verifying the spent transaction output (UTXO) and/or the transaction (Tx) containing the UTXO.

The allocation may support load balancing among multiple resources.

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

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

Clause 5.3 the method of clause 5.1 or 5.2, further comprising: receiving said data from which said portion of data is derived at the allocated resources; parsing the data to determine whether to: processing the data and/or storing information derived from the data, or taking no action.

A portion of the data and/or information associated with the data may be received from a plurality of resources and a determination may be made as to whether it is responsible for storing the information related to the UTXO.

Clause 5.4 the method of any of the preceding clauses, the method further comprising: the portion of data is derived from the blockchain.

Clause 5.5. The method of any of the preceding clauses, wherein identifying and/or allocating the processing and/or storage resources is performed by an intermediary connected to a plurality of allocated resources.

Clause 5.6. The method of any of the preceding clauses, wherein the allocated resources perform at least one of: at least partially verifying the unexpired transaction output (UTXO) and/or a transaction (Tx) containing the UTXO; records of verification data required to verify the spent transaction output (UTXO) and/or the UTXO-containing transaction (Tx) are generated, stored, and/or maintained.

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

Clause 5.8 the method of any of the preceding clauses, wherein processing the data comprises: a key is determined, wherein the key determines the allocated resources.

Clause 5.9 the method of clause 5.8, wherein the key is hashed and the resulting hash determines the allocated resource.

Clause 5.10. The method of any of the preceding clauses, wherein at least one of the data, the key, and the resulting hash comprises at least one of: a number (alphanumeric number) comprising letters and numbers, a binary number; and, the number is used to determine the allocated resources.

Clause 5.11 the method of clause 5.10, wherein the portion of the number is parsed to determine the allocated resources.

Clause 5.12. The method of any of the preceding clauses, wherein a hash table (hash table) determines the allocated resources in which at least a portion of the UTXO and/or the transaction (Tx) is stored.

Clause 5.13 the method of any of clauses 5.6 to 5.12, wherein the recording of the at least a portion of the UTXO and/or the transaction (Tx) comprises at least one of: a merck tree for recording blocks of the transaction (Tx); a merck root for recording the block of the transaction (Tx); a merck path capable of determining a value of the merck root for recording the block of the transaction (Tx) from a hash of the transaction (Tx); merck proof; a block identifier (block_id), the block identifier being associated with a block chain block; a transaction identifier (TxID) associated with a transaction (Tx) of 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).

Clause 5.14. The method of any of the preceding clauses, the method further comprising, for at least a portion of the transaction (Tx) and/or the UTXO, at least one of: verifying and/or validating the UTXO; performing at least a portion of a Simple Payment Verification (SPV) process for the UTXO; confirm whether a given blockchain transaction (Tx) is included in the blockchain block; generating a hash of at least one of the blockchain transactions, constructing a merck path using the hash and/or checking whether the hash matches a transaction identifier (TxID) in a blockhead of the blockchain block; determining a merck proof for the UTXO.

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

Clause 5.16. A computer-implemented method, the method comprising: receive and/or process an unexpired transaction output (e.g., UTXO) for inclusion in the transaction; and/or using partial data derived from the unexpired transaction output to identify an allocated resource, wherein the allocated resource holds verification data for the unexpired transaction output (e.g., UTXO); and/or requesting the verification data from the allocated resources.

Clause 5.17 the method of clause 5.16, further comprising obtaining at least one of the following from the allocated resources:

(i) Verification of the UTXO and/or the transaction (Tx) containing the UTXO; and/or the number of the groups of groups,

(Ii) A record for determining the validity of the UTXO and/or the transaction (Tx) containing the UTXO.

Clause 5.18 the method of any of the preceding clauses, further comprising: -preparing and/or transmitting a transaction (Tx) having as input said UTXO.

Clause 5.19. A blockchain node configured to at least one of generate, store, and maintain UTXO resources for recording, searching, and/or processing a plurality of unexpired transaction outputs (UTXOs), wherein the node processes partial data derived from the blockchain to identify and/or allocate processing and/or storage resources, wherein deriving the data of the partial data therefrom comprises: unexpended transaction output (UTXO) and/or transactions (Tx) containing unexpended transaction output (e.g., UTXO).

Clause 5.20. A computer device, the computer device comprising: a memory, the memory comprising one or more memory cells; and a processing device comprising one or more processing units, wherein the memory stores code configured to run on the processing device, the code configured to perform the method according to any of clauses 5.1-5.18 when run on the processing device.

Clause 5.21. A computer program embodied on a computer readable memory and configured to perform the method according to any of clauses 5.1 to 5.18 when run on one or more processors.

Clause set 6

Any of the embodiments defined in any of the clauses or combinations of clauses in clause set 6 may be used to implement any one or more of clauses 1-5, or in combination with any one or more of clauses 1-3.

Embodiments of the present disclosure may provide one or more systems for implementing any of the methods described in the following clauses. The one or more systems may be used to perform any of the following methods.

Clause 6.1 a computer-implemented method, the method comprising:

Generating, storing, processing, accessing and/or maintaining a record of at least a portion of the transaction (Tx),

Wherein the record includes transaction data for determining that the at least a portion of the transaction (Tx) is contained in a merker path of a blockchain block (B).

In general, the record is used to hold information such as data items. As described elsewhere, the records may be stored in a database or the like in an allocated resource, which may be part of a resource connected to the blockchain, such as a node or other resource connected to the blockchain network. The invention is not limited in this regard and the verification, distribution/identification and format of the records may be used to implement the functionality of a node, which may be in-chain.

The record may include at least transaction data and may also include a status flag/status, authentication information, verification data, detailed information about where the UTXO is located, a reference to at least one previous record, such as location, signature, and authorization data. The record enables data associated with the transaction to be stored and stored in a cataloged manner.

In other words, the record is part of a pruned version of the blockchain block. The record will become part of a collection of records, preferably stored in the allocated resource, and hold data items obtained directly from a block of the blockchain and/or data derived from the blockchain, such as a collection of verification data or information associated with a transaction.

The system 1100 manages the database and/or the allocated resources 1104 that hold records of transactions. The system may be considered to behave like a node-the record holds transaction data with at least a portion of a transaction contained in the merck path, thus enabling merck linked pruning nodes.

For example, the system (e.g., the merck linked pruning node) may be established and used by the owner. For example, blockchain data associated with tokens issued by England banks may be held as records in the allocated resources. The record may be a pruned and/or enhanced version of the corresponding transaction data held on the blockchain.

As taught herein, configuring the record supplements at least one of verification of the transaction, processing and/or allocation and/or identification of storage resources. The recorded content can increase security, resilience, and efficiency, or reduce speed and resource requirements, when used, including validating the transaction involved with the record.

The allocation and/or identification is based on partial data derived from all or at least a portion of the blockchain transaction, e.g., the partial data derived includes transaction data, which may be an unexpired transaction output (UTXO) and a UTXO-containing transaction (Tx). Additionally or alternatively, the data may include transaction data for determining that at least a portion of a transaction is contained in the merck path of a blockchain chunk.

Clause 6.2 the method of clause 1, wherein the record comprises a data catalog (data catalog), the data catalog being or comprising a collection of the transaction data.

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

Clause 6.4, the method of any of the preceding clauses, wherein the at least a portion of the transaction (Tx) is an output of the transaction.

Clause 6.5 the method of clause 4, wherein the output of the transaction is

Unexpired transaction output (UTXO) and/or

A transaction (Tx) comprising a UTXO of a block chain block.

Clause 6.6. The method of any of the preceding clauses, wherein the record is stored in a database, the record comprising:

i) A blockchain transaction (TX 0), the blockchain transaction (TX 0) comprising at least one data item (D); and

Ii) at least one other blockchain transaction (TX 1), the at least one other blockchain transaction (TX 1) being necessary to confirm that the blockchain transaction (TX 1) is contained in the merck path of blockchain block (B).

Clause 6.7. The method of any of the preceding clauses, wherein using the database comprises generating, maintaining, providing, updating, storing, accessing, or processing:

i) The database; and/or

Ii) data stored within or associated with the database.

Clause 6.8 the method of any of the preceding clauses, wherein the recording further comprises: a merck path from the transaction (TX 0) to the root of the merck tree for the blockchain chunk (B).

Clause 6.9. The method of any of the preceding clauses, wherein: the merck path includes at least: establishing or validating the blockchain transaction (TX 0) includes a minimum blockchain transaction required in the blockchain block (B).

The method of clause 6.10, wherein the blockchain chunk is stored on or in association with:

i) Blockchain ledger; and/or

Ii) an under-chain storage resource.

Clause 6.11 the method of any of clauses 6 to 10, further comprising: validating using the blockchain transaction (TX 0) and the at least one other blockchain transaction (TX 1): the blockchain transaction (TX 0) is included in the merck path of the blockchain block (B).

Clause 6.12 the method of any of clauses 6 to 11, wherein the data item (D):

Storing in association with a script in the transaction; and/or

Stored as metadata in the transaction.

Clause 6.13 the method of any of the preceding clauses, wherein the recording further comprises: verification data required to verify the unexpired transaction output (UTXO) and/or the transaction (Tx) containing the UTXO.

The method of clause 6.14, wherein the recording further comprises:

The unexpired transaction output (UTXO) and/or a history (history) of a plurality of previous transactions including a transaction (Tx) of the UTXO.

The method of clause 6.15, wherein the recording further comprises:

a history of allocated resources, which process and/or store

Said data of at least one previous transaction is preferably at least one transaction of said unexpired transaction output (UTXO) and/or a transaction (Tx) comprising UTXO.

The method of clause 14 or 15, wherein the history comprises at least one of:

A set of transaction data for determining a merck proof of the previous transaction or transactions;

a link of the respective allocated resources that process and/or store the plurality of previous transactions.

The method of clause 6.17, wherein the recording further comprises:

The unexpired transaction output (UTXO) and/or a flag and/or status indication for the or each input of a transaction (Tx) containing a UTXO.

The method of clause 6.18, wherein the recording further comprises at least one of:

A merck tree for recording blocks of the transaction (Tx);

A merck root for recording the block of the transaction (Tx);

A merck path capable of determining a value of the merck root for recording the block of the transaction (Tx) from a hash of the transaction (Tx);

Merck proof;

A block identifier (block_id), the block identifier being associated with the blockchain block;

A transaction identifier (TxID) associated with a transaction (Tx) of 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);

a digital signature;

an authentication code;

A signed message, the signed message used to determine a transaction state;

A protocol flag;

An autonomous public key (DPK);

Autonomous transaction ID (DTxID).

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

Clause 6.20. A computer-implemented method, the method comprising:

using a database, the database comprising at least one record, the at least one record comprising:

i) A blockchain transaction (TX 0), the blockchain transaction (TX 0) comprising at least one data item (D); and

Ii) at least one other blockchain transaction (TX 1), the at least one other blockchain transaction (TX 1) being necessary to confirm that the blockchain transaction (TX 1) is contained in the merck path of blockchain block (B).

Clause 6.21 the method of clause 20, wherein using the database comprises generating, maintaining, providing, updating, storing, accessing, or processing:

i) The database; and/or

Ii) data stored within or associated with the database.

The method of clause 6.22, wherein the recording further comprises: a merck path from the transaction (TX 0) to the root of the merck tree for the blockchain chunk (B).

The method of clause 6.23, wherein the merck path comprises at least: establishing or validating the blockchain transaction (TX 0) includes a minimum blockchain transaction required in the blockchain block (B).

The method of any of clauses 20-23, wherein the tile is stored on or associated with: blockchain ledger; and/or an off-chain storage resource.

The method of any one of clauses 20-24, further comprising:

Verifying that the blockchain transaction (TX 0) is included in the merck path of the blockchain block (B) using the blockchain transaction (TX 0) and the at least one other blockchain transaction (TX 1).

The method of any one of clauses 20 to 25, wherein the data item (D): storing in association with a script in the transaction; and/or stored as metadata in the transaction.

The method of any of clauses 20-26, wherein the transaction further comprises: transaction ID (TxID); a protocol flag; an autonomous public key (DPK); and autonomous transaction ID (DTxID).

Clause 6.28. A computer device, the computer device comprising:

a memory, the memory comprising one or more memory cells; and

A processing device comprising one or more processing units, wherein the memory stores code configured to run on the processing device, the code configured to perform the method according to any of clauses 1-27 when run on the processing device.

Clause 6.29, a computer program embodied on a computer readable memory and configured to perform the method according to any of clauses 1 to 27 when run on one or more processors.

Exemplary technical Environment for implementing illustrative embodiments of the disclosure

An overview of a computing environment in which one or more embodiments of the present disclosure may be practiced is now described. However, as noted above, this context is not intended to be limiting, and embodiments may be used to handle 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.

FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet switched network 101, typically a wide area internet such as the internet. The packet switched network 101 includes a plurality of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet switched network 101. Although not shown, blockchain node 104 may be set to a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

Each blockchain node 104 includes a peer's computer device, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, such as one or more Central Processing Units (CPUs), accelerator processors, special purpose processors, and/or Field Programmable Gate Arrays (FPGAs), among other devices, such as Application Specific Integrated Circuits (ASICs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as Solid State Disks (SSDs), flash memory or electrically erasable programmable read-only memory (EEPROMs), and/or optical media such as optical drives.

The blockchain 150 includes a series of data blocks 151 with a respective copy of the blockchain 150 maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean completely storing the blockchain 150. Instead, the blockchain 150 may perform data pruning as long as each blockchain node 150 stores a block header (discussed below) for each block 151. 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 particular transaction protocol throughout. In one common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing a digital asset as an amount of property, an example of which is the output being cryptographically locked to the user 103 (requiring the user's signature or other solution to be unlocked for redemption or spending). Each input points to the output of a previous transaction 152, linking the transactions.

Each block 151 also includes a block pointer 155 that points to previously created blocks 151 in the blockchain to define the order of the blocks 151. Each transaction 152 (in addition to coinbase transactions) includes a pointer to the previous transaction to define the order of the sequence of transactions (note: the sequence of transactions 152 may branch). The blockchain of the blockchain 151 dates back to the start block (Gb) 153, which is the first blockin the blockchain. Early one or more original transactions 152 in the blockchain 150 point to the start block 153 instead of the previous transaction.

Each blockchain node 104 is configured to forward the transaction 152 to other blockchain nodes 104 such that the transaction 152 propagates throughout the network 106. Each blockchain node 104 is configured to create a block 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into the block 151. Ordered pool 154 is commonly referred to as a "memory pool". In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to an ordered set of transactions that node 104 has accepted as valid, and for which node 104 is forced to not accept any other transactions that attempt to expend the same output.

In a given current transaction 152j, the input (or each input) includes a pointer that references the output of the previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152 j. In general, the previous transaction may be any transaction in ordered set 154 or any block 151. Although in order to ensure that the current transaction is valid, there will be a need to have the previous transaction 152i and verify that it is valid, there is no need to have the previous transaction 152i when creating the current transaction 152j and even sending the current transaction 152j to the network 106. Thus, in this context, "prior" refers to predecessors in the logical sequence linked by pointers, not necessarily creation times or transmission times in the time sequence, and thus the case of out-of-order creation or transmission transactions 152i, 152j is not necessarily precluded (see discussion below regarding isolated transactions). The previous transaction 152i may also be referred to as a look-ahead transaction or a look-ahead transaction.

The input of the current transaction 152j also includes an input authorization, such as a signature of the user 103a to which the output of the previous transaction 152i was locked. In turn, the output of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152 j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users or entities (one of which may be original user or entity 103a for alteration). In some cases, a transaction may also have multiple inputs, summarizing the amounts in multiple outputs of one or more previous transactions, and reassigning to one or more outputs of the current transaction.

According to an output-based transaction protocol, such as bitcoin, when a party 103, such as an individual user or organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuer sends the new transaction from its computer terminal 102 to the recipient. The issuer or recipient will eventually send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle other user terminals are possible as well). It is also not precluded 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, may not send the transaction to the recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to the blockchain point protocol applied at each blockchain node 104. The blockchain point protocol typically requires the blockchain node 104 to check whether the encrypted signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of the previous transaction 152i assigned by the new transaction, where the condition typically includes checking at least whether the cryptographic signature or other authorization in the input of 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. Or this may be determined solely by the block link point protocol, or may be determined by a combination thereof. Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain point protocol and thus forward the new transaction 152j to one or more other nodes 104, and so on. In this way, new transactions propagate throughout the network of blockchain nodes 104.

In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether it is effectively redeemed by the input of another subsequent transaction 152j according to the blockchain point protocol. Another condition that the transaction is valid is that the output of its previous transaction 152i attempting to be redeemed has not yet been redeemed by another transaction. Also, if invalid, the transaction 152j will not propagate (unless marked invalid and propagated for reminder) or record in the blockchain 150. This prevents the duplication of costs, i.e. the transaction processor's output allocation to the same transaction more than once. On the other hand, account-based models prevent recurring costs by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at any time.

In addition to verifying that a transaction is valid, blockchain node 104 also contends to be the first node to create a block of transactions in a process commonly referred to as mining, which is supported by "proof of work". At the blockchain node 104, the new transaction is added to an ordered pool 154 of valid transactions that have not yet occurred in the blocks 151 recorded on the blockchain 150. The blockchain node then contends to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve the encryption challenge. Typically, this involves searching for a "random number" value such that when the random number is juxtaposed with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has some predefined number of leading zeros. Note that this is just one particular type of proof of work challenge and does not exclude other types. The hash function is characterized by having an unpredictable output relative to its input. Thus, the search can only be performed with brute force, consuming a significant amount of processing resources at each blockchain node 104 that is attempting to solve the puzzle.

The first blockchain node 104 to solve the problem declares the problem solution on the network 106, providing the solution as proof, and then other blockchain nodes 104 in the network can easily check the solution (once a solution for a hash value is given, can directly check if the solution has the output of the hash value meet the condition). The first blockchain node 104 propagates a block to other nodes that accept the block to achieve a threshold consensus, thereby enforcing the protocol rules. Ordered transaction set 154 is then recorded by each blockchain node 104 as a new chunk 151 in blockchain 150. The block pointer 155 is also assigned to a new block 151n that points to a previously created block 151n-1 in the blockchain. The significant amount of work (e.g., in the form of a hash) required to create the proof of work solution signals the intent of the first node 104 to follow the blockchain protocol. These rules include accepting no transaction as valid if it allocates the same output as the transaction previously verified to be valid, otherwise referred to as a repeat cost. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointer 155 also applies an order to the block 151. Since the transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an unchangeable common ledger for transactions is provided.

It should be noted that different block chain nodes 104 that contend to solve a puzzle at any given time may do so based on different snapshots of pool 154 of transactions that have not yet been issued at any given time, depending on the order in which they begin searching for or receiving transactions. The person who solves the corresponding puzzle first defines the transactions 152 and their order included in the new block 151n and updates the current unpublished transaction pool 154. The blockchain node 104 then proceeds to contend to create a block from the newly defined unpublished transaction ordered pool 154, and so on. In addition, there are protocols that address any "bifurcation" that may occur, where two blockchain nodes 104 solve a problem within a short time of each other, propagating conflicting views of the blockchain between nodes 104. Briefly, the bifurcation direction is longest and becomes the final blockchain 150. It should be noted that this does not affect the users or agents of the network, as the same transaction will occur in both forks.

Based on the bitcoin blockchain (and most other blockchains), the node that successfully constructs the new block 104 is granted the ability to newly allocate additional, accepted amounts of digital assets in a new special type of transaction that allocates an additional defined amount of digital assets (as opposed to inter-agent or inter-user transactions that transfer a certain amount of digital assets from one agent or user to another). This particular type of transaction is commonly referred to as a "coinbase transaction," but may also be referred to as a "start transaction" or a "produce transaction. It typically forms the first transaction for the new block 151 n. The proof of work signals the intent of the node constructing the new block to follow the protocol rules, allowing the particular transaction to be redeemed at a later time. The blockchain protocol rules may require a maturity period, for example 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction cost in one of its outputs to further reward blockchain nodes 104 that create the block 151n in which the transaction was issued. This cost is commonly referred to as the "transaction cost" and is discussed below.

Because of the resources involved in transaction verification and distribution, typically at least each blockchain node 104 takes the form of a server including one or more physical server units, or even an entire data center. In principle, however, any given blockchain node 104 may take the form of one user terminal or a group of user terminals networked together.

The memory of each blockchain node 104 stores software configured to run on the processing devices of the blockchain nodes 104 to perform their respective roles and process the transactions 152 in accordance with the blockchain point protocol. It should be appreciated that any actions attributed herein to blockchain node 104 may be performed by software running on the processing means of the respective computer device. The node software may be implemented in an application layer or in one or more applications at a lower layer, such as an operating system layer or a protocol layer, or any combination of these layers.

Computer devices 102 of each of the parties 103 playing the role of a consuming user are also connected to the network 101. These users may interact with the blockchain network 106 but not participate in verifying transactions or constructing blocks. Some of the users or agents 103 may act as senders and receivers in transactions. Other users may interact with blockchain 150 without having to act as a sender or receiver. For example, some parties may act as storage entities that store copies of blockchain 150 (e.g., have obtained copies of blockchains from blockchain nodes 104).

Some or all of the parties 103 may connect as part of a different network, such as a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required by blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 to utilize the blockchain 150 by connecting to the blockchain node 106 (i.e., communicating with the blockchain node 106). For illustration purposes, both parties 103 and their respective 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 the system 100, but are not illustrated for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as alice and the second party 103b is referred to as bob, but it should be understood that this is not limited to alice or bob, and any references herein to alice or bob may be replaced with "first party" and "second party", respectively.

The computer device 102 of each party 103 includes a respective processing means comprising one or more processors, such as one or more CPUs, graphics Processing Units (GPUs), other accelerator processors, application-specific processors, and/or FPGAs. The computer device 102 of each party 103 also includes memory, i.e., computer readable memory in the form of a non-transitory computer readable medium. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and/or optical media such as optical drives. Memory on the computer device 102 of each party 103 stores software including a respective instance of at least one client application 105 arranged to run on a processing means. It should be understood that any actions attributed herein to a given party 103 may be performed by software running on the processing means of the corresponding computer device 102. The computer device 102 of each party 103 comprises at least one user terminal, for example a desktop or laptop computer, a tablet computer, a smart phone or a wearable device such as a smart watch. 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 the user terminal.

Client application 105 may initially be provided to computer device 102 of any given party 103 by, for example, an appropriate computer readable storage medium downloaded from a server, or by a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a floppy disk or magnetic tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

Client application 105 includes at least a "wallet" function. This has two main functions. One of which is to enable the corresponding party 103 to create, authorize (e.g., sign) and send a transaction 152 to one or more bitcoin nodes 104 and then propagate through the network of blockchain nodes 104 for inclusion in the blockchain 150. Another function is to report to the corresponding party the amount of digital asset it currently owns. In an output-based system, this second function includes sorting out the amounts defined in the output of the various transactions 152 that are dispersed in the blockchain 150 that belong to the interested party.

Note that: while various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead any of the client functions described herein may be implemented in a suite of two or more different applications, such as interfacing via an API or as a plug-in to one application as another. More colloquially, client functionality may be implemented at the application layer or at a lower layer such as the operating system or any combination of these layers. The description will be described below in terms of client application 105, but it should be understood that this is not limiting.

An instance of a client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This may enable the wallet functionality of the client 105 to send the transaction 152 to the network 106. The client 105 may also contact the blockchain node 104 to query the blockchain 150 for any transactions that the corresponding party 103 is a recipient (or indeed check the blockchain 150 for transactions of other parties, because in an embodiment the 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 transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify the transaction 152 and forward the transaction 152 for propagation in the blockchain network 106 according to the blockchain point protocol. The transaction protocol and the node protocol correspond to each other, and the given transaction protocol and the given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

When a given party 103 (say alice) wishes to send a new transaction 152j to be included in the 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 152 from client application 105 to the blockchain node or nodes 104 to which she is connected. For example, this may be the blockchain node 104 that best connects with alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it will process according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j satisfies a particular condition to become "valid", a specific example of which will be discussed in detail later. In some transaction protocols, validity conditions may be configured on a per transaction basis by scripts contained in the transaction 152. Or the condition may be merely a built-in function of the node protocol or defined by combining a script and the node protocol.

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

Upon entering the pending ordered pool of transactions 154 maintained at a given blockchain node 104, that blockchain node 104 will begin to contend for solving a proof-of-job puzzle on the latest version of its respective pool 154 containing new transactions 152 (bearing in mind that other blockchain nodes 104 may attempt to solve the puzzle based on different transaction pools 154. But the person that first solved the puzzle will define the set of transactions included in the latest block 151. Eventually, blockchain node 104 will solve a portion of the puzzle of ordered pool 154, including alice's transaction 152 j). Once pool 154, including new transaction 152j, completes the proof of work, it will invariably become part of one of blocks 151 in blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of the transactions is also recorded unchanged.

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

As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of the previous transaction in the past transaction sequence, but by reference to the absolute account balance. The current state of all accounts is stored separately by the nodes of the network into the blockchain and is updated continuously. In such systems, transactions are ordered using running transaction records (also referred to as "positions") of accounts. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields may also be signed in the transaction. For example, if the data field contains the ID of the previous transaction, the data field may point to the previous transaction.

UTXO-based model

Fig. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Embodiments of the invention are not limited to use with this model, and other protocols are within the scope of the present disclosure. Transaction 152 (simply "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The description will be made below by referring to an output-based or "UTXO" -based protocol. But this is not limited to all possible embodiments. It should be noted that while the exemplary UTXO-based protocol is described with reference to bitcoin, it may be implemented on other exemplary blockchain networks as well.

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

Say alice 103a wishes to create a transaction 152j that transfers the amount of the associated digital asset to bob 103 b. In fig. 2, alice's new transaction 152j is labeled "Tx ₁". The new transaction obtains the digital asset amount locked to alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to bob. In fig. 2, the previous transaction 152i is labeled "Tx ₀".Tx₀ and Tx ₁ are just arbitrary labels, which does not necessarily mean that Tx ₀ refers to the first transaction in the blockchain 151 and Tx ₁ refers to the subsequent transaction in the pool 154. Tx ₁ may point to any previous (i.e., look ahead) transaction that still has the spent output 203 locked to alice.

When alice creates her new transaction Tx ₁, or at least when she sends the new transaction to the network 106, the previous transaction Tx ₀ may already be valid and included in the block 151 of the blockchain 150. The transaction may already be included in one of the blocks 151 at this time, or may still wait in the ordered set 154, in which case the transaction will soon be included in the new block 151. Or Tx ₀ and Tx ₁ may be created and sent together to network 106; or Tx ₀ may even be sent after Tx ₁ if the node protocol allows buffering "orphaned" transactions. The terms "prior" and "subsequent" as used herein in the context of a transaction sequence refer to the order of the transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may also be replaced with "predecessors" and "successors", "antecedents" and "offspring" or "parents" and "children", etc. This does not necessarily refer to the order in which it was created, sent to the network 106, or arrived at any given blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to a previous transaction (look ahead transaction or "parent transaction") will not be valid unless the parent transaction is valid. Child transactions that arrive at blockchain node 104 before a parent transaction are considered orphaned transactions. Depending on the node protocol and/or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

One of the one or more outputs 203 of the previous transaction Tx ₀ includes a particular UTXO, labeled UTXO ₀. Each UTXO includes a value specifying the digital asset amount represented by the UTXO and a locking script defining the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction to validate the subsequent transaction to successfully redeem the UTXO. Typically, a locking script locks an amount to a particular party (beneficiary of the transaction of that amount). That is, the locking script defines an unlocking condition, which generally includes the following conditions: the unlock script in the input of the subsequent transaction includes an encrypted signature of the party to which the previous transaction was locked.

A lock script (also known as scriptPubKey) is a piece of code written in a domain-specific language identified by a node protocol. A specific example of such a language is called "Script" (S uppercase), which may be used by blockchain networks. The lock script specifies information required to spend the transaction output 203, such as alice signed requirements. An unlock script appears in the output of the transaction. An unlock script (also known as SCRIPTSIG) is a piece of code written in a domain-specific language that provides the information required to meet the lock script standard. For example, it may contain bob's signature. An unlock script appears in the input 202 of the transaction.

Thus in the example shown, the UTXO ₀ in the output 203 of Tx ₀ includes a locking script CHECKSIG P _A that requires alice's signature Sig P _A to redeem the UTXO ₀ (strictly speaking, to validate subsequent transactions attempting to redeem the UTXO ₀). [ CHECKSIG P _A ] contains a representation (i.e., hash) of public key P _A of Alice's public-private key pair. The input 202 of Tx ₁ includes a pointer to Tx ₁ (e.g., by its transaction ID (TxID ₀), which in an embodiment is a hash of the entire transaction Tx ₀). The input 202 to Tx ₁ includes an index identifying UTXO ₀ in Tx ₀ to identify it among any other possible outputs to Tx ₀. The input 202 of Tx ₁ further includes an unlock script < Sig P _A >, which includes alice's encrypted signature created by applying alice's private key in its key pair to predetermined partial data (sometimes referred to as a "message" in cryptography). Data (or "messages") that alice needs to sign to provide a valid signature may be defined by a lock script, a node protocol, or a combination thereof.

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

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

Where "||" denotes juxtaposition "< … >" denotes placing data on the stack, "[ … ]" denotes a function consisting of a locking script (in this example, a stack-based language). Also, rather than concatenating scripts, scripts may run one after another using a common stack. Either way, when run together, the script uses alice's public key P _A (included in the locked script of the output of Tx ₀) to authenticate whether the unlocked script in the input of Tx ₁ contains the signature when alice signed the data of the intended portion. It is also necessary to include the expected portion of the data itself ("message") in order to perform this authentication. In an embodiment, the signed data includes the entire Tx ₁ (and thus need not include a separate element to explicitly specify the signed portion of the data, as it already exists itself).

Those skilled in the art will be familiar with the details of authentication by public and private passwords. Basically, if alice has encrypted a signed message using his private key, then given alice's public key and the message in plain text, other entities such as node 104 can verify that the message must have been signed by alice. Signing typically involves hashing the message, signing the hash value and signing this to the message as a signature, thereby enabling any holder of the public key to verify the signature. Thus, it should be noted that in an embodiment, any reference herein to signing a particular data segment or transaction portion, etc., may mean signing the hash value of that data segment or transaction portion.

If the unlock script in Tx ₁ satisfies one or more conditions specified in the lock script of Tx ₀ (and thus, in the example shown, if Alice's signature is provided and verified in Tx ₁), then the blockchain node 104 considers Tx ₁ valid. This means that the blockchain node 104 will add Tx ₁ to the pending transaction ordered pool 154. The blockchain node 104 may also forward the transaction Tx ₁ to one or more other blockchain nodes 104 in the network 106 so that it may propagate throughout the network 106. Once Tx ₁ is valid and included in the blockchain 150, this will define UTXO ₀ as spent from Tx ₀. It should be noted that Tx ₁ is only active when it spends the unused transaction output 203. If it tries to spend the output that another transaction 152 has spent, tx ₁ will be inactive even if all other conditions are met. Thus, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx ₀ has already spent (i.e., whether it has already formed a valid input for another valid transaction). This is one of the reasons why it is important that the blockchain 150 impose a defined order on the transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXOs 203 of spent transactions 152, but ultimately defining whether a UTXO has spent depends on whether a valid input for another valid transaction is formed in the blockchain 150.

If the total number specified in all outputs 203 of a given transaction 152 is greater than the total number pointed to by all of its inputs 202, this is another basis for failure in most transaction models. Thus, such transactions are not propagated or included in block 151.

Note that in the UTXO-based transaction model, a given UTXO needs to be used as a whole. A portion of the amount defined as spent in the UTXO cannot be "left behind" while another portion is spent. The amount of UTXOs may be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXOs ₀ of Tx ₀ may be split among multiple UTXOs in Tx ₁. Thus, if alice does not want to give bob all the amounts defined in UTXO ₀, she can use the remainder to make his own change in the second output of Tx ₁ or pay the other party.

In practice alice typically also needs to include a fee for the bitcoin node 104, which bitcoin node 104 successfully contains alice's transaction 104 in block 151. If alice does not include such fees, tx ₀ may be rejected by blockchain node 104 and thus, while technically effective, may not propagate and be included in blockchain 150 (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept). In some protocols, the transaction cost does not require its own separate output 203 (i.e., a separate UTXO is not required). Instead, any difference between the total pointed to by the input 202 and the total pointed to by the output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 that issued the transaction. For example, assume that the pointer to UTXO ₀ is the only input to Tx ₁ and that Tx ₁ has only one output UTXO ₁. If the digital asset amount specified in UTXO ₀ is greater than the amount specified in UTXO ₁, the difference may be assigned by node 104 that wins the proof of work contest to create a block containing UTXO ₁. Alternatively or additionally, this does not necessarily preclude that the transaction cost may be explicitly specified in one of the UTXOs 203 of its own transaction 152.

Alice and bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered throughout the UTXOs of the various transactions 152 of the blockchain 150. No location in blockchain 150 stores a number defining the total balance of a given party 103. The purpose of the wallet function of the client application 105 is to put together the various UTXO values that are locked to the respective party and that have not yet been spent in other subsequent transactions. To achieve this, it may query the copy of the blockchain 150 stored at any of the bitcoin nodes 104.

It should be noted that script code is typically represented schematically (i.e., in a non-precise language). For example, an operation code (opcode) may be used to represent a particular function. "op_," refers to a specific opcode of the scripting language. For example, op_return is a scripting language opcode that, when op_false is added before the opcode at the beginning of the locking script, creates an inexpensible output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include files that need to be stored in a blockchain.

Typically, the input of the transaction contains a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using an elliptic curve secp k 1. Digital signatures sign specific data segments. In an embodiment, for a given transaction, the signature will sign part of the transaction input as well as part or all of the transaction output. Signing a particular portion of the output depends on the SIGHASH flag. The SIGHASH flag is typically 4-byte code contained at the end of the signature to select the output of the signature (and thus fixed at the time of signing).

The locking script is sometimes referred to as "scriptPubKey" meaning that it typically includes the public key of the party to which the corresponding transaction is locked. The unlock script is sometimes referred to as "SCRIPTSIG" meaning that it typically provides a corresponding signature. But more colloquially, the UTXO redemption conditions do not necessarily include verification of the signature in all applications of the blockchain 150. More colloquially, a scripting language may be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

Side channel

As shown in FIG. 1, the client application on each of the computer devices 102a, 120b of Alice and Bob may include additional communication functionality. This additional functionality may enable alice 103a to establish a separate side channel 107 with bob 103b (under the initiative of either party or a third party). The side channel 107 enables exchange of data off the blockchain network. Such communications are sometimes referred to as "under-chain" communications. For example, this may be used to exchange transaction 152 between alice and bob without registering the transaction (not yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it on the network 106. Sharing transactions in this manner 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, the side channel 107 may be used to exchange any other transaction related data, such as keys, bargained amounts or terms, data content, etc.

The side channel 107 may be established through the same packet switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network, such as a mobile cellular network, or a local area network, such as a wireless local area network, or even via a direct wired or wireless link between alice and bob's devices 102a, 102 b. In general, the side channels 107 referred to anywhere herein may comprise any one or more links for "under-chain" exchange of data, i.e., exchange of data off of the blockchain network 106, via one or more networking technologies or communication mediums. Where multiple links are used, the bundle or set of links may be referred to as a side channel 107 as a whole. It should therefore be noted that if alice and bob are said to exchange some information or data etc. via the side channel 107, this does not necessarily mean that all of these data must be sent over exactly the same link or even the same type of network.

Conclusion(s)

Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art once the disclosure herein is given. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims. For example, some of the embodiments above have been described in terms of bitcoin network 106, bitcoin blockchain 150, and bitcoin node 104. However, it should be appreciated that a bitcoin blockchain is one specific example of a blockchain 150, and that the above description is generally applicable to any blockchain. That is, the present invention is in no way limited to a bitcoin blockchain. More generally, any of the references above to the bitcoin network 106, bitcoin blockchain 150, and bitcoin node 104 may be replaced with reference to the blockchain network 106, blockchain 150, and blockchain node 104, respectively. The blockchain, blockchain network, and/or blockchain nodes may share some or all of the characteristics of the bitcoin blockchain 150, bitcoin network 106, and bitcoin node 104 as described above.

In a preferred embodiment of the present disclosure, the blockchain network 106 is a bitcoin network, and the bitcoin node 104 performs at least some or all of the functions described for creating, publishing, propagating and storing the blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) performing only one or some, but not all of these functions. That is, network entities may perform the function of propagating and/or storing blocks without creating and publishing blocks (keeping in mind that these entities are not considered nodes of the preferred bitcoin network 106).

In other embodiments of the present disclosure, the blockchain network 106 may not be a bitcoin network. In these embodiments, it is not excluded that a node may perform at least one, but not all, of the functions of creating, publishing, propagating and storing the blocks 151 of the blockchain 150. For example, on these other blockchain networks, "node" may 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.

Even more colloquially, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element" wherein such entities/elements are configured to perform some or all of the roles of creating, publishing, propagating, and storing a chunk. The functionality of such network entities/elements may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

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

The above-described embodiments illustrate rather than limit the disclosure, and those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "including" or "consisting of. The use of the terms "comprises" or "comprising," such as "comprises" or "comprising," throughout this specification, will be understood to mean the inclusion of a stated element, integer, step, or group of elements, integers or steps, but not the exclusion of any other element, integer, or step, or group of elements, integers or steps. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims (29)

1. A computer-implemented method, the method comprising: Generate, store, process, access and/or maintain a record of at least a portion of a transaction (Tx), Wherein the record comprises transaction data, and the transaction data is used to determine that at least a portion of the transaction (Tx) is included in a Merkle path of a blockchain block (B). 2 . The method of claim 1 , wherein the record comprises a data directory, the data directory being or comprising a collection of the transaction data. 3. The method according to claim 1 or 2, wherein the records are processed and/or stored in the allocated resources (1104). 4. A method according to any preceding claim, wherein said at least part of said transaction (Tx) is an output of said transaction. 5. The method of claim 4, wherein the output of the transaction is an unspent transaction output (UTXO) and/or a transaction (Tx) comprising an unspent transaction output of a blockchain block. 6. A method according to any preceding claim, wherein the record is stored in a database, the record comprising: i) a blockchain transaction (TX0), the blockchain transaction (TX0) comprising at least one data item (D); and ii) at least one other blockchain transaction (TX1), said at least one other blockchain transaction (TX1) being necessary for confirming that said blockchain transaction (TX1) is included in said Merkle path of blockchain block (B). 7. A method according to any preceding claim, wherein using the database comprises generating, maintaining, providing, updating, storing, accessing or processing: i) the database; and/or ii) data, said data being stored in or associated with said database. 8. A method according to any of the preceding claims, wherein the record further comprises: a Merkle path, the Merkle path from the transaction (TX0) to the root of the Merkle tree of the blockchain block (B). 9. A method according to any of the preceding claims, wherein: the Merkle path includes at least: establishing or verifying the minimum blockchain transaction required for the blockchain transaction (TX0) to be included in the blockchain block (B). 10. A method according to any preceding claim, wherein the blockchain block is stored on or in association with: i) a blockchain ledger; and/or ii) Off-chain storage resources. 11. The method according to any one of claims 6 to 10, further comprising: using the blockchain transaction (TX0) and the at least one other blockchain transaction (TX1) to verify that the blockchain transaction (TX0) is included in the Merkle path of the blockchain block (B). 12. A method according to any one of claims 6 to 11, wherein the data item (D): stored in association with a script in the transaction; and/or Stored as metadata in the transaction. 13. A method according to any of the preceding claims, wherein the record further comprises: verification data required to verify the unspent transaction output (UTXO) and/or the transaction (Tx) containing the unspent transaction output. 14. The method according to any preceding claim, wherein the recording further comprises: The unspent transaction output (UTXO) and/or a history of multiple previous transactions of a transaction (Tx) containing the unspent transaction output. 15. The method according to any preceding claim, wherein the recording further comprises: The history of the resources allocated, their processing and/or storage The data of at least one previous transaction, preferably at least one transaction of the unspent transaction output and/or a transaction (Tx) containing an unspent transaction output. 16. The method of claim 14 or 15, wherein the history comprises at least one of: a set of transaction data, the set of transaction data being used to determine a Merkle proof of the previous transaction or multiple previous transactions; A link to a respective allocated resource that processes and/or stores the plurality of previous transactions. 17. The method according to any preceding claim, wherein the recording further comprises: A flag and/or status indication of the unspent transaction output and/or the input or each input of the transaction (Tx) containing the unspent transaction output. 18. The method according to any of the preceding claims, wherein the record further comprises at least one of the following: A Merkle tree of blocks recording said transaction (Tx); A Merkle root of the block recording the transaction (Tx); A Merkle path, wherein according to the hash of the transaction (Tx), the Merkle path is capable of determining a value of the Merkle root of the block recording the transaction (Tx); Merkel proved; a block identifier (block_ID), the block identifier being associated with the blockchain block; a transaction identifier (TxID), the transaction identifier being associated with a transaction (Tx) among a plurality of blockchain transactions within the blockchain block; A function of the block identifier (block_ID) and the transaction identifier (TxID); a concatenation of the block identifier (block_ID) and the transaction identifier (TxID); digital signature; Authentication code; A signed message, wherein the signed message is used to determine the transaction status; Protocol logo; Autonomous Public Key (DPK); Autonomous Transaction ID (DTxID). 19. A method according to any one of claims 3 to 18, wherein partial data derived from a blockchain for identifying and/or allocating resources is used to identify and/or allocate the allocated resources for processing and/or storing the record, wherein the data from which the partial data is derived includes the unspent transaction output (UTXO) and/or the transaction (Tx) containing the unspent transaction output. 20. A computer-implemented method, the method comprising: Using a database, the database comprising at least one record, the at least one record comprising: i) a blockchain transaction (TX0), the blockchain transaction (TX0) comprising at least one data item (D); and ii) at least one other blockchain transaction (TX1), said at least one other blockchain transaction (TX1) being necessary for confirming that said blockchain transaction (TX1) is included in said Merkle path of blockchain block (B). 21. The method of claim 20, wherein using the database comprises generating, maintaining, providing, updating, storing, accessing or processing: i) the database; and/or ii) data, said data being stored in or associated with said database. 22. A method according to claim 20 or 21, wherein the record further comprises: a Merkle path, the Merkle path from the transaction (TX0) to the root of the Merkle tree of the blockchain block (B). 23. A method according to claim 22, wherein the Merkle path includes at least: establishing or verifying the minimum blockchain transaction required for the blockchain transaction (TX0) to be included in the blockchain block (B). 24. A method according to any one of claims 20 to 23, wherein the block is stored on or associated with: a blockchain ledger; and/or an off-chain storage resource. 25. The method according to any one of claims 20 to 24, further comprising: The blockchain transaction (TX0) and the at least one other blockchain transaction (TX1) are used to verify that the blockchain transaction (TX0) is included in the Merkle path of the blockchain block (B). 26. A method according to any one of claims 20 to 25, wherein the data item (D) is: stored in association with a script in the transaction; and/or stored as metadata in the transaction. 27. The method of any one of claims 20 to 26, wherein the transaction further comprises: a transaction ID (TxID); a protocol flag; a autonomous public key (DPK); and an autonomous transaction ID (DTxID). 28. A computer device, comprising: a memory, the memory comprising one or more memory cells; and A processing device, the processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, and the code is configured to execute the method according to any one of claims 1 to 27 when executed on the processing device. 29. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method of any one of claims 1 to 27.