Maintaining blocks of a blockchain in a partitioned blockchain network

Abstract

Merkle Tree)。 A computer-implemented method and system is provided that maintains blocks of a blockchain across nodes of a sharded blockchain network, wherein each node is a member of one or more shards of a plurality of active shards. The method and system employ a given node that is a member of a particular subset of the plurality of active shards to generate data representing a new block of the blockchain and store the data representing the new block. Such data includes i) a list of transaction identifiers for transactions that are part of the new block and associated with the particular subset of the plurality of active shards, and / or ii) a Partial Merkle Tree for the new block.

Description

[Technical Field]

[0001] This disclosure is generally about computer-implemented systems and methods for processing blockchain transactions, and more specifically about systems and methods for partitioning a blockchain and verifying transactions and blocks of a partitioned blockchain. [Previous Technology]

[0002] In this document, the term "blockchain" refers to any of several types of computer-based electronic decentralized ledgers. These ledgers include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin blockchain, although other blockchain implementations have been proposed and developed. While examples of Bitcoin are mentioned herein for convenience and illustrative purposes, it should be noted that this disclosure is not limited to use with the Bitcoin blockchain; and alternative blockchain implementations and protocols fall within the scope of this disclosure. For example, this disclosure can be used in other blockchain implementations that have similar restrictions to Bitcoin regarding which constraints can be encoded within transactions.

[0003] A blockchain is a peer-to-peer electronic ledger generated and maintained through a computer-based, decentralized, decentralized system. The ledger consists of blocks, which in turn consist of transactions and other information. A blockchain system or network comprises multiple blockchain nodes and a set of operations. Blockchain nodes may be configured to perform some or all of the operations within that set. Various blockchain nodes may be implemented via computer hardware, computer software, or a combination of both operated by node operators, where the node operators may be independent and not associated with other node operators. Each blockchain node may maintain a copy of the blockchain ledger or a portion thereof. The set of operations may include generating transactions, propagating transactions, reading the blockchain ledger, evaluating the blockchain ledger, generating (mining) new blocks proposed for addition to the blockchain ledger, communicating with other blockchain nodes, and providing users with e-wallet functionality to generate transactions and manage blockchain assets.

[0004] The decentralized nature of a blockchain ledger lies in the absence of a single blockchain node or entity that determines when the ledger is modified. Instead, each blockchain node, understanding the rules of the blockchain protocol, is programmed to verify the blockchain ledger and to verify that actions performed by other blockchain nodes conform to those rules. The term "blockchain" can refer to the fact that a blockchain ledger comprises a series of linked blocks, each block representing a data structure in computer memory, readable by a computer program and transferable as data. A block contains one or more transactions, which can also be represented as data structures in computer memory, readable by a computer program and transferable as data. Blocks are linked in that each new block officially added to the blockchain contains an immutable reference to its directly preceding block, and so on.

[0005] For a given transaction, in order to be included in a block to be written to the blockchain, one or more nodes verify the transaction and may propagate it to other nodes. Nodes mine a block containing the given transaction, and other nodes verify the validity of the block and the validity of the transactions within it. Because mining nodes are programmed or assembled with these rules in mind, it is unlikely that a mining node will include a transaction in a block that would invalidate the block; therefore, the block would not be accepted by other nodes, and the mining node would not benefit. For example, in many blockchain networks, blocks may include "reward" transactions, where a specified amount of value is allocated to the operator of the mining node. In this way, the successful miner is compensated by the value generated by using the block. Furthermore, transactions may include transaction fees, which also benefit the operator of the mining node.

[0006] Transactions in a blockchain network contain various data elements, including units of value and other data elements. Units of value can be cryptocurrencies (such as Bitcoin SV), but other variations using other digital assets are possible. In a decentralized ledger system, the ledger can be public, allowing anyone to view the ledger and access transactions stored in the blocks of the ledger.

[0007] Blockchain networks, such as the Bitcoin blockchain, can suffer from performance limitations related to transaction verification caused by delays in the propagation of transactions through the network. This is because each transaction needs to be verified before it can be propagated to other nodes for mining. In addition, as the size of the blockchain grows, the storage requirements for nodes verifying transactions and blocks also increase. [Summary of the Invention]

[0008] Summary of the Invention Therefore, there is a need to provide an improved system and method for improving the scalability of a blockchain ledger by using partitioning or sharding.

[0009] Dividing a blockchain network into several shards allows users to choose their level of participation in the blockchain network. Each user can choose to be a member of one or more shards. Users who are members of fewer than all shards require less storage space to store all transactions assigned to the shards to which they are members. Assigning transactions to shards based on their transaction IDs offers the following advantages: the shard sizes will be approximately equal, thereby avoiding undue burdens on members of larger shards relative to members of smaller shards, while simultaneously ensuring that transaction and association verifications are performed accurately and without any undue delays.

[0010] The term "user" as used herein may be associated with one or more nodes or computing devices, and such nodes may also be referred to as client entities in a partitioned blockchain network. In the following text, reference to a user may also be understood as a reference to a node or entity associated with the user (which may own or control a portion of the fragmented or partitioned blockchain network). Each node may be communicatively coupled to at least one or more other nodes in the partitioned blockchain network.

[0011] The advantages discussed herein in relation to this and other forms of the disclosure (discussed below) are attributable to the node structure and the resulting network topology and architecture of the sharded blockchain network, as well as the protocols associated with the network nodes. Receiving, storing, and / or verifying UTXOs in this sharded network utilizes the methods described and claimed, rules and protocols for communication, data storage, and data sharing, as well as verification techniques for nodes within each shard and associated rules and protocols based on communication with nodes belonging to different shards.

[0012] These specific structures, data flow methods, transaction allocation, and verification protocols will be further explained below in relation to various embodiments of this disclosure. Advantageously, the sharded network structure or architecture and the associated methods described herein for transaction allocation and verification of such allocated transactions within a sharded blockchain network provide novel technologies for data flow, data storage, and UTXO verification checks. Furthermore, these technologies advantageously prevent double-spending attacks, such as Sybil attacks in the Bitcoin blockchain given its structure and data communication / verification protocols.

[0013] Therefore, according to this disclosure, a computer-implemented method and system for maintaining several blocks of a blockchain across several nodes in a sharded blockchain network can be provided, wherein each node is a member of one or more shards in a plurality of functions. The method and system use a given node that is a member of a specific subset of the plurality of shards, wherein the given node is configured to generate and store data representing a new block of the blockchain. This data includes i) a list of transaction identifiers for transactions that are part of the new block and associated with that specific subset of the plurality of shards, and / or ii) a partial Merkle tree for the new block. The list of transaction identifiers in i) does not include transaction identifiers for transactions that are part of the new block and not associated with that specific subset of the plurality of shards.

[0014] In an embodiment, the list of transaction identifiers of i) can be generated by: constructing an initial list of transaction identifiers for the new block based on the data included in the new block, and processing the initial list of transaction identifiers by removing any transaction identifiers corresponding to a transaction that is not associated with the specific subset of the multiple action shards.

[0015] In an embodiment, the local Merkle tree of ii) includes hash values ​​derived from transactions that are part of the new block and are not associated with the specific subset of the shards in the plurality of actions, while omitting hash values ​​derived from transactions that are part of the new block and are associated with the specific subset of the shards in the plurality of actions.

[0016] In an embodiment, the local Merkle tree of ii) may be generated by: constructing a full Merkle tree for the new block based on the data included in the new block, and processing the full Merkle tree to replace placeholders for hash values ​​derived from transactions that are part of the new block and associated with the particular subset of the multiple active shards.

[0017] In an embodiment, processing the full Merkle tree may further include iterating from the bottom level of one of the full Merkle trees to the root level and removing two hash values ​​for an adjacent node pair and leaving a parent hash value.

[0018] In an embodiment, processing the full Merkle tree may further include iterating from the bottom level of one of the full Merkle trees to the root level and replacing a placeholder for the hash value of a parent tree node having two child nodes, the two child nodes not both representing a hash value derived from a transaction not associated with the particular subset of the multiple action shards.

[0019] In an embodiment, the node is operable to process the local Merkle tree to compute one of the Merkle root hash values ​​for block verification without requiring access to such transactions, which are part of the block and not associated with that particular subset of the shards in the plurality of actions.

[0020] In an embodiment, processing the local Merkle tree to calculate the Merkle root hash value may involve iterating from one of the bottom levels of the local Merkle tree to the root level, replacing any placeholder in the bottom level with the corresponding hash value from the list of transaction identifiers from i), and replacing any placeholder in a level higher than the bottom level with the corresponding sub-hash value from the local Merkle tree.

[0021] In an embodiment, the transaction identifier list (i) and the local Merkle tree (ii) may vary between the nodes based on node membership and the transactions, and the allocation among the shards may change.

[0022] In an embodiment, a transaction that is part of a new block may be associated with (or assigned to) several shards of a plurality of actions based on a transaction identifier.

[0023] In other embodiments, a transaction that is part of a new block may be associated with (or assigned to) several shards of a plurality of shards in a plurality of actions based on a parent blockchain transaction, wherein the parent transaction is defined by an output corresponding to an input of a child blockchain transaction, and wherein both the parent transaction and the child transaction are associated with the same shard.

[0024] In this embodiment, the block data maintained by the nodes can omit transaction data for shards to which the nodes do not belong, thus saving node storage space. Therefore, some nodes can store the data structure of the blockchain for a finite subset of the blockchain's transactions, while other nodes store the data structure of all transactions in the blockchain. In this case, the data storage capacity of the node storing the data structure of a finite subset of the blockchain can be much smaller than the data storage capacity of the node storing the data structure of the entire blockchain.

[0025] In an embodiment, when generating the data representing the new block, the node can verify transactions that are part of the new block and associated with that specific subset of the shards in the plurality of actions, while omitting the verification of transactions that are part of the new block but not associated with that specific subset of the shards in the plurality of actions. This processing reduces the computational effort of block verification operations. This advantage, along with reduced data storage capacity requirements for certain shards of the blockchain network, allows nodes to participate effectively in the blockchain network with limited computational resources.

[0026] Therefore, based on this disclosure, a method as defined in the accompanying technical solution is provided.

[0027] According to this disclosure, an electronic device including a processor, computer memory, and a network interface device can be provided. The memory has computer-executable instructions stored thereon, which, when executed, assemble the processor to perform the methods as described herein.

[0028] According to this disclosure, a non-transitory computer-readable storage medium may be provided. The computer-readable storage medium includes computer-executable instructions that, when executed, assemble a processor to perform the methods described herein.

Implementation Method

[0040] Detailed Description of Preferred Embodiments Referring first to FIG1A, an example blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure is illustrated. In the embodiment, the blockchain network 100 includes: blockchain nodes, which may be implemented as peer-to-peer decentralized electronic devices, each executing its own software; and / or hardware that performs operations following a blockchain protocol, which is agreed upon wholly or partially among the operators of the blockchain nodes. In some instances, such decentralized electronic devices are simply referred to as "nodes," such as node 102 in FIG1A. One example of a blockchain protocol is the Bitcoin protocol.

[0041] Node 102 may include any suitable computing device (e.g., a server in a data center, a client computing device such as a desktop computer, laptop, tablet, smartphone, etc.), multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device such as computing device 2600 in Figure 9. Node 102 may have input to receive data messages or objects representing transactions and / or blocks, as well as information related to other nodes. Node 102 may query information it maintains, such as its understanding of the state of transactions.

[0042] As shown in FIG. With respect to which nodes 102 can communicate with which other nodes, those details do not need to be determined centrally. Role in the blockchain network 100 It is sufficient that the total node is capable of communicating with one or more other nodes 102 such that a message transmitted from one node 102 to another node 102 can be propagated across the blockchain network 100 (or some significant part of the blockchain network), wherein the message is assumed to be a message that the blockchain protocol indicates should be forwarded. One such message may be for publishing a transaction proposed by one of node 102A, the message will then be propagated along one of path such as path 106 . In addition this message can be for the release of new blocks proposed to be included on the blockchain.

[0043] Node 102 may store a distributed blockchain ledger (or blockchain) containing data corresponding to a transaction and data corresponding to a transaction block. Node 102 may store a complete copy of the blockchain ledger or a portion thereof. For example, some nodes can store data for the entire blockchain ledger, while others can store data for only unspent transactions, while other nodes may maintain the entire blockchain ledger. Node 102 may include validating the functionality of each block it receives and the transactions in this block. Some of the nodes 102 may be miner nodes that collect transactions and generate blocks of transactions such that new blocks can be added to the blockchain ledger. The miner node may be expected to perform some job that is both complex (to avoid malicious nodes easily generating improper blocks) and depends on the data of the included transactions (so that the malicious node cannot perform complex operations ahead of time), where the execution of those tasks is easily verified by other nodes. When generating new blocks, it is possible for multiple miner nodes to compete to perform the necessary work. This is known as "proof-of-work" mining. Alternatively, the miner node of the new block depends on the value of the new block also defined as equity and can be selected in a deterministic way. This is called "certificate of title" excavation or forging. The miner node propagates the new block to other nodes for verification. Other nodes validate the new block and the transactions embedded in the new block. If the validation operation performed by resorting to the node is successful, the node adds the new block to the blockchain and propagates the new block to other nodes. This submits the new block to the blockchain ledger.

[0044] In some instances, blocks are often groups of transactions marked with timestamps and "fingerprints" (e.g., hashes) of previous blocks. In this way, each block becomes linked to previous blocks, thereby creating a "chain" of blocks in the blockchain ledger. Each block includes information (e.g., transaction identifiers) indicating the group of transactions in the block. In embodiments, valid blocks are added to the blockchain ledger through consensus among nodes in the blockchain network. Also, in some instances, the blockchain ledger contains an ordered list of verified blocks. Figure 1B illustrates a blockchain ledger 1216 with a chain of three blocks 1221, 1223, and 1223. It should be noted that block 1222 includes information indicating the group of transactions in block 1222 (e.g., block header 1230 and transaction identifiers 1231(1), 1231(2), 1231(3)...).

[0045] This disclosure aims to improve the scalability of blockchain ledgers by using partitioning. Partitioning in this technique considers two specific dimensions: a horizontal dimension and a vertical dimension. In horizontal partitioning, data is divided into different segments called shards, which are effectively multiple instances of a particular database scheme, in which data is distributed across each of these instances (discounted instance redundancy). In vertical partitioning, a given database scheme is distributed across multiple nodes, using normalized distribution based on the properties of this particular object.

[0046] This disclosure uses a horizontal partitioning scheme for the data structure of a blockchain ledger within a group of associated nodes called "shards". Each shard is assigned a unique identifier. There exists a group called "all shards" that encompasses all shards. Each node in the blockchain network may belong to one or more shards (including the "all shards" group). Nodes belonging to a shard are called members of that shard. In the example of Figure 2, nodes A1 and A2 are members of shard A (belonging to shard A), nodes B1 and B2 are members of shard B (belonging to shard B), node C is a member of both shards A and B (belonging to both shards A and B), and node D is a member of the "all shards" group (belonging to the "all shards" group). Other shards may also be used. Furthermore, each node is configured to store the data structure of the blockchain ledger, which corresponds to the blockchain ledger belonging to one or more shards. In the example of Figure 2, the data structure of the blockchain ledger includes the Bitcoin-related data structure for each shard. This data structure includes the UTXO set for each shard, the transaction queue (mempool) for each shard, the transaction data for each shard (labeled as TX data), and the block data for each shard. The UTXO set for each shard represents the unspent transaction outputs (UTXOs) that can be used as inputs to new transactions.

[0047] In the embodiments described herein, the block data maintained by a given node includes block data to which the given node belongs (or more) shards. This block data includes data representing blocks of the blockchain ledger and may include the following data for each block: i) a block header including a local Merkle tree along with other data of the block, and / or ii) a list of transaction identifiers for transactions that are part of the block; this list includes transaction identifiers only for transactions that are part of the block and associated with which the given node belongs (or more) shards; and the list does not include transaction identifiers for transactions that are part of the block and not associated with which the given node belongs (or more) shards. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and associated with which the given node does not belong (or more) shards, but omits hash values ​​derived from transactions that are part of the block and associated with which the given node belongs (or more) shards. Local Merkle trees can be used to allow nodes to verify and compute the Merkle tree root hash of a block without accessing transactions that are part of the block and not associated with one or more shards to which the node belongs. In this way, the list of local Merkle trees (i) and (ii) of a given block, which are part of the block data, can vary among nodes based on node membership and the distribution of transactions within the shards. Advantageously, using the local Merkle tree associated with the block header and other data, as described in this embodiment, given the narrow nature of sharded blockchain networks and the protocols described herein for establishing information that each node can or cannot store, it is possible to accurately retain and use the necessary details of the block for verification and transmission without requiring each node to store and verify all UTXOs associated with a given transaction. As will be further explained in this article, the generation and use of local Merkle trees for processing block information are facilitated by the following: the structure of the fragmented network, and the protocols used by nodes within the fragmented network for communication and data flow within the same fragment, plus other protocols for communication and data flow of one or more nodes outside the fragment associated with the node.

[0048] In the example of Figure 2, nodes A1 and A2 store copies of the UTXO set of shard A, copies of the transaction queue (memory pool) of shard A, copies of the transaction data of shard A, and copies of the block data of shard A. Nodes A1 and A2 do not store the following: copies of the UTXO settings of other shards (excluding shard A), copies of the transaction queue (memory pool) of other shards (excluding shard A), and copies of the transaction data of other shards (excluding shard A). Furthermore, the block data for shard A includes data representing blocks in the blockchain ledger and may include the following data for each block: i) a block header including a local Merkle tree along with other block data, and ii) a list of transaction identifiers for transactions that are part of the block; this list includes transaction identifiers only for transactions that are part of the block and associated with shard A; and the list does not include transaction identifiers for transactions that are part of the block but not associated with shard A. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and not associated with shard A, but omits hash values ​​derived from transactions that are part of the block and associated with shard A.

[0049] Nodes B1 and B2 store copies of the UTXO settings of shard B, copies of the transaction queues (memory pool) of shard B, copies of the transaction data of shard B, and copies of the block data of shard B. Nodes B1 and B2 do not store the following: copies of the UTXO settings of other shards (excluding shard B), copies of the transaction queues (memory pool) of other shards (excluding shard B), and copies of the transaction data of other shards (excluding shard B). Furthermore, the block data for shard B includes data representing blocks in the blockchain ledger and may include the following data for each block: i) a block header including the local Merkle tree along with other block data, and ii) a list of transaction identifiers for transactions that are part of the block; this list includes transaction identifiers only for transactions that are part of the block and associated with shard B; and the list does not include transaction identifiers for transactions that are part of the block and not associated with shard B. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and not associated with shard B, but omits hash values ​​derived from transactions that are part of the block and associated with shard B.

[0050] Node C stores copies of the UTXO settings of shard A, the UTXO settings of shard B, the transaction queues (memory pool) of shard A, the transaction queues (memory pool) of shard B, the transaction data of shard A, the transaction data of shard B, and the block data of shards A and B. Node C does not store the following: copies of the UTXO settings of other shards (excluding shards A and B), copies of the transaction queues (memory pools) of other shards (excluding shards A and B), and copies of the transaction data of other shards (excluding shards A and B). Furthermore, the block data for shards A and B includes data representing blocks in the blockchain ledger and may include the following data for each block: i) a block header including the local Merkle tree along with other block data, and ii) a list of transaction identifiers for transactions that are part of the block; this list includes transaction identifiers only for transactions that are part of the block and associated with shard A or B; and the list does not include transaction identifiers for transactions that are part of the block and not associated with shard A or B. The local Merkle tree stored in the block header includes hash values ​​derived from transactions that are part of the block and not associated with shard A or B, but omits hash values ​​derived from transactions that are part of the block and associated with shard A or B.

[0051] Node D stores copies of the UTXO settings of all shards, copies of the transaction queues (memory pools) of all shards, copies of the transaction data of all shards, and copies of the block data of all shards.

[0052] It should be noted that by maintaining block data through nodes, transaction data for shards to which the node does not belong can be omitted, thus saving node storage space. Therefore, some nodes (e.g., nodes A1, A2, B1, B2, and C) store only a finite subset of the blockchain ledger's transaction data structure, while other nodes (e.g., node D) store the entire transaction data structure of the blockchain ledger. In this situation, the data storage capacity of nodes storing a limited subset of the blockchain ledger's data structure (e.g., nodes A1, A2, B1, B2, and C) can be much smaller than the data storage capacity of nodes storing the entire blockchain ledger's data structure (e.g., node D). It should be noted that in other blockchain ledgers, other data structures can be stored and maintained for different shards.

[0053] The horizontal partitioning scheme in Figure 2 allows node operators to select or choose to become members of one or more shards of the blockchain network. This allows small parties with limited data storage capacity (such as addicts) to select as members of a single shard, while large parties with greater data storage capacity (such as financial institutions) can select or choose to become members of all shards.

[0054] Furthermore, each node can be configured to perform block verification operations that only verify transactions associated with one or more shards to which the node belongs. In such operations, the verification of any transactions associated with another shard to which the node does not belong is skipped and does not affect whether the block is considered valid by the node. In this case, operators who choose to be members of a single shard have a lighter security concern by verifying a limited set of transactions in the blockchain ledger, while operators who choose to be members of all shards have a greater security concern by verifying all transactions in the blockchain ledger.

[0055] It should be noted that nodes can be grouped to communicate with multiple other nodes within a single shard to prevent Sybil attacks. Such attacks can effectively omit transactions sent from nodes, thus preventing their further propagation over the network. One or more nodes in a given shard can also be assigned to exchange information related to nodes in other shards, and such assignments can rotate among nodes in a given shard over time. Each node can broadcast each transaction it receives to other nodes to which it is coupled, and if the given node is not a member of the shard and does not perform full transaction verification, it performs basic transaction-level checks before forwarding transactions.

[0056] Details about other nodes can also be shared among nodes in a specific shard at different or specific times / moments. This is implemented according to a second embodiment of the disclosure using a modified version of the addr protocol message. The current implementation of the addr message, which is part of the Bitcoin protocol, is used to enumerate or identify one or more IP addresses and ports. For example, a getaddr request can be used to obtain a bundle of addresses of peer devices known in operation (e.g., for startup). Addr messages often contain only one address, but sometimes contain many, and in some instances up to 1000 addresses. In some instances, all nodes periodically, i.e., once every 24 hours, broadcast an addr containing their own IP address. Nodes can then relay these messages to their peer devices, and can store the relayed addresses if the message is new to the node. In this way, nodes in the network can have a reasonably clear picture of their IPs when or after connecting to the network. In most cases, IP addresses are added to each person's address database due to the initial addr broadcast.

[0057] In addition to the above, embodiments of the modified addr protocol according to this disclosure may be able to transmit additional information about the fragment to which a particular node belongs. For example, in the modified address protocol, when a node in a shared network such as FIG1b joins a particular fragment in the network, the content broadcast as part of the addr message may also include a field identifying that the node is a member of one or more fragments. This information is also thus responded to in response to a getaddr request from a peer device in the network of FIG1b being returned. As discussed in the first embodiment, this information may be based on a data structure associated with each node and / or each fragment to which the node is associated.

[0058] Figures 3A and 3B together illustrate the process of generating, verifying, and mining blockchain transactions as a part of a sharded blockchain ledger, such as the sharded blockchain ledger in Figure 2.

[0059] In block 301, a user node generates a blockchain transaction, wherein the blockchain transaction is associated with (or assigned to or allocated to) one or more shards of the blockchain network. The shard associated with a valid blockchain transaction may be a shard associated with the blockchain transaction itself, or a shard associated with one or more transaction inputs or transaction outputs of the valid blockchain transaction. For example, in one embodiment, the shard associated with a valid blockchain transaction may be based on a transaction identifier of the blockchain transaction, which is generated by applying a SHA256 function to the transaction data of the blockchain transaction. More specifically, the shard associated with a valid blockchain transaction may be determined by applying a modulo operation of the number of currently active shards on the blockchain network to the transaction identifier, i.e., shard identifier = TX ID mod n, where n is the number of currently active shards. In another embodiment, the shard associated with a valid blockchain transaction may be based on a first or other input of the blockchain transaction and the output of an earlier transaction to which the input points. In this scenario, the transaction whose output is referenced by the first input of a subsequent transaction is referred to as the "parent" transaction, and the subsequent transaction is referred to as the "child" transaction. It should be noted that the first input is used to define a parent transaction that is not essential to the method; any input can be selected to execute the method in the presence of multiple inputs. For example, if a specific number of inputs to a child transaction refer to the outputs of transactions in the same shard as the parent transaction, then an earlier transaction can be defined as the parent transaction of the child transaction. The number of inputs can define the number of inputs to a child transaction. Details of these mechanisms are set forth in UK Patent Application No. 1806907.0 and UK Patent Application No. 1806909.6, both of which are jointly assigned to the assignee of this application and are incorporated herein by reference in their entirety. In other embodiments, other mechanisms can be used to associate blockchain transactions with one or more shards of the blockchain network.

[0060] In box 303, the client node broadcasts a blockchain transaction for transmission to nodes belonging to one or more shards associated with the blockchain transaction (and may also transmit to other nodes belonging to shards not associated with the blockchain transaction).

[0061] In box 305, a node belonging to one or more shards associated with a blockchain transaction receives a blockchain transaction.

[0062] In box 307, a node belonging to one or more shards associated with a blockchain transaction verifies the received blockchain transaction or a portion thereof, and if and when the received blockchain transaction or a portion thereof is deemed valid, each node propagates the blockchain transaction to other nodes in the shard to which it belongs.

[0063] In one embodiment (referred to as "transaction shard verification"), the transaction verification in block 307 is performed by the shard to which the transaction is associated or assigned. As described above, a transaction can be associated with (or assigned to) a shard using the result of a modulo function of a transaction identifier applied to the transaction. Because a transaction can have inputs from a shard, a node can communicate with nodes in other shards for UTXO checks. Specifically, a node belonging to one or more shards can request nodes belonging to other shards to retrieve the UTXO settings of those other shards. If none of the nodes have the requested UTXO settings, an empty response is given, and the transaction in question is considered invalid. When the transaction input is considered valid, the transaction is added to the transaction queue (memory pool) of the shard to which the transaction is associated or assigned (block 309), and the transaction is propagated to other nodes in that shard (block 311).

[0064] In another embodiment (referred to as "UTXO-based verification"), the transaction verification in block 307 is based on input verification transactions, which are associated with UTXO settings within the same shard as the node performing the verification. Inputs associated with UTXO settings in different shards are not verified. Verification of each input may involve checking to confirm that the UTXO of the referenced output has not been spent, verifying (e.g., code verification) the input authorized to collect the value of the referenced input, and a number of other checks. In cases of invalid input (such as when the UTXO associated with the input does not exist, the value of the transaction's output is greater than the corresponding input's UXTO, or a code error exists), the transaction is discarded and not propagated to other nodes in the same shard. If the input is considered valid, the transaction is added to the transaction queue (memory pool) of the shard of the node performing the verification (block 309), and the transaction is propagated to other nodes in this shard (block 311).

[0065] Details of the “Transaction Sharding Verification” and “UTXO Sharding-Based Verification” embodiments are set forth in UK Patent Application No. 1806911.2 and UK Patent Application No. 1806914.6, which are jointly assigned to the assignee of this application and are incorporated herein by reference in their entirety.

[0066] In an embodiment, the verification of the transaction in block 307 may also involve checking and confirming that the transaction is generally related to the transaction, such as checking and confirming whether the syntax and data structure of the transaction are correct, checking and confirming that the transaction is smaller than the allowed block size and is greater than or equal to 100 bytes, and checking and confirming that the lock time is less than the maximum allowed number.

[0067] In box 309, a node belonging to the shard associated with a valid blockchain transaction adds the valid blockchain transaction to the transaction queue (memory pool) of the shard associated with the valid blockchain transaction.

[0068] In box 311, one or more nodes (e.g., miners) form a block from the transaction queue (memory pool) of a shard (e.g., the memory pool of the "all shards" group) and propagate this new block to other nodes.

[0069] In box 313, the node receives the new block and processes the new block based on the consensus protocol for block verification and block submission.

[0070] Figures 4A and 4B together are flowcharts describing the operation of verifying a new block generated by a miner targeting nodes that are not members of all shards, as shown in box 313 of Figures 3A and 3B. In this situation, the node belongs to a restricted subset of the active shards and therefore does not belong to one or more active shards. Note that any node that is a member of all shards can use a well-known block verification procedure to verify the new block.

[0071] In box 401, the node receives a new block. In an embodiment, the block includes a block header and lists data representing an ordered sequence of TX identifiers of the block. In a decentralized blockchain system of the Bitcoin type shown in Figure 2, the block header may include the following data fields: [1] Block version number, which indicates which set of block verification rules is followed: [2] Previous block header hash, which is the SHA256 (SHA256()) hash of the tuple order within the header of the previous block. This ensures that no previous block can be modified without altering the header of this block; [3] the Merkle root hash derived from the hashes of all transactions included in this block, thus ensuring that none of those transactions can be modified without modifying the header; [4] the block time, which is the Unix time at which the miner began hashing the header (according to the miner); [5] nBits, which is the encoded version of the target threshold value that the header hash of this block must be less than or equal to; and [6] the temporary flag, which is any number of hashes that the miner changes to modify the header hash to produce a hash less than or equal to the target threshold value. An example block with these fields is shown in Figure 6A.

[0072] In box 403, the node extracts an ordered list of transaction identifiers ("TX identifiers" or "TX Id") stored in the block received in box 401. An example list of transaction identifiers of a block is schematically shown in Figure 6A.

[0073] In box 405, the node generates data representing a full Merkle tree of ordered sequences of transaction identifiers of the block extracted in box 403. The full Merkle tree is a tree with ordered sequences of leaf nodes corresponding to ordered sequences of transaction identifiers of the block. Each leaf node includes a hash of the transaction data referenced by the corresponding transaction identifier, and each non-leaf node includes a cryptographically encoded hash of the hash values ​​of its child nodes. The non-leaf nodes of the full Merkle tree are logically organized at several levels extending upwards from the leaf (bottom) to the root, which stores the root hash value of the full Merkle tree, as is well known. An example full Merkle tree of a block is schematically shown in Figure 6A.

[0074] In box 407, the node extracts the Merkle root hash value as stored in the header of the block received in box 401, and the node compares the extracted Merkle root hash value with the root hash value of the full Merkle tree generated in box 405.

[0075] In box 409, the node evaluates the comparison value of box 407 to determine whether the extracted Merkle root hash value matches the root hash value of the full Merkle tree generated in box 405. If not, the operation continues to blocks 439 and 441. If yes, the operation continues to box 411.

[0076] In box 411, the node evaluates other header conditions for the validity of the block.

[0077] In box 413, the node checks the evaluation in box 411 to determine whether other header conditions for the validity of the block have been met. If not, the operation continues to boxes 439 and 441. If yes, the operation continues to box 415.

[0078] In box 415, node assembly is performed by looping through an ordered sequence of transaction identifiers of blocks extracted as in box 403, and the operations of boxes 417 to 425 are performed for each given transaction identifier in the loop.

[0079] In box 417, the node identifies the fragment corresponding to the transaction referenced by the given transaction identifier. The fragment corresponding to the transaction can be a fragment associated with the transaction itself or a fragment associated with one or more transaction inputs or transaction outputs of the transaction. Examples of institutions that can be used to specify the association (or correspondence) between a transaction and one or more fragments are described above with respect to box 301 of Figures 3A and 3B.

[0080] In box 419, the node checks whether it belongs to the fragment identified in box 417. If not, the operation continues to box 421. If yes, the operation continues to box 422.

[0081] In box 421, the node freely removes the given transaction identifier from the ordered sequence of transaction identifiers of the block extracted in box 403, and the operation continues to box 425.

[0082] In box 423, the node checks whether the transaction referenced by the given transaction identifier is valid. If the transaction referenced by the given transaction identifier is determined to be valid, the operation continues to box 425. If not, the operation continues to boxes 439 and 441. In an embodiment, the node may check whether the transaction referenced by the given transaction identifier is stored in the transaction queue (memory pool) of the shard to which the node belongs. If yes, the transaction can be considered valid, and the operation continues to box 425. If not, the node may communicate with another node in the network to request and obtain a copy of the transaction. Once received, the node can perform operations to verify the received transaction. Examples of such verification operations are described above with reference to box 307 of Figures 3A and 3B. If the transaction is considered valid, the operation continues to box 425. If the transaction is considered invalid, the operation continues to boxes 439 and 441.

[0083] In box 425, the node checks whether all transaction identifiers have been processed in a loop through the ordered sequence of transaction identifiers as configured in box 415. If not, the operation resumes to box 415 to continue looping for the next transaction identifier in the list. If yes, the operation continues to box 427.

[0084] Please note that the operation checks in boxes 419 to 425 are for the validity of transactions associated with the shard to which the node belongs, and therefore the verification of transactions associated with shards to which the node does not belong is skipped.

[0085] In box 427, nodes can generate and store data that marks blocks as valid.

[0086] In box 429, the node stores data including a list of transaction identifiers for the block. This list of transaction identifiers may omit transaction identifiers associated with shards to which the node does not belong, thus avoiding the need to store a complete list of ordered sequences of transaction identifiers for the block.

[0087] In box 431, the node derives data representing the local Merkle tree of the block. The details of this operation are described below with reference to Figure 5.

[0088] In box 433, the node updates the block header data to include the local Merkle tree of the block as exported in box 431.

[0089] In box 435, the node stores data representing the block (including the header updated in box 433 using a local Merkle tree for the block, and data including the resulting list of blocks as stored in box 429) as part of the block data to which the node belongs. This operation can store the block representation to persistent storage, such as a disk or other form of persistent data storage. The instance header data and transaction list data representing the block are schematically shown in Figure 6D.

[0090] Note that the local Merkle tree in box 431 may omit branches derived from transactions associated with shards to which the node does not belong, and includes placeholders (for hash values) along the branches derived from transactions associated with the shards to which the node belongs. Therefore, in many cases, the nodes and hierarchy of the local Merkle tree will be unbalanced relative to the conventional form of the full Merkle tree. Importantly, the operation of reducing the full Merkle tree to produce a local Merkle tree can be used to reduce the storage requirements of the local Merkle tree in the header of block data to which a node belongs. Since Merkle tree branches are the result of cascading branches or leaves below branches and hashes, the full Merkle tree can be reduced based on the complete path in the tree. Where a branch results in a sufficiently complete leaf, such a branch can be removed, leaving only its hash. Each hash from the Merkle root to a leaf can be removed so that the root hash of the local Merkle tree can be regenerated by placeholder replacement. By implementing this procedure, the number of hashes that need to be stored in the local Merkle tree can be reduced, thereby lowering storage requirements.

[0091] In box 437, a node may propagate a new block received in box 401 to other nodes.

[0092] In box 439, a node can generate and store data that marks a block as invalid.

[0093] In box 441, a node may discard data representing an invalid block and avoid propagating the invalid block to other nodes. A node may also discard transaction data of one or more transactions that are part of an invalid block assigned to a shard, and, where appropriate, return the UTXOs of such transactions to the shard's UTXO settings.

[0094] Figure 5 is a flowchart illustrating an exemplary operation performed by nodes to derive data representing a local Merkle tree of blocks.

[0095] In box 501, the node reads the block header and the ordered list of block transaction identifiers.

[0096] In box 503, the node uses a list of transaction identifiers of the block, as read in box 501, to generate data representing the full Merkle tree of the block.

[0097] In box 505, node assembly is performed by cycling through an ordered list of transaction identifiers of the block, which correspond to hash values ​​(from left to right) at the bottom level of the full Merkle tree. The operations in boxes 507 to 513 are performed for each given transaction identifier in the list.

[0098] In box 507, the node checks whether the transaction referenced by the given transaction identifier corresponds to the shard to which the node belongs. Examples of institutions that can be used to specify the association or correspondence between a transaction and one or more shards are described above with respect to box 301 of Figures 3A and 3B. If the transaction referenced by the given transaction identifier does not correspond to the shard to which the node belongs, the operation continues to boxes 509 and 513. If the transaction referenced by the given transaction identifier does correspond to the shard to which the node belongs, the operation continues to box 511.

[0099] In box 511, the node replaces a given transaction identifier (hash value) in the list with a placeholder, and the operator proceeds to box 513. The placeholder is a data value or character with a smaller encoded size relative to the encoded size of the transaction identifier in the list. The placeholder is also arranged such that it is easily identifiable from the allowed values ​​of the transaction identifier in the list. In an embodiment, the placeholder may be a null value or a specific character. Ideally, the placeholder should provide the maximum space reduction relative to a 256-bit hash. Alternatively, the placeholder may provide some other minimum to maximum space reduction relative to a 256-bit hash value.

[0100] In box 513, the node checks whether any transaction identifiers are being processed through the loop of transaction identifiers as configured in box 505. If yes, the operation resumes to box 505 to continue the loop for the next transaction identifier in the list. If not, the operation continues to box 515.

[0101] Please note that the operations in boxes 507 to 513 replace the transactions corresponding to the shard to which the node belongs with placeholders from the transaction identifiers in the bottom (leaf) level of the whole Merkle tree.

[0102] In box 515, the node sets the current level index of the Merkle tree to the bottom (or leaf node level) of the entire Merkle tree, as represented by the data generated in box 503.

[0103] In box 517, the node checks whether the current level indicator of the Merkle tree points to the root level in the entire Merkle tree. If not, the operation continues to box 533. If yes, the operation continues to box 519.

[0104] In box 519, nodes are assembled at the current level of the full Merkle tree (which is referenced by the current level index of the Merkle tree) by a cycle of adjacent node pairs. This cycle performs the operations of boxes 521 to 529 for each given adjacent node pair at the current level of the full Merkle tree.

[0105] In box 521, the node checks whether each of the two nodes in a given pair of adjacent nodes contains a hash value (distinguished from a placeholder). Note that the node in a pair of adjacent nodes at the bottom level of the full Merkle tree refers to the corresponding element in the ordered list of transactions and placeholders generated by the operations in boxes 505 to 513 as described above, where this correspondence is indicated by matching the position in the list of transactions and placeholders with the position of the leaf node (from left to right) at the bottom level of the full Merkle tree. If this condition is not met, the two nodes of the given pair of adjacent nodes are left alone in box 523, the hash value of the parent node of the given pair of adjacent nodes is replaced with a placeholder in box 525, and the operation continues to box 529. If this condition is met, the node removes both nodes of the given pair of adjacent nodes, and the hash value of the parent node of the pair of adjacent nodes is left alone in box 527, and the operation continues to box 529.

[0106] In box 529, the node check confirms that any further adjacent nodes at the current level of the full Merkle tree are kept in a loop through the adjacent node pairs assembled as in box 519. If yes, the operation resumes to box 519 to continue the loop for the adjacent node pairs at the current level of the full Merkle tree. If not, the operation continues to box 531.

[0107] In box 531, the node adjusts the current level indicator of the Merkle tree to point to the level below the full Merkle tree, and the operation continues to repeat the operations of boxes 517 to 529 for the level below the full Merkle tree.

[0108] In box 533, the node replaces or supersedes the root node hash value of the whole Merkle tree with a placeholder, and the operation ends.

[0109] Figure 6A illustrates the full Merkle tree of an exemplary block.

[0110] Figure 6B illustrates the results of operations on the full Merkle tree of the exemplary block in Figure 6A, as shown in blocks 519 to 529 of the flowchart in Figure 5. In these operations, placeholders have replaced the hash values ​​(transaction identifiers) of six transactions at the bottom level of the full Merkle tree, where these transactions correspond to the shard to which the node belongs.

[0111] Figure 6C illustrates the results of the operations performed on the full Merkle tree of Figure 6A, as shown in blocks 519 to 529 of the flowchart in Figure 5. In these operations, two adjacent hash values ​​(on the upper left side of the full Merkle tree) in the bottom level of the full Merkle tree have been removed because these hash values ​​are derived from transactions that do not correspond to the shard to which the node belongs. Furthermore, in three cases where adjacent nodes do not all have corresponding hash values ​​and are therefore derived from at least one transaction corresponding to the shard to which the node belongs, placeholders have replaced the parent node of the adjacent leaf node in the second level of the full Merkle tree (on the upper left side of the full Merkle tree).

[0112] Figure 6D illustrates the operation results of the flowchart in Figure 5, which is a local Merkle tree of the full Merkle tree in Figure 6A.

[0113] Figures 7A to 7C are collectively flowcharts of the operation performed by nodes that are not members of all shards to verify blocks stored as a portion of a sharded blockchain ledger, such as the one in Figure 2. In this case, the node belongs to a restricted subset of the active shards and therefore does not belong to one or more active shards. Note that any node that is a member of all shards can use a well-known block verification procedure to verify a new block.

[0114] In box 701, the node reads a block from the block data of the shard to which it belongs. The block data includes a block header, which includes information representing the local Merkle tree of the block. The block header may also include other fields. The block data also includes an ordered list of transaction identifiers for transactions that are part of the block and correspond to the shard to which the node belongs. Example block data is schematically shown in Figure 8A.

[0115] In box 703, the node extracts an ordered list of transaction identifiers of blocks, such as those stored in the block data read in box 701. The list of transaction identifiers may omit parts of the block that correspond to transactions to which the node does not belong, and thus avoids storing a complete list of the ordered sequence of transaction identifiers of blocks.

[0116] In box 705, node extraction represents the local Merkle tree data of the block as stored in the block data read in box 701.

[0117] In box 707, the node sets the current level index of the local Merkle tree to the bottom level of the local Merkle tree as represented by the data extracted from box 705.

[0118] In box 709, node assembly is performed by looping through the tree nodes of the current level of the local complete Merkle tree (which is the bottom level referenced by the local Merkle tree current level index as set in box 707). This loop performs the operations of boxes 711 to 717 for each given tree node at the bottom level of the local Merkle tree.

[0119] In box 711, the node checks whether the given tree node is a placeholder. If not, the node skips the tree node in box 713 and continues to box 717. If not, the node continues to box 715 where the node replaces the placeholder with the corresponding transaction identifier (hash value) from the list extracted in box 703, and the operation continues to box 717. Note that the correspondence between the placeholder and the transaction identifier (hash value) from the list extracted in box 703 can be indicated by the correspondence between the order of the placeholders in the bottom level of the local Merkle tree and the order of the transaction identifiers in the list extracted in box 703.

[0120] In box 717, the node check confirms whether any additional tree nodes at the current level of the local Merkle tree (which are no longer referenced by the local Merkle tree current level index) are still being processed in the loop through the tree nodes as assembled in box 709. If yes, the operation resumes to box 709 to continue the loop for the next tree node. If not, the operation continues to box 719.

[0121] In box 719, the node sets the current level of the local Merkle tree to the level below the local Merkle tree represented by the data extracted in box 705 (which is a level above the bottom leaf node level).

[0122] In box 721, the node checks whether the current level indicator of the local Merkle tree points to the root level in the local Merkle tree. If yes, the operation continues to box 735. If no, the operation continues to box 723.

[0123] In box 723, node assembly is performed by looping through the tree nodes of the current level of the local full Merkle tree (which is referenced by the local Merkle tree current level index as set in boxes 719 or 733). This loop performs the operations of boxes 725 to 731 for each given tree node of the current level of the local Merkle tree.

[0124] In box 725, the node checks whether the given tree node is a placeholder. If not, in box 727, the node skips the tree node and continues to box 731. If not, the node continues to box 729, where the node calculates a hash value based on the hash values ​​of the two child nodes of the given tree node and replaces the placeholder with this calculated hash value, and the operation continues to box 729.

[0125] In box 729, the node check confirms that any additional tree nodes at the current level of the local Merkle tree (referenced by the local Merkle tree current level index) remain in the loop processing through the tree nodes as assembled in box 723. If yes, the operation resumes to box 723 to continue looping for the next tree node. If not, the operation continues to box 733.

[0126] In box 733, the node adjusts the current level index of the local Merkle tree to point to the next level below the local Merkle tree, and the operation is restored to box 721 to process the next level in the local Merkle tree.

[0127] In box 735, the node calculates a hash value based on the two child nodes of the root node as determined by the operations from boxes 709 to 731, and replaces the placeholder of the root node with the calculated hash value.

[0128] In box 737, the node extracts the Merkle root hash value stored in the block header as part of the block data read in box 701, and the node compares the extracted Merkle root hash value with the root hash value of the local Merkle tree calculated in box 735.

[0129] In box 739, the node evaluates the comparison value in box 737 to determine whether the extracted Merkle root hash value matches the root hash value of the local Merkle tree calculated in box 735. If yes, the operation continues to box 741. If no, the operation continues to boxes 755 and 757.

[0130] In box 741, the node evaluates other header conditions for the validity of the block.

[0131] In box 743, the node checks the evaluation in box 741 to determine whether all other header conditions for the validity of the block have been met. If yes, the operation continues to box 745. If not, the operation continues to boxes 755 and 757.

[0132] In box 745, node assembly is performed by looping through a list of transaction identifiers extracted in box 703. The list of transaction identifiers may omit transactions associated with shards to which the node does not belong, thus avoiding the storage of a complete list of ordered sequences of transaction identifiers for blocks. This loop performs the operations of boxes 747 to 749 for each given transaction identifier in this list.

[0133] In box 747, the node checks whether the transaction referenced by the given transaction identifier is valid. If the transaction referenced by the given transaction identifier is determined to be valid, the operation continues to box 749. If not, the operation continues to boxes 755 and 757. In an embodiment, the node may check whether the transaction referenced by the given transaction identifier is stored in the transaction queue (memory pool) of the shard to which the node belongs. If yes, the transaction can be considered valid, and the operation continues to box 749. If not, the node may communicate with another node in the network to request and obtain a copy of the transaction. Once received, the node can perform operations to verify the received transaction. Examples of such verification operations are described above with reference to box 307 of Figures 3A and 3B. If the transaction is considered valid, the operation continues to box 749. If the transaction is considered invalid, the operation continues to boxes 755 and 757.

[0134] In box 749, the node checks to confirm that any transaction identifiers remain in the loop of transaction identifiers as configured in box 745. If yes, the operation resumes to box 745 to continue the loop for the next transaction identifier in the list. If not, the operation continues to boxes 751 and 753.

[0135] In box 751, nodes are generated and stored to mark blocks as valid.

[0136] In box 753, a node can propagate data representing a valid block to other nodes belonging to the same set of shards as the node.

[0137] In box 755, a node generates and stores data that marks a block as invalid.

[0138] In box 757, a node may discard block data representing an invalid block and avoid propagating the block data representing an invalid block to other nodes. A node may also discard transaction data of one or more transactions that are part of an invalid block assigned to a shard, and, where appropriate, return the UTXOs of such transactions to the shard's UTXO settings.

[0139] Figure 8A illustrates the local Merkle tree of an exemplary block.

[0140] Figure 8B illustrates the results of the operations on the local Merkle tree of Figure 8A in blocks 709 to 717 of the flowcharts of Figures 7A to 7D. In these operations, the five placeholders in the lower (leaf) level of the local Merkle tree have been replaced by the corresponding hash values ​​(transaction identifiers) that are part of the list of transaction identifiers extracted in block 703.

[0141] Figure 8C illustrates the results of the operations on the local Merkle tree of Figure 8A in flowcharts 723 to 731 of Figures 7A to 7D. In these operations, the three placeholders in the second level of the local Merkle tree have been replaced with hash values ​​derived from the hash values ​​of their child nodes.

[0142] Figure 8D illustrates the results of the operations on the local Merkle tree of Figure 8A in flowcharts 723 to 737 of Figures 7A to 7D. In these operations, the hash value of the root of the local Merkle tree is derived from the hash values ​​of its child nodes and compared with the Merkle root hash value stored in the block header of the block for verification.

[0143] FIG9 is an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any of the systems described and illustrated above. For example, the computing device 2600 can be configured as a data server, web server, portable computing device, personal computer, or any electronic computing device. As shown in FIG9, the computing device 2600 may include one or more processors 2602 that can be configured to communicate with and operatively coupled to several peripheral subsystems via bus subsystem 2604. As part of verifying a spending transaction as described herein, the processor 2602 can be used to process unlocking and locking of instruction codes. These peripheral subsystems may include a storage subsystem 2606, comprising a memory subsystem 2608 and a file / disk storage subsystem 2610; one or more user interface input devices 2612; one or more user interface output devices 2614; and a network interface subsystem 2616. This storage subsystem 2606 may be used for the temporary or long-term storage of information, such as details associated with the transactions and blocks described in this disclosure.

[0144] Bus subsystem 2604 provides a mechanism for enabling various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Network interface subsystem 2616 provides an interface to other computing devices and networks. Network interface subsystem 2616 can act as an interface for receiving data from and transmitting data to other systems from computing device 2600. For example, network interface subsystem 2616 can enable a data technician to connect the device to a wireless network, allowing the data technician to transmit and receive data when at a remote location (such as a user data center). The bus subsystem 2604 can be used to transmit information such as details and search items to the monitoring model disclosed herein, and can be used to transmit the output of the monitoring model to one or more processors 2602 and merchants and / or creditors via the network interface subsystem 2616.

[0145] The user interface input device 2612 may include one or more user input devices, such as a keyboard; pointing devices, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen integrated into the display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. Generally, the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to the computing device 2600. The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display (such as an audio output device). The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projector or other display device. Generally, the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate interaction between the user and the application performing the described process and its changes (where such interaction may be appropriate).

[0146] Storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data construction that provide functionality for at least one embodiment of the present disclosure. Application programs (programs, code modules, instructions) that provide functionality for one or more embodiments of the present disclosure when executed by one or more processors may be stored in storage subsystem 2606. Such application modules or instructions may be executed by one or more processors 2602. Storage subsystem 2606 may additionally provide a repository for storing data used according to the present disclosure. Storage subsystem 2606 may include memory subsystem 2608 and file / disk storage subsystem 2610.

[0147] The memory subsystem 2608 may include several memories, including a main random access memory (RAM) 2618 for storing instructions and data during program execution and a read-only memory (ROM) 2620 for storing fixed instructions. The file / disk storage subsystem 2610 provides non-transitory permanent (non-volatile) storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a CD-ROM drive, a CD drive, a removable media cartridge, and other similar storage media.

[0148] The computing device 2600 may include at least one local clock 2624. The local clock 2624 may be a counter representing the number of ticks that have occurred since a specific start date, and may be entirely located within the computing device 2600. The local clock 2624 may be used to synchronize data transfers between the processor of the computing device 2600 and all its included subsystems with specific clock pulses, and may be used to coordinate synchronous operation between the computing device 2600 and other systems in a data center. In one embodiment, the local clock 2624 is an atomic clock. In another embodiment, the local clock is a programmable interval timer.

[0149] The computing device 2600 may be of various types, including portable computer devices, tablet computers, workstations, or any other devices described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that can be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, this device can be configured to convert optical signals into electrical signals that can be transmitted via the ports connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 depicted in FIG9 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations with more or fewer components than the system depicted in FIG9 are possible.

[0150] Additional examples describing certain aspects or embodiments of the present invention:

[0151] Example 1: A computer-implemented method for maintaining several blocks of a blockchain across several nodes of a sharded blockchain network, wherein each node is a member of one or more shards in a plurality of active shards, the method comprising: generating data representing a new block of the blockchain by a given node, the given node being a member of a particular subset of the plurality of active shards; and storing the data representing the new block by the given node; wherein the data representing the new block includes i) a list of transaction identifiers for transactions that are part of the new block and associated with the particular subset of the plurality of active shards, and / or ii) a partial Merkle tree for the new block.

[0152] Second example, a computer-implemented method as in the first example, wherein: i) the list of transaction identifiers does not include transaction identifiers for transactions that are part of the new block and are not associated with that particular subset of the multiple action shards.

[0153] The third example, a computer-implemented method as in the second example, wherein: i) the list of transaction identifiers is generated by the following operations: constructing an initial list of transaction identifiers for the new block based on the data included in the new block, and processing the initial list of transaction identifiers to remove any transaction identifiers corresponding to a transaction that is not associated with the particular subset of the multiple action shards.

[0154] Fourth example, a computer-implemented method as in the first example, wherein: ii) the local Merkle tree includes hash values ​​derived from transactions that are part of the new block and are not associated with the particular subset of the shards in the plurality of actions, while omitting hash values ​​derived from transactions that are part of the new block and are associated with the particular subset of the shards in the plurality of actions.

[0155] Fifth example, a computer-implemented method as in the first example, wherein: ii) the local Merkle tree is generated by: constructing a full Merkle tree for the new block based on the data included in the new block, and processing the full Merkle tree to replace placeholders for hash values ​​derived from transactions that are part of the new block and associated with the particular subset of the multiple action shards.

[0156] Example 6, a computer-implemented method as in Example 5, wherein: processing the full Merkle tree further includes iterating from one of the bottom levels of the full Merkle tree to the root level and removing two hash values ​​for an adjacent node pair and leaving a parent hash value.

[0157] Example 7, a computer-implemented method as in Example 5, wherein: processing the full Merkle tree further includes iterating from one of the bottom levels of the full Merkle tree to the root level and replacing a placeholder for the hash value of a parent tree node having two child nodes, the two child nodes not both representing a hash value derived from a transaction not associated with the particular subset of the multiple actions.

[0158] Example 8, a computer-implemented method as in Example 1, further comprising: operating the node to process the local Merkle tree to compute one of the Merkle root hash values ​​for block verification without requiring access to the transactions, the transactions being part of the block and not associated with the particular subset of the shards in the plurality of actions.

[0159] Example 9, a computer-implemented method as in Example 8, wherein: the local Merkle tree is processed to compute the Merkle root hash value iteratively from a lower level of the local Merkle tree to the root level, and a placeholder is replaced with a hash value computed from the corresponding sub-hash value of the local Merkle tree.

[0160] Example 10, a computer-implemented method as in Example 1, wherein i) the list of transaction identifiers and ii) the local Merkle tree change among the nodes based on node membership and the allocation of the transactions among the shards.

[0161] Example 11, a computer-implemented method as in Example 1, wherein: in generating the data representing the new block, the node verifies transactions that are part of the new block and associated with the specific subset of the shards in the plurality of actions, while omitting the verification of transactions that are part of the new block and not associated with the specific subset of the shards in the plurality of actions.

[0162] Example 12, a computer-implemented method as in Example 1, wherein: the transactions that are part of the new block are associated with several shards of the plurality of actions based on transaction identifiers.

[0163] Example 13, a computer-implemented method as in Example 1, wherein: the transactions that are part of the new block are associated with a parent blockchain transaction and several shards of the plurality of actions, wherein the parent transaction is defined by an output corresponding to an input of a child blockchain transaction, and wherein both the parent transaction and the child transaction are associated with the same shard.

[0164] Example 14: A system comprising: a processor; and memory including executable instructions, which, by execution by the processor, cause the system to perform at least part of a computer-implemented method as described in any of Examples 1 to 14.

[0165] Example 15: A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor of a computer system, cause the computer system to perform at least part of the computer-implemented method as described in any of Examples 1 to 14.

[0166] It should be noted that the embodiments mentioned above are illustrative and not limiting of this disclosure, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. Any reference numerals placed in parentheses in the claims should not be considered as limiting the scope of the claims. The words "comprising" and similar terms do not exclude the presence of elements or steps other than those listed as a whole in any claim or specification. In this specification, "comprise, comprising" means "include, including" or "consist of, consisting of". A singular reference to an element does not exclude a plural reference to such element, and vice versa. This disclosure can be implemented by means of hardware comprising several unique elements and by means of a suitably programmed computer. In the item enumerating several components, some of these components can be embodied by the same item of hardware. The mere fact that certain measures are described in separate, distinct technical solutions does not imply that a combination of such measures cannot be used advantageously.

[0167] It should be understood that the above description is intended to be illustrative and not limiting. Those skilled in the art will understand many other embodiments after reading and understanding the above description. Although this disclosure has been described with reference to specific example embodiments, it should be recognized that this disclosure is not limited to the described embodiments but can be practiced with modifications and alterations within the scope of the appended claims. Therefore, this specification and drawings should be treated in an illustrative rather than limiting sense. Therefore, the scope of this disclosure should be determined with reference to the appended claims and the full scope of their equivalents. [Simplified Explanation of the Diagram]

[0029] These and other aspects of this disclosure will be apparent from the embodiments described herein and will be illustrated with reference to the embodiments described herein. Embodiments of this disclosure will now be described only by way of example and with reference to the accompanying drawings, in which:

[0030] Figure 1A illustrates a blockchain network in which various embodiments can be implemented.

[0031] Figure 1B illustrates a blockchain ledger and representative blocks, which can be maintained by the blockchain network of Figure 1A and various implementations can be carried out therein.

[0032] Figure 2 illustrates the data structure of nodes in an illustrative sharded blockchain network, along with the sharded blockchain ledger maintained by those nodes.

[0033] Figures 3A and 3B together illustrate the process of generating, verifying, and mining blockchain transactions as part of a sharded blockchain ledger, such as the sharded blockchain ledger in Figure 2.

[0034] Figures 4A and 4B together are flowcharts describing the operations performed by a node that does not verify the membership of all fragments in a new block generated by the miner.

[0035] Figure 5 is a flowchart describing the operation performed by a node that is not a member of all shards in the local Merkle tree that constructs the new block.

[0036] Figures 6A to 6D are schematic diagrams of the operation in Figure 5.

[0037] Figures 7A to 7D are flowcharts describing operations performed by nodes that are not members of all fragments in the block data maintained by the nodes; such operations process the local Merkle tree of the block to calculate the Merkle root hash value of the local Merkle tree.

[0038] Figures 8A to 8D are schematic illustrations of the operations shown in Figures 7A to 7D.

[0039] Figure 9 illustrates the computing environment in which various embodiments can be implemented.

Claims

1. A computer-implemented method for maintaining several blocks of one blockchain across several nodes in a horizontally sharded blockchain network, wherein each node is a member of one or more horizontal shards in a plurality of active operations, the method comprising: generating data representing a new block of the blockchain by a given node, the given node being a member of a specific subset of the plurality of active horizontal shards; and storing the data representing the new block by the given node; wherein the data representing the new block includes i) a list of transaction identifiers for transactions that are part of the new block and associated with the specific subset of the plurality of active horizontal shards, and / or ii) a partial Merkle tree for the new block.

2. The method implemented by the computer as described in request item 1, wherein: The list of transaction identifiers in i) does not include transaction identifiers for transactions that are part of the new block and are not associated with that particular subset of the horizontal shards in the multiple actions.

3. The computer-implemented method as described in request item 2, wherein: The list of transaction identifiers in i) is generated by the following operations: constructing an initial list of transaction identifiers for the new block based on the data included in the new block, and processing the initial list of transaction identifiers to remove any transaction identifiers corresponding to a transaction that is not associated with that particular subset of the horizontal shards in the plurality of actions.

4. The computer-implemented method as described in request item 1, wherein: The local Merkle tree in ii) is generated by the following operations: constructing a full Merkle tree for the new block based on the data included in the new block, and processing the full Merkle tree to replace placeholders for hash values ​​derived from exchanges that are part of the new block and associated with that particular subset of the horizontal shards in the plurality of actions.

5. The computer-implemented method as described in request item 4, wherein: Processing the full Merkle tree further includes iterating from the bottom level of one of the full Merkle tree levels to the root level and removing two hash values ​​for an adjacent node pair, leaving a parent hash value.

6. The computer-implemented method as described in request item 4, wherein: Processing the full Merkle tree further includes iterating from the bottom level of one of the full Merkle tree levels to the root level and replacing a placeholder for the hash value of a parent tree node having two child nodes, which do not both represent a hash value derived from a transaction not associated with that particular subset of the horizontal shards in the plurality of actions.

7. The computer-implemented method of claim 1, further comprising: operating the node to process the local Merkle tree to compute one of the Merkle root hash values ​​for block verification without requiring access to the transactions, the transactions being part of the block and not associated with the particular subset of the horizontal shards in the plurality of actions.

8. The computer-implemented method as described in request item 7, wherein: The local Merkle tree is processed to compute the Merkle root hash value iteratively from one of the lower levels of the local Merkle tree to the root level, and a placeholder is replaced with a hash value computed from the corresponding sub-hash value of the local Merkle tree.

9. The computer implementation method of claim 1, wherein the transaction identifier list in i) and the local Merkle tree in ii) change between the nodes based on node membership and the allocation of the transactions between the horizontal shards.

10. The computer-implemented method as described in claim 1, wherein: In generating the data representing the new block, the node verifies transactions that are part of the new block and associated with a specific subset of the horizontal shards in the plurality of actions, while omitting the verification of transactions that are part of the new block and not associated with that specific subset of the horizontal shards in the plurality of actions.

11. The method implemented by the computer as described in request item 1, wherein: These transactions, which constitute part of the new block, are associated with several shards of the horizontal shards in the plurality of actions based on transaction identifiers.

12. The computer-implemented method as described in request item 1, wherein: The transactions that constitute part of the new block are associated with several shards of the multiple horizontal shards based on a parent blockchain transaction, wherein the parent transaction is defined by an output corresponding to an input of a child blockchain transaction, and wherein both the parent transaction and the child transaction are associated with the same shard.

13. A system for processing blockchain transactions, comprising: a processor; and memory including executable instructions, which, by execution by the processor, cause the system to perform at least a portion of the computer-implemented methods as described in any one of claims 1 to 12.

14. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor of a computer system, cause the computer system to perform at least part of the computer-implemented method as described in any one of claims 1 to 12.

Images