Method and system for distributed blockchain functionality

Abstract

The present disclosure provides methods and systems for distributed and / or parallel processing of data records, and in particular for validation of blockchain transactions in blockchain blocks. In a preferred embodiment, a distributed validation node is disclosed in which one or more transactions are assigned to one validation resource of a plurality of validation resources. The one or more transactions relate to a portion of the block's Merkle tree, such that each validation resource can operate independently in validating a subset of the block's transactions, each subset being based on a segment of the Merkle tree. The present disclosure includes at least advantageous techniques for the assignment of tree segments to different validation resources, load balancing, downloading of transactions to be validated, a distributed UTXO pool, an indexing scheme, and prevention of double-spend events.

Description

[Technical field]

[0001] The present disclosure generally relates to improved methods and systems for processing related or associated data records. The present disclosure is particularly suited for use with, but not limited to, pre- and / or post-mining validation of blockchain transactions, SPV checks, and other transfers accomplished through or using a blockchain network. Advantages include, but are not limited to, improved security and resilience, improved efficiency or reduced speed and resource requirements, and novel approaches to validation not possible with prior art configurations, resulting in previously impossible blockchain implementation configurations. [Background technology]

[0002] Although the Bitcoin protocol and network may be referenced herein for purposes of providing an example context for implementation, the present disclosure is not limited to use with the Bitcoin blockchain, and alternative protocols and implementations (including those involving account-based and proof-of-stake consensus) are within its scope. Hereinafter, the term "UTXO" may be used merely for convenience to refer to transaction outputs, and should not be interpreted as meaning that embodiments of the present disclosure are limited to use with UTXO-based blockchain models.

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

[0004] In order for a transaction (Tx) to be written to the blockchain, it must be "validated." Network nodes (miners) perform the work of ensuring that each transaction is valid, and invalid transactions are rejected from the network. In some protocols, a software client installed on the node performs this validation work on the unspent transaction (UTXO) by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, i.e., propagated; ii) added to a new block constructed by miners; and iii) mined, i.e., added to the public ledger of past transactions. Once a transaction is stored in the blockchain as a UTXO, the user can transfer control of the associated cryptocurrency to another address associated with an input in another transaction that is later written to the blockchain. This is often done using a digital wallet that stores a public / private key pair associated with a user's cryptocurrency. There are various forms of known cryptocurrency wallets, including Simplified Payment Verification (SPV) wallets. SPV techniques allow users and merchant nodes to perform local verification based on only partial information related to a particular transfer. SPV is described in more detail below.

[0005] However, while it is known that validation is essential to ensure security, conformance with relevant protocols for a given blockchain, and protection against double-spend exploits, it has been recognized that such validation tasks can require significant resources and time due to the need to download and store blocks, maintain large UTXO pools, and perform the processing tasks required for validation. Many users are either unable to meet such requirements, or in some cases do not need to and would prefer not to meet them. Thus, there is a need for a faster and more efficient validation model that addresses at least these challenges (and others) without compromising security or requiring adaptation of existing protocols. Such an improved solution has been devised. Summary of the Invention

[0006] Embodiments of the present disclosure provide improved blockchain-related methods, devices, and systems. According to one form of expression, such embodiments provide solutions for validating part or all of blockchain transactions and / or blockchain blocks. According to additional or alternative forms of expression, they provide secure solutions for controlling, managing, and / or enhancing the efficiency, resource requirements, speed, and / or resilience of known approaches to processing blockchain transactions. Embodiments also enable scalability of blockchain-implemented solutions and provide improved methods and technical architectures for electronic transfer of digital resources.

[0007] The embodiments of the present disclosure may be implemented in part or in whole by a variety of devices. These may be hardware and / or software-based devices, including (but not limited to) one or more virtual machines, servers, GPU-based computing resources, or multi-processor systems. Additionally or alternatively, the embodiments may include one or more digital wallets. Importantly, however, the embodiments provide a mechanism for distributed processing of blockchain-related validation tasks. Coordination, management, and control of distributed processes are known to be inherently technical in nature, as they require a holistic understanding of the interactions between the hardware and software components involved, and the implementation of such distributed solutions extends beyond the technically trivial.

[0008] Embodiments may include solutions that enable or facilitate the distribution of validation tasks across multiple processing resources, which for convenience we will refer to as “validators.” A validator may include a single processing resource, or may include multiple related processing resources that can be collectively considered as a validation resource.

[0009] In one example, when a block of transactions needs to be validated and / or downloaded, its Merkle tree may be decomposed into one or more smaller segments, each segment having its own root and containing a tree structure that represents a subset of the transactions in the block. These segments can then be assigned to different validators. Each validator operates to perform the necessary processing tasks on the subset of transactions assigned to it.

[0010] The assignment of tree segments to validators can be performed in a variety of ways, but according to one advantageous embodiment, a binary indexing system may be used that uses the leading digit of a randomly generated, double-hashed Merkle root to assign a given segment to a validator (or group / cluster of validators) with a matching binary identifier, providing a simple, efficient and fast mechanism for load balancing across multiple validators.

[0011] Each tree segment may contain a small binary marker that allows reconstruction of the entire Merkle tree of transactions after a validator has finished its operations. The segment markers allow the controller component to reconstruct the segments into their original form, with the marker indicating their location in the original tree. This provides the advantage that multiple tree segments can be distributed across many different validators, potentially anywhere across the globe, yet they can be quickly and easily reconstructed to provide a complete Merkle tree of blocks.

[0012] In one or more embodiments, a validator may include or have access to a repository that records data regarding the work it has performed and / or the data it has processed. In one embodiment, this may include a database that contains unspent transaction outputs (UTXOs) that have been assigned to a given validator for processing. Recall that in a traditional model, all UTXOs on a blockchain are tracked by nodes in a database called a UTXO pool. Each full node has its own full copy of the UTXO pool for the blockchain. However, in accordance with the present disclosure, a different approach may be utilized in which each validator has its own UTXO pool that tracks the UTXOs of transactions that have been assigned to it for validation. Advantages of such a decentralized UTXO pool include, but are not limited to, guaranteed data integrity, increased speed and efficiency, and the incorporation and support of various validation techniques such as SPV. [Brief description of the drawings]

[0013] To aid in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] 1 provides an illustration of a typical Merkle tree structure known in the art. [Figure 4] We show how a Merkle root can be derived from a set of blockchain transactions, as known in the art. [Diagram 5] We provide an example of how a Merkle tree can be divided into subsets (or "segments"), which can then be assigned to respective validation resources, according to one embodiment of the present disclosure. [Figure 6] FIG. 5 shows an alternative example of how a Merkle tree may be divided into logical segments. [Figure 7] 1 illustrates a system level view of a distributed validation node according to an exemplary embodiment of the present disclosure. [Figure 8] 1 is a flow chart outlining the steps involved in an exemplary method of the present disclosure. [Figure 9] FIG. 8 illustrates the example system of FIG. 7 in greater detail. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Exemplary embodiments of the present disclosure will now be described, by way of example and not limitation, with reference to the accompanying drawings.

[0015] Traditionally, nodes in a blockchain network maintain a global ledger of all transactions on the blockchain. The global ledger is a distributed ledger, and each node may store a full or partial copy of the global ledger. Transactions by nodes that affect the global ledger are verified by other nodes to ensure that the validity and integrity of the global ledger is maintained. The details of implementing and operating a blockchain network, such as one that uses the Bitcoin protocol, will be understood by those skilled in the art.

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

[0017] Using the Bitcoin network and protocol as an example, as described above, mining nodes compete to create the next block in the blockchain. To assemble a block, a miner constructs the block as a set of transactions from a pool of unconfirmed transactions ("mempool"). The miner then attempts to complete a Proof-of-Work (PoW) puzzle on the block it assembled. If a miner manages to complete a PoW before receiving notification that other miners have successfully generated their block and completed their PoW, it propagates by sending its block to peer nodes on the network. Those nodes validate the block and then send it further in the network to other nodes. If a miner receives notification that another block has been completed before it has finished its PoW, it abandons its efforts and begins attempting to construct the next block.

[0018] Thus, fast propagation of blocks helps to avoid wasted effort (and associated energy) on behalf of miners and validation nodes. By providing a solution that allows faster validation and therefore propagation of blocks, the present invention provides an enhancement of network performance. This reduces the amount of computation time and effort required, and also reduces the amount of energy required by the network. A more efficient network in terms of resources and time is provided. Finally, an improved (blockchain) network is provided.

[0019] In current implementations of blockchains, such as the Bitcoin network, each node that receives a block first validates the block before sending it to other nodes. If it takes a long time to validate a block, it will propagate the block through the network slower. Note that while some implementations of blockchains, including evolutions of existing protocols, may provide block validation by only a subset of nodes rather than every node in the network, block validation at most nodes is still likely to be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0020] Validating a block includes verifying that the block meets predefined criteria set by the applicable blockchain protocol. Exemplary criteria applicable to the Bitcoin protocol may include functions such as CheckBlock and CheckBlockHeader. In addition to verifying that the block itself meets predefined criteria, each transaction within the block may be evaluated for conformance with transaction-level criteria. As an example, transaction-level criteria applied in the Bitcoin protocol may include the functions AcceptToMemoryPool, CheckTransaction, and CheckInputs.

[0021] Examples of block-level standards based on the Bitcoin protocol could include: Block data structures are syntactically valid. The hash of the block header is less than the target difficulty (to enforce the proof of work). The block timestamp is less than 2 hours in the future (allowing for time skew). Block sizes are within acceptable limits. The first transaction (and only the first transaction) is a coinbase generating transaction. All transactions in a block are valid.

[0022] Examples of transaction level standards based on the Bitcoin protocol could include: · The transaction syntax and data structures must be correct. Neither the input list nor the output list may be empty. Each output value x and the sum of all outputs is 0 <x<21·10 6 must be within the range. No input has 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 and less than the maximum. The number of signing actions is less than the signing action limit. · The unlock script scriptSig can only push numbers onto the stack, and the lock script scriptPubkey must match the isStandard format. 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 a coinbase output, then at least COINBASE_MATURITY(100) confirmations are required. For each input, the referenced output must exist and not be in use. Use the referenced output transaction to get the input values, and ensure that each input value and the sum are within the tolerance range of value x, i.e. 0 <x<21·10 6 Check that it's inside. · There must be a matching transaction in the pool or in a block on the main branch. The sum of the input values ​​must be greater than or equal to the sum of the output values. The transaction fee must be sufficient to gain entry to a free block. · The unlock script for each input must be validated against the corresponding output lock script.

[0023] These exemplary criteria are exemplary and should not be construed as sufficient or necessary for all embodiments, as the predetermined criteria may vary by protocol and may change over time for a given protocol as changes are made to the protocol. In general, transaction-level validation criteria are predetermined characteristics that a transaction must have in order to be considered valid under the applicable blockchain protocol. Similarly, block-level validation criteria are predetermined characteristics that a block must have in order to be considered valid under the applicable blockchain protocol.

[0024] In accordance with the present application, methods and devices are described that speed up block validation to facilitate faster propagation of blocks in the network. Faster and more efficient validation and propagation helps address the technical challenge of how to scale blockchain networks, thus providing improved applications and systems built on such blockchain platforms.

[0025] In one aspect, the present application describes a node structured to validate a block by performing at least transaction-level validation of individual transactions in a parallel and / or distributed manner. However, certain transaction-level criteria may not be evaluated in parallel. For example, the uniqueness of a UTXO may be evaluated on a serial basis. In such cases, a distributed validation node of the present disclosure may be structured or configured to verify the uniqueness of a transaction's referenced input (UTXO) before allocating the set of transactions among a set of two or more parallel processors for validation of the remaining transaction-level criteria.

[0026] In particular, embodiments of the present disclosure provide improved validation and security solutions for processing related or associated data records stored in a tree structure. The tree can be a binary tree or a mesh structure. As is known in the art, the tree structure can be decomposed into smaller trees (sometimes referred to herein as tree "segments," "subsets," or "parts"), each segment containing a subset of the data records in the overall tree and having its own root. Advantageously, embodiments of the present disclosure take advantage of this feature to provide a method and system for distribution and parallelization of processing of related data records across multiple processing resources.

[0027] In an exemplary embodiment of the present application, a plurality of data records comprise related blockchain transactions as they form nodes in a Merkle tree. A Merkle tree has a root that is or can be included in the header of a block of transactions according to a blockchain protocol, such that the root provides a path that can be traced to all leaves (i.e., transaction IDs (TxIDs)) in the tree. In the present example, the blockchain protocol is or is derived from the Bitcoin protocol, although other protocols are within the scope of the present disclosure.

[0028] In an example of the present invention, processing the plurality of transactions includes validating at least a portion of a blockchain block that includes the plurality of blockchain transactions and the root of a Merkle tree for the block. These examples are non-limiting, and the techniques disclosed herein may be utilized with respect to non-blockchain related data and / or with respect to other processes other than validation. For example, embodiments may be used to store, structure, search, and / or maintain any type of data record that can be represented by a Merkle tree. Databases and other known storage resources may be utilized instead of or in addition to a blockchain ledger.

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

[0030] For completeness, a discussion of Merkle trees and their use in representing blocks of blockchain transactions is provided with reference to Figures 3 and 4.

[0031] Merkle Tree Referring to Figure 3, a Merkle tree is a hierarchical data structure that allows for secure verification of a collection of data. In a Merkle tree, each node in the tree is given an index pair (i,j), denoted as N(i,j), where the indices i,j are simply numerical labels associated with a particular position in the tree.

[0032] A characteristic of a Merkle tree is that the composition of each of its nodes is governed by the following formula:

number

[0033] An example of a binary Merkle tree constructed according to these formulas is shown in Figure 3. As shown, for i=j, we simply denote the corresponding i-th data packet D i If i ≠ j, then it corresponds to an internal or parent node generated by hashing recursively until a single parent (the Merkle root) is found, and concatenating the child nodes.

[0034] For example, node N(0,3) is constructed from four data packets D0,...,D3 as follows:

number

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

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

[0037] The main function of a Merkle tree is to find a data packet D i Let D be a set of N data packets D∈{D0,...,D N-1 The goal of verification is to verify that a packet of data D is a member of a list or set of . i and obtaining a set of hashes, known as the Merkle path, for the Merkle root R. A Merkle proof for a data packet is simply the minimal list of hashes needed to reconstruct the root R by repeated hashing and concatenation, and is often called an "authentication proof."

[0038] A proof of existence is the proof of existence for all packets D0,...,D N-1 and their order are known to the prover, this can be done trivially. However, this requires a much larger storage overhead than Merkle proofs, and requires the entire data set to be available to the prover.

[0039] A comparison of using Merkle proofs and using the entire list is shown in the table below, where we use binary Merkle trees and assume that the number of data blocks, N, is exactly equal to an integer power of 2.

[0040] The table below shows the relationship between the number of leaf nodes in a Merkle tree and the number of hashes required for a Merkle proof (or a Merkle proof). [Table 1]

[0041] In this simplified scenario, where the number of data packets is equal to the number of leaf nodes, we can see that the number of hash values ​​required to compute a Merkle proof scales logarithmically. It is clear that it is much more efficient and practical to compute a Merkle proof that contains log2N hashes than it is to store N data hashes and compute an explicit proof.

[0042] Given a Merkle root R, let D∈{D0,...,D N-1}, you can perform a Merkle proof as follows: i. Obtain the Merkle root R from a trusted source. ii. Obtain a Merkle proof Γ from a source, where Γ is a set of hashes: Γ={N(1,1),N(2,3),N(4,7)}. iii. Compute the Merkle proof using D1 and Γ as follows: a. Hash the data block to get: N(0,0)=H(D0). Concatenating with bN(1,1) and hashing, we get: N(0,1)=H(N(0,0)||N(1,1)). Concatenating with cN(2,3) and hashing, we get: N(0,3)=H(N(0,1)||N(2,3)). Concatenate this with dN(4,7) and hash it to get the root: N(0,7)=H(N(0,3)||N(4,7)), R´=N(0,7). e. Compare the calculated root R' with the root R obtained in (i): 1. If R′=R, then the presence of D0 in the tree and therefore the data set D is confirmed. 2. If R' ≠ R, the proof fails and D 0が D membership is not verified.

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

[0044] SPV Simple Payment Verification (SPV), first described in section 8 of Satoshi Nakamoto's 2008 whitepaper "Bitcoin: A Peer-to-Peer Electronic Cash System", exploits these properties of Merkle trees. In an SPV-based cryptocurrency exchange between Alice and Bob, both parties use the same type of SPV wallet. The SPV wallet stores the user's private and public keys, unspent transactions, and a block header that uniquely identifies the block so that it can be located on the blockchain. As explained, the block header contains a field of data that provides a unique summary or fingerprint of the entire block's contents, and a field that provides the Merkle root of that block. The Merkle root is generated by repeatedly hashing pairs of transaction IDs (TxIDs) from the block together until a single hash is eventually arrived at. The Merkle root provides an efficient and secure mechanism for verifying that a transaction is part of a block, as it allows users such as wallets and merchant nodes to verify a particular transaction locally without having to download the entire blockchain. This is advantageous for users who do not need or want to run a full node, but simply need to perform a local check that a particular transaction is in a particular block, e.g., parties such as merchants and customers who want to perform transfers between each other. In summary, SPV allows such users to search a Merkle tree with a given root to check (i.e., verify) whether a particular transaction is included in a particular blockchain block, without having to download and store the entire blockchain.

[0045] Thus, SPV wallets provide at least the advantage that power and storage constrained devices, such as phones and laptops, can operate within the Bitcoin ecosystem because they only need to verify that a transaction has been verified (hence the name "simple payment verification"), rather than performing a full check of the blockchain as other forms of wallets do. SPV wallets download only the block headers without including any of the transactions, greatly reducing the storage space, energy, and processing resources required for verification. SPV wallets are particularly well suited for use in embodiments of the present disclosure for reasons explained below, and the term "verification" is used herein to include SPV checks.

[0046] Blocking Transactions FIG. 4 illustrates an example of a blockchain block. Each block includes a block header and a set of transactions. The block header includes, among other things, a hash of the previous block header, i.e., the hash of the block header of the block from which the current block was built. The block header also includes the Merkle root of a Merkle tree built using the set of transactions. Each transaction is first hashed (e.g., double hashed) to generate a transaction identifier (TxID) for that transaction. The transaction identifier is then used as a leaf node of the Merkle tree. Pairs of transaction identifiers are then concatenated and hashed to form respective internal nodes of a first internal level of the Merkle tree. Pairs of internal nodes of the first internal level are then concatenated and hashed to form respective internal nodes of a second internal level of the Merkle tree. The process of concatenating and hashing pairs of internal nodes is repeated until only a single hash remains, i.e., the Merkle root. This Merkle root is sometimes referred to as the block Merkle root.

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

[0048] Identifying the segments of a block’s Merkle tree Suppose a particular party, say Alice, wishes to validate some transactions. According to one embodiment of the present disclosure, at least one subset of transactions is identified, the subset forming a segment of the entire Merkle tree of blocks and / or represented by a segment of the entire Merkle tree of blocks. Thus, the block of transactions can be logically segmented into multiple segments based on the Merkle tree of blocks, with each segment containing a subset of the block's transactions, and each segment having its own root node (or "root hash"). This common root hash may be referred to as the "segment hash" below to distinguish it from the root hash of the entire block. Transactions on the same level in a tree segment (i.e., the lowest level, sometimes referred to as the "leaf level" or "leaf tier") are 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 Merkle tree, i.e., the level immediately above the lowest level. Alternatively, the common root node may belong to a higher level. In general, the common root node may belong to any level of the Merkle tree between the lowest level and the Merkle root.

[0049] Splitting a block into smaller parts based on a Merkle tree offers significant technical advantages, including the ability to quickly and efficiently allocate transactions across multiple validators. For example, because the Bitcoin protocol uses a binary tree, it is possible to implement binary allocation across multiple machines. By using small binary markers as an indexing system for segments, the position of each segment in the overall Merkle tree can be quickly calculated, and the segments can be returned to their original state after validation is complete, reconstructing the full Merkle tree for the block. This binary indexing approach is described in more detail below.

[0050] Although various techniques can be used to identify the segments, according to one approach, the number of segments may be determined by the number of available validators in the system. For example, in a system with four validators, the Merkle tree may be divided into four segments, if there are eight validators, the Merkle tree may be divided into eight segments, and so on. The identification of the segments of a given Merkle tree may be performed or influenced by a control entity, represented by controller 702 in FIG. 7.

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

[0052] FIG. 6 shows another example of how a Merkle tree can be split into parts 602. The Merkle tree of FIG. 6 is the same as the Merkle tree of FIG. 5. However, in this example, the Merkle tree is split into eight parts 602a-h, each part 602 representing four transactions. In this example, the common internal node 604 belongs to the third level of the Merkle tree. The Merkle trees of FIG. 5 and FIG. 6 may alternatively be split into more (e.g., 16) or fewer (e.g., two) parts 502, 602. In general, a Merkle tree formed from a set of transactions of a block may be split into any number of parts 502, 602, each part containing a minimum of two transactions.

[0053] Assigning segments to each validation resource Following their identification, a subset of transactions are distributed across multiple validation resources, sometimes also referred to as "validators" for ease of reference. In Figures 7 and 9, the multiple validators are shown as Resources A-D (704a-704d). The allocation process may be directed or influenced by a dedicated unit, such as, but not limited to, component 904 as shown in Figure 9.

[0054] Each validator (704a-704d) can include one or more processing resources. Thus, at least one of the validators in the plurality of validators (704a-704d) can 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 multi-processor systems, etc. In essence, any of the plurality of validators can be comprised of any type(s) or combination of processing resources, each capable of validating one or more transactions related to each other by a segment of a Merkle tree of blocks. The plurality of validators (704a-704d) and other system components form a collective resource or entity 700, which we refer to as a "(distributed) validation node."

[0055] Preferably, the distribution includes allocating each of the segments to a respective validator in the plurality of validators. The validators may be configured to do at least the following: · Operate on one or more transactions that make up the assigned segment(s); Validating one or more transactions to verify that they comply with the blockchain protocol; and / or Validate that they are identifiable within an existing repository, such as a blockchain ledger or a database of known, registered or used transactions.

[0056] The activity of the validators and the allocation of subsets to different validators may be directed by a controller. Figure 7 shows the controller 702 assigning subsets of transactions A-D for each tree segment to validators 704a-d, respectively. The system-level controller 702 coordinates the activity of the systems or devices 704a-d in the distributed validation node and may control or influence tasks such as identifying tree segments according to the Merkle tree of blocks, assigning the identified segments to respective validators, reordering the validated tree segments into the complete Merkle tree of blocks, and / or ordering of transactions in the reconstructed blocks.

[0057] One or more of the validators may include at least one coordinating entity configured to act as a controller at the validator level. Thus, any or all of the validators 704a-704d may include at least one controller component of their own. This lower-level controller may influence or direct operations such as the allocation of tasks or subtasks to one or more processing resources within the validator, the reconstruction of the Merkle tree for a given segment, or interaction with other system components, e.g., other validators or higher-level controllers, UTXO pools, wallets, etc. The processing resources themselves may then be further decomposed into smaller systems, one or more of which may include a controller and one or more processing resources of their own. In this way, the system may include a hierarchical architecture in which segment validation is performed by a validation entity that includes one or more processing resources for performing validation tasks and one or more controllers for coordination of execution of processor activities and inter-component communication.

[0058] In embodiments where the validator includes multiple processing resources, the validator may divide its assigned segment into smaller segments. The validator's controller can then distribute the sub-segments across the processors under its control. In this manner, the validation process can be performed in a hierarchical and distributed manner.

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

[0060] Thus, the present disclosure allows many transactions to be processed simultaneously, with the only limitation being the amount of hardware available to form the distributed validation nodes, rather than the bottleneck being the amount of processing speed available as in conventional techniques. This allows blockchain processing systems to scale horizontally without the need to change the underlying protocol of the blockchain network.

[0061] Thus, the present disclosure represents a significant departure from conventional approaches to validation, which are described in more detail below in the section entitled "Exemplary Technical Environment for Implementing Exemplary Embodiments of the Present Disclosure" with reference to Figures 1 and 2. As explained, conventional approaches include a block being validated as an entire entity and the conventional view of a validation node (see 104 in Figure 1) as a single computing unit. In contrast, embodiments of the present disclosure divide the Merkle tree into multiple segments that are fed to different validators (704a-704d in Figures 7 and 9), each of which can be further decomposed to increase the degree of distribution involved.

[0062] Furthermore, by splitting each block into segments based on its Merkle tree, embodiments of the present disclosure allow validators to access, download, and process smaller portions of a block rather than the entire block. Recall that transactions in each segment hash up (in pairs) to a single root value. This means that segments can be validated using only the relevant transactions required, rather than the entire block being downloaded, stored, and processed in its entirety. As protocols such as Bitcoin SV allow for scaling block sizes and for larger blocks to be included in the ledger, the traditional model of downloading the entire block becomes a bottleneck. Embodiments of the present disclosure overcome this challenge to blockchain scalability by allowing individual validators to receive and process only the (smaller) portions relevant to them. This results in faster overall validation times, improved blockchain networks, and improved applications running on the blockchain.

[0063] Additionally, embodiments support and facilitate the use of SPV processes and resources because such SPV involves local validation of only the portion of the Merkle tree that is of interest to a given party. Thus, the tree-pruning nature of SPV techniques is ideally suited for use with embodiments of the present disclosure. In the context of SPV, validators may be provided with only the portion of the block data they need, i.e., the block header or segment root node and associated transactions.

[0064] If each validator performs its checks and confirms the validity of the segments it has processed, the hashing mechanism used to generate the tree can ensure that the block is valid.

[0065] Load Balancing Across Multiple Validators Load balancing techniques and systems are known in the art that are designed to distribute tasks evenly across multiple resources to improve efficiency. The objective is to minimize the risk of some processing resources being overloaded while others are idle, and thus the risk of performance degradation and even failure. Load balancing is therefore important in ensuring the resilience of the overall system as well as its performance and efficiency. The embodiments of the present disclosure may utilize any known load balancing technique, such as, for example, static or dynamic load balancing. Additionally or alternatively, the load balancing techniques disclosed herein may be advantageously used.

[0066] When a tree segment needs to be assigned to a validator, the first four digits of that double hash (i.e., the segment hash of the tree segment) can be used to determine which validator will process that segment. Recall that the Merkle root is generated by hashing together pairs of transaction IDs (TxIDs) from blocks to generate each interior node (or inner hash) of the Merkle tree, and then repeatedly hashing adjacent inner hashes until a single hash is finally reached. This double-hashed Merkle root provides an efficient, fast, and secure validation mechanism. It also provides the advantage, in the present context, that the double hash generates random binary numbers. Each inner hash, including each segment hash, is itself a double hash.

[0067] When a tree segment needs to be assigned to a validator, the first four digits of the double hash (i.e., the segment hash of the tree segment) can be used to determine which validator will process the segment. Recall that the Merkle root is generated by hashing together pairs of transaction IDs (TxIDs) from blocks to generate each internal node (or internal hash) of the Merkle tree, and then repeatedly hashing adjacent internal hashes until a single hash is finally reached. This double-hashed Merkle root provides an efficient, fast, and secure validation mechanism. It also provides the advantage, in this context, that the double hash generates random binary numbers. Each internal hash, including each segment hash, is itself a double hash. Thus, the first x leading digits of the segment hash can be taken as the assignment index. A hash with four leading zeros would result in the assignment of the tree segment to the validator with ID 0000, a hash with leading digits 0001 would result in the assignment to the validator with ID 0001, and so on. The random generation of the double hash ensures a random distribution of tree segments to validators.

[0068] Although a double hash is typically used in generating a Merkle tree, this is not required in all instances and instead, only a single hash may be used. In fact, any number of hash operations will result in a random binary number. Load balancing tasks may be performed by a dedicated system component shown as 905 in Figure 9, or may be provided elsewhere in system 700 or in association with and communication with system 700.

[0069] Distributed reception / download of blocks According to some embodiments, the allocation of segments of a block Merkle tree to different validators can be used to provide a faster and more efficient process for downloading or otherwise receiving some or all of a block of a transaction.

[0070] In some embodiments, the validator(s) may receive the data in the form of one or more data packets sent to a multicast address to which the validator subscribes. This may be an IPv6 multicast address known in the art. One, some, or all of the validators may subscribe to the multicast address. In some embodiments, subsets of the validators may subscribe to different respective multicast addresses so that transactions for different segments can be assigned to groups of validators that share a common multicast address.

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

[0072] A distributed node may require a complete block, i.e., the entire set of transactions that form the block, in which case each validator that has been assigned a tree segment receives, e.g., downloads, a subset of the transactions that form that segment. In other scenarios, a distributed node may require only a certain portion of a block, in which case only a portion of the validators may need to download their respective subsets of transactions to obtain the desired transactions.

[0073] Downloading a block (or a portion of a block) in this manner results in a faster overall download, since each validator processes only a subset of the transactions of the entire set of transactions that form the block. This is in contrast to a traditional block download, where a given entity (e.g., a full node) must receive or download the entire block, e.g., by downloading each transaction in the order in which it appears in the block. Here, a block is downloaded in parallel by multiple validators. A block may contain tens of thousands of transactions, if not more than a few orders of magnitude more. A single entity downloading this number of transactions would consume significant resources and take a significant amount of time. The computational load is distributed among the validators, such that each individual validator consumes a portion of the processing resources. Similarly, the overall time to download a block is reduced.

[0074] As described above, each validator may download a subset of the transactions. The subsets may then be combined to reconstruct a block in a single storage location. (By "single storage location" we mean either a storage resource that is a self-contained entity, or multiple related storage resources that form a collective entity). To do so, the individual validators may send their respective subsets to a central controller of distributed nodes configured to place the transactions in the correct order. Segment hashes (i.e., hashes that link tree segments) may be utilized for this purpose. For example, a mapping of segment hashes to their positions in the Merkle tree may be maintained, e.g., from left to right as the segment hashes appear in the Merkle tree. The subsets of transactions may then be placed in order (e.g., from first to last) based on their corresponding segment hashes.

[0075] In some embodiments, individual validators (or the distributed nodes as a whole) may verify that the correct transactions have been downloaded (or that the transactions have been downloaded correctly) by reconstructing the Merkle tree. After downloading a subset of transactions, the validators may generate candidate segment hashes based on these transactions. The candidate segment hashes are constructed by hashing pairs of TxIDs to generate their respective internal hashes, and repeatedly hashing the pairs of internal hashes until a candidate segment hash is generated. The level of the Merkle tree to which the candidate segment hash belongs depends on the number of tree segments the Merkle tree is divided into. The validators may verify that the candidate segment hash is a hash of the Merkle tree. If the hashes do not match, an error occurred during download. In some examples, each validator may generate a candidate segment hash and send it to the controller to perform validation. As another example, a candidate block Merkle root may be generated based on the entire set of downloaded transactions. Again, the candidate Merkle root should match the actual block's Merkle root (i.e., the Merkle root stored in the block) if the block was downloaded correctly.

[0076] In some cases, validators may validate the downloaded transactions using the techniques described above; that is, each validator is assigned a tree segment, downloads a corresponding subset of transactions, and validates those transactions. In other cases, validators may not necessarily validate the transactions, but simply download them for later use, e.g., sending to a third party.

[0077] Decentralized UTXO Pool Preferably, each validator 704 forming part of the distributed validation node has its own repository (pool) for generating, storing and / or maintaining unspent transaction outputs (UTXOs). It serves as a UTXO pool providing a record of unspent, i.e. unspent outputs associated with blockchain transactions. Thus, each validator's UTXO pool is built based on and from transactions that are assigned to it by the controller in terms of Merkle tree segments. In one embodiment, this may be a (graph) database containing data on unspent UTXOs of transactions assigned to a given validator for processing. A record in the database is created for each UTXO that the validator becomes aware of when a new Merkle tree segment is assigned to it. Thus, from the perspective of the distributed validation node, the UTXO pool is not a single pool but rather consists of several different UTXO pools, each UTXO pool provided to or on a different validator and containing a different set of UTXOs. Thus, the UTXO pool for a node is distributed both in terms of data and the resources to store and / or process it.

[0078] This is a significant departure from the traditional UTXO model, where each full node in the network has a copy of a UTXO pool that tracks all UTXOs on the blockchain. In contrast, the present disclosure distributes UTXO pools across multiple validating resources, each of which has a UTXO pool that is a subset of the blockchain's entire UTXO set. Each validator's UTXO pool contains the UTXOs of transactions that make up a subportion of the Merkle tree that it is tasked with validating.

[0079] Such an approach can be implemented in a manner similar to SQL transaction logs in that all commands, events, and items related to the database are logged each time a new block needs to be validated. The term "database log" is used herein to avoid confusion arising from the use of the term "transaction" as known in the context of blockchain, but the term "database log" is used to include terms such as "transaction journal", "transaction log", etc. In essence, 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 with respect to the state of the database, as known in the field of computer-based databases (see https: / / en.wikipedia.org / wiki / Transaction_log).

[0080] The use of an ordered history database log means that the entire UTXO pool can be constructed by running the log's history in its original order. Advantageously, this ensures that a copy of the database can always be (re)generated when needed, and no separate copies of the data need to be stored. Data integrity is ensured and fewer storage resources are required. Each UTXO pool can be stored, maintained and processed separately. Advantageously, the SPV technique also facilitates the creation of a separate UTXO database for each validator, assuming that the SPV technique operates on a pruned portion of the Merkle tree.

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

[0082] Structuring transactions in this way provides a fast and efficient lookup mechanism. Transactions can be sorted by block_ID such that all transactions with the same block_ID are located together in the database. Thus, when a validator needs a transaction (e.g., to check if the transaction's UTXO has been spent), the validator can locate the transaction in the database by first looking up the corresponding block_ID and then the corresponding TxID. This has the effect that the search is limited to the relevant section of the database. This efficiency reduces the time, processing resources and energy required for the search operation, providing a significant improvement over the prior art.

[0083] A flag or marker is associated with each UTXO in a validator's pool to indicate whether the UTXO is locked or unlocked. For convenience, we sometimes refer to this flag or marker as the "lock flag." When a UTXO is marked as "locked," it serves as an indicator to validators in the group (i.e., elsewhere in the decentralized validation nodes) that this UTXO is not available for spending. Conversely, when a UTXO is marked as "unlocked," it serves as an indicator to validators that the UTXO is available for spending. It thus serves as a way for a validator assigned to verify a transaction that uses a UTXO to signal to its peers that it has been redeemed and is therefore no longer available for spending, assuming that the transaction proves valid. The "locked" state means that spending is permitted, and the "unlocked" state means that spending is prohibited.

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

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

[0086] Once a validator sees that a UTXO has been spent by a newly allocated transaction, it sends a message to all other validators in the pool informing them that this UTXO should also be locked in their respective pools. Essentially, the validator sends a communication to its peers indicating that it has seen a spend involving a transaction with a particular hash ID at a particular time. Other validators do not need to receive the full data for the entire transaction, since the transaction hash and the list of UTXOs it uses are enough to identify the transaction and mark it as locked in its own database. Upon receiving the message, each receiving validator checks if the UTXO is in their UTXO pool. If so, the state of the lock flag is changed to "locked". Thus, the lock prevents the validator from allowing the same UTXO to be spent in a subsequent transaction. If a new transaction attempts to spend the same UTXO, the lock flag check indicates that the second spend attempt should be ignored. If the validator that sent the message determines that the validation has failed and therefore the UTXO has not been spent, a further message to this effect may be sent to the validator peers indicating that the UTXO's lock flag should be changed to an "unlocked" state. Once valid usage has been completed, a message to this effect can be sent and the locked UTXO can be removed from the associated UTXO pool.

[0087] In the embodiments described above, each validator has a single UTXO pool that contains the UTXOs of all transactions in all of the tree segments assigned to it. However, in an alternative approach, the UTXO pool maintained by each validator may be divided / split / compartmentalized / formed into multiple subpools, one for each block. In this way, the single UTXO pool may be organized into a logical hierarchy. In yet another approach, one or more validators may be configured in association with respective multiple UTXO pools, each multiple UTXO pool relating to UTXOs for a set of one or more tree segments. Thus, in some embodiments, the validator(s) may organize UTXOs into separate UTXO pools for different individual tree segments, or according to some predefined criteria, such as the type of tree segment or tree segments that fall within a given range. In such an embodiment, the identifier may include a block ID that can be used to narrow the search to the relevant UTXO pool, and then the search can proceed within that pool to (attempt to) identify the relevant transaction by its TxID. Those skilled in the art will understand that in some embodiments, a mixture of these approaches may be used, i.e., one or more validators within a distributed node may employ a single UTXO pool approach, while other(s) are configured to use multiple separate UTXO pools, and / or a UTXO pool organized into sub-pools, or any combination thereof.

[0088] This provides protection against "double spend" situations where a party attempts to spend the same UTXO twice. It provides a simple and secure locking mechanism that works efficiently and quickly regardless of the number or location of validators in the system, and preserves the security and integrity of transfers implemented via the blockchain.

[0089] Exemplary Systems of Possible Embodiments Figures 7 and 9 show an example system 700 for implementing at least some of the described embodiments. Figure 8 shows a flow chart of example steps that may be taken in a (high-level view of) the method of the present disclosure.

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

[0091] As shown in Fig. 7 and Fig. 9, the system 700 includes a control entity 702 (or simply "controller") and a number of validation resources 704, also referred to herein simply as "validators". Although only four validators 701a-d are shown in Fig. 7, in general the system 700 may include any number of validators. Furthermore, although the controller 702 is shown in Fig. 7 and Fig. 9 as distinct from the validators 704, this does not exclude that the controller 702 may include or be included in one of the validators 704. As explained above, each validator may include one or more processing resources and may include its own controller for the coordination of its own internal activities. There are no technical or logical limitations to the hierarchical levels that may be implemented in this manner. However, Fig. 7 shows only one level (the top) of such a hierarchy for the sake of brevity and ease of understanding.

[0092] As shown in FIG. 7, the controller 702 obtains a set of transactions. The transactions may be received over an electronic channel or network from a sending resource. The sender may be any entity that wishes to perform some type of validation check, internal or external to the organization of the system, as described above. For example, this may be a full node on the blockchain network, such as node 104 in FIG. 1, or a digital wallet, or a merchant / SPV node that wishes to perform local checks on blockchain-implemented transfers made between parties. The interface(s) 902 may facilitate the transmission of data between the system 700 and sources external to the system.

[0093] The transactions form or may form a block of transactions. The transactions may be obtained from a single resource (e.g., from a block of the blockchain) or from different resources (e.g., one or more users, one or more blockchain nodes, etc.). The transactions may be obtained before they are published on the blockchain, i.e., before they are recorded in a block. Alternatively, the transactions may be obtained after they are recorded in the blockchain.

[0094] The controller 702 assigns a respective subset of the transactions to each validator 704 as described herein. Each subset of the transactions forms at least a portion of a respective portion of a Merkle tree generated based on the full set of transactions and is linked by a respective common internal node of the Merkle tree. In the example of FIG. 7 , transaction subset A is assigned to validator A, transaction subset B is assigned to validator B, transaction subset C is assigned to validator C, and transaction subset D is assigned to validator D. Once the subsets of transactions have been assigned, the validators 704 process the respective subsets. In some embodiments, this includes each validator 704 validating its respective subset of the transactions. To do so, the controller 702 may send the relevant transactions to the respective validators 704. The validators 704 may reply to the controller 704 to indicate that each of the respective subsets of the transactions is valid or that at least one transaction is not valid.

[0095] At least one, and preferably some or all, of the validators 704a-704d have access to their own UTXO pool, shown as 901a-901d in Figure 9. This pool may include a storage facility such as the database described above, potentially with an advantageous indexing structure including a concatenation of block IDs and transaction IDs. While the pool is shown in Figure 9 as being contained within the respective validator, those skilled in the art will readily appreciate that the pool may also / alternatively be provided as being external to and in communication with the validator.

[0096] In one or more embodiments, the disclosed process may include a block-level validation phase, during which incoming new blocks are tested against block-level criteria. Exemplary block-level criteria are described above and generally relate to predefined formatting requirements and characteristics or restrictions applicable to the blocks themselves, as opposed to transactions within the blocks. Examples include block size, block header structure or contents, and similar criteria. Such operations may be performed by the controller, or a component of the controller, or another system component.

[0097] In some embodiments, the method may further include a UTXO uniqueness checking module that operates to evaluate whether each of the inputs to a transaction in the new block, i.e., each UTXO, is unique. If the same UTXO appears more than once as an input in the new block, it indicates a potential double-spend problem and violates the UTXO uniqueness criteria. If the UTXO uniqueness checking module identifies a UTXO that is referenced more than once among transaction inputs in the new block, it may output an error signal or other interrupt to indicate that the block should be rejected.

[0098] Assuming that the new block is not rejected, i.e., all UTXO entries are unique, Merkle tree segments may be identified and their associated transactions may be allocated among the set of validators. 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 one of several possible allocation schemes for distributing block segments among the individual validators, but in an advantageous approach, the allocation scheme may be for the purpose of load balancing, as explained above. The allocation unit 904 may include (or be in communication with) a load balancing unit 905. Although this is shown in FIG. 9 as a separate and related component of the system, in other embodiments, the load balancing unit may be part of the allocation unit 904 or may be separate to the controller 702. Any combination of components may be readily employed.

[0099] Individual validators validate transactions associated with the segment(s) they receive against transaction-level validation criteria. Validators operate independently in verifying that their assigned transactions are valid, so no synchronization paradigm between validators is required. Each validator outputs a result that confirms the validity of its assigned transactions. The results are added or accumulated to confirm that all transactions in the segment are valid. If one of the validators identifies a non-compliant, i.e., invalid, transaction, the validator may issue an output, such as an interrupt or other signal, to indicate that an invalid transaction is present. That interrupt or signal may be sent to other validators, or to a controller or another system component, which can immediately stop testing their respective transactions and not waste any more resources validating transactions in the block to be rejected.

[0100] In some examples, the system may be configured to check block-level criteria. This may be performed prior to the allocation of segments to validators, although it will be understood that the block-level validation stage may occur after transaction-level validation tests by the validators, and in some cases may occur in parallel with transaction-level validation tests.

[0101] Reference is now made to Figure 8, which illustrates in flow chart form one example of a method for validating a block. A block includes multiple transactions, each transaction references one or more inputs, each input being a UXTO (except in the case of a coinbase generating transaction). The method is implemented using suitable hardware and processor executable instructions in a node on the blockchain network.

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

[0103] In step S802, the system 700 identifies chunks of the Merkle tree of a block. In S803, the segments are distributed to multiple validators, which process their respective subsets of transactions substantially in parallel and independently of each other in S804. In S805, the validators signal to the controller whether the validation was successful or unsuccessful.

[0104] It should be noted that the term "processor," as used herein in connection with the description of a parallel processor, does not necessarily mean a physically separate microprocessor, but may include any hardware or software implementation that allows for parallel processing resources that can perform processor functions independently and in parallel. A parallel processor may include one processor with multiple cores. In some cases, a parallel processor may include multiple separate processing units. Parallel processors may or may not share physical memory. Each parallel processor, however implemented, has a software or hardware mechanism for signaling, such as outputting a signal in response to identifying an invalid transaction. A parallel processor implementation also includes providing, in software and / or hardware, the necessary data transfer mechanisms to route assigned transaction data to the respective processors for local processing.

[0105] Clause enumeration Embodiments of the present disclosure are provided by way of example, and not by way of limitation, in the following enumerated appendices.

[0106] Features mentioned below with respect to one set of enumerated appendices or aspects of the disclosure are not intended to be limiting in such respects, and any feature(s) mentioned with respect to one set of appendices may be incorporated in one or more of the other sets of appendices.

[0107] Appendix Set 1: <Supplementary Note 1.1> A computer-implemented method for processing (e.g., validating) at least a portion of a blockchain block that includes a plurality of blockchain transactions and the root of a Merkle tree for the block. The method may include the following step(s). assigning respective subsets of the blockchain transactions to a plurality of processing resources (e.g., validation resources), each respective subset providing a respective portion of the Merkle tree and represented by a respective interior node of the Merkle tree; and / or Processing (e.g., validating) a respective subset of the blockchain transactions using a plurality of processing (e.g., validation) resources.

[0108] Additionally or alternatively, the method may include: Transmitting or receiving at least a portion of a blockchain block including a plurality of blockchain transactions and a root of a Merkle tree for the block. The portion of the blockchain block may be transmitted from a transmitting resource to a receiving resource. It may be transmitted over a network, e.g., the Internet. The method may include processing the portion of the blockchain block at the receiving resource. The receiving resource may be referred to as a processing or validation resource. The portion of the blockchain block may be transmitted using IPv6 multicast transmission. At least one, some, or all of the plurality of processing resources may be members of an IPv6 multicast group. The transmitting resource may include a network device. The network device may be operative to transmit IPv6 multicast communications to a multicast address. MLD snooping may be enabled in the network device. This provides efficiency with respect to traffic on the network, since the transmitting resource may selectively transmit the portion of the blockchain block to a particular receiving resource (e.g., a resource within the plurality of processing resources). Network traffic is reduced and no waste of energy and processing resources is caused by transmitting data packets to all resources on the network, including those that do not need or want to receive the data. It also improves security as it avoids possible Denial of Service (DOS) attacks, while lower levels of network congestion allow for faster throughput of transactions, promoting the scalability of blockchain networks.

[0109] The term "validator" may be used interchangeably with "validation resource." Multiple validation resources may form a distributed validation node. At least one of the multiple validation resources may include one or more processing resources. Additionally or alternatively, one or more of the multiple validation resources may include a validator controller component substantially as described herein.

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

[0111] Stated another way, each subset may include at least two transactions associated with a common node in the Merkle tree such that the subset provides and / or is represented by a (sub)portion of the Merkle tree. The common (internal) node may be a segment node or root substantially as described herein. A portion of the Merkle tree may be a "segment" substantially as described herein. At least one or some of the validation resources in a distributed validation node may share, i.e., subscribe to, a common IPv6 multicast address.

[0112] <Supplementary Note 1.2> The step of validating a subset of blockchain blocks and / or blockchain transactions includes: i) validating and / or verifying at least one blockchain transaction; and / or ii) performing a Simplified Payment Verification (SPV) process; and / or iii) checking 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 Merkle path using the hash, and / or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block. The method of claim 1.1, comprising:

[0113] <Supplementary Note 1.3> At least one of the subsets of blockchain transactions includes an identifier that is associated with, identifies, and / or represents the subset; The method according to claim 1.1 or 1.2.

[0114] <Appendix 1.4> The identifier facilitates the computation of the position of at least one subset in the Merkle tree. The method described in Appendix 1.3.

[0115] <Supplementary Note 1.5> The identifier includes a portion of a hash of a blockchain transaction in at least a subset of the blockchain transactions. The method according to claim 1.3 or 1.4.

[0116] <Supplementary Note 1.6> The step of assigning each subset of the blockchain transactions to a plurality of validation resources includes matching each subset to a respective validation resource based on a respective identifier associated with the subset of transactions; 2. The method according to any preceding claim.

[0117] <Supplementary Note 1.7> i) downloading at least a subset of the blockchain transactions to at least one of a plurality of validation resources; and / or ii) sending at least a subset of the blockchain transactions to at least one of the plurality of validation resources; The method of any preceding claim, further comprising:

[0118] <Appendix 1.8> A Merkle tree is a binary tree or mesh of hashes of multiple blockchain transactions. 2. The method according to any preceding claim.

[0119] <Appendix 1.9> Identifying and / or determining a subset of blockchain transactions within a plurality of blockchain transactions The method of any preceding claim, further comprising:

[0120] <Supplementary Note 1.10> At least one of the multiple validation resources is Virtual machines, servers, GPU-based computing resources, processing threads, and / or multi-processor systems is or includes one or more of: 2. The method according to any preceding claim.

[0121] i) at least two transactions are siblings in the Merkle tree, and / or ii) A common node is a parent or ancestor of at least two transactions; 2. The method according to any preceding claim.

[0122] <Supplementary Note 1.12> A blockchain validation system that operates to validate at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, comprising: The system includes a plurality of validation resources, each of which: A processor; A memory containing executable instructions; the executable instructions, when executed by the processor, cause the system to perform a computer-implemented method as set forth in any preceding clause. Blockchain validation system.

[0123] <Appendix 1.13> A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause the computer system to perform a computer-implemented method described in any one of Appendices 1.1 to 1.11.

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

[0125] Also provided is a blockchain system (network) including a plurality of computer-implemented nodes, each node in the blockchain network being: A processor; A memory containing executable instructions; The executable instructions, when executed by the processor, cause the system to perform any variation of the computer-implemented methods claimed or described herein.

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

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

[0128] Appendix Set 2: <Supplementary Note 2.1> A computer-implemented method for receiving, e.g., downloading, at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, comprising: allocating respective subsets of the blockchain transactions to a plurality of processing resources, each respective subset providing a respective portion of a Merkle tree and represented by a respective interior node of the Merkle tree; receiving or otherwise downloading, using one, some, or all of the plurality of processing resources, a respective subset of the blockchain transactions; The method includes: According to one or more embodiments, one, some, or all of the processing resources may receive a respective subset of the blockchain transactions from the providing (transmitting) resource. The respective subsets of the blockchain transactions may be transmitted over a network, e.g., the Internet. The respective subsets of the blockchain transactions may be transmitted using IPv6 multicast transmission. At least one, some, or all of the multiple processing resources may be members of an IPv6 multicast group. The transmitting resource may include a network device. The network device may be operative to transmit IPv6 multicast communications to a multicast address. MLD snooping may be enabled in the network device. This provides efficiency with respect to traffic on the network, since the transmitting resource may selectively transmit a subset(s) of the blockchain transactions to a particular receiving resource (e.g., a resource within the multiple processing resources). Network traffic is reduced, eliminating the waste of energy and processing resources by transmitting data packets to all resources on the network, including those that do not need or want to receive the data. It also improves security as it avoids the possibility of denial of service (DOS) attacks, while lower levels of network congestion allow for faster throughput of transactions, promoting scalability of the blockchain network.

[0129] Each respective subset may be represented by a respective internal node in the sense that each respective internal node may encode the respective subset. That is, each respective internal node may be generated based on (i.e., as a function of) the respective subset. Each transaction in each respective subset may be linked to the respective internal node by one or more hash operations.

[0130] <Appendix 2.2> One, some, or all of the multiple processing resources sending respective subsets of the blockchain transactions to a central storage location. The method of claim 2.1, comprising:

[0131] <Appendix 2.3> Each internal node of the Merkle tree has a respective position in the Merkle tree, and the method further comprises: placing each subset of the blockchain transactions based on their respective positions in each internal node of the Merkle tree; The method of claim 2.2, comprising:

[0132] <Supplementary Note 2.4> One, some, or all of the processing resources generate respective candidate internal nodes of the Merkle tree based on the respective downloaded subsets of the blockchain transactions. Including, verifying that each candidate internal node matches a respective internal node of the Merkle tree; and / or verifying that each candidate internal node is a node of the Merkle tree by performing a Merkle proof based on the root of the Merkle tree; and / or sending each candidate internal node of the Merkle tree to one or more other processing resources; The method of any preceding claim, further comprising at least one of:

[0133] <Appendix 2.5> Validating each subset of blockchain transactions using one, some, or all of a plurality of processing resources. The method of any preceding claim, comprising:

[0134] <Supplementary Note 2.6> The step of validating each subset of blockchain transactions includes: i) validating and / or verifying at least one blockchain transaction; and / or ii) performing a simplified payment verification process; and / or iii) checking whether the given blockchain transaction is contained within a blockchain block; and / or iii) generating a hash of at least one of the blockchain transactions, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier in a header of the blockchain block. The method described in Appendix 2.1.

[0135] <Supplementary Note 2.7> At least one of each subset of blockchain transactions includes a respective identifier associated with, identifying, and / or representing the respective subset; 2. The method according to any preceding claim.

[0136] <Appendix 2.8> Each identifier facilitates the computation of the position of each of at least one respective subset in the Merkle tree. The method described in Appendix 2.7.

[0137] <Appendix 2.9> Each identifier is based on each internal node of the Merkle tree, The method according to claim 2.7 or 2.8.

[0138] <Appendix 2.10> Each identifier contains a portion of each internal node of the Merkle tree, The method of claim 9.

[0139] <Supplementary Note 2.11> The step of allocating each subset of the blockchain transactions to a plurality of respective processing resources includes a step of matching each subset to a respective processing resource based on a respective identifier associated with each subset of the transactions; 2. The method according to any preceding claim.

[0140] <Appendix 2.12> A Merkle tree is a binary tree or mesh structure of hashes of multiple blockchain transactions. 2. The method according to any preceding claim.

[0141] <Appendix 2.13> Identifying and / or determining a subset of blockchain transactions within a plurality of blockchain transactions The method of any preceding claim, comprising:

[0142] <Supplementary Note 2.14> At least one of the multiple processing resources is or includes a virtual machine, a server, a GPU-based computing resource, or a multiprocessor system; 2. The method according to any preceding claim.

[0143] <Supplementary Note 2.15> A blockchain processing system that operates to download at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, the system including a plurality of processing resources, each of the plurality of processing resources: A processor; A memory containing executable instructions; the executable instructions, when executed by a processor, cause or enable a system to perform a computer-implemented method as set forth in any preceding clause. Blockchain processing system.

[0144] <Appendix 2.16> A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause or enable a computer system to perform any of the computer-implemented methods described in Appendices 2.1 to 2.14.

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

[0146] Appendix Set 3: <Supplementary Note 3.1> A computer-implemented method, comprising: generating, storing, and / or maintaining a first output repository for recording, retrieving, and / or processing a plurality of unspent transaction outputs respectively associated with transactions (Tx) in a plurality of blockchain transactions (TX) of a blockchain block; Including, The plurality of blockchain transactions provide and / or are represented by a portion of a Merkle tree for a blockchain block; method. In some embodiments, the first output repository may be referred to as the first UTXO output repository. An unspent transaction output may be referred to as a UTXO.

[0147] <Appendix 3.2> Generating, storing and / or maintaining at least one further output repository The method of claim 3.1, comprising:

[0148] <Appendix 3.3> Creating and / or maintaining a database log containing a history of actions, changes, and events related to the output repository The method of claim 3.1 or 3.2, further comprising:

[0149] <Appendix 3.4> The first output repository and / or the further output repository: i) Unspent Transaction Outputs, and / or ii) a) unspent transaction outputs and / or b) an identifier associated with a transaction (Tx) among multiple blockchain transactions. The method of any preceding claim, comprising at least one record associated with

[0150] <Appendix 3.5> At least one record, i) the block identifier (block_ID) associated with the blockchain block, and / or ii) A transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions. The method of claim 3.4, including a record identifier having the following:

[0151] <Appendix 3.6> i) The record identifier includes a function of a block identifier (block_ID) and a transaction identifier (TxID), and / or ii) the concatenation of a block identifier (block_ID) and a transaction identifier (TxID), and / or iii) Transactions across multiple blockchains are associated with unspent transaction outputs (UTXOs); The method described in Appendix 3.5.

[0152] <Appendix 3.7> Using the record identifier to locate, identify, access, or insert at least one record in the output repository. The method of claim 3.5 or 3.6, further comprising:

[0153] <Supplementary Note 3.8> At least one UTXO in a plurality of unspent transaction outputs (UTXOs) is associated with a lock flag in the output repository, and the lock flag is: i) Indicates whether unspent transaction outputs (UTXOs) are available or unavailable; and / or ii) being configurable between a first state indicating that use of unspent transaction outputs is permitted and a second state indicating that use of unspent transaction outputs is prohibited; The method according to any preceding claim.

[0154] <Appendix 3.9> The method is i) associating unspent transaction outputs (UTXOs) with a lock flag; and / or ii) changing the state of the lock flag from a first state to a second state or from the second state to the first state. The method of claim 3.8, comprising:

[0155] <Supplementary Note 3.10> Sending a communication from the first processing resource to the at least one further processing resource to cause the at least one further processing resource to change a state of a lock flag associated with the unspent transaction output from the first state to the second state or from the second state to the first state. The method of claim 3.8 or 3.9, further comprising: The communication may be sent to an IPv6 address associated with the at least one further processing resource using multicast transmission.

[0156] <Appendix 3.11> Communications are i) the transaction (TX), the transaction identifier (TxID), and / or the hash of the transaction (Tx), and ii) A list of one or more unspent transaction outputs (UTXOs). The method of claim 3.10, comprising:

[0157] <Supplementary Note 3.12> Receiving a communication at at least one further processing resource; changing the state of the lock flag from the first state to the second state or from the second state to the first state; The method of claim 3.10 or 3.11, comprising:

[0158] <Appendix 3.13> i) a portion of a Merkle tree is a sub-portion or segment of a Merkle tree for a blockchain block; and / or ii) Multiple blockchain transactions are represented by interior nodes of the Merkle tree; 2. The method according to any preceding claim.

[0159] <Supplementary Note 3.14> A blockchain implementation system including a plurality of processing resources, each of which is A processor; A memory containing executable instructions; the executable instructions, when executed by a processor, cause or enable a system to perform a computer-implemented method as set forth in any preceding clause. Blockchain processing system.

[0160] <Appendix 3.15> A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause or enable a computer system to perform any of the computer-implemented methods described in Appendices 3.1 to 3.13.

[0161] Note Set 4 Any embodiment defined in any addendum or combination of addendums in addendum set 4 may be configured to implement or combine with any addendum(s) in addendum sets 1 to 3.

[0162] <Supplementary Note 4.1> A system operative to validate at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, comprising: Multiple Validation Resources each of the plurality of validation resources At least one processor associated with at least a portion of the memory that stores executable instructions. the executable instructions, upon execution by the at least one processor, cause a validation resource to: Validating at least a subset of a plurality of blockchain transactions, the at least a subset providing a portion of a Merkle tree and represented by an interior node of the Merkle tree; A system that causes or enables the execution of

[0163] <Supplementary Note 4.2> i) a load balancing component configured to facilitate balancing the distribution of a plurality of subsets of a plurality of blockchain transactions among a plurality of validation resources; and / or ii) a segment identification component configured to facilitate identification of at least a subset of the plurality of blockchain transactions; and / or iii) Allocation Units; and / or iv) One or more interfaces for sending or receiving communications between the system and one or more data sources or destinations. The system of claim 4.1, further comprising:

[0164] <Supplementary Note 4.3> The system includes at least one controller component, the at least one controller component being At least one validation resource, at least one processor of at least one validation resource; One or more interfaces, one or more load balancing components, and / or One or more segment identification components configured to facilitate identification of at least a subset of the plurality of blockchain transactions. 3. The system of claim 4.1 or 4.2, configured to affect and / or control the operation of at least one of the following:

[0165] <Supplementary Note 4.4> i) At least two of the multiple blockchain transactions are siblings in the Merkle tree, and / or ii) an internal node is a parent or ancestor of a subset of blockchain transactions; 2. The system of any preceding claim.

[0166] <Supplementary Note 4.5> A plurality of UTXO repositories, each of which is associated with a respective validation resource and configured to facilitate recording, retrieval, and / or processing of a plurality of unspent transaction outputs (UTXOs). Further equipped with Preferably, each of the plurality of unspent transaction outputs is associated with at least one transaction (Tx) in the plurality of blockchain transactions; 2. The system of any preceding claim.

[0167] <Appendix 4.6> Create and / or maintain a database log containing a history of actions, modifications, and events with respect to at least one of multiple UTXO repositories. 4.5. The system of claim 4.5,

[0168] <Appendix 4.7> At least one of the multiple UTXO repositories: i) Unspent Transaction Outputs (UTXOs), and / or ii) a) unspent transaction outputs and / or b) an identifier associated with a transaction (Tx) among multiple blockchain transactions. Contains at least one record associated with 2. The system of any preceding claim.

[0169] <Appendix 4.8> At least one record, i) the block identifier (block_ID) associated with the blockchain block, and / or ii) A transaction identifier (TxID) associated with a transaction (Tx) among multiple blockchain transactions. The system of claim 4.7, further comprising a record identifier having:

[0170] <Appendix 4.9> The record identifier is i) a function of the block identifier (block_ID) and the transaction identifier (TxID), and / or ii) a concatenation of a block identifier (block_ID) and a transaction identifier (TxID); 9. The system of claim 4.7 or 4.8,

[0171] <Appendix 4.10> The system is Using the record identifier, locate, identify, access, or insert at least one record in at least one UTXO repository among the plurality of UTXO repositories. 10. The system according to claim 8 or 9, which operates as follows:

[0172] <Supplementary Note 4.11> At least one UTXO among the multiple unspent transaction outputs (UTXOs) is associated with a lock flag, and the lock flag: i) Indicates whether unspent transaction outputs (UTXOs) are available or unavailable; and / or ii) being configurable between a first state indicating that use of unspent transaction outputs is permitted and a second state indicating that use of unspent transaction outputs is prohibited; 11. The system of any of Clauses 4.5 to 4.10.

[0173] <Appendix 4.12> The system is Changes the state of a lock flag from a first state to a second state or from a second state to the first state The system of claim 4.11,

[0174] <Appendix 4.13> i) Allocating each subset of blockchain transactions to multiple validation resources; and ii) using one, some, or all of the multiple validation resources to download and / or receive respective subsets of the blockchain transactions; 2. The system of any preceding claim, operative to:

[0175] <Appendix 4.14> Using one, some, or all of the validation resources to generate candidate internal nodes for each of the Merkle trees based on each downloaded subset of blockchain transactions. It operates to do Verifying that each candidate internal node matches a respective internal node of the Merkle tree; and / or verifying that each candidate internal node is a node of the Merkle tree by performing a Merkle proof based on the root of the Merkle tree; and / or sending each candidate internal node of the Merkle tree to one or more other processing resources; The system of any preceding claim, further operative to perform at least one of the following:

[0176] <Appendix 4.15>i) validating and / or verifying at least one blockchain transaction; and / or ii) carrying out a simplified payment verification process; and / or iii) verifying whether a given blockchain transaction is contained within a blockchain block; and / or iii) generating a hash of at least one of the blockchain transactions, constructing a Merkle path using the hash, and / or checking whether the hash matches a transaction identifier in a header of the blockchain block. 2. The system of any preceding claim, operative to:

[0177] <Supplementary Note 4.16> At least one of the multiple validation resources is or includes at least one of a virtual machine, a server, a GPU-based computing resource, a thread, and / or a multiprocessor system; 2. The system of any preceding claim.

[0178] Exemplary Technology Environment for Implementing Exemplary Embodiments of the Present Disclosure We now provide an overview of a computing environment in which one or more embodiments of the present disclosure may be implemented. However, as noted above, this context is not intended to be limiting, and embodiments may be implemented for processing data records and structures that are not implemented via blockchain. Non-blockchain embodiments may be devised, for example, using databases rather than distributed ledgers.

[0179] FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may be comprised of a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0181] The blockchain 150 includes a chain of data blocks 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a decentralized or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing an amount of digital assets as a property, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or used). Each input points to the output of a preceding transaction 152, thereby linking the transactions.

[0182] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain to define an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer back to a previous transaction to define an order for the sequence of transactions (Note: a sequence of transactions 152 can branch). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0183] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. This refers to an ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0184] For a given current transaction 152j, its input (or each input) contains a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. Although a preceding transaction 152i must exist and be validated for the current transaction to be valid, a preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or transmitted to the network 106. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by a pointer, and not necessarily to the time of creation or transmission in the time sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i is also referred to as an antecedent transaction or a predecessor transaction.

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

[0186] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (manually or by an automated process adopted by the party), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which is currently typically a server or a data center, but in principle could be other user terminals). It is not excluded that the party 103 enacting the new transaction 152j sends the transaction directly to one or more of the blockchain nodes 104 and in some examples does not send it to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of them. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction uses (or "assigns"), which condition typically includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i. Alternatively, it may be fixed solely by the blockchain node protocol or by a combination of these.In any event, 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 node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0187] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has been validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it is trying to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated for a warning) or recorded in the blockchain 150. This prevents double-spending, where a transactor tries to allocate the output of the same transaction multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because the transaction order is defined, the account balances are always in a single defined state.

[0188] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is supported by "proof of work." At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated and hashed with a representation of the ordered pool 154 of pending transactions, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output for its input. This search can therefore only be performed in a brute force manner, consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0189] The first blockchain node 104 to solve the puzzle publishes this to the network 106 and provides its solution as a proof that can be easily checked later by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the output of the hash satisfies the conditions). This first blockchain node 104 propagates the block to threshold consensus of other nodes that accept this block and enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution indicates the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it uses or assigns the same output as a previously validated transaction (also known as double-spending). Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0190] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined, ordered pool of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may occur if two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate between the nodes 104. In essence, whichever prong of the fork grows the longest will be the deterministic blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both forks.

[0191] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate the additional amount of accepted digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but may also be referred to as an "initiation transaction" or "generation transaction." This typically forms the first transaction of a new block 151n. The proof of work indicates the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturity period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generative) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and is explained below.

[0192] Due to the resources involved in transaction validation and publishing, typically at least each of the blockchain nodes 104 takes the form of a server made up of one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0193] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0194] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers of transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0195] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but are not blockchain nodes 104 because they do not fulfill the role required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting (i.e., communicating) with the blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes, namely, a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that there may be many more such parties 103 and their respective computer devices 102 and they may participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, although it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0196] The computer equipment 102 of each party 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises a memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. This memory may comprise 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 memories or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to run on the processing device. It will be understood that any action attributed to a given party 103 herein may be performed using software running on the processing device of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

[0198] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104 for propagation across the network of blockchain nodes 104 and thereby inclusion in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of the various transactions 152 scattered across the blockchain 150 that belong to that party.

[0199] It should be noted that various client functions may be described as being integrated into a given client application 105, but are not necessarily limited thereto; instead, any client functionality described herein may be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer or a lower layer, such as an operating system, or any combination thereof. The following description is given with respect to client application 105, but will be understood to be non-limiting.

[0200] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward the transactions 152 to propagate them across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol goes with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0201] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using a wallet function in Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This includes first checking if the newly received transaction 152j meets certain conditions to be "valid", examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0202] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, it will be propagated immediately throughout the network 106.

[0203] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but whichever node solves it first defines the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it universally becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 contains a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

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

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

[0206] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. It is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). In the following, it is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0207] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which 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 that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include a transaction ID of the underlying transaction, among other information. The transaction data structure may also include a header 201 that may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 that is submitted to the node 104.

[0208] Suppose Alice 103a wants to create a transaction 152j that transfers an amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point to any previous (i.e., earlier) transaction that still has unspent outputs 203 locked to Alice.

[0209] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 106 together, or even Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of the transactions in a sequence defined by transaction pointers (e.g., which transactions point to which other transactions) specified in the transactions. They may similarly be replaced with "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. This does not necessarily imply the order of their creation, transmission to the network 106, or arrival at any given blockchain node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for the parent or discarded, depending on the node protocol and / or node behavior.

[0210] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that an unlocking script in the input 202 of the following transaction must satisfy in order for the following transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines an unlocking condition that includes a condition that an unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction is locked.

[0211] A lock script (commonly called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies what information is needed to use the transaction output 203, e.g. the need for Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0212] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig P A ] is the public key P of Alice's public-private key pair.A Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key of her key pair to a given portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0213] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that are composed in the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create Alice's public key P as contained in the lock script in the output of Tx0. A, to authenticate that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. In order to perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the data to be signed includes the entirety of Tx1 (i.e., a separate element specifying the signed portion of the plaintext data does not need to be included, as that is already inherently present).

[0214] The details of public-private cryptographic authentication are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular portion of data or part of a transaction, etc., may, in embodiments, mean signing a hash of that portion of data or part of a transaction.

[0215] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the ordered pool 154 of pending transactions. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that the transaction Tx1 is propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it uses unspent transaction outputs 203. If it attempts to use an output that has already been used by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it already formed a valid input to another valid transaction in the blockchain 150.

[0216] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another ground of invalidity in most transaction models, so such a transaction will not be propagated or included in block 151.

[0217] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined as spent in the UTXO cannot be "left" while another part is spent. However, it is possible to split the amount from the UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use a reminder to give the remainder to herself in the second output of Tx1 or to pay another party.

[0218] In practice, Alice would also typically need to include a fee for any Bitcoin node 104 that successfully includes Alice's transaction 104 in a block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus may not be propagated and included in the blockchain 150, even if it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or used) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0219] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. No number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to collate together all the values ​​of the various UTXOs that are locked to the respective parties and that have not yet been used in another subsequent transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0220] Note that scripting code is often represented generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in the scripting language. As an example, OP_RETURN is an opcode in the scripting language that creates an unusable output of a transaction that can store data in the transaction when preceded by OP_FALSE at the beginning of the lock script, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0221] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific portion of the data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs, and some or all of the transaction outputs. The specific portion of the outputs that are signed depends on the SIGHASH flag, which is a four-byte code that is typically included at the end of the signature (and is therefore fixed at the time of signing) to select which outputs are signed.

[0222] A lock script may typically be referred to as a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script may typically be referred to as a "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, any condition or conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0223] Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a (at the instigation of either party or a third party) to establish a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data apart from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction (yet) being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0224] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, anywhere in this specification, the side channel 107 referenced may include any link or links over one or more networking technologies or communication media for exchanging data "off-chain," i.e., apart from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange information or particular pieces of data, etc., over the side channel 107, this does not necessarily mean that all of these pieces of data must be transmitted over the exact same link or the same type of network.

[0225] Further notes Other variations or use cases of the disclosed techniques may become apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims. For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0226] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, issuing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and issuing blocks (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0227] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, issuing, propagating, and storing blocks 151 of the blockchain 150. For example, on those other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and issue blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0228] Even more generally, any reference above to the term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element”, where such entity / element is configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

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

[0230] The above-described embodiments are illustrative rather than limiting of the disclosure, and those skilled in the art could design many alternative embodiments without departing from the scope of the disclosure, which is defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the scope of the claims. Terms such as "comprising" and "comprises" do not exclude the presence of elements or steps other than those listed in the claim or the specification as a whole. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consisting of". It will be understood that throughout this specification, the word "comprise", or variations such as "includes", "comprises" or "comprising" are meant to include the stated elements, integers or steps, or groups of elements, integers or steps, and are not meant to exclude any other elements, integers or steps, or groups of elements, integers or steps. The singular reference of an element does not exclude the plural reference of such element, and vice versa. The disclosure can 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

1. 1. A computer-implemented method comprising: generating, storing, and / or maintaining a first output repository for recording, retrieving, and / or processing a plurality of unspent transaction outputs respectively associated with transactions (Tx) among a plurality of blockchain transactions (TX) of a blockchain block; Including, the plurality of blockchain transactions provide and / or are represented by a portion of a Merkle tree for the blockchain block; method.

2. generating, storing, and / or maintaining at least one further output repository; The method of claim 1 , comprising:

3. creating and / or maintaining a database log containing a history of actions, changes, and events associated with said first output repository; The method of claim 1 further comprising:

4. The first output repository and / or at least one further output repository may include: i) unspent transaction outputs, and / or ii) a) an unspent transaction output, and / or b) an identifier associated with a transaction (Tx) in said plurality of blockchain transactions. The method of claim 1 , further comprising at least one record associated with the

5. The at least one record comprises: i) the block identifier (block_ID) associated with the blockchain block; and / or ii) a transaction identifier (TxID) associated with a transaction (Tx) in the plurality of blockchain transactions; The method of claim 4 , including a record identifier having:

6. i) the record identifier comprises a function of the block identifier (block_ID) and the transaction identifier (TxID); and / or ii) the record identifier comprises a concatenation of the block identifier (block_ID) and the transaction identifier (TxID); and / or iii) the transactions of the plurality of blockchain transactions are associated with unspent transaction outputs; The method of claim 5.

7. using the record identifier to locate, identify, access, or insert the at least one record in the first output repository and / or at least one further output repository; The method of claim 5 further comprising:

8. At least one unspent transaction output in the plurality of unspent transaction outputs is associated with a lock flag, the lock flag being: i) indicating whether the unspent transaction output is usable or unusable; and / or ii) configurable between a first state indicating that use of the unused transaction output is permitted and a second state indicating that use of the unused transaction output is prohibited; The method of claim 1.

9. The method comprises: i) associating said unspent transaction output with said 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; The method of claim 8, comprising:

10. sending a communication from the first processing resource to at least one further processing resource to cause the at least one further processing resource to change the state of the lock flag associated with the unspent transaction output from the first state to the second state or from the second state to the first state; The method of claim 8 further comprising:

11. The communication i) the transaction (TX), transaction identifier (TxID), and / or hash of the transaction (Tx), and ii) a list of one or more unspent transaction outputs; The method of claim 10, comprising:

12. receiving the communication at the at least one further processing resource; changing the state of the lock flag from the first state to the second state or from the second state to the first state; The method of claim 10, comprising:

13. i) the portion of the Merkle tree is a sub-portion or segment of the Merkle tree for the blockchain block; and / or ii) the plurality of blockchain transactions are represented by interior nodes of the Merkle tree; The method of claim 1.

14. 1. A blockchain validation system that operates to validate at least a portion of a blockchain block that includes a plurality of blockchain transactions and a root of a Merkle tree for the block, the system comprising: The system includes a plurality of validation resources, each validation resource comprising: a processor; a memory containing executable instructions; the executable instructions, when executed by the processor, cause a system to perform the computer-implemented method of any one of claims 1 to 13. Blockchain validation system.

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 computer system to perform the computer-implemented method of any one of claims 1 to 13.

Images